林健的BLOG

　　使用 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，都可以借助公钥认证方式避免密码的输入。这样有利于定时备份和同步的自动化执行。具体方法不再赘述。

　　场景：假设实验室的打印机距离你的工位比较远，现需要打印一些文章，但不知道打印机里有没有放纸、是不是合适的纸（A4/B5；新纸/旧纸反面）。贸然打印有可能造成浪费，而如果把合适的纸拿过去放进打印机再回来发送打印命令则需要跑两个来回，中途别人还有可能发送打印命令把你的纸给用了。懒人有懒道，要是能在打印机旁遥控电脑就好了！想想用什么做遥控器呢？身边最好找的远程通信器件应该是手机了。于是，我们来实现基于手机遥控的远程打印（以 Windows 环境为例）——
　　我的手机可以使用语音、短信、红外、蓝牙、GPRS 等通信手段，软件支持 Email、MSN、Gtalk、Fetion 等应用。考虑到成本，排除语音和短信；考虑到距离，排除红外和蓝牙；Email 没有实时性，也排除；剩下三个 IM，其中基于 Jabber 的 Gtalk 由于其简单性和开放性，成为了我的首选。
　　接着考虑如何操作应用程序进行打印。对于 Windows GUI 的自动化操作，AutoHotkey (AHK) 大神当然是不二之选。
　　现在可以动手了。首先建立一个 Jabber Message Handler 来接收手机 Gtalk 客户端发来的消息。如果收到事先定义好的某个消息，则通知特定的应用程序执行打印操作。这种简易的 Handler 用 Python + xmpppy 实现即可，代码如下（gthandler.py）：

　　这段代码很好理解。Handler 端使用“yyy@linjian.org”账号登录 Gtalk，如果收到来自手机端联系人“xxx@linjian.org”发来的“p”消息，则执行 doprint.ahk 脚本。该 AHK 脚本负责向应用程序发出打印命令（这里是以 Microsoft Word 为例的，向 Word 发送 Ctrl-P 并回车，即可使用默认打印机来打印文档），内容如下：

　　好了，现在打开 MyDoc.doc，再运行 gthandler.py，然后在手机上登录 Gtalk，从“xxx@linjian.org”向“yyy@linjian.org”发送一个“p”，看看有没有效果？当然，实验时可以先用 Ctrl-G 之类不浪费纸的命令做测试。
　　这就是程序员，本来可以通过内线电话或免费的 VPMN、利用社会工程学手段解决的问题，也要设法把它程序化了。这到底是折腾呢，还是不折腾呢？但至少有一点是肯定的：脚本的优点是一劳永逸。

As you know that some web 2.0 services, such as twitter web clients, URL shorteners, and picture hosting services cannot be accessed steadily in Mainland China. Perhaps you know how to break through the “wall”, but as information promulgators, we would better make our resources accessible for masses without special network skills or the lazy ones. A few months ago, I wrote Imagoxy, a picasa proxy for my blog readers. And these days a private URL shortener and a private picture hosting service are built for my twitter followers.

I chose a free PHP hosting service with advertisements to host these web applications. For one thing, I do not want my paid host be punished for being related to them accidentally, while free spaces are easily replaceable. For another, advertisements are only appended to htmls, and yet URL forwarding and picture files are not affected.

There are lots of free URL shortener scripts based on PHP and MySQL. I prefer TightURL, which is relatively simpler than the others, since web pages with rich features such as AJAX may go wrong for appended advertisements. Apache's RewriteEngine should be enabled to make the short URL more graceful. And you can also modify “tighturl.*.tmpl” to make it more friendly to users and external caller scripts. Like most of public URL shorteners, TightURL can be dragged into browser's bookmarks for convenience.

I had not found a free and simple enough PHP application to host pictures for twitter. So I wrote a tiny script for myself. It saves uploaded picture and send a tweet via twitter API (with shortened URL). I employed PHP Twitter to call twitter API for its simplicity. The script is accessible from my cellphone, so I can upload the taken photos instantly. I will release the script after more security measure taken.

More services can be deployed on free / advertisement web hosting sites. However, these sites are also usually banned by the “wall”. You should backup your data periodically and be ready to migrate at all times. The only unaltered entrance for your twitter followers is your domain name – unless you have too much influence infuriating somebody.

At last, my private services' domain name is “Jian.me”. It originates from my given name. It's interesting that “Jian” can be thought as “简” or “减” for URL shortener using.

