LUG 服务器黑板报迁回 servers.blog.ustc.edu.cn

2015 年 1 月 4 日 把非 USTC 域名迁移到国外代理 后,很多用户反映 servers.ustclug.org 无法访问。

阿里测 测试,通过国外代理访问的 https://servers.ustclug.org 有 55% 的地区和运营商无法访问,http://servers.ustclug.org 有 48% 的地区和运营商无法访问。

现将 LUG 服务器黑板报的默认域名从 servers.ustclug.org 改回 servers.blog.ustc.edu.cn。两个域名仍然都可以访问。

学校移动线路网络中断

2014年5月16日凌晨 03:10,学校移动线路突然中断。此故障导致国内移动线路和国外无法访问科大 LUG 各项网络服务,同时 freeshell、blog 和 LUG VPN 无法访问国内移动线路和国外,LUG Public DNS 服务运行缓慢。目前尚未修复。

Update(05:30): 由于学校移动出口仍然没有恢复,{mirrors,blog,freeshell}.ustc.edu.cn 暂停移动线路 IP 解析,切换到电信线路。LUG VPN 和 Public DNS 改用电信线路出国,服务恢复。

Update(12:50):运营商方面已于上午 9 时许修复路由问题,将 LUG 的 DNS 和路由恢复到原来状态。

LUG 所有服务器升级 OpenSSL 以修复 Heartbleed 漏洞

OpenSSL 爆出重大漏洞(CVE-2014-0160),由于 TLS heartbeat extension 中没有检查长度字段与实际长度是否相符,可以溢出缓冲区,获取至多 64 KB 的服务器内存内容,包含用户请求、SSL 证书等敏感信息。此漏洞影响 OpenSSL 1.0.1a 至 1.0.1f,Debian wheezy 包含在其中。LUG 所有提供 HTTPS 的服务器都从 Debian security 源升级了 OpenSSL 并重启了相关服务。

升级过程中,发现部分服务器的 sudoers 存在问题(没有设置 sudo PATH),部分服务器的 /etc/apt/sources.list 存在问题(没有包含 security 源),一并予以解决。

漏洞技术细节详解

修复 Ganglia 主机名漂移问题

昨天重启 freeshell 之后,Ganglia monitor (gmond) UDP channel 绑定的网卡漂移到了 OpenVPN tunnel (tun0) 上,导致收到的数据查不到主机名,在 Ganglia webfrontend 中显示出来的是 10.8.0.x 的 IP 地址,跟原来的统计数据也对不上了。

解决方法:修改 gmond.conf,在 udp_send_channel 中增加了 bind_hostname = yes,在 udp_recv_channel 中增加了 mcast_if = eth0。
配置文件 diff

另外发现早先 gmond 没有限制 XML 查询的来源 IP,任何人都可以通过 TCP 8661 端口查询主机状态,这可能是一个安全隐患,因此加入了 访问控制列表 使得只有 status.lug.ustc.edu.cn 可以收集主机状态。

顺便修复了 mirrors 上 gmond 端口号配置错误导致 gmetad 收不到数据的问题。

学校网络故障导致 LUG 服务短暂中断

今天(2014年3月20日)下午 16 时,由于学校网络故障,电信出口中断约 10 分钟,移动出口也受到短暂影响。LUG 所有网络服务均受到此次事件的影响。据 BBS ustcnet 版,是教学行政楼内两台机器大量广播包侵袭校园网络核心设备,造成全校网络故障。

http://bbs2.ustc.edu.cn/cgi/bbstcon?board=USTCnet&file=M.1395306954.A

科大 LUG 服务器列表

网络中心机房

  • mirrors (mirrors.ustc.edu.cn): 202.38.95.110, 202.141.160.110, 202.141.176.110, 2001:da8:d800:95::110
  • blog (blog.ustc.edu.cn, freeshell.ustc.edu.cn, archive.lug.ustc.edu.cn, 邮件 SMTP 服务器): 202.141.160.99, 202.141.176.99, 2001:da8:d800:f001::99
  • gitlab (gitlab.lug.ustc.edu.cn): 202.141.160.98, 2001:da8:d800:f001:250:56ff:fe9f:54
  • dns (dns.lug.ustc.edu.cn, 权威 DNS): 202.141.160.97, 2001:da8:d800:f001::5353
  • ldap (ldap.lug.ustc.edu.cn): 202.141.160.111, 202.141.176.111, 2001:da8:d800:f001:202:141:160:111
  • lug-vpn (lug-vpn.lug.ustc.edu.cn, 防污染公共 DNS): 202.141.160.95, 202.141.176.95, 2001:da8:d800:f001:202:141:160:95

