今天在搞 guaobackup 时遇到了一个非常奇怪的问题：通过 Windows Live Writer 发布的帖子中 html 标记的 <> 都被自动过滤掉了，要说 wordpress 自己也搞过很多个了，但是这样的问题还真是第一次遇到，而且仔细查看 wordpress 和 wlw 的设置后也没有发现类似的设置可以修改。

貌似我 blog 的帖子都是 google 找到答案。。。难道还能是百毒吗？原来这是 lib-xml2 2.6.30 到 2.7.3 之间的版本存在 bug，这篇文章很详细的讲述了这个 bug 的起因。解决办法：

1. 修改 wp 源程序，刚才那篇文章中有办法，不推荐，以后升级很麻烦。
2. 重新编译 php，用 expat 这个 xml 解析器替代 libxml2。
3. 用这个 wp 插件凑合一下。
4. 也就是最彻底的解决办法：把 PHP 升级到 5.2.9 以上，libxml2 升级到 2.7.3 以上的版本。

虽然我用的是 php 5.3.3，但是在 phpinfo 中看到 dotdeb 这个 package 居然是用 libxml2 2.6 编译而来的，难怪存在这个问题。顺手把服务器做了个系统升级到 Ubuntu 10.10，php 和 nginx 也都用官方源和 ppa 升级到最新版，问题解决。

安装 mysql：

sudo aptitude install mysql-server

使用官方 ppa 安装 nginx：

sudo aptitude install python-software-properties
sudo add-apt-repository ppa:nginx/stable
sudo aptitude update
sudo aptitude install nginx

安装 phpy + php-fpm + 其他模块：

sudo aptitude install php5-cgi php5-mysql php5-fpm php5-curl php5-gd php5-idn php-pear php5-imagick php5-imap php5-mcrypt php5-memcache php5-mhash php5-ming php5-pspell php5-recode php5-snmp php5-sqlite php5-tidy php5-xmlrpc php5-xsl

配置 php：

sudo vi /etc/php5/fpm/php.ini

设置

cgi.fix_pathinfo=0

原因见这里。接下来修改 nginx 虚拟主机设置：

sudo rm -r /etc/nginx/sites-available
sudo rm /etc/nginx/sites/default
sudo vi /etc/nginx/sites/default

内容，我这里 IPv4 和 IPv6 用了两条独立的命令监听，原因见这里。

server {
        listen   [::]:80;
        listen   80;
        server_name  xxx.xxxxx.xxx;
        root   /var/www/;

        #access_log  /var/www/log/xxx-access.log;
        #error_log   /var/www/logs/xxx-error.log;

        location / {
                index  index.php index.html index.htm;
        }

        #error_page  404  /404.html;

        # redirect server error pages to the static page /50x.html
        #
        #error_page   500 502 503 504  /50x.html;
        #location = /50x.html {
        #       root   /var/www/nginx-default;
        #}

        location ~ \.php$ {

                fastcgi_pass   127.0.0.1:9000;
                fastcgi_index  index.php;
                include        fastcgi_params;
        }

        location ~ /\.ht {
                deny  all;
        }
}

修改 fastcgi 参数，

sudo vi /etc/nginx/fastcgi_params

加入：

fastcgi_param  SCRIPT_FILENAME    $document_root$fastcgi_script_name;
fastcgi_param  PATH_INFO          $fastcgi_script_name;
fastcgi_connect_timeout 60;
fastcgi_send_timeout 180;
fastcgi_read_timeout 180;
fastcgi_buffer_size 128k;
fastcgi_buffers 4 256k;
fastcgi_busy_buffers_size 256k;
fastcgi_temp_file_write_size 256k;
fastcgi_intercept_errors on;

重新启动 nginx 和 php-fpm，配置完成：

sudo /etc/init.d/nginx restart
sudo /etc/init.d/php5-fpm reload

http://www.xxx.com/ucenter/avatar.php?uid=21480&size=middle

