本次维护历时53分钟，服务共中断17分钟。
这次维护时发现服务器无法对外发起连接请求。这是由于1月21日日志把VPN服务器的磁盘占满了，移动日志的过程中重启了VPN服务，导致GitLab服务器默认路由被内核删了。以下功能受到影响：
7.7.1 主要特性：
GitLab服务器计划于2015年1月24日升级维护，计划维护时间为16:00 ~ 17:00。届时GitLab代码托管服务将短暂性中断。
维护内容：
给您带来的不便，深表歉意。
在测试环境中更新时遇到一些问题，更新推迟至22:00
RT，感谢 高三山 的反馈。
更多 PHP 限制，请参考 http://blog.ustc.edu.cn/phpinfo.php
由于 DigitalOcean 的虚拟机不稳定，LUG 国外反向代理服务器（revproxy-sg.ustclug.org）启用双 IP 做热备和负载均衡。两台服务器均支持 IPv4 和 IPv6。
同时修复了导致 IPv6 反向代理失败的路由问题。
Blog 服务器 1 月 8 日 11:41，blog 服务器网络中断。通过 VMWare console 登上去，看到下列错误提示，应该是未知内核问题（Debian wheezy 官方 3.2 内核）：
为尽快恢复服务，服务器于 11:45 重启。但重启后数据库没有成功启动，提示下列错误，这是由于 blog 的数据库数量较多，MySQL 达到了同时打开文件数量的上限。
在 /etc/security/limits.conf 中做如下修改，并重新启动服务器。
* soft nofile 1024000
* hard nofile 1024000
* soft nproc 10240
* hard nproc 10240
11:53 重启后数据库没有成功启动。手动启动 MySQL，在十秒左右的 crash recovery 后成功启动。blog、freeshell 控制面板恢复正常，但发现监控国外 VPS 隧道的脚本变成了 lug-vpn 服务器上的版本，导致国外隧道中断，这是由于之前 git pull 的时候不慎把 lug-vpn 服务器上的配置拉下来了。
为了恢复到干净的网络配置，12:05 再次重启服务器，以为所有服务恢复正常了。但端口映射事实上不能正常工作，当时没发现就去吃饭了。Qijiang Fan 和 崔天一 分别报了 bug，吃饭回来我执行了重置 freeshell 与 blog 服务器之间 GRE tunnel 的脚本，就好了。该脚本忘了放进 /etc/rc.local 里，因此重启时没有执行。
本次故障造成 blog 和 freeshell 控制面板 20 分钟左右的服务中断，端口映射服务中断约一个小时。
2015 年 1 月 6 日 zhsj 发现 Chrome 40 Beta 版里，ustclug.org 和 servers.ustclug.org 的地址栏不是小绿锁而是小黄锁，也就是不完全是安全连接。这是由于 Chrome 40 决定把证书失效时间不早于 2016 年 1 月 1 日，并且使用 SHA-1 数字签名算法的 SSL 证书认为是不安全的。推荐使用的是 SHA-256 数字摘要算法。
1 月 7 日，stephen 向 LUG 捐赠了 StartSSL Class 2 认证账号一枚，可用于颁发有效期两年的任意 SSL 证书。用该账号给 https://ustclug.org/ 和 https://servers.ustclug.org/ 换发了使用 SHA-256 和 RSA 2048 位数字签名的新 SSL 证书。
ustclug.org 新证书的基本信息（为防垃圾邮件用了图片）：
感谢 stephen 的捐赠！
Blog 在 “设置” 中上传新的 SSL 证书后，不会立即生效，而要过一段不确定的时间才会生效。这个问题现已修复。
问题是由于代码里仅仅在域名修改时才会修改并重新载入 nginx 配置，而域名不变、仅 SSL 证书修改时，只是把新的证书放到了 nginx 配置目录里，没有重新载入 nginx 配置，因此不会立即生效。需要等其他 blog 或 freeshell 用户执行了会导致 nginx 配置修改的操作时，nginx 配置被重新载入，新的 SSL 证书才能生效。
2014 年 12 月 18 日服务器故障、20 日恢复以来，blog 的注册一直处于关闭状态。这是由于本次故障的部分原因与遭受资源耗尽攻击有关，该攻击利用了 blog 注册流程中的一处漏洞：填写任意 E-mail 地址，在收到激活邮件的同时，blog 的数据库和文件已经被创建，只是处于未激活状态。当初如此设计，是为了让用户在点击激活邮件后，可以立即开始使用 blog，而无需等待安装。
由于安全架构的原因，blog 注册系统只能通过几个特定的接口访问数据库，因此不能把用户的注册信息保存进数据库里。为了让用户点击激活链接后无需重新输入注册信息就能完成注册，需要把用户的注册信息编码在激活链接里。由于注册信息中包含明文密码，而 blog 安装过程中需要把明文密码交给 WordPress 安装程序，我们对注册信息使用仅服务器知道的密钥进行加密。用户点击激活链接后，服务器从链接中解码、解密注册信息，完成之前的注册和激活步骤。
2014 年 12 月 18 日服务器故障、20 日恢复以来，freeshell 的注册一直处于关闭状态。这是由于本次故障的部分原因与遭受资源耗尽攻击有关，该攻击利用了 blog 注册流程中的一处漏洞：填写任意 E-mail 地址，在收到激活邮件的同时，blog 的数据库和文件已经被创建，只是处于未激活状态。当初如此设计，是为了让用户在点击激活邮件后，可以立即开始使用 blog，而无需等待安装。
Freeshell 的注册流程与 blog 类似，也是注册时先创建好虚拟机，但不启动它，控制面板也不允许操作。这也给利用任意邮件地址滥发注册请求、耗尽资源提供了方便。
修复方法是：在注册时将用户的注册信息和唯一的 id、随机 token 保存在临时表中，并把 id 和 token 包含在用户收到的激活 URL 中。用户点击 URL 后从临时表中取出注册信息，一并完成原来的注册和激活。
我们检测部分用户自己 HTTP proxy 的域名没有 CNAME 到 proxy.freeshell.ustc.edu.cn，而是使用了 A 记录或 CNAME 到了其他域名。这会带来备案问题，也不便于我们升级 HTTP proxy 系统。希望您尽快在域名注册商处把自己的域名 CNAME 到 proxy.freeshell.ustc.edu.cn，谢谢！