由于众所周知的原因，linode节点的访问十分不稳定，上一篇文章是刷新了至少5遍才发成功了。经常写着写着就发现预览和提交等等的按钮已经灰了。在我朝混久了都知道人怕出名猪怕壮，能被不稳定也是说明了linode在我朝的市场份额举足轻重。如此不稳定的服务器怎么支持我的中国梦，必须换啊。还是前面文章http://www.luo666.com/?p=4提到的原因，我的域名属于国际域名备份不方便，用国内的服务器还必须备份，所以还是要用境外服务器。可惜了我大阿里云的服务器便宜又好用。话说我司的境外服务器也是自带围墙的，看来我朝的防御体系真是固若金汤，至少在墙内看起来是这样。现在的这篇文章已经是在新站上发的了，下面简单记录一下这次迁移的过程，以备不时之需。没办法，这个可能性还是很大的。
基本步骤：
1，安装mysql,php,nginx如果没有的话。尽量使用VPS自己提供的APT源，原因见后面。
apt-get install mysql-server mysql-client
apt-get install php5-fpm php5-mysql
apt-get install nginx
2，使用rsync将原服务器的wp站点目录同步到新站点。rsync要用来从原来的服务器上同步文件，这个比scp好，能压缩，能通过配置参数自己解决冲突，还能在覆盖之前做备份，总之比格很高。
rsync -avuzb <src> <dst>
3，将原服务器的mysql数据库全部备份，到新服务器restore。
backup: mysqldump -u root -p --all-databases > /tmp/backup.sql
restore: mysql -u root < backup.sql>
4，将原服务器的nginx站点配置文件/etc/nginx/sites-available同步到新服务器，需要的话修改其中的配置文件，比如你在第二步改变了站点目录的路径。在/etc/nginx/sites-enabled下建立软连接到前面的服务器配置文件。
5，测试一下用ip能不能访问新站点，不能访问就看nginx日志解决问题。详见下面。
6，到你的域名解析提供商的网页修改DNS目标地址。
遇到问题：
1，这台机器上真是很干净，git，sudo，rsync，等等一概没有，更别提mysql，php，nginx等等了。幸而apt是有的，于是就先装这些工具。装到mysql时发现依赖问题，印象当中都是丝般顺滑的直接自动安装依赖包啊。于是我就手贱的将APT源换成了大阿里云的源镜像地址，然后apt-get update发现了两百多个需要升级的包，我窃喜，以为找到了不顺滑的终极原因，于是apt-get upgrade，这个回车下去，一个下午时间就没有了。。。不但upgrade无论如何也不成功，而且什么包都装不了了，被rsyslog的安装错误挡住了，各种workaround各种问题，最后发现这个VPS是个OpenVZ，这货是修改过的内核做的轻量级虚拟化，后面的文章也许我会写写这个内容，这个是我的主业，讲不清楚愧对江东父老。回到主题，至少这种VPS的一大弊端就是无法更新通用版本的包，因为内核版本就是这么低2.6.32，那么lib库比如glibc这种版本就上不去，于是后面一堆的包只能停留在某个版本。所以不能轻易的修改VPS提供的APT源，尤其是发现一堆需要升级的包时要慎重。在各种downgrade后，终于可以装包了，最后我心力交瘁的时候，小伙伴把mysql搞定，还是指定了低版本的依赖包解决。但是第二天，我满血恢复准备继续迁站工作时，发现ssh连不上了。ping还是可以通的，于是通过VPS服务商提供的console通道（对串口做的封装，挺顺畅的）进去，重装了openssh-server。这个过程还是异常难受，要downgrade一些包，一个个的用apt-cache policy <package>看过去，然后找到VPS提供的源对应的那个包的版本，再指定安装：apt-get intall <package>=<version>。随后，我继续php的安装，发现依赖包及其的多，如果要一个个的downgrade下去，人都要崩溃，还不知道出什么问题。还好我灵机一动，发现依赖包里有dpkg，这么基础的东西不对，那么影响肯定是一大片啊，于是果断downgrade。自此之后，世界恢复平静，装包继续顺滑了。
2，这其实是个历史遗留问题，以前通过workaround的方法解决的，这次借着迁站的机会，必须要解掉。在第5步尝试ip访问站点时，还是出现了令人发指的500 internal error。在nginx配置文件中加入日志配置：access_log /root/sites/luoben/logs/nginx-access.log; error_log /root/sites/luoben/logs/nginx-error.log;发现是stat() 我的wp站点目录时出现permission denied，首先把wp目录的owner改掉：chown -R www-data:www-data /root/sites/luoben，之后发现还是不行。搜索大法在这里再次显现威力，本文参考链接的第一条位置就留给了这个令人兴奋的答案，他一语道破天机：要在站点目录的每一级上加入x权限。照做之后，豁然天明。其实原因很简单，我的站点在/root/sites/luoben，root目录权限是drwx——,这样的话，只有owner才有进入这个目录的权限，目录的权限解释：http://superuser.com/questions/168578/why-a-folder-must-be-executable，r可以列举目录内容，w可以创建删除，x才可以进入并访问目录下的文件和子目录。