科大博客修复无法安装插件、主题等问题

2016年9月,我们遇到了两次利用插件漏洞的恶意代码上传事件,一次是被挂黑页、被网监查了水表,一次是滥发垃圾邮件用完了 LUG 的邮件配额。第二次恶意代码上传事件后,我们修改 PHP 解释器代码,禁止了 .php 扩展名文件的写入和非 .php 扩展名文件的执行。这个限制的后果是无法安装或升级插件、主题。非常抱歉此问题给您带来的麻烦。

现在修改了 PHP 解释器中的文件访问限制,使得通过 WordPress 后台正常的上传、更新、编辑插件和主题不会受到影响。禁止插件和主题自己修改代码,也就是利用插件漏洞的恶意代码上传将不能得逞(当然部分生成 PHP 模板的插件可能无法使用)。

具体文件访问限制策略如下:

  1. 非 .php 扩展名的文件禁止执行(与之前相同)
  2. WordPress 用户上传目录内的文件禁止执行(上传目录相对路径可在 php.ini 里配置,用户不能修改)
  3. .php 扩展名的文件,只有受信目录内的代码才能写入(受信目录列表可在 php.ini 里配置,用户不能修改)。具体方法是判断 php 调用栈上的每个文件是否都在受信目录内,只要有一个不在就报错。目前受信目录是用户间共享、用户不可修改的 WordPress 核心代码。

此外,之前 blog 注册激活后需要升级数据库。这是因为之前安装 blog 的过程是直接导入一个数据库模板,WordPress 4.6.1 检测到数据库表结构的变化,就提示需要升级。现在修改了安装过程,直接调用 WordPress 的数据库安装函数,装好的 blog 就是最新版本的数据库结构。与 WordPress 原版安装程序略有不同,您将不会收到 WordPress 自动发送的安装成功邮件,因为其中包含明文密码,我们把这个发邮件的过程去掉了。

如果您注册新博客后发现问题,或发现插件、主题无法安装、升级,欢迎报 bug。感谢您对科大博客的支持。

USTC Blog 可以使用 Let’s Encrypt 证书了

Let’s Encrypt 是一个自由、免费、自动化的 SSL 证书颁发机构。只要有域名的控制权和一个 Web 服务器,就能申请到可信的 SSL 证书,给网站挂上小绿锁。除非你想要泛域名证书(即 *.example.com 这种)或者想要 EV 认证(绿色地址栏),Let’s Encrypt 颁发的证书不仅不需要花钱,整个申请过程还是完全脚本化的。

USTC Blog 今天针对第三方域名,增加了自动申请和续期 Let’s Encrypt 证书的功能。如果您希望给博客绑定第三方域名,将不再需要自己申请和上传证书及私钥,而可以让我们代为自动申请。

Let’s Encrypt 需要验证域名的所有者,因此请首先把域名 CNAME 到 p.blog.ustc.edu.cn,并等待一段时间以便 DNS 记录更新。然后登录 WordPress 后台,设置 => 常规,勾选 “Apply, install and renew Let’s Encrypt SSL certificate automatically”。

勾选之后下面的上传 SSL 证书部分会自动收起。

保存更改,等待十秒左右,Let’s Encrypt 证书应该就申请成功并安装到您的博客上了。随后您可以通过 https://your-domain.com 访问博客了。

如果申请失败,例如域名解析尚未生效(Let’s Encrypt 需要通过域名 HTTP 访问到 USTC Blog 上的验证文件),或者您的域名所申请 Let’s Encrypt 证书的数量超过 Let’s Encrypt 方面的限制,请稍候再试。

证书的有效期为三个月。到期前一段时间,USTC Blog 会自动续期。

由于 Let’s Encrypt 限制每个域名每个月不能申请超过 100 张证书,且不支持泛域名证书,我们目前无法为 *.blog.ustc.edu.cn 使用 Let’s Encrypt 证书,而是仍然使用 StartSSL 颁发的 OV 泛域名证书(*.blog.ustc.edu.cn)。

如果您在使用 Let’s Encrypt 过程中遇到任何问题,欢迎联系我们

请不要把 Freeshell 上的 Debian 升级到 Jessie