但是调用后的地址就变成了：

http://www.xxx.com/ucenter/avatar.php/ucenter/data/images/000/05/60/39_avatar_middle.jpg

查看源代码发现，discuz 中的相对路径都是直接写的文件名，前面没有 ./，与此同时还带来了批量上传 flash 文件无法调用 misc.php 导致提示文字无法显示，引用及提醒信息跳转地址错误等，一概都是由于指向了错误的 xxx.php/dir 这样的 url。感觉不应该是 nginx 的问题，于是查看 php.ini 相关设置，发现 cgi.fix_pathinfo 这个选项正是解决问题的关键，将这个值设置为 0 的话，PATH_TRANSLATED 将等同于 SCRIPT_FILENAME，之后重启 php-fpm 后 discuz 的这个问题就解决了。看来还是 discuz 7.2 代码兼容性的问题，不知道更新的 dzx 是否已经有所改进了？

UPDATE：发现今年5月有一个相关的 nginx 漏洞，可以参考。

PS：这篇 blog 是我第一次尝试安装 nginx 时候写的，有不少配置不合理的地方，更好的配置请参考这篇文章。

由于最近谷奥的负载实在比较大，究其根本除去 WordPress 本身程序的问题外，很大一部分原因在于 Apache 的低效。虽然谷奥更换了更强劲的 Xeon x3370 CPU，但是还是未雨绸缪试了试传说中可以承受 Apache 10 倍负载的 Nginx，安装环境为 运行 Debian Lenny 的 VPS。

1，安装 Nginx：

aptitude install nginx

搞定了。。。打开 80 端口看一下吧，应该已经 Welcome to nginx 了。

2，安装 php5：

aptitude install php5-cgi php5-mysql php5-curl php5-gd php5-idn php-pear php5-imagick php5-imap php5-mcrypt php5-memcache php5-mhash php5-ming php5-pspell php5-recode php5-snmp php5-sqlite php5-tidy php5-xmlrpc php5-xsl

如果你还需要什么变态模块的话尽管往上加好了

修改 php.ini

vi /etc/php5/cgi/php.ini

在最后加入一行

cgi.fix_pathinfo = 1

接下来要让 php-cgi 以一个 daemon 形式运行，基本有以下几个方法：

• php-cgi 本身使用 -b 参数
• lighthttpd 自带的 spawn-fcgi
• Python 脚本 supervisord
• PHP-FPM（Fast Process Manager），很多高负载服务器上使用的是这个，即将进入 PHP 的 Trunk。

这里有 php-cgi, spawn-fcgi 和 PHP-FPM 的一些细节比较。

这里我们使用 spawn-fcgi。

借用 lighthttpd：

aptitude install lighttpd

安装的最后启动 lighthttpd 的时候会提示你启动失败，80 端口已经被占用，这是正常的，因为 nginx 正在那里跑着，所以不用管它。安装完成后将 lighthttpd 从 rc 里面删除

update-rc.d -f lighttpd remove

我们可以用如下命令启动 spawn-fcgi

/usr/bin/spawn-fcgi -a 127.0.0.1 -p 9000 -u www-data -g www-data -f /usr/bin/php5-cgi -P /var/run/fastcgi-php.pid

可以将其加入 rc.local，以后每次开机自动启动

编辑一下 nginx 默认虚拟主机的配置文件，加入 php 支持

vi /etc/nginx/sites-available/default

修改成

# pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
#
location ~ \.php$ {
fastcgi_pass   127.0.0.1:9000;
fastcgi_index  index.php;
fastcgi_param  SCRIPT_FILENAME  /var/www/nginx-default$fastcgi_script_name;
include        fastcgi_params;
}

# deny access to .htaccess files, if Apache's document root
# concurs with nginx's one
#
location ~ /\.ht {
deny  all;
}
}

重新启动 ngingx

/etc/init.d/nginx restart

