比尔盖子 博客

Category: 建站那点事 (page 1 of 6)

服务器维护初步结束

2013 年,爱德华·斯诺登披露了棱镜计划,于是人们,包括盖子自己终于学会了如何正确配置 TLS;2014 年,各研究者纷纷加入到 Linux 安全的研究行列中,随着一篇“炮打shell司令部root,我的一个 exploit”的 Bug 报告,以前那种“随便配置个 Linux 服务器让它跑”的欢乐时光已经彻底结束,真是让各运维苦不堪言,都快患上 Shell Shock 了,人们不得不以正确的态度开始对待安全;2015 年,越来越多的安全审计也被提上日常。

在这样的背景环境下,学习并应用的安全技术是多多益善的。因此,我在今年初部署了一台实验性的服务器,用于测试 PaX 技术。如今,虽然 grsecurity 以盖子的能力完全掌握还需要时间,但 PaX 已经完成测试可以部署了,而盖子的服务器运行了两年时间,也暴露出来一些问题。

因此盖子进行了一次大型服务器维护。而凑巧,在服务器进行维护之前的 8 月 15 日,忽然被 GFW 屏蔽了!一天之后,服务器也进入了关机维护状态,以至于不少人出现了“这服务器怎么挂了代理也不能翻墙访问”的错觉。

长话短说,这此维护的摘要如下(随着维护的进行,可能会更新):

Continue reading

Apache 之 mod_status 配置问题解决(403, 404错误)

为了使用监控宝来监控比尔盖子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规则?保密,稍后公布。

apt-get 导致硬盘爆满的解决之道

折腾完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/*

切换VPS到Ubuntu

最近比尔盖子将服务器重新安装了操作系统。最开始使用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也常常出动……算了,最后优化吧。

比尔盖子虚拟主机1.0(代号Mango)发布!

经过数个月的学习,比尔盖子终于掌握了一些和虚拟主机有关的经验,重新设计了整个虚拟主机架构,也算要发布一下

特点

性能

高性能服务器Ngnix

比尔盖子虚拟主机使用Nginx作为Web服务器,在高并发的情况下拥有极高的稳定性。

高性能数据库MariaDB

使用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

比尔盖子虚拟主机1.0(代号Mango) 开发的那些事

最近临近期末考试,也是最近博客停止更新的原因之一。但是,比尔盖子对其表示鸭梨不大,压力更大的则是重新配置比尔盖子虚拟主机。

从比尔盖子开始使用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导致CSS无法解析

比尔盖子最近在对服务器进行重构,在重构过程中,比尔盖子用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守护进行就好了。

 

解决一个小Bug——Sendmail无法发送邮件

今天输入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终于把邮件发出去了!

比尔盖子虚拟主机的可用率未能达到99.9%

随着即将结束的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开通了亚太地区的第一个云计算数据中心——日本东京云数据中心。
比尔盖子在这周已经更换到了这个机房,速度果然有很大提升!

Olderposts

Copyright © 2021 比尔盖子 博客

Theme by Anders NorenUp ↑