2015 年 4 月 25 日,Debian 8 (Jessie) 发布,使用的是 Linux 3.16 内核和 systemd 2.15 服务管理系统(取代 sysvinit)。由于 Freeshell 使用了 OpenVZ,而 OpenVZ 没有跟着内核主线走,一直停留在 RHEL 6 所用的 Linux 2.6.32 上。该老旧内核不支持 systemd 2.12 及以上版本。

如果您 Freeshell 上的 Debian 通过 dist-upgrade 升级到了 Jessie,将无法启动(启动过程中会卡住)。尽管我们可以通过修改 systemd 源码的方式让 Jessie 跑起来,但可能引来其他问题,毕竟如此新的系统跑在如此老的内核上不放心。

如果您不慎升级了 Debian 到 Jessie,请使用 Freeshell 控制面板的 “Reinstall System” 功能重装回 Debian wheezy。很抱歉您暂时不能使用新版 Debian,希望您能理解。

今天 OpenVZ 官方发布了基于 RHEL 7 的 3.10 内核的 OpenVZ 内核(邮件列表源码仓库),让我们看到了一线曙光(之前一直以为 OpenVZ 快死了,原来是闷声发大财了大半年)。但 OpenVZ 尚未发布与 3.10 内核配套的用户态管理工具。等到管理工具发布了,Freeshell 就可以升级到 3.10 内核,包括 Debian Jessie 在内的大多数发行版应该都可以跑起来了。

GitLab 修复 HTTP push 失败问题

GitLab 通过 HTTPS 做包含大量内容的 push 时会失败,提示 HTTP 413 Request Entity Too Large。这是由于 GitLab 服务器的 nginx 配置了 client_max_body_size 100m,限制了 POST 请求不能超过 100 MB。目前该限制已经增加到 2 GB,而 LUG GitLab 限制的单个仓库最大为 2 GB,因此不再会出现由于 nginx 的限制而 push 失败的问题了。

GitLab 修复移动线路 IP 无法访问问题

4 月 12 日 GitLab 添加移动线路 IP 之后,由于路由表配置错误,校外用户无法通过该新增 IP 访问 GitLab。今天才从 DNSPod 的报警中发现这一问题。非常抱歉此问题给您带来的不便。

问题原因是 GitLab 服务器挂上了 LUG VPN。挂上 VPN 的机器要想仍然可以从外网访问,需要设置策略路由。而 GitLab 服务器新增移动线路 IP 地址之后,没有更新策略路由规则。

这个问题之所以没有被发现,是因为校内可以正常访问 GitLab 的移动 IP。为了优化校内访问,我们对校内 IP 不走 VPN,如下路由表所示。从移动 IP 出来的回复包尽管走错了出口(本来应该走移动出口,但现在走了电信出口),但仍然能被正确路由。发往校外 IP 的回复包则会根据 default 那条路由规则,发送到 VPN 服务器,这就不可能到达目的地了。

boj@gitlab:~$ ip route
default dev tun0  scope link
default via 202.141.160.126 dev eth0  metric 10
10.1.14.0/24 dev tun0  proto kernel  scope link  src 10.1.14.7
10.38.0.0/16 via 202.141.160.126 dev eth0
114.214.160.0/19 via 202.141.160.126 dev eth0
114.214.192.0/18 via 202.141.160.126 dev eth0
121.255.0.0/16 via 202.141.160.126 dev eth0
202.38.64.0/19 via 202.141.160.126 dev eth0
202.141.160.0/25 dev eth0  proto kernel  scope link  src 202.141.160.98
202.141.160.0/20 via 202.141.160.126 dev eth0
202.141.176.0/25 dev eth1  proto kernel  scope link  src 202.141.176.98
202.141.176.0/20 via 202.141.160.126 dev eth0
210.45.64.0/20 via 202.141.160.126 dev eth0
210.45.112.0/20 via 202.141.160.126 dev eth0
210.72.22.0/24 via 202.141.160.126 dev eth0
211.86.144.0/20 via 202.141.160.126 dev eth0
218.22.21.0/27 via 202.141.160.126 dev eth0
218.104.71.160/28 via 202.141.160.126 dev eth0
222.195.64.0/19 via 202.141.160.126 dev eth0

