一个斜杠引发的血案

注：不了解 mirrors 的朋友，请先看《科大开源软件镜像是怎样炼成的》。

祸起 iSCSI

故事要从2013年6月26日讲起。mirrors 有一个网线直连的磁盘阵列，使用 iscsi 协议，上面有一个XFS文件系统。6月26日下午14时许，stephen 在邮件列表里报告 mirrors 挂了。根据 syslog，6月26日13:58，iscsi 连接超时，导致 sdg 访问失败，大量I/O操作被卡住，导致 nginx 被卡住，mirrors HTTP 无法连接。几分钟后，I/O超时，nginx 恢复正常，但磁盘阵列上的源无法使用了。

这是第二次了。就在6月1日，mirrors 就出现了同样的 iscsi 连接超时 (内部页面)，导致了同样的后果。因为当时没有经验，服务中断了4小时。当时，我和 tux 都把问题矛头指向磁盘阵列上的 XFS 文件系统，因此试图使用 xfs_repair 修复，没有任何结果，最后 umount，mount 就好了。事实上，问题出在 iscsi 上（具体原因未知），跟 XFS 可能没什么关系。这次故障修复用时2小时。

好景不长。6月27日 10:30，mirrors 再次出现同样的问题，服务又挂了。我故技重施，半小时就解决了问题。这么长时间是因为总是找不到占用着挂载点的进程，原来是 mirror-lab LXC 虚拟机的根分区在磁盘阵列上，lxc-stop 之后就能 umount 了。

“血案”现场

频繁的故障促使我们把 LXC 的根分区移到磁盘阵列外面。斜杠引发的血案由此上演。

4月27日16时许，mirrors 无法 SSH 了，但 HTTP 服务正常，rsync、FTP 服务挂了。原因是 /lib 消失了，/lib/ld-linux.so 也消失了，所有需要动态链接的程序，包括使用 glibc 的程序都无法运行。HTTP 请求不需要开新进程，因此能正常工作；rsync、FTP 每个连接都要开新进程，于是都不能用了。

根据 /var/auth.log 和我的回忆，故障的过程是这样的：

  1. 由于 mirror-lab 在 sdg 里，sdg 不稳定，所以就想移出来。
  2. cp -R /path/to/mirror-lab-root/ /path/to/new-mirror-lab-root/
  3. 启动LXC，发现目录权限和 owner 不对，所以就想用 rsync 修正。
  4. 在 pwd=/ 里 rsync -aP /path/to/mirror-lab-root/ . 是在 screen 里执行的，然后就logout 了。这个操作导致根目录被覆盖掉。
  5. 过了一会儿在另一个打开的 session 里发现没有同步过来，screen -r，发现那个 rsync 还没有结束，心想怎么这么慢呢，就 Ctrl+C 掉，cd 到家目录，rsync -aP /path/to/mirror-lab-root/ .
  6. 马上发现同步目标写错了，在 pwd=/home/boj 里 rm 一长串，其中包括 lib/
  7. 发现 ls 不了了，就 logout，发现再也不能 login 了。
    为什么当时会连犯覆盖根目录和删掉 lib 两个重大错误呢？我觉得是因为当时正忙着写别的程序，心不在焉，敲命令的时候没有过脑子。前两步是在我比较空闲的时候做的，但后面的 rsync 就是在手忙脚乱中做的。

从上面的操作过程里可以吸取几个教训：

  • 使用相对路径时，一定要注意 pwd（我几乎不用 pwd=/，知道这很危险，但这确实发生了）
  • 第5步，发现没有同步完成时，应该检查一下上次输入的命令，而不是直接重写一遍。
  • 不要用 rm xxx/，要用 rm xxx，以免 follow symlink。
  • 不能 ls 时不能急于 logout，而要用 bash 内置命令检查一下是什么问题，如果当时没有 logout 说不定还有可能修复。

亡羊补牢

当时只有 stephen 有 login session，只有一些 bash 内置命令可用。由于 LXC 并没有被破坏，LXC 仍然能正常登录和操作。只不过我们找不到 LXC 的漏洞以跳到主机里。通过 bind mount 的 /srv/array 作为跳板，外界静态链接的程序可以被送进 mirrors 并运行。

