和机房交涉了很多个来回，他们仍然坚持他们的服务器没有问题，也没有短暂的apache中断，而且还说他们这个主机上有上百的用户，只有我在抱怨这个问题。我告诉他，中国有很多人都在使用你们的reseller，他们之中的也有人向你抱怨了，希望你一定要仔细查看。

没有办法，这帮SB始终坚持自己的服务器没有问题，所以我现在打算请CPH的paveo一起来维护几个独立主机算了，这样自己弄，有啥问题就可以尽快解决。

下面是我最近的一次发送的ticket，可能会有些语法错误，但是我希望国内几个同样用这个供应商的也去反映这个问题，毕竟这个主机商能解决问题，对我们都有利。

my customers( all over the world ) often complain to me, your server DO have problems.（我的分布在世界各地的用户都在抱怨这个问题（就是一天一两次半分钟左右短暂的终端），你的服务器确实有问题）
let me describe the problem phenomenon again :（让我再次向你描述一下这个问题的现象）

(I noticed this happened when new cpanel user created )（我发现当有cpanel新用户创建的时候，这个问题就发生一次）

1. when the connection to web server  failed;（1.网站无法连接）
2.then I ping your ip, it returned me with right IP address and normal connection response which means your server is not down;（2.我马上ping你们的域名，发现返回的IP地址和连接都很正常，因此这说明你们的服务器并没有宕机）
3.and I telnet yourdomain.com 80, failed, so which means httpd service is down;（紧接着我telnet你们服务器的80端口，显示连接失败，因此你们的httpd 服务在此刻已经宕掉）

then I try again from remote server from server in  US,I got the same result（我在美国的远程服务器上操作上面的步骤，结果是一样的）

1 or 2 min later , web service returns to  normal status（1分钟到2分钟之后，你们的web服务再次恢复正常）

so , the I think the problem may caused by :（因此，我产生这个问题的原因如下：）

1. you have too many accounts on this server;（你们的服务器上的用户分配的太多）
2.errors in apache or apche conf;（apache或者apache的配置文件有错）
3.add news user, apache restart( normally, this only take 1 or 2 or 3 seconds, no affect to web server ) fail （当添加新的用户的时候，apache肯定要重启，常常这个重启的时间只需要1 2 秒钟，所以可能是这个时候重启失败）
4.before your CPANEL  monitor restart the apache,  the httpd service is down;（在重启失败和你们的web service监控检测到httpd宕机的这段时间内，web则不可用）

you said I am the  only person who  complained  this problem , you ‘re lying!  two  of my  friends( your reseller account )  have  the same problem, one of them complained to you,（你们说我是唯一抱怨这个问题的人，你们正在撒谎，我有两个朋友也遇到同样的问题，其中有一个已经在向你抱怨了）
another friend is considering to change to another web hosting provider (这句是忽悠他们的)!

IF you DO think there is no problem on you server, I can say nothing!!（如果你一定坚持说没有啥问题，我无话可说）

I want to be you big customer, but your bad server is driving my customers away!（我正在努力成为你们的大客户，但是你们却正在将我的用户赶走）

最后补充，实话说，相比起这个家供应商的主机的访问速度，这个问题也没有什么大不了的，国内知名的reseller都一样用着这家的主机。但是有的时候感觉有点不爽，因此我们正在努力让他变得更加完美。 (read on …)

今天去了东莞，那个旅行社的欠款依然只能要了部分，剩下的还在他的承诺中。回到家，打开reader想了解昨天晚上发生的事情，结果消息非常的有限，看来网络导向已经很成功。算了，还是抽点时间，写一点昨天晚上一直想写的东西吧。

虚拟主机CPU超标相关技术

美国的虚拟主机有一个不成文的规矩，那就是只要某个网站CPU超过一定的百分比，网站就会被挂起，所以无限流量，无限磁盘空间在CPU的限制之下显得是那么的苍白无力。连paveo同学都给我说过，若要是他也那样严格限制，一样可以承诺不限流量。我们熟悉的bluehost以及旗下的hostmonster就有一个严格的CPU限制标准，那就是CPU的利用超过了4%左右帐户将会被挂起几分钟，然后才恢复。作为shared  虚拟主机，就应该这样做，否则某个站点占用资源太高，对其他站点很不公平。

然而不幸的是homezz所在的服务器昨天和前天被一个站点（不是我们的用户）拖得很慢，幸亏机房人员及时发现，将该站点suspended了，homezz才再度恢复。据cosbeta所知，国外会自动suspended帐户的好像只有bluehost和其他的站点，其他的虚拟主机供应商都是通过手动的方式搞定的。

我所知道的bluehost 的技术实力是很不错的，他们有一批人员对cpanel非常熟悉，也为cpanel定制了很多的插件。而这个自动suspend cosbeta也高度怀疑是基于cpanel开发的。

