林健的BLOG

　　上个月 iPad 上市后，我就常听到 idealee 和 heqian 同学鼓吹 MiFi 及其类似设备。说白了，那就是一个 3G-to-WiFi Adaptor。只要有一台同时支持 3G 和 WiFi 的设备，并且其系统相对开放，实现 MiFi 的功能就不难。笔记本电脑当然可以，不过体积大了点。正好我年前购入一台智器 V5，就用它来山寨一台 MiFi 吧。
　　智器 V5 的三个系统中，只有 Ubuntu 预装了 3G 驱动和拨号程序，那就在 Ubuntu 中实现。首先使用 USB OTG 连接 3G Modem，我这里是华为的 WCDMA Modem。智器最新版的固件不需要显式拨号，Modem 插入之后自动联网。然后使用 NetworkMananger 创建新的无线网络，为其设定名称（“miffy”如何？）和密钥，这样一来智器摇身一变成了无线 AP。现在试用笔记本电脑搜索周围的无线网络，很快就会发现智器的信号。连接之，密钥校验通过之后笔记本和智器便构成了局域网，使用 /sbin/ifconfig 可查看各自的 IP（在我这里为 10.42.43.*）。Ping 一下，连接正常。

　　下一步理应在智器上配置 iptables，将来自笔记本的数据包转发到 WCDMA 网络。智器的 Ubuntu 中虽然有 iptables 命令，然而运行后才发现这个 Linux Kernel 中的 ip_tables 模块已被裁减。用不了 iptables，就先找点简单的办法连接外网，比如 SSH 转发。智器的 Ubuntu 中预装了 OpenSSH 服务端，使用 sudo /etc/init.d/ssh start 命令启动即可。在笔记本上使用 ssh user@10.42.43.1 -D 7474 登录智器（不知道密码？那就先用 sudo passwd user 设置一下密码），然后将浏览器的 Socks 代理服务器设置为本地的 7474 端口。实验一下，访问网页正常。
　　智器电力相当有限，特别是同时打开 WiFi 和 3G 的时候。要把它当 MiFi 用的，最好加一个移动电源，比如我用的这块 4400mAh 锂电池。最终三个设备加其来的体积比 MiFi 大不少，但比起笔记本电脑还是可以接受的。其续航能力与笔记本相当，当然比不过专业的 MiFi。

　　哪位朋友有空研究着重新编译一下智器的 Linux Kernel，加入 ip_tables 模块？这样我们山寨的 MiFi 就更加完美易用了。从智器粉丝团的相关帖子看应该不难，有个 Mer-SmartQ 可用，需要的可能只是经验和时间。
　　附，iptables 可用之后，数据包转发所需要的配置：

　　受 @Sisyphusliu 师兄的启发，我最近决定试用 Amazon S3 来做个人数据同步与备份。初步计算发现这很可能比之前使用 VPS 或 Web 主机的方案要节约成本。我对三款面向 Amazon S3 的开源文件同步工具进行了对比，将其中部分细节说明如下，供有相同需求的朋友参考。
　　这三款工具分别是 jets3t、s3cmd 和 s3sync.rb。其主要特性和附加功能这里不再赘述，它们的官方主页都有详细说明。软件的稳定性还有待长时间使用的考验，但从网上没有发现用户反映太大的问题。我在这里强调它们存储文件元信息的差别，以及由此可能引发的问题。

