美国西海岸及阿拉斯加地区海啸警报中心

| AsiaBSDCon | Life

住在西海岸的同学可以在 West Coast and Alaska Tsunami Warning Center 这里找到相关的信息,以及对这次本州地震的海啸模拟。

从美国地震局网站上 ,余震仍然在继续中。

另外,今年的 AsiaBSDCon 仍会如期举行。

参与评论

ZFS dedup初步测试

| *nix and Win32 Kernel

最近做一个存储的项目,顺手在家测试了一下实际数据的dedup。操作系统是 FreeBSD 8.2 配合一组总共大约3MB的patch来跑ZFS v28,硬件是 Atom D510 配合 4G 内存。

阅读全文…( 本文约 667 字,阅读大致需要 2 分钟 )

tarsnap修正了一个重大安全漏洞

| Security

今天 Colin 在blog上介绍说 他刚刚修正了一个 TarSnap 重大安全漏洞。简单地说,用来加密密钥文件的AES-CTR实现时,计数器没有增加(正确的实现中计数器应该每次递增),导致在已知明文时能够通过加密块推算出一块数据使用的密钥,并用它来解密余下的数据。

阅读全文…( 本文约 272 字,阅读大致需要 1 分钟 )

作弊条:git配合svn的一些使用方法

在一个git库中跟踪不同的svn branch

首次创建git库:git svn clone [svn代码库到HEAD分支的URL] [git代码库名]

例如,对于 FreeBSD,对应的URL为 http://svn.freebsd.org/base/head/

一般来说,从远程svn库复制需要的时间会比较长,也可以考虑首先在本地建立一份镜像,然后直接用 file:/// 去指定。

阅读全文…( 本文约 559 字,阅读大致需要 2 分钟 )

折腾了一下 neptune 上的 ZFS

| *nix and Win32 Kernel

我一直是非常反对重装系统的。从技术上说,今天的折腾并不算是重装系统,不过因为把机器上所有的数据(是的,文件系统全部都拆掉重建了)都重写了一遍,所以还是算做了一次吧。

缘起

在采购 家里的路由器 的时候,选择了 WDAV-25【1】 系列硬盘。我选的那款硬盘使用的是新式的 AF (4kiB扇区)格式。

FreeBSD 使用的主流文件系统 UFS 和 ZFS,以及 ahci(4) 驱动都 直接支持 4kiB 扇区。但是,目前市面上的AF硬盘,为了与先前的 BIOS 和操作系统(主要是 Windows XP)兼容,对于 ATA IDENTIFY 的回应,原先返回扇区尺寸的位置变成了逻辑扇区尺寸,这种做法俗称512e,即硬盘通过固件或其他方式模拟山区尺寸为512字节,并处理相关的回写操作。

以512字节为单位进行读写时,在AF格式的硬盘上是低效的。FreeBSD的 ahci(4) 驱动和对应的 ada(4) 驱动会设置 stripesize 以反映驱动器采用的实际物理扇区尺寸,但文件系统并不直接识别这个尺寸。

对于 ZFS 而言,其扇区尺寸是在创建时以 ashift 值写死的,目前在命令行没有办法指定这个值,也不能在创建 ZFS 之后修改。如果修改内核令其使用 GEOM 的 stripesize 来产生 ashift,对 AF 硬盘则会出现内核得到的 ashift 比先前已经存在的 ashift 大,从而导致 ZFS 无法识别的问题(如果创建 ZFS 时已经使用了更大的 ashift 则没有关系)。因此,必须想办法让 ZFS 在创建时就知道扇区尺寸是 4KiB。

FreeBSD 5.3-RELEASE 时新增了一个调试用的 GEOM class —- gnop。可以用它来封装其他 GEOM 对象,并改变扇区尺寸,方法是 gnop create -S 4096 /dev/gpt/store (此处 /dev/gpt/store 是一个按 4k 对齐的 GPT 分区的 label)。gnop会产生一个新的设备节点,/dev/gpt/store.nop,其向系统汇报的扇区尺寸是我们指定的 4096 字节,而不是驱动器汇报的逻辑扇区尺寸 512 字节。

使用这个设备节点创建的 ZFS 就会采用正确的 ashift 值了。

使用 zdb -C pool名字可以检查 ashift 值:对于扇区尺寸为 512 字节的 zpool,其 ashift 是 9,而我们希望的 ashift 值是12。

gnop节点在系统重启以后会消失,但 ZFS 会记住 ashift,因此并不会导致问题。此处也可以 zpool export,gnop destroy /dev/gpt/store.nop 然后再 zpool import 来验证。