因为就cosbeta目前对cpanel的了解来看，做这样一个自动suspend超标站点的程序并不是很难，作为一个业余爱好者也能轻而易举的搞定（其实昨天晚上睡觉的时候想了很久，发现用cpanel的接口很容易搞定的），真搞不懂其他的虚拟主机供应商为啥只能手动监控超标的站点？难道是我们太高估了国外的技术，或者我应该再次去租用独立服务器？

搞定BT的支付宝直接接口

悄悄的说，homezz的虚拟主机现在完全可以通过支付宝或者paypal自动开通了。目前没有申请支付宝商家工具，用的是支付宝的一个小小的逻辑漏洞（注意：非技术漏洞）搞定的，当然，我肯定不会公布这个漏洞，否则我就用不成免费的支付宝自助开通啦。因为今天要去东莞收款，所以只有尽快自动开通的搞定。于是昨天晚上从21：00折腾到0：20。

透过昨晚的事情，已经可以看到，疯狗开始乱咬人了。

我们只有两个选择：

1. 随身不要带肉，避免被疯狗咬到；
2. 拿起打狗棒，痛打疯狗

然而，疯狗横行，打狗的人心不齐，所以我现在能做的就只有继续的懦弱着。

于是，我们决定人肉介入homezz.com的关键字筛选程序，为了防止工作量过大，我们会一个月修改一次白名单和重点关注名单。

特别危险的blog，我们将按照homezz协议处理。

我也很愤怒，也很郁闷，有时候为了发泄，不得不放弃母语发泄几句，有的时候也只能找个安全的地方，另，欢迎follow我的twitter: cosbeta

其实按照homezz的的设计机制，根本没有所谓的第几号主机，因为我们的后台程序会自动集成多个WHM的主机，不同的服务器可以集成，不同机房的服务器可以集成在一起，甚至不同国家机房中的服务器都能集成起来统一管理。

homezz的后台机制是分散风险和分散负载，因为同是homezz的wordpress主机用户，我们的程序可以将其分配到负载最低的主机，用户之间可能IP不同，主机不同，今后若日本或者新加坡有真正靠谱的主机，可能也会分散用户到日本和新加坡的主机上。关于更详细的homezz后台预览，请参见这里：homezz虚拟主机管理软件。

今天上午我注意到了，我们的3个不同的帐户被分配在两个实体的虚拟主机上，所以我马上联系机房，要求他们将我三个帐号都分配到不同的服务器上，这样才可以更好均衡用户的负载，然而机房的人告诉我，我们的帐户所分配的服务器是最新负载最低的服务器，于是我便作罢。

当然，随着homezz用户的增加，我们后面的主机数量也会不断的扩张，我们绝不oversale，绝不以牺牲用户的质量来获取最大的利益，因为我们有强大的管理后台，我们不需要牺牲用户的利益来达到最大利润的目的，这点熟悉cosbeta的朋友就知道，我绝不会那样做。

homezz wordpress主机的用户，我们已经绝对尽量不发送邮件给您，所以请你订阅homezz的官方日志，地址在这里：

用户都去homezz吧，storyday将继续回到到他的blog位置。

快餐阅读的年代，继续用简约的几句话来描述。

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.

此日志结束，不懂的在评论中留言，高手也请出山指点！

只要域名在国外注册，修改DNS和修改A记录一样简单，所以国外很多虚拟主机商为了减少用户恶意或者错误绑定域名的机会，往往会要求用户将域名DNS修改成指定的DNS才能正常绑定。

恶意绑定或者错误绑定：比如我不小心将不属于我的homezz.com绑定在了我使用的虚拟主机上，这样将会导致homezz.com域名的真正拥有者无法将其绑定同一台服务器上，因为一台主机上不能有两个一模一样的域名绑定。

同一个域名无法多次绑定在同一台主机上的原因本blog以前也做过介绍，这里再次举一个简单的例子说明：虚拟主机就如同一个柜子，柜子里面的抽屉就如同虚拟主机的网站，当用户访问某个域名的时候，首先是域名解析到IP，用户连接到服务器，然后服务器通过来访的域名将指定的网站发送给用户。如果两个一模一样的域名都绑定在同一个主机上了，当用户请求的时候，服务器将不知道怎么办了。 (read on …)

考察了一个多月，决定放弃采用日本主机，主要原因如下：

1. ping值变化快，虽然多数时候延迟在90秒附近，但是有的时候ping会掉包；
2. 日本主机价格都异常昂贵，若是主机商的用户过少，对其经营的后续能力表示怀疑；
3. 美国的虚拟主机虽然速度不是飞速，但是也还很不错，重要的一点是速度稳定

至少，在没有遇到特别好的日本主机之前，cosbeta还是决定不选择日本主机了。

找到了一个知名的日本虚拟主机，买了一个share hosting，自己粗心大意，买了之后才发现没有数据库，甚至没有CP登录，oh my god，虽然钱不多（5540日元 = 398.651702 人民币），但是摆在那里浪费掉总不是个事吧！

站内搜索，居然没有发现30-Day Money Back Guarantee ,郁闷了，发送一个帮助，希望能退款，都怪我自己！

都什么年代了，shared hosting居然不提供数据库？