tux 做了一个静态链接的 busybox，但 stephen 说不能用。后来 tux 又从其他 Debian squeeze stable x86-64 的机器上复制了 /lib 目录到 mirrors，stephen 把它们 copy 过去了，此时 SSH 连接立即断开了（原因未知）。rsync 和 FTP 服务恢复正常了，可见 copy 过去的 /lib 是有效的。但 SSH 还是进不去（原因未知）。看来是不得不去机房了。

28日 00:49，我们发布了 mirrors 维护通告。由于当时临近期末考试，我和 tux 否决了复杂的、可能需要一天的虚拟化方案，计划速战速决（当时我还不知道做了 rsync 覆盖根目录的傻事，只是以为 /lib 挂了）：

  1. 重启机器，进U盘 live 系统
  2. 用 dpkg 检查缺失文件的情况，并复制缺失的文件进去
  3. 重启机器，看是否正常
    考虑到系统文件被严重破坏的 mirrors 可能需要重装，stephen 建议我们采用切换 DNS 到备份站点的应急方案。我写了个脚本找出国内几大开源软件镜像的源列表，人工处理名字不同的源之后，随机把现有的源分配给这些镜像站。在备份站点的首页上挂上了维护通告。凌晨3点，backup.mirrors.ustc.edu.cn 在 lug.ustc.edu.cn 服务器上搭建和测试完成。还修改了 mirrors 系列域名 DNS 记录的 TTL 为 120 秒，以便 DNS 修改快速生效。

去机房

6月28日10时，我们来到网络中心机房，开始修复 mirrors。首先，我们修改了 DNS 记录，让 mirrors 系列域名 CNAME 到 backup.mirrors.ustc.edu.cn。一两分钟后，大部分源通过 HTTP 重定向到国内其他开源软件镜像，在 lug.ustc.edu.cn 服务器上看到了飞速刷屏的 access log。

熟悉 mirrors 的硬件环境、确认问题后，tux 用前一晚制作的 Debian 启动U盘启动 mirrors。很快就发现，问题不是那么简单，因为 /home 和 /etc/passwd 都被覆盖了。既然这样，只好重装系统了。

我和 tux 在前一天晚上已经讨论了详细的 LXC 虚拟化方案，但不打算立即实施。但到了机房，tux 希望把虚拟化做出来，我没有提出异议。他又希望在下面搞一层 Xen，以便主机出错时能在不进机房的情况下解决，我也没有提出异议。由此看来，我是负有重大 “领导责任” 的。

12时许，我见没有要结束的意思，就把 pudh 和 bible 叫过来观战。zguangyu 已经回家了，因此没来。我们一起折腾到19点，确保 mirrors-main 不会挂了（这只是一厢情愿），才 “恋恋不舍” 地离开了机房。

IMG_20130628_132139IMG_20130628_132139

“花瓶” 架构

当时设计的虚拟化架构听起来很美妙，但实际做起来困难重重。

mirrors-structuremirrors-structure

tux 的设 (wa) 计 (keng) 能力果然很强，搞了两层虚拟化，如上图所示。底层虚拟化是 Xen，Dom0 是 mirrors-base，找 jameszhang 要了一个专用IP（202.38.95.106），只能从几个受限 IP ssh，仅用于恢复目的，平时严禁使用。Dom0 挂载了几块本地磁盘，除用于根分区的那一块以外，都映射到 Xen 的 domU 里。domU 只有一个，是 mirrors-main，绑定了 mirrors 三条线路的四个公网IP，通过 eth1 连接 iscsi，挂载磁盘阵列。

第二层虚拟化是在 mirrors-main 上开了几个 LXC container，分别用于 nginx，ftpd，rsyncd，rsync 和 lftp 同步，静态页面生成，mirror-lab，ftp-push（可写ftp）。

听起来挺美妙的，但是……装 Xen 的时候，为了让 mirrors-base 能够访问 mirrors-main 的文件系统（以便修复），根分区不是用 Xen 官方工具建立的，而是手工在 LVM 卷上 debootstrap 出来的。DomU 的根文件系统是 NFS 挂载在 Dom0 上的。配置文件里有一些 undocumented 的东西，tux 就开始翻 xen-tools 的 python 源码，终于 NFS 启动成功了……还有几项配置，是参考了之前在少院搞的 Xen 配置文件。

