SysAdmin

主任说：

冗余不做，日子甭过；备份不做，十恶不赦。

以前一直是每天手动给自己的新服务器做备份，最近找时间写了一套脚本来自动完成这个事情。

脚本没啥复杂的，大体的思路是这样：

1. 在源上根据日期命名生成一份新的快照；
2. 将上次备份机器收到的快照和新快照之间的差异 pipe 给 xz，然后再把结果pipe给ssh（使用key验证），传到备份机上；
3. 备份机解压缩、zfs receive之后，如果成功，ssh到源系统上记录自己拿到的那个新的快照日期；

由于是通过 Internet （从AS6939送到AS33651）传递快照，所以使用了压缩。用ssh来完成传输的考虑主要是因为它能够做到互相验证身份。

原則上，在 Internet 提供服務的機器，應提供對應的 whois 記錄，以便在出現問題時能夠與事主及時聯絡。北美地區的數字資源，例如 IP 地址、AS號等等，是由 ARIN 負責分配的。

📜 历史文件已不具备现实意义

现时提倡的安装方式为 pkg，本文并未对此进行更新。

VirtualBox可以在远程运行，并把界面通过 ssh 的 X11 转发放到管理员的桌面。

之前 @quakelee 提的一个问题（通道上登录第二台机器作为跳板登录第三台机器，但不把ssh私钥传到中间那台机器上）。如果shell是csh，在 ~/.cshrc 中加入：

source ~/auth.csh
[ -e ${SSH_AUTH_SOCK} ] || ssh-agent -t 15m -c > ~/auth.csh && source ~/auth.csh

然后所有的 csh 就可以使用同一个ssh agent了。

指望硬盘不挂掉是 很拼人品的事情（附带说一句，从某种意义上说，21世纪的硬盘质量并没有下降，只是单位容量出现故障的概率没有显著提高，而硬盘容量的扩大使得单块硬盘的故障率看起来提高了，但是如果我们从单位容量的故障率来看，坏损率并没有非常显著的增长）。所以想要长久地保存数据，就必须采用各式各样的冗余和备份手段。冗余和备份是不一样的，前者往往会采用同样的访问控制逻辑，提供在线或近线的数据存储，强调的是数据访问的及时性；而后者则强调的是数据的可恢复性。

关于访问控制

一般来说，不希望备份与原始数据采取相同的访问控制机制。例如，对网站来说，可以读写数据库的那个 Web 访客的数据库账户，很可能并不能直接读写网站的备份数据。有时，备份甚至是以一种"外科手术"的方式进行的：对文件系统做快照，然后将快照打包发到异地的另一套系统。

续前。

除了硬件上直接采用的降噪措施之外，一些软件方面的配置也可以提高其效果。

首先是BIOS中的配置。风扇转速最低可调整为"Energy Saving"（即使用30%的频率）。启用Active Power State之后，可节省大约2W左右的耗电（这个选项的默认值是Disabled）。

然后是FreeBSD本身的配置。我个人采用的配置包括：

• 禁用硬盘的APM。WD的这款硬盘默认的APM值为128，这样它每隔大约10秒没有操作时就会将磁盘转速降低。这类操作对磁盘的寿命有一定影响（一般来说磁盘的机械部分支持10万到20万次这样的操作），因此可将其设为254；
• 启用磁盘的AAM。这个配置的好处是让磁盘控制其磁头臂的加速度，其效果是减少噪音，并且有一定的节能效果。注意：实际测试显示这个设置产生的节能效果基本上可以忽略不计，并且会稍微降低一些性能。磁盘的AAM数值设置为128（默认为254）；
• 将经常写的日志放到 /tmp （使用tmpfs）；
• 将收集entropy（随机数种子）的频率由每11分钟一次降低到每天一次；
• 启用 AHCI 磁盘驱动；将ahci通道的pm_level全部设置为5（设备在闲置125ms之后可申请通道链路进入SLUMBER模式）
• 禁用APIC时钟。
• 禁用AT RTC时钟。
• 对于没有驱动的PCI设备，将其置入D3模式（停电）。

