上次看到的主要是RAM Host旗下的 TinyVZ 推出的，价格便宜，年付$15，上网查了一下，貌似RAM Host的口碑还行，虽然OpenVZ有超售的风险，但是自己还没有怎么接触过VPS，觉得还是弄个尝尝鲜，看了一下，配置的主要瓶颈是内存：独立内存（Dedicated RAM）128MB，突发内存（Burstable RAM）256MB。其他还好吧，准备跑个DNS服务器，BIND系的估计是跑不了了，网上找了一个 maradns 的DNS Server，中文资料还真少，捣鼓了半天，没配置好，索性卸载了。

咱不搞DNS服务器了，搞个WEB服务器，放个WordPress。思来想去，内存这么小，只能按精简的方式配置了，参考了lowendbox的 《Yes, You Can Run 18 Static Sites on a 64MB Link-1 VPS》 这篇文章，再结合网上搜索的一些结果，配置了Debian 5.0 x86 + Nginx + MySQL + PHP的WEB服务器，最后内存被消耗掉100左右，不晓得最后28MB的独立内存和125MB的突发内存能支撑多大访问量。

配置完毕后，申请监控宝每15分钟监控一次服务器，但昨天晚上出现了无法访问的情形，查看 RAM Host News ，得知其服务器遭到了拒绝服务（DoS）的攻击，导致服务器离线，杯具了，今天晚上貌似又出故障了，希望RAM Host能够妥善解决吧。

突然感到Linux配置服务器真的很省资源，我在考虑要不要把一台装有Windows Server 2008的服务器系统换成Linux的，因为那台服务器内存也不大，才4GB，所有服务上线后感觉很吃力。

好吧，先写到这儿，这个VPS再监控一段时间，没有问题的话，我将试着将博客转过去，实在不稳定的话，只有拿来练习Linux了。

1.什么是eAccelerator？

摘自 百度百科 ：eAccelerator是一个自由开放源码php加速器，优化和动态内容缓存，提高了php脚本的缓存性能，使得PHP脚本在编译的状态下，对服务器的开销几乎完全消除。 它还有对脚本起优化作用，以加快其执行效率。使您的PHP程序代码执效率能提高1-10倍。

总体上说是一款加速PHP执行速度的扩展，具体效果，我试下来觉得还是不错的。

2.如何获取eAccelerator？

大家可以到其 官方主页 上去下载最新版本。但是遗憾的是不晓得为什么，官方首页最近变成了Apache的默认页了，最新的eAccelerator版本应该是eaccelerator-0.9.6.1.tar.bz2，官方下载地址是： http://bart.eaccelerator.net/source/0.9.6.1/eaccelerator-0.9.6.1.tar.bz2 ，但是这个地址也用不了，所以我先临时提供一个下载地址：

http://orpin.org/downloads/source/linux/eaccelerator/eaccelerator-0.9.6.1.tar.bz2 md5sum 32ccd838e06ef5613c2610c1c65ed228 sha1sum c95e87229a6e674b4994d4fc13278e516ea314f9

3.如何安装并使用？

3.1 准备工作

首先需要make模块，大多数Linux系统都自带了这个模块，没有的通过下面的命令安装：

前一篇文章 《Nginx配置SSL安全证书及解决PEM_read_bio:bad end line error错误》 简单介绍了Nginx下SSL安全证书的配置，本来以为这样就算配置完成了，实际不然，首先发现WordPress的 AdminSSL 无法正常工作，显示有太多的递归转向，也就是说无限循环的跳转，就是无法转到https上，具体错误如下：

Error 310 (net::ERR_TOO_MANY_REDIRECTS): There were too many redirects.

在FireFox火狐下有可能错误是这样的：

Redirection limit for this URL exceeded. Unable to load the requested page. This may be caused by cookies that are blocked.

原先以为是插件问题，想用PHPMyAdmin操作数据库移除插件，利用https的安全方式尝试登录数据库时出现以下错误：

400 Bad Request The plain HTTP request was sent to HTTPS port

同时地址也变成了类似于http://localhost:443/index.php，也就是表单没有提交到SSL的https上，而是以普通方式提交到443端口，大家都知道443端口是SSL的传输端口，正确的传输方式应该是https协议。

在 StartSSL 上申请了免费一年的证书，本来想配置到nginx里的，把申请到的key和crt文件放到/etc/nginx/certs/目录下，并命名为server.key和server.crt，对于申请的StartCOM Class1证书还需要以下命令，合并证书链：

wget http://cert.startssl.com/certs/ca.pem
wget http://cert.startssl.com/certs/sub.class1.server.ca.pem
cat ca.pem sub.class1.server.ca.pem >> ca-certs.crt
cat ca-certs.crt >> server.crt

然后修改Nginx的配置文件nginx.conf如下：

# 下面这段是强制80端口非SSL客户端转向至https安全连接
# 如果希望保留http非安全连接，请去掉这里
server {
  listen 80;
  server_name www.example.com; # 你自己的域名
  rewrite ^(.*) https://$server_name$1 permanent;
}

# 这里是SSL的相关配置
server {
  listen 443;
  server_name www.example.com; # 你自己的域名
  root /home/www;
  ssl on;
  ssl_certificate /etc/nginx/certs/server.crt;
  ssl_certificate_key /etc/nginx/certs/server.key;
}

使用下面的命令重启nginx服务

