Snooda

    从sendmail迁移到postfix，由于在服务器上有邮件转发服务，之前对于任意目标邮件地址都转发到固定账户，然后由一个分拣程序根据规则分发。sendmail在/etc/mail/sendmail.mc里添加：define(`LUSER_RELAY',`local:default_account')dnl，然后make -C /etc/mail重新编译一下即可。

    对于postfix就复杂很多了，参数有本地alias，virtual alias等等很多概念，刚开始尝试virtual alias，用virtual_alias_maps指定对应的正则文件，同时需调用postmap编译一下正则文件成db。设置了几条正则，发现总是命中第一条，奇怪，后来在正则表达式都加了^和$进一步限定了一下才好，比较奇怪。但后来发现针对用户名做alias不可行，因为向外发出的邮件也会做alias，导致无法发邮件出去。
    然后尝试alias_maps和alias_database，这两个参数的区别没看出来，看文档说是都是针对本地邮件的规则，默认都是/etc/aliases文件，但这个文件不支持正则，因为用的是：alias_maps = hash:/etc/aliases，尝试了一下alias_maps = regexp:/etc/postfix/aliases，发现会死循环。也比较恶心。当然，这个aliases文件也需要调用newaliases编译。

    最后又回到使用virtual_alias_maps方式，因为找到了一个方法，原来可以对域设置默认值，这样只要在/etc/postfix/virtual设置：@domain.com default_account 就ok了。然后使用virtual_alias_maps = hash:/etc/postfix/virtual，重启postfix即可。



    postfix功能强大，配置也复杂不少，文档不是很丰富。配置坑很多，有待研究。

    今天在一台新机器上调用mutt时发现一个问题，报找不到dst@example.com这个文件，而dst@example.com是邮件的目的地址，命令在centos上运行正常，在ubuntu上就不行了，查了下，原因是我用了管道向mutt传送正文，并且用-s指定了标题，目标邮件地址跟在标题后面，导致新版mutt认为目标邮件地址也是一个标题。在地址前加上两个减号就ok了。

    echo ‘my comment" | mutt -a file -s SUBJECT -- dst@dst.com


    这时还是发现报错，说邮件过大，原来postfix默认邮件大小是10m，而我发送的备份邮件单封是20m，所以需要在/etc/postfix/main.cf中添加配置：message_size_limit = 0  不限制大小。ok了。

    前几天百度快照和流量都恢复了，心情很好，但今天看收录时突然发现迁移前服务器绑定的那个临时域名居然也在收录之列，这个不是一个好的现象，因为如果爬虫同时对两个域名同时抓取，会得到相同的内容，对于重复内容是很不利于收录的。查了下快照，发现百度依旧动作很慢，收录只有一页，还是迁移前的那个测试页，google则全都收录了，怪不得迁移时google非常活跃，现在回想应该不是爬主域名，很可能是发现那个临时域名指向的站点大更新，在爬那个。

   纠结的是nginx默认配置居然不打印请求的host域名，无法考证之前爬虫爬取情况，亡羊补牢，幸亏nginx默认留空了日志第二个字段，打印的是“-”，正好用来打印域名，将-修改为$host，重启后就打印了。


   对于已经收录的临时域名，需要将流量都导入到主域，在nginx里配置了一下301跳转：

    if ($host = 'tmpdomain.com' )
    {  
        rewrite  ^/(.*)$  http://maindomain.com/$1  permanent;
    }



   ok

    今天发现程序中有几个地方在没有校验指针为NULL的时候进行了打印日志操作，在字符串处理函数中使用NULL指针不是什么好事，研究了一下，发现在一些的linux发行版中，printf("%s",NULL)会打印一个“（NULL）”，而在solaris中则会出core，windows下也没有问题。

    可见不同的c库对于这个行为的实现不太一致。

    使用中还是要尽量避免这种用法，不过每次打日志前都要判断指针情况确实比较恶。

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

    对于原创内容的对待上百度比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的很快就都更新到新的上面了。

    差距。