但是有时候某台工作站没有打开这个VNC服务，只有SSH，但是又必须通过桌面来操作，这时候自带的vino server就好像不容易跑起来。

x11vnc这个小工具就可以派上用场，它对当前的x11 session建立VNC服务，很简单直接运行x11vnc，就等你连接5900端口了。当然，如果一定要指定一个session，有个-display参数可以指定，或者看看x11vnc --help，好长好长～～～

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

apt-get install python-software-properties
add-apt-repository ppa:nginx/stable
add-apt-repository ppa:nginx/php5
 
#Ubuntu 10.10 以后可不需添加以上源
 
apt-get update
apt-get install nginx
apt-get install php5-cgi php5-mysql php5-fpm php5-curl php5-mcrypt
 
#或者你需要更齐全的php包：
#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
 
service nginx start
service php5-fpm start

FPM Tunning

php5-fpm默认参数启动的服务器还是比较耗资源的，如果环境不充裕（如512内存以下的VPS），可以做下配置。

这个包的fpm的默认配置文件是/etc/php5/fpm/main.conf，但对子进程的配置是在其包含的/etc/php5/fpm/pool.d/目录内，里面有个www.conf，可以对以下的参数做以下修改：

pm = dynamic              ;动态管理php-fpm的子进程
pm.max_children = 5       ;最多的时候开不超过5个
pm.start_servers = 2      ;启动服务时候开2个
pm.min_spare_servers = 2  ;空闲时候最少留2个
pm.max_spare_servers = 5  ;最多留5个
pm.max_requests = 300     ;每个子进程最多处理300个请求就退出换新的子进程。

按需调整这些参数可以达到最佳动态分配资源的效果。

如果单独一个hg仓库，直接运行hg serve就已经是在线仓库，用nginx做的http_proxy反向代理就够了，各种功能齐全。但是要host多个hg仓库，需要用hgwebdir。

Ubuntu当中安装的mercurial已经包含了架设仓库所用的程序，包括cgi/fcgi/wcgi的，主接口在/usr/share/doc/mercurial-common/examples下的hgwebdir.(ws|(f)c)gi。虽然其中的wsgi有效的只有三行。

Mercurial官方Wiki上主要介绍了用apache2来跑cgi方式的仓库，但是作为python的程序，wsgi才是最原生的嘛。用Nginx+uwsgi的方式，资源占用、响应效率等，都要比apache + cgi靠谱。

Nginx+uwsgi的方式很普遍，参见本博客之前的MoinMoin 与 Nginx, fastcgi 与 uwsgi 的配置一文。

但是因为uwsgi处于快速开发过程当中，ppa的打包也还不十分成熟，里面的路径跟以前有些不一样了。

add-apt-repository ppa:nginx/stable
add-apt-repository ppa:uwsgi/release
apt-get update
apt-get install nginx uwsgi-python python-virtualenv mercurial
 
mkdir -p /var/www/hgwebdir
virtualenv /var/www/hgwebdir/python-home
 
cat >/var/www/hgwebdir/hgwebdir_wsgi.py << EOF
from mercurial import demandimport; demandimport.enable()
from mercurial.hgweb.hgwebdir_mod import hgwebdir
 
class hgwebdir_with_fixed_staticfile(hgwebdir):
    def __call__(self, env, respond):
        response = super(self.__class__, self).__call__(env, respond)
        return response[0] if isinstance(response, tuple) else response
 
application = hgwebdir_with_fixed_staticfile('/var/www/hgwebdir/hgweb.config')
EOF
 
cat >/var/www/hgwebdir/hgweb.config << EOF
[collections]
/home/hg-repo = /home/hg-repo
 
[web]
style = monoblue
allow_archive = gz, zip, bz2
baseurl = /
push_ssl = true
hidden = false
allow_read = *
allow_push = user1 user2
 
[extensions]
#highlight =
EOF
 
cat >/etc/uwsgi-python/apps-enabled/uwsgi.xml << EOF
<uwsgi>
  <limit-as>256</limit-as>
  <processes>6</processes>
  <memory-report/>
  <vhost/>
  <no-site/>
</uwsgi>
EOF
 
cat >/etc/nginx/sites-enabled/hgwebdir << EOF
server {
    listen   80;
    client_max_body_size 512m;
    server_name hg.mydomian.com;
    location / {
                include uwsgi_params;
                uwsgi_pass unix:///var/run/uwsgi-python/uwsgi/socket;
                uwsgi_param UWSGI_PYHOME /var/www/hgwebdir/python-home;
                uwsgi_param UWSGI_CHDIR /var/www/hgwebdir/;
                uwsgi_param UWSGI_SCRIPT hgwebdir_wsgi;
                uwsgi_param UWSGI_SCHEME \$scheme;
                uwsgi_param REMOTE_USER \$remote_user;
        }
}
EOF
 
mkdir /home/hg-repo
cd /home/hg-repo
hg init example-repo1
hg init example-repo2
chown -R www-data:www-data /home/hg-repo
 
/etc/init.d/nginx restart
/etc/init.d/uwsgi-python restart