LXC 也不是个好伺候的主，直接建立的 LXC 是启动不起来的。需要修改配置文件 bind mount，建立 tty 设备文件等。我把 mirrors-main 的配置脚本用 git 库管理起来了：http://gitlab.lug.ustc.edu.cn/mirrors/mirrors-main/tree/master （需注册登录）这算是那次不完整的 mirrors 重建留下的一点遗产吧。如果要使用这些脚本，请一定区分清楚是在主机里运行的，还是在 LXC 虚拟机里运行的。

折腾 LXC 网络

折腾完 Xen，LXC 的网络是个更大的麻烦。不想在 mirrors-main 上放任何有用的服务，就需要把 nginx，ftp 和 rsync 分端口映射到 LXC 里。

总共试验了四种方案：

  • 让 LXC 和主机共享相同的 IP，用 ip rule 和 fwmark 转发。
  • 用 DNAT 端口映射。
  • 用 IPVS（Linux Virtual Server）路由。
  • 不隔离网络命名空间。

共享 IP?

首先是想让 LXC 和主机共享相同的 IP，就搞了 ip rule 和 fwmark。这并不是那么简单，因为 mirrors-main 的根分区是 NFS 挂载，如果把 NFS 搞断网了，可不是什么好玩的事……因此，我们不得不调整了 local 规则的顺序（以下规则做了简化）。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
// rc.local in mirrors-main
iptables -t mangle -A PREROUTING -d 202.38.95.110   -p tcp --dport 80 -j MARK --set-mark 86
ip rule add from all lookup local          pref 200
ip rule add from all fwmark 0x56 lookup 86 pref 100
ip rule del from all lookup local          pref 0

// After LXC startup in mirrors-main
ip addr add 10.87.0.1/30 dev veth-nginx
ip route replace default via 10.87.0.1 dev veth-nginx table 86

// rc.local in LXC
ip addr add 10.87.0.2/30         dev eth1
ip route add default via 10.87.0.1 dev eth1 table 1000
ip rule add from 202.38.95.110   table 1000

折腾这些规则可不是一帆风顺的。6月29日，mirrors 重建的第二天，我就把 mirrors-main 的 NFS 搞挂了，我就到 mirrors-base 里修。忘了由于什么原因，mirrors-base 的 SSH 断掉了。（不是由于经典的 sudo networking restart，我们全程都是在 byobu 里操作的。）当时是周六，网络中心机房的值班老师不在。我跟 jameszhang 打电话，他主动提出从科大花园跑到网络中心一趟，我们实在是过意不去。

这就 OK 了吗？LXC 能收到入站数据包，但回复的出站数据包就不见了。在 PREROUTING 链还能匹配上，但在 INPUT，POSTROUTING 和 FORWARD 上都找不到回复包，我们猜测是内核的路由逻辑发现 FORWARD 包的源IP和目标网卡的某个IP相同就丢包了。用其他机器做了个实验，发现 Linux 确实不会转发源IP与目标网卡IP相同的包。当时想用 ebtables 搞，但我们研究它的结构后没有想出方案来。

最后，搞定 iptables 转发本地地址被内核“吃掉”的问题，只需要一行：
net.ipv4.conf.<interface>.accept_local = 1

我当时是翻了内核源码，定位到“吃掉”非法包的地方。相关 commit：
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8153a10c08f1312af563bb92532002e46d3f504a

但是，IPv6 没有对应的选项，我们也没搞出来。

DNAT?

DNAT 端口映射倒是简单，但无法处理 ipv6，内核的 ipv6 NAT 是在 3.7 才有的，我们不想用太新的内核。

IPVS?

接下来试验的是 ipvs (Linux Virtual Server) NAT 模式，宣称支持 ipv6，而且操作起来确实方便。不过 ipv6 确实无法工作，我也不知道是什么原因。

我们又试了把所有虚拟机和主机的网卡桥接起来，使用 ipvs 的直接路由方式，估计是什么地方配置有误，仍然不能按照预想的工作。

不隔离网络命名空间！

在折腾两天后，tux 做出了一个艰难的决定：不隔离网络命名空间。

不过，这种配置也带来了更大的风险：LXC 内执行 init 0 就会运行关机脚本，停止网络设备，然后 mirrors-main 的网络就会停止运行！也就是说，只能运行 lxc-stop 来关闭虚拟机，在虚拟机内 shutdown 是很危险的。

性能问题

磁盘

6月30日8时许，HTTP 访问初步恢复（没有 IPv6），于是把 DNS 切回来了。