写个 phpinfo() 放到  /var/www/nginx-default/ 里面看看吧，应该已经可以显示了。

参考：

• Installing Nginx With PHP5 And MySQL Support On Debian Lenny
• Quick Guide to Nginx

2010/12/14 更新，适用于 api-proxy-php-0.5.zip，步骤简化了很多，推荐使用

0，服务器环境要求

服务器最好运行 Linux / FreeBSD 等操作系统，需要使用 apache httpd（nginx 有专用版本，请直接往下看），并且启用了 mod_rewrite，PHP 启用了 cURL支持。

1，下载/解压缩源代码

下载源代码压缩包：http://gfwinterceptor.googlecode.com/files/api-proxy-php-0.5.zip，解压后将 api-proxy-php 目录中的所有文件上传 / 移动到服务器相应目录。

2，文件配置

将 ~htaccess 文件改名为 .htaccess，之后用编辑器打开 users.config，按照文件中示范的每行一个用户名密码，用分号分隔的格式填入允许访问服务器的用户名密码。

不过需要注意的是，在默认 mime 情况下，apache 会把 users.config 当作文本文件，也就是说别人在浏览器输入 your.server/users.config 可以直接看到你的用户密码配置文件！临时解决办法是修改 index.php 第六行

$file_handle = fopen("users.config", "rb");

中的 users.config 位置，最好放到 http root 以外，比如改成 /home/gkp/gfw/users.config，之后把 users.config 移动到相应的位置就可以了。

3，开始使用吧

在安装好 GFWInterceptor 的 iDevice 上进入 Settings –> GFWInterceptor，将主力服务器设置成你安装 PHP 服务器端文件的地址，注意开头的 http:// 不要省略。在相应的位置填入上一步 users.config 中设定的用户名和密码，之后 respring 一下，打开 twitter for iPhone, Facebook, Foursquare 等应用试试看吧，没有问题的话应该可以顺利登录了。之后打开 safari，试试看 m.twitter.com，应该也是可以访问的。

4，有问题？

当安装 php-server 出现问题时，首先查看下 apache 的日志文件，如果都是类似于 File does not exist: /var/www/html/1 这样的报错的话，应该是 url rewrite 没有正常工作，请检查 apache 的 mod_rewrite 和 php-server 目录下面的 .htaccess 文件。

5，适用于 nginx 的版本

适用于 nginx 的 php 服务端程序目前还不支持用户名密码验证，安装方法如下：

• 下载 http://gfwinterceptor.googlecode.com/files/api-proxy-php-ngix-0.4.zip，并解压缩
• 把 api-proxy-php-ngix 目录下的文件上传/移动到服务器相应目录
• 把 gic 这个虚拟主机配置文件放到 nginx 会自动 include 的目录中，并编辑之，根据实际情况修改域名，文档目录等选项，最后重启 nginx。
• 搞定！

以下为老版本 php server 安装步骤，已经失效，仅供参考。

首先非常感谢 @overboming 同学连续两个晚上和我调试 GFWInterceptor 的 PHP 服务端，而且今天后来很长一段时间都是因为我的一个操作失误导致的错误，实在是很对不住 @overboming 同学，具体的这个操作失误在最后会提到，先来简单说一下安装的过程。

1，下载源代码

有两种方式，使用 svn：

svn checkout https://gfwinterceptor.googlecode.com/svn/trunk/api-proxy-php

或者直接到下面这个地址下载 index.php 和 .htaccess 这两个文件的 raw file

http://code.google.com/p/gfwinterceptor/source/browse/#svn/trunk/api-proxy-php

其中 svn 还是强烈推荐的，虽然文件可能要移动一下，不过这样可以确保在 copy / paste 时候不出错误。

2，代码安装

GFWInterceptor 的安装还是十分简单的，首先确认你的服务器使用的是 Apache httpd，并且开启了 mod_rewrite 支持，php 方面需要有 cURL 模块。没问题的话，把 index.php 和 .htaccess 这两个文件放到服务器的某个目录就可以了，完全不需要进行代码修改以及权限设置。