所以，/home/hg-repo下的所有仓库(新建的两个空仓库example-repo1/2)都会被hgwebdir列表在目录上，直接使用其地址就可以pull/push了。

注意的是hgweb.config文件里面的配置，push_ssl = true只允许使用https协议的时候push，也就是需要另外配置一个支持https的nginx。这个属于nginx的基本配置，这里不重提了。

对于不公开的仓库，除了HTTPS，还需要用户名密码，只需要配置nginx的basic http auth，上面命令当中的uwsgi_param REMOTE_USER $remote_user一行配置会把http auth的USER通过协议发送到hgweb，完成其认证过程。

其实hgweb的认证仅仅是用户名的匹配，hgweb.config里面的allow_push = user1 user2是全局设定，各个仓库的.hg/hgrc里面的同样的[web]区下也可以定义allow_push/read，即仓库各自的读写权限。

hgweb.config中注释掉的highlight一行，是启动语法高亮插件用的，打开需要先安装python-pygments包，不然会出错。

这个版本的uwsgi程序的log在/var/log/uwsgi-python/uwsgi.log，如果出任何问题，大概看看log的提示按提示去修复即可。

Update: 2011-3-17

原hgwebdir的程序跟wsgi2协议兼容不好，会出现仓库目录的首页里面的静态文件全部无法打开，log里面的信息是invalid WSGI2.0 response size: 1 .。 上述代码中已经修复（见1楼留言。） Thank You, Leonid.

Vimpress had been updated to 2.x, usage and configurations are now different, read the officle page in vim.org:

http://www.vim.org/scripts/script.php?script_id=3510

If you noticed Vimpress before and got more than one wordpress to write, must glad now to know this VimRePressed support multiple configs and swith freely.

The new VimRePressed (Version: 1.2.0) Changes:

      Add: MarkdownPreview command to preiview markdown in browser.
      Add: MarkdownNewPost command to convert a markdown
           written post into html and set to the new post view.
      Add: Move blog configs info to personal .vimrc
      Add: Multiple config is now supported, and with :BlogSwitch
           command added.
      Add: Show which blog your editing at :BlogList view.
      Fix: Running :BlogList in the List view got error.

Now you got to wirte your blog config in your own ~/.vimrc file. (CAREFUL when your share your vim configure with others then. Use a source my_vimpress.vimrc instead. )

let VIMPRESS=[{'username':'user',
              \'password':'pass',
              \'blog_url':'http://your-first-blog.com/'
              \},
              \{'username':'user',
              \'password':'pass',
              \'blog_url':'http://your-second-blog.com/'
              \}]

The syntax looks just like python or json, dictionarys in a list(or array), only that line brake need to write in the vim way.

BlogSwitch command rotate you from the first blog to the last, then the first. If you got confused, BlogList command can show you which one you're connecting to.

Then the Markdown support. I added two command to save my time saving .mkd file then convert them into html then check in a browser, MarkdownPreview command can do this for me. When flawless, the MarkdownNewPost command switch me to the new post view with all thing I write into html, which is ready to publish.

Download: from google code

SVN Version also available:

1

svn checkout http://ptcoding.googlecode.com/svn/trunk/vimpress

但是Nginx的改写规则就没这么容易让代码来配置了，虽然wp-super-cache的第二种缓存方式就是为这种使用环境设计，但实际上是用了PHP来提供静态数据了，在使用apache benchmark压力的时候，php-cgi依然占很高的CPU占有率。

通过编写nginx的rewrite规则还是可以让nginx直接读取静态文件，参考来自Code Exchange: nginx rewrite rules for WordPress + WP Super Cache，这里的配置被很多地方引用过，但实际尝试使用过程看到那里面的代码还需要微调。

    server {
        listen          80;
        server_name     apt-blog.net;
        root    /var/www/pt-sites/wordpress;
        index   index.html index.htm index.php;
        location / {
                # enable search for precompressed files ending in .gz
                # nginx needs to be complied using –-with-http_gzip_static_module
                # for this to work, comment out if using nginx from aptitude
                gzip_static on;
 
# if the requested file exists, return it immediately
                if (-f $request_filename) {
                        break;
                }
 
set $supercache_file '';
                set $supercache_uri $request_uri;
 
if ($request_method = POST) {
                        set $supercache_uri '';
                }
 
# Using pretty permalinks, so bypass the cache for any query string
                if ($query_string) {
                        set $supercache_uri '';
                }
 
if ($http_cookie ~* "comment_author_|wordpress|wp-postpass_" ) {
                        set $supercache_uri '';
                }
 
# !!!! IMPORTANT
                # if we haven't bypassed the cache, specify our supercache file
                if ($supercache_uri ~ ^(.+)$) {
                        set $supercache_file /wp-content/cache/supercache/$http_host/$1/index.html;
                }
 
# only rewrite to the supercache file if it actually exists
                if (-f $document_root$supercache_file) {
                        rewrite ^(.*)$ $supercache_file break;
                }
 
# all other requests go to Wordpress
                if (!-e $request_filename) {
                        rewrite ^(.*)$ /index.php?q=$1 last;
                }
 
}
        location ~ \.php$ {
              include        fastcgi_params;
              fastcgi_pass   127.0.0.1:9000;
              fastcgi_index  index.php;
              fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
        }
    }

