成功配置好了 Nginx + uWSGI + MoinMoin

昨天晚上加班前,我去星巴克喝了一杯冰美式,加上周末白天我睡的比较多,因此晚上回家就睡不着了,于是就继续研究 MoinMoin 在 Nginx 上的配置。最终配置成功。

总结:我大概是有段时间没有碰 Linux 服务器了,因此对一些信息提示太不敏感了,完全忽略了错误信息的本意,并且忘记了上网搜索的方法,反而像一个菜鸟一样,照着文档的葫芦画瓢,遇到了和自己实际情况不一样的地方,就束手无策。另一方面,Linux 系统发行版众多,很多发行版有自己的一套工具,这就导致了配置命令的多种多样。加上 Python 和 uWSGI 的配置又比较麻烦,因此网上的文档不能做到面面俱到,实际上这方面的文档比起 WordPress 的配置要少很多,我这次也算是吃了这方面的亏。

我一开始是按照 DigitalOcean 给出的 How To Install MoinMoin with Nginx on Ubuntu 14.04 来一步一步的操作的,一开始比较顺利,直到文档要我执行 sudo start moin 这个命令时,系统提示我找不到 start 命令,我一下子傻掉了,不知道该怎么进行,而且根据我有限的 Linux 经验,我也从没见过一个叫 start 的命令。用 tab completion 得知,系统有一个 start-stop-daemon 命令,我想也许版本不同换成了这个?于是就在周六的下午研究它的命令行参数,走了不少弯路,到最后也没有成功。

之后我还参考过 Nginx 的网站,结果让我更加困惑,只是草草的给了我一小段配置片段,就没有其它任何内容了。我在 Google 上用 Nginx 和 MoinMoin 做关键词搜索,得到的结果和 DigitalOcean 的大同小异,都是在 start 这一步上卡住了。

到了昨天晚上,我决定不按照 DigitalOcean 的文档里来操作,而是先把我在 Linode 上的 MoinMoin 实例复制过来,毕竟到最后还是要转移数据的。为了不影响我目前在 Vultr 服务器上的 WordPress,我在 DigitalOcean 里新建了一个 droplet,专门用来配置 MoinMoin。我重新执行了一下文档里的东西,最后依旧是在 start 这一步上受挫。

我看文档中要求的 moin.conf 文件其实是执行了一个命令,我于是把命令提取出来,很简单,就是 uwsgi <配置文件>。文档中要求的是 .ini 文件。然后我就手工来执行这条命令,没有什么提示。看错误日志,说 bind 这一布发生了权限错误。我很奇怪,明明我是通过 root 来执行的,怎么可能还会有权限不足的情况发生呢?这让我非常苦恼。

结果一直到了今天凌晨两点多也没有弄好,我觉得有些累了,就上床睡觉。躺着睡不着,就看小说,看到大概凌晨五点,天已经开始发亮,我就下了床,继续来研究 uWSGI。

后来我渐渐的走向了正轨,开始看 uWSGI 的官方文档,这个 Managing the uWSGI server 页面的这张表格让我恍然大悟,原来在 Ubuntu < 15.04 的时候,系统默认的是 Upstart,文档中说要用 Upstart 来管理 uWSGI 服务器,而 start 命令想必也来自 Upstart 咯。而我用的是 Debian,还有 Ubuntu 16.04,都开始用 Systemd 来管理服务,因此就没有了 start 命令。

找到了错误的原因,问题就解决了一大半。我研究了一下 uwsgi 程序的命令行参数,把 .ini 的内容用参数表示出来。我发现如果我不用 socket 通信,而是用一个本地服务器端口,就没有问题。我在 8080 端口上执行了 uwsgi 程序,然后通过 IP地址:port 的形式,成功的看到了我的 wiki。虽然因为一些图片路径之类的设置没有经过 Nginx 的配置,所以只有字符没有图形,不过已经证明了 uWSGI 可以这样跑没问题了,一下子给了我极大的信心。

我看了一下 .ini 文件,里面非常明确的说明了 Python 程序的路径,生成用于传递内容的 socket 路径,以及执行时所需要的权限,在这里设置成了 www-data。而我的 socket 文件位于一个 root 权限的文件夹中,这样导致了权限不足的错误。明白了这一点,我把 socket 文件路径换到了 /var/www/moin 中,这个目录的所有者是 www-data,这样问题就解决了。

之后按照文档说的,简单的配置了一下 Nginx,再次打开 wiki,久违的页面就出来了。随后,我在 Vultr 服务器上继续这么操作了一遍,也是很容易就弄好了。这时我的 uWSGI 还是通过命令行执行的,我用 screen 让它在我登出的时候也继续执行。我想先这么用着,等有了精力后再尝试用 Systemd 来管理。不过随后我配置了 Shadowsocks,然后在配置 BBR 的时候,学会了 /etc/rc.local 文件里的命令会在启动后自动执行,于是我把启动 uWSGI 的命令放了进去,问题就解决了。当然,以后我应该还是会配置 Systemd 的。

这时,一方面为了测试 MoinMoin 真的配置好了,一方面也为了把这次的经验记录下来,我在 MoinMoin 上继续完善了 MoinMoinInstall 这个页面,记录了通过 uWSGI 让 MoinMoin 和 Nginx 合作的方法。随后,我研究了一下在 Nginx 里配置 301 转向的方法,然后我的首页也回来了。

随后还有点时间,这次成功配置好了 MoinMoin 也让我振奋,于是我一鼓作气的开始配置 Awstats。结果到了 fastcgi 这一步,我还没有执行,就累的不行了,一看表也到了 7:30,我就收拾收拾上班去了。一夜没睡,年轻时的我就不能撑的太久,现在也是,这个时候虽然我还睡不着,但身体已经疲劳到了极点,开车的时候也有好几次走神。然后一天就萎靡不振,用手指肚搓皮肤和头皮会很舒服,这就是我缺乏休息的表现。

大手术

最近我的网站服务器运行的比较糟糕,特别是博客部分,经常发生 500 错误,有的时候 MySQL 会被 mercy killed,导致 WordPress 无法连接到数据库,博客就挂掉了。

过去我买的比较廉价的 VPS,因此时不时就要捣鼓一下,不过自从我买了 Linode,就比较少的去上 VPS,所以近几年对 VPS 的了解也差了很多。VPS 资源不足的时候,一点资源就要精打细算,因此控制的比较好。后来的 VPS 的内存有了 1GB,想比起过去条件好了许多,我就没有在意控制,甚至编写过一个 Rails 应用,后台用的 MySQL InnoDB 引擎,那时候就觉得内存没有不够的时候。