解决方法是添加策略路由规则:

ip route replace 202.141.176.0/25 dev eth1 table 1001
ip route replace default via 202.141.176.126 table 1001
ip rule add from 202.141.176.98 lookup 1001

Blog Google Fonts 不再需要代理

去年由于谷歌字体被墙,我们提供了 Google Fonts 代理服务。今年早些时候,Google 把字体服务解析到了国内的服务器,不再需要代理了。

现对 USTC Blog 的 fonts.googleapis.comfonts.gstatic.com 两个域名取消强制代理。其余的域名,如 ajax.googleapis.comthemes.googleusercontent.com,IP 地址仍然在国外,因此仍然实施强制代理。

.lug.ustc.edu.cn 上的谷歌字体代理服务将继续运行,有需要的用户可以继续使用。

GitLab 添加移动线路出口

为加速移动、国外和部分教育网用户访问科大 GitLab,今天我们请 jameszhang 给 GitLab 添加了移动线路出口,IP 地址为 202.141.176.98。

目前移动、国外和部分联通用户访问 gitlab.lug.ustc.edu.cn 使用新增的移动线路出口,其余用户仍然使用电信出口。git.ustclug.org 则会同时返回两个 IP 地址,客户端会随机连接其中一个。

Freeshell 3月31日晚宕机说明

2015 年 3 月 31 日下午开始,一个用户在 7 台 Freeshell 上同时运行科学计算程序,导致负载飙升,56 个核的集群负载超过 500,到傍晚时分甚至超过 1000,一度导致部分节点上的 freeshell 无法连接。

21 时 49 分,承载着外部存储的 1 号节点不堪重负而崩溃,所有运行在外部存储上的 freeshell 随之卡死。

21 时 59 分,我们通过 IPMI 重启了 1 号节点。

23 时 57 分,1 号节点上的 freeshell 全部启动完成。(是的,你没看错,一个节点上的 241 个 freeshell 需要两小时才能启动完毕。这个启动过程已经是并行的,磁盘 I/O 一直是满的。因为上次系统崩溃时各虚拟机的磁盘配额处于不一致状态,重启后需要扫描所有文件来重新初始化磁盘配额。如果上次物理节点是正常关机的,大概 30 分钟就启动完了,而且大多数 freeshell 会恢复到关机前的状态)

4 月 1 日 0 时 17 分,我们启动了 1 号节点上的 NFS 服务,其他节点上的虚拟机逐渐恢复。但由于存储中断时间过长,部分虚拟机已经被关闭,这些虚拟机需要用户在控制面板里手动启动。(由于 1 号节点上 freeshell 初始化过程中开启 NFS,可能引发未知原因的 kernel panic,我们不得不让 1 号节点的 freeshell 启动完再开启 NFS)

非常抱歉这次故障给您带来的不便。

Freeshell 关于禁止科学计算的公告

随着 Freeshell 用户数量的增加和用户活跃度的提升,Freeshell 目前面临着严峻的资源短缺问题,经常由于负载过高导致服务中断。在邮件列表中讨论后,管理团队一致认为应当让 Freeshell 回归 Linux 实验平台的本质,禁止科学计算等占用大量 CPU 或内存资源的程序,以保证大多数用户的正常使用。

Freeshell 用户规则 已经更新并添加了如下条款:

用户不得利用 Freeshell 进行以下行为:……
c. 运行科学计算、分布式计算、网格计算等占用大量 CPU 或内存的程序;

需要进行科学计算的用户,请利用科大云和科大超算中心的资源。科大云(cloud.ustc.edu.cn)默认配额是双核 2G 内存,如果需要更多计算资源,可以另行申请;科大超算中心拥有用于科学计算的专业集群,可以实验室的名义申请使用。Freeshell 作为 Linux 实验平台,没有能力支持需要大量资源的科学计算服务,希望您能理解。

即日起,我们将采取技术措施来限制科学计算等占用大量 CPU 或内存资源的程序。限制方法包括但不限于降低进程优先级、暂停进程运行、杀死进程。因此带来的不便,我们深表歉意。

这不是愚人节玩笑,谢谢。