经测试,ZFS在知道正确的扇区尺寸以后,持续写操作的性能可以提高至少一倍。

阅读全文…( 本文约 2314 字,阅读大致需要 5 分钟 )

在服务器上用gpg-agent

| Security

上回书说到通道服务器的问题。在 /etc/csh.cshrc 中添加下列内容,可令系统同时启动 gpg-agentssh-agent

1
2
3
4
5
6
7
setenv SSH_AUTH_SOCK    /dev/null/nonexistent
if ("${TERM}" != "su") then
        [ -e ~/.gpg-agent.csh ] && source ~/.gpg-agent.csh >& /dev/null
        echo UPDATESTARTUPTTY | /usr/local/bin/gpg-connect-agent >& /dev/null || /usr/local/bin/gpg-agent --daemon --ignore-cache-for-signing >& ~/.gpg-agent.csh && source ~/.gpg-agent.csh >& /dev/null
        [ -e ~/.ssh-agent.csh ] && source ~/.ssh-agent.csh >& /dev/null
        [ -e ${SSH_AUTH_SOCK} ] || ssh-agent -c -t 20m >& ~/.ssh-agent.csh && source ~/.ssh-agent.csh >& /dev/null
endif

启动 gpg-agent 的作用是在一段时间内不用重新输入 gpg 的密码。

阅读全文…( 本文约 412 字,阅读大致需要 1 分钟 )

ZFS的自动化备份

| Others

主任说:

冗余不做,日子甭过;备份不做,十恶不赦。

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

脚本没啥复杂的,大体的思路是这样:

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

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

阅读全文…( 本文约 704 字,阅读大致需要 2 分钟 )

一个简单的密码生成器

| Security | #password generator

我个人比较喜欢复杂的随机生成的密码。是一个JavaScript的密码生成器,完全裸奔的界面,可以自行设定字母、数字和特殊符号出现的概率(默认是字母=3×52,数字=7×10,特殊符号2×27,或者78:35:27的关系)。

使用方法很简单,设置参数之后按Generate按钮,系统会随机生成希望数量的随机密码。然后从里面挑一个自己觉得容易记住的就可以了。

阅读全文…( 本文约 241 字,阅读大致需要 1 分钟 )

FreeBSD基金会年终募捐

| Life | #FreeBSD Foundation | #Fundraising

再发一次。

FreeBSD基金会是符合美国税法501(c)3款的非盈利慈善机构,它为 FreeBSD 的开发以及全球范围内的开发者会议活动提供资助,并帮助 FreeBSD Project 的开发人员提供法律咨询。

阅读全文…( 本文约 252 字,阅读大致需要 1 分钟 )

IPv4终于快用完了

| Others

在很久很久以前就有人提出IPv4将要用完的事情,然而当时IPv4地址空间还很充裕,而且NAT还没有非常广泛地使用。于是这事说着说着就变成了一个狼来了的故事,不停地有人嚷嚷IPv4地址要用完了,而这个用完的日期则在600天、400天和300天附近的时候反复来回地拉锯了很久。

和狼来了那个故事稍微不太一样的是,喊狼来了的那些人,例如大的IPv6 ISP和运营商已经早早做好了准备,而那些把这故事当做狼来了而毫无警惕的人则只好手忙脚乱地应付了。

阿宅的一大恶趣味是喜欢仅仅因为"Because we can"而去做一些事情,我也是。我自己的网站的第一个DNS AAAA记录是2007年7月31日创建的,而FreeBSDChina.org于2007年8月4日也已经开始在IPv6上提供服务。由于当时条件所限,在当时我能够使用的唯一的测试手段是登录到一台位于北美的有双栈支持的测试服务器来进行测试。到了北美以后,因为这里的住户 IP 地址是很少发生变化的,我开始在家搭建 IPv6 路由,到后来在北美地区托管了一台服务器,基本上一直都是以双栈的方式接入Internet了。目前,我拥有两个/48的IPv6地址段和两个/64的IPv6地址段。

时间过得很快。今年年初的时候我看到了一个报道说 IPv4 地址大约还剩不到1年了,于是开始关注相关的报道。根据 Hurricane Electric 的估算,今天距离 IPv4 中央地址池的地址耗尽还有大约 47 天。中央地址池的耗尽对最终用户并不会产生立即而直接的影响(总有各种各样的办法来减少IP地址的占用,大企业或者ISP可以用NAT,双层甚至三层NAT等技术来减少实际使用的IP,等等),但是无论如何,我们之前所熟悉的那个互联网的日子已经所剩不多了。

阅读全文…( 本文约 1547 字,阅读大致需要 4 分钟 )