需要重点关注的是set $supercache_uri这一行，这里的路径是wp-super-cache生成静态文件的路径，配置文件起作用的时候，这个路径会和$document_root组成最终静态文件的绝对路径，最终输出文件。所以如果这个路径不对的话，最终还是交给了index.php，缓冲就不起作用了。

wp-super-cache在wordpress目录/wp-content/cache/supercache/$http_host/下生成了各个请求url的目录，目录下是一个index.html静态文件，可以在wordpress工作时候，在这个目录下用命令watch find观察（在缓冲不多的情况下），总之小心的把这个路径写好，因为估计每个博客的permanent link的样式都不一样，wp-super-cache生成的目录也不一样，需要仔细调试一下。

当然这里的规则并没有安全包含了wp-super-cache 插件的功能，比如识别手机客户端之类的，如果需要还得仔细根据插件生成的.htaccess规则来添加到nginx。

完成后用apache benchmark压一下，Request per second应该很容易上百，而且php-cgi应该不会出现在top的列表前面了，CPU应该集中在nginx的子进程上，而且都是个位数CPU占有率，系统的load非常低。

Tips: 发现测试结果不对时，可以尝试删除/wp-content/cache整个目录，让wp重新生成所有缓冲。

顺便说一下，如果仅使用ab测试压力，用不着安装整个apache2，只需要apt-get install apache2-utils。

• 5.0系统断网自动修复程序黑莓断续膏(AntiBrokenNet！)
• BrokenNetFixup断网修复工具

区别是前者后台自动修复，后者要手动运行修复。

从网友的留言看出，虽然软件虽然有效，但没有稳定的服务器，软件刚出现时候确实有一批地址提供了服务，但很快就失效了。北京小C这里提供了模拟MDS服务器的程序，是VC写的一个小UDP服务器，虽然原理很简单，但用一台Windows的服务器来跑成本太高了，当然很难稳定提供。

其实服务只是很简单的几行代码，稍微改了一下就可以在Linux下面运行。一台低端Linux VPS的费用大概一年200RMB，这个费用对大多数人来说都不是什么问题的，所以推荐想要稳定防断网服务器的人去弄一台，一台可以很多人共享了。VPS侦探 、Lowendbox上有很多这样的推荐。

Linux版本的MDS服务器代码在Google Code上，可以直接下载。

在服务器（Debian/Ubuntu系统）上编译并运行：

1
2
3
4
5

sudo apt-get install build-essential
wget http://ptcoding.googlecode.com/svn/trunk/mds_server.c
gcc -Wall -o mds_server mds_server.c
sudo cp mds_server /usr/local/bin/
/usr/local/bin/mds_server

现在可以设置手机的续断软件使用这个服务器来连接断网测试了，手机连接的时候，会实时打印出手机的连接信息跟PIN码。

当然最好把程序加入系统自动启动：

sudo touch /var/log/mds_server.log
sudo chown nobody /var/log/mds_server.log
sudo sed -i '/^exit 0/isu nobody -c "nohup /usr/local/bin/mds_server >>/var/log/mds_server.log &"' /etc/rc.local

这样程序会在系统启动后自动在后台运行，运行的LOG会记录在/var/log/mds_server.log文件当中。

下面也无偿提供一枚MDS服务器，就是跑在我的Linux服务器上的。

地址：119.134.250.11
端口：19781

另外服务端口可以修改源代码里面的宏：

1

#define LOCAL_SERVER_PORT 19781

Wiki我选择了用Python的MoinMoin，一定程度上受CPYUG社区 ZoomQuiet 大妈的推荐影响，首次试用感觉非常impresive，所以就定了。再加上 GraphViz 工具的支持，实在的强大。

在vps上服务，肯定是无视apache的，内存有限。之前架设过用来上Twitter奶瓶腿，是Nginx + php-cgi的方案，nginx是必须的。

Python跟web前端的架构方式有太多选择了，五花八门，MoinMoin的发行包里面都提供了moin.cgi moin.scgi moin.ajp moin.fcgi moin.wsgi等多种启动方式。MoinMoin里面全部通过内置的flup作为中间件提供这些接口，目前我仅尝试使用了fastcgi和wsgi。

虽然解压了moin的源码包就可以直接运行里面的wikiserver.py来本地访问了，但在服务器上通常是由nginx/lighttpd等服务来综合转发。php的话是通过spawn-fcgi启动一些php-cgi的进程，服务器接受到动态的请求就通过本地socket跟php-cgi通讯，返回的结果展现回给客户。php-cgi是使用FastCGI协议的。

MoinMoin 源码当中wiki/server/moin.fcgi就是一个类似php-cgi功能的fastcgi服务，类似地可以使用spawn-fcgi来启动moin.fcgi，作为后端的处理进程。

