月度归档： 2013年12月

mirrors修复BioConductor和Loongson源

这两个源都是因为上游源地址换掉，我们没有及时跟进导致长期同步失败的。

BioConductor此次修复后增加了2.13版本的源，现在共有2.11/2.12/2.13三个版本。

而来自anheng的龙芯补充源则是在联系了其维护者后，重新完成了同步。在此摘录部分邮件内容加以说明：


新的Debian不再支持老的软件源的方式，因此增加了bjlx 目录，用于龙芯补充源，目录说明如下:
 
loongson: 包含一些2e的补充源和一些老的龙芯的东西，install目录是离线安装包发布目录，还在更新。
 
Loongson2f: 2f的补充源，不再更新。
 
loongson3: wheezy源，已经合并到bjlx。
 
bjlx: 统一的补充源，经常更新。

因此我们选择同步loongson/loongson2f/bjlx这三个源，频率是每天一次。

Freeshell 1 & 7 节点 IPv4 恢复

We are sorry that IPv4 of Freeshell nodes 1 & 7 is broken since the maintenance yesterday. It is because we did not write network routing configurations into persistent storage, and the configs were in an inconsistent state after reboot. This problem is fixed now.

If you have any problem regarding network connectivity, please let me know.

For technical details, see https://gitlab.lug.ustc.edu.cn/boj/freeshell/commit/6020fe088b398315eb5a6e5b50ea9e4896da4e8f

Thanks wl56 for bug report.

Freeshell Node 1 & 7 is rebooted several times

We are installing SSD on freeshell Node 7, but accidentally pulled out the original hard disk, which leads to an immediate kernel panic of the hardware node. So we have to reboot the node.

All freeshells on that node are therefore rebooted. It may reboot several more times in the next few hours. We are sorry for the inconvenience it may have brought to you.

Notification emails have been sent to freeshell users on Node 7.

Update: When the disk is connected to SATA port of freeshell Node 1, it kernel paniced immediately. So Node 1 is also impacted.

Blog 修复偶尔发生的 500 错误

Blog 服务器作为 Freeshell 的反向代理，近几天访问量较大，偶尔发生 500 Internal Server Error。在 nginx error.log 中一查，发现是 24: Too Many Open Files。这是由于 nginx worker 默认的打开文件数限制为 1024，超过了就会打不开文件而报错。

只需在 nginx.conf 中加入一行（在任何花括号外面）

worker_rlimit_nofile 32768;

service nginx reload 即可解决问题。

Freeshell 解决有时不能建立 TCP 连接

从12月22日凌晨开始，freeshell 有时不能建立 TCP 连接。原因是我在用 freeshell 爬数据，接受了外来的大量 HTTP 请求，每个请求都是一个 TCP 连接。这些 HTTP 请求是 freeshell HTTP proxy 进来的，速度稳定在 200 qps (query per second) 左右。

基于如下事实，我推测是交换机上的防火墙做了限制：

  • proxy 成功的 HTTP 请求速度稳定；
  • 没有接受大量 HTTP 请求的 freeshell 节点也有此问题；
  • ping 没有丢包；
  • freeshell syslog 中没有错误记录，/proc 相关配置也足够大。

随后在少年班学院的一台交换机上发现了防火墙配置，正是 “防止 SYN/SYN-ACK Flooding” 选项捣的鬼，它限制 SYN 包发送速率 128 kbps，按照一个包 64 字节计算，就是 256 pps (packet per second)，与 HTTP 200 qps 的数据相符。取消此项限制后，网络恢复正常。此问题大约持续一整天。

顺便关闭了一些可能带来问题的防火墙选项：

  • 丢弃源端口小于1024的SYN报文
  • 防止 Ping Flooding
  • 防止 SYN/SYN-ACK Flooding（这次问题的元凶）

目前这台交换机上开启的防火墙选项包括：

  • 防止 Land 攻击（源地址和目的地址相同，可能在 loopback 接口上引起环路，漏洞存在于 Windows XP/2003 早期版本）
  • 防止 FIN, Xmas, NULL scan（透过拦截 TCP SYN 的防火墙，扫描开放端口）
  • 防止 Ping of Death 攻击（发送非法或超长 ping 包，现代操作系统已经不存在这个漏洞，不过还是防一下）
  • 防止 Smurf 攻击（伪造源地址的 ICMP 报文，反射攻击）

解决 “TCP: time wait bucket table overflow” 问题

Freeshell 一个服务接受了大量的 HTTP 连接，主机的 syslog 中出现大量 “TCP: time wait bucket table overflow” 信息。这是因为有大量 TIME_WAIT 状态的 TCP 连接。

根据 TCP 协议，连接终止后一段时间内端口号不允许重用，以避免已关闭连接后到达的乱序数据包影响新的连接。这个值默认是 60 秒。事实上，一个乱序数据包在网络中停留不了这么长时间，而且恰好与新连接的端口号和序号重合的概率也很小。因此我们把这个值改成了 5 秒，以便及时释放已关闭连接的资源。

同时还把本地外发连接的端口范围扩大到了 1024 ~ 65535，可用端口号增加了一倍。

net.ipv4.tcp_fin_timeout=5
net.ipv4.ip_local_port_range=1024 65535

Mirrors 关闭虚拟机导致主机网络中断

今天（2013年12月21日）18:40，我（boj）在 mirrors 的 LXC 虚拟机里 init 0 了一下，本来以为跟 lxc-stop 一样的效果，但主机连不上了。原因是虚拟机没有做网络隔离，虚拟机 init 0 过程中会关闭网卡，然后主机网络就 down 了。

事故发生时虽然网络中心值班老师已经下班，但 jameszhang 老师还在东区，于是帮忙打开了机房门。zguangyu 重启了主机，但重启后屏幕显示 GRUB 四个字母（还没到 GRUB 菜单）就卡住了。截至 20:00 发稿时，zguangyu 仍然在机房修理。

Update (21:00)：20:45 mirrors 各项服务已恢复正常。宕机时间2小时5分钟。mirrors 不能自启动的原因另文说明。

由于 [email protected] 在 DNSPod 的账号被锁定了，无法修改 DNS，从而无法迅速切换到备份站点。非常抱歉此次事故给大家带来的麻烦。

事故教训：

  1. 虚拟机要做网络隔离，避免虚拟机内的错误网络配置影响主机。
  2. 应该尽快把 DNS 收回学校。

Freeshell 修复域名解析问题

12月8日 Roy Zhang 升级了 DNS view，不过我忘了做 nsupdate，导致 freeshell 域名 *.6.freeshell.ustc.edu.cn 和 *.4.freeshell.ustc.edu.cn 无法解析。多谢 高一凡 报 bug，这个问题终于在 9 天后被修复。重新 nsupdate 就好了。

Update (12月22日): 今天发现电信线路 DNS view 没有更新，新加的 *.6.freeshell.ustc.edu.cn 域名从电信线路查不到 IP。现已解决。非常抱歉。

USTC Blog 升级 WordPress

WordPress 3.8 发布，现将 USTC Blog 的 WordPress 升级到 GitHub HEAD，即 3.9-alpha。

升级后首次登录后台时，会提示升级数据库，按提示操作即可，不会影响正常使用。如果发现插件或主题存在不兼容问题，请联系我们。