配置:

  • mirrors: 物理服务器,16 核 Intel(R) Xeon(R) CPU E5620 @ 2.40GHz,16 G 内存,12 块 2 T 硬盘 (RAID 1 后可用空间 12 T),26 T 磁盘阵列 (RAID 6),256 G SSD 做缓存。
  • blog: 网络中心虚拟机,8 核 Intel(R) Xeon(R) CPU X5650 @ 2.67GHz,100 G 磁盘,8 G 内存。
  • gitlab: 网络中心虚拟机,单核(CPU 型号与 blog 相同),200 G 磁盘,2 G 内存。
  • dns, ldap, lug-vpn: 都是网络中心虚拟机,单核,10 G 磁盘,1 G 内存。没有放在 freeshell 上是担心少年班学院网络不稳定。

图书馆机房

  • lug (lug.ustc.edu.cn): 202.141.162.123, 2001:da8:d800:22::123
  • pxe (pxe.ustc.edu.cn): 202.38.93.94, 2001:da8:d800:931::94
  • oldpxe(老 PXE 服务器): 202.38.93.95
  • shinobu: 2001:da8:d800:931:0:30:20:1
  • donut: 2001:da8:d800:931:0:30:20:2

配置:

  • lug: 物理服务器,4 核 * Intel Core 2 @2.66GHz,2 G 内存,1 T、2 T、4 T SATA 硬盘各一块。
  • pxe: 物理服务器
  • oldpxe: 物理服务器
  • shinobu, donut: 捐赠的物理服务器

少年班学院机房

以下 7 台机器均为物理服务器,在同一个机架上,作为 freeshell 运行节点,仅限校内访问。

  • s1.freeshell.ustc.edu.cn
  • s2.freeshell.ustc.edu.cn
  • s3.freeshell.ustc.edu.cn
  • s4.freeshell.ustc.edu.cn
  • s5.freeshell.ustc.edu.cn
  • s6.freeshell.ustc.edu.cn
  • s7.freeshell.ustc.edu.cn

配置:8 核 Xeon E5450 @ 3.00GHz,16 G 内存(3号节点只有 12 G),300 G SAS 硬盘。1 号节点有一块 2 T SATA 硬盘作为外部磁盘。

  • backup: 202.38.70.210 (1.5T 硬盘用于备份和 docker 测试)

Ganglia 服务器状态监控

https://status.lug.ustc.edu.cn/

3月8日早晨机房电信线路短暂故障

3月8日凌晨 5:15,LUG 在网络中心机房的电信线路开始出现异常高延迟。5:25 至 5:30,电信线路彻底中断,连校内少年班学院机器都连不上,所有 LUG 服务均受影响。但移动和教育网线路正常。6:00 至 6:15、7:00 至 7:05、8:25 至 8:30,电信线路又出现了中断。

我们发现机房内部出现了至今(16:00)未消除的异常高延迟,而且这个延迟不稳定。

3月8日6时至15时从 mirrors ping 三个默认网关的延迟(单位:毫秒,下同):

Capture

6时至7时(一个小时的时间)ping 三个默认网关的延迟:

Capture

上面这张图将 0~100 毫秒部分放大:

Capture1

7时至8时(一个小时的时间)ping 三个默认网关的延迟:

Capture2

可以发现这些延迟有一定的规律性,而且极端高延迟几乎是在三条线路同时出现,因此猜测是机房网络配置问题或者有网络攻击。

ping 原始数据下载(3月8日6时至15时,每秒一个点,单位为毫秒):

注:3月8日下午 jameszhang 回复,“06:00- 11:00 左右核心交换机(所有网关都是它)的CPU利用率持续较高,可能是这个原因引起的。”