GitLab 挂上小绿锁了

代码安全是一件比较严肃的事情。看到这么多人使用 GitLab,我自己也经常在校外使用 GitLab,安全的 HTTPS 传输是必要的。由于 gitlab.lug.ustc.edu.cn 是三级域名,LUG 也没有顶级域名 ustc.edu.cn 的管理权限,搞 SSL 证书是比较麻烦的。

为此,我申请了 gitgeek.net 域名,去 StartSSL 申请了一个免费 SSL 证书。没办法,GoDaddy 非促销季的证书太贵了;要是那位高富帅给 USTC 搞个 Verisign 的 Extended Validation,我可以给TA所有服务器的 root 🙂

总之,GitLab 挂上小绿锁了:

screenshot

在 Ubuntu 和 Windows 下的主流浏览器中测试,均可以正常访问。在 Debian 和 cygwin 中用 git clone 和 curl 也可以正常访问。由于 wget 1.12 的一个 bug,会提示证书不匹配,升级 wget 即可。

如果大家发现小绿锁没有挂上,或者 HTTPS 访问出现任何问题,请把你用的操作系统、浏览器或命令行工具的名称及版本号发到 lug@ustc.edu.cn。

原来的 http://gitlab.lug.ustc.edu.cn 仍然可以使用,只不过登出之后,登录会跳到 gitgeek.net……… GitLab 就是这样的,我本来不想这样……

Tips for GitLab Maintainers

修改配置文件后,最好清除 Redis Cache。例如 Gravatar 的 URL 会缓存,今天下午我百思不得其解的小黄锁问题就是由于早先生成的 HTTP URL 被缓存了。清除缓存步骤:

  1. sudo -u git -i
  2. cd gitlab
  3. RAILS_ENV=production bundle exec rake cache:clear

重启 gitlab 服务需要比较长的时间,虽然 sudo service gitlab restart 会立即显示成功,但事实上还是原来的 sidekiq 和 unicorn 在运行。可以用 sudo service gitlab status 和 pstree -pa 来查看 gitlab 服务的状态。如果发现“残余进程”,要 kill 掉再 sudo service gitlab start。

如果 gitlab 服务起不来,可以查看 ~git/gitlab/log/ 里的日志文件。

注意,从 StartSSL 申请的免费证书是 intermediate CA 签发的,为了在 git clone 和 curl 中正常使用,需要 cat intermediate.CA.crt >> gitlab.crt,把自己的证书和 intermediate CA 证书连接在一起。

Blog 再次发生 OOM Kill

9月15日晚上23时许,USTC Blog 服务再次发生 OOM Kill,数据库进程被杀掉,导致 blog 首页显示 “0 users”,无法登录,用户博客也无法显示。

事实上,早在21:30,21:50,22:15,就已三次发生 OOM Kill。不知道为什么,monit 没有发送报警邮件。监控基本服务可用性的 servmon 由于依赖数据库,也挂掉了。因此直到16日上午 zguangyu 给 boj 打电话这事才被知道。解决方法很简单,启动 mysqld 服务,重启 php-sandbox 服务。

统计 nginx access log,每分钟的 HTTP 访问数大多在 100 以下,没有 DDoS 攻击的迹象。不过一个奇特的 IP 202.194.3.59(山东大学)很奇怪,它大量访问形如 http://lttt.blog.ustc.edu.cn/feed/p2.ajax?p2ajax=true&action=get_latest_posts&load_time=2013-09-13%2002:47:50&frontpage=0&vp=&vp=2199&_=1378861410811/wp-admin/install.php 的URL,结果是一个空页面。分析结果出来后再更新。

由于 blog 近期多次发生 OOM Kill,我们做了如下调整:

  1. 停止 blog 上占用资源较多的 BIND9 服务,换用轻量级的 DNSmasq(其实相当于把负载转移到学校DNS上了)。
  2. 调整 php-fpm.conf,最大 PHP 线程数 max_children 由 200 降低到 50。
  3. 将 servmon HTTP 监控服务迁移到 lug 服务器上。

BugFix: Blog 升级、安装插件期间访问出错

USTC Blog 升级、安装插件期间,访问首页会提示出错。原因是 WordPress 进行升级、安装插件等操作时,会生成 .maintenance 文件,wp-includes/load.php 会试图 include 这个文件以检查其存在性。为了保证安全,USTC Blog 禁止 include 非 .php 后缀的文件。因此我们将 .maintenance 修改成 .maintenance.php 以绕过此限制。相关 commit:

http://gitlab.lug.ustc.edu.cn/ustc-blog/wordpress/commit/4537059a91aea17a6d85151293b6a35c668fa6ff

感谢 Moqi Lee 同学的 bug 反馈。

9月7日 blog 数据库 OOM kill

9月7日16:30,blog 数据库(mysqld)被 OOM kill。故障在 19:00 左右恢复。

恢复方法是先后重启 mysql 和 php-sandbox 服务。php-sandbox 有一个已知的 bug,mysql 重启后不会自动重连,因此 mysql 重启后必须重启 php-sandbox 服务。

本次故障是内存溢出引起的,当天 14:30 已经收到 monit 的邮件报警,但当时唯一接收报警的 boj 没打开数据流量,没收到邮件,酿成服务中断的悲剧。我们今后将让服务器维护小组的更多人收到报警。

PXE 支持 IPv6

pxe.ustc.edu.cn 长久以来不支持 IPv6 的问题于今天被解决。

之前 /etc/network/interfaces 中已配置 2001:da8:d800:931::94 这个地址,不过没有生效。 现在已绑定到网卡上了。

/etc/lighttpd/lighttpd.conf 中增加了一行:
server.use-ipv6 = “enable”

之后 /etc/init.d/lighttpd restart 了。

一共就这些操作。

— tux, USTC PXE Maintainer

blog 启用 monit 监控报警

由于前些天 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 错误。我们尚未找到相关技术资料。

2013-08-31

目前 mirrors-base(Xen Domain0)仍然在正常运行,因其根文件系统在 sdc 上。mirrors-main 连同 LXC 虚拟机系统的根分区连同那块硬盘,已经消失了。我们怀疑并不是硬盘损坏,因为两块硬盘是硬 RAID1,同时损坏的概率微乎其微;怀疑是 RAID 卡损坏,或者主板上接线松了。

本次故障由于涉及硬件问题,恢复时间未知。我们对此带来的不便深表歉意。