Snooda

    自从去年改版后一直百度不收录，大概半个月前满半年才开始收录，直到昨天才开始正常有百度搜索引入的流量，快照也更新到之前一天了。小博客伤不起，改版代价真大。

    对于原创内容的对待上百度比google可是差远了，搜一下某些热门的东西在百度的第一页也往往都是重复的一大抄列表，google就见得少。


    不靠谱。

    由于一快一慢搭dns靠谱程度不高，只能再搞一个速度比较快的vps来当dns服务器，没啥好选择，对国内靠谱的线路也就东亚这几个地方的：日韩港台。日韩的有语言障碍，价格也相当牛叉，于是还是搞香港的，今天入了一个试试。

    香港是众所周知的小水管，今天试了一下名不虚传，网站测速测一个wp的首页才6k的数据就惨不忍睹，测一个380k的图片，单线程稳定1.4M，应该是限速了。多线程直接各种超时，并且遇到一个从来没遇到的情况：测速时由于带宽跑到限制，ssh输入都挂了，无响应，停止测速才恢复。。。。小水管真是名不虚传。

    观察了一下稳定性，也非常一般般，波动不小。

    用台湾vps和香港vps搭了一对dns试了一下，刚开始设置所有记录均不缓存，发现我自己的电脑上每次都稳定在500ms左右，非常奇怪，因为到任意一台机器都只需要几十ms，解析时指定dns确实也只需要几十ms，后来把ns记录设置了缓存一分钟，发现在缓存期内延迟降到了几十ms，看来是由于不缓存ns记录时需要去一级域dns那里查顶级域名的ns记录导致的，不过奇怪，难道一级域dns给出的ns记录缓存时间是由顶级域dns里的ns设置决定的么？搞不懂。不过我把ns记录设置成缓存1小时时，发现监控宝的dns监控时间还是稳定在500ms左右，没有下降，ft。并且四个监控点还总有一个报获取不到记录。

   dns的性能测试实在是不好搞，设置成不缓存的话不太好同条件对比，因为dns商不会允许这么设。设缓存的话结果又往往取决于缓存dns服务器的性能。对于大站的话由于访问人数多，所以dns一定是被缓存住的，倒不用考虑dns问题，对于小站，每个访客都要从头解析一下域名，dns的速度就很重要了。

   不过通过今天的观察发现自己建dns性能也不如预想的那么好，不过毕竟定制性好。

    本来想用自建dns，设置两条ns记录，其中速度较快的dns服务器排在前面作为主dns，比较慢的放在后面做备份。

    结果发现实践中两条记录是随机顺序返回的，查了下需要rrset-order参数来指定方式，有如下三种：

fixed 以它们在域文件中的顺序排序
random 以随机顺序被返回
cyclic 以环顺序被返回

    显然对于我的需求是使用fixed模式，结果启用了后提示我默认不开启此模式，查了下原来从bind9开始默认编译不启动这个选项了，除非编译的时候手动加参数打开，而我用apt安装的bind9，所以该选项未开放，即使我这里支持了，上级域的dns也不能设置这个选项，很可能是随机返回结果的，悲剧。看来之前的设想满足不了，dns也要木桶原理了。

    今天开始搭dns服务器，主dns采用最快的台湾vps，辅dns暂时先使用老博客服务器。

    为了服务器安全性，需要进行一下chroot，避免bind被攻破后整个服务器被黑。

    centos自带了bind9的chroot软件包，可以自动将bind进行chroot启动，而debian就差了一点，需要手动搞，所幸debian自己带有官方chroot教程，所以照着做也并不难。

    
    先修改/etc/default/bind9，改成：OPTIONS="-u bind -t /var/bind9/chroot"

    然后建立各种chroot的目标目录：mkdir -p /var/bind9/chroot/{etc,dev,var/cache/bind,var/run/bind/run}

    为bind9的chroot环境创建两个虚拟设备：空和随机数

