首先是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就可以了

公司服务器给很多邮箱发邮件都正常，唯独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成功！

懒得说明了，真正懂的一眼就看懂了，下面说说怎么查占用端口的进程

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这种路由器，只要设置一下就能支持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出来，请勿照抄，有什么不明白可以留言

宅急送，是国内知名的物流公司之一。

根据百度百科的宅急送词条 描述，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以及宣传画

本来可以通过路由器上端口映射加上花生壳来实现这个功能，可是软件 上面限制了考勤机的地址只能是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就可以实现连接远程考勤机了，就这么简单

这种连接方法在ICG2000C上测试成功，不过网上也有一种说法，如下

如果第一种不行，大家可以试试第二种