后来经历过 MySQL 升级,默认的引擎变成了 InnoDB,我旧的配置文件一度导致 MySQL 无法启动。从那之后,我基本上没有再在意过 MySQL 资源优化的问题。这导致的问题就是,MySQL 进程经常被杀死,因为 VPS 的内存被用光了。然后我采用了一些办法,不过收效不大,最后我给博客加上了 WP Super Cache 插件,这样哪怕数据库挂掉也能访问一些页面。然后上周五写了几篇文章,发布的时候竟然出现了 500 错误,这简直不能忍受。刷新了几次发布成功文章后,我就考虑修正一下这个问题。

我想计划是不用 Apache 了,采用 Nginx。我刚用 VPS 的时候,内存很小,才 80M,当时就知道 Nginx 占用资源和 Apache 相比不是一个数量级的。当然 Apache 有它的好处,寿命很久的工程有很多插件,比如 WSGI,我安装 MoinMoin 非常方便,在 Nginx 下就要费一些事。再就是 .htaccess 等功能,Nginx 下使用不同的语法,要改变也很麻烦。不过,现在出现了资源不足的问题,我还是决心做一个尝试。我的 VPS 上目前跑的东西也不多了,主要是一个 WordPress 的博客和一个 MoinMoin 的 wiki,之前自己的 Rails 应用也不跑了,有一个 Awstats 在运行,不过现在看的也不多。

我琢磨了一下,我刚开始用 VPS 的时候,拿 Nginx+php-fpm 跑过 WordPress,经验证过基本上没什么问题,就是 Super Cache 之类的东西配置起来很不方便,实际上我的小站点不用缓存问题也不大。MoinMoin 之前有过不成功的经验,也有过成功的经验,后来入门之后,我发现用 Apache + UWSGI 跑 MoinMoin 还是挺简单的。Nginx 上我不敢确定,不过 Nginx 几年前就很火,相信现在一定有所改进。另外,我对 MoinMoin 这个 wiki 还有其它的考虑,不过没有成熟的记下来,改天在新的文章里再写写。

于是我周五晚上开始,一开始没有继续尝试修改原有的 Linode 服务器,而是从 DigitalOcean 上新建了一个 Droplet,系统还是选 Debian,因为最熟悉。从一开始安装 Nginx 到后来配置 WordPress,DigitalOcean 的帮助文档很全面,非常清晰,我还从中学会了用 rsync 从两个服务器之间同步文件。等我把数据库转移了之后,在新服务器上 WordPress 打不开了,查看错误日志,原来是 Cache 插件的问题。新服务器上没有配置插件,导致了无法显示。然后我尝试了各种其它的方法,一直没有成功。后来又尝试了一下 MoinMoin,我发现这个的文档就有些问题了,进行到了 uwsgi 配置这一步,总会有各种各样莫名其妙的不对,比如说执行了一个命令,start wsgi,而我的机器上并没有 start 这个命令,也许是 Ubuntu 特有的。我最终能做到显示一部分的页面,其它的就没有搞定。这时候时间已经到了周六的凌晨三点多,我坚持不住了,就先去睡觉了。

周六有时间就继续搞,到晚上,我重新在 Vultr 上建立了一个服务,也是用的 Debian,然后还是进行了各种配置,到了最后 WordPress 有很多页面都是 404,弄得我很郁闷,然后重新建立服务,再搞一次,发现我应该是忘记在 Nginx 上加入 index.php 的识别,最后算是弄好了。我一开始尝试导入从原 WordPress 导出的 xml 文件,结果没有成功,只导入了一部分,看来是中途出了问题。之后我还是在数据库层面导入,还是遇到了 Cache 问题。我从 wp-config.php 开始修改,一点一点删除和 cache 有关的配置和 PHP 文件,最后终于能够正常进入页面和后台,然后在控制台把 cache 相关的插件都关掉,算是正常了。

WordPress 正常了之后,我继续尝试 MoinMoin,很郁闷的是在 uWSGI 这一步怎么也无法正常。我发现 Python 应用这一部分的文档很不完善,而且不同的系统之间也有差异。比如,我从网上找到过在 Ubuntu 下的配置方式,按理说它和 Debian 血缘很近,但两者之间就不同用,还有 CentOS 系统下的配置说明,又是一种方法。MoinMoin 上有 Nginx 下配置的方法,从我的 Debian 服务器里就不能正常工作;Nginx 的页面有 MoinMoin 的配置实例,写的非常简洁,我看的云里雾里,最终还是放弃,等再找时间看看。我之前已经配置成功过,没理由这次会失败。不过这不是一个短时间能够完成的任务,还是找其它时间吧,毕竟 wiki 是给我自己看的记录,短期不上线也问题不大。

剩下的就是 Awstats 的迁移了,我还没有开始进行。另外 Shadowsocks 应该也不难,我看看 Linode 什么时候到期,再决定是继续用 Vultr 还是在 Linode 上新建一个 node。

对记录的痴迷

今天晚上,我终于能静下心来,整理一下我的个人维基了。我已经有很久没有编辑我的维基了,上次编辑还是去年十月份。

这次主要是折腾了几次系统,有写知识点想记录下来,但到最后总是懒得弄,所以拖到了今天。另外,和妻子在楼下的餐馆吃饭的时候,也说道要把所有点过的菜都记录下来,最终把菜单上的菜都尝一遍,这个事情我在加拿大的时候就做过,至今维基上还有记录。这些心里都想着要做,最后总是因为懒惰,没有及时之行。

我目前使用的维基系统是 MoinMoin,之前在博客里说过,我受到了啄木鸟社区的影响,十分喜欢他们的维基的界面,最终自己也上了 MoinMoin。今天我在想,我已经挺长时间没有鼓捣它的后台了,也不知道最新版本是个什么情况。我觉得 Python Web 应用比起 PHP 来,还是复杂一些,导致时间长了我都不敢动它了。MoinMoin另一个问题是搜索还不支持中文,网上好像有人弄成了,我也没有功夫去看一看。所以我想,我之前用过 DokuWiki,PHP 写的,还不错的样子,比较轻量,我想也许换成它是个好主意,于是在另一个子域名下进行了安装,结果效果不大理想,速度不大快,感觉还不如 MoinMoin,而且转移也要耗费功夫,单把每篇文章复制粘贴可不行,这些修改记录都是很宝贵的个人历史呢。