DNS 刚刚切回来20分钟，就发现响应很慢，CPU 几乎是 100% wait，于是9时许又切回 backup.mirrors 了。回去睡觉。

当天搞明白了原因，是 Xen 的磁盘虚拟化层导致的。当初是在 Xen Dom0 上挂载 LVM，再把 LVM 分区映射到 DomU（mirrors-main）的。tux 改成了把物理硬盘（/dev/sdx）直接映射进 DomU，再在 DomU 上挂载 LVM，问题解决。

网络

7月2日6时，mirrors HTTP 服务恢复，首页挂上公告，把 DNS 切换回来，向 科大 LUG 和清华 TUNA 邮件列表发布了恢复公告。

观察半小时没有问题后，我就回去睡觉了。事实上，因为当时还是清晨，访问量很小，I/O 性能问题还没露出其狰狞的面目。一整天，我们都没有去看 mirrors，也没有恢复 collectd 监控服务，因此我们对服务器的运行状态一无所知。

19时许，anthon 社区报告了 mirrors 访问缓慢的问题。我们这才发现首页几乎都打不开，这一整天 mirrors 几乎是不可用的状态。

20时许，查明了 mirrors 访问缓慢的原因。iscsi 是在 Xen 的 domU，不知道 Xen 的网络虚拟化层捣了什么鬼，总之 iscsi 挂载 XFS 的磁盘阵列只有几百K，而 I/O util 已经是 100% 了。Nginx 在 I/O 很慢时会被卡住，因此本地磁盘上的 HTTP 请求速度也受到牵连。我把磁盘阵列 umount 了，本地磁盘的访问马上正常了。

晚上24时许，tux 解决了这个性能问题。把 iscsi 在 Xen 的 dom0 挂载，再直接映射到 domU 里，就好了。由此推断是 Xen 的网络虚拟化层导致的。

故障影响

6月28日10时到7月2日6时的92小时里，来自 12.8 万个IP的 1060 万次 HTTP 请求被重定向到其他源，来自 1.1 万个IP的 161 万次 HTTP 请求因为没有设置重定向而无法正常完成，也就是说 94.5% 的 HTTP 请求被重定向到其他源。而用户是否能正常使用，还取决于被重定向到的源的可用性。例如，6月28日中午有两个小时左右，由于 bjtu 源恰好也挂掉了，导致 40% 的用户无法使用 debian 源（当时做的是 2:4:4 在 tuna、bjtu、sjtu 间负载均衡）。

7月2日上午9时至晚20时，由于前面提到的性能问题，mirrors 基本处于完全瘫痪的状态，打开首页都要很久，校内下载速度只有十几K。相比前几天重定向到其他源，这才是本次故障事件最严重的影响。

我们对这次影响数以十万计服务器和 PC 用户的大规模故障深表歉意。

总结

这次 mirrors 大规模故障，有两个原因：一是我 “一个斜杠” 的误操作，二是修复过程中的折腾。

误删 /lib

直接把 Zhang Cheng 的评论 摘过来了：

紧急的事情总是有，比如我在公司就碰到过一些紧急情况，由于受到攻击或者程序bug或者其他原因，导致一些关键服务器宕机。这时候，经验少的人很容易慌张，不知道该怎么办（因为只知道挂了，但不知道问题出在哪里，定位问题很困难），而我碰到这样的情况，会刻意的告诉自己，冷静，仔细的思考，不要轻易的下结论。慌张对解决问题起不到任何作用，冷静的思考才是正道。比如有一次夜里我们的一台db服务器宕机了，由于NFS的原因，连带另外几台机器的nginx都响应很慢。但是大家都没有先验经验，不知道nfs会导致nginx hang住，所以也根本想不到nfs有故障这回事。大家只是知道nginx响应很慢，但是看系统的各项指标（cpu、内存、带宽、io等）都很正常，所以有人提出重启机器。我当时拒绝了重启，因为没有找到问题的根源，甚至连线索都没有，盲目的重启，可能无法解决问题，甚至会破坏现场，使得这个问题再也无法找到。后来无意中通过/proc/$nginx-pid/stack中看到了nfs的影子，以此为线索最终定位到了nfs的问题。

大家维护mirrors都难免会碰到各种紧急的事情。这几年维护服务器的经验，使得我的性格越来越“慢”，越来越“果断”，在各种紧急情况（不一定是操作服务器）下能够不慌张，能够沉着，能够果断的做出决定。这也是我最大收获之一。

