之前为了安全起见,关掉了 blog 的 PHP display_errors 选项,即使出现语法错误也不会提示。现在为方便调试程序,打开了 display_errors,也就是如果由于语法错误导致 500 错误,显示的将不是空白页面而是有关语法错误的提示信息。
月度归档: 2013年11月
Freeshell IPv4/IPv6-only 域名启用
1~7号节点的 IPv4-only 域名是 s1.4.freeshell.ustc.edu.cn 至 s7.4.freeshell.ustc.edu.cn。
IPv6-only 域名是 s1.6.freeshell.ustc.edu.cn 至 s7.6.freeshell.ustc.edu.cn。
如果您的网络环境是 IPv4/IPv6 双栈接入,但其中一个有访问限制,可以使用上述域名指定使用 IPv4 或 IPv6 访问 freeshell。请注意,端口映射只对 IPv4 生效,访问 IPv6 的对应端口会被拒绝。
Blog 保护数据库连接类不被篡改
今天 lttt.blog.ustc.edu.cn 装了一个插件,在 wp-content 下添加了一个 db.php,导致数据库无法连接。现在修改了 WordPress 核心源码,不再载入用户自定义的 db.php。这是由于 USTC Blog 会在启动时自动连接数据库,任何试图自行连接数据库的尝试都会失败。因此没有必要写自己的数据库连接类。
感谢 Abel Van 的 case 使我们少了一个 bug。
Mageia 和 LDP 恢复同步
LDP已经同步完成,Mageia由于停止同步时间过长,还在同步中。
另外其它停止同步的源我们正在恢复。
Blog 服务器宕机半小时故障过程
11月25日 23:40 至26日 00:10,blog 服务器宕机半小时。受影响的服务包括 blog,freeshell 控制端和 http proxy,public DNS,VPN server,邮件服务器,邮件列表 archive。
问题发生在 11:40 左右,blog 服务突然中断。此时除了与 blog 同一局域网的机器都无法 ping 通 blog。从同一子网的 mirrors 上 ssh 进去,发现 ip route 和 ip rule 都挺正常的,但 ping 自己的 IP 都不通。执行了 ip rule flush,重新添加了 local, main, default 三个 ip rule,重新执行了设置 ip route/rule 的启动脚本,问题如故。当时,高一凡在邮件列表里反映有路由环路,发往 202.141.160.99 的包弹回了上级路由 218.22.21.30。
于是决定重启,23:48 发出 sudo reboot 命令,几秒后连接还没断,就 sudo init 6,大约10秒后 ssh 连接才中断。事后发现,23:49 syslog 里记下了最后一条日志。直到 00:02,新的 syslog 才出来,这时候应该是 kernel 启动 322 秒的事了。可见从发出重启命令到真正关电源需要的时间超过了 5 分钟,kernel 初始化也超过了 5 分钟。dmesg 里从 5.60s 到 290.48s 完全是空的,也没有看到 fsck 之类的字眼。
更坑爹的问题是 nginx 没有启动起来,导致 blog 和 freeshell 的恢复又拖了10分钟。nginx 没起来的原因是形如 s1.freeshell.ustc.edu.cn 这样的域名解析失败。而域名解析失败的原因是本地 bind9 nameserver 没有启动。bind9 启动失败的原因是 named.conf.local 配置文件里少加了一个分号。由于最近几次对 bind9 配置文件做的修改都忘了 git commit,不知道是什么时候配置文件开始出现语法错误了。这就奇怪了,如果配置文件改错了,service bind9 reload 会失败,肯定一眼就发现了。
同样是由于 bind9 没有启动,OpenVPN 无法解析域名,因此几个 tunnel 没能启动,不过这不是大问题。
这次故障中奇怪的地方:
- 为什么会出现路由环路?之前出现过一次,定性为内核 bug,之后就没管了。
- 为什么从 kernel init 到服务进程(rsyslogd)启动需要近 300 秒的时间,中间内核都在做什么?
- bind9 配置文件少了一个分号,为什么改的时候没发现?
应当吸取的教训:
- Nginx resolver 不要使用默认的本地 nameserver,以防 nameserver 挂掉连累 nginx。目前已改成4个学校官方 nameserver。
- 配置文件修改后应及时 git commit,便于追踪历史。已经将之前 bind9 的几处修改 commit & push。
Blog 服务器上服务太多,路由配置过于复杂,一旦发生故障,受影响的服务太多。计划做的修改:
- 向 jameszhang 再申请两台虚拟机(称为A、B)和移动、电信线路 IP 地址,将 OpenVPN server 转移到A,策略路由和国外 tunnel 转移到B,DNS nameserver 转移到B。这样就能避免规则间错综复杂的相互作用,也顺便解决了 tee 不经过 POSTROUTING nat 的遗留问题。
- 把 HTTP 服务监控脚本转移到 lug 服务器上,在 freeshell 上反过来监控 lug。
- 邮件列表 archive 转移到 freeshell 上,blog 上做反向代理。
- 由于少院机房网络偶尔抽风的问题尚未解决,blog,freeshell 控制端,freeshell http proxy,邮件服务器仍然在 blog 上不变,暂不移到 freeshell 上。
lug.ustc.edu.cn更新opensuse-guide
lug.ustc.edu.cn上的openSUSE Guide更新到13.1版本。
地址在此: 传送门
mirrors恢复status页面
奇怪的status.txt不在了,而大家期盼已久的status页面终于能看了!
status页面暴露出mirrors上的许多问题,我们会尽快修复。
Freeshell 修复5号节点无法建立虚拟机
由于配置文件路径写错了(/etc/vz/vz.conf 写成了 /etc/vz.conf),freeshell 5 号节点不知从何时起,由于找不到 OS template(系统镜像)文件,无法建立虚拟机。表现为新注册的 freeshell 一直是 Not exist,重装系统后也是 Not exist。非常抱歉这个 bug 给您带来的不便。
如果您的 freeshell 也遇到 Not Exist 的问题,请登录 freeshell.ustc.edu.cn,点击 “Reinstall Freeshell”,按提示重装系统。
感谢 杨博远 的 bug report。
mirrors 修复 linux.git 源
最近有人反映 mirrors 上的 linux.git 源无法 clone。具体表现为 git clone 到 700MB 左右时卡住,git 无输出。登录后发现 linux.git 有差不多 7GB 大小,判断为 git 存储的松散对象没有被重新打包,导致这个 git 镜像越来越大。
因此先手动对 linux.git 进行 git gc 操作,其占用空间从 7GB 下降到 700MB,服务恢复。随后在同步用的LXC虚拟机中,添加crontab规则:
0 0 * * mon (cd /srv/ftp3/git-repos/linux.git; git gc) > /dev/null 2>&1
即每周一零点零分对 linux.git 进行一次 git gc 操作。
lug.ustc.edu.cn 恢复 IPv6
由于 IPv6 路由表配置错误,lug.ustc.edu.cn 无法通过 IPv6 访问,表现为连接超时。现已修复。