Freeshell 修复不同物理节点间访问缓慢问题

由于路由策略配置不当,freeshell 不同物理节点之间 IPv6 访问缓慢(1 MB/s 左右),且有一定的丢包率,现已修复。非常抱歉。

原因是配置策略路由时,所有从 eth0 进来的连接的出站方向包都是 via $GATEWAY,这对少院以外是正确的,但在少院内部(如 freeshell 各物理节点间互相访问),本来应该直接发到局域网内目的主机的,但 via $GATEWAY 就发到了网关。正常情况下,网关的三层转发逻辑应该能正常转发这样的包,但少院这个网关比较奇怪,既不是完全禁止,又不是完全放行。总之,这个问题算是修复了。

Gitlab升级至7.1

本次更新历时49分钟,服务共中断17分钟。

小插曲:

今天苏州研究院提前清人,没升级完就被“赶出”实验室了,只好找了个附近的麦当劳继续升级,直到0:48分才全部搞完。

一开始使用官方提供的自动升级脚本,可能由于网络不稳定,导致gems更新失败,升级脚本被中断。只好手动切换到科大源完成剩余的更新步骤,预编译输出不太正常,但自检显示没有错误。如果您在使用过程中发现问题,请随时反馈(lug#ustc.edu.cn)。

7.1主要特性:

  • 全新的登陆界面
  • 删除observers
  • 评论中使用@all,向所有人发出提醒
  • 增强代码高亮功能,添加对Go, Clojure, Erlang等语言的支持
  • webhook功能提升
  • 其他UI提升
  • 其他逻辑改进

Freeshell 支持 Archlinux

@huzuyi 制作了可以在 freeshell 上正常启动的 Archlinux 镜像,在注册或重装系统时,发行版可以选择 “Archlinux 2014-07-27”。

Freeshell 之前不能启动最新版 Archlinux 的原因是 systemd 2.12+ 使用了 clock_gettime 系统调用的 CLOCK_BOOTTIME 参数,而这个参数是 2.6.39+ 内核才支持的(freeshell 主机目前是基于 2.6.32 的内核)。因此把 systemd 固定在了 2.11 版本。升级系统的时候会有如下所示的 warning,请注意不要强制升级 systemd,否则系统将无法启动。

[[email protected] ~]# pacman -Syu
:: Synchronizing package databases...
 core is up to date
 extra is up to date
 community is up to date
 archlinuxcn is up to date
:: Starting full system upgrade...
warning: systemd: ignoring package upgrade (211-1 => 215-4)
warning: systemd-sysvcompat: ignoring package upgrade (211-1 => 215-4)
 there is nothing to do

如果您在使用 Archlinux 过程中有任何问题,欢迎联系 support (AT) freeshell.ustc.edu.cn。

USTC blog 强制对 Google 字体加速

自从 Google 抽风之后,WordPress 默认的 Google 字体也就跟着抽风了,表现就是 blog 页面需要 “花很长时间才能打开”。之前我们通过修改 WordPress 源码的方式,将 Google Fonts “劫持” 到 LUG 搭建的代理(传送门),但 WordPress 主题升级之后修改就被覆盖了。因此采用了 @zsj 的建议,对 WordPress 输出的内容进行文本替换,将 Google 字体 URL 强制替换为 LUG 搭建的代理。

技术细节:在 nginx 服务器上,把 WordPress 输出的 MIME type 为 text/html text/css text/javascript text/xml 的内容中的 URL 做如下字符串替换:(Updated 2014-08-05)

fonts.googleapis.com         fonts.lug.ustc.edu.cn
ajax.googleapis.com          ajax.lug.ustc.edu.cn
themes.googleusercontent.com google-themes.lug.ustc.edu.cn
fonts.gstatic.com            fonts-gstatic.lug.ustc.edu.cn

某些机器访问 freeshell IPv4 SSH 卡死问题

问题一般是由于您到 freeshell 链路上的网络设备(包括路由器、NAT 等)没有正确转发 ICMP Error (Packet Too Big) 包。要验证这个问题,请用下列 ssh -v 命令验证,如果最后两行输出与下面的相同,并且卡住了,则一般是这种问题。还可以用 wireshark 抓包,如果没有收到 ICMP Destination Unreachable 包,则确定是网络问题。

$ ssh -v -p 30xxx [email protected]
OpenSSH_6.6.1, OpenSSL 1.0.1h 5 Jun 2014
debug1: Connecting to ssh.freeshell.ustc.edu.cn [202.141.176.99] port 30xxx.
debug1: Connection established.
...
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY

问题原因是 ssh.freeshell.ustc.edu.cn 与 freeshell 计算节点之间使用了 GRE tunnel,载荷 MTU 为 1476 字节,略小于以太网通常的 MTU 1500。ssh 密钥交换阶段一次发送的数据一般大于 1500 字节,因此至少填满了一个 MTU,这个长为 1500 字节的包发到 ssh.freeshell.ustc.edu.cn 会被丢弃,并返回一个 ICMP Error (Packet Too Big) 消息,其中包含了可用 MTU 1476。SSH 客户端所在主机收到 ICMP 消息后,会重新对数据拆分为 1476 字节大小的分片并发送。这个 MTU 会在路由表中缓存一段时间,因此短时间内第二次连接 freeshell IPv4 会使用正确的分片大小,不会收到 ICMP Error 消息。

遇有此种问题,请联系您的运营商解决。NAT 设备转发 ICMP Error 包是 RFC 规范的要求

如果想临时解决此问题,可以修改网卡的链路 MTU 为 1476,例如 ifconfig eth0 mtu 1476。请注意网络重新连接后 MTU 设置会恢复原状。

Update (2014-07-31): 此问题已解决。我们在 blog 主机上添加了 iptables -A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu 以修改用户所发起连接的 MSS(Max Segment Size),这样 freeshell 返回的 SYN+ACK 包就会包含用户支持的 MSS 与 blog-freeshell 间的 tunnel 所支持 MSS 的较小者,用户随后发送 SSH 认证数据包时,就会分片成合适大小,从而不会产生 ICMP unreachable 消息。

Freeshell 新功能:虚拟机镜像库

如果你安装了一套开发工具链或者部署了一个系统,希望其他人也能使用,现在可以发布到公开的虚拟机镜像库了。在新建或重装 freeshell 时,不仅可以从标准发行版中选择,还可以从虚拟机共享库中选择。新建或重装出来的 freeshell,除了主机名和 root 密码,跟共享库里的 freeshell 完全相同,妈妈再也不用担心系统配置不一致了!

DeepinScreenshot20140705183646

注册界面选择 Distribution 为 “Create from Gallery”:

DeepinScreenshot20140705182722

重装系统界面选择 Distribution 为 “Create from Gallery”:

DeepinScreenshot20140705182650