维护服务器的经验，同样使得我养成了许多条件反射。例如我在执行任何可能有伤害的命令前，都会在敲回车前停顿1秒。还有许多命令在执行前我都会给自己留个backup的退路。比如我见过一个人敲crontab命令时敲错了，敲成了crontab -<某单词>，某单词中含有字母’r’，导致crontab被清空，所以后来我每次执行crontab命令前，都会下意识的先执行一次crontab -l，这样即使后面自己出错了，还有机会找出前面的内容以恢复；同时我在线上部署crontab任务时，也尽量避免直接用crontab命令，而是写文件放到/etc/cron.d/中，以杜绝这种错误。

===== 引文结束 =====

修复过程中的折腾

这暴露了几个严重问题：

  1. 没有把用户体验放在第一位，在生产服务器上折腾不熟悉的技术。以后遇到服务器故障，在不破坏现场以便事后分析的前提下，要把尽快恢复服务放在首位。

  2. 没有培养新人，人员上容易发生“单点故障”。故障期间恰好是期末考试周，我和 tux 都很忙。LUG 其他人早先没碰过 mirrors，也没办法插手。

  3. 系统配置文件没有完整备份，只是把与服务有关的配置文件用 git 管理起来了，导致 SSH key 丢失。

  4. 恢复服务之后没有对运行状态进行持续监控。应当尽快恢复 collectd、ganglia 之类的监控服务。

  5. 高负载服务只有最基本的报警，运维人员无法及早得知硬盘满、内存短缺、I/O util 过高等 “安全隐患”。可以尝试用 monit 或 nagios 做更细粒度的报警。
    此外，关于 mirrors 的日常运维，也已经暴露了一些问题。虽然与此次故障无关，但与之前的其他故障有关，也是值得重视的。

  6. 源的同步状态只有粗糙的监控。应该加上长期统计以供调整同步策略参考。

  7. syslog 一定要检查，比如 nf_conntrack table full，如果不是 iscsi 故障，运维人员都不知道有这回事。

虚拟化的迷思

虚拟化可以让运维变得更简单，也可以让运维变得更复杂。

如果 HTTP、rsync、FTP 等基础服务在主机上，同步脚本之类的在 LXC 虚拟机上，就能起到隔离的效果，提高稳定性，也便于分不同人维护。

然而，像这次 mirrors 重建这样，搞两层虚拟化，而且试图把 HTTP、rsync、FTP 这些 “大象” 塞进 LXC 的 “冰箱” 里，不仅需要用大量的胶水在不同的层次间黏合，还容易带来性能问题。更严重的是，当出现问题的时候，我们要花更长的时间排查问题出在哪个层次；出问题的层次越低，修复的复杂度越高。

兴也勃焉，亡也忽焉