Running MoinMoin Wiki with Nginx via FastCGI and Flup该文章很形象解释了fastcgi的角色，以及提供了一段很方便的服务脚本来启动spawn-fcgi。

Client ----> Nginx Web Frontend -----------+
                                           | fastcgi_pass
                                          \|/
                            +-------------------------+
              moin.fcgi     | spawn-fcgi-moin.socket  |
spawn-fcgi ---------------> |           or            |
                            |     localhost:port      |
                            +-------------------------+

但是文章当中的nginx配置不完整，而且复杂了，这是我的配置：

server {
        listen   80; ## listen for ipv4
        server_name  wiki.apt-blog.net;
 
access_log  /var/log/nginx/wiki.apt-blog.net.access.log;
        error_log   /var/log/nginx/wiki.apt-blog.net.error_log;
 
location / {
                include fastcgi_params;
                fastcgi_param PATH_INFO $fastcgi_script_name;
                fastcgi_param SCRIPT_NAME /;
                fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
                if (!-f $request_filename) {
                        fastcgi_pass unix:/var/run/spawn-fcgi-moin.socket;
                }
        }
}

当然那文章中的配置有考虑对静态文件直接由nginx服务，不通过flup这一层，有一定优化，这里省去了这些。其实增多一个/moin_static193(据版本号不同而不同)的location即可，可参考后面使用uwsgi做服务时候的配置。

文章还提到wikiconfig.py里面一个fix_script_name变量，是1.9版本新加入的，需要xxx.com/wiki这样访问的童鞋就不用像以前版本那样要在nginx配置里面写一大堆东西了。

Fastcgi就这么多，不算太复杂。Fastcgi虽然很流行，但弊端不少，首先是速度，在一台虚拟机上测试，用ab居然跑出每秒20个请求的速度……虽然平均下来还是有5、60次，但真的，唉。php-cgi还支持产生多个工作进程以并行和均衡请求，提高效率，fastcgi似乎就没这样的东西了。

刚好这天observer专栏杂记写了一篇配置Nginx＋uwsgi更方便地部署python应用，当中也提到fcgi和 mod_python的各种不便，然后介绍了uwgi，高性能、多应用。

uwgi充当了python解析器的角色，使用wsgi的接口和Python程序交互，这个过程中做了优化，和上层nginx之间则设计了更加轻量的协议。nginx0.8.40以后官方默认带了uwgi的协议模块，所以使用很方便。

uwgi的文档有些简略，但是重点都是在wiki/Example里面了。 MoinMoin在uwgi的配置在其中一句带过：

/usr/bin/uwsgi -s /tmp/moin.sock --wsgi-file wiki/server/moin.wsgi -M -p 4

uwgi的-w参数是把某个py文件作为module，import使用，但是wsgi文件不被认识，所以新版里面多了这么个--wsgi-file参数。但是如果是多站点呢！

nginx配置的虚拟主机里面的uwsgi_param UWSGI_SCRIPT参数会让uwgi按模块导入名称，相当于命令行里面的-w，但是moinmoin的moin.wsgi文件，不是py结尾，只能用--wsgi-file参数。扫了一圈uwgi的wiki/Example和RunOnNginx，都没提到这个问题，倒是在这里提到在旧版的uwgi当中没有--wsgi-file参数，需要把wsgi文件改名成py结尾来导入，好吧，确实那样成功了。

至于性能，一开始我发现uwgi占的内存也不少，一个worker时候就占了20M多的内存，所以没开更多的工作进程；Fastcgi也差不多，然后用Apache Benchmark测试，好像两者区别不大。于是看了下fcgi vs. gunicorn vs. uWSGI的测评，才发现uwgi要开多个worker进程才有性能！于是开了8个，性能出来了，秒请求马上就上千！ 显然是uwgi打开了多个进程，充分利用了机器的CPU，还做了均衡请求。

最后，我的Wiki使用uwgi后的nginx配置：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

server {
    server_name  wiki.apt-blog.net;
    access_log  /var/log/nginx/wiki.apt-blog.net.access.log;
    error_log   /var/log/nginx/wiki.apt-blog.net.error_log;
    location / {
        include uwsgi_params;
        #uwsgi_pass 127.0.0.1:9096;
        uwsgi_pass unix:///tmp/uswgi.sock;
        uwsgi_param UWSGI_PYHOME /usr/local/lib/moinmoin;
        uwsgi_param UWSGI_CHDIR /var/local/wiki-moinmoin/server;
        uwsgi_param UWSGI_SCRIPT moin_wsgi;
    }
    location /moin_static193/ {
        alias /usr/local/lib/moinmoin/lib/python2.6/site-packages/MoinMoin/web/static/htdocs/;
    }
}

完整配置指南：

#安装
sudo -s
add-apt-repository ppa:nginx/stable
add-apt-repository ppa:uwsgi/release
apt-get update
apt-get install nginx uwsgi-python python-virtualenv
 
