这个问题持续了得有超过一年了，症状很简单，配置了 https 访问之后，使用 IPv6 访问的时候会报 400 Bad Request 错误，强制使用 IPv4 或者强行指定 https 协议都能解决。说到这里应该很明显了对吧，首先就应该想到是不是 80 端口上也开着 ssl 来着。但这个讨厌的地方在于用 IPv4 就一切正常了，我一直没想那么多……就因为这我的博客很长时间都没办法强制 https 访问，不然 IPv6 过来的用户没法看。
前两天搞着搞着调另一个什么反向代理相关的设置的时候，顺手开了 debug 日志，然后就想顺便测一把，结果一不小心就找到了原因_(:зゝ∠)_
长话短说，问题的根本原因是普通 http 协议和加密的 https 协议配置在了一个
server{} 块内。并不是说不支持这样搞，而是这样配置过后服务器的行为会和分开配置成两个有所不同。
[……]
用screen在 VPS 上跑 shadowsocks, 不过时不时会退出然后需要我上去重启，很麻烦，于是就搞了个定时检测 shadowsocks 是否在运行，如果没有就自动重启的脚本。
|
1 2 3 4 |
pids="$($_CMD pgrep ss-server)" if [ ! $pids ]; then screen -dmS shadowsocks /some/path/ss-server -p port -k password fi |
然后在cron任务里面写上一句
*/1 * * * * root bash /some/path/autostart.sh 就可以每分钟自动执行了，而且这样还能变相实现开机自动启动，所以就算服务器意外重启也不怕了。
如果觉得异常退出过后一分钟启动的间隔太长，当然也可以写成死循环：
|
1 2 3 4 5 6 7 8 |
while true: do pids="$($_CMD pgrep ss-server)" if [ ! $pids ]; then screen -dmS shadowsocks /some/path/ss-server -p port -k password fi wait 5; done |
就可以每5秒检查一次了，但这样[……]
“Because Oracle is Oracle is Oracle(…)”[?]
ArchLinux 昨天宣布将使用 MariaDB 作为 MySQL 的默认提供包，openSUSE 已经在新近发布的12.3版中默认使用 MariaDB, 连 Fedora 也正在考虑更换为 MariaDB.
于是我决定把我的所有服务器从 MySQL 迁移到 MariaDB.
对 Arch 用户来说很简单，照着官方新闻里面的来就是了：
|
1 2 3 4 |
systemctl stop mysqld pacman -S mariadb libmariadbclient mariadb-clients systemctl start mysqld mysql_upgrade -p |
而对于 openSUSE 就更傻瓜式了，毕竟是默认的嘛： zypper in mariadb 一句就够。
至于 Debian/Ubuntu 用户就要稍微复杂一些，不过整个过程还是很流畅的：
[……]
唔…大致说来就是最近在折腾着把停止更新的 embr 给升级到 Twitter REST API v1.1, 然后今天参考黄飘飘的改动把 fav 相关的两个地方弄上了自动翻页。
因为 api 更新的关系，不能用原来的页码作为参数，只能用推文的 id 来做界定了，不过操作起来倒是比想象的还要简单就是了。修改好过后传到 appfog 上木有任何问题，但放到我自己的服务器上面过后发现翻页不能了…
开始还以为是 nginx 配置不对，但看了半天找不到问题，于是考虑是不是 PHP 的问题…
简单找了一下，发现问题在于生成的翻页链接上，因为推文 id 被作为参数传到链接里面，而生成的链接变成了类似于
/favor.php?max_id=2.9972877531744E+13 这样的形式…科学计数法耶…
[……]
基本还是弄着玩的…前提显然是有一台vps嗯嗯…
Trac 是一个专为软件开发设计的集问题追踪和 wiki 系统于一体的网页软件，git 是一个灵活而强大的版本控制工具，而 cherokee 则是一款简单好用的 web 服务器，当然，三者都是开源的。另外，这里选用 cherokee 而不是 nginx 或者 apache 这一类更为主流的服务器是因为 cherokee 的网站和默认页面比较好看所以想干脆来装逼一下这种事情我是不可能在教程里面说的。
为了搞好这个我折腾了一天，翻看了好多文档和教程，试了多种方法，最后是用的文档上没有提到的一种组合。之所以这样是因为按照文档进行设置一直不成功…
我所用的系统是 Ub[……]
就是记录一下设置 Wiki 的自动备份，在 Wiki 所在的 VPS 上定时对资料目录打包，然后从备份用 VPS 把打包好的文件传输过去。
之前遭遇过多次 VPS 挂掉而数据灭失的惨剧，最近一次就是幸苦写了十多个页面之后的个人 Wiki… 然后到现在都还木有把那些内容全部给补回来…虽然说现在使用了几乎不用考虑升级（也就大大减少了手贱的几率）的 Slackware 系统，但是以防万一还是做个异地备份的好。
异地备份重于泰山。
为了方便设置备份时间和文件传输的安全性考虑，我把所有参与备份的服务器设置为了同一时区，并且使用 scp 命令来通过 SSH 完成文件传输。至于备份的脚本，设置为使用 cron 任务定期执行。
我的个人 Wiki 放在一台跑着 Slackware 13.37 的低配 VPS 上面，用的是 MoinMoin Wiki 系统，所有数据都保存在文件系统中而不需要数据库，所以只要给 Moin 文件夹打包就可以备份全部内容了。
[……]
出于某些原因，某台低配VPS上面只能使用 CentOS 5.8 系统，但是 el5 系列的 python 版本只更新到了 2.4.3 而需要运行的应用建议使用 2.6.x 系列，所以设法更新python版本。
找了好几处不同的网站，最后综合起来达到了想要的效果：非编译安装 python 2.6 并通过 yum 管理，同时系统全局默认使用 2.6 版本替代 2.4.3
对于刚安装好的vps来说，当然要更新系统至最新。然后我们来更新python.
python是一个系统级的依赖包，没有办法卸掉（要不然很多东西都不能用了），于是只能用第三方提供的二进制包了，这里我用的是 Fedora 维护的 EPEL 源，同时还需添加 RPMForge 源以满足依赖关系。
[……]
博客搬家到了 Linode 的东京结点上，操作系统依然使用的是配置服务器最顺手的 ArchLinux 但服务器构架从之前小内存机器上仔细调教过的 MySQL + Apache httpd 变成了复杂一些但可以充分压榨服务器性能的 MySQL + Apache httpd -> varnish -> nginx 也即通常所说的 LNMPA 再加一个 varnish 这样。数据库和文件等的迁移都很顺利，因为是先修改我的本地dns缓存指向新主机，调试好过后才真正修改的dns记录，所以实现了博客不下线地转移。
迁移完成立刻就发现了一个问题：首页无限重定向。
这个倒是不难办，把原来所用的 nginx 虚拟主机配置文件中一些针对不同文件类型做的配置全部去掉，只保留了反向代理给 varnish 的语句，首页正常打开，后台也正常。经测试插件配置、启停、增删都没有问题。
很快就发现，博客的重定向不正确，也就是 WordPress 后台中的固定链接设置无法生效，访问自定义链接的页面打开的是首页。
安装了 Permalink Fix & Disable Canonical Redirects Pack 插件，但是还是无法正常。（需要注意下面的语句是建立在此插件启用的基础上的，停用插件后还是会出错）
[……]
在之前的几篇文章中，曾经提到过用[glibc-vps]源来解决ArchLinux内核比母机高的问题，之前用这样的方法配好的服务器也一直稳定运行着。不过直到Arch的glibc更新到2.15.
话说，那一天，我写完了2011年总结，配好了留言头像墙，淡定地打开ssh输入了 pacman -Syu 然后重启系统。于是悲剧开始了。
重启过后很快发现vps没有启动，在后台尝试多次均无果后，发ticket要求客服修复。不久后客服回应，给我详细讲解了OpenVZ不能使用独立内核的问题。晕啊，这是我解决好了的。然后再发ticket，告诉客服我用的[glibc-vps]源的种种，结果客服还是说没办法修复，而且数据也拿不到。 
悲剧了吧，傻逼了吧，没备份只能干着急了吧。正好那几天又在考试，根本没时间重新配置服务器，不得以快速装上了nginx然后放上这个页面。
[……]
这篇日志注定很短。
现在使用的服务器是 ArchLinux + Apache 2.2.21 + Nginx 1.0.11 + MySQL 5.5.18 + PHP 5.3.8 的环境，详细的PHP探针可以在这里看到。
以上都是直接从Arch的原安装，然后一些组件是自己编译的，简单的方案在之前的这篇和这篇日志中有提及。再加上ftp客户端和后台运行一个ntp进程，apache加载上mod_python组件，配置好了过后开机内存在72-75M，很满意。但是在运行一段时间（积累了一定量的网页请求）过后，内存就会直逼400，突发状况可以冲到接近500，就算空闲下来也有接近300，这个就有点不爽了。
于是折腾。
根据观察，处在前端的Nginx资源占用一直很小而且稳定，主要占用内存的就是若干httpd进程，那么就着手应对这个了。
在一番Google以及不断实验，重启若干次过后，找到了个人比较满意的配置方案如下～
[……]
