由于前些天 blog.ustc.edu.cn 服务器多次发生 OOM Kill 等异常情况，我们使用 monit 对系统行为和各进程进行了监控和报警。这是 LUG 网络服务首次部署较为细粒度的监控和报警。
monit 配置文件参考：http://gitlab.lug.ustc.edu.cn/boj/blog-monit-config/tree/master
希望 mirrors 等其他服务的维护者也部署 monit 之类的报警机制。
科大开源软件镜像发生磁盘故障
2013年8月31日 11:06，科大开源软件镜像（mirrors.ustc.edu.cn）发生磁盘故障。磁盘 sda 从系统中突然消失。sda 上有 mirrors 主系统（mirrors-main）的根分区、各 LXC 虚拟机系统的根分区，sda 的消失导致 mirrors 的所有服务立即中断。
问题发生一小时后的 12:08，Stephen Zhang 在邮件列表发帖说 mirrors 挂了。收到邮件后，我们检查了服务监控系统，发现学校短信平台也很不巧地挂掉了，因此没有在第一时间收到报警短信。我们登录到 mirrors-base（mirrors-main 是 Xen 虚拟机，mirrors-base 是 Xen Domain0），发现 dmesg 中有同样的磁盘错误信息，/dev/sda 不见了。据此判断是磁盘故障。
由于此问题无法快速解决，我们采用以往的方法（所谓“启动应急预案”），将 mirrors 的 DNS 设置别名为 backup.mirrors.ustc.edu.cn，它解析到 lug.ustc.edu.cn 服务器，显示一个临时错误页，并把大部分源 HTTP 重定向到国内其他开源软件镜像。
随后，我们把 /etc 备份到其他机器上，挽救了一些尚在缓存内的配置文件。我们重新扫描了 SCSI 总线，未发现新设备。确认主管机房的张运动老师在校后，在学校的 bible 去了网络中心机房。张运动老师还说学校几百台服务器依赖 CentOS 来装软件包，让我们一定把 CentOS 源维护好。据去年统计，校内流量仅占 mirrors 总流量的1%，因此每次 mirrors 挂机，都可能影响数以万计的服务器和 PC，对此我们深感愧疚。
重新拔插硬盘、物理重启 mirrors 数次，包括使用不带 Xen 的内核，仍未在系统里发现丢失的那块磁盘。在 RAID 控制界面，发现有两块磁盘报 PD Missing 错误。我们尚未找到相关技术资料。
目前 mirrors-base（Xen Domain0）仍然在正常运行，因其根文件系统在 sdc 上。mirrors-main 连同 LXC 虚拟机系统的根分区连同那块硬盘，已经消失了。我们怀疑并不是硬盘损坏，因为两块硬盘是硬 RAID1，同时损坏的概率微乎其微；怀疑是 RAID 卡损坏，或者主板上接线松了。
本次故障由于涉及硬件问题，恢复时间未知。我们对此带来的不便深表歉意。
gitlab升级到6.0
原来gitlab是5.2版本，公共项目页面显示的第二页以后的项目链接是错误的。这个bug在新的版本中修正了。
freeshell SSH/HTTP 访问恢复
从8月18日晚上开始，由于弄错了 ip rule，导致只有加入了 LUG VPN network 的机器可以访问 freeshell 各节点。而测试的时候用的都是 VPN network 中的服务器，因此外面一直是不能访问 freeshell 的。非常抱歉。
USTC Blog 服务8月22日晚间中断
8月22日晚间，USTC Blog 服务出现乱码、显示0个用户等问题。
此问题由 Hao Wang 在邮件列表里报告（http://archive.lug.ustc.edu.cn/2013-August/012242.html）。
bible 在第一时间修复了这个问题（http://archive.lug.ustc.edu.cn/2013-August/012244.html）
boj 给出了此次故障的一些技术信息（http://archive.lug.ustc.edu.cn/2013-August/012248.html）
当时 blog 服务器上没有运行特别占用资源的服务，而 freeshell 上运行了批量解析域名的脚本，resolver 是 blog，故有可能是由于 blog 上自建的 BIND9 recursor（进程名：named）占用了过多内存。之前已经设置了 BIND9 recursor 缓存限制为 512M，因此不知道是什么原因。总之，这种不熟悉的服务最好不要在生产服务器上搭建。
这次还揭露一个问题，服务器报警不够全面。早先的报警是”黑盒测试”，在 HTTP response 不包含给定字符串时触发，这次首页和我的个人博客没有明显故障，是发现不了的。因为硬盘满而出故障那次之后，还加入了磁盘报警，这是第一个”白盒测试”，不过这次没派上用场。应该再加一种白盒测试，tail -f syslog，一旦出现某些感兴趣的关键词就报警。
freeshell 1号节点网络恢复
由于 ip rule 配置错误，1号节点前几天网络不正常，现在已经恢复。非常抱歉。
少院机房维护
freeshell所在机房（即少院机房）需要新安装空调。
但由于空间不够，所以需要挪动现有服务器位置，以及安装空调管道时会涉及到机房网线的挪动，
因此，不排除施工时由于人为因素使得机房内服务器暂时掉线。
施工时间：2013年8月21日早上9：00起。
涉及到的服务器有 http://ourscgy.ustc.edu.cn/tech/index.php?title=%E6%9C%8D%E5%8A%A1%E5%99%A8
由此带来的不便，敬请谅解。
2013/8/20
少院技术部
s{1..7}.freeshell.ustc.edu.cn 域名启用
Freeshell 各计算节点启用新域名：s1.freeshell.ustc.edu.cn 代表1号节点，s2.freeshell.ustc.edu.cn 代表2号节点，以此类推。这下大家就不用记忆IP地址了！每个节点都有 IPv4 和 IPv6 地址，IPv4 限校内 IP 访问。IPv6 访问区域不限，但可能不稳定。
Freeshell 支持访问外网，修复 IPv6
首先给大家道个歉，前几天由于配置错误需要重启 freeshell 主机，所有虚拟机都重启了，有的同学正在跑的计算任务可能丢了，很抱歉。今天有了 servers.blog.ustc.edu.cn 这个平台，这种事情会在这里发布出来，欢迎 RSS 订阅。
================ 言归正传 ================
很多同学希望在 freeshell 里访问外部网络，今天我们部署了从 freeshell 访问外网的 Proxy，这下大家可以从校外的源安装非官方软件了，也可以从 github 或其他开源站点上直接下载源码了。如果你发现还是不能上外网，或者有的网站上不去，请联系我们：lug AT ustc.edu.cn。
如果你也想用 LUG 的服务器做出口加速，请猛戳这里：http://vpn.lug.ustc.edu.cn/ （LUG 会员才能申请哦）
下图是目前的网络拓扑示意图（点击看大图）
此外，由于前几天 Freeshell 重启了，IPv6 地址都不能访问了。现在 IPv6 已经恢复，如果有的同学发现还是不能用 IPv6，请重启试试，OpenVZ 对 IPv6 的支持并不是很好，我在百思不得其解之后，重启了一下自己的 freeshell，ping6 bbs6.ustc.edu.cn 就通了。如果遇到问题，请联系 lug AT ustc.edu.cn。
Update (08/19 15:30)：有几个节点的 eth1 网卡没有 up 起来，因此这几个节点上的 IPv6 当时不可用。现在已经恢复。昨天由于是脚本批量执行，以为一个节点OK了其他的也没什么问题。每次想懒省事的时候，都会出问题啊……
嗯，Freeshell 是什么？你火星了：http://freeshell.ustc.edu.cn/
世界，你好！
LUG 最近又推出了什么网络服务？服务器挂了吗？订阅本博客 servers.blog.ustc.edu.cn 吧！
LUG 服务器实时状态（每10秒更新一次，mirrors 尚未配置）：http://status.lug.ustc.edu.cn/
LUG 网络服务实时状态（每分钟更新一次）：http://servmon.lug.ustc.edu.cn/hostlist.php