#组件配置
cat >/etc/uwsgi-python/apps-enabled/uwsgi.xml << EOF
<uwsgi>
  <limit-as>256</limit-as>
  <processes>6</processes>
  <memory-report/>
  <vhost/>
  <no-site/>
</uwsgi>
EOF
 
cat >/etc/nginx/sites-enabled/moinmoin << EOF
server {
    listen   80;
    access_log  /var/log/nginx/wiki.access_log;
    error_log   /var/log/nginx/wiki.error_log;
 
client_max_body_size 64;
    server_name wiki.mydomian.com;
    location / {
                include uwsgi_params;
                uwsgi_pass unix:///var/run/uwsgi-python/uwsgi/socket;
                uwsgi_param UWSGI_PYHOME /var/www/moinmoin/python-home/;
                uwsgi_param UWSGI_CHDIR /var/www/moinmoin/;
                uwsgi_param UWSGI_SCRIPT moin_wsgi;
                uwsgi_param UWSGI_SCHEME $scheme;
                uwsgi_param REMOTE_USER $remote_user;
        }
}
EOF
 
#Python环境预备
mkdir /var/www/moinmoin
virtualenv /var/www/moinmoin/python-home
cd /tmp
wget http://static.moinmo.in/files/moin-1.9.3.tar.gz
tar xvfz moin-1.9.3.tar.gz
source /var/www/moinmoin/python-env/bin/activate
cd /tmp/moin-1.9.3
python setup.py install
deactivate
 
#MoinMoin环境
cp -r /tmp/moin-1.9.3/wiki /var/www/moinmoin
cd /var/www/moinmoin/wiki
cp config/wikiconfig.py wikiconfig.py
cp server/moin.wsgi moin_wsgi.py
sed -i '/# a2)/isys.path.insert(0, os.path.abspath(os.path.dirname(__file__)))'
 
#可选
rm -rf config server
 
#重启
/etc/init.d/nginx restart
/etc/init.d/uwsgi-python restart

但是OpenVPN的--dhcp-option配置，对非Win32的客户端是无效的，只能考虑执行自定义脚本来完成：

vpnup.sh

1
2
3
4
5
6
7
8
9

#!/bin/bash
RESOLVE=/etc/resolv.conf
FOREIGNDNS1='4.2.2.1'
FOREIGNDNS2='4.2.2.2'
DNSMARK='_MK'
 
sed "s/^nameserver/#$DNSMARK nameserver/" -i $RESOLVE
echo "nameserver $FOREIGNDNS1" >> $RESOLVE
echo "nameserver $FOREIGNDNS2" >> $RESOLVE

vpndown.sh

1
2
3
4

#!/bin/bash
RESOLVE=/etc/resolv.conf
DNSMARK='_MK'
sed -e '/^nameserver/d' -e "s/^#$DNSMARK //" -i $RESOLVE

很简单，就是使用sed来完成/etc/resolv.conf文件的内容替换。

实际上我还使用了chnroutes的脚本生成的国内路由表，上面两段只是分别贴到其中的vpnup/vpndown当中。

VPS的内存就是钱。虽然这台VPS有384M内存，不算小，但apache什么的内存大户还是不考虑了，直接上nginx+fastcgi。

此前有做过这个组合的笔记《简单配置nginx+fastcgi后端的WordPress服务器》，不做博客的话mysql就省掉了。

但是启动php-cgi是个问题，还好有人写了不错的启动脚本/etc/init.d/php-fastcgi，Nginx, PHP and a PHP FastCGI daemon init script。而这篇How to set up nginx with PHP on Ubuntu的脚本稍微简化一点，而且是用Unix Socket来绑定nginx跟fastcgi的通讯。这样就免除了lo interface的依赖。

假设奶瓶Dabr是没什么难度的事情，奶瓶腿的话，我从项目的SVN checkout出源码后，下载 user_oauth.php并改名覆盖原来的common/user.php，以支持后台自动oauth登录Twitter；然后配置到nginx的虚拟主机目录下，基本就结了。

当然兽兽Showfom的Dabr教程里面提到了使用nginx的伪静态改写规则，这必须的（跟用wordpress一样）：

1
2
3

    if (!-e $request_filename) {
        rewrite ^/(.*)$ /index.php?q=$1 last;
    }

最后遇到的问题是，访问奶瓶腿的Setting，保存后502错误，查看error.log看到报的是：

24219#0: *40 upstream sent too big header while reading response header from upstream

直接Google找到答案，就是调大nginx的fastcgi缓冲区。

1
2
3
4
5

fastcgi_connect_timeout 60;
fastcgi_send_timeout 180;
fastcgi_read_timeout 180;
fastcgi_buffer_size 128k;
fastcgi_buffers 4 128k;

把这段加入到虚拟主机的配置下面，完了。没什么营养。

Update: 2011-02-28

2010版的奶瓶里面改用了itap作为oauth代理，但是itap对改写的规则跟奶瓶不兼容，如果使用nginx配置，需要配置两个Location域：