mknod /var/bind9/chroot/dev/null c 1 3
mknod /var/bind9/chroot/dev/random c 1 8
chmod 660 /var/bind9/chroot/dev/{null,random}

    将bind的默认配置文件移动到目标地址：mv /etc/bind /var/bind9/chroot/etc
    为了保持兼容性，仍在原位置为其建立软链： ln -s /var/bind9/chroot/etc/bind /etc/bind

    修改一下权限： chown -R bind:bind /etc/bind/*

    然后修改一下启动脚本里面pid文件的位置： PIDFILE=/var/bind9/chroot/var/run/named/named.pid
    注意，这里需要是在named目录下的named.pid文件，我之前把这个目录设置成bind了，结果发现放不进去，改成named才行，怀疑bind的代码里面写死了。


    然后通知rsyslog添加一个监听句柄： echo "\$AddUnixListenSocket /var/bind9/chroot/dev/log" > /etc/rsyslog.d/bind-chroot.conf

    debian默认只装了syslog，而不是增强版的rsyslog，需要安装一下。

    然后运行： /etc/init.d/rsyslog restart; /etc/init.d/bind9 start

    查看进程和pid文件均存在的话，表示chroot成功了






    

    上周博客正式迁移，所以给服务器配置上了各种备份脚本，最近一周观察发现总是差了8个小时，非常奇怪，因为top看到的结果是没错的，今天深究了一下，看了下cron服务的环境变量：/proc/pid/environ的内容，发现是采用了莫斯科时区，一看/etc/localtime，确实是设置的莫斯科，看来是上周忘了改时区，于是改了下，重启cron进程，发现还是没变，疑惑，看了下cron的重启脚本，发现用了/etc/timezone，这个文件还是莫斯科时区，看来自己用改文件的方法不是特别的靠谱，总是有漏的地方，于是用debian
官方的命令设置了一下：dpkg-reconfigure tzdata  这个命令是文本图形界面，设置了一下，两个文件都更新了，再重启cron，看了下系统变量，发现更新了。看看明天的备份时间是不是恢复正常了。


    不过为啥top看的时间时区是对的呢？

    在博客迁移前好几天就把a记录的ttl设成了10分钟，目的是为了减少dns记录在spider处的缓存时间，加快迁移速度，即使是这样，在昨天还有一部分Baidu Spider在爬，到今天还有Yahoo! Slurp China的Spider在爬，处于不一致状态，有的爬虫爬新的，有的爬老的，估计建库模块会比较疑惑，导致不更新网站索引，而Google的很快就都更新到新的上面了。

    差距。

    最近接触到一个Transfer-Encoding: chunked相关的问题，原来http在应答时，有两种方式来标示应答body的长度，一种就是用content-length方式直接指明body长度，还有一种就是chunk模式。

    在这种模式下，应答正文分段发送，每个chunk由长度段和数据段组成，每个段均由\r\n结束，当服务器发送完数据后，发送一个长度为0的chunk，即：0\r\n\r\n。其中长度段为十六进制表示。


举例一个长度11的chunk：

b\r\n12345678901\r\n



    chunk模式多用于结果长度未定的情况下，比如用php输出一个长字符串的时候，就默认使用的chunk模式，当然可以通过header来指定使用content-length模式。不过需要自己算出应答body的长度。

    chunk模式的一个好处是可以进行分段压缩，服务器对每个chunk进行gzip压缩发送给客户端。

    公司的电脑vi是有搜索高亮的，我自己的几个系统都没有，不过之前用搜索功能不算太多，也就忍了，今天终于决定要也给我的加上配置。

    在.vimrc里加上：set hlsearch即可。

    如果想单次搜索高亮，则:match Search /word/

    还有一个功能：set incsearch，这个是在搜索过程中动态高亮，就是在搜索时，随着单词的输入高亮其被找到的位置，不过作用感觉比较一般。

    今天发现一个问题，发现博客的js和css都没有gzip压缩，大号js动辄就20几k，很奇怪，以为是迁移导致的某个地方忘了开，查了下，发现之前的也没开，疑惑。

    我明明在ngix配置文件里加了gzip  on;了，但为啥js和css没有开呢，查了下nginx文档，原来默认只对text/html类型的压缩。

    加了一句：gzip_types application/x-javascript text/css
    ok，现在js和css都压缩了，加载速度又提高了不少。

    一个月前入了台湾vps，考察了一个月，感觉稳定性和速度上都还不错（废话，价格在那里），决定要把博客迁移过来，劳动节前动力还挺大，过了五一反而感觉一般般了。这周末搞了个监控程序，需要部署，正要往新vps上布的时候想想还是把系统重装一下，把测试用的那一坨东西都清理掉后再部署，以后再迁移的时候就不用重新布了。

   系统重装后开始安装基础环境，各项都搭好后心想，都基本搞定了，一不做二不休，直接迁过来得了，于是先用rsync把程序同步过来，webserver配置配了下，然后数据库导入，跑了一下正常了，然后切域名，搞定。
    然后去超市了，在麦当劳休息了一下，期间用手机访问了下，发现在线人数很高，突然想起来忘了部署我写的那个分辨爬虫的php扩展，从超市回来后把php错误日志打开，部署好php扩展，发现没装gd库，验证码出不来，装了一下gd库，搞定，速度很快。

   这时看日志发现google的爬虫异常活跃，大概以4s一个的频率重新抓站，莫非是看到了换ip要重新跑跑？baidu的爬虫毫无动静，又被bs了。