寒假期间，我们重构了网络启动服务（PXE），主要有以下改变：
校内使用方式和以前一样。校外用户可在 GRUB2 命令行中执行以下命令加载我们的网络启动服务：configfile (http,pxe.ustc.edu.cn)/boot2/menu/root.menu
诚邀各位使用并提供反馈。
freebsd-pkg 源占用空间较大。我们分析了 freebsd-pkg 镜像的访问记录，除去 FreeBSD Tier 1 架构（amd64/i386/aarch64）以外，其他架构的访问量都非常少（每月少于100次访问）。
为了缓解 mirrors 空间紧张问题，提高空间利用效率，我们决定移除 freebsd-pkg 源非 Tier 1 架构的软件包镜像。
LUG 服务器维护人员定于 7月6日（周一）14:30 起，对 Mirrors 进行停机维护。预计当晚可恢复服务。
本次维护主要有两个目的：
维护期间，Mirrors 的 http 访问会被自动重定向到其他镜像站。rsync、ftp 暂停服务。
希望各位用户予以理解！
5月21日早晨6时许，Mirrors 外部磁盘阵列 XFS 文件系统发生故障。
此次文件系统故障疑为前一日外部磁盘阵列连接异常中断所致。我们现在正在对文件系统进行完整的检查和修复，以彻底消除前次故障对文件系统的影响。
一次完整的磁盘检查需要花费大量的时间。在此期间，部分镜像将无法访问。为了减轻对用户的影响，我们临时将这部分镜像的 http 访问分流到国内其他镜像站。
给您带来了不便，敬请谅解！
更新： 磁盘检查于5月21日下午3时左右结束，服务现已恢复。
今年2月开始，Mirrors 上若干 Git 仓库提供了 git 协议支持。但最近我们发现，用户通过 git 协议访问 linux 和 linux-2.6 这两个占用空间巨大的仓库时，会占用服务器大量 CPU 和内存资源。
为了保障 Mirrors 上其他服务的正常运行，在找到解决方案以前，我们将无限期取消这两个仓库的 git 协议支持。原先提供的 http、https 访问不受影响。
望各位用户予以理解！
近期，lug.ustc.edu.cn 服务器一块硬盘出现了坏道，造成部分数据损坏。
损坏数据多为 LUG 主页 wiki 生成的缓存，其他重要数据均已备份。而 Time Machine 的备份文件在另一块硬盘上，未受到任何影响。
为避免进一步的数据损失，技术部门将于2015年5月2日下午3:00开始对该服务器执行停机维护，更换损坏的硬盘。预计停机2小时，届时以下服务将不可用：
希望各位用户予以理解！
2014年10月19日凌晨开始，Freeshell 节点 5 发生故障无法连接。
当日上午，维护人员进入少院机房主控室进行物理接触，发现之前新添加的硬盘出现故障，导致系统被 IO 操作卡死。故障原因是硬盘连线接触不良，导致设备离线。
强制关闭机器后，新硬盘被移除。重新开机后，Freeshell 节点 5 服务恢复。
另外，查看节点 6 日志后，发现该节点新硬盘也出现了类似的错误。为了避免事故，我们将故障硬盘直接移除了。这一过程中，节点 6 的服务未受影响。
对于节点 5 上受到此次故障影响的用户，我们深表歉意。
一言以概：科大 mirrors 服务器被黑客入侵以及攻击了。
下面将以 cuihao 同学的视角描述整个过程的经过。其中跳过了大量技术细节，以后有机会会陆续公布。
8月6日
mirrors 流量大增，IO负载也显著升高。rsync 日志显示同步 ubuntu 镜像的下游同步流量较平时显著升高。
8月8日
有人报告 http 出现零星的 404 错误，但没有引起重视。
晚上，为了降低负载和网络压力，限制了单 IP 的 rsync 并发连接数。
8月9日
中午，由于前一天的限制效果不理想，又对 http 并发连接施加了限制，并进一步压低了 rsync 的限制，网络/IO 压力得到控制。
晚上，有 mirrors 维护人员发现，从上游同步 ubuntu 镜像同步时出现奇怪的错误。检查后发现，ubuntu 镜像目录下的 /ubuntu 软链接（指向自身），被人替换为文件夹，并将自身 bind mount 到该文件夹上。
这就解释了 mirrors 流量激增的原因：mirrors 的下游源要多传输一整个 ubuntu 镜像。该问题于当日解决。
当日，有更多人反应 http 出现随机的 404 的错误。这引起了我们的注意。Nginx 日志和 strace 跟踪显示，Nginx 对特定文件执行 open 系统调用时有一定概率因 ENOENT 失败。但无法用其他程序重现，原因不明。
8月10日
LUG 多位技术人员都开始对 404 问题进行调试。boj 发现，Nginx 执行 open() 系统调用后，包含文件路径参数的字符串被篡改了。
下午，该 bug 突然出现反调试行为 —— Nginx 被 gdb 或 strace 跟踪之后，bug 消失，无法再次重现。调试陷入僵局。综合前面链接被替换的事件，有人指出 mirrors 可能被人入侵。但这也使得该 404 问题得到临时“解决”——我们把所有 Nginx 进程都 strace 上了……
晚上，测试了 Apache，发现 Apache 会出现随机的 403 错误。根本原因和 Nginx 错误一样，即 open() 调用失败。
当天还发现，root 的 bash 历史在近期被清除过（第一条记录为 rm ~/.bash_history）。
8月11日
boj 深入内核进行调试，最终发现了导致 404 问题的罪魁祸首。mirrors 上被人植入了一个内核模块，该模块会篡改 open() 函数的参数。根据 boj 反汇编结果，其行为大致如下：
if (process name is "nginx" and process is not traced) or
\(process name is "apache2" or "lighttpd"))
if (rand() % sample == 0)
if (path is not empty && file extension is "exe", "msi"...)
rewrite the path to empty string
自此，404 问题真相大白。
8月12日
我们对系统文件做了检查（使用 debsum），没有发现其他文件被篡改。但为了安全起见，决定于 14 日停机重装系统。
8月13日
下午将近6点，mirrors 上短时间内 fork() 出两万多个 vsftpd 进程，FTP 服务疑似遭 DoS 攻击。发现时为时已晚，服务彻底瘫痪。http 服务切换到备份机器。
晚间，cuihao、Guangyu Zhang、pudh、zsj 进入机房，决定提前开始重装系统作业。作业持续到晚上 11 点，大家先回去洗洗睡了。
8月14日
http、rsync 服务陆续恢复。不过因为路由配置错误（当时未发现），所以国内非教育网用户仍访问的是备份站点，也无法访问 rsync/ftp。
当日，我们对 vsftpd 进行了大量测试。认为 vsftpd 先 fork()（clone()）再检查客户端数量限制的行为使得 DoS 成为可能。进行若干严格的限制后，ftp 服务也恢复了。
8月15日
晚上，cuihao 发现国内非教育网用户仍无法访问 mirrors 的问题。后经检查确认是路由没有配置好，现已修复。
此次事件显示，LUG 服务器安全方面存在不少漏洞。重装系统后，我们会在安全方面做更多努力，以后这些安全措施也会逐步应用于其他服务器。
同时 LUG 也对黑客入侵和攻击 mirrors 服务器的行为表示强烈愤慨 🙁
近期我们对 mirrors 上的所有镜像了清理（见《Mirrors 镜像整理通知》），下面列出了所有受到影响的镜像。
今天（2014年8月3日）下午3点左右，我（cuihao）对 Mirrors 服务器上的 LXC 虚拟机执行了关机操作（lxc-shutdown）。由于虚拟机没有配置网卡隔离，该操作导致 mirrors 网络被切断。此次事故和去年年底的一次宕机事故非常相似。
事故发生后，我立即联系了 James Zhang 老师，并前往网络中心机房着手修复。断网导致 iSCSI 阵列出现大量 IO 错误。当时登录很慢且 sudo 后终端卡住，我错误地认为这是由于IO问题导致系统卡死（事后想到应该是LDAP无法链接导致的），并重启了系统。
重启导致了新的问题——系统引导失败。后来在 @zsj 同学的协助下，才通过U盘中的引导器进入了系统（但主机的引导仍未修复），mirrors 恢复服务。恢复服务后，发现 mirrors 的路由配置以及 udev 规则存在一些问题，有待日后解决。
Mirrors 从 15 时左右停止服务，到 17 时左右恢复服务，宕机时间约2小时。
近期 Mirrors 多次宕机，严重影响了服务质量，LUG 维护人员对此深表歉意。
为了避免 Mirrors 服务器故障给用户带来困扰，我们在 DNSPod 上设置了故障时DNS自动切换。检测到故障时，Mirrors 的域名解析会被切换到另一台服务器，该服务器会将用户的 HTTP 访问重定向到其他镜像站。