server {
    listen   80; ## listen for ipv4
    server_name     your.server.com;
    access_log /var/log/nginx/netputtweet.access.log;
    error_log /var/log/nginx/netputtweet.error.log;
    root    /var/www/netputweets/;
    index   index.html index.htm index.php;
    location / {
            if (!-e $request_filename) {
                    rewrite ^/(.*)$ /index.php?q=$1 last;
            }
    }
    location /oauthproxy/ {
            if (!-e $request_filename) {
                    rewrite . /oauthproxy/index.php last;
            }
    }
    location ~ \.php$ {
          include        fastcgi_params;
          fastcgi_pass   127.0.0.1:9000;
          fastcgi_index  index.php;
          #fastcgi_param  HTTPS on; #if you use HTTPS
          fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
    }
}

• DebianWiki Xen
• DebianWiki DebianInstaller/Xen
• XenWiki HowTos
• Ubuntu Doc/Xen
• Ubuntu 9.04上的XEN虚拟服务器（一） 安装XEN （二） 安装虚拟机
• 在 Debian 上安装和配置 Xen

一：Xen工具及其关系

《在 Debian 上安装和配置 Xen》一文把在Debian上安装Xen简化成一道命令：

On Debian Lenny 5.0 :

apt-get install xen-hypervisor-3.2-1-amd64
xen-linux-system-2.6.26-2-xen-amd64 xen-utils-3.2-1
xenstore-utils xenwatch xen-shell xen-tools

On Debian Squeeze 6.0

apt-get install xen-linux-system xen-hypervisor xen-utils xen-tools

• xen-hypervisor主要只有一个文件:/boot/xen-3.2-1-amd64.gz，就是宿主内核；
• xen-linux-system则是打了Xen补丁的Linux内核，这个内核脱离hypervisor是无法启动的，只适用于虚拟机；dom0对hypervisor来说也是虚拟机之一，domU也可以直接用这个内核启动。
• xen-utils则是运行在Dom0上的程序，比如xend、xm，作用是跟hypervisor通讯，是主要由Python编写的一系列程序。
• xen-tools是如xen-create-image的一系列工具，作为xm工具的前端，用以管理安装虚拟机；这是一套perl脚本，也有很灵活扩展性。
• xen-shell是一个交互式的shell，常见用于VPS服务商提供给用户的操作界面，用户根据几个封装好的命令控制虚拟机如重启等工作。(Debian 6.0 下没有了。)
• xenstore-utils、 xenwatch分别是虚拟机间数据共享和虚拟机监控的工具，不是必要组建，可不安装。

二: Dom0的启动

1. grub2跟xen dom0目前关系不怎么所以如果你用grub2启动遇到挂掉xen启动不起来之类的，换回grub-legacy吧。

2. 装完xen-hypervisor后可以打开/boot/grub/menu.lst看看，第一个选项应该是Xen 3.2-1-amd64之类的，看他的启动参数，是先加载Xen内核/xen-3.2-1-amd64.gz，再按模块挂在Linux内核；如果没有出现，需要运行update-grub。有这个后就可以放心重启了。

3. /boot/grub/menu.lst文件里面有这么一行配置：

1
2

## Xen hypervisor options to use with the default Xen boot option
# xenhopt=

是预留来传hypervisor参数的，比如要限制dom0的内存使用，可以写成：

1

# xenhopt=dom0_mem=256M

修改后记得运行 update-grub才生效。

关于Dom0内存的占用可能导致虚拟机不稳定可参看：Dom0 mem allocation and domU network issues。

三：虚拟机的网络

无论是简单的桥接，安全的NAT子网，内部私有网，单双向网，利用内核的特性都可以做到： Xen Networking

四：虚拟机的安装

关于管理工具

有两套工具可以用来创建Xen虚拟机：xen-tools, libvirt-bin，从它们各自的主页很清晰看到它们的定位不同，前者主要用于本地管理Xen，由Debian支持，后者用于管理各种虚拟方案（xen,openvz,kvm,qeum,vbox,vmware....），由Redhat支持。虽然都支持跟兼容，但实际上前者有利于安装前者的系统，后者有利于安装后者的系统。这里只研究前者。

关于 xen-create-image

xen-tools是相当简单实用的一套脚本，教程里面一般提到使用的xen-create-image。

xen-tools有一个全局配置文件/etc/xen-tools/xen-tools.conf，里面写的参数会最终被xen-create-image的命令行参数覆盖或补充。

关于 --install-method

xen-tools的作用主要是控制怎么安装一个发行版，因为xen虚拟机的特殊方式，一般都不会启动该发行版的安装程序，而是用发行版的基础包管理来进行安装，安装参数--install-method负责这个过程，比如Debian/Ubuntu就要用debootstrap方法安装，CentOS/Fedora用rinse或rpmstrap，另外还有copy、tar方法。安装好一个模板系统后对那个镜像手动挂载，tar压缩后来用部署其他虚拟机，是个好方法。

关于 --dist

--dist让你指定一个发行版的名字，你会发现并不是所有发行版都能被支持的，实际支持的可以看看/usr/lib/xen-tools的内容，里面各个对应发行版的目录内都包含了一系列的脚本，如预先安装什么包，需要设置某个配置文件，比如说libc6-xen，不过在64位机环境下这个是不需要的，脚本会自动判断。

