139 邮箱的 Pushmail 看起来还挺好用

139 邮箱的 Pushmail 看起来还挺好用

原本很早以前 10086 就一个劲的给我打电话推销 139 邮箱,说免费啥的,但是我手头邮箱已经够多的了,再开这么一个能给自己不停发骚扰短信的邮箱似乎也没啥太大用处,于是很坚决的拒绝了。前几天看到招行也在推广这个 ,说通过招行开通 139 邮箱有 139 个积分送,而且收费的 139 邮箱还可以多免费用一阵子,于是顺手开通了 5 元版本的,打算体验一下传说中的 pushmail,没想到这个 pushmail 远比想象的要好用。

开通 pushmail 的时候需要下载一个客户端装上,我的 m600i, uiq3 的系统居然也有支持,装上的很顺利。我本来一直以为 pushmail 这个东西只能在 blackberry 机器上做出来,而移动这个 pushmail 是山寨货,需要靠客户端不断的连接上 GPRS 去查询一下,就像飞信那样,但实际使用的时候发现它还真是 push 的,平时没看到手机有任何 GPRS 行为,但一旦给 139 邮箱里面发一封信,在十几秒钟之内就会看到手机自动开始连接 GPRS 并下载邮件,下载完邮件以后就又迅速断开 GPRS。然后就是这个客户端做得很有 SE 自己软件的特色,邮箱内容显示风格和 m600i 自带软件几乎完全一样,弹出联系人框和自动补全之类更是神似,怀疑是移动直接外包给 SE 做出来的。不管怎么说,用起来确实相当顺手,比飞信那个 Java 界面要顺手多了,而且还比飞信省电且不需要加好友,可以一定程度上代替飞信用来聊天。。

我现在已经打算把这个 pushmail 功能续下去了,看来果然需求都是培养出来的,之前也没觉得在手机上直接收发邮件有多方便,现在用了才知道。

另外友情提示其他想用这个 pushmail 的人,如果要用 pushmail 建议将 139 邮箱的短信提醒给关了,否则经常会短信提示也到了,这个也提示收到邮件,很烦。

数据安全,从异地备份开始

话说我的 blog 也 down 了有数次了,每次 down 掉以后都好久起不来,其中很大程度上是 blog 的数据没有及时备份出来,用以前的备份开的话,中间的就都丢了,回头合并又是个麻烦事情。

最近有点时间,在北京机器上的 MySQL 配置了一下,让他作为从库从唐山机器的 MySQL 同步下来 blog 的数据,只要网络不是太烂,基本可以做到实时备份了。

当然,从公网上用 MySQL 复制存在各种风险,不过实际能做的事情不多,只能用 iptables 保护,只对同步机器开放 MySQL 端口;关闭除同步账户之外其他所有用户的网络访问权限;同时使用 MySQL 内建的 SSL 功能防止监听;最后复制用的账户要求 SSL 发行者校验,只相信北京机器发过来的 SSL 连接请求。

不过现在异地备份还是太近,不满足 1000km 的基本要求,无法抵抗华北平原地震,要不要再在美国买个便宜空间专门定期上载打包后 gpg 加密的备份数据呢?

支付宝的控件也够脑残的了

自从支付宝控件某个版本开始装驱动拦截键盘以后,我就没能在我的 Vista 下面正常用起来过它,无论是在 IE 里面直接点 cab 装,还是下载下来装了以后重启,都不成,访问 www.alipay.com 的时候 IE 还是让我安装,不知道发生了什么事情。害的我明明在 Windows 下面,却不得不用虚拟机。

然后更恶心的一个事情是发现这个用驱动拦截键盘的版本,不知道是为什么不认我的远程桌面,远程桌面上去的时候在支付宝控件中输入无效,我在水木上发帖说这个事情,有人还专门回我信箱说没这个问题。。。当然可能确实是我用的 seamlessrdp 和它有点冲突。看水木上面的帖子,有人甚至因为这个破控件不认自己的键盘导致无法登录而搞得差点重装系统,最后是靠 remote registry 才删掉。

招行的控件虽然也被很多人骂,但至少没出现这么多不兼容报告。支付宝这控件的测试貌似还差的远,而且他们似乎很着急的就把网页上面要求的最低控件版本号给升了,搞得我专门装上囤积的老版本控件都不能用。

