文章归档

写了个简单的 shadowsocks 退出自动重启脚本

screen在 VPS 上跑 shadowsocks, 不过时不时会退出然后需要我上去重启,很麻烦,于是就搞了个定时检测 shadowsocks 是否在运行,如果没有就自动重启的脚本。

然后在cron任务里面写上一句 */1 * * * * root bash /some/path/autostart.sh 就可以每分钟自动执行了,而且这样还能变相实现开机自动启动,所以就算服务器意外重启也不怕了。

如果觉得异常退出过后一分钟启动的间隔太长,当然也可以写成死循环:

就可以每5秒检查一次了,但这样[……]

继续阅读~→

从 MySQL 迁移到 MariaDB

“Because Oracle is Oracle is Oracle()”[?]

ArchLinux 昨天宣布将使用 MariaDB 作为 MySQL 的默认提供包,openSUSE 已经在新近发布的12.3版中默认使用 MariaDB, 连 Fedora 也正在考虑更换为 MariaDB.

于是我决定把我的所有服务器从 MySQL 迁移到 MariaDB.

对 Arch 用户来说很简单,照着官方新闻里面的来就是了:

而对于 openSUSE 就更傻瓜式了,毕竟是默认的嘛: zypper in mariadb 一句就够。

至于 Debian/Ubuntu 用户就要稍微复杂一些,不过整个过程还是很流畅的:
[……]

继续阅读~→

在两台 VPS 之间实现自动异地备份

就是记录一下设置 Wiki 的自动备份,在 Wiki 所在的 VPS 上定时对资料目录打包,然后从备份用 VPS 把打包好的文件传输过去。

之前遭遇过多次 VPS 挂掉而数据灭失的惨剧,最近一次就是幸苦写了十多个页面之后的个人 Wiki… 然后到现在都还木有把那些内容全部给补回来…虽然说现在使用了几乎不用考虑升级(也就大大减少了手贱的几率)的 Slackware 系统,但是以防万一还是做个异地备份的好。

异地备份重于泰山

为了方便设置备份时间和文件传输的安全性考虑,我把所有参与备份的服务器设置为了同一时区,并且使用 scp 命令来通过 SSH 完成文件传输。至于备份的脚本,设置为使用 cron 任务定期执行。

我的个人 Wiki 放在一台跑着 Slackware 13.37 的低配 VPS 上面,用的是 MoinMoin Wiki 系统,所有数据都保存在文件系统中而不需要数据库,所以只要给 Moin 文件夹打包就可以备份全部内容了。
[……]

继续阅读~→

在 CentOS 5 下默认使用 Python 2.6

出于某些原因,某台低配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 & nginx 重定向设置

博客搬家到了 Linode 的东京结点上,操作系统依然使用的是配置服务器最顺手的 ArchLinux 但服务器构架从之前小内存机器上仔细调教过的 MySQL + Apache httpd 变成了复杂一些但可以充分压榨服务器性能的 MySQL + Apache httpd -> varnish -> nginx 也即通常所说的 LNMPA 再加一个 varnish 这样。数据库和文件等的迁移都很顺利,因为是先修改我的本地dns缓存指向新主机,调试好过后才真正修改的dns记录,所以实现了博客不下线地转移。

迁移完成立刻就发现了一个问题:首页无限重定向。
这个倒是不难办,把原来所用的 nginx 虚拟主机配置文件中一些针对不同文件类型做的配置全部去掉,只保留了反向代理给 varnish 的语句,首页正常打开,后台也正常。经测试插件配置、启停、增删都没有问题。

很快就发现,博客的重定向不正确,也就是 WordPress 后台中的固定链接设置无法生效,访问自定义链接的页面打开的是首页。
安装了 Permalink Fix & Disable Canonical Redirects Pack 插件,但是还是无法正常。(需要注意下面的语句是建立在此插件启用的基础上的,停用插件后还是会出错)
[……]

继续阅读~→

邮件通知已可用 -> 之前是我脑残了

之前也提到过邮件服务无法使用的问题,当时去Arch的官方wiki看,装上了Postfix之后的步骤太多,把我看晕了于是放弃神马的。。。
然后昨晚突然心血来潮想,干脆装上sendmail吧/ 然后到aur里面找到了sendmail包,编译好过后安装,然后提示我某某文件已有某某文件已有,突然想起来postfix还木有卸载。。。
这个时候我突然意识到,postfix作为官方源里面的包,照理说是安装好就可以直接用的啊!打开探针,测试邮件。。。。成功。。。。。但是木有收到测试邮件诶。。。
然后一直到了今天早上我才想起来。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。
。。。。。。。。。。。。。。。。。。。。。。。。。。。。[……]

继续阅读~→

Apache + 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以及不断实验,重启若干次过后,找到了个人比较满意的配置方案如下~
[……]

继续阅读~→

暂时稳定 – ArchLinux 与 OpenVZ 与 kernel too old 之二

上回,这次采用了这篇文章中的办法来解决母机kernel过旧的问题。
编辑/etc/pacman.conf[testing]之前加上:

然后到/etc/pacman.d/mirrorlist设置为合适的源就行了,我用的是这个:

此时先不升级、不重启,编辑/etc/fstab添加:

当前最新版本的glibc-vps已经修复此bug,安装后可直接使用,无需特别设置(截止glibc-2.16.0-101_x86-64测试通过)。
UTF8_E[……]

继续阅读~→

继续折腾 – ArchLinux 与 OpenVZ 与 kernel too old

本馆从周五开始就无法访问了,嗯,乃木有猜错,瓦又开始折腾了……
因为给ThinkUp从0.16升级到0.17的时候数据库出了一点莫名其妙的问题所以不能用,于是干脆备份数据然后重新来过。反正我是一直想用ArchLinux+LNMPA的组合的,因为老是弄不好才用的Debian+LNMP救急。然后备份的时候发现ThinkUp的数据库居然有220+M小吃惊了一下。
然后就重装VPS的系统咯,然后装了Ubuntu觉得不爽,还是弄成了Arch。因为之前一直因为母机内核版本的问题没办法直接用Arch的源来更新,一旦更新就:

然后系统崩溃只能重装。网上找到的许多解决办法都有各种各样的问题,最后自行找到了一个折中的妥协方案。
通过搜索,找到了一个存档了每天的Arch源的网站,然后又因为我的VPS母机kernel貌似是2.6.18,经过测试找到了不会引发上述错误的最新的源。
[……]

继续阅读~→

怪蜀黍神马的到这里就禁止通行了哟/
Merry