近年来我编辑个人维基的次数少多了。在加拿大的时候,我一有了新的东西就进行编辑,MoinMoin 也不赖,在要编辑的地方双击鼠标,就可以在这里进行编辑,不用耗费功夫,就把一个个的干货知识点给记录了下来,十分便捷。现在想想,那个时候我主要还是在用 MacBook,在家用,上学也带着,在校园里也在一直用,甚至在家里躺在床上也用。在这种情况下,有了新的想法,记录下来是很自然的事情。现在我不是这样了,手机替代了笔记本电脑,就没发再这么干了。手机上我不知道有没有 MoinMoin 的客户端,就算是在浏览器里编辑,打字也不爽快,最后也就算了。

个人维基对我来说,是一个记录自己的工具,就好比 Evernote 早年宣传的第二大脑。我之前有了博客,但它记录的是我的想法,我在上面写的是文章,既然是文章,就要有起承转合。维基不同,它像一个私人的笔记本,想到哪里,都可以写上几笔,不必在意格式,不必关心文章的间架结构,只写知识点。当然,这些也不是强制的,有的时候我也喜欢在上面发表一些见解,做一些解释,但毕竟少数。说回来,这是你的地方,想写什么随你。比起博客来,维基要有私密性,我不用 MediaWiki 的原因就是它不支持单个页面加密。MoinMoin 里我设了个私密区,里面所有不方便被别人看到的东西都在里面。我还保存了给我妻子谢的情书。

在手机上,维基就不怎么方便了,人们发明了其它方法来记录自己,这一度让我产生不安。我的手机里装了 Day One,我在里面努力写日记,每周要写一篇周记,但在里面写过一遍的东西,时间长了就不想在别的地方再写一次了。我担心这样下去,我的维基或博客还有没有继续存在的必要。后来我想通了,Day One 更加私密,我常常用来记录一些更佳琐碎的东西,比如同事见的龌龊、工作上的不顺利、甚至关于妻子的坏话。Day One 里面也记录了我的生活,不过方向完全不同,我不用担心谁取代谁。

维基对我来说不可取代的功能之一是内部链接。每篇维基都不是一个孤岛,通过内部链接,把他们串联起来,就能达到非常惊人的效果。像这次我在编写 Funtoo 的条目的时候,顺便浏览了 Linux、Arch Linux、Gentoo 的条目。这些信息的关联,就像是之前流行一时的知识图谱(Knowledge Graph)。

图这种数据结构,在人工智能领域里有很多的应用,对于知识/内容串联也非常有效。之前学英语的时候,我接受过一个理论,学英语要有一本英英词典,查一个单词,就要看它原汁原味的英文解释,有不认识的词就继续查,直到弄懂了所有的词(似乎是李笑来在新东方的课上说的),最终的效果,就是在脑中形成了一副知识图谱,你经历过的每个单词都在这张图的节点里,互相关联着,这样才起到了背单词的作用。我在学人工智能的时候,也做过神经网络方面的项目,心想如果有一台足够快、存储量足够大的计算机,是不是可以把这些算法用上去,让它分析整理全世界的知识,或者仅仅是维基百科上的知识,能不能至少形成一个 inference engine 来帮助我们工作呢?

当然这个想法现在还不能实现,至少不能普及实现,但不妨碍我对于记录这件事的痴迷。其实,不仅仅是维基,个人博客也是我对于自己的记录,很多事情我已经淡忘,但回顾过去的博客,常常会有一种恍然大悟的感觉,原来我这件事情是在这个时间点做的呀。我一共写了 11 年的博客,虽然文章数量不多,但我不打算停下。在 2005 年前后,中国博客最火的年代,我遇到了很多很好的博客,可惜现在 90% 已经不见了,这是多么可惜。我上次给域名续费,一下子续了 10 年,就是要把这个域名下的内容在我有生之年永远的维护下去,并不断补充。

MoinMoin 用了一年多了

今天编辑了我的 wiki 之后,顺手点了一下 RecentChanges 页面,看到了我的编辑记录,发现我这个用 MoinMoin 建的 wiki 已经使用了一念多的时间了。创立这个 wiki 的时间是 2012 年 2 月 1 日,现在想起来感觉就像是前几天一样,让我惊叹时间真是过的飞快啊。

我挺早的就接触了 wiki 这个东西。最开始自然是维基百科,后来买了空间后就在上面自己搭建私人的 wiki。当时 blog 正流行的火爆,很多人买了自己的域名和空间搭建自己的 blog,并把它当作首页。我不想这么做,所以一直是自己手写一个导航页面放上去,blog 和其它的东西放在下层域名中。但自己手写 HTML 并上传十分不方便,SSH 到服务器上修改又有编码问题,页面上的中文在 shell 中被解析成乱码,基本上处于无法改动的状态。最后我厌倦了,于是想用一个内容管理系统来生成首页。最早考虑的是 Movable Type,当时我也是在用 MT 来搭建 blog,MT4 又开始有了页面功能,不过弄来弄去一直不成功,我也不满意 MT 提供的美观效果。后来就把主意打到了 wiki 上面

当时我还只是想用 wiki 来管理首页,因此就排除了已经使用着的 MediaWiki,选择了一个小型的、简单的 wiki 软件来用。当时选择的是 UseMod,外观我挺喜欢的,简单,没有 MediaWiki 那些专门适用于百科全书的功能,整个页面基本上是个白板,我可以任意的往上写东西。不过很快我就遇到问题了。我的想法实际上是用软件当作一个动态管理的工具,说白了就是我可以在浏览器里面编辑这个页面,即时发布。可 UseMod 本质上是个 wiki 软件,因此在页面内容上做出了很大的限制。具体哪一点限制了我,在今天我已经记不起来了,总之它不让我用 HTML 来写页面,它自己提供的格式又无法满足我的要求。我查了一些资料,据说是为了安全考虑。对于一个多人编辑的 wiki 这是必要的,可对于只有我一个人维护的页面则有些过度保护了。没有放宽这个限制的办法,所以我只好作罢。后来我还尝试了一些其它的 wiki 软件,都无法达到要求。最后还是换回了一个我手写的页面,上面只有导航链接,算是一个鸡肋吧。