3，测试安装

首先在电脑上用浏览器打开一下 GFWInterceptor PHP server 所在的目录，看看有没有报错信息，显示白板一块就对了。如果报 error 500 internal server error 服务器内部错误的话，很可能是你的服务器 Apache 没有启用 mod_headers。如果你有操作 apache 权限的话，直接

sudo a2enmod headers

加载 mod_headers 的配置文件，并重新启动 Apache 即可。如果服务器不是你的话，那你只能退而求其次，将 .htaccess 中下面这段删掉了，副作用是 4sq 无法 check-in，facebook 无法登陆。不过你可以将备用服务器（图床服务器）保留默认的 appspot.com 地址，0.61 以后版本的 GFWInterceptor 会将 4sq check-in 之类的请求直接走备用服务器。

#<Files ~ "*.php">
SetEnvIf content-type ([^m].*) NEW_CONTENT_TYPE=$1
SetEnvIf content-type (multipart/form-data)(.*) NEW_CONTENT_TYPE=multipart/form-data-alternate$2 OLD_CONTENT_TYPE=$1$2
RequestHeader unset content-type
RequestHeader append content-type %{NEW_CONTENT_TYPE}e env=NEW_CONTENT_TYPE
#</Files>

4，开始使用吧

在安装好 GFWInterceptor 的 iDevice 上进入 Settings –> GFWInterceptor，将主力服务器设置成你安装 PHP 服务器端文件的地址，注意开头的 http:// 不要省略。图床服务器则根据个人情况，有 mod_headers 的话完全也可以用自己的服务器。之后确认第一个选项在启动状态，保存退出，我这里需要 respring 一下，但是据 @overboming 说他那里则不用。

依次打开 twitter for iPhone，4sq，Facebook 试试看吧，目前这三个应用除了 4sq check-in 后的 mayor 皇冠等几个图片不能显示外，应该已经完美了。

5，关于安全

首先我认为所有 Fuck-GFW 的服务都应该保持 private，所有公开的服务都会在瞬间被干掉，经过我的实测，北京移动 edge 用户已经无法访问 GFWInterceptor 的默认 appspot 服务器了。所以我强烈建议自己搭建 GFWInterceptor 服务器的用户也将服务器保持私有状态，仅限自己和好友使用。更何况现在 GFWInterceptor 的服务端还没有验证机制，也就是说任何人只要知道你的服务器地址就可以用。大家可以将服务器路径设置的诡异一些，有条件的甚至可以在非标准端口上开一个虚拟主机，这样被猜到的可能性就大大降低了。

不过 @overboming 已经确认在下个大升级中将加入 token 验证机制，手机端转发请求时将在 HTTP_HEADER 中包含一个 token，服务器端收到后会先验证 token，没有问题才放行，届时安全性将大大改善。

最后一个建议，就是尽量使用 https 加密连接，twitter for iPhone 已经是全 OAuth，但是最新的 Facebook 登录时密码还是明文发送的，存在被居心不良的人截获的可能性。

最后说下我今天晚上犯的错误吧，我是直接在 Chrome 中复制代码，然后到 iterm 中 vi 粘贴，结果不小心在代码开头的 <? 前面多复制了一个空行，导致 twitter / Facebook 报告 xml 数据前有垃圾数据，折腾了好久，所以大家最好还是 svn 吧，最起码避免了复制代码出错的可能性。

基本安装就是这样，如果遇到问题可以留言或者在 twitter @gokeeper，我会尽我所能帮大家解决。

背景：进入8月中，twitter 已经在每天减少 Basic Auth 的 API limit了，到月底 Basic Auth 将彻底关闭，也就是说到月底，所有的客户端，twitter与第三方服务之间都必须使用 OAuth 来传递帐号密码等信息。