　　由于 S3 基于 Key-Object 存储方式，与树型文件系统不同，因此如何将树型结构组织的文件及其元信息存储在 S3 中就是一个问题。这三款工具都将文件的全路径作为 Key，并把文件的元信息保存在 Object 的自定义属性中。
　　这样有什么后果呢？首先看目录。稍稍想想就会发现，像“a/b/c”这样的 Key 无法直接判定“c”是一个目录还是一个文件。s3cmd 的处理最简单，它的任何一个 Object 都是文件，不把目录作为 Object 保存。这样消除了歧义，但导致了目录的元信息无从保留，同时也无法保存空目录。而 jets3t 和 s3sync.rb 会保存目录的 Object，并通过元信息中的 Content-Type 来区别文件与目录。这样就保留了目录元信息，也允许空目录存在，但这影响了工具之间的互操作性。下载另一个工具上传的文件时，工具彼此不认识对方的目录 Object，就会将它们保存成普通文件，从而造成同名的目录无法创建。
　　再来看看文件的元信息。s3cmd 保存的 s3cmd-attrs 属性是一个包含了 uid、gid、uname、gname、mtime、atime、ctime 等信息的字符串，因此它保留了最完整的文件元信息。jets3t 只保存文件修改时间，无从得知属主与权限，不适合保存可执行程序的目录；s3sync.rb 只保存属主与权限，而且是数字 id 而非名字，在新系统中恢复数据时可能出现映射错误。
　　我个人倾向于选择 s3cmd。其一，文件修改时间和权限对于个人程序、文档来说是比较重要的信息。当然这不是技术问题，修改 jets3t 和 s3sync.rb 肯定也能做到。其二，不使用自定义的目录 Object 就允许一定程度的互操作，例如使用 jets3t 和 s3sync.rb 可以直接下载 s3cmd 上传的文件与目录结构（元信息丢失）。而 s3cmd 设计造成的目录元信息缺失、空目录消失等问题，对一般应用和文档来说不太重要、相对容易恢复。当然也可以使用额外的机制来记录目录元信息，但考虑 KISS 原则，s3cmd 目前的设计还是有道理的。要想同时解决元信息与目录问题，容易想到的办法是将目录打包或压缩再上传，这比较适于长周期的文件归档备份场景，但对于细粒度、短周期的日常数据同步场景并不适合。
　　至于云存储的信任问题，在现阶段我也只能选择折衷。一方面不要将鸡蛋放在一个篮子里，重要数据还是需要异地备份的。另一方面可以使用这些同步工具自带的安全机制，或自己稍加封装实现数据加密。
　　最后提醒大家，务必看看 Joel 的备份观。

　　IPv6 环境一般使用 DHCPv6 和 ICMPv6 协议自动配置网络参数，网关配置错误或多个网关的存在会导致客户端得到错误或冲突的配置参数。最近在我使用的 IPv6 环境中，就出现了网关同时给一个客户端分配多组 IPv6 地址、两个 IPv6 路由的问题，这使得路由发生混乱，IPv6 网络无法连通。由于种种原因，网管一直未能解决此问题，我们只好试图在客户端动动脑筋。
　　按照 IPv4 的经验，如果 DHCP 有问题，直接手工配置静态地址即可。但我们的环境中，即使手工配置了静态的 IPv6 地址和路由，发现没过多久又会恢复原状。看来还是有一定的自动配置机制在作祟。经搜索得知，这是 ICMPv6 的路由发现（Router Discovery）特性，系统会根据其收到的 ICMPv6 包自动修改 IPv6 配置。下面要做的就是过滤与路由发现相关的包。
　　在 Linux 下，可以使用 ip6tables（即 iptables 的 IPv6 版本）过滤相应的 ICMPv6 包：

　　可以将上述命令加入 /etc/rc.local。或使用 ip6tables-save 导出到文件，在启动网络前使用 ip6tables-restore 恢复。
　　在 Windows Vista/7 或 Windows Server 2008 以后的版本，可以使用这条命令：

　　执行一次之后持久生效，重启后不用再次执行。
　　而在 Windows XP 下，目前还没有发现很好的办法。XP 对 IPv6 的支持仅仅是一个“预发行版”，实现并不完善。手工配置 IPv6 地址和路由只能使用“ipv6 adu”、“ipv6 rtu”命令，而没有图形界面支持；虽然 XP SP2 以后 Windows 防火墙加入了 IPv6 支持，但仍不支持 ICMPv6。我没有查到 XP 下屏蔽路由发现协议的标准方法，目前可行的办法是使用支持 ICMPv6 的第三方防火墙软件，比如 ZONEALARM Internet Security 8 以上版本。