除了首页外,根据我的 blog 记录,我从 2010 年 2 月 7 日开始搭建自己的私人 wiki。当时我已经放弃了用 wiki 来做首页,因此就使用了最流行的 MediaWiki 来搭建了一个,用于自己日常的记录。开始的时候我因为觉得 wiki 是个好东西,因此就让自己尽量在上面写东西。后来发现这样做对了,因为有很多东西或许当时觉得不值得记录,于是就错过了,到之后再想找回来就很麻烦。而编辑 wiki 的成本很低,而且 wiki 是页面组织的,而不是像 blog 那样用文章来组织的,所以编辑 wiki 就像是随手再纸片上写点什么,而不用专门写一篇文章,所以也不用考虑太多,不用组织语言,直接把最纯粹的信息记录下来就行了。之后要用到了搜索一下就找到了。

我有几次这种经验,比如配置 VPS。一开始我觉得这不就是远程配置 Linux 么,有什么难的,有什么不会的去 Google 很快就能找到答案,因此也没有注重记录。只是因为第一次配这个东西,于是写了篇 blog 记录了一下,没有很详细,只是一些我过去没遇到过的一些设置。结果后来我换了一个新的 VPS 后,又需要配置一遍,我就有点抓瞎了,因为不清楚我有没有漏下什么。于是我就在配置的时候在 wiki 中记录下每一步,包括要做什么、命令、需要怎么编辑哪个文件,都详细的记录下来。之后我买了新的 VPS 后配置起来十分方便,按照这个列表走一遍就行了,不用担心漏掉了什么。

从那以后,我每当遇到这种情况,都用 wiki 把步骤记录下来,感觉安心了许多。

MediaWiki 并不是我最满意的 wiki 软件。首先它是专门为 Wikipedia 服务的,因此除了它的界面比起私人 wiki 更像是百科全书外,它还欠缺一些私人 wiki 上用得到的功能。比较重要的一项就是访问权限功能。我建立 wiki 是随身为了记录我的信息,而不是为了发布信息,因此我有些比较敏感的信息(比如帐号、密码之类的)不想公开,MediaWiki 就没有这个功能,而且也不准备添加这个功能,因为他们要做的 wiki 软件是为了自由的百科全书服务的,因此不应该有限制别人访问的功能。所以有机会我就会换到别的 wiki 软件。

中间因为我看到了 FreeBSDChina 的 wiki 觉得不错,就用了一阵子 DokuWiki。但我最终的目标还是 MoinMoin,或许是因为看到啄木鸟社区想弄一个那样的 wiki 页面。把里面的东西做好了真的是让人非常惊叹。后来经过几次尝试,我终于在 VPS 上成功跑起了 MoinMoin

使用 MoinMoin 伴随着的是我买了 512M 内存的 VPS,这样我可以放心的在上面跑 Apache 了。过去我用的 Nginx,设置页面转向非常困难,跟 Python 合作运行 MoinMoin 也需要很多第三方的东西,我弄了几次也没有成功。这次用了老牌的 web 服务器 Apache,我终于可以比较容易的设定 页面转向了。因此我的首页,也终于指向了我的 wiki 的用户页面。开始时我还想着怎么让 MoinMoin 生成一个 HTML 文件,后来才琢磨过来,直接用 301 转向不就行了吗。着算是完成了我最开始的目标。

我在刚刚搭建私人 wiki 的时候还幻想着会有人过来跟我一起写作,共同完善一些条目,因此就没有设定权限,结果很快我的页面就充斥了各种 spam,我一气之下就禁止了用户注册和游客写入,这是我在用 MediaWiki 时发生的事情。后来用 MoinMoin 后同样如此,现在在我的修改记录页面还能看到那些 spam 的条目,以及我的删除记录。经过此事,我同样禁止了游客的写入功能,这才清净下来。

在用 MoinMoin 的这一年里,我也遇到了一些问题。比如 MoinMoin 使用 xapian 来索引全文。当然,对于英文来说它很好使,但它不支持中文。因此在 MoinMoin 里基本上没法用 xapian 来搜索中文,我也不知道猴年马月 xapian 会支持中文。

另外就是 MoinMoin 的数据存储问题。它把每个页面用一个目录来保存,放在硬盘上。对于磁盘文件和数据库的优劣网上有很多的讨论,虽然我觉得把数据放在数据库里应该更好一些,但目前 MoinMoin 还不支持数据库。我过去也关注过 MoinMoin 2,但它的进展似乎不快,还不知道什么时候才有完成度比较高的版本出来。

回顾过去一年中的使用情况,我发现我往里面填充了许许多多的东西。不光是编程、网络方面的资料与笔记;我买过的咖啡品牌,我在中国餐馆点过的外卖菜名,我比较喜欢的歌曲名和歌词等等,我都往里面添加。我希望多年后我能有一个包容万象的私人知识库,不知道有多少年可以完成,而我有生之年可以往里面塞多少东西。

用 MoinMoin 做首页

我最早接触的 wiki 系统是 MediaWiki,带我进入 wiki 这扇大门的正是维基百科。我读过一些文章描写过有些人第一次听说一种新技术而激动不已,我当时对 wiki 没有这种感觉。事实上,我那时也不理解 wiki 的作用是什么。为了尝试,我在维基百科上建立了一个 “Gnu 宣言”页面,然后把那篇文章给复制了上去。结果没一会儿,我就发现我建立的页面不见了,然后我的 talk 页面上多了这么一条消息:

欢迎加入Wikipedia大家庭!在动手之前,请先抽出时间阅读Wikipedia:版权信息、Wikipedia:如何编辑页面及Wikipedia:帮助。您也可以到Wikipedia:沙盒中实验一下,有什么问题请到Wikipedia:互助客栈提出,或者直接与我联系。请注意Wikipedia并不收入原始资料。例如“GNU宣言”一文,应当加入介绍GNU宣言的文章,而不是原文。谢谢!–Formulax 2003年8月9日 02:42 (UTC)

这是我第一次的 wiki 的体验。这之后,我陆续在维基百科上进行过数次编辑,渐渐的了解了 wiki 是什么东西。不过,真正让我体会到 wiki 可以用来生成网站的页面是后来的事情了。

当我意识到 wiki 可以用来生成首页时,我已经用一个手写的 HTML 静态页面来做我的首页几年时间了。因为时我随意手写的,因此那个网页非常简单,上面除了我的名字之外,就只有一些我别的网页的链接,比如说 blog、相册等等。之前我还在上面放过我写的论文、我的头像等等,不过靠手动来管理这些东西,实在是太麻烦了,我渐渐的就把它简化成了像这样最最基础的页面了: My homepage until Feb 11, 2012