　　晚上为 Nokia S60v2 老机型用户写了一个 PC 端的小工具——vCard Assistant，用于将含有中文姓名的 vCard 文件（可以是 GB、UTF-8 或 UTF-16LE 编码的）转换成 ASCII 字节编码 UTF-8 形式；并可将 vCard 3.0 格式转为 2.1 格式，便于在某些对 vCard 中文姓名或 3.0 标签支持不好的手机中导入联系人。效果如下：
　　输入：

BEGIN:VCARD
VERSION:3.0
N:;张三
FN:张三
TEL;TYPE=CELL;TYPE=VOICE:13811112222
EMAIL;TYPE=PREF;TYPE=INTERNET:foo@bit.edu.cn
REV:20090901T035836Z
END:VCARD
BEGIN:VCARD
VERSION:3.0
N:;李四
FN:李四
EMAIL;TYPE=PREF;TYPE=INTERNET:bar@gmail.com
REV:20090901T035835Z
END:VCARD
...

　　输出：

BEGIN:VCARD
VERSION:2.1
N;ENCODING=QUOTED-PRINTABLE;CHARSET=UTF-8:;=E5=BC=A0=E4=B8=89
FN;ENCODING=QUOTED-PRINTABLE;CHARSET=UTF-8:=E5=BC=A0=E4=B8=89
TEL;CELL;VOICE:13811112222
EMAIL;PREF;INTERNET:foo@bit.edu.cn
REV:20090901T035836Z
END:VCARD
BEGIN:VCARD
VERSION:2.1
N;ENCODING=QUOTED-PRINTABLE;CHARSET=UTF-8:;=E6=9D=8E=E5=9B=9B
FN;ENCODING=QUOTED-PRINTABLE;CHARSET=UTF-8:=E6=9D=8E=E5=9B=9B
EMAIL;PREF;INTERNET:bar@gmail.com
REV:20090901T035835Z
END:VCARD
...

　　这种格式可以被 Best vCard for S60 等软件读取，导入手机通信录。
　　vCard Assistant 下载地址（包含源代码）：
　　http://files.linjian.org/dotNet/VCardAssistant.zip
　　http://www.linjian.cn/files/dotNet/VCardAssistant.zip
　　（需要 .Net Framework 3.5 平台支持）

---

　　我为什么要写这个东西呢？主要还是自己的需求。我使用的 Nokia 6600 的 PC Suite 只支持从 IBM Lotus Notes、Microsoft Outlook 这类庞大的程序或 Windows Address Book 这种已被放弃的格式中导入联系人。我没有使用这两个商业软件，也不愿使用已经失去官方支持的 WAB 格式，而选择使用跨平台的、广为各类软件支持的 vCard 格式管理联系人，以便在多个系统、软件中直接共享。以前同步联系人时，先将 vCard 导出为 CSV，再使用虚拟机中的 Windows XP 通信录将 CSV 转换成 WAB 格式，然后通过 PC Suite 同步，比较折腾。现在只需要将 vCard 转换一次，通过蓝牙或 Email 发到手机上，用手机端的软件做同步，简便不少。
　　事实上我以前也尝试过用 Google Sync 服务在线同步联系人（Gmail 也支持 vCard 导入导出），但同步过程总是异常停止。换用其它一些 SyncML 同步服务问题依旧。最终我在 mobical 网站发现一句话：“Nokia 6600: This device has a known issue where the synchronization may stop working at any time. As far as we can tell this is a bug in the Nokia software.”原来这是 Nokia 6600 的 bug……我也没有找到其它免费的 SyncML for S60v2 客户端，只能作罢。