　　使用 web 主机而非 VPS 的站长，站点的备份或同步常常是一个问题。很多站点只能使用 ftp 做单向备份，基于较弱的元信息来判定文件是否需要重新下载，缺乏校验、压缩、增量传输等高级特性。有的服务商在 web 控制面板中提供备份功能，或允许上传简单的 cron 脚本，但这些途径通常只适合备份整站或指定目录，而不方便以增量方式传输更新过的内容。Linux 下成熟的镜像同步工具是 rsync，如果你的 web 主机允许 ssh 登录，则可以考虑使用 rsync 或其它类似工具。
　　网上有很多说法认为 web 主机不允许跑 daemon、不允许开自定义端口，故而无法使用 rsync。其实不然，rsync 可以仅通过 ssh 连接而不需要开放额外的端口，服务端也可以借助 sshd 来启动而不需要作为 daemon 运行。我们需要的只是 ssh 登录以及运行自己上传的程序的权限。我使用的 Godaddy Economy Plan Hosting (Linux) 即属于这种情况。
　　Godaddy 的 web 主机不提供 rsync 程序，我们可以从本地上传一个。需要注意上传的 rsync 二进制文件应该与你的 web 主机的平台一致，连接 libc、libpopt 等库的版本一致。对于使用 x86 版 CentOS 5.2 的 Godaddy 主机，我也直接在相同版本的 CentOS 中提取了一个 rsync 上传。这时，在客户端使用“-e”参数指定连接方式为 ssh，用“--rsync-path”参数指定服务端 rsync 所在的位置，即可借助 ssh 连接传输数据了。

　　如果客户端为 Windows，则可以使用 Win32 下移植的 cwRsync，这个工具基于 cygwin 库但不需要安装整个 cygwin 环境，它同时包含了 Win32 版的 OpenSSH 客户端。上述命令无须修改即可在 Windows 下运行。
　　rsync 解决了文件的单向的备份或镜像功能，但如果需要双向同步，更适合的工具是 unison。unison 使用 OCaml 语言开发，基于 rsync 算法对两端文件进行比较，将它们更新到一致的状态（最新的、不冲突的版本）。unison 可借助 socket、ssh 等连接方式，并支持多种操作系统。与 rsync 类似，我们需要向 web 主机上传一个 unison 二进制文件。官方只提供了最新版的源代码，需要自行下载到本地编译（事先安装 OCaml 编译器及 etags 工具）。服务端部署之后，客户端配置文件（[config_name].prf）为：

　　在客户端执行 ./unison [config_name] 即可完成双向同步。注意 unison 要求服务端和客户端的主次版本号一致。
　　如果客户端为 Windows，同样可以使用来自 cwRsync 的 ssh 命令。如果嫌这个 ssh 外加 cygwin 库的体积太大（~5M），另一种替代的方案是使用 Putty 提供的 Plink 工具。这是一个小巧的 Win32 ssh 客户端（276K），由于运行参数与 OpenSSH 不同，因此需要写一个批处理文件（ssh.bat）来封装：

　　并在 unicon 配置文件中指定 ssh 命令：

　　此时运行 unicon，即可使用 Plink 进行 ssh 连接。
　　无论使用 OpenSSH 的 ssh 还是 Putty 的 Plink，都可以借助公钥认证方式避免密码的输入。这样有利于定时备份和同步的自动化执行。具体方法不再赘述。

　　前面三篇文章分别介绍了三类已经投入实际使用的、独立的 Identity 2.0 机制。与此同时很多在互联网时代既得利益的公司也都试图借助自己庞大的用户资源在身份认证领域分一杯羹。微软的 Windows Live ID（早期称为 .NET Passport、Microsoft Passport Network）算是动手比较早的，Google Account Authentication、Yahoo! BBAuth、Facebook Connect 等是各家公司推出的类似的身份认证服务。但这些服务本质上不符合 Identity 2.0“以用户为中心”的精神，它们仍使用原有的集中式用户系统，由这几家大公司自己维护用户数据，仅允许其它网站借助其 API 验证用户身份，读取用户的非敏感信息。这类技术的用户价值在于单点登录和相对安全（类似于 OpenID），单点失效问题通过内部对用户透明的分布或容错机制实现（目前阶段，这几家大型网站的可靠性相比小型的 OpenID provider 更有技术保障，至少用户的心理体验是这样）。对小型网站的经营者来说，让拥有 Google、Yahoo、Facebook 账号的用户直接登录自己的网站，同时能从知名网站获得用户的部分注册信息，确实有一定的吸引力。目前已经有像 clickpass 这样集成各家身份认证的第三方服务。而对于想为第三方网站提供身份认证服务的普通网站来说，开放的 OAuth 协议可以直接在既有系统中集成，twitter、豆瓣等是其成功案例。但 OAuth 更多地用于与提供身份认证的网站息息相关的第三方应用开发，还不能算是一种通用的身份认证机制。