我过去是通过 ssh 登陆到主机上,用 vim 来编辑 index.html 文件来制作首页。有时候要往上面放中文时而终端不支持中文字符的话,就用 Emacs 远程编辑这个文件。我也考虑过在本地写好了所有的东西后再同步到服务器上,但这些页面保存在本地上,我又不能随时带着电脑,没法做到随地修改,还是太麻烦。正因为没有一种非常方便的编辑页面的方法,所以我的首页都是万年一个样,我都想考虑过要不要把我的 blog 直接放在根目录下呢。直到后来我想到了 wiki 可以帮我完成这一切。

其实,我最早想用到的工具不是 wiki,而是 Movable Type。MT 5 出来之后,我发现它在过去的基础上添加了 website 这个概念。经过尝试,我觉得 website 就是用来放 blog,这其实不就是一个网页么。而 MT 的后台编辑也勉强可以达到我的要求了。把 blog 和首页一起生成,不但让首页的风格跟 blog 统一,而且还可以让首页趁此机会丰富一下内容。可惜到后来我失败了。当我对 MT 5 的了解加深之后,我才发现 website 并不是我要的东西,中间有些东西要配置起来实在是太复杂了。

MT 不行,我之后才选择了 wiki。出于我个人对于简洁的喜好,我选择了相当简单的 wiki 系统——UseMod Wiki。安装它特别容易,我很快用它生成了一个比较不错的页面。但是当我往页面上添加东西时,我发现这个 wiki 系统不让我在页面里添加 HTML 代码,而它本身的格式功能也比较弱,这就让我感觉很不爽。比方说我想在页面上放几个贴纸,人家给出的代码我复制过来就没有用。我找过不少资料想解决这个问题,结果发现原来时出于安全的考虑,它禁止在页面里插入一些 HTML 代码。不仅仅是 UseMod Wiki,我找了一些其它的 wiki 系统,都禁止你这么做。如果一个 wiki 是给一个团队用来统一管理文档的,那么这种安全措施非常必要,但对于一个把 wiki 自己用的用户来说,这样就非常不方便了,尤其是我还希望可以用它来生成我的首页。

在尝试了一些其它的 wiki 之后,我渐渐的开始怀疑我这样做是否正确,是不是也有其它人和我一样用 wiki 来生成自己的首页。当中我早就听说过 MoinMoin,但我一直没有成功的安装。原因是那时我对于 FastCGI、WSGI 之类的没有任何经验,因此对这类程序完全不开窍,所以我那时选择的 wiki 基本上是 PHP 写的或者是 Perl CGI 的。到后来我渐渐的对这一点死心了,觉得或许用 wiki 来做首页有点不太实际,于是在 2010 年 2 月,我在空间上用 MediaWiki 单独搭建了一个 wiki

从那时候开始,我也尝试并转换使用了一些其它 wiki 工具。当然 MediaWiki 用的时间最长,后来我换成了 DokuWiki,然后是 MoinMoin。每换用一个 wiki,我都想过如何用它来管理首页。当中我也做过尝试,比如说把 DokuWiki 放在根目录下,把命名空间的分隔符由默认的冒号换成斜杠,结果页面没法显示了。我还考虑过在根目录下搭建 MoinMoin,然后 blog 之类的其它域名指向它们的子目录。结果这样我的 blog 就没法访问了,链接全被 MoinMoin 给拦截了。要让子目录可以访问,只好在 Apache 的配置文件里给它们添加 Alias,实在是太麻烦了。

不过几天早上我突然想到,MoinMoin 不是有用户页面么?在一个团队中,每个人都有自己的页面非常正常,那么私人的 wiki 呢?个人页面不是和我的首页用途重复了么?既然这样,我就用 Apache 的 rewrite 模块来把根域名转向到我的 MoinMoin 的用户页面上不就行了么?经过尝试,我发现这样做确实可以。我很愉快的在我的个人页面里加上了很多东西,编辑完毕后点一下保存,页面马上就生成了,非常方便。而且完全没有字符编码的问题,因为一切都可以在浏览器中完成,我也可以随地编辑我的页面。要在页面上放插图什么的,也不需要我手动用 FTP 来搞来搞去了,都交给 wiki 来管理,太方便了。

虽然我不知道这样做是不是一个好的主意,但至少现在它满足了我一直以来的愿望,现在看来它完全满足我的要求吧。

终于开始使用 MoinMoin

今天我终于把自己的 wiki 系统换成了 MoinMoin。

我对 MoinMoin 算是觊觎已久了,我的 blog 上关于 MoinMoin 最早的一篇文章是两年前的《还是建了一个 wiki》,那也是我在自己的网站上搭建 wiki 的开始。本来我用 wiki 是像用它来管理我的网页,因为这样可以在浏览器里用方便的结构化文本来生成页面,而不用我麻烦的手写 HTML,当时我试用了几个 wiki 程序都不符合我的要求。主要原因是 wiki 的内容限制有些死板,我不想把我的首页弄得像一个 wiki,我想让它像一个网页。而那些 wiki 程序都以安全为由把用户可以输入的内容限制的死死的,令我非常不爽。后来我放弃了用 wiki 来管理整个网站的想法,转而建立一个单独的 wiki,于是我在当时用的 Site5 共享空间上用 MediaWiki 搭建了一个 wiki。当时我已经想用 MoinMoin 了,可惜用共享空间来搭建 MoinMoin 太麻烦,我最后放弃了。

到了 2010 年的 10 月,我自己开始试用了 VPS,当时也尝试过安装 MoinMoin,不过失败了。虽然现在看来我觉得安装 MoinMoin 不难,但对我来说有些事情是必须要经历过一次才能理解的,在这之前我没有成功的在远程主机上安装成功过 MoinMoin。

2011 年 7 月 2 日我第一次在自己的 VPS 成功安装了 MoinMoin,用 Nginx + FastCGI 来运行,感觉不错。不过由于中文文件名等原因,我到了第二天就放弃了

今年年初我第一次给自己买了 512M 内存的 VPS,有很大的资源可以让我稍微挥霍一下,不用严格计算内存的用量了。本着学习的想法,我在这个 VPS 上装上了 Apache 服务器。在稍微熟悉了一下 Apache 的配置之后,我尝试着在上面跑 MoinMoin。MoinMoin 的文档上说用 WSGI 来运行 MoinMoin 是推荐的方法,但我就是没办法让 MoinMoin 在 Apache + mod_wsgi 模式下正常运行,于是我的尝试又一次失败了。那时我把 wiki 程序换成了 DokuWiki,用起来感觉很不错,当时我基本上都决定了之后就一直用 DokuWiki 下去了,结果命运弄人,偏偏我这时候瞎猫碰上死耗子一般的成功把 MoinMoin 在 Apache + mod_wsgi 模式下给跑起来了。