唉,说这么多也是没用的,还是等什么时候彻底闲下来,自己反向算法搞个山寨版本的出来自己用吧。

郁闷,折腾了这么久,才发现居然是双工的问题

这个机器最早刚拿到机房的时候,发现不知道为啥,启动时候总是协商成 10M 半双工,但是交换机和网卡显然都是 100M 的,于是只好在 rc.local 里面加了一条 mii-tool -F 100baseTx-FD eth0 , 这么一直用了一年多也没有太大问题。后来因为一些原因,这个机器 down 了又有一年多,再起来以后就总觉得这个机器网络慢,在 shell 上面执行比较大输出的操作,都会一卡一卡的,一直没搞明白是为什么。这段时间为了解决访问 blog 慢的问题,对 web 进行了不少优化,gzip, expire 啥的都设了一遍,有一点提升,但是没有特别明显的效果。因为没有太多时间,所以就懒得管了。

今天稍微清闲了一点,就仔细研究了下这个问题,发现从同一内网用 ab 压 17K 的静态文件最好情况下只能到 40 个每秒左右,大文件则是只能到 1.8MB/s,这明显有问题。但是 ping 也看不到什么丢包。

习惯性的看 dmesg 的时候,发现网卡每次启动时候还是会协商成 10M 半双工,这就奇怪了,机器经过这两次倒腾,机箱换了,网卡也换了,网线也换了,交换机上网口也换了,为啥还是 10M 半双工,莫非这个交换机其实只能上半双工?于是 mii-tool 重新调整为 10M 半双工,马上 shell 就不卡了。

但是 10M 半双工虽然 shell 不卡,带宽实在比较不能够接受,于是尝试了一下 100M 半双工,貌似效果很好, HTTP 大文件同一内网能到 8MB/s, ab 那个 17K 的静态文件可以压到 400 个左右,这样看起来就还算凑合了,虽然总的来说不是很高,但对这个破机器,还是可以接受的结果。

最后的结果就是 rc.local 里面改了一行

mii-tool -F 100baseTx-HD eth0

至于为什么不能上百兆全双工,这问题也懒得研究了,先这样用着好了,我要求不高。

另,这机器以前的网卡是 3C905B(3c59x),后来用了几天 8139(8139too), 现在是 DFE-530TX(via_rhine),都不是什么特别好的网卡,不过都协商成 10M 半双工也真是够那个的了。。

邪恶的泛域名

邪恶的泛域名

前段时候发现域名经常不好用,在很多机器上面很长时间解析不出来。今天有点时间,就研究了一下,发现原来是泛域名到 CNAME 导致的。

这个域名用了 CNAME 两次的方式来做双网分流,也就是 www.host.com 长时间 CNAME 到 www.a.host.com ,然后 www.a.host.com 会根据不同的来源 CNAME 到某个机器名,最后某个机器名对应到某个 A 记录。出问题的原因是,有 IPV6 支持的客户端通常会先请求 AAAA 记录,如果没有则会再次请求 A 记录(没仔细研究过 DNS 协议,虽然好像协议中有 ANY 选项,但是我 tcpdump 出来的结果,过来无数 AAAA 请求)。对于 AAAA 记录,www.host.com -> www.a.host.com 和 www.a.host.com -> machine2.host.com 的 CNAME 都正常执行了,在 machine2.host.com 到地址的时候,假如有 AAAA 记录,那么这时候当然是正常返回该记录,但是实际上没有,于是落到了以前设置的一个泛域名解析上面了。这个泛域名解析会将 *.host.com CNAME 到 www.host.com,造成了死循环。这时候会返回一个 SERVFAIL,客户端则会去重试其他 NS,直到完全失败,才会再发起 A 请求。

解决办法两个,要么就取消泛域名,要么就泛域名不要到 CNAME, 直接到 A 记录。我是直接干掉泛域名了,懒得折腾。

至于为什么用 2 次 CNAME 来做分流而不是 1 次或者直接用 view ,那是因为某些原因,总的来说,还是因为我懒。。

最近评论

时光机

其他