MediaWiki 的安全真让人头疼啊

更换了服务器之后，我着手把旧的站点上的东西都转移过来。从共享空间换到了 VPS，可以操控的东西更多了。

Blog 的事情我之前说过了，由 Movable Type 换到了 WordPress。昨天我转移了 wiki。

我之前对 MoinMoin 挺好奇的，从来没有在服务器上安装成功过，只用过它的单机版本。单机版本不是我想要的。我想要的是一个可以让我随地都可以阅读、编辑的地方，这也是我安装 wiki 的理由。

我过去在 site5 主机上安装的是 MediaWiki，原因是它很方便。现在的国外共享空间，安装 PHP 程序都非常容易。不过对于 MoinMoin 这样的 Python 来说就不是那么的方便了。我过去在 site5 上尝试了几次，都没有成功。我过去还安装试用过一些其它的 wiki 程序，像 PmWiki 之类的，不过我都觉得它们比较一般，最后没有选择它们。不过我倒是对 UseMod Wiki 这样的程序印象不错，我还用它打理了一阵子首页。

MediaWiki 是专门为了 Wikipedia 开发的。Wikipedia 的口号是“自由的百科全书”，“自由”是基调，因此 MediaWiki 对于权限控制做的非常不足。MoinMoin 让我欣赏的一点是，它可以控制哪些条目是公开的，哪些不是；而 MediaWiki 就不行，而且是刻意这样做的。我印象里在 MediaWiki 的一份文档里看到了解释，说这与开发者的价值观不符，如果你要这样做，请不要使用 MediaWiki。不过毕竟是安装起来方便，我还是在 site5 的主机上安装了它。

这次我换了 VPS，就想试试 MoinMoin。我用的 apt-get 来安装了软件包，但我用的操作系统是 Debian 5.0，Debian 的软件包实在是太老旧了，里面的 MoinMoin 的版本也非常的低。不过我过去从来没有用过 MoinMoin，所以想先试着安装一下看看。不过我折腾了一个晚上，没有成功，最后就放弃了，今天又安装了 MediaWiki。

过去用 MediaWiki，最让我受不了的一点就是它的默认安全性。默认情况下，似乎谁都可以修改页面，我估计是有人开发了专门针对 MediaWiki 的垃圾发送器，我辛辛苦苦维护的页面，经常就被一些人给替换成了垃圾链接，广告的色情的都有。虽然 wiki 有历史记录可以回滚，但一次两次还行，次数多了我也厌烦了，所以我到后来都不大愿意去自己的 wiki 了，眼不见心不烦。

这次安装 MediaWiki，我下定决心，首先要解决的就是任何人都可以编辑的问题。通过查询 MediaWiki 的 FAQ， 我在这一节中找到了解决办法。按照说明，我禁止除了 sysop 之外的用户编辑页面、禁止匿名用户注册。我想应该解决了问题，不过我突然在修改列表里发现了又有人发了垃圾，让我的心情一下子坏了不少。不过后来我通过观察，看到似乎之后就没有了垃圾了，让我稍微放了一下心，不过我仍然在观察。

我忘了当初是怎么回事了，我没有导出我过去的数据，只备份了我过去的数据库。我之前使用的是 SQLite3 作为数据库引擎的，不过这次自己用 VPS 之后，对 MySQL 的操作更熟练了一些了，于是就把 wiki 的数据库同样放在 MySQL 里。我不确定 SQLite dump 出来的 SQL 能不能直接导入到 MySQL 之中，不过我也不希望这么做，因为之前实在是有太多的垃圾了，我不想再把它们导入。我从 Google 搜索的 cache 中找到了一些页面的备份，然后结合我 dump 出来的旧的数据库的 SQL，再手动的把过去的页面再重新输入回去吧。

这次为了安装 MediaWiki，我还装上了 Memcached。按理说我的 VPS 只有 80MB 内存，本身就比较吃紧了，不过我还是想看看这样做能够提升 MediaWiki 到底多少的效率。因为内存少，所以我没有使用默认的开启 64MB 缓存的选项，而是设定为了 16MB。这样最后的结果是将近 79MB。不过让我挺纳闷的是无论是 Memcached 还是 php-cgi，都不是严格按照我设定的参数走的。比如说我给每个 php-cgi 限定的 memory_limit 是 16MB，不过我用 top 察看了之后发现还是有写进程达到了 20MB 左右。这样导致了我实际占用的内存超过了 80MB，不过有了 burstable 的内存问题不大。虽然我还不了解 VPS 供应商对于这种情况下的政策是怎么考虑的。

Memcached 安装了之后，除了 MediaWiki，我同样也给 WordPress 安装了相应的插件，打开了 Memcached 功能，效果还没有完全体现。既然已经做了数据库缓存了，我顺便研究了一下 WP Super Cache 插件，做了一个 HTML 静态缓存，经过 Preload 之后 WordPress 就跟 Movable Type 完全一样了。我的 web 服务器是 Lighttpd，不支持 .htaccess 文件。我是按照这篇文章的说明，安装了 Lighttpd 的 magnet 模块，通过 Lua 脚本来操作 URL Rewrite。之前我还担心 Lua 脚本会不会影响效率，不过我发现只有在第一次访问的时候会慢一些，之后完全没有影响。而且那篇文章里也说了：

You may be worried that having a huge LUA script like that running on every request is going to reduce the effectiveness of wp-super-cache or WordPress in general? Don’t worry, Lighttpd caches the compiled script, it’s pretty swift.

打开了 Preload 之后，我确实看到了 WP Super Cache 生成了所有页面的静态文件，数目高达 500 多张，普通的和 gz 压缩的都有。不过这个插件的 Preload 速度和 Movable Type 重新发布整个站点没法比，但好处是 CPU 消耗很低。