上述设置，除了ahci部分之外，可将系统闲置时的功耗降低到17W左右。

以下是实现中采用的loader.conf相关的部分：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

hint.apic.0.clock=0
hint.atrtc.0.clock=0
hw.pci.do_power_nodriver=3
hint.ahcich.0.pm_level=5
hint.ahcich.1.pm_level=5
hint.ahcich.2.pm_level=5
hint.ahcich.3.pm_level=5
hint.ahcich.4.pm_level=5
hint.ahcich.5.pm_level=5

FreeBSDChina 最近又出现了很多垃圾广告等信息。针对一些常见的灌水机实现了一些临时的workaround，并且删除了大约3万2千的用户。

越忙越有人添乱。

补充：为论坛的链接增加了 rel=“nofollow” 的标记。

nginx可以作为很多种不同的用途。对Web服务器来说，nginx可以直接用作https服务器，也可以用于为现有的http Web服务器作为前端代理和负载平衡的同时提供https之用。

📜 历史文件已不具备现实意义

OpenLDAP 现已转为使用 lmdb。

今天帮陈总研究一个奇怪的问题的时候误操作导致机器停止ssh响应，遂请机房重启。由于机房做的是power cycle，导致部分数据丢失。先前在配置OpenLDAP时，忘记在其中配置checkpoint，另外也没有对这台机器的LDAP进行备份，因此只好尝试从现有的数据库中恢复。冗余不做，日子甭过；备份不做，十恶不赦！

记录一下修复过程。

第一件事是把出问题的数据库做一份备份：rsync -av /var/db/openldap-data/ /var/db/openldap-data.old/

接着尝试slapcat。出现下面的错误：

1
2
3
4
5
6

bdb(dc=********.com): file id2entry.bdb has LSN 1/1476384, past end of log at 1/374639
bdb(dc=********.com): Commonly caused by moving a database from one database environment
bdb(dc=********.com): to another without clearing the database LSNs, or by removing all of
bdb(dc=********.com): the log files from a database environment
bdb(dc=********.com): /var/db/openldap-data/id2entry.bdb: unexpected file type or format
bdb_db_open: database "dc=********.com": db_open(/var/db/openldap-data/id2entry.bdb) failed: Invalid argument (22).

尝试使用BerkeleyDB的修复工具修复：

1
2
3
4
5

# db_recover-4.6 -vvf
Finding last valid log LSN: file: 1 offset 374639
recovery 0% completeRecovery starting from [1][374527]
recovery 67% completeRecovery complete at Tue Jul 13 16:41:59 2010
Maximum transaction ID 800000c0 Recovery checkpoint [1][374639]

slapcat发现问题依旧。搜索Google发现答案基本上都是从备份中恢复，看了一下Oracle的网站，关于这类问题也没有很好的办法。尝试将bdb文件dump出来再load回去：

1
2
3
4
5

db_recover-4.6 -vvf
db_dump-4.6 id2entry.bdb > /tmp/id2entry.dump
rm id2entry.bdb
db_load-4.6 id2entry.bdb < ~/id2entry.dump
db_recover-4.6 -vvf

再次slapcat，发现对另一文件报错，用类似的方法修补之后，slapcat成功。

将slapcat的输出导出到一个文件中： slapcat > /tmp/my.ldif

然后，删除OpenLDAP数据目录：rm /var/db/openldap-data/_* /var/db/openldap-data/[a-z]*

最后，重新使用导出的ldif文件恢复：slapadd -l /tmp/my.ldif。

至此，恢复完成。

周末抽时间对网站做了一些调整。主要是把网站迁移到nginx上，不过遇到一些问题。Movable Type以FCGI::Spawn运行的时候，有时会反复出现先前的页面（例如，在mt.cgi上登录时，在提交登录之后仍会出现登录界面，而不是正常完成登录）。用ktrace看了一下FastCGI进程，结果发现之前看到的资料里面有相当多的小问题，但这个问题最终没有解决，暂时起了一个Apache来以cgi方式处理来绕过问题了。