Sugarhosts是老牌的空间商，提供空间服务已经很多年了。成立于2009年7月，为 TechEVE Ltd 旗下品牌。TechEVE Ltd，注册于英国伦敦，是一家致力于应用与创新科技投资的公司。

deepvps 在他们家买了一个512兆的VPS，已经使用大半年了，一直运行稳定。他们家最近的配置又升级了一次，512M免费升级到1G内存，而且还有 异地备份保护您的数据安全，性价比很突出。这里强烈推荐一下他们家。

VSATA L1 配置如下：

• Intel XeonR 2核
• 1024M RAM
• 60GB Sata
• 1 T 流量
• Xen
• 优惠价69元/月

TestIP：198.148.116.113

如何升级？

登陆管理面板，将会看到有一个“Upgrade Available”按钮，点击它，将进入升级列队中。

一旦开始升级，你的VPS将被关闭，迁移到另一台主机。迁移时间大概在1G数据/1分钟。如果你的数据比较多，以此类推。迁移完成后，你的VPS将恢复（启动或关机），此时，你的内存变成新的了。请赶紧ssh连接上使用free命令查看一下。

虽然内存升级了，VPS的价格也升级了一点点，只是一点点而已。比如之前512M套餐是19.95美元一个月，现在是20美元一个月，只差了0.05美元。

Linode也说了，这个升级不是强制的，你可以不选择升级。

虽然如此，但是弗里蒙特机房的VPS升级还无法使用，如果你在这个机房，需要等待。

原文链接：

http://blog.linode.com/2013/04/09/linode-nextgen-ram-upgrade/

升级的方法也很简单。下面的几行代码，直接粘帖到SSH，直接回车就行了。升级会自动进行。

cd /root/
wget http://nginx.org/download/nginx-0.8.54.tar.gz
tar xzf nginx-0.8.54.tar.gz
cd nginx-0.8.54
./configure –user=www –group=www –prefix=/usr/local/nginx –with-http_stub_status_module –with-http_ssl_module –with-http_gzip_static_module –with-ipv6
make
mv /usr/local/nginx/sbin/nginx /usr/local/nginx/sbin/nginx.old
cp -r objs/nginx /usr/local/nginx/sbin/nginx
nginx -t

kill -USR2 `cat /usr/local/nginx/logs/nginx.pid`
sleep 15
kill -QUIT `cat /usr/local/nginx/logs/nginx.pid.oldbin`
ls

升级主要是修复了一些bug，如果这些bug对你没有影响的话，升级不升级都可以。
详细内容请看 changeslog  http://nginx.org/en/CHANGES-0.8

错误提示如下：

无法启动数据库 :
MySQL Daemon failed to start.
Starting mysqld:  [FAILED]

deepvps查看了Mysql的启动日志，显示如下：

101014 13:56:50 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
101014 14:01:54 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
101014 14:01:54 [Note] Plugin ‘InnoDB’ is disabled.
/usr/libexec/mysqld: Table ‘mysql.plugin’ doesn’t exist
101014 14:01:54 [ERROR] Can’t open the mysql.plugin table. Please run mysql_upgrade to create it.
101014 14:01:54 [ERROR] /usr/libexec/mysqld: unknown option ‘–skip-bdb’
101014 14:01:54 [ERROR] Aborting

101014 14:01:54 [Note] /usr/libexec/mysqld: Shutdown complete

101014 14:01:54 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
101014 14:02:57 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
101014 14:02:57 [Note] Plugin ‘InnoDB’ is disabled.
/usr/libexec/mysqld: Table ‘mysql.plugin’ doesn’t exist
101014 14:02:57 [ERROR] Can’t open the mysql.plugin table. Please run mysql_upgrade to create it.
101014 14:02:57 [ERROR] /usr/libexec/mysqld: unknown option ‘–skip-bdb’
101014 14:02:57 [ERROR] Aborting

101014 14:02:57 [Note] /usr/libexec/mysqld: Shutdown complete

通过启动日志的错误提示，deepvps在Google一顿搜索，终于搞明白了错误的原因。Mysql从5.0升级到5.1的时候，数据库的结构发生了一些变化，而Webmin 在升级Mysql的时候，升级不完全所以导致了Mysql在升级收启动失败的问题。

现在我们只能通过手动的方法修复这个问题了：

1，修改不兼容的数据库参数

在最新的Mysql 5.1.50版中已经废除了skip-bdb参数。所以现在我们需要在Mysql的配置文件里面删除这个参数。而skip-locking改为了skip-external-locking，skip-innodb改为了loose-skip-innodb。

首先进入/etc 目录，编辑my.cnf
命令：先cd /etc
再输入 vi my.cnf

在[mysqld]下面删除以下三行：

skip-locking
skip-bdb
skip-innodb

加入以下两行：

skip-external-locking
loose-skip-innodb

2，修改完参数后，Mysql数据库应该就可以启动了，然后进行第2步的修改。

最新的Mysql 5.1.50版实现了支持无需重启服务器就能在运行时加载或卸载API插件。这个特性需要用到mysql.plugin表，可以运行 “mysql_upgrade” 命令来创建该表 。

3，最后在Mysql命令行方式下运行，”mysql_repair” 命令修复整个数据库，这样就算彻底解决了Mysql数据库升级失败的问题了。

现在我们在来看一下Mysql的日志：