　　此外还有一系列或是没有走出实验室、或是没有着力推广的 Identity 2.0 技术。关于它们的讨论可以通过以下一些网站获取：
　　● Identity 2.0 Blog
　　● Identity Commons Wiki
　　● Internet Identity Workshop
　　我们回过头来看，Identity 2.0 概念的提出大约有五年了，而事实上像 Microsoft Passport Network 之类的原型产品的推出是更早之前的事。但即使是现在发展情况最好的 OpenID，支持它的独立公众网站也维持在三位数之内。而看看上述几个网站，文章和项目的活跃程度也在逐渐下降，不少链接失效。Identity 2.0 为什么没有像 Web 2.0 那样大放异彩？这个问题值得业内人士思考。我列出以下几点：
　　“鸡与蛋”的问题——要想让基础设施（互联网标准、客户端软件）支持 Identity 2.0 的特性，就需要用足够的杀手级应用来说明其重要性；而要建立有影响力的杀手级应用，又需要基础设施的原生支持。要让用户接受并广泛使用 Identity 2.0 的个人身份，就需要有大量的既有应用启用 Identity 2.0 机制；而要让现存的网站加入对 Identity 2.0 的支持，又需要广大持有 Identity 2.0 身份的用户来诱发。
　　使用的体验的改变——普通用户可能不会理解 OpenID 这种 provider 中介模式的安全优势，因为在用户看来还是要输入一次用户名密码的，而且是把密码交给了第三方。对于 Information Card，用户可能难以习惯长期保存并随身携带 Card 文件的使用模式，在经历了一两次 Card 丢失或一时无法取得的情况，就会打击用户的使用兴趣。而如果在线保存 Information Card，又存在和密码托管网站一样的信任危机。至于基于 XRI 的 i-name，普通用户可能也不愿意为其缴纳年费。
　　安全性问题——这是任何一种身份认证机制都必须首先保证的。各类 Identity 2.0 技术都宣称自己的协议比传统方式安全，这不假，但它们的前提假设是：provider 等第三方机构确实可信；用户按照一定的规程来使用（比如不随意复制未加密码的 Information Card）。如果 provider 作恶或者用户不遵守使用规程，同样会造成信息泄露。provider 作恶在其它分布式系统中是存在的（比如 DNS 欺骗、虚假 Tor 节点等），难免在 Identity 2.0 中重演；而引入新的用户体验之后，要求用户掌握其操作原则是有时间成本和运营风险的。
　　用户价值的体现——我认为这是核心因素。Identity 2.0 究竟能不能给用户带来全新的使用价值？是否满足普通用户和网站经营者双方的利益需求？身份认证方面的创新能否给互联网带来足够大的积极影响？这些问题不是纯粹的技术问题，有待市场来检验。但 Web 2.0 时代用户是重要的资源，如果将用户系统拱手交出，全线采纳 Identity 2.0，或许是一些既得利益者不愿意看到的。即使对于普通用户，像单点登录、一卡走天下这样的特性真的是大众的需求吗？也许更细的授权粒度、站点独立的密码设置才能让一部分人放下心来。
　　我们不能过早地断言 Identity 2.0 会走向失败。也可能是早期定义的 Identity 2.0 过于激进，我们来看看 OpenID 现在的发展：在多数网站中没有完全取代传统的身份认证机制，而是作为它们的补充；通过底层的服务发现协议来和 LID、i-name 等兼容（最近 Windows Live ID 也要和 OpenID 兼容了），力图建立统一且开放的 Identity 2.0 平台。这种渐近式的、开放包容的路线，应该是 Identity 2.0 的生路所在。