关于安装新版本系统

因为版本太旧，在Debian Lenny里面的xen-tools跟debootstrap不能直接支持比如Ubuntu Lucid(10.4)之类的较新的发行版的安装，倒是有比较曲折的方法Ubuntu upgrade to 9.10/10.04 for Xen DomU 。但其实有更好的方法：下载新版的Xen-tools跟debootstrap的deb回来装上。因为这些只是一些脚本，不会跟系统其他包有冲突。装完后就可以直接安装新版系统了。(dpkg安装新版xen-tool时候提示缺一个依赖，按名字装上即可)

关于 --mirror

安装教程里面一般都让你指定一个对应发行版的源，考虑到网速因素，这样安装一个虚拟机是很累的，虽然xen-create-image有个--cache可以在dom0上缓存deb包。其实如果你有相应发行版的iso文件，完全可以拿iso来做安装源：

1
2
3
4

mkdir /mnt/isodir
mount -o loop /path/to/the_iso_file.iso /mnt/isodir
cd /mnt/isodir
python -m SimpleHTTPServer

现在这个机器就在8000端口上运行着一个HTTP源了，直接在mirror参数里面指定该地址即可，这样的安装过程很快。缺点是可能安装脚本有一些包在iso中没有提供而出错，建议加上--verbose参数查看整个安装过程。

安装过程的日至会被放在/var/log/xen-tools/<NAME>.log，如果安装过程出现什么问题可以直接看这个对应的文件。使用本地ISO做源虽然一般没什么问题，但如果缺了什么包之类的会在日志中提示。

关于 --role

--role=udev这个参数建议创建新虚拟机时候加上。--role参数会让创建脚本在/etc/xen-tools/role.d/目录下寻找相应名字的脚本运行，udev就是其中一个，作用是给虚拟机装上udev包。udev是提供动态/dev目录的机制，是提供内核对硬件识别的事件桥梁，对一般的xen虚拟机来说影响不算太大，如果不安装最显然的是会找不到/dev/shm挂载点（启动过程有一个warnning），但一般来说还是推荐安装。

/etc/xen-tools/role.d/里面默认包含了以下一些有用的脚本，使用时可以逗号分隔，如--role=udev,minimal,cfengine：

• builder 自动安装build-essential等编译链包，部署distcc集群有用。
• cfengine CFengine是一个服务器自动化控制服务，对部署大量服务器很有用。会拷贝dom0上的配置。
• editor 自动根据dom0里面的sed脚本来配置domU内的配置文件，具体可以打开/etc/xen-tools/role.d/editor看看说明。
• passwd 自动修改domU的密码。默认--passwd参数是会出现passwd的交互修改root密码的过程，用这个role脚本就可以实现自动应答。要使用--role-args=mYpassWd传入相应密码。
• minimal 精简化domU系统。安装一些screen、vim等实用工具，卸除manpages等对虚拟机意义不大的包。
• udev 如前述，安装udev包。
• xdm 安装X、xdm、icewm等GUI包。
• gdm 同上，登陆器换成gdm。

另外这些脚本默认都是针对Debian系系统设计的，Redhat系的应该用不了。

关于 --pygrub

最后有个--pygrub参数，关系到domU的引导过程。xen的半虚拟并没有从引导区的虚拟过程，而是直接读取内核文件运行。默认情况下是直接用dom0的内核的，如果domU的发行版跟版本跟dom0一致，这样处理倒是很方便，但是一旦不一致就容易出现找不到root分区等各种引导问题。如果安装的domU的系统跟dom0不一致的（包括amd64/i386这样的架构不同），就加上--pygrub参数，这会让domU安装上它自己的内核，以及生成一个/boot/grub/menu.lst文件，引导虚拟机时会根据这个文件模拟grub出现一个引导菜单，提出其自己的内核文件来启动虚拟机。

pygrub其实是xend的一个python工具，在/usr/lib/xen-3.2-1/bin/pygrub，可以直接这样运行来测试pygrub是否正常读取到内核：

1

/usr/lib/xen-3.2-1/bin/pygrub /home/xen/domains/lenny3/disk.img

会出现菜单，选择后会退出，返回一段临时文件数据，内核文件的临时位置。

目前在Debian Squeeze内的Xen 4.0的pygrub有个小小的低级错误，运行后会报模块导入错误，其实只要编辑/usr/lib/xen-4.0/bin/pygrub文件，把里面修改path的一行提前即可：

1
2

sys.path.insert(1, sys.path[0] + '/../lib/python') #这行原在30行左右，提前到这里
import xen.lowlevel.xc  #原本这里出错

典型的几种创建方法

1
2
3
4
5

xen-create-image --hostname=my-lenny --dist=lenny --mirror=http://mirrors.163.com/debian --role=udev --force --verbose
 
xen-create-image --hostname=my-ubuntu-vm --dist=lucid --mirror=http://mirrors.163.com/ubuntu --role=udev --pygrub --force --verbose
 
