有网友说我前面的日志写得太简单了，好吧，这篇我稍微详细一点。其实很为难：详细点吧，都不愿意看，简单点吧，都说看不懂！
在homezz.com后面的几个的服务器的数据转移过程中，发现很多homezz.com用户转移到新的服务器上的时候，都出现了这样那样的错误，归根结底，就是文件夹权限设置错误。旧的主机放得太开，对安全性能控制不严格，所以文件权限太大没有做限制，新服务器的安全机制更加严格，因此太大的权限服务器将会拒绝执行。下面开始讲一讲linux下的文件权限。
Linux的文件权限是linux能有如此安全性能的最大的保障之一，有朋友可能会知道，很多攻击windows的方法都是通过漏洞获取到创建用户的权限从而达到控制计算机的目的，在linux下，Root帐户有最大的权限，可以干任何事情，其他用户只能拥有自己的文件的所有权限和该改组成员赋予的文件的权限，下面开始对文件权限的一个说明。 (read on …)
快餐阅读的年代，继续用简约的几句话来描述。
linux下，每个文件和文件夹都是有权限的，他们分为可读、可写和可执行，默认的权限并不是和window一样：可读+可写+可执行；
linux下用户的对文件的控制是非常严格的，所以文件若需要任何人都可写，必须设置成 可读+可写，可读+可写的数字组合就是4+2=6 （所有人6 组成员6 公共成员6），即设置成0666；
linux下文件的可执行和win不一样，不靠后缀名来区分，因此linux下需要对可执行文件赋予可执行属性数字即为1，可以可读+可写+可执行=4+2+1，那么给三种用户都设置全属性就是 0777；
文件夹的打开即可理解成象文件夹发送了执行命令，所以文件夹没有可执行的属性，其他用户是无法打开的；
重要的来了，大家在ftp下或者在shell中用简单的chmod 0777 dir来对一个文件夹进行修改，记住，该文件夹下的所有文件不会自动继承0777属性，这个和你在windows下设置共享文件夹不是一样的效果，很多朋友犯了这样的错误，还理直气壮的说我已经把web根目录属性都设置成了0777，为何我的wordpress后台还无法在线更改。答案很简单：那是因为你所更改的那个php文件依然不是公共可读写属性，即0777；
即使文件夹属性为0777，也并不表示该文件夹下的所有文件就可以随意读写，这些文件依然有他们自身的属性，所以你必须将你需要修改的文件设置成0666；
记住：web根目录不要设置成0777，这有安全隐患。有php文件的目录也最好不要设置成0777.
此日志结束，不懂的在评论中留言，高手也请出山指点！
用了一天的时间做了一个简单的文件管理器。
特点：
目前还没有添加用户登录验证功能！欢迎大家去围观：0bad.com，目前只能保证在FireFox上最正常。
写在后面。有了jquery，处理dom真的好方便，缓存是本程序最伤脑筋的地方，一方面为了节约用户时间，所以load之后的数据必须以变量的方式缓存在浏览器里面，这个很简单，最麻烦的就是当用户创建文件夹、创建文件、删除文件夹、删除文件，一方面要保持左边的树形不要变化，另外一方面还好保证需要更改的缓存得以及时的更新。这个逻辑太麻烦了，所以现在依然有bug，可能还不少。
快餐式阅读的年代，我尽量精简我的文字
域名的主要作用是便于人类记忆，如storyday.com，而计算机最多只能认识IP地址，如202.115.22.194；
访问域名的时候，计算机做的第一件事情就是把域名的解析成IP地址，这个解析靠你设置的A记录来对应；
下面的设置请到你域名注册的网站去设置。
cname只是一个别名，请删除该域名原来所有的cname；
举例开始：如果你想storyday.com和www.storyday.com都对应到IP 216.65.69.71, 那么你设置的格式应该如下所示：
| Record Type | Record Host | Record Answer | TTL |
| A | *.storyday.com | 216.65.69.71 | 300 |
| A | www.storyday.com | 216.65.69.71 | 300 |
一般来说，设置A记录只有两个空需要填写，一个是A记录的名字，一个是IP地址。
没有WWW的一般留空或者填写“@”，多数情况留空，有www只需要填写“www”即可，IP地址就填写你需要指定的IP地址。 (read on …)
homezz.com主机群中有一台主机老是出现重启现象，很频繁，差不多2天一次。起初cosbeta也没有去注意它，因为重启的时间很短，可能也就导致web服务器中断10-30秒而已。
然而今天重启的时间发生在中国的白天，刚才就一个用户在QQ上给我说网站打不开了，等我看到消息去测试的时候，又可以打开了，看来apache服务器重启速度还是挺快的，虽然影响不大，不解决难免有点不爽！
根据cosbeta的经验，导致这样的问题多半是apache的conf文件配置有点小问题，毕竟apache服务可以强制启动，于是先去检查错误文件，得到错误的提示如下：
[Sat May 30 12:58:48 2009] [error] [client 94.26.67.199] File does not exist: /var/www/html/whm [Sat May 30 12:58:48 2009] [error] [client 94.26.67.199] File does not exist: /var/www/html/favicon.ico [Sat May 30 14:23:43 2009] [notice] caught SIGTERM, shutting down
从这个error log也不能彻底看出问题何在，所以还是test一下apache 文件的配置是否正确把。SSH登录上服务器：
root@serverx [~]# apachectl configtest
[Tue Jun 09 02:03:45 2009] [error] VirtualHost 66.40.x.X:0 — mixing * ports and non-* ports with a NameVirtualHost address is not supported, proceeding with undefined results
果然如此，原来是一个VirtualHost 配置错误，IP后面添加了通配符*作为端口号，看来apache不吃这一套，解决办法是要么去掉通配符*来通配，要么指定特定端口！
改正之后，再次test apache configuration，一切OK，问题得以解决！
只要域名在国外注册，修改DNS和修改A记录一样简单，所以国外很多虚拟主机商为了减少用户恶意或者错误绑定域名的机会，往往会要求用户将域名DNS修改成指定的DNS才能正常绑定。
恶意绑定或者错误绑定：比如我不小心将不属于我的homezz.com绑定在了我使用的虚拟主机上，这样将会导致homezz.com域名的真正拥有者无法将其绑定同一台服务器上，因为一台主机上不能有两个一模一样的域名绑定。
同一个域名无法多次绑定在同一台主机上的原因本blog以前也做过介绍，这里再次举一个简单的例子说明：虚拟主机就如同一个柜子，柜子里面的抽屉就如同虚拟主机的网站，当用户访问某个域名的时候，首先是域名解析到IP，用户连接到服务器，然后服务器通过来访的域名将指定的网站发送给用户。如果两个一模一样的域名都绑定在同一个主机上了，当用户请求的时候，服务器将不知道怎么办了。 (read on …)
考察了一个多月，决定放弃采用日本主机，主要原因如下：
至少，在没有遇到特别好的日本主机之前，cosbeta还是决定不选择日本主机了。
dreamhost具有顽强的抗WALL（据网友说本站由被reset的现象，所以特地修改）功能。早些时候，两个合租的bluehost都在非常时期被wall：一个是在17da期间，一个是在Olympic期间。幸好有dreamhost，他光荣的将cosbeta其他合租用户给临时安置了，由于dreamhost重新绑定可以更换IP（虽然这个过程比较痛苦），所以他的抗WALL功能比较强大，cosbeta甚至这样给自己说，即使不用国外所有的虚拟主机了，也得要保留dreamhost的帐号。
Dreamhost具有“超级”的处理能力。cosbeta的一个站点，由于访问过多，被bluehost警告之后，即使双倍增加cache失效时间，都被bluehost无情的赶走了，这个时候dreamhost张开双臂，将这个站点给收留了，并且一收留就是半年多，从未抱怨过，即使mysql数据库达到了惊人的200M之后，也只是不小心给我删除了一些数据而已（很快就从dreamhost自己的系统中恢复了）。最近酝酿了一个比较吃CPU的站点，到时候还是继续把最棘手的数据抓取部分交给dreamhost吧！
Dreamhost稳定的Secure Shell连接。这个我找不出有利的公共证据，但是从我个人2006年开始用dreamhost开始，用ssh做某件事情，一直都是DH的最稳定，速度也最稳定。
自从DH对推介做了修改之后，一窝蜂的国人少多了，而且续费对于中国人来说也不太容易，考虑到中美白天黑夜的时差，刚好将服务器的负载给错开，所以买国外的服务器，中国人越少，就越好。我个人觉得DH还可以尝试的，从DH的后台控制面板可以看得出来，他们的技术实力不错，至少在web开发方面不错，bluehost也还可以，bluehost在cpanel的基础上，开发了很多他们自己定制的插件，但是不足的是经常更换策略，比如现在，虚拟主机的内存分配就比以前少多了。
综上所述，dreamhost是个好伙伴