101014 21:54:39 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
101014 21:54:41 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
101014 21:54:41 [Note] Plugin ‘InnoDB’ is disabled.
101014 21:54:43 [Note] Event Scheduler: Loaded 0 events
101014 21:54:43 [Note] /usr/libexec/mysqld: ready for connections.
Version: ‘5.1.50′ socket: ‘/var/lib/mysql/mysql.sock’ port: 3306 MySQL Community Server (GPL) by Utter Ramblings

可以看到已经没有任何问题了，Mysql运行正常，问题解决。^_^

首先在SSH命令行输入：

vi /etc/yum.repos.d/utterrambling.repo

如提示vi命令不存的可以用下面这个命令：

vim /etc/yum.repos.d/utterrambling.repo

32bit的Centos输入以下内容：

[utterramblings]
name=Jason’s Utter Ramblings Repo
baseurl=http://www.jasonlitka.com/media/EL5/i386/
enabled=1
gpgcheck=1
gpgkey=http://www.jasonlitka.com/media/RPM-GPG-KEY-jlitka

64bit的Centos输入以下内容：

[utterramblings]
name=Jason’s Utter Ramblings Repo
baseurl=http://www.jasonlitka.com/media/EL5/x86_64/
enabled=1
gpgcheck=1
gpgkey=http://www.jasonlitka.com/media/RPM-GPG-KEY-jlitka

保存并退出vim模式，回到SSH命令行，输入以下命令:

yum -y upgrade php

升级的过程中会有2个 y/n 的提问，输入y并回车就可以了，大概2分钟左右就升级完毕了，此时输入命令

php -v

就能看到PHP版本已经更新到 5.2.13的版本了，如升级有疑问，可以留言给我。

转载：http://www.vpsbeta.com/vps%E4%B8%8A%E5%AE%89%E8%A3%85virtualminwebmin%E5%B9%B6%E5%8D%87%E7%BA%A7php%E7%89%88%E6%9C%AC%E5%88%B05-2-11/

VPS侦探原来一直使用的是Nginx 0.7.63，一直没什么问题，最近有空顺便升级一下，更新到最新比较稳定稳定的0.7.65，顺便做一下简单的维护。

Nginx编译后就一个小文件，不带动态库，升级也可以无缝升级，并不影响访问。

首先下载Nginx：执行wget http://soft.vpser.net/web/nginx/nginx-0.7.65.tar.gz

再执行 ./configure –user=www –group=www –prefix=/usr/local/nginx –with-http_stub_status_module –with-http_ssl_module 。

然后make，但不要make install

编译完，在objs目录下有一个nginx执行文件，就是它了。

备份下原来老的nginx文件

mv /usr/local/nginx/sbin/nginx /usr/local/nginx/sbin/nginx.old

在把新objs下的nginx cp到sbin下。

执行 /usr/local/nginx/sbin/nginx -t 测试下，显示没有问题。

//让nginx把nginx.pid改成nginx.pid.oldbin 跟着启动新的nginx，一般lnmp一键安装包安装的按下面执行命令即可。
kill -USR2 `cat /usr/local/nginx/logs/nginx.pid`

//退出旧的nignx
kill -QUIT `cat /usr/local/nginx/logs/nginx.pid.oldbin`

升级完成！

 转自：VPS侦探

　　DNSSEC是为阻止中间人攻击而设计的，利用中间人攻击，黑客可以劫持DNS请求，并返回一个假地址给请求方，这种攻击手段类似于正常的DNS重定向，人们在不知不觉中被转到另一个URL。

　　据Melbourne IT首席战略官，ICANN董事Bruce Tonkin说，本次升级将会给那些毫无准备的网络管理员一个措手不及，响应标准DNS请求往往只有一个单一的数据包(UDP协议)，大小一般不会超过 521字节，在某些较旧的网络设备中，比这个大的请求将会被出厂默认配置阻止掉，它会认为超过这个大小的数据包是异常的。

　　截至UTC 5月5日17:00点，所有发送给用户DNS解析器的DNSSEC签名的消息将会变大到2KB，是原来的4倍，但这么大的数据包可能会被许多网络设备拒绝接收，因此这个响应消息很可能会通过TCP分成多个数据包进行发送。

　　Tonkin有点担心，虽然DNSSEC已经提上日程有一段时间了，但许多IT和网络管理员还没有测试他们的旧路由器和防火墙，如果不能处理更大的DNS响应数据包就麻烦了。

　　他说：“企业网络中的设备可能会阻止比以往更大的DNS请求响应数据包”。

　　DNSSEC其实早在 2009年11月就在全球13台根服务器上准备好了，到目前为止，它只会导致许多旧网络设备载入网页略有延迟。

　　不是所有DNS根服务器都会响应每一个请求，用户机器上的DNS解析器会逐个请求这13台根服务器，直到返回一个满意的答复。当13台具有 DNSSEC签名功能的根服务器全部上线后，所有的响应不会抵达旧设备的企业网络，Tonkin希望大型ISP能解决这个问题，让家庭用户不受影响。

　　他说：“我不能保证所有ISP都准备好了，ISP会为你翻译DNS，但企业网络可能影响比较大，因为企业可能运行了自己的DNS服务器”。

　　从这个意义上来说，5月5日可与千年虫危机匹敌。Tonkin预计会有大量的组织遇到互联网接入问题，大量的网络管理员将会抓破头皮寻找问题的根源。

　　这个问题可能需要数天才能完全消除，晚上未关机的用户可能会访问到一些页面，那也仅仅是缓存中的内容。Tonkin建议网络管理员尽快运行一系列简单的测试，确保他们的网络可以处理更大的DNS响应包。