我们一般常用的压缩格式就三种吧，zip、rar、7z。今天我就对三种压缩格式做了一下对比，测试的内容有：用最大压缩算法压缩一个网站设计的PSD文件(裸体大小192M)后的大小，还有压缩时间，以及解压时间。
首先是zip，压缩时间以及解压时间未测试，压缩后大小是83.8M
其次是rar，压缩时间为40秒，压缩后大小是32.1M，解压时间是6秒
最后是7z，压缩时间90秒，压缩后大小6.29M，解压时间不到2秒
<注：zip其实我没测试，rar绝对是用winrar 64位版本测试的，7z是用7-zip软件测试>
最后，winzip以及winrar是收费软件，使用盗版有可能带来法律问题，7-zip是开源软件，任何个人以及商业组织可以免费使用
一般出现这个问题都是因为安装软件包的时候非正常中断造成的，解决办法也很简单
一般gentoo的portage都是这样命名的 “net-ftp/pure-ftpd” 类似于这样。
现在要做的就是，删除/var/tmp/portage/下面的 net-ftp 目录下的一个隐藏文件，名字和软件包的名字类似，然后再emerge就可以了
最近接二连三邮件出问题，前几天，买了个bluehost，安装有wordpress blog程序，昨天安装了个contact form 7的联系插件，使用的是blog程序的域名邮箱，可是邮件一直发送失败，上网搜索，竟没有很好的答案，在bluehost面板里面找，找到个“电子邮件递送路径”，点进去看看，追踪一下，提示“virtual_aliases via virtual_aliasesrouter forced address failure”，貌似是说发往本地的邮件，可是我没用bluehost的邮箱啊，再找找，发现个“MX输入”，估计是添加域名MX记录的，点进去，果然，可以管理域名的解析记录，估计是bluehost直接在自己的服务器上解析了域名，所以邮件发不出去，添加了我在GD那边的正确的记录，然后再发送，果然成功了，bluehost为客户想的太周到了，什么都做好了，结果导致这个问题，又是找了很久的原因
说这是小问题，其实也不小，折腾了我将近半年时间，那就是，服务器发送邮件到yahoo的邮箱，客户总是收不到邮件，所以一直建议客户不要使用yahoo的邮箱，今天坐下来，立志解决这个问题，一坐就坐到了凌晨三点钟。。。下面就来记录下我的解决过程
公司服务器给很多邮箱发邮件都正常，唯独yahoo的不正常，怀疑是yahoo把ip加入黑名单了，于是用telnet模拟了一下SMTP发信过程（网上教程很多，搜一下一大把，记得把消息全部写在记事本里面，然后只要复制粘贴就行了，不然手工输入很容易超时退出了），发现yahoo竟然能收到邮件，只不过是在垃圾箱里面，但是至少比收不到邮件强一点吧。这样的话，说明不是被yahoo加入黑名单。
然后我又在服务器上面tcpdump了一下
tcpdump -i eth0 -s 65535 -w /some/file
网上资料说，tcpdump默认dunp出来的数据只有200多个字节还是bit，所以要-s 65535一下，-w是写入结果到某文件，这样的话，可以用wireshark直接分析导出的数据，不然的话，分析数据累死你不偿命的。
tcpdump运行起来立即发送一封邮件到yahoo，然后重新运行tcpdump，再发一封到google邮箱，这样就得到了两个文件供分析。
分析结果令我大吃一惊，发送到google的邮件正常与服务器通讯，监控yahoo的那个文件，竟然没有发现任何一个smtp会话，于是乎，在网上找了一整天的资料，终于找到了qmail的日志，用下面的命令监控日志
tail -f /var/log/qmail/qmail-send/current
然后发信，发现了错误
@400000004e5933e615fe4984 delivery 2: deferral: CNAME_lookup_failed_temporarily._(#4.4.3)/
继续上网查资料，然后发现，这个错误产生的原因是qmail没打bigdns的补丁，补丁在这里下载 http://www.ckdhr.com/ckd/qmail-103.patch，虽然是1.03的补丁，可是到了1.06，这个问题依旧没有解决，真的要怀疑一下qmail的开发人员了，虽然是开源软件，但是也不要这样绝情吧，哎，还算不错的是，虽然是1.03的补丁，但是经过我测试，1.06版本依然适用
把这个文件下载到 /usr/portage/mail-mta/netqmail/files里面，然后编辑这个文件
/usr/portage/mail-mta/netqmail/netqmail-1.06.ebuild
在大约84行的地方找到
epatch "${FILESDIR}"/${PV}-exit.patch
epatch "${FILESDIR}"/${PV}-readwrite.patch
在下面加一行
epatch "${FILESDIR}"/qmail-103.patch
然后执行
ebuild /usr/portage/mail-mta/netqmail/netqmail-1.06.ebuild manifest
重新编译安装qmail，重启一些服务，/etc/init.d/svscan restart
再次测试，发送到yahoo成功！
l2tp 1701/udp
pptp 1723/tcp
懒得说明了，真正懂的一眼就看懂了，下面说说怎么查占用端口的进程
server ~ # netstat -anp |grep 1701
udp 0 0 0.0.0.0:1701 0.0.0.0:* 5986/xl2tpd
说明进程号为5986的进程占用了1701端口，可能是进程挂了，成了僵尸，所以常规的方法无法停止进程了，只能kill -9 5986 这样强制干掉了，下面启动xl2tpd就很顺利了
server ~ # /etc/runlevels/default/xl2tpd start
* Starting xl2tpd ... [ ok ]
话说丘老板介绍了ICG2000策略路由的配置方法，详见：
http://www.h3c.com.cn/Service/Channel_Service/Operational_Service/ICG_Technology/201010/697664_30005_0.htm
这边是双出口的解决方法，但是ICG2000这种路由器，只要设置一下就能支持N口路由了，双WAN显然不是办法，要设置多wan，是要靠if-match语句来判断，下面是我配置4wan的方法
acl number 2000 rule 0 permit source 192.168.10.10 0 rule 5 permit source 192.168.10.11 0 rule 10 permit source 192.168.10.12 0 rule 15 permit source 192.168.10.13 0 rule 20 permit source 192.168.10.14 0 acl number 2100 rule 0 permit source 192.168.10.20 0 rule 5 permit source 192.168.10.21 0 rule 10 permit source 192.168.10.22 0 rule 15 permit source 192.168.10.23 0 rule 20 permit source 192.168.10.24 0 acl number 2200 rule 0 permit source 192.168.10.30 0 rule 5 permit source 192.168.10.31 0 rule 10 permit source 192.168.10.32 0 rule 15 permit source 192.168.10.33 0 rule 20 permit source 192.168.10.34 0 acl number 2300 rule 0 permit source 192.168.10.40 0 rule 5 permit source 192.168.10.41 0 rule 10 permit source 192.168.10.42 0 rule 15 permit source 192.168.10.43 0 rule 20 permit source 192.168.10.44 0 policy-based-route mypbr permit node 5 if-match acl 2000 apply output-interface Dialer 10 policy-based-route mypbr permit node 10 if-match acl 2100 apply output-interface Dialer 11 policy-based-route mypbr permit node 15 if-match acl 2200 apply output-interface Dialer 12 policy-based-route mypbr permit node 20 if-match acl 2300 apply output-interface Dialer 13 interface Vlan-interface1 ip policy-based-route mypbr
到此结束了，记得测试一下，完了保存哦，不然断电你就杯具了
顺便附带一下改N WAN的方法
interface Ethernet0/2 port link-mode route
剩下的端口自己去配置吧，出去散步，bye
-------------------------------------------------------------------------------------
7月15日更新：
昨天发现一个问题，那就是，如果路由器上有多个vlan，每个vlan使用不同的网段，原本默认两个vlan之间是可以互通的，启用策略路由会导致vlan之间无法互通，使用tracert命令测试发现，数据会被直接路由到外网
解决办法就是再加一条acl，这次acl涉及到源和目的地，所以要使用acl编号为3000-3999的高级acl，这条acl是这样的：
[H3C]dis acl 3100 Advanced ACL 3100, named -none-, 1 rule, ACL's step is 5 rule 0 permit ip source 192.168.10.0 0.0.0.255 destination 192.168.5.0 0.0.0.255
然后在policy-based-route最前端加一句
[H3C]dis policy-based-route mypbr
policy-based-route : mypbr
Node 4 permit :
if-match acl 3100
apply output-interface Vlan-interface10
因为我的第一条匹配是node 5 所以这次就使用node 4就好了
最后说明一点，本文所涉及的代码命令基本都是display出来，请勿照抄，有什么不明白可以留言
转自职业欠钱 http://hi.baidu.com/zyqq/blog/item/668b9f3dba95fc19baa167ca.html
宅急送，是国内知名的物流公司之一。
根据百度百科的宅急送词条 描述，2004年该公司的总资产已经过2亿了。
这样的公司，应该算是个大公司了，我认为。
大公司应该就有大公司的范，我以前是这么认为的。
所以同事说，这次服务器发货，选择了宅急送，我并未过问。
只是万万没想到，这正是噩梦的开始。
2011年，5月11日，我公司2名同事出差在福建，计划将10台服务器发到上海。
当日上午10点，完成机房的手续，致电福建宅急送取件，结果到1点还没来，因行程安排紧凑（晚上的飞机要回上海），同事决定自己打车将服务器送至宅急送公司。
结果送到了以后，宅急送方面说，他们那是个“分公司”，没有打包服务，只有福建总部才有打包服务。
于是同事又继续打车将货物送到了福建宅急送总部。
期间，同事特意问询宅急送业务员：“如果货物丢失的话，怎么办？”
宅急送答复“会按照3倍运费赔付” ————（很好奇为什么宅急送业务员当时不提及可以投保？）
虽然觉得不合理，但快递行业采取的是“格式合同”，客户压根没有讨价还价的余地，于是就这么托运了。
杯具正式上演。
正常情况下，异地托运，3天左右航空件可以到达。
但不知道为什么，我们这批货迟迟没有消息。
中间同事打了福建宅急送业务员的电话无数次，对方都答复“已经到上海了，正在催上海宅急送方面解决”
终于，在5月17日（已经过去一周了），得到一个说法，由于“标签贴错”，3箱货发到上海丢了1箱。还需要上海宅急送方面去寻找。
这丢失的1箱货物里有4台服务器。每一台市场价都过万元。算上折旧，这一箱服务器也仍然价值数万元。
我们只好先收下到的2箱服务器，恳请宅急送方面再仔细寻找剩下1箱服务器。
（当时压根没考虑过这么大的货物会丢失，你能想象一个能装下3个人的大箱子整个不见了的情形吗？我不能）
5月25日，对方仍无进展，但流程上我们完成了“签字”，并标记了“其中1箱服务器丢失”。
期间，我的同事无数次的拨打宅急送客服、福建当地业务员手机，结果得到的答复不是生硬的“不知道”，就是推卸责任，说是另一方的问题，福建的怪上海，上海的怪福建。
最后居然拨打福建当地客服电话、福建承办业务人员电话都没人接了！！
（上海的宅急送客服电话还是接的，总是机械的重复“会联系专员说明情况，他们会在2小时内联系您”，但一次也没有兑现过，从来没有在2小时内真的联系过我）
这时候我们开始寻求新的解决思路。
我们在新浪微博上看到了宅急送的官方微博，还有几个实名认证带V的高管，于是发了若干条微博，@了他们。
很快，某位高管帮我们转发了，并@陈显宝 先生。（陈显宝是现在宅急送的CEO）
这时候，宅急送北京总部的客服主管（猜测的职位）也主动通过微博联系我本人。了解了一些情况并答应向上反馈。
最后，为了方便沟通，还排除了宅急送上海分公司的一名市场经理 常小姐来到我们公司和我们谈赔付事宜。
我们还以为看到了希望的曙光：
惊动公司最高层，老板亲自关照并指派专人负责处理。
第一次的谈判，常小姐带来的说法是，宅急送方面承认福建操作承办人员存在重大渎职，并且愿意赔付数千元的通融赔偿。因为我们并未投保，这个额外的通融赔偿已经是物流行业比较罕见的了。
我们表示赔付金额太低，面对硬件价值5万元左右，附加价值（含程序、数据库、误工）更高的损失，我们难以接受。
希望常小姐回去请示总部，并带来更合理的赔付意见。
结果常小姐回去请示后，
又没了声音，
等待了1个工作日没有任何答复，我们开始在微博上质疑宅急送的处理效率，因为请示一下意见，得到的答复应该是即刻的，一个工作日都没汇报的话，不符合常理。
而我们的心态也很理性：第一次的谈判中，常小姐有明确说到，如果我们不满意赔付金额，她可以回去再做适当的请示和申请。
那么我们自然会期待第二次会有略微提高的补偿。
此时，微博上不断的有朋友留言：“算了，能赔1万2已经很不容易了”
我意识到了双方谈判地位的不平等：原来宅急送这种级别的公司，在物流行业，丢失货物太稀松平常了，官司也常有，多一个不多，少一个不少，未投保的丢失货物，大不了赔付3倍运费。打官司就打官司咯。
这时候我安抚同事说：没关系，他们答应了可以再申请一点，这次无论他们加多少，我们就答应了算了，和解吧。
我话音刚落，却意外的得到消息：“鉴于我们在微博上无理取闹，已经对宅急送造成了事实上的品牌损坏，宅急送方面当初的忍辱负重和息事宁人的态度未收到效果，所以1.2万的赔付也拒绝做出了。如果不接受，你们可以去起诉，宅急送的法务部已经做好了应诉准备”
这让我充分理解了谈判地位不平等，和对方的强势。
照这个逻辑，
以后宅急送发货的时候，只要看到值钱的东西，干脆押下别发了，自己留着，然后借口你没投保，直接赔偿3倍运费好了。
反正去打官司也是这个结果。
交谈中，宅急送的客服人员提到了，这是邮政法的规定。
于是我上网去搜索了邮政法的全文。
第五章的 损失赔偿 里考虑到了物品丢失的情况赔付：
第四十七条 邮政企业对给据邮件的损失依照下列规定赔偿：
（一）保价的给据邮件丢失或者全部损毁的，按照保价额赔偿；部分损毁或者内件短少的，按照保价额与邮件全部价值的比例对邮件的实际损失予以赔偿。
（二）未保价的给据邮件丢失、损毁或者内件短少的，按照实际损失赔偿，但最高赔偿额不超过所收取资费的三倍；挂号信件丢失、损毁的，按照所收取资费的三倍予以赔偿。
邮政企业应当在营业场所的告示中和提供给用户的给据邮件单据上，以足以引起用户注意的方式载明前款规定。
邮政企业因故意或者重大过失造成给据邮件损失，或者未履行前款规定义务的，无权援用本条第一款的规定限制赔偿责任。
很显然，我们这个案例里，福建宅急送方面明显存在重大过失——就连上海客服的人员都说“这批货没有任何入库出库的记录，属于福建方面人员违规操作，他们全责”（有电话录音为证）
重大过失的情况，与主观故意没有本质上的区别。
综上所述，
1. 宅急送 服务态度不佳，预约时间不上门收件，还要我们主动上门送件
2. 宅急送 承办人员涉嫌误导客户 ，问及赔偿的时候，只提3倍运费赔付，不说可以投保，不满足格式合同的信息公开前提
3. 宅急送 逃避责任，电话追踪事件进展的时候，生硬的回答“不知道”，甚至挂电话，不接电话
4. 宅急送出尔反尔 答应的最低赔付和再争取的空间，事后一文不值
5. 宅急送 店大欺客 ，所谓的谈理赔事宜，居然只是开了个价，然后你们爱接受就接受，不接受拉倒的态度，事后还说“由于经过双方多次沟通都未达成一致意见”，明显睁着眼睛说瞎话
今天，我们已经收到宅急送最后的确认，连当初答应的1.2万元的赔付都不会赔了，
所以，我们本着客观，不夸大，陈述，不诬陷，理性，不冲动的态度，将事情经过整理出来。
并且，也转告了公司的法务，提交律师函，等待对簿公堂。
或许，这个案子我们会赢，但赔付多少不知道。或许还没有1.2万元。
但那已经不重要了。
在某些国家，一个不公平的现象，需要一个知名的案例和判决来改变。
在我们国家，或许需要千千万万的不公平案例累积，才能从量变到质变的驱动决策层改变现状。
那么，我们愿意不在乎这一点点小钱，成为千千万万奠基者中的一个。
并且，我希望，所有受到这种快递行业不公正的同胞能够联合起来，凝聚成一股可以让社会听到的声音。
不求对我们个人有什么回报，但愿改变无数个不公平当中的一个细节。
附宅急送最新logo以及宣传画
今天要介绍的软件名字叫 rinetd ，是linux下面一个端口转发软件。使用这个软件的原因是，公司有很多在外面的部门，每个部门都有指纹打卡机，每个月需要导出一次数据, 如果每个月去每个部门跑一趟来取数据，有点不现实，况且现在天气这么热，咱们又没四轮的。。。
本来可以通过路由器上端口映射加上花生壳来实现这个功能，可是软件 上面限制了考勤机的地址只能是IP，不能用域名，如图
这可麻烦了，每次先要获取IP，然后才能传输，如果能有一个软件，我连接局域网内某个固定IP的电脑，这个软件会去自己连接考勤机的域名，然后把考勤机的数据转发到这个电脑的端口上，我只要连接这台电脑的IP，不就解决了，于是上网找到这个软件，ubuntu下面的安装方法就是直接apt-get了，然后编辑 /etc/rinetd.conf
allow *.*.*.*
之后，下面会有转发配置的提示
bindadress bindport connectaddress connectport
bindaddress 意思是bind本机上某个端口 bindport意思是bind的端口
connectaddress connectport就是远程服务器的地址和端口了，这里是可以填域名的，比如我的配置就是
192.168.3.254 4370 kaoqin.domain.com 4370
执行下面命令
/etc/init.d/rinetd restart
重启一下服务，连接192.168.3.254就可以实现连接远程考勤机了，就这么简单
今天入手一台H3C ICG2000C，但是没有Console线，玩H3C没线当然不爽了，于是就自己订做一条，一端是RJ-45，一端是串口的DB-9头，按照如下方法连接
这种连接方法在ICG2000C上测试成功，不过网上也有一种说法，如下
如果第一种不行，大家可以试试第二种
