2013 年，爱德华·斯诺登披露了棱镜计划，于是人们，包括盖子自己终于学会了如何正确配置 TLS；2014 年，各研究者纷纷加入到 Linux 安全的研究行列中，随着一篇“炮打司令部，我的一个 exploit”的 Bug 报告，以前那种“随便配置个 Linux 服务器让它跑”的欢乐时光已经彻底结束，真是让各运维苦不堪言，都快患上 Shell Shock 了，人们不得不以正确的态度开始对待安全；2015 年，越来越多的安全审计也被提上日常。
在这样的背景环境下，学习并应用的安全技术是多多益善的。因此，我在今年初部署了一台实验性的服务器，用于测试 PaX 技术。如今，虽然 grsecurity 以盖子的能力完全掌握还需要时间，但 PaX 已经完成测试可以部署了，而盖子的服务器运行了两年时间，也暴露出来一些问题。
因此盖子进行了一次大型服务器维护。而凑巧，在服务器进行维护之前的 8 月 15 日，忽然被 GFW 屏蔽了！一天之后，服务器也进入了关机维护状态，以至于不少人出现了“这服务器怎么挂了代理也不能翻墙访问”的错觉。
长话短说，这此维护的摘要如下（随着维护的进行，可能会更新）：
为了使用监控宝来监控比尔盖子Apache的运行状态，比尔盖子打算启用mod_status模块来访问biergaizi.com/server-status页面。
结果，屡次失败。后来干脆把安全严重去掉，直接将以下配置添加到/etc/apache2/httpd.conf中，也根本不管用，永远提示403错误：
ExtendedStatus On
<Location /server-status>
SetHandler server-status
Order deny,allow
Allow from all
</Location>
难道是这个模块有专门的配置文件被引用，从而覆盖了盖子的设置？经过长期奋战，终于最后通过文本流搜索，找到了/etc/apache2/mods-enabled/status.conf文件：
SetHandler server-status
Order deny,allow
Deny from all
Allow from 127.0.0.1 ::1
原来只允许127.0.0.1，难怪无法访问。但是去掉这个安全规则之后，确实再也不提示403了，反而变成盖子博客的404页面了。难道是和虚拟主机的配置冲突？经过搜索，发现确实如此。解决之一是将Virtualhost中所有的*:80都变成具体的IP地址，但是这个规则是控制面板管理的，还是不动为好；或者为/server-status专门指定一个监听端口，直接在前面加上Listen 8050之类的端口就行了。
最后的规则如下：
#专门监听2500端口
Listen 2500
ExtendedStatus On
SetHandler server-status
Order deny,allow
Deny from all
#只允许监控宝
Allow from 60.195.252.106
当然，不要尝试访问http://biergaizi.com:2500/server-status/页面，你连403页面也看不见的——有iptables！想看看iptables规则？保密，稍后公布。
折腾完Ubuntu之后，硬盘空间迅速爆满。比尔盖子不得不几次停下VPS，进行扩容操作。导致是什么鬼东西耗尽了我的硬盘。一气之下，使用
du -sh /*
进行检查。结果如下：
12K /aquota.group
8.0K /aquota.user
7.9M /bin
34M /boot
4.0K /dev
13M /etc
985M /home
0 /initrd.img
188M /lib
16K /lost+found
32K /Maildir
8.0K /media
12K /mnt
4.0K /opt
0 /proc
160K /root
216K /run
6.2M /sbin
4.0K /selinux
12K /srv
0 /sys
8.0K /tmp
1019M /usr
1.3G /var
0 /vmlinuz
怎么？/var占了这么多空间，难道是日志太多吗？继续输入
du -sh /var/*
进行检查：
736K /var/backups
488M /var/cache
16K /var/crash
697M /var/lib
4.0K /var/local
0 /var/lock
41M /var/log
4.0K /var/mail
4.0K /var/opt
0 /var/run
772K /var/spool
4.0K /var/tmp
16K /var/usermin
4.0K /var/virtualmin-autoreply
22M /var/webmin
12K /var/www
这么多缓存文件？都是些什么东西？再看：
du -sh /var/cache/*
8.0K /var/cache/apache2
401M /var/cache/apt
15M /var/cache/apt-show-versions
67M /var/cache/apt-xapian-index
4.0K /var/cache/awstats
12K /var/cache/bind
4.4M /var/cache/debconf
20K /var/cache/ldconfig
1.6M /var/cache/man
8.0K /var/cache/postgresql
4.0K /var/cache/pppconfig
进入/var/cache/apt一看，原来是里面有个叫archives的目录，存在大量apt-get下载过的软件包，难怪硬盘空间迅速变小。速速删除之，根目录果然多了大量空间！
rm -r /var/cache/apt/archives/*
。
最近比尔盖子将服务器重新安装了操作系统。最开始使用Linode的时候，使用的操作系统是CentOS 6，但后来发现CentOS为了稳定性，实在也太保守了，很多软件甚至落后上游3、4个版本，比如Python，都2.6了，CentOS里面居然还是2.4！——一句话，除了安全更新，什么都不管！
为了追求性能，改用了Gentoo，同时也开始提供虚拟主机服务。但是几乎没有任何一种虚拟主机管理面板支持Gentoo！后来强行安装了Virtualmin/Webmin，勉强运行起来了。我自己还用Nginx替换了Apache；MariaDB替换了MySQL。也算是一个大实验吧。
这勉强运行起来的系统环境给比尔盖子造成了无穷的痛苦啊，比如，自动修改配置文件的功能根本无法工作，只能人工修改，简直就是一个半自动的系统环境——甚至不如手动编写配置文件。前天，终于下定决心，更换一个Virtualmin可以运行，但自己也能接受的Linux发行版。Debian，占用资源小，但也保守；正巧想到了Ubuntu。这个系统比尔盖子不是很喜欢，因为它把很多传统上需要Linux用户自己做的事情，都给自动化了——显示不出盖子的水平啊（其实是反而给盖子添乱）！而且这个系统据说用来做服务器也不是很稳定。
但是，看到很多搞云计算的都开始用，而且这个系统的最新版本12.04 LTS，可以支持VIrtualmin，便还是决定安装了。运行Virtualmin的安装脚本之后，什么都不用管，很快就装完了。而且这个管理面板安装这些软件的方式，居然不是编译安装，是调用apt-get安装，非常不错，
安装好管理面板后，恢复所有服务，折腾半天。恢复完之后，打算在Linode上运行Ubuntu官方内核，又折腾半天，成功运行了linux 3.2，但盖子想用3.4，于是增加软件源，直接从12.04 LTS切换到Development Branch，虽然不太靠谱了，但是对于盖子来说还是可以接受的，而且用上了linux 3.4的内核。
不过最要命的是，Virtualmin默认安装并配置启用了Mail Server、Bind、PostgreSQL等等根本用不到的东西，服务器的可用内存动不动就只剩下100M，Swap也常常出动……算了，最后优化吧。
经过数个月的学习，比尔盖子终于掌握了一些和虚拟主机有关的经验，重新设计了整个虚拟主机架构，也算要发布一下
比尔盖子虚拟主机使用Nginx作为Web服务器，在高并发的情况下拥有极高的稳定性。
使用MariaDB作为服务器，MariaDB使用改进过的两种引擎，有着强大的事务能力，这两种引擎比MyISAM和InnoDB性能都要高很多。
你没听错，MariaDB的储存引擎分别与MyISAM和InnoDB完全兼容，您不用对您的代码进行任何修改！
比尔盖子为您提供1GB的储存空间和512MB的数据库空间，在免费虚拟主机中已经很多。而且，还将有20元Amazon S3计划，提供1GB空间/10GB流量的Amazon S3，轻松容纳您越来越多的数据。
比尔盖子的VPS拥有备份服务，每24小时将数据备份到云机房的RAID磁盘阵列上，您无须担心误操作引起的损失。
比尔盖子虚拟主机将提root命令申请，将您需要执行的root命令提交，通过审核后将被执行！如果您需要其它开发环境和服务器，均可和比尔盖子协商，这是非个人服务所做不到的。
比尔盖子虚拟主机的缺点也很明显，但是其优点是非常多的，比尔盖子非常希望能够帮助想学习技术的朋友！
此外，代号为何是Mango，那是因为Ma(riaDB)ng(inx)(Gento)o
最近临近期末考试，也是最近博客停止更新的原因之一。但是，比尔盖子对其表示鸭梨不大，压力更大的则是重新配置比尔盖子虚拟主机。
从比尔盖子开始使用VPS之后，就提供了虚拟主机。这虚拟主机从配置上来看，确实够强劲。但是学习成本也够大了。因为比尔盖子最初打算面向Linux命令行用户，因此没有设计控制面板。后来配置Apache自己都快疯了。因此发现，控制面板是多么的重要。再后来，服务器也被搞得一团烂。
因此，比尔盖子终于决定在2011年的最后一个月开始重构。好不容易架构好了Gentoo，结果发现没有可用的管理面板，最后发现了Virtualmin，大名鼎鼎的Webmin管理面板的一个插件，用了它就可以无压力的实现虚拟主机。
结果又发现，不支持Gentoo！最后经过各种Hack，终于让一个Apache+MySQL+PHP的服务器运行起来了。但是，比尔盖子认为这也太耗资源了，于是，首先用Nginx干掉Apache，然后找了一个牛人的Nginx管理插件，结果发现有些小Bug。水平不够不会改，就当半自动管理吧。今天又突发奇想，用MariaDB代替MySQL，幸好是完全兼容的，1小时不到搞定。这期间还洗了我家猫。
现在的情况是：服务器运行阶段有130M的已用内存，可用内存大约剩下380M，足以对付大家的应用了。硬盘空间还没调整，但是可以估计出来：都配完了还有16GB，如果大家每人500M，也能承受30个伙计了。另外，比尔盖子打算提供一个计划：如果你的月数据流量不超过10GB，储存的内容不超过1GB，那么通过某种方式每月给比尔盖子人民币20元，比尔盖子可帮你申请Amazon S3的云储存！也当是平衡一下比尔盖子的收支，给我继续研究的动力吧。上传文件的方式等等不用担心，Wordpress 都是有插件的，你也可以开发一个小程序，API很容易懂的。
我的虚拟主机的用户目前只有John Webber同学；Sandeli同学貌似只是测试了一下，没有放什么数据。比尔盖子虚拟主机最大的特点就是灵活性：想做Java开发，没问题，比尔盖子给你安装就Java环境，就像John Webber同学；想安装什么软件，一般的都没问题。但是，sudo权限经过再三考虑还是给不得，但是有个替代的计划，就是把你想用root权限执行的命令通过某种的方式提交，比尔盖子审核后就会执行。
暂时就说这么多了，等会比尔盖子再写一份虚拟主机的宣传广告。
比尔盖子最近在对服务器进行重构，在重构过程中，比尔盖子用Nginx取代了Apache，结果发现博客页面不正常了，像是主题文件损坏的样子。而换成Wordpress默认的主题Twenty Ten就没事了。
比尔盖子重新安装了主题，但依然不起作用，只好打看Firefox万能的错误控制台进行调试，结果发现了以下错误信息：
错误： 样式表单 http://biergaizi.info/wp-content/themes/philna2/style.css?v=201001171531 未载入，因为它的MIME类型 “text/plain” 不是 “text/css”。
源文件：http://biergaizi.info/
行：0
网上对这种错误众说纷纭，有的是IE的兼容性问题；还有是XHTML的问题。
最后发现，原来是配置Nginx的时候将/etc/nginx/nginx.conf的一行include /etc/nginx/mime.types;误删了，导致了Nginx无法正确识别CSS文件，因此向浏览器发送了错误的MIME类型。加上那行，然后重启Nginx守护进行就好了。
今天输入mail，发现root收到16000多封邮件，都是Cron发给我的。
我一看：
451 gmail.com: Name server timeout
天啊，这年头DNS也抽风？后来经过查阅资料，再加上一些回忆，终于想到了原因：
原来比尔盖子的VPS机房是支持IPv6的，可自从搬到日本去IPv6就没有了。但是Sendmail依赖IPv6，因此没有了它DNS也就查询不成功了。
解决这个问题的方法倒是挺简单：
cd /etc/mail
yum install sendmail-cf
#刚学会超级转义符号：单引号，用单引号引用的内容永远不会具有特殊含义，比双引号厉害。
#正好就用到了！
#下面这句话的意思是：在sendmail.mc的最后一行加上"dnl define(`confBIND_OPTS’, `WorkAroundBrokenAAAA’)dnl" 来屏蔽IPv6！
echo 'dnl define(`confBIND_OPTS’, `WorkAroundBrokenAAAA’)dnl' >> sendmail.mc
m4 sendmail.mc >sendmail.cf
make
service sendmail restart
然后，Sendmail终于把邮件发出去了！
随着即将结束的2011年，比尔盖子也对服务器进行了一些检查。但是比尔盖子网站的可用率未能达到100%，在此表示道歉。
故障分许：在2011年第三季度时出现了15小时的当机时间，这是由于网站搬迁机房造成的；而在2011年第四季度，由于比尔盖子所使用的Linux内核版本存在Bug，因此导致了多次的系统崩溃，总计崩溃时间达到了10小时。
| 年 | 季度 | 月 |
|
2011年
99.52%
1天14小时46分钟
|
第4季度
98.95%
10小时26分钟
|
11月
100%
|
|
10月
98.60%
10小时26分钟
|
||
|
第3季度
99.35%
15小时9分钟
|
09月
98.48%
10小时57分钟
|
|
|
08月
99.93%
33分钟
|
||
|
07月
99.51%
3小时39分钟
|
||
|
第2季度
99.51%
4小时50分钟
|
06月
99.90%
44分钟
|
|
|
05月
99.77%
1小时43分钟
|
||
|
04月
99.67%
2小时22分钟
|
||
|
第1季度
99.54%
8小时19分钟
|
03月
99.73%
2小时2分钟
|
|
|
02月
99.34%
4小时26分钟
|
||
|
01月
99.75%
1小时50分钟
|
||
|
2010年
99.32%
24小时8分钟
|
第4季度
99.12%
14小时34分钟
|
12月
99.75%
1小时50分钟
|
|
11月
99.60%
2小时54分钟
|
||
|
10月
98.68%
9小时48分钟
|
||
|
第3季度
99.42%
9小时34分钟
|
09月
98.75%
8小时58分钟
|
|
|
08月
99.81%
36分钟
|
| 监控项目 | 开始时间 | 恢复时间 | 故障持续时间 | 故障原因 | 故障分类 | ||
| 2011-10-20 | |||||||
 |
比尔盖子技术交流站 | 15:30:50 | 15:34:07 | 3分钟 | 无法连接服务器 | 网络故障 | |
| 2011-10-12 | |||||||
| |
比尔盖子技术交流站 | 01:59:57 | 02:00:59 | 1分钟 | 数据包全部丢弃 | 网络故障 | |
| |
比尔盖子技术交流站 | 01:21:41 | 01:22:41 | 1分钟 | 无法连接服务器 | 网络故障 | |
| 2011-10-08 | |||||||
| |
比尔盖子技术交流站 | 19:26:02 | 19:27:02 | 1分钟 | 数据包全部丢弃 | 网络故障 | |
| 2011-10-07 | |||||||
 |
比尔盖子技术交流站 | 15:30:33 | 16:02:34 | 32分钟 | 请求超时 | 软件故障 | |
| 2011-10-05 | |||||||
| |
比尔盖子技术交流站 | 01:11:35 | 08:13:48 | 7小时2分钟 | 请求超时 | 软件故障 | |
| 2011-10-04 | |||||||
| |
比尔盖子技术交流站 | 15:39:22 | 18:26:25 | 2小时47分钟 | 请求超时 | 软件故障 | |
| 2011-10-02 | |||||||
| |
比尔盖子技术交流站 | 09:36:47 | 09:37:48 | 1分钟 | 服务器无返回数据 | 网络故障 | |
| 2011-09-30 | |||||||
| |
比尔盖子技术交流站 | 09:48:41 | 18:20:58 | 8小时32分钟 | 无法连接服务器 | 软件故障 | |
| |
比尔盖子技术交流站 | 09:48:32 | 18:20:53 | 8小时32分钟 | 数据包全部丢弃 | 软件故障 | |
| 2011-09-10 | |||||||
| |
比尔盖子技术交流站 | 15:26:00 | 17:46:26 | 2小时20分钟 | 无法连接服务器 | 软件故障 | |
| |
比尔盖子技术交流站 | 15:21:45 | 17:27:16 | 2小时5分钟 | 数据包全部丢弃 | 软件故障 | |
| |
比尔盖子技术交流站 | 14:51:43 | 14:56:00 | 4分钟 | 无法连接服务器 | 网络故障 | |
| 2011-08-27 | |||||||
| |
比尔盖子技术交流站 | 07:03:50 | 07:35:56 | 32分钟 | 无法连接服务器 | 网络故障 | |
| 2011-08-21 | |||||||
| |
比尔盖子技术交流站 | 01:58:40 | 01:59:41 | 1分钟 | 无法连接服务器 | 网络故障 | |
| 2011-07-29 | |||||||
| |
比尔盖子技术交流站 | 16:11:48 | 16:28:50 | 17分钟 | 请求超时 | 网络故障 | |
这周，Linode开通了亚太地区的第一个云计算数据中心——日本东京云数据中心。
比尔盖子在这周已经更换到了这个机房，速度果然有很大提升！
Copyright © 2023 比尔盖子 博客
Theme by Anders Noren — Up ↑