USTC Freeshell 走进新时代

USTC freeshell

虽然有些标题党,我们还是高兴地宣布 USTC Freeshell 升级了:

  • 每人可以注册多个虚拟机
  • 支持三级域名
  • 修复在线管理功能,支持在线重置密码

Multiple Shells

一个 freeshell 做多种事情,不符合隔离的原则。今天,每个科大邮箱都可以注册至多5个 freeshell。不同的 freeshell 可以设置不同的密码,登录时会默认进入密码匹配的 freeshell 管理界面,也可以随时切换到其他的 freeshell(如下图)。

freeshell-select

Subdomain

blog.ustc.edu.cn 支持三级域名,freeshell 今天起也可以了。每个 freeshell 都可以设置一个三级域名作为 HTTP Proxy,这样在 freeshell 上建的小站就能摆上台面了~

freeshell-admin-2

喜欢折腾的同学可能会发现,不存在的域名是公益 404 页面,让我们一起为他们祈福。

Start / Shutdown / Reboot / Reset Password

很抱歉地跟大家说,自从上次 Freeshell 控制节点与运算节点间 API 升级后,下面这几个 Start / Shutdown / Reboot 按钮就一直是坏的,我也没发现。这次不仅修好了已有的 bug,还在用户体验上做了些许改进(Processing 提示,邮件提醒)。

freeshell-admin-1

更重要的是,Freeshell 增加了千呼万唤的重置 root 密码功能。重置后的 root 密码会通过邮件发送。如果邮件被丢进了垃圾箱,请把 noreply@blog.ustc.edu.cn 加入联系人。

Let The Source Be With You

Freeshell 的代码是开源的,注册登录 USTC GitLab 即可:https://gitgeek.net/boj/freeshell

LUG 网络服务将使用 freeshell 作为 testbed,freeshell 也会在今后的 LUG 活动中持续推广。Enjoy freeshell at freeshell.ustc.edu.cn, 欢迎报 bug!

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 卡损坏,或者主板上接线松了。

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