我喜欢 twitter for iPhone 的很大一个原因就是其支持自定义图片服务，3.0 以及之前的版本使用 Basic Auth 自建图片服务很容易，只要处理一下提交过来的 multipart/form-data 就行了，但是相应的安全性比较低——密码用明文传送，所以 atebits 强烈推荐用 https，并且曾经计划在后续版本强制 https。当然现在都 OAuth 了，这个问题也就不存在了。

twitter for iPhone 升级到 3.01 以后，就一直有人说其有 bug，自定义 API 和 自定义图片服务都不能用，这个 "bug" 一直持续到了 3.03a。。。昨天偶然和 @2046 聊起这个事情，才突然明白这根本不是什么 bug，而是新版的 twitter for iPhone 已经开始用 oAuth 将用户信息打包提交了，所以导致之前在 expect basic auth 的 API Proxy 以及 自定义图片服务都歇菜了，包括 img.gd 与 twip 。。。

这里要强烈谴责一下 twitter 的官方网站，直到现在 twitter for iPhone 的支持页面里面还是让大家去 atebits 的 developer 页面看老掉牙的信息，严重误导。实际上现在 twitter 使用 OAuth Echo 为类似的第三方服务进行验证，基本原理可以参考这（1，2）篇文档，基本流程如下图：

以 twitter for iPhone 发图到 img.gd 为例：

1. twitter for iPhone 将 multipart/form-data POST 到 img.gd 的 ending point，包括图片以及 $_POST['message']，即 tweet 主体。
2. POST multipart/form-data 的同时，HTTP HEADER 中会包含关键的 OAuth 信息：X-Auth-Service-Provider （验证 url） 以及 X-Verify-Credentials-Authorization （OAuth 信息主体，包括 token 等）。
3. img.gd 收到 POST 后，将 HTTP HEADER 中的 X-Verify-Credentials-Authorization 改名为 Authorization 提交到 X-Auth-Service-Provider （这里就是 twitter）验证。
4. 如果 twitter 返回 HTTP CODE 200 的话，表示验证成功，同时会返回一个 json 格式的用户 object。
5. img.gd 读取 twitter 返回的 json 数据，存储图片，返回图片 url 给 twitter for iPhone。

最终效果如本文题图，这样终于可以放心升级到 twitter for iPhone 3.03a了，twitter 本身走 #GFWInterceptor 图片则直接 OAuth Echo 到 img.gd，赞！

虽然 twitter 因为世界杯的原因将 Basic Auth 的死期推迟到了8月16日，但是该来的总会来的。之前 img.gd 读取用户信息并在本地 cache 的函数使用的正是 Basic Auth ，于是趁着 @musiXboy 需要加 #tag 功能的机会重写了这个函数，全面 OAuth 化了。另外还简化了一些代码，修复 bug，具体更新如下：

• 全面 OAuth 化
• 加入可以点击的 #tag 功能，加入 tag 页面，例如：http://img.gd/tags/google
• 和 twitter 一样的字符长度处理，中英文字符都算1个字，修复了之前出现过错误计算 tweet 长度的问题

另外，由于 img.gd 代码脆弱，所以未来相当长一段时间内这个服务将保持现在的私人性质，sorry。

在最后的短网址后面加入了仿效 TechCrunch 更新的作者提示，比如 by @gokeeper。另外也改走 OAuth 的 ，防止下个月停止 Basic Auth 后抓狂。目前看来一切正常，在观察观察。

• full-filename -  原图，尺寸不限
• filename - 标准显示图片，尺寸 < 620 x 800
• 150-filename - 150x150缩略图
• 75-filename – 75x75缩略图

其他更新：

• gb2312编码中文处理问题，用了一个通用的解决办法，理论上所有编码的邮件主题都可以正确识别了
• 修复把email地址加到地址薄后，邮件To属性变化后无法正确提取用户名和用户pin的bug

• 放弃单独的头像缓存函数。导入用户表，用户资料和头像保存本地，过期时间一周，大大减少api请求次数。