xen-create-image --hostname=my-xen-vm --dist=squeeze --install-method=tar --install-source=/path/to/system_tared.tar.gz --pygrub --force --verbose

第五章：虚拟机的运行

关于虚拟机配置文件

完成创建虚拟机后，默认情况下在/home/xen/domains/<NAME>下生成虚拟机的磁盘文件，在/etc/xen/<NAME>.cfg生成相应虚拟机的配置文件。关于虚拟机配置的修改，只需直接打开这个cfg文件修改即可(如内存大小，CPU多少，使用VNC等)。配置文件其实是一个Python脚本，也就是说可以对虚拟机的参数进行创建时的动态调节。

配置文件的选项完整说明可以运行xm create --help_config查看。

启动虚拟机以Xen的术语来说是创建一个实例：xm create -c /etc/xen/<NAME>.cfg，-c参数可以马上进入虚拟机的console，使用pygrub的虚拟机只能通过这个方法看到grub菜单。

关于虚拟机启动过程

本文成文时，使用Debian Lenny默认安装系统部署的domU似乎都有一个启动bug，即创建后使用xm console <NAME>仅能看到虚拟机启动的log信息，但是不出现shell，也无法登录，无法响应，只能按ctrl-]返回dom0。如果按上述安装了新版的Xen-tools跟debootstrap再创建的虚拟机就没有这个问题了。

用了旧版工具但要修复这个问题也不算太麻烦：

1
2
3
4
5
6

xm shutdown <NAME>
#确保关闭，运行xm list确保虚拟机已经没有运行
mount -o loop /home/xen/domains/<NAME>/disk.img /mnt
cp /mnt/etc/inittab /mnt/etc/inittab.bak
sed 's/tty1/hvc0/' /mnt/etc/inittab.bak > /mnt/etc/inittab
umount /mnt

就是替换/mnt/etc/inittab文件里面，把虚拟终端的交互设备从tty1改成hvc0。在新版的xen-tools里面，这个替换已经由安装脚本完成了。hvc0是Xen虚拟机的类终端设备，只有让虚拟终端的输出输入跟hvc0链接，才能通过xen的console方法登录虚拟机。

如果使用vnc连接虚拟机，又会发现vnc里面无法登录虚拟机，vnc是framebuffer驱动的图形，默认连接tty1设备，可以按上述方法打开虚拟机的/mnt/etc/inittab文件，在getty那一段，写成这样：

1
2

0:2345:respawn:/sbin/getty 38400 hvc0
1:2345:respawn:/sbin/getty 38400 tty1

如果你安装的是Ubuntu，Ubuntu默认没有使用inittab来配置终端，而是使用了新的机制，使用目录/etc/init/里面的文件来控制，可以发现里面有tty1.conf之类的文件，可以cp /etc/init/tty1.conf /etc/init/hvc0.conf，然后打开/etc/init/hvc0.conf，把tty1那一段改成hvc0，保存即可。

关于使用VNC查看虚拟机

关于VNC的设置在/etc/xen/xend-config.sxp和各个虚拟机的配置文件里面都有选项，关系是前者是全局配置。

要打开一个虚拟机的VNC输出，只需在其配置文件内添加（望文生义即可）：

1
2
3

vfb = [ 'type=vnc' ]
#复杂点的：
vfb = [ 'type=vnc,vncdisplay=10,vncpasswd=s3cr3t' ]

vncdisplay的值加上5900，得到的就是最终vnc服务所监听的端口。

更复杂的配置选项看xm create --help_config。

关于虚拟机的自动启动

让虚拟机跟随dom0启动的方法有很几种，比如在/etc/xen/auto/目录里面放虚拟机配置文件的链接。但似乎更好的做法是在每个配置文件里面写上：

1
2

on_xend_start = 'start'
on_xend_stop = 'suspend'

这样的好处是当dom0关机，Xen会先让虚拟机进入挂起状态（当然也可以改成shutdown直接关机），下次重启后虚拟机直接恢复。

第六章：其他问题

关于虚拟机的磁盘方式

使用xen-create-image工具创建的虚拟机，默认都是使用loop文件设备来映射，这样对io比较敏感的服务来说会有些影响。Xen3.3后引入了使用blktap驱动映射的磁盘设备，据称性能会有提高，不过根据试验好像跟pygrub配搭不怎么稳定（在xen-4.0下）。

觉得最靠谱的方式是使用lvm，xen-create-image工具也是支持直接创建lvm逻辑卷来安装的，这样即没有性能问题，也没有稳定问题。

全虚拟半虚拟与CPU支持VM指令集的关系

扫了一圈Google到的Xen资料，很多都让你检查/proc/cpuinfo里面有没有支持VM标记。其实CPU是否支持VM指令集，对xen来说只是能不能跑windows的问题，对于Xen的特色——半虚拟来说没什么影响，而且这才是xen最有价值的地方。

相关资料

• Details, Installation, & Set-up of Debian based Linux Servers
• Howto Install Windows XP / Vista on Xen