编译原理及编译器那个栏目一直空着，网站改版前是有一些文章的，改版后觉得价值不高就没有放上来，想先完成基础数据结构的函数库，可能学艺不深，一些简单的数据结构函数总是要改上很多次，本来是想从基础数据结构构建，直到一些复杂数据结构及算法的实现。事实上，问题开始逐渐凸显出来，作为一些简单的基础的数据结构，实现起来很容易，调用起来也很方便，没有什么问题，对于构筑于这些简单的数据结构上的复杂数据结构及算法貌似也实现了设想的功能，似乎这样没有问题，直到有一天我在做WEB数据库操作时想到：复杂数据及算法操作总是分成若干个操作简单数据结构的步骤，如果说这些若干步骤中，第N步出错，错误可以是内存读写失败或者权限等问题，那么对于第N步的致命错误，一般是直接返回，那么第N+1步是不会执行了，问题就在于第N-1步，如果第N-1步对原有数据造成了破坏，那么有没有类似于关系型数据库的事物恢复机制呢？如果说没有这种机制，那么在调用这个函数导致失败是小事，破坏了原有的数据就麻烦了。

可能最简单的做法就是在操作数据前对数据做一个拷贝，一旦失败并导致原有数据被破坏，则立即利用拷贝恢复被破坏的数据。数据量小的情况下这种方法确实简单方便，但是在应用复杂，数据量大的情况下，必然会导致存储空间和性能瓶颈，准备有时间好好研究一下数据库的原子操作的实现，一个可靠的数据算法函数库必须要有灾难恢复机制，否则就违背了函数设计的初衷了，即输入数据，得出正确结果，或者执行可以失败，但不能破坏了原有的数据。

不久前看到WAVDB上一篇 《BlueCMS信息门户系统存在getip()注射漏洞》 ，让我感觉到WEB编程中安全隐患处处都会存在，往往很多情况下都是我们大意，导致问题的产生，经典的安全问题就是SQL注入攻击（SQL Injection Attack）以及XSS跨站脚本攻击，这些安全问题说到底就是对用户数据校验不严格所造成的，经典的安全编程模式应该是脱离程序员假定的数据格式，要能够接受来自客户任何数据，然后对这些数据进行甄别，过滤掉不符合原假定格式的数据，因为这些数据可能是无用的或者是有害的，说到底，大部分安全问题还是由于对来自用户数据的不严格判断过滤所导致的。

下面再来看看BlueCMS的getip()安全漏洞，原有的代码摘录如下：

前年实习时写的软件，偶然翻出来，觉得搁着还是搁着，还是发布出来吧，功能很简单：主要用于辅助银行客户经理在个贷（房贷）方面撰写调查报告，通过一些简单的填空，最后可以自动生成一篇个贷调查报告。本软件以提高效率为主要目标，所以结合数据库，自动计算相关数据，避免用户的不必要重复输入，最后合理组织数据，从而降低调查报告的错误率。为了适应各类房贷调查报告类型，特采用模板技术，用户可以自行编辑模板，灵活配置输出内容，可以输出的报告格式有Word（*.doc）、RTF和文本文档（*.txt）。

基本上每一个域名都有一个对应的WHOIS服务器，由WHOIS服务器来提供该域名的一些必须信息，有时候我们需要获取这些信息，这时就要查询这些服务器。

至于得到WHOIS服务器地址后下一步该怎么做，其实就是通过Socket编程连接远程服务器43端口来获取信息。在PHP中还可以利用PEAR简化写法：

<?php
require_once "Net/Whois.php";

$server = "whois.denic.de";
$query  = "phpcrawler.de";     // get information about
                               // this domain
$whois = new Net_Whois;
$data = $whois->query($query, $server);
echo $data;
?>

主要来自于 iana.org ，为了便于查阅，先以PHP数组的形式记录在这儿：

1.3.6.1.5.5.7.3.1 - id_kp_serverAuth 1.3.6.1.5.5.7.3.2 - id_kp_clientAuth 1.3.6.1.5.5.7.3.3 - id_kp_codeSigning 1.3.6.1.5.5.7.3.4 - id_kp_emailProtection 1.3.6.1.5.5.7.3.5 - id-kp-ipsecEndSystem 1.3.6.1.5.5.7.3.6 - id-kp-ipsecTunnel 1.3.6.1.5.5.7.3.7 - id-kp-ipsecUser 1.3.6.1.5.5.7.3.8 - id_kp_timeStamping 1.3.6.1.5.5.7.3.9 - OCSPSigning

用逗号分隔，比如：

makecert -eku 1.3.6.1.5.5.7.3.1,1.3.6.1.5.5.7.3.2,1.3.6.1.5.5.7.3.3

今天在对项目进行安全单元测试时发现的，主要是PHP在处理404页面时向用户展示所请求的URL不可访问的消息那儿的问题。The Request URL...这里直接读取的$SERVER[]变量，导致不怀好意者有机会在URL中构造XSS跨站脚本，其实这里只需要过滤一下即可，但是说明“永远不要相信用户的输入”这条安全守则的重要性，所有来自客户端的数据都要经过严格过滤，并保证最小数据要求，比如某模块只需求字母字符串，不过你把数字传过去也没有问题，但是严格来说在过滤时就应该过滤掉所有非字母的字符。

XSS也是前几年接触到的新的攻击技术，在这之前也就知道个SQL注入攻击，安全一直是个老生常谈的话题，不过我们往往注重某一点时会忽视另外一点，回顾过去的项目，几乎或多或少会存在XSS跨站漏洞，最经典的就是比如访问delete.asp?id=1就会删除id=1的数据记录，攻击者可以构造<img src="http://example.com/delete.asp?id=1" />的代码，然后诱使你访问，比如邮件什么的，当你访问时，即使没有任何操作，记录号为1的记录已经被删除了。XSS的另一个严重的问题就是Session会话劫持，攻击者会尝试劫持合法用户的会话ID，一旦会话劫持成功，攻击者就可以以合法登录者身份为所欲为了。