我想，这个成语最能够形容我上学期对 mirrors 做的事了。

  • 2012年11月24日，在 Linux User Party 上，信誓旦旦地宣布要搞 mirrors lab，让更多人参与 mirrors 维护。不过，在来自 tux 的阻力下，这个计划一直搁置。
  • 2013年3月15日，tux 在内部邮件中提出使用 os-level 虚拟化技术的想法。
  • 3月29日，沙盒第一版做好了，没有使用 LXC，而是 tux 自编的命名空间隔离脚本。lab.mirrors.ustc.edu.cn 在 nginx 里指向 /srv/array/exports，也就是提供了 HTTP 访问。
  • 4月5日，利用一个经典 chroot 漏洞，我获得了 mirrors 主站的 root 权限。也许这是 LUG 成员第一次通过非正常途径获取权限，也希望这是最后一次。
  • 4月10日，我再次催促 tux 在 mirrors 上部署安全的 container。
  • 4月12日，container 里同步完成 kernel.org, chakra, apache, php.net 几个镜像，设置 crontab 6小时同步一次。正在同步的镜像还有 pypi, rubygems, openwrt, trisquel, dev.mysql.com。
  • 4月12日，tux 把同步完成的4个镜像放入主站首页。
  • 4月18日，tux 使用 LXC 建立好了 mirror-lab，算是第二版沙盒吧。
  • 4月27日，LUG 换届大会召开，tux 宣布了 mirror-lab 成立，但并没有开账号。
  • 4月28日，mirrors-lab 的一大波新同步的镜像上线。
  • 5月1日，php.net 镜像转移到 lug 服务器上，申请官方源被拒。
  • 5月9日，一批比较稳定的源被放上 mirrors 主页。我不太确定，但这可能是我第一次动用 mirrors 主站上的账号。
  • 5月10日，stephen 拿出了 mirrors 曾经的一版 index，放在 testindex.mirrors.ustc.edu.cn。
  • 5月10日，把 mirror-lab 上的同步脚本用 git 管理。
  • 5月13日，hackage 源上线。
  • 5月15日，zguangyu 提出在 mirrors 上同步 PPA，tux 给他开了账号。这是 mirror-lab 上除了 tux 和我以外的第三个人。
  • 5月19日，向 sourceforge 提出 mirror 申请，不过在一次回复之后就再也没有回信了。
  • 5月20~24日，向多个发行版官方提出官方源申请。
  • 5月25日，根据 stephen 的建议，mirror-lab 上我的同步脚本升级。
  • 5月31日，tux 修复了早先一直 502 的 FreeBSD 源。
  • 5月31日，mirrors 某块本地硬盘满了。
  • 6月1日，mirrors 第一次磁盘阵列 iscsi 故障。
  • 6月3日，PyPI 同步改用 bandersnatch，变得稳定了。
  • 6月4日，PyPI 源（pypi.mirrors.ustc.edu.cn）开始试用。
  • 6月4日，nginx 日志文件格式升级，增加两个字段。
  • 6月9日，mirror-lab 修改默认出口为移动出口。
  • 6月10~15日（具体时间记不清了），mirror-lab 开始悄然从 mirrorservice.org 同步 sourceforge 源。
  • 6月12日，给 pudh 开 mirror-lab 账号。
  • 6月14日，发布了 meego 源。
  • 6月15日，去掉了 meego 源，添加 tizen 源。（多亏了移动出口，一天 500G 的源就同步完了）
  • 6月16日，把 mirrors 主站的同步脚本用 git 管理，这是我第一次看到 mirrors 原来的同步脚本。
  • 6月17日，给 anthon 开源社区提供可写 FTP。
  • 6月20日，对 mirrors 主站各镜像的同步状态逐一排查，尽量做到全绿。
  • 6月20日，把 mirrors 的 nginx、rsyncd、vsftpd、logrotate、rc.local 等系统配置文件用 git 管理。
  • 6月20日，mirrors 主站的同步脚本改为默认移动出口。
  • 6月20日，stephen 发布了 mirrors 的磁盘负载分析。
  • 6月21日，stephen 在内部邮件中提出了系统维护的一些规范。这些规范在重建 mirrors 时被采用。
  • 6月24日，我开始写 mirrors 新版首页。
  • 6月26日，mirrors 第二次磁盘阵列 iscsi 故障。
  • 6月27日，mirrors 第三次磁盘阵列 iscsi 故障。
  • 6月27日，我不慎把 mirrors 搞挂了。
  • 6月28日至7月2日，mirrors 关站维护，HTTP 被重定向到其他源。
  • 7月2日，在未解决负载问题的情况下满负荷运行，导致一天几乎无法访问，事实上这才是最长的故障时段。
  • 7月4日，搞清楚了故障原因，总结教训。
  • 7月5日，tux 把 LXC 的一些文档整理到了 LUG wiki 内部页面。
  • 7月5日、6日，我和 tux 相继离开学校，mirrors 重建工作陷入停滞。
    前几天，mirrors 又发生了一次硬盘故障。在 mirrors 之前的维护人员都不在场的情况下，新一届 LUG 技术团队在短短两天内重建了 mirrors 的各项基本服务，并部署了合理的 LXC 虚拟化架构。尽管故障不是什么好事，但最近这次重建是值得庆贺的。重建效果总体上令人满意，比我们两个月前那次务实多了。

在今后的一段日子里，希望 mirrors 维护团队：

  • 吸取故障教训，完善备份和监控；
  • 尽快把 SourceForge 源联系好；
  • 恢复 mirrors 原有的 SSH 账号和家目录；
  • 逐步为已有源的同步状态和访问热度添加监控。
    祝愿 mirrors 早日走出故障的阴影，重振昔日雄风，继续领跑大陆高校开源软件镜像。作为 LUG 访问量最大的网络服务，相信 mirrors 能让她的每位维护者领略到别样的风采。

Comments

▲