我今年初在买 VPS 的时候,因为 Ramhost 的 512M OpenVZ VPS 断货,于是我就买了 KVM 的。后来我又找到了 YardVPS 的更廉价的 512M Xen VPS,于是我最终把我的网站放到了 Xen 上。而 KVM 在这一个月内就被我用作了实验的机器。在把可以安装的操作系统装了个遍后,空余下来的我又尝试了一次安装 MoinMoin。这次我按照这篇文章中的讲解做了一遍,结果就成功了。对比这次和我之前的安装方法,我发现很大一部分原因是我中间少了给 moin.wsgi 文件添加查找路径那一步,还有就是我对 WSGIScriptAlias 要放在什么位置有困惑,这次上我试验了一下就给成了。

我是在实验用的 KVM 主机上安装的 MoinMoin,但要不要用它来替换我正在使用的 DokuWiki,我还拿不准。我稍微的在实验用的主机上用 MoinMoin 添加了几篇文章看了看,发现 MoinMoin 和 DokuWiki 的 wiki 语法在有些方面正好相反,需要转换一下;后台文字界面的编辑器没有乱七八糟的多余功能,其它方面的差距并不是特别明显。相比较而言,DokuWiki 更加方便一些,功能都被配置到了最好,安装上去后几乎不用改什么地方就可以很好的使用,而 MoinMoin 的配置性更高一些,看了一下帮助文档,我也学到了很多东西。

我之后打算把实验用的 MoinMoin 给搬到我的工作主机上来,先放在不同的目录下,同时运行,在转移数据的同时也好做对比。不过这时,发生了一个小意外。

我原本的 DokuWiki 是放在 /public_html/wiki 下面的,为了把 wiki 这个名字让给 MoinMoin,我在 ssh 里执行了 mv wiki doku 命令,之后进去 doku 目录找我过去的页面,发现我原先的页面都不见了。大惊之下我仔细检查,发现我原先在安装 DokuWiki 的时候就在 /public_html/doku 下面安装过一个 DokuWiki 来做实验,确定它运行正常之后才在 wiki 下面重新装了一个新的 DokuWiki。而原先的目录没有删除,结果这次出了问题。

我当时脑子不清晰,觉得这有些出乎我的意料,因为我印象里是如果 mv 命令的目标目录已经存在的话,是会覆盖目标目录的,结果这次却是把原始目录给丢掉了。虽然很不解,但我并没有太过担心,因为网页在 Google 上还有缓存,我可以用搜索出过去被缓存的页面,再从上面把内容转移到新的 wiki 中去,虽然有些私有页面和孤立页面没有被缓存很可惜,但我的损失并不大。这也让我下定决心转移到 MoinMoin 上来——因为 DokuWiki 已经被我给弄丢了。结果当我慢悠悠的转移了一个页面之后,再从 Google 搜索里打开其它的页面缓存的时候,我发现那些缓存竟然失效了。看来是在我编辑那个页面的时候,Google 访问了我的主机,发现原先的页面不存在了,于是就把缓存设定成失效了。我抱着试一试的心情去 web.archive.org 看了下,它根本没有收录我的 wiki,我这时才真的急了。

之后我发现我在换到 DokuWiki 之前用的 MediaWiki 还在,我没有删除它,只是给它变了个域名,而里面还有一些早期版本的文章。这让我心情稍微平复了一点,我毕竟没有失去一切,虽然在这一个月内我往 wiki 里添加了很多内容,这些内容的丢失还是让我心疼的想砸电脑来泄愤。话虽如此,这毕竟是我自己的所作所为,也怨不得别人,我也只好接受现实,默默的把文章从 MediaWiki 往 MoinMoin 上转。结果在转移的途中,我竟然看到了 /public_html/doku/wiki/ 这个目录,进去一看这不就是我之前的 DokuWiki 吗,原来我之前的数据还没有丢。静下心来回想了一下,我在执行 mv 命令的时候,目标目录 doku 已经存在了,结果不就是把原始目录给移动到 doku 下面吗。想到这里,我不禁想抽自己一耳光,惩罚自己犯下了如此低级的错误,白惊慌了一场。

之后就好说了,我把过去的数据下载下来,自己一篇一篇的添加进了 MoinMoin 中。文章不算太多,我手动修改添加也没有费多少功夫。当然,在做这些的同时我也学到了不少东西。比如说过去我以为 MoinMoin 没有最近更改这项功能,结果发现这是需要在 RecentChanges 页面下面添加一个 macro 才能搬到的,虽然我很奇怪为什么 MoinMoin 不直接把这个 macro 加到 RecentChanges 里去,不过这样也是 MoinMoin 定制性高的一种体现,毕竟易用性与定制性算是零和博弈的关系。

从两年前到现在,我的主机上的 wiki 系统终于演化到了我的目标 MoinMoin,让我有了一种两年的长跑结束了的感觉。当然,我对于 MoinMoin 的接触才刚刚开始,我已经发现 MoinMoin 有很多我不了解的地方,看来我在将来又可以学到新东西了。

我放弃 MoinMoin

昨天我在实验用的 VPS 上成功安装了 MoinMoin,今天早上正好有时间,于是就把 MoinMoin 安装在了我目前正式提供 web 访问的 VPS 上了。当中出了一些问题,不过我最终解决掉了。但其中有一个问题让我决定暂时放弃 MoinMoin 了。

发生问题是因为我这次想把 MoinMoin 放在一个子目录域名里。我在实验的时候把 MoinMoin 放在根域名下,跑起来很正常,但在子目录下就不行。页面可以显示出来,但呈现的是一种 CSS 缺失的状态,明显不正常。我查了很多文档,才最终解决了问题。解决方法我详细的记录在了我的 wiki 的相关页面上。

让我决定放弃 MoinMoin 的原因是中文支持的问题。我在实验的时候没有遇到这种情况,我猜测和根域名有一定的关系。我开始时用的是 FrontPage 来当首页,但我安装中文语言包并在用户设置里把语言设置成简体中文之后,发现这两个语言的页面不统一,需要中文、英文各弄一套,而我也不想只使用中文界面。之后我就选择了 MyStartingPage 来做首页,这时发现由中文标题的页面完全不正常了。比如“VPS 笔记”就被弄成了“VPS %E7%AC%94%E8%AE%B0”。如果仅仅是 URL 成了这样也就算了,实际的页面标题也成了这样,而且 MoinMoin 似乎还不把它们当成一个页面处理,这样我保存的时候就发生了问题。这太恶心了!