　　Native Client（简称 NaCl）和 Xax 分别是 Google 和 Microsoft 近一年来开展的有关在 web 浏览器中安全执行本地代码的研究性工作。它们都已有实验原型，其功能类似于现在的 ActiveX，但相比只能在 IE 中运行的 ActiveX，二者都支持跨操作系统、跨浏览器运行（Xax 还声称可以跨体系结构），同时具备比 ActiveX 更完善的安全模型。这类在本地系统直接运行的代码相比 Flash、Silverlight、Java Applet 等虚拟机、JIT 机制，在性能、功能灵活性方面有优势，也便于移植遗留应用。
　　NaCl 是开源的，其项目主页提供了大量的文档和示例程序，并开放了讨论区。加之 Google IO 大会的宣传，它得到了行业和媒体相对较多的关注，不少人认为它会成为“ActiveX 杀手”。而 Xax 在网上只有一个简单的论文页面，官方没有提供实验产品和更详细的资料下载，因此网络上关注它的文章很少，可能只在学术界为人知晓。
　　NaCl 和 Xax 已发表的论文分别是：
　　● Native Client: A Sandbox for Portable, Untrusted x86 Native Code
　　● Leveraging Legacy Code to Deploy Desktop Applications on the Web
　　从论文可以看出两项工作的侧重点有所不同。NaCl 的论文发表在 S&P/Oakland 2009，主要在论证其模型的安全性，欲打造一个安全且跨平台的 ActiveX 替代品；而 Xax 的论文发表在 OSDI 2008，更强调其软件结构的特性利于遗留应用快速移植到与操作系统、浏览器无关的 web 平台。
　　NaCl 的结构比 Xax 简单，更类似于 ActiveX。它通过浏览器插件加载应用代码，创建一个沙盒进程来执行不可信的代码，直接在浏览器窗口中输出结果。不可信的代码不能直接访问本地文件系统和网络接口，而可以通过 IMC（Inter-Module Communications）间接调用一些可信的服务模块来访问本地资源。这些模块也是一些浏览器插件，可以通过它们实施安全策略。因此，NaCl 客户端安装和运行过程不需要特殊权限。Xax 的结构相对复杂，它的浏览器插件称为 Xax Monitor。Xax Monitor 包含一个 web proxy，浏览器的 HTTP 流量均要经过它。当 Xax Monitor 发现有 Xax 应用的链接时，它会从远程下载 Xax 应用。Xax Monitor 将下载来的应用代码与 PAL（Platform Abstraction Layer）模块连接，作为本地进程（称为“picoprocess”）运行。picoprocess 通过共享内存与 Xax Monitor 交互，由 Xax Monitor 为其执行封装过的、有限的、安全的系统调用（称为“xaxcalls”）。Xax Monitor 同时作为本地的 web server，通过 HTTP 消息与浏览器通信，处理浏览器到 picoprocess 的输入输出。Xax 使用系统特定的机制（Linux 的 ptrace 或 Windows 的虚拟设备驱动）来保证安全，在 Windows 下安装时需要超级用户的权限。
　　NaCl 修改了一套 C/C++ 工具链，开发人员下了大量工夫让这套工具链生成的二进制代码安全可靠。其中包括严格的指令对齐、禁用系统调用和中断（只能通过 IMC 间接调用系统服务）、安全的跳转指令等。使用自己的加载器，使得不含系统调用的二进制代码可以跨操作系统加载执行（限于 x86 平台）。Xax 完成的工作类似，生成代码安全方面没有像 NaCl 那样严格控制，而是通过在运行时使用 Linux 的 ptrace 或 Windows 的虚拟设备驱动来阻止恶意添加的系统调用，同时接管内存分配工作，安全地管理堆上数据分配。
　　Xax 所谓的跨体系结构，目前是在 x86 和 PowerPC 平台上分别做了 ABI（Application Binary Interface）各异的实现，因此运行在不同体系结构上的应用的二进制代码并不能互相兼容，只是说 Xax 机制已能在不同的体系结构上成功实现。作者提出可以用 Binary rewriting 的方法使得 x86 代码在其它平台上翻译执行，做到真正的跨体系结构，不知道现在实现没有。
　　NaCl 的图形输出与本地程序渲染基本无异，用户体验较好，官方给出的 Quake 示例运行得很流畅（下图是在我的 Ubuntu 9.04 / Firefox 3.5 上运行的截图）。而对于 Xax，浏览器只能通过 HTTP 与连接到 Xax Monitor 的 picoprocess 通信，浏览器中的应用界面目前只能使用 HTML、Javascript 等已有技术渲染。论文中给出的 OpenGL 3D 示例使用 PNG 贴图的方式模拟动画输出，达到了 8.8 fps，用户体验比 NaCl、ActiveX 差一些。但相信加强浏览器插件的能力可以改善效果。

　　由于 Xax 没有提供下载试用，所以不方便对比二者实际的编程难度和用户体验。个人感觉从用户角度而言，NaCl 似乎是一项更有吸引力的技术，简单地说它就是安全的、跨操作系统和浏览器的 ActiveX。而 Xax 在部署方式（权限）和界面交互效果方面还有欠缺。从开发人员角度来说，使用 NaCl 或 Xax 开发新应用或移植遗留应用都需要把原来使用系统调用的地方修改成调用 NaCl 可信服务模块或 xaxcalls，同时需要重写界面和 I/O 相关代码。NaCl 对代码有更严格的要求，比如不能使用部分不安全的标准库函数、不能滥用不安全的内嵌汇编指令等。而 Xax 的论文认为向 Xax 移植遗留应用是一件程序化的事，只要按照几个步骤去做，很多修改的代码可以复用。估计类似的步骤也可以应用于 NaCl，从 Quake 的成功移植可以看出 NaCl 在这方面应该不差。