从网上找了一阵子,没有找到解决方法,很多人也说无解。我要想正常使用 MoinMoin,只能不在页面标题里用中文,这样限制就大了;要么我就换个 MoinMoin 版本。本来我以为是因为我使用了不同的域名的原因,结果我看了一下我实验用的 MoinMoin,发现虽然中文标题能够正常显示,但实际上那标题依然是百分号开头的字符,这让我的兴致降低了许多。

想了想,我于是又用回了 MediaWiki。好在我之前的 wiki 没有删除,我只是改了一下 Nginx 的配置,换了个子目录域名,这会再弄回来就行了。MediaWiki 对中文的支持很好,我想不止是 PHP 的原因,底层数据库本身就有一定影响。MediaWiki 用的数据库软件对中文支持很好,而 VPS 上的文件系统上来存储中文文件名还是一个不确定的事,跨平台编写相关的程序又加大了工作量,所以 MoinMoin 对中文的支持情况,我也可以理解。我检视了一下 MediaWiki,没有发现有类似的情况。文章的标题都存放在数据库中,非常安全。

昨天我安装好 MoinMoin 之后,试着在里面编辑了几篇文章,把原来的 wiki 上的文章复制几篇过去,想看看 MoinMoin 的功能如何。结果我觉得刚安装好后的 MoinMoin 相对于 MediaWiki 来说功能算是比较弱的。有些 MediaWiki 的功能,MoinMoin 默认没有实现,比如说最近更改功能,MoinMoin 好像就没有。还有 MoinMoin 的用户选项设置,只有那么几样,与 MediaWiki 由很大差距。或许 MoinMoin 的那些选项已经够用了,不过 MediaWiki 的明显更多。

这几年使用 MediaWiki 给我一个感觉,就是“成熟”。经过了 WikiPedia 的考验,MediaWiki 可以说是非常可靠,从功能上和稳定性上都是如此,当然万恶的 access key 除外。或许我用 MediaWiki 没法做出很漂亮的页面,但我有了一个百科全书级别的用来收录知识的网站,这就足够了。当然,要是有访问控制,就更好了。我还要等着保存那些不怎么好公开的东西呢 😉

MoinMoin Wiki

今天我终于成功的在自己的 VPS 上跑起了 MoinMoin。

我很早之前就想用 MoinMoin 了。我最早在虚拟主机上运行过 MediaWiki,感觉不错,不过我更希望使用 MoinMoin。首先 MoinMoin 是用 Python 写的,我比较熟悉;而 MediaWiki 用的 PHP 我实在是没有入门。如果我可以运行 MoinMoin,那么我就可以更好的操纵这个 Wiki。

第二点原因是我比较喜欢 MoinMoin 做出来的站点风格。MediaWiki 做出来的 WikiPedia 虽然不错,不过我更喜欢 MoinMoin 做出来的 WoodPecker。我几年前就从网上和 WoodPecker 的创始人之一 ZoomQuiet 有过交流,看到他在 WoodPecker 上的个人页面,我总是很羡慕那种“乱糟糟”的感觉。我比较喜欢这种看似杂乱无章的大杂烩,就像是高手的小纸条,外人看上去皱皱巴巴的,丝毫没有条理,但高手却可以马上从上面得到信息。MediaWiki 是为了写百科全书而开发的,版面很严谨。我曾经想把 MediaWiki 做的页面故意弄乱,结果失败了。

第三点也非常重要,就是 MoinMoin 支持访问控制。如果说 blog 是一个公告板,那么我希望我的私人 wiki 可以稍微私密一点。虽然不一定有多少人访问,但我总是想记点见不得人的东西什么的。我本来觉得 MediaWiki 应该挺成熟了,应该有这个功能,结果去官方网页上查,却看到人家直接就说 MediaWiki 是为了知识可以公开访问、编辑而开发的,访问控制?提都不用提!我直接心碎了。MoinMoin 才不管这一套,奔着实用主义去的。

过去我没有 VPS,只有和别人合租过虚拟主机。我没有 root 权限,因此想真正把 MoinMoin 装在服务器上很难。我倒是可以从命令行启动 server,可这又不是真正的安装在 server 上,和在本地运行的 MoinMoin 没什么两样,只能测试,无法实用。我从网上看到有成功的例子,可我自己来安装却怎么都不行。归根结底是我没有 root 权限,fcgi 也没法配置。几次下来直接把我给弄伤了,所以后来我有了 VPS 后还是装的 MediaWiki。

这次我换了新 VPS 后,考虑再三,还是把旧的 VPS 再续了一期的费,三个月不到 3 美元,我可以承受,而且我有些东西想实践一下,比如 Rails、Django 等。新的 VPS 是放网站的,我不想轻易装各种各样的东西来测试,因此就在旧的 VPS 上随便用了。昨天我试验了 Django 之后,今天我就打起了 MoinMoin 的主意。

我从网上找到了这篇文章,照着做了一次,才发现安装 MoinMoin 实在是简单,当然是在你有完全控制的前题下。我在中间遇到过一个小问题,不知道操纵了什么地方,等我再次启动 moin.fcgi 之后就发现页面居然提示我 502 错误。我找了半天错误,才发现我是用 sudo 执行的启动 spawn-fcgi 的脚本(我把命令写在 shell 脚本里了),这样根本不行。我在 root 账号下运行脚本就没问题了,我估计应该要把 sudo 写进脚本里才行,不过还没有测试。

现在有了 MoinMoin,我也在考虑是不是要把 wiki 系统换过来。MoinMoin 有上面的种种好处,但要用到 Python,效率是个问题,我的 256M 内存的 VPS不知道跑的畅不畅,这还要我观察一段时间再说。另一方面,MediaWiki 是 WikiPedia 的引擎,这已经可以证明了许多东西。我用了这么一段时间 MediaWiki,也算是有点熟了,而要用 MoinMoin 的话需要重新熟悉。还有就是 MoinMoin 的数据存储在文件系统里,与 MediaWiki 的数据库相比到底怎样,我还没有一个明确的结论,至少那些随即字符的 id 让我有些云里雾里,不好识别。不知道 WoodPecker 的数据是不是很乱?

还是建了一个 wiki

最近一段时间,我一直断断续续的研究 wiki。主要的目的是想用 wiki 来做首页,因为我厌倦了一直依赖手写 HTML 代码来更新首页。因为这样弄起来麻烦,所以过去我的首页基本上都是常年不变的。我一直觉得首页应该是一个站点的门户,所以我在 2007 年第一次建立这个站点的时候就决定把 blog 分离出来。那时候有很多人的首页上来就是自己的 blog,我觉得作为一个学计算机的,网站应该保留一些传统,所以尽管我的主页常年不动,几乎是个废物,我还是一直留着它。

直到我忍不了了,心想应该需要大修一下,最起码要做到内容和格式分离。开始的时候我想的是用 MT 来一并管理了,后来总是不得法,一直没有成功。然后就决定用 wiki 来做,也能达到一个 CMS 的要求了。我当时想的是首页不需要多少功能,就选了个最简单的 wiki 程序──UseMod Wiki。它不使用数据库,所有数据用纯文件保存。后来觉得首页全用 wiki 写有很大限制,比方说不能插入 javascript 代码,这样我就不能在页面上放一些贴纸(比如 Ubuntu 发布倒计时什么的)。我试验了好几个 wiki 程序,他们的设计方向都是多人共同编辑,因此在插入可执行代码方面的政策相当保守。最后只好作罢。后来想起了之前用过的 Blosxom,它可以在文章中放置任何代码,但我最后还是觉得 Blosxom 主要还是为 Blog 系统设计的,要想让它编程首页的样子,就要重新设计模板,而这正式我最不擅长的。

前几个星期我在看 Ramhost 的消息的时候,看到它的老板曾经写过一个叫 Ram-CMS 的项目。它很类似 Blosxom,也是手动把页面写在纯文本文件里,放在一个目录中,系统会通过链接找到文件,显式出来。我把在首页上放了几天,觉得还算不错,不过也有部分问题,就是这个项目的开发还不够成熟,用它来做很多事都挺麻烦。虽然能够完成,但我毕竟是不想再手写 HTML 代码,要是能有类似 Markdown 那样的抽象机制就好了。同样的,那个项目不是一个产品项目,而是作者给自己开发的小玩意。我要对模板做一些改动才能使用。我于是一遍慢慢进行,一遍在寻找其它产品。

我前几天又上了 Zoom.Quiet 的页面,他们一帮人组织的致力于 Python 的推广学习的啄木鸟社区,用的是 MoinMoin 做的 wiki。而那个社区里的一些看上去杂乱的页面风格挺符合我的胃口,我那时候有正在考虑 CMS 的问题,就想试试 MoinMoin。后来看了半天文档、又实践,却发现 MoinMoin 很难安装在共享虚拟主机上。最后也不得不放弃,同时发现,Python 程序和 Ruby 写的 CMS 往我的 Site5 主机上放都不太容易。Perl 写的 CGI 已经就差不多了,当然最方便的还是 PHP。

后来由于怀念起很早之前用 MediaWiki 搭建的一个歌词为主题的 wiki 了,于是就又装了一个 MediaWiki。我印象里一直以为 MediaWiki 只支持 MySQL 的,结果查了一下发现 MediaWiki 同样支持 SQLite。我目前觉得 SQLite 数据库比纯文本文件数据库还要方便,毕竟一个目录和一个文件的便宜程度是没法比的。Site5 主机上的 MySQL 默认的字符编码是 Swedish,很讨厌,我一直也没有成功的弄到 UTF-8 上,于是我没有在主机上建立一个数据库,全部用的 SQLite。不过装上 MediaWiki 后却发现不会用了。我过去为了管那个站点,还研究过一段时间,但将近两年的时间没有再管理了,再次见到一头瞎。最后觉得也不甚理想,于是就删除。

昨天看到 TualatriX 写的文章《摆脱信息爆炸,开启个人Wiki的时代》,提到他用 MoinMoin 建立了一个 wiki。我看了之后也挺羡慕的,只谈自己没有 VPS 啊。不过文章却启发了我,之前一直想用 wiki 做首页,但其实真正弄一个私人的 wiki 还真是个不错的主意。日常里有些信息还真得需要用 wiki 来维护。

我最头疼的首先是打开的网页。我的习惯是看到好页面,如果不是特别想看的话,而且还有别的页面也想看时,就把它的标签留着,以后再看。反正我平时的本子基本上不管,移动的话直接一扣,Mac OS X 的电源管理还是做得很好的。这样时间长了我的 Firefox 就积攒很多标签,既影响速度,又让我觉得很难看完,而关掉有觉得不甘心。最后要么把所有标签收藏起来,好么就把链接保存在文件里,等将来再看(虽然绝大多数情况是将来再也没有看过)。我曾经写过一个 Google App Engine 上运行的程序,名叫 URL-Basket,专门收集临时链接的。跨年的时候写的,但不能处理非英文的字符,后来事情多了也没有再修改。现在觉得而这些东西放进 wiki 里应该也不错。同样因为是放在网上,移动的问题也解决了,远比在硬盘上建立文件方便。

我心中理想的产品,是一个 wiki 为基础的大杂烩,可以进行普通的编辑,也可以在上面加各种各样的应用,最好它本身就是一种语言的解释器,可以运行自己的语言。所有的东西可以放在一个页面里,也可以进入不同的目录。程序也即文本,也就是那些小程序模块可以像文字一样复制粘帖。其实这个东西就相当于一个在线版的 Emacs,我这想法也没有任何依据表明它一定会有用,不过我空想中觉得应该是挺好玩的。目前的 wiki 程序算是完成了一半的要求,不过毕竟发展的思路不同,或许将来会有类似的东西吧。

既然自己要弄一个 wiki 系统,我还是选择了 MediaWiki。因为不是想用它做首页了,所以复杂一些也没关系。过去在 Dreamhost 上运行 MediaWiki 要忍受它的龟速,但在 Site5 的共享主机上就完全没有速度的问题了。我试过一些其它的 PHP 写的 wiki 程序,很多都只支持 MySQL 数据库,这是我不想要的。MediaWiki 支持 SQLite,也被 Wikipedia 证明了它的稳定性,所以我也就义无反顾的选择了它。安装好了还是想不起来怎么用,只好查文档看各种资料,折腾了一会好歹把之前的数据都放进去了。

目前来看,我对这个 wiki 还是比较满意的。本着能用就好的原则,我也没有进行过多的设置。把自己的 favicon 和 MediaWiki 的 logo 合并,作为了 wiki 的 logo,虽然觉得那粗线挺丑的,但也算到了我设计能力的“极限”了,也只好将就了。

弄了 wiki 后,首页我就不打算放 wiki 了。之前那些杂货也都挪到 wiki 上了,首页就让我设计成几个指向我几个不同帐户的图标组合了。目前看起来一切都还好。