Planet of Woodpecker.org.cn for CPUG

July 30, 2014

@shell909090

14年7月,无甚大事

这个月比较忙,啥都没说。堆月底做个总结吧。 空难 一个月三起,马航又来一次。我都 … Continue reading

by shell909090 at July 30, 2014 03:45 AM

July 11, 2014

@delphij

India NIC签发未经授权的 Google SSL证书事件

详情参见 Google Online Security Blog

说两个我认为比较有意思的事情:

第一个是 Google 并没有公布作为证据的证书。由于证书是以 CA 的私钥签署,因此这类未经授权的证书本身就可以作为证据。但是,Google这样做(不公布证书)意味着签发者不得不销毁全部签发的证书,而不仅仅是被公布的那些。

第二个是 Google 在 Chrome 中限制,而不是直接删除或禁止了负有责任的根CA: India CCA 的许可范围。我认为这是远比禁止使用或删除根CA更好的做法(同样的原则也适用于几年前 Mozilla 基金会决定接纳 CNNIC 证书),原因如下:

  1. 在攻击者使用未经授权证书的同时,他们也将自己的身份(持有私钥)暴露在了阳光下,从而使检测和指证变得容易
  2. 加密通讯要比不加密好。鼓励所有人加密通讯,有助于提高攻击所需的代价。
  3. 限制使用范围削弱了CA的权力,阻止了恶意CA对用户的影响,同时对正常证书持有者的影响又不大,降低他们的迁移成本。

by Xin LI at July 11, 2014 06:42 PM

July 02, 2014

@shell909090

July 01, 2014

@shell909090

狗肉节

吃没吃过狗肉 吃过,还不止一次,不过自己没点过。没特别觉得好吃,也没觉得难吃—— … Continue reading

by shell909090 at July 01, 2014 02:44 AM

June 30, 2014

@shell909090

docker的原理和类比

从虚拟化的种类和层级说起 cpu虚拟化:可以模拟不同CPU,例如bochs 完全 … Continue reading

by shell909090 at June 30, 2014 04:32 AM

June 26, 2014

@shell909090

核聚变?

最近看到一篇文章極限DIY之核融合反應爐。昨天和朋友吐了不少槽,我总结一下。 真 … Continue reading

by shell909090 at June 26, 2014 05:34 AM

June 19, 2014

@delphij

Windows 2003笔记补遗

接上回书。

启用 virt-net 支持。采用 RedHat 的 virtio-win-0.1-52.iso 版本驱动,这是最后一个可以在 Windows 2003 上安装的版本,之后(0.1-59 及以上)的版本均有问题,这里先记一笔,等有空的时候再看看到底 KVM 把哪儿改错了。换网卡的过程中需要重新激活 Windows,直接网上激活即可。

将原有的 IDE 控制器换成 AHCI 控制器。这个其实主要是体力活:先切换芯片组并增加一个 AHCI 控制器,启动 Windows,然后在 Intel 网站找到 AHCI Windows 2003 的驱动(F6那款,以前装 Windows NT 时代插软盘的那种),那个未知设备就是虚拟出来的 Intel AHCI 控制器,选中刷掉驱动。重启后可摘除 IDE 控制器,并将磁盘挂到 AHCI 控制器上。

然后注意在 Windows 2003 中启用磁盘的 Advanced Performance,在换控制器的时候会需要。

by Xin LI at June 19, 2014 08:24 AM

June 18, 2014

@delphij

如何:将现有的 Windows 2003 单处理器实例转换成多处理器

我知道这是个十分蛋疼的需求。

这篇 介绍了如何转换,但是实际情况是进 Device Manager,打开 Computer,只会看到两个适用于单处理器的选项(一个ACPI,一个非ACPI)。

仔细查资料发现需要使用一个叫 DevCon 的工具。Q311272 可以下载这个工具。DevCon 可以绕开 Device Manager 的一些限制。

接下来是暗黑科技:

SET HAL=ACPIAPIC_MP
devcon.exe sethwid @ROOT\ACPI_HAL\0000 := !E_ISA_UP !ACPIPIC_UP !ACPIAPIC_UP !ACPIAPIC_MP !MPS_UP !MPS_MP !SGI_MPS_MP !SYSPRO_MP !SGI_MPS_MP
devcon.exe sethwid @ROOT\ACPI_HAL\0000 := +%HAL%
devcon.exe update %windir%\inf\hal.inf %HAL%
devcon.exe ReScan

然后重启即可。这一操作适用于在虚拟机中安装了Windows 2003,然后主机升级,增加内存及CPU数量之后的情形。

by Xin LI at June 18, 2014 11:48 PM

June 09, 2014

@shell909090

上海的出租车越来越不像话了

事情

5月24日,我乘一辆出租车从玉兰路杜鹃路到纪念路汶水路。上车第一时间,我报了目的地,然后脱口而出的是走外环。司机纠正了我这点——外环太绕路了。我说对对,您怎么走。他说南浦大桥。南浦大桥能走么?我说不知道,您走吧。

OK,30分钟后,我就发觉好像不对。计价器已经高达了50,而目的地还没有影。我没和司机说,我岳母家就在旁边,这两个地点我经常来返,一般都是40-50之间。

到地方一看,80。我擦。。。算了,公司有事,回头再处理。

办好事情,回头打电话给法兰红,报上车号证号,上车下车时间地点。完了回复我说,7个工作日之内给回复。我说OK。

过了几天,等等不来电话,我再去打了一次。法兰红接电话的人也很奇怪,已经转给他们了,怎么还不回复呢?

今天(6月6号),实在忍不住了,再打了一次。法兰红的人直接给了宫霄的电话。打到宫霄去,差点没把我气死。

他首先慢悠悠的说,上车你怎么和师傅说的?我说外环。他说你都要走外环了,还指责师傅绕路?

我了个去,我要去北京路不小心说了个北京,然后说不对不对。师傅真给我开北京去也合理?何况当初师傅已经说了,外环太绕,走法不对。这明显是口误还拿来说事。

然后他说,师傅这个不算绕路。你上车时让师傅随便走的,师傅按照自己的判断走的。

我当场就骂娘了。我XX你个女性直系亲属的,说了随便走就可以随便走啊。你让客人到你家随意,是不是他XXXX你个女性直系亲属你也随意啊。当晚我反向打回来,大众的车,只走了14公里。你的师傅走了23.3公里,这叫判断?是判断能多赚我多少钱么?

他又慢条斯理的说,师傅开的时候说了往南浦大桥走的啊。

我擦,我上海盲,去那里只知道一条道——大连路。还有好像内环也行(这就是口误成外环的原因)。师傅说哪里更快,我就说跟着走啊。不是这次我哪里会去查“从玉兰路杜鹃路到纪念路汶水路”的路里面“是不是走南浦大桥不合适”呢?

电话对面的沉默了一会,又说,按照师傅的判断,在那个点走大众那条路会堵的更厉害。你上车的时候也说快一点的,现在不认了?

我OO你个XX,..你个**。绕路不往市郊绕,绕到市中心去了?你说大连路隧道会堵车,杨浦大桥会堵车,我不敢说不会。你说从南浦大桥开过市中心比他们更空,我还真不信了。何况这条路一绕就是10公里,本来一个14公里的路,总共24公里你能开到25分钟以内?我TMD的老老实实走预期也就是半个小时而已。为了省5分钟(还没准),多花60%的车费?你脑残还是我脑残?而且从结果来说,更快了么?结果还是半个小时开到。

更何况,公司的同事从张江打车到同一地点,47元,半个小时多点。充分证明当时事实上就没有堵车,唯一对堵车的判断只来自于驾驶员的内心。

对面沉默了一会,又和我扯师傅当时自己的判断。我懒得和他罗嗦。“自己内心的判断”用在每个绕路案例上都是一个无法驳斥的东西——你不能指着一个人说,我知道你内心里明知道这是绕路的,You know it。既然无法驳斥,索性跟他说我会打回法兰红,就这样吧。然后挂了电话打回法兰红。

值得玩味的事在后面。法兰红的人听完整个流程,一言不发,给了我上海市运管处的电话。照理说作为管理母公司,你觉得我不对应当直接告诉我“师傅是对的”。如果你觉得我对就应该直接处理。运管处电话可能把没事的事惹出事来。给我运管处电话,基本只有两种可能:

  1. 运管处肯定会打太极,或者什么都不做。所以拿运管处当挡箭牌。
  2. 这件事我们也有难处。索性简单点,你有本事再往上面投诉。投诉出了结果,也没人有话说。但总之我们这里我没法帮你处理掉。

我打给运管处,他们说接受投诉。然后又是一通车号证号的,然后等回复。

分析

无论如何,宫霄出租车公司在管理上至少有以下几个瑕疵:

  1. 七天内不回复。没什么好多废话的。
  2. 根本没给乘客选项。在整个乘车过程中,出租车司机就没提供过“大连路隧道”和“杨浦大桥”这两个选项。如果你要用一个绕路的方案,至少要告诉乘客,可以走大连路,但是会堵。最后“大连路隧道”是我和宫霄的运管人员争论的时候出现的。

我有次曾经坐过一辆大众的车,从曹河泾回家。问说回浦东能不能更快点什么的,例如走徐浦大桥。司机马上跟我说那样会绕路,起码绕10公里。如果一趟车,乘客自己要绕过50%以上,哪怕是乘客自己要求的,也会要求乘客签单子避免责任。我当然不指望每个公司都有这个水准,但是至少说明“绕路一半以上”并不是什么常见选项,更不会是唯一选项。

其实我在坐车的时候,经常会和司机聊聊天。虽然大部分的司机都很油滑(上海话讲“老油条”),但是其中碰到的大部分人不坏。我见到过因为我身体不适,不能吹空调。大夏天关着空调开车子,开的自己一身大汗的师傅。我见到过不小心东西掉在车上,不要额外收费给我送回来的师傅。我见到更多的师傅,冷淡,油滑,事不关己高高挂起。但是基本上,大部分人都不坏。靠自己的本事吃饭,不会恶意绕路,或者拿着乘客的财物不还(要乘客出送还时的车费我觉得是合理的行规)。

但是,这一情况,在这几年,是越来越差而不是越来越好。

这一问题,我碰到一位师傅,他的分析让我觉得有几分道理。一辆车,一天24小时管理费300-400,油费300-400,一天要做到傍晚,挣的才是自己的钱。15天做一休一,才能挣到6000-7000元上下。有路道的做做私人司机,虽然只能挣个4000,但是工作强度只有三分之一不到。剩下的时间陪陪家里人,炒炒股票,上网卖点东西,日子也过的去。照他们那个强度推算,我们应该挣12000的。所以现在越来越没人要做出租车了。有本事的开开大车,有路道的当私人司机,或者做做小生意也行,只有其他什么都做不了的才做出租车。

我说所以出租车司机的素质越来越差么?

他说还不止。很多时候运管处要管,又没法管。管多了,司机不做了,运管处还要费心找人补上。出租车在上海是属于公众交通而不是私人企业,不能说不做就不做的,不做就大事件了。但是要做,又没有人,只能对一些事情眼开眼闭。对着乘客说,我们已经严肃处理了。对着司机口头警告警告算了——反正他们这辈子没那么巧刚好碰上。

他一说我顿时觉得确实是这样。07年的时候我投诉过一次拒载。当时公司运管核对了事情就和我说,要师傅打给你道歉还是怎么处理。我说还能怎么处理。他说扣师傅一天工资(好像是一天,还是多少),给我100元举报奖金。我想想算了,不是那么大的事,不结那么大的仇。师傅真给我打过来道歉了(虽然听着心不甘情不愿的)。12还是13年我投诉机场有人拒载的时候,公司运管给我打了个电话。“我们感谢您对公司的支持,如果没有您的举报,我们肯定无法发现这些败类。对于这次的事情,我们会严肃处理,以敬效尤。”听着很爽,不过注意到了没,既没说当事人的处理,举报奖金什么的也只字不提——而且关键是这个说辞很流利,我感觉这哥们的工作就是复读机。

这次,个人觉得,法兰红的运管对下属小公司也没有办法了——乘客你要来自己来吧。

建议

下面主要是给台湾朋友的建议了。我的外地朋友里面北京和台湾人比较多,如果是欧美——大概也看不懂中文吧。

不要随意打车。

如果你真的需要打车的话,先确定这不是一辆套牌车。套牌车运管是处理不了的,有什么问题自己倒霉。套牌有点像天灾,很少碰到,但是一旦碰到就是自己倒霉。你最好先看一下出租车的内装,如果不对的话就不要上车。

再确定这不是一辆小公司的车。哪些是大公司?巴士,大众,锦江,强生,海博,海虹,农工商。至少这些牌子我还叫的上来。其他公司的车子,一般也不会碰到问题。但是一旦碰到就很难处理。

注意,这不是说小公司没什么好人。我在小公司的车里面,碰到过很多很好的师傅。只是说,这些公司的投诉管理机制不给力——你得祈祷你没有用到这些机制的机会。

上海出租最重要一个特点是,属于公众交通而不是私人服务。因此有一条很特殊的规定——拒载投诉。主要是针对司机一听你这个地方,觉得不合算就不去了,你可以投诉他。

所以上车前先问师傅做不做生意。等师傅说做,上车后他问你去哪里再说。千万不要当街就把自己的目的地大声说出来。如果出租车司机没有主动询问你目的地,或者确定表明自己做你这单生意,你是不能投诉拒载的。也就是说,如果你一喊,我就去个隔壁。得一堆师傅纷纷表示不做你这个生意了——这是你自己问题,无法投诉。

而且如果你扬招车的时候,师傅当着你的面把出租车运营灯关了——也无法投诉。你自己拉开门坐进去,师傅关掉运营灯——无法投诉。你主动跑上去告诉他去哪里,他关掉运营灯——也无法投诉。

上海出租的一大奇观,就是在下午4-5点的下班高峰。你招手的时候,一堆车纷纷关掉运营灯——这是他们到了交班的时间,只能去特定的方向。如果你的方向不对他们是不会问的,省得给自己找麻烦。对了,如果上车前师傅已经说了只去哪里——也无法投诉。

另一个就是记得收好发票了。上海出租的乘车凭证就是车票,没有车票是不能投诉或者报销的。如果出现东西丢在车上也是要凭车票找人的。所以下车记得拿票。

至于东西忘在车上——抱歉不要指望。如果你有确定的证据证明是司机拿的,你可以投诉,或者卯起来告他到死。但是司机没有义务保管你的财务,或者在你下车时确定东西都拿上了。所以如果不能排除后面的乘客拿走的财务——事实上很难排除——那么几乎找不回来,而且你也不能投诉他。

哪种情况是可以比较完美的排除的?如果你的电话过去的时候,司机的第二个乘客还没有下车。这时候,还没有人离开过出租车,所以不是司机就是乘客拿了你的东西。但是比较悲剧的是,司机是没有权力搜查乘客的。所以如果乘客坚持没有看到,你还是没办法。

所以?要养成一个习惯。离开车前慢悠悠的搜一遍,确定东西都拿了,再下车。你搜的再慢,司机也不能赶你下车——你也不会真的搜上半天吧。

by shell909090 at June 09, 2014 09:46 AM

June 06, 2014

@shell909090

cgroup限定内存

机器配置

ubuntu 12.04

内核版本:3.11.0-20-generic

ulimit的限制效果

  1. ulimit -m 8192
    当内存突破8M时,什么事情都没有发生。直到38M都没任何反应。

  2. ulimit -v 65536
    python抛出MemoryError

cgroup的限制效果

  1. echo 8388608 > memory.limit_in_bytes

大小不对,cgroup的内存量计算方法和ps/status不一致。因此限制计数需要根据具体情况调整。

内核计数

/proc/[pid]/statm

size       (1) total program size
(same as VmSize in /proc/[pid]/status)
resident   (2) resident set size
(same as VmRSS in /proc/[pid]/status)
share      (3) shared pages (i.e., backed by a file)
text       (4) text (code)
lib        (5) library (unused in Linux 2.6)
data       (6) data + stack
dt         (7) dirty pages (unused in Linux 2.6)

/proc/[pid]/status

statm的size和resident分别乘以pagesize等于VmSize和VmRSS。

pmap

pmap -p [pid]

可以看到某个进程内部,用户地址空间分配情况。

pmap -d [pid] | grep 'rw' | awk '{a += $2} END {print a}'

可以看到所有可写入的内存大小,应当正好等于正常显示的writeable/private。

这个值,应当等于status的VmHWM+VmStk。不知为何,VmStk和pmap里面显示的stack正好差了一个4k。怀疑是关于目前在正在使用的页的计算差异。

而high water mark,从分析上说,即是某个进程内部,不是stack的,所有可写的地址空间。当然,这些页并不一定立刻映射了物理内存。因此VmHWM > VmRSS应当没什么问题。

ps

ps和top都是读的status,不废话。

资源限制实践

准备

安装cgroup-bin

aptitude install cgroup-bin

setup cgroup-bin

修改/etc/cgconfig.conf:

mount {
        cpu = /sys/fs/cgroup/cpu;
        cpuacct = /sys/fs/cgroup/cpuacct;
        devices = /sys/fs/cgroup/devices;
        memory = /sys/fs/cgroup/memory;
        freezer = /sys/fs/cgroup/freezer;
}

group memimage {
        perm {
                admin {
                        gid = root;
                }
                task {
                        uid = user;
                }
        }
        memory {
                memory.swappiness = 0;
                memory.limit_in_bytes = 2048000000;
        }
}

限定内存用量2G。

service cgconfig start

执行效果

头部加入nice -n 19 cgexec -g memory:memimage

注意:使用内存限制,务必配置OOM日志告警通知。当重启时,管理者必须知道。当重复发生时,必须重新考虑内存限制问题。

监测

查看group内存状态

watch cat /sys/fs/cgroup/memory/memimage/memory.stat

by shell909090 at June 06, 2014 06:34 AM

@delphij

OpenSSL 的新一批漏洞

今天早上4点多就爬起来准备发安全公告(友商约的是早上5点发),一刷,OpenSSL官方已经正式发表了(时间大约是4点30),于是立即开始相关手续,commit修正,发公告,通知CERT,这些不表。

总体来说,这次安全公告比之前 Heartbleed 那回要有序的多,这主要归功于上回大家的声讨以及 Solar Designer 同学做的友商提前告知列表。大致时间线如下:

  1. 6月2日凌晨: OpenSSL 通知友商列表存在问题,要求同意 TLP:Amber 之后才告知具体细节。签署后约1小时得到了具体说明及补丁。
  2. 6月2日-3日:各友商各自修补,发现及反馈补丁问题。由于 TLP:Amber, FreeBSD 只有我和 des@ 及一位 OpenSSL 核心成员看到了公告草稿及补丁。
  3. 6月3日:FreeBSD 发表了本月第一批安全公告(这是更早前计划的周二批次)。此后立即开始着手联编 OpenSSL 特别更新。

本次问题可分成两类:SSL/TLS 和 DTLS。DTLS 常见于采用 UDP/SCTP 等 datagram 协议的应用,实际影响范围较小。

SSL/TLS 方面,CVE-2014-0224 CCS协议可在任意状态下使用的问题,可导致中间人攻击,后果严重,利用容易(可改变网络数据即可)但实际影响面较小,因为大部分人使用的浏览器并不是用 OpenSSL 来实现 SSL/TLS 支持的。但对邮件本身未做加密的邮件来说,基本等于是全军覆没了。这个漏洞存在了约16年,是的,十六年。发现者blog [英文]。我想,可能搞个可以形式证明的描述语言来重写SSL/TLS的实现才是正路?

另一个 CVE-2014-3470 可导致崩溃,影响较小一些。

值得一提的是,这次的一个 DTLS 问题 CVE-2014-0195 (可有任意代码执行之虞)也是上回引入 Heartbleed 的 Robin Seggelmann 引入的,呵呵。


总体来说,我觉得这批漏洞让人觉得有些绝望。 OpenSSL 有非常多的问题,但其中有很多必须对协议十分理解才能看出来,而另一方面看出来了报告给开发者也无非是得到几句赞扬而已。在现在这个年代,有能力看出来问题的人未必不会选择找个好的买家把漏洞卖掉。这种趋势十分危险,而最近几年有愈演愈烈的趋势。

by Xin LI at June 06, 2014 01:16 AM

June 03, 2014

@shell909090

为什么running不高但是load很高

很多初学者会混淆几个概念。CPU繁忙程度,load。两者的区别在于,一个秘书是真的忙着抄抄写写,另一个么,反正领导只检查桌子上堆的文件数。只要桌子上准备一堆文件,在文件里换来换去就好了,没必要真的很忙。当然,大多数时候桌子上堆着很多文件的理由还是因为秘书手不够了,不过少数时候也有例外。例如fork boom,CPU很空但是load奇高。

我们就遇到了一个例外的例外。

症状是这样的。系统经常出现偶发性的load过高。例如有那么几分钟,load会高到100-200,然后就快速下降。但是检查后发现,即使在load极高的时候,cpu占用率也并不高,大概在10-20左右。磁盘吞吐也一般。那么load为什么会这么高呢?

我的第一怀疑当然是超多数量的小线程,在那里搞切换调度。所以我第一反应就是看了/proc/loadavg的当前活跃线程数——结果居然只有1-5。为了确认,我特意的持续观察了数次,在我观测期间load的1分钟计数还升高了——这说明当前实际队列比1分钟平均还要高,而活跃线程却是3。

怎么可能?交通系统报警说北三环大赛车,平均堵塞长度500辆。去一辆警车到现场回报说只看到塞了两辆,再去一辆说算上我们自己三辆。去了十多次都如此。任何脑子清楚的人都会毫无疑问的喊出——黑箱政治,政府不作为,我们要占领国会——不好意思,我们好像没有这个东西。

OK,言归正转。为了解释这个疑惑,我特意的去看了一下内核源码——我擦,loadavg的平均值计算中,是把uninterruptible算在一起的。而活跃上下文中,只算了nr_running!

——你丫敢再精神分裂点么?

为了确认,我还特意man proc,结果发现里面确实有说,平均值是R和D两者去算的。但是在活跃上下文那里,只说了the number of currently runnable kernel scheduling entities——看看清楚,这里可从没有说有D。脑子清楚的仔细想想就知道,D是不可调度的。

——问题是咱脑子不清不楚的就没想这差异,而且咱连man proc都没查。。。

另外顺便说一句,内核也告诉了我们一点东西——load计算的时候是连内核线程一起算的。

清楚这点差异后,问题的原因也很清楚了——肯定是哪里有很高的D。用ps -e Hl | grep -e R -e D扫了一下,再用wc -l做了一下统计。214个线程在D(或者R,或者只是不小心被grep到,但是实际上大部分都是D)。系统当前的loadavg正好长这样:

214.12 156.63 82.25 7/4629 10027

7个执行中线程(R),207个uninterruptible。

——所有的谜都解开了。

by shell909090 at June 03, 2014 06:43 AM

May 28, 2014

@delphij

Google Compute Engine

初步尝试了一下 Google Compute Engine(G社类似 Amazon EC2的产品,基于 Linux/KVM)。确认 FreeBSD 可用(在家里用qemu建一个image出来,装好,然后打包扔到 Google 的系统上,然后用这个包建一个image,再用image起个instance)。

几个比较显著的坑:

  • Google Cloud SDK假定bash位于/bin/bash。这个很容易patch。
  • 如果是在远程的 FreeBSD 系统上使用 Google Cloud SDK,它默认会起 links 作为浏览器。由于 links 不支持 JavaScript,因此会导致 Google Cloud API 授权失败。解决方法是关闭浏览器,然后通过 X forwarding 起一个 Chromium (我估计 Firefox 也没问题)来操作。
  • GCE的系统只支持GNU tar格式的文件,使用 FreeBSD 的 bsdtar 时必须指定用 gnutar 格式,或者用 GNU tar(bsdtar默认采用的是 pax interchange 格式,而 libarchive 目前并不支持 GNU tar 的 sparse 模式;具有讽刺意义的是 Tim 其实应该是在 Google? xz 支持未测,我觉得以只支持 GNU tar 的劲头应该是不支持 xz 的)。
  • 预设的防火墙规则基本只允许 ssh。
  • 系统内建 禁止任何发到标准SMTP端口 (25, 465, 587)的请求。可以理解禁止25,但是不太理解禁止465和587,意义何在?是为了推广 SendGrid 吗?
  • 初始的qemu镜像文件必须是10240MB。
  • 上传 qemu 打包之后,建立 image 后其实可以直接删除原包。

存到盘上的数据据说是加密的,不过个人认为扔到 Internet 上的数据基本就没有隐私可言了,有加密自然可以阻止一些泄密(例如如果一家创业公司想要保存一些患者信息,那么在 Google 本身不被黑掉且他们遵守一系列安全设计准则的前提下,他们至少不用担心由于硬盘坏掉,替换硬盘时这些数据被第三方厂商偶然得到),但基本上跟家里的门窗结实程度一样,你懂的。

实际测试,虚拟网络至少可以做到 100Mbps 跑满(对 Internet)。我认为对大部分普通应用而言应该是够用了。比较遗憾的是本地读写性能忘记测试了,等有时间再研究一下(看 这里 估计太快不了;可靠性方面,据说有内建冗余和校验和检查,不知道实际情况如何,个人感觉可靠性应该还不错)。

现在有个比较邪恶的想法是跑个定制的 FreeBSD 系统:以 64-bit FreeBSD 为主体,大部分系统工具替换为 32-bit 的,削去不必要的元件如 APM、电源管理、无线等等,同时安装 64-bit 和 32-bit 的库。这样的好处有:1) 可以充分利用内存和 long mode 的一些优势; 2) 大部分应用程序并不真的需要使用 2GB 以上内存(除非出了问题),跑 32-bit 的版本作为副作用恰好可以阻止它们疯长(一旦发生这种情况直接就被内核干掉了),而另一个副作用则是 32-bit 的代码本身比较小,因而可以节省内存和磁盘空间从而降低使用成本; 3) 64-bit FreeBSD 上的 32-bit 兼容库是采用最新 CPU 指令集编译的,而直接安装的 32-bit 版本 FreeBSD 则不具备这一特性。

by Xin LI at May 28, 2014 08:20 AM

May 25, 2014

@shell909090

台北地铁砍人事件

哪里都有疯子

其实并没有疯,只是不论理由,就是要杀人而已——就是所谓的反社会人格。理论上心理咨询是可以发现的。但是台湾的经验告诉我们——目前的心理咨询密度不足,敏感度不足。而要维持足够的敏感度,不仅费用成问题,而且还会有很多啼笑皆非的情况。

社会压力?北欧够没压力了吧。2011年挪威发生爆炸和枪击。

废除死刑?

我不赞成废除死刑。当然,这和捷运杀人案本身并没有什么关系。他杀人的时候就知道自己会被判死刑。人不畏死,奈何以死惧之,死刑对凶手是没什么阻止力的。所以废除死刑还是保留死刑,都不能阻止凶案的发生。

但是死刑还是能阻止一些东西的。例如本次事件,死者中有两位20出头的年轻人。如果没有死刑,他们的父母会不会试着杀了凶手呢?反正活着也没什么意思,而且很讽刺的——我们也不能判这些人死刑。更进一步的,每次杀人案,我们需要严密保护的想必不是受害人,而是加害人——因为加害人不能死。而我们的法律为了保护加害人而存在,受害人遗族如果心理难以平复,只有自己动手,同时把自己变成受法律保护的人——就是加害人——才行。这样的逻辑不荒谬么?

死刑这事原本就没什么意思——我们已经遭到了损失,却还要用杀人来扩大损失。从这个意义来说,如果真是很久都没有恶性事件了——例如2011年挪威枪击和爆炸事件那样。这样的情况下,要不要废除死刑还真的可以商量。只是真的如此,我们应当判处什么人的死刑呢?长着野百合的绞刑架大概会成为城市最美丽的徽章。

死刑的意义在于,在无法无天的地方,我们有一种廉价的方法,可以永远的不用看到这个人。

和太阳花连结

咳,要认真论关系,马总统和杀人犯的关系绝对比太阳花近——这人的衣食住行,哪个不是受到政府政策的影响?是为期一个月的太阳花运动,还是持续执政数年的政府,更有可能造就一个杀手?两者哪个和凶犯的联系更多?持太阳花论的人认真想过这个问题么?

还有。包围行政院的年轻人去哪了?大概正在被各种凶案发生时的警察逮捕吧——你不觉得换个说法”凶案发生时,警察去哪了?“,这个质疑也能成立么?而且大部分凶案发生时都看不到警察啊,明明总统府门口一大堆的说。

也不要以为持这种论点的人是傻瓜。你讨论了这个问题,哪怕是否定,也达到了他们的目地——没有关系也是一种关系啊。我们不断讨论,有没有关系,有没有关系。不断得出结论,没有关系,没有关系——届时只要轻轻反问一句,真没有关系为何要讨论这么久,有人讨论过西瓜和美国国旗的关系么?没人讨论,是因为真的真的,一点点关系都想不到啊。

从这个角度来说,这种问题居然还需要讨论本身就很反常,你我都是网里的一个飞虫而已。

玩游戏和杀人的关系

比”吃饭和杀人的关系“近,比”没有女朋友和杀人的关系“远。从这个意义上说——难道政府要强制所有人谈恋爱?

by shell909090 at May 25, 2014 03:12 AM

May 21, 2014

@delphij

精生大法讨论:信用卡的 Balance Transfer

大通银行最近经常发一些其信用卡的 balance transfer 的活动。这种 offer 的特点是提供两张支票(一般来说有效期在2个月左右),通常提供18个月的免息期。

由于这种 offer 要收 2% 或 $5(以两者中较高者为准),所以我之前基本是直接碎掉的。今天和一位同学讨论了一下,发现似乎不是完全不存在合理价值,当然这次这份我还是要碎掉,但先把这个观点记下来,等以后有机会再做评估。

想要充分利用这种 offer,需要满足下面全部条件:

  1. 能够在18个月之内完全不使用这张信用卡。(使用条款规定,尽管 Balance Transfer 本身是18个月内 0% APR,算上 2% 的手续费不妨看做收 2 个点预付利息的小额贷款,也就是大约 1% APR,但此后新买的产品是按标准利率收取利息的。后者的利率通常在十几到二十几个百分点)。
    假如能封存这张卡18个月不用,好,这是一个 1% APR 的小额贷款,接着:
  2. 使用这些钱足以在18个月内产生至少2个点的税后收益。可能有同学说好,我去买 SPY,或者另类投资如 Lending Club,确实可以,但是这收益是没有保障的,而如果无法持有超过 1 年,又有可能按照短期资本利得来缴税,导致收益减少。
    购买能够免税的本州内城市债券基金可能可以。

我个人认为意义不太大:现金流不足的时候似乎应该采取更稳健的投资策略而不是继续举债?而如果现金流充足的话,为什么要举债投资呢?(毕竟信用卡的额度通常不会让一个人的现金流增加数倍,吧?)但是假如有很可靠的高收益投资机会,似乎并不是太坏的选择,只是在充分竞争的市场中出现这种投资机会应该不太常见就是了。

by Xin LI at May 21, 2014 05:41 PM

May 19, 2014

@delphij

Intel RDSEED指令

今天看到 John Baldwin commit 的这个 r266391 增加了相关支持。

RDSEED 和 RDRAND 的区别是 RDRAND 采用的是 128-bit AES 密钥的 CTR-DRBG,而 RDSEED 则是直接从真随机数发生器中获得输出(两者并不是直接使用真随机发生器的输出,这些输出是做过 AES-CBC-MAC 处理的,防止外界通过观测输出了解内部运行的细节),较慢,后者具备 multiplicative prediction resistance 特性。

具体细节可以参考 Intel® Digital Random Number Generator (DRNG) Software Implementation GuideThe Difference Between RDRAND and RDSEED

Intel 的后一份文档中建议实现 PRNG 时使用 RDSEED,不太清楚这样做是否会同时复位 RDRAND 的状态?假如不复位的话,这样做似乎也意义不太大?(PRNG 的实现者应该从更多的地方收集 entropy 而不是假定真随机发生器的输出可信)。

此外, DRNG 用的 AES-CBC-MAC 这个事情,我认为是一把双刃剑(虽然用比不用要好),因为这样一来便很难验证来自硬件的随机数是否具有某些特性了(此外我找到的文档也没有具体描述如何 AES-CBC-MAC 是如何使用的)。

by Xin LI at May 19, 2014 05:20 AM

May 17, 2014

@delphij

OpenZFS Developer Summit

今天去 San Francisco 的 Delphix 参加了 OpenZFS Developer Summit,今天这会太充实了,先记一笔。

ZFS Channel Program:目前的 ZFS 应用程序需要以多次系统调用来完成一项功能。为了实现原子性,用户态部分实现起来比较复杂,而且最终内核中的 sync task 可能会导致长时间的延迟。提出的解决方案是在 ZFS 内核部分引入一个 Lua 字节码解释器,用户态一次灌一个脚本进去,通过脚本逻辑实现原子性,从而减少上下文切换开销并极大地简化用户态部分。

分层的 ZFS 存储:希望将 ZFS 改造为能够适应冷热存储的结构,这样可以将冷数据部分固定下来之后脱机(例如置于待机状态),从而节省能源开销。(Nexenta)

对于 spacemap/metaslab 的改良:Delphix 通过 DTrace 观察发现了一系列性能瓶颈并进行优化的实例。这个已经在 Illumos 里了,今天主要是趁热讲解一下所做的改进。比如写带宽限制从原始的限时、限量、加延迟变成了按系统中未回写数据比例作为限制条件、当 I/O 持续到来时自动切换到吞吐量优先(多排任务)的模式、写入速度减慢时减缓接受写请求等的新一代写带宽控制,使得 ZFS 的写入延迟得到了极大的改善。Adam Leventhal (这位老大也是 RAID-Z2/Z3 以及 ZFS gzip 压缩支持的作者)分享了采用的方法、评估手段等等。

明天的活动是 Hackthon,又要起个大早。

by Xin LI at May 17, 2014 01:52 AM

May 08, 2014

@shell909090

goproxy和msocks简介

goproxy是我个人写的,和shadowsocks同类的软件。当然,在设计之初我完全不知道shadowsocks的存在,goproxy的最初目标也不是成为shadowsocks的同类。只是我一直无法实现一个可靠的,能够达成目标的系统。最后想,那这样吧,我找一个跳一跳能够够到的苹果。大幅简化的结果就是goproxy——后来我才知道shadowsocks。

shadowsocks的基本原理

shadowsocks的基本概念,就是利用某种不同于SSL的协议,将本地的socks数据流转发到远程。这个协议,在默认版本中是一个凯撒变换,后来有了aes等加密算法。goproxy也采用了类似的做法,同样支持aes等加密算法。在每次连接时,客户端先用加密通道连接服务器端,然后完成整个连接通路。这样的设计鲁棒性相当好,但是作为代价的,也有不少缺陷。

首先,goproxy和shadowsocks不约而同的采用了自己的协议,而非将socks5透明的转发到远程的服务器端。为什么?因为socksv5协议中,握手过程是三次交互。客户发送握手包,服务器响应允许的握手验证方法。客户发送验证报文,服务器端返回是否成功,客户发送要连接的目标,服务器端返回是否成功。细节我记得不是很清楚,但是2-3次往返是必须的。

这种工作机制需要client -> proxy-client -> proxy-server -> server的一个链条,本身就比直连多了两次TCP握手。加上上述的往返过程,更加耗时。而且这个消耗在每次建立链接时都要来一次,而HTTP是一种短连接协议——这就更加无法容忍了。因此改用自有协议,一次交互完成握手,就会更加快速。

更根本的原因在于,这两个系统都需要越过IDS,而三次交互的报文大小是几乎固定的——就算加密也无法改变报文大小。不但大小一样,而且由于用户名密码相同,起始加密过程和IV一致,因此采用socks协议的话,每个链接开始都有相同的来返数据。

我不知道shadowsocks怎么处理的这个问题。qsocks协议(msocks)的前身规定,每次握手时客户端提供一组IV,然后发送一个头部变长的字符串(256字符以内),在远程丢弃同样长度的随机字符。经过这样的处理,每次链接时的报文长度和内容序列都不一样,增加了破译难度。至于多出来的几十个字节,和验证报文在一个报文内,开销相比一次RTO几乎可以忽略不计。

但是还是有一点无法避免的问题。如果你看到某个服务器上有一个端口,频繁的被一个或多个IP链接。每个链接都不长,每次都是客户端吐一堆数据,服务器返回一堆,然后关闭链接。尽管协议无法破解,但是基本可以肯定这就是shadowsocks。根据这个特性,可以有效的阻挡服务——这也是我最近碰到的问题。

而且每个链接都需要验证和TCP握手太慢了。

msocks的改进

所以,我参考SPDY协议,做了msocks。msocks的核心思路和qsocks很类似,主要修改是以下两点:

  1. 使用一个可靠链接(这里是经过加密的TCP),在这个链接里面封装多对传输。
  2. 每个链接只要一次验证。

这样做,首先减少了一次TCP握手和一次身份验证,工作速度更加快。其次多个传输叠加在一个流里面,流特征更加变化莫测。最后,无论是服务器端还是客户端的开销都小了很多。

当然,这也带来不少问题。例如TCP原本的拥塞控制窗口是为了一对传输序列设计的。当很多传输序列在一对TCP上传递的时候,丢报文造成的影响会作用作用在全体传输序列上。包括丢了一个报文重传的时候,所有序列都必须阻塞。还有基础的TCP被施加了丢包,导致全体序列共享5k带宽。当然,经过评估后,我觉得这些问题比频繁握手更加轻,所以就设计了msocks协议。

协议设计的时候,有几个细节问题。

多对复用

我采用了一个map,来记录某个id是否对应到了一个控制结构。这个映射只能被客户端更改,并且有个专门的函数负责查找空闲的id,每次生成的id都是递增的,如果碰到最大值则绕回。

id的大小是16位,足够容纳65536对同时链接。其实不修改内核的话,500对代理就会导致too many files。

实际上一般到id达到400后,单一的tcp就断线重连了。目前我还没见过上千的数字呢。

连接状态

连接一般情况下可以看到5种状态,连接请求发送,连接请求接收,连接建立,主动关闭连接中,被动关闭连接中。

当客户端请求代理连接一个远程服务器时,进入连接请求发送。代理远程端接受后在连接目标服务器的过程中,进入连接请求接收。当成功后,双方进入连接建立。

当关闭时,主动发起关闭一端进入主动关闭,另一端进入被动关闭。当被动关闭端调用close,或者主动关闭端收到对方关闭,整个链接就销毁。

由于tcp是可靠传输,因此三次握手和四次关闭都是不必须的。

简单吧。

拥塞控制

TCP原本是带有拥塞控制的——借助SSN双序列和窗口机制。但是在多路复用的时候,我们需要自行控制拥塞——而且不能采用会和机制。会和会导致后续已经到达的其他链接的报文被一个没人接收的报文阻挡。所以必须采用带拥塞控制的缓存队列机制。

不过幸好,TCP本身是可靠传输协议,所以我不用担心丢包重发之类的问题。我需要做的,就是把对方读取的字节数传递回来,减在控制器上,即可。

不过,我没有做对应于silly window syndrome的优化,在每次读取小数据量后,这个读取造成的window扩张都会被传回。当然,这么设计是有原因的。我默认采用了8K的buffer进行fd间拷贝,所以一般碰不到SWS。

为了解决tcp链接复用造成的单连接带宽问题,我强烈的建议你做以下的设定:

net.ipv4.tcp_congestion_control = htcp
net.core.rmem_default = 2621440
net.core.rmem_max = 16777216
net.core.wmem_default = 655360
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096    2621440 16777216
net.ipv4.tcp_wmem = 4096    655360  16777216

ip选择算法和DNS

在goproxy中,我沿用了一个做法。通过DNS获得请求的目标IP,和中国IP范围核对。如果在国内则直接访问,否则透过代理。这个方法能够极快的加速访问,而且几乎不依赖于需要更新的列表(中国IP列表相对来说固定)。

问题是DNS解析过程。msocks内置了DNS能力,可以帮助做DNS。但是实践下来发现这样做效果并不很好。而原本是采用直接DNS,丢弃特定的报文。这样可以过滤防火墙污染。

原因很简单。原本的模式会让DNS服务器感知到查询者位于中国,于是给出中国可以访问的最快地址。而新的模式则会将DNS请求者搬到美国——这无故加重了代理的负担。例如www.qq.com,原本只需要请求得到一台深圳的服务器即可,现在则需要让DNS绕出去,再回来。如果不幸,QQ有一台位于美国的服务器,那么我的访问都会通过这台服务器——这可比深圳的服务器慢多了。

地址

抱歉刚刚忘记写地址了:

goproxy

debian/ubuntu安装包:amd64 i386

by shell909090 at May 08, 2014 08:41 AM

May 04, 2014

@delphij

记一笔关于iPad的DFU mode

由于送修 iPad 最终没有修好,因此店家给提供了一台二手的 iPad。作为不折腾就会死星人我觉得显然应该重刷一遍固件(卖家已经重新清空了数据),因此做了一次 DFU mode 固件更新。

具体做法是先把 iPad 接在 Macbook 上,同时按住 power 和 Home。等待大约10秒后屏幕變黑,此时按住 Home,等到 iTunes 上可以看到 Recovery 为止。

然后就是刷 iOS 和恢复数据了,此前过程中在网关听包未见明显异常。

by Xin LI at May 04, 2014 09:23 AM

April 23, 2014

@delphij

FreeBSD 10.0-RELEASE

这是我加入 FreeBSD Release Engineering Team (re@) 之后,我们发布的第一个主要(X.0)版本。

这个版本对整个系统进行了大量的改进。其中的重要变化包括在基本系统中用 clang 取代了 gcc(所有 Tier-1平台)、新增了 unbound(用于取代BIND的部分功能,后者十分复杂,且支持计划经常与 FreeBSD 的发生冲突)、基本系统中提供了转码API iconv(3) (我在2010年指导的 Summer of Code项目)、使用了 PkgNG 包管理工具、BHyVe虚拟机、对于虚拟化支持的大幅改进(virtio(4)以及 Hyper-V支持)、ZFS新增了TRIM支持、ZFS的LZ4完整支持(我在去年新增的功能),等等。

这个版本的发布工程过程将发布日期推迟了总共三次(从2013年11月18日推迟到了2014年1月15日,大约两个月的时间)。我认为有很多需要改进和汲取经验教训的地方。总结如下:

  • 对 KBI 冻结的时间沟通不足:X.0版本涉及 KBI/KPI 冻结,而初期 re@ 对此宣导不够。由此导致后期必须进行某些修改,而 KPI/KBI 冻结的事项实际并未严格实施。
  • 对于测试重点等事项的跟踪需要进行改进:初期测试主要是依赖 re@ 的测试,许多影响比较大的方面未能覆盖到。

由于这些问题,导致在 BETA2 之后增加了两个新的 BETA。RC1之后,开发节奏基本是按照计划进行的,但由于意外情况必须增加RC4(一个非常严重的 VM bug)。而此后又发现了一个 10.x 新引入的安全问题,因此不得不发布 RC5 以便对修正进行更充分的测试。这些延期导致的一项(我认为是好的)副作用是,原定 10.0-RELEASE 之后两周左右发布的一批安全公告的修正内容也在 10.0-RELEASE 之前得到修正和公布。

注意(此处大坑):由于之前 freebsd-update 的 bug (EN-13:04EN-13:05),在更新之前的版本可能无法直接通过二进制方式升级到 FreeBSD 10.0-RELEASE。这些版本的 FreeBSD 应首先用 freebsd-update 升级到 9.2-RELEASE-p2、 9.1-RELEASE-p9、 8.4-RELEASE-p6、 8.3-RELEASE-p13 或更高版本之后再使用 freebsd-update 进行升级。

by Xin LI at April 23, 2014 11:30 PM

April 19, 2014

@delphij

Heartbleed之危机公关处理

这次 Heartbleed 安全漏洞之后,阿里巴巴集团的多个产品均迅速修复了漏洞(好事),但事后的公关处理做的却有待改进。

我在微博上看到有人转发 阿里安全 在4月9日13:01发表的一篇微博,内容如下:

关于OpenSSL某些版本存在基于基础协议的通用漏洞,阿里各网站已经在第一时间进行了修复处理,目前已经处理完毕,包括淘宝、天猫、支付宝等各大网站都确认可以放心使用。

紧接着, 支付宝 转发了 这条微博:

大家可以放心了!

我并不是阿里巴巴/支付宝的客户,不过看到有人转发这条消息,我半开玩笑地 回了一句:

冲这句"大家可以放心了"就没法放心了......

有疑似工作人员的同学在我这条微博下面发表了评论,并指出真实情况可能会吓到用户。但坦率地说,我还是认为这样的公关做法是不对的,公众在发生这类重大安全问题的时候,了解全部事实有助于消除他们的恐惧心理。

我为什么说冲这句"大家可以放心了"就没法放心了呢?原因很简单,一句简单的"大家可以放心了"给我的第一印象是相关的工作人员并没有向公司的公关部门交代清楚到底发生了什么,以及它的影响是什么:给服务器运行的软件升级只是万里长征的第一步而已,而假如公关部门认为这件事只要升级之后就可以忽略全部其他问题的影响,并且向公众如此宣示,那么公众很可能就不会再继续关注这起事件,而忽略了必要的自我保护的措施。

这种忽视对于用户和支付宝都是不利的。在用户方面,由于缺乏必要的保护措施,很可能导致不必要的损失,而由于这种损失并不完全是用户的问题,用户很可能进一步向支付宝求偿。假如发生这种情况,除了双方会有经济损失之外,也会对支付宝产品的声誉以及用户信心发生影响。

我认为PR部门应该根据初步的评估做出:"我们的系统未受影响。""我们的系统受影响,但问题已经修复,我们将会通知所有受影响的用户。"这样的的宣布。具体到 Heartbleed 这个问题上,仅仅修补软件漏洞是远远不够的,由于攻击者有可能已经窃取了证书的私钥(透过简单的如架设假基站、开放wifi热点,或较为复杂的、配合DNS投毒的攻击手段,攻击者可以架设和真正网站一模一样的网站而不被用户发现),因此作为补救措施,网站的运营者只有在先修补了软件问题,并更换了所有证书并撤销旧证书(这是很容易忽略的一步)之后,才可以认为问题已经完成了"修复处理"。

在用户方面,则需要对自己所受的影响做出一定的评估。例如,网站运营者至少应根据运营日志给出一个大致的时间点:某年月日(升级到受影响的 OpenSSL 1.0.1)到某年月日(完成修复处理)之间登录的用户,其信息存在失窃之虞。由于这本质上是一个缓冲区过读问题,攻击者可以完美地伪装请求(没有有效的方法知道攻击者在什么时候进行了攻击:系统日志中不会记录什么时候收到了来自谁的心跳信号;即使知道,也没有有效的方法知道到底哪些内存内容遭到了泄密),除了根据运营日志的记录来查询用户的登录日志之外,事实上没有很好的办法知道哪些用户受到了影响。对于一个安全性非常重要的网站而言,此时最稳妥的做法就是首先假定所有用户都受到了影响,然后尽量找到那些一定没有受到影响的用户,然后通知两者的差集。

作为电子商务网站,由于用户在使用过程中可能会输入信用卡号,因此这些信用卡号也同样有泄露的风险。网站方面可以做的事情不多,但应在用户登录后明确告知用户哪些信用卡信息有可能发生泄露,应关注账单异常等等。

当然,我没有支付宝账户,而且即使在平时我也有经常改密码和查看信用卡对帐单的习惯,因此我确实是可以放心的。

by Xin LI at April 19, 2014 12:31 AM

April 18, 2014

@delphij

OpenBSD fork 了 OpenSSL

OpenBSD [捐款链接] 又一次出手为民除害了! Undeadly报道: OpenBSD has started a massive strip-down and cleanup of OpenSSL

这次 Heartbleed 的事情搞的我十分不爽,这事固然不能全怪 OpenSSL 的开发者,但是整个过程非常的让人不舒服,具体的就不多说了。等过个几十年再回头看看这次这件事情再说吧。

OpenBSD 目前对 OpenSSL fork 的改进主要包括:

  • 修正了一处释放后还在使用内存的问题
  • 清理了一系列在 OpenBSD 上不需要的垃圾代码
  • 删除了绝大多数后端引擎(VIA padlock、Intel AES-NI支持除外)
  • 去掉了一系列用于移植的函数封装。
  • 使用了易读的 KNF (BSD的代码风格)取代坑爹+反人类的 GNU C 风格
  • 去掉了可能弱化随机数的代码
  • 砍掉了 Heartbeat 功能作者所写的全部代码

我个人非常希望 OpenBSD 的 fork 能够成功,那样的话我们就可以在几年以后(已经发布的版本还需要继续支持一段时间)彻底从 FreeBSD 基本系统中砍掉 OpenSSL 了。

by Xin LI at April 18, 2014 07:25 PM

April 12, 2014

@delphij

基于Asrock C2750D4I的全加密存储

去年第四季度的时候,在网上看到 华擎科技 推出了一款基于 Intel Atom C2750 SoC 的主板, Asrock C2750D4I,感觉很赞,于是立即和华擎科技取得了联系(当时这款主板还没进入量产),并着手开始了测试等工作。这张主板的重要特色包括:

  • mini-iTX尺寸
  • CPU支持Intel AES-NI,加密加速
  • 提供了两个千兆以太网口
  • 支持ECC内存(更重要的是,采用的是台式机和服务器常见的4x240-pin DDR3 DIMM规格,不像同类产品通常使用的是204-pin的SO-DIMM,这一点可以节省很多成本)
  • 提供了8个SATA III 6.0Gbps接口和4个SATA II 3.0Gbps接口
  • 支持IPMI并提供了独立网口

此处强行插入一条广告: 我厂 目前这一代的 FreeNAS Mini 采用了这张主板,组装好的产品可以通过 Amazon 购买,我厂每年都会将一部分利润捐给 FreeBSD 基金会,如果先 在 smile.amazon.com 注册支持 FreeBSD 基金会,并使用前述链接, Amazon 公司还会再捐出 0.5% 的金额给 FreeBSD 基金会

目前这张主板已经进入了量产阶段,因此也可以从其他零售渠道获得相关组件自行组装。

我厂的出厂配置中,整套系统包括了一个容量为 16GB、预装了最新版 FreeNAS 的 SATA DOM。目前新版的 FreeNAS 已经支持全盘加密,通过其 Web 界面即可完成配置(参见 FreeNAS 手册中关于如何创建加密卷的介绍)。

作为不折腾就会死星人,以及强烈的迫害妄想症患者 为了进一步完善 FreeBSD 对于全盘加密的支持以及为下一代 FreeNAS 版本尝试其他一些选择,我并没有直接使用 FreeNAS,而是改装成了一套我自己补过的 FreeBSD 版本。此外,在对磁盘初始化的过程中也进行了一些调整。

具体来说,在使用全盘加密之前,应首先对裸盘做一次初始化(在其上写满随机数)。写随机数的目的是在磁盘被人物理地拿到的时候,对方在没有密钥的情况下将无法知道某个具体的扇区是否存在加密数据。FreeBSD 的 geli(4) 手册上建议在 GELI provider 上写随机数,但是由于我们并不使用 GELI 的 checksum 能力,因此实际上直接在裸盘上写随机数就可以了。

FreeNAS 目前版本的做法是用 dd 在裸盘上写 /dev/random 的数据。这样做本身并没有太大的问题,但是很慢,根据我的计算,4块4TB (WD Red)的硬盘完成初始化需要将近两天的时间。显然,花些时间改进初始化流程是十分必要的,于是我对 libc 中的 arc4random(3) 进行了一些改进,然后写了一个简单的多线程 producer-consumer 程序,这样第二天起床的时候初始化就完全做好了(具体代码将在稍后集成进 FreeNAS)。

目前 FreeBSD 提供了以磁盘序号作为标签的能力(/dev/diskid/*)。因此,直接在初始化后的磁盘上建立 GELI provider,这样当盘位变化时不致影响 GELI 的解密;此外,密钥直接放在一个USB盘上,在其上建立一个GPT分区(放上4KB随机数),这样在系统启动时插上,启动脚本检测到其存在即开始解密磁盘,之后将其拔下即可。保险起见,我做了两个USB盘分别保存用于解密 GELI 两个密钥槽中的两个不同的密钥。

由于民用硬盘的尺寸可能略有不同,因此我在 GELI provider 上也建立了 GPT 分区,并留出了最后大约1GB的空间作为缓冲,以备将来出现硬盘损坏时找不到更大的替换硬盘时使用。(使用最后部分作为缓冲区的原因是在初始化过程中发现靠后的部分性能较差)。

这个存储上采用的 ZFS 有一些尚未提交的改进,例如采用 LZ4 作为默认的元数据压缩算法,等等。此外,我采用了 sha256 而不是默认的 fletcher4 作为 checksum,虽然这样性能会稍微有些影响,但它可以改善send dedup的性能,由于这台机器只有两个千兆口,因此 CPU 也不致成为性能瓶颈。

by Xin LI at April 12, 2014 02:35 PM

April 08, 2014

@khsing

招聘: 新浪招聘DevOps

职位:运维开发工程师 (需求2~3人)

工作地点:北京,中关村地区

  • 工作职责

    1. 分析日志和监控数据指标,发现和定位问题
    2. 对系统故障进行长期的跟踪分析
  • 任职要求:

    1. 有3年以上Linux运维经验;
    2. 精通Linux/UNIX等操作系统,有3年以上Linux平台操作经验; 熟悉Shell编程,熟悉Python或Ruby者优先;
    3. 熟悉服务器监控软件,有较强的分析能力;
    4. 熟悉rsyslog, scribe, flume等日志收集和处理系统;
    5. 熟悉Nginx、Apache、Haproxy、LVS等软件日常操作和优化
    6. 学习能力强,能快速了解掌握新技术
  • 优先条件:

    1. 熟悉Elasticsearch、Logstash者优先

有意者请联系我,邮箱:khsing.cn@gmail.com, 来信注明应聘职位,附上简历一份。

by Guixing at April 08, 2014 11:11 AM

@shell909090

CVE-2014-0160(openssl)严重漏洞及其对应

描述

openssl 1.0.1系列中,1.0.1f以前的版本在实现上存在漏洞,未正确处理Heartbeat扩展,导致攻击者可以窃取服务器端敏感数据。

对应

  1. 请立刻升级openssl到1.0.1g版以上,并重启整个系统,以保证不会遗漏某些已经启动的进程。
  2. 如果有自行编译的程序使用了openssl。当这些程序静态链接或链接了自定义的openssl时,需要重新编译。
  3. 在有问题的设备上使用过的key,需要升级私钥。
  4. openssh不受影响,openvpn受影响。

作为证明,请执行以下语句自行检查。

ldd /usr/sbin/sshd | grep ssl
ldd /usr/sbin/openvpn | grep ssl
ldd /usr/sbin/nginx | grep ssl

for i in $(ps aux | awk '{print $2}'); do echo $i; ldd /proc/$i/exe | grep ssl; done

其他

根据昨晚看到的信息,这个漏洞会泄漏服务器端的通讯数据。因此请将所有session清空,在受影响期间使用过的用户名和密码请务必在3-5天后再修改一次(具体看服务商什么时候补掉漏洞)。

参考

  1. nvd
  2. debian
  3. ubuntu
  4. openssl
  5. Is OpenSSH affected by this as well?

by shell909090 at April 08, 2014 10:03 AM

March 25, 2014

@shell909090

安全的几点快速说明

这篇文章谨献给某些特殊环境下奋斗的人士。其他人参考使用。

物理设备

物理设备上存储着相当多的个人资讯,所以所有的机密资讯要保密这是常识。

物理设备上可能拥有的机密资料:

  • 各大站点的session token。借助这些,虽然不能抢走帐号,但是可以仿冒身份,发出假消息,或者诈骗。
  • 浏览器启用了“保存密码”选项后,所有的密码都半明文存储在硬盘上。这些信息可以被用来抢走帐号。
  • 个人的文档,照片,私密视频。万一笔电丢失就够倒霉了,再变陈老师岂不更痛苦?
  • 浏览某些特别站点的记录。咳咳,大家懂。

之所以要设备加密,是因为有一种破解方法是将你的设备存储拆下来,接到独立的读写设备上,直接读取数据。无论系统密码设定多强,也无法防范。

如果是mac,有一个选项叫做全盘加密。ubuntu有home分区加密的选项。启用这两项可以有效加密你的电脑。windows也有个类似的功能叫做EFS,但是据说不少国家级单位有解密权限。

android上有加密系统的选项。但是要注意,如果启用会消耗大量电力,而且必须擦除整个设备才能解除。iphone我没用过,据一位挺熟悉的朋友说,只要设定了pin码,整个手机就会被加密。

加密只是第一步。对于经常保持开机的系统,如果能够轻易的进入系统,那么磁盘加密也形同虚设。所以,请给你的系统加上一个足够强的登录密码。

最低强度:

磁盘加密8位以上,系统登录6位以上,包含小写和数字。

推荐强度:

磁盘加密10位以上,系统登录8位以上,包含大小写和数字。

网络安全

首先,请把系统的防火墙开到最大:

基本原则是,只许出不许进。如果需要可以开放特定端口。

然后,如果在不安全的环境下使用网络,请使用vpn。这里请允许我广告一把朋友的网站云梯。一般是用来大陆翻墙的,不过要用来绕过不安全的环境也可以。

有时间有条件的朋友可以自行架设vpn服务器,这里给出linux下架设pptp vpn的方法。客户端使用方法可以参考云梯的说明。

注意加密一定要使用128位,不要使用56位。

网站访问

如果可以选择,尽量使用https。下面有一些插件,使你可以尽可能的使用https访问站点。当然,如果站点没有https则无效。

在https访问的时候,如果跳出证书是伪造的之类的警告,请千万不要确定。这是有人在man-in-middle的信号。正确的做法是使用vpn,看看问题是否消失。如果消失,上报给工程师。如果没有消失,请找可信的工程师来排查。千万不要轻易认可未经鉴定的证书(实际上不建议自行接受任何证书——除非那是你自己配出来的)。

另外,请关注证书的签署者。在我这里看到的信息如下:

  • google的证书签署者是GeoTrust
  • facebook的签署者是VeriSign
  • twitter的签署者是VeriSign

如果签署者有异,请上报工程师。这可能是有人获得了某个根证书机构的密钥来做的签署(例如CNNIC之类)。原则上这样的man-in-middle可以攻击任何网站。

by shell909090 at March 25, 2014 09:14 AM

March 23, 2014

@shell909090

携程网信用卡泄密问题

事情经过

2014年3月22日晚上6点多,乌云平台报告了携程平台支付日志泄漏问题,然后信息快速传播。晚上八点左右我就得到消息。

从描述中大致来看,应当是支付过程的各种信息都被打到了日志里面,然后日志泄漏了。

第二天,携程发表声明。简单归纳就是几点:

  1. 漏洞系调试所致。
  2. 受影响的用户为21-22日的用户,统计仅93人。
  3. 因漏洞引起损失,携程将全额赔付。

个人认为,携程的声明基本就是在推卸责任。

过程还原

漏洞细节虽然没有暴露,但是从透露出来的信息仍然可以拼凑出部分过程。

  1. 某个时间开始,携程的某个内部人员打开了线上系统的日志,用来做调试。不幸的是,日志里面包含了信用卡所有刷卡信息,而且日志可以被穷举下载。这个人是谁,什么时间开始,不知道。
  2. 22日,漏洞发现者(猪猪侠)发现了这个问题,并报告在了乌云上。
  3. 携程收到信息后,立刻关闭了调试模式。并且把系统日志拉出来看看,发现里面有一些人。于是携程就发表声明。

问题分析

在整个过程中,暴露出几个问题:

  1. 携程未必是故意记录CVV信息。但是根据携程可以让用户仅提供卡号后四位就可以完成刷卡来看,携程一定是记录某些信息的,但是未受到本次漏洞影响。
  2. 交易过程所交流的数据属于机密,到底是什么人有权限打开调试日志,又没有经过严格的访问控制?是主管级以上?还是普通员工?无论哪个级别都是严重的问题。如果是普通员工,说明携程对员工的管理不到位,权限分割控制不合理。任何恶意员工可以打开日志得到数据而主管无法察觉。如果是主管以上级别则更加糟糕。说明主管根本不懂技术,也不知道如何保护客户的安全。
  3. 时间是否仅限于21-22日?如果是的话,意味着仅仅2天就被攻击者找到了漏洞。如果是偶然的话也太快了,如果是必然的话,则代表携程内部其实还有其他问题。
  4. 两天的交易仅仅是93人?没有更多?为什么只是部分用户受影响?携程并没有披露更多细节。要么是这里仍旧隐藏着漏洞,要么是携程的危机公关不到家。

评论

为什么说携程的声明是推卸责任?

  1. 首先,对于受到影响的用户,只要能证明是携程的责任,无论携程是否发布声明,都可以打官司获得赔偿。携程的声明仅仅是表达了他必然受到的法律后果。如同驾驶员发表声明:“我喝醉后所撞伤的所有人,我将全额赔付其医疗费”一样,没有任何意义。而如果无法证明是携程的责任,携程当然不会管你。
  2. 携程是否隐瞒了更久以前服务器调试开启的事实?这并不好说。个人倾向于善意的揣测携程不会隐瞒,但是在行动上不妨恶意的揣测其实调试信息打开时间更长,受影响的人更多。
  3. 为什么只有93人受到影响,携程并没有公布。携程的事后分析,应当都是基于这个漏洞的特性“下载日志”而定的。其赔偿基线也是根据“下载日志就会有日志”而产生。但是是否有可能被擦脚印?或者内部人员打开日志然后关闭而逃过被抓?这些携程并不能回答。从问题分析2来看,这种可能并不能排除。而携程的声明并没有表示对这些情况负责(当然就算想要负责也无能为力)。
  4. 由于携程信息的不透明,其声明“只有93人受到影响,其他用户安全不受影响”,换个说法就是,“不接受任何赔偿请求,除非你们有足够证据”。问题是用户怎么可能有证据?证据都在携程的服务器上和拿到信息者手里。当有用户的信用卡被盗刷,如何确认是自己的责任还是携程的责任?

基于上述几点,我认为携程的声明是在推卸责任。

建议

如果你是93人之一,当然,携程应该已经联系你换卡了。

如果你不是93人之一,根据上文分析,携程是不会理你的。基于携程并没有透露更多的信息,也没有第三方机构佐证其说法的事实。你需要自行考量信用卡信息泄漏的风险。因此,我对所有在三年以内在携程使用过信用卡的所有用户的建议是,立刻用各种方法冻结信用卡或额度,并尽快换卡

我对所有人将来的建议是,远离携程直到其展现出对用户隐私和安全足够的尊重,或者关门。

PS,你可以用下面几种方法冻结信用卡:

  1. 打电话给发卡行,要求冻结。发卡行核对一些基本信息后就会帮你冻结。
  2. 使用网银将额度改为1元。根据网友反馈,建行的额度是千元为单位设定的,建议建行的用户们尽快弃卡。

信用卡的固有弱点

信用卡消费的几个要素是,卡号,CVV号,还有有效期。如果是线下消费,需要核对签名(理论上如此)。如果有设定密码,需要核对密码。

密码的问题是,如果设定了密码,一旦信用卡被盗刷,而密码一次正确,将被视为用户责任。而且很多发卡行的跨境消费是设定了密码但是没有密码也能成功的。因此信用卡的建议是不打开密码。

在网络使用中,这里有个很严重的不便——卡号,CVV,有效期,都是发行时即固定,不可更换。这导致一旦你将这些信息交给对方,你的安全就全由对方保护,发卡行无法帮你做任何事情。

正常来说,应当使用密码乃至在信用卡上附上电子token来加强安全性需求。这样的话,token信息无法保存,密码可以修改。当出现携程这类问题时(或者更普遍的,当碰到有恶意的商家时),可以通过修改密码来解决问题,不需要换卡。

一个小故事——我和携程打交到的经历,还有我为什么幸运的逃过一劫

我在某年,使用携程订机票的时候,对方业务员让我报出身份证号。我当时就一阵错愕——难道身份证号不是应当使用手机键盘输入么?

两者的区别在于,手机键盘输入,信息是直接输入到VI系统的电脑中,业务员只能看到尾号。而如果是业务员输入,那么他就有我的所有信息——从身份证号到信用卡号。也许我可以相信携程,但是我如何相信业务员?出了问题,我如何证明?

所以我就向携程的客户经理投诉了这个问题。具体经历在网络安全——你需要知道的东西里面已经描述了。这里面甚至我质疑了携程保存信用卡的安全性,几乎和今天的问题类似。

结果没多久,我打给携程的时候,丫的业务员和我说,如果你信不过我,咱们可以走这套系统。

我了个大去,这种系统还允许旁路绕过?那有个毛线的意义?

从此(12年年中吧)我再也没有用过携程的业务——用也是让公司同事帮我用。因此,当去年(13年某个时候)我的老卡到期,我就换用了新卡。新卡还没有在携程上用过。所以本次问题我一点事都没有。

by shell909090 at March 23, 2014 02:15 PM

March 21, 2014

@shell909090

台湾反服贸占领立法院中,网络干了点什么

短文,直接说吧。今天在facebook上看到,有帮台湾朋友组装了两台大功率的基台,把信号直接打到立法院里面。我在图片上看到了一堆天线,不少Cisco的设备,还有基台车。好像还有朋友拿着易拉罐和炒菜锅不知道是帮忙还是帮倒忙。

简单点说,基本架构就是外面架一个基台(推测使用5G频率),用定向天线和里面的client连通,出口用4G和基台车连接。然后里面的client走有线网和多个AP连接起来,每个AP分散部署,分享基台到client之间的链路。

目前看到的效果,信号已经打到立法院里面了。连警察人墙都可以用网——只是他们没有密码而已。

——结果今天早上发现立法院内其实有网,而且网速快过4G。所以又反过来架设——内部多个AP分享出去后,向外面打信号,外面又架设多个AP把信号分享给会场的上万人群。

上万?想想都要疯啊。

03-21T14:42: 根据看到的最新消息。3G和WiMax都爆满,而且整个立法院内信号密度过高。因此退回最原始的方案——拉一根超长网线解决。啊啊,这不是白折腾了么?

03-23T12:00: 在会场架网络的朋友,在google plus上分享了细节。细节在这里:

https://plus.google.com/+DAVIDLIFUHUANG/posts/WKP2qTDJypA

摘抄如下:

我來解釋一下我在立法院內部遇到的網路問題, 同時也說明這是我看到的問題, 或許 rex 有不一樣的見解, 那就再請 rex 另外闢文說明,

我剛開始進去的時候, 我原來以為 g0v 裡面有人, 不過實際上應該是我搞錯意思, 所以我就傻傻的進去了, 不過我個人是覺得, 我們應該要維持裡外訊息的暢通跟正確性, 所以我應該要做一點事情, 畢竟我只會弄網路, 所以我就真的去想辦法弄網路了 XD

  1. 人很多, 3G 全部癱瘓, 所以早就該換 LTE 了, 對吧 XD

  2. 3G 全部癱瘓, 所以大家都用 WIMAX, 這次 WIMAX 的表現還不錯, 讓我覺得以後來台北參加活動還是應該花點小錢租 WIMAX, 畢竟正確的訊息傳遞可以避免很多不必要的麻煩發生, 同時沒有人用的服務遇到人多的時候就是好服務, 因為它沒有人用, 但是目前沒有 5G 無線網路的 WIMAX 攜帶型無線網路熱點, 這是一個很嚴重的問題 XD

  3. WIMAX 多, 大家都開無線網路熱點來分享 WIMAX 的服務, 所以造成了無線網路封包的的碎片化

  4. 立法院本來就有無線網路系統, 在一個會議室裡面有一堆一樣的 ESSID, 同時又分散在不同的頻道上, 然後這些頻道上面又有很多一樣的 ESSID 但是分散在不同的 AP 上面, 這樣會發生什麼事情呢? 就是無線網路使用效率的降低, 因為沒有加密, 又是同樣的 ESSID, 也沒有做子網路的切割, 當無線網路用戶端大量增加的時候, 同樣的無線網路 ESSID 分散在不同頻道跟不同 AP 的狀態下, 廣播封包就亂竄, 無線網路頻道的使用效率就非常差, 因為封包破碎產生的重送率大大提昇

  5. 在 2.4G 的可用頻道少, 現場重複的 ESSID 又太多, 加上有限空間裡面又有大量的 WIMAX 熱點, 最後就導致無線網路可用性很低的問題, 在那個環境中, 你的無線網路可以用的狀況, 你在熱點半徑一公尺左右的範圍內, 如果超過這個範圍又發生直線路徑上面有阻礙物發生繞射的問題的話, 你的無線網路就變得很慢很慢

  6. 實際上發生的狀況就是我們在靠近青島東路 2F 的媒體席那邊放無線基地台, 但是我在議事廳前面的位置要用 x220 連線的時候, 會發生 ESSID 看得到, 但是當我點下連線按鈕的時候, 那個 ESSID 就不見了, 然後 windows 7 就告訴你, 我沒有辦法連接這個網路

  7. 最後的解決方式就是我們用一條很長的網路線, 從基地台直接拉到前面活動執行單位的位置, 讓訊息發布人在連接網路服務的時候使用以太網路連線, 這樣就可以避免無線網路密度太高產生的干擾問題

  8. 那要怎麼樣解決無線網路密度太高造成的干擾問題, 解決方式只有大量的小功率無線網路 AP 加上不重複的 ESSID 名稱跟子網路切割, 缺點是無線網路連線沒有辦法漫遊, 不過說真的, 我們現在也不建議一邊走路一邊滑手機, 如果有需要漫遊的服務, 再建立另外一個支援無線網路漫遊的 SSID 專門解決漫遊這件事情, 這樣我才覺得比較合理,

  9. 當沒有漫遊的狀態下, 你到同一個建築物的另外一個小空間的時候, 也就是再重新連接你可用的無線網路 ESSID 就好, 不過目前你看得到的無線網路服務都是以訊號的涵蓋率為考量, 所以就很難解決這樣的問題, 這需要時間, 就像從 AMPS, GSM, UMTS, LTE 這樣的過程一樣, 速度越來越快, 但是手機發射功率越來越小

  10. 無線服務設備的連接效果取決於訊號的距離跟功率, 還有同樣的頻道裡, 使用設備的數量, 當你要服務相當多的設備的時候, 功率要變小, 基站密度要拉高, 還要用不同的方向來提高可用頻道的重複率

  11. 我不敢說我說的是絕對, 但是我有實際上試著解決這樣的問題過, 所以應該還有一些可信度, 如果有任何問題歡迎下面留言討論, 如果有需要規劃服務的話也可以跟我連絡, 謝謝

by shell909090 at March 21, 2014 02:49 AM

March 19, 2014

@shell909090

台湾服贸协议问题

这篇东西是简单介绍台湾服贸问题的前世今生的文。其实我早就在关注这个问题,只是作为一个大陆人,这个问题很不合适。毕竟服贸这东西让台湾人很不爽。换言之,某种程度上我是获利一方。作为获利方还指手画脚说三道四未免有点“得了便宜还买乖”的嫌疑。不过近日,服贸问题已经从一个单纯的贸易协商变为政治问题。这里面很多东西非常值得我们学习。

什么是服贸协议

简单来说,就是大陆和台湾的贸易协定。从这个角度来说,这个东西不但没问题,而且必须。出问题的是内容和通过内容的方法。

台湾政府宣称服贸可以提振台湾经济,但是民众始终有疑虑:

  • 大陆人工(薪酬)比台湾便宜,加大开放是否会影响就业
  • 开放不对等,台湾太多领域对大陆开放,而大陆很多领域不对台开放,其中甚至包括影响国家安全的重要领域(例如通讯和传媒)
  • 大陆食品安全问题,台湾的检验检疫是否能保持独立性

老实说,从大陆人眼光看,很多问题颇有点——不知道怎么说的味道。台湾食品安全问题也不轻,而且从就业工资来看,台湾平均起薪大概和上海持平。随着工作年限上涨,反而是上海这里工资更高(至少在IT业)。如果每一条都照着对台湾有利的方向改,对服贸不爽的就是我了。基本一点,协议是双方的东西,即使我们看起来这个协议再合理,对对方再有好处,如果对方本身不同意,就不应当且也无法签署。协议本身,必然是双方讨论,我这里退让一点换取你哪里退让一点,最终得到双方认可——的这么个过程。

参考可以看以下几条:

问题在哪里

问题在于通过的流程。

台湾服贸对不同人群造成的影响不同。对于老板阶级来说,员工工资降低,市场扩大,自然是好到不能再好的好事。对于高阶白领来说,能到大陆打工也不坏。但是对于中低层员工而言,就要面对工资降低,服务品质变差等等问题。因此不同人群对服贸的支持和反对是不一致的。而台湾不是大陆,通过这种东西理论上是要通过内部讨论,人民授权的。问题是服贸这么一大包,这条这帮人不同意,那条那帮人不同意。每个人一个说法,但是总之就是反对你。这样服贸就始终无法通过,政府非常头大。

因此要通过服贸,比较容易的办法就是逐步协议,每次只谈一部分,对少部分人产生不利影响而对多数产生好处。逐步通过逐步调整,减少影响范围,降低抗议人群比例。但是台湾政府不但拿着一大包协议来签,而且想大手笔的一笔就签下去,完全没管民众的反应,也不管是否合规。等民众抗议了,再强行闯关。

呃,是不是来大陆考察多了,一不小心以为自己还在过组织生活呢?

最近怎么回事

本来去年服贸都要签了,结果被人踢爆,叫停回去重新逐条审查,而且要开公听会(听证会)。大陆的同志们想也知道,听证会么,涨价就对了。所以党国官员干脆一周开八场,我讲你听就好,乖乖不要多问。结果引起不满,后面被人排成了两周一场——依然是我讲你听(非常熟悉吧)。党国官员还很不爽,指责这是拖延时间。

然后拖到最后一场,干脆一合本子。好了,三个月已到,审查视为通过。

咳咳,要这么容易,不知道能不能拜托他通过一下大陆人获得“台湾”国籍的法规。只要迁一成大陆人的户籍过去,公投回归大陆就没疑虑了。

参考可以看这里

所以呢

所以这帮不爽的人就跑去把立法院给“占领”了。

啊然后呢

我也不知道。不过搞成这样,已经完全不是服贸的问题了。服贸本身没什么太大问题,逐条审议逐步通过也可以,阻力大也不会比现在更糟吧。现在已经是手法本身激起的不满比服贸本身还大了,作为政治(尤其是还算民主的地区的政治),这么搞是很不明智的。

从我关注的台湾各大事件的结果来看,往往是雷声大雨点小。运动的时候声势沸反,但是最终结果下来往往是差强人意。但是好在运动是经常的。民众往往是这里一点,那里一点,能够挡住一些太过荒唐的事情。其实这也是民主社会协商的必然结果,指望一次运动就能把所有的问题一并解决的想法,和一次通过整包服贸一样不靠谱。

by shell909090 at March 19, 2014 03:33 AM

March 17, 2014

@shell909090

系统内存有富裕但是syslog中持续报告内存耗尽

现象

ubuntu12.04,3.5.0-23的内核。在syslog里面持续看到内存耗尽,用free去查看却是内存还有80G左右。检查系统没有cgroup或者ulimit限制。log如下:

Mar 11 14:45:34 nb81 kernel: [7352493.081026] swapper/0: page allocation failure: order:4, mode:0x4020
Mar 11 14:45:34 nb81 kernel: [7352493.081035] Pid: 0, comm: swapper/0 Tainted: G        W    3.5.0-23-generic #35~precise1-Ubuntu
Mar 11 14:45:34 nb81 kernel: [7352493.081038] Call Trace:
Mar 11 14:45:34 nb81 kernel: [7352493.081040]  <IRQ>  [<ffffffff8112d1b6>] warn_alloc_failed+0xf6/0x150
Mar 11 14:45:34 nb81 kernel: [7352493.081065]  [<ffffffff81139a51>] ? wakeup_kswapd+0x101/0x160
Mar 11 14:45:34 nb81 kernel: [7352493.081071]  [<ffffffff81130ffb>] __alloc_pages_nodemask+0x6db/0x930
Mar 11 14:45:34 nb81 kernel: [7352493.081079]  [<ffffffff815c80df>] ? tcp_new_space+0xbf/0xd0
Mar 11 14:45:34 nb81 kernel: [7352493.081086]  [<ffffffff816895e2>] kmalloc_large_node+0x57/0x85
Mar 11 14:45:34 nb81 kernel: [7352493.081092]  [<ffffffff811766f5>] __kmalloc_node_track_caller+0x1a5/0x1f0
Mar 11 14:45:34 nb81 kernel: [7352493.081099]  [<ffffffff81574b8b>] ? __alloc_skb+0x4b/0x230
Mar 11 14:45:34 nb81 kernel: [7352493.081103]  [<ffffffff81574ee5>] ? skb_copy+0x45/0xb0
Mar 11 14:45:34 nb81 kernel: [7352493.081108]  [<ffffffff81574bb8>] __alloc_skb+0x78/0x230
Mar 11 14:45:34 nb81 kernel: [7352493.081113]  [<ffffffff81574ee5>] skb_copy+0x45/0xb0
Mar 11 14:45:34 nb81 kernel: [7352493.081135]  [<ffffffffa00181e5>] tigon3_dma_hwbug_workaround+0x205/0x270 [tg3]
Mar 11 14:45:34 nb81 kernel: [7352493.081142]  [<ffffffff8134d359>] ? swiotlb_unmap_page+0x9/0x10
Mar 11 14:45:34 nb81 kernel: [7352493.081151]  [<ffffffffa0019e25>] tg3_start_xmit+0x445/0x990 [tg3]
Mar 11 14:45:34 nb81 kernel: [7352493.081157]  [<ffffffff815848b6>] dev_hard_start_xmit+0x256/0x550
Mar 11 14:45:34 nb81 kernel: [7352493.081165]  [<ffffffff815a09c6>] sch_direct_xmit+0xf6/0x1c0
Mar 11 14:45:34 nb81 kernel: [7352493.081170]  [<ffffffff815a0b36>] __qdisc_run+0xa6/0x130
Mar 11 14:45:34 nb81 kernel: [7352493.081175]  [<ffffffff81583786>] net_tx_action+0xe6/0x200
Mar 11 14:45:34 nb81 kernel: [7352493.081183]  [<ffffffff8105ba88>] __do_softirq+0xa8/0x210
Mar 11 14:45:34 nb81 kernel: [7352493.081191]  [<ffffffff8169e7de>] ? _raw_spin_lock+0xe/0x20
Mar 11 14:45:34 nb81 kernel: [7352493.081196]  [<ffffffff816a841c>] call_softirq+0x1c/0x30
Mar 11 14:45:34 nb81 kernel: [7352493.081204]  [<ffffffff81016245>] do_softirq+0x65/0xa0
Mar 11 14:45:34 nb81 kernel: [7352493.081209]  [<ffffffff8105be6e>] irq_exit+0x8e/0xb0
Mar 11 14:45:34 nb81 kernel: [7352493.081214]  [<ffffffff816a8c73>] do_IRQ+0x63/0xe0
Mar 11 14:45:34 nb81 kernel: [7352493.081220]  [<ffffffff8169ec6a>] common_interrupt+0x6a/0x6a
Mar 11 14:45:34 nb81 kernel: [7352493.081222]  <EOI>  [<ffffffff81040af9>] ? default_spin_lock_flags+0x9/0x10
Mar 11 14:45:34 nb81 kernel: [7352493.081236]  [<ffffffff813992da>] ? intel_idle+0xea/0x150
Mar 11 14:45:34 nb81 kernel: [7352493.081241]  [<ffffffff813992bc>] ? intel_idle+0xcc/0x150
Mar 11 14:45:34 nb81 kernel: [7352493.081247]  [<ffffffff81535509>] cpuidle_enter+0x19/0x20
Mar 11 14:45:34 nb81 kernel: [7352493.081252]  [<ffffffff81535b2c>] cpuidle_idle_call+0xac/0x2a0
Mar 11 14:45:34 nb81 kernel: [7352493.081258]  [<ffffffff8101d89f>] cpu_idle+0xcf/0x120
Mar 11 14:45:34 nb81 kernel: [7352493.081266]  [<ffffffff81661f8e>] rest_init+0x72/0x74
Mar 11 14:45:34 nb81 kernel: [7352493.081274]  [<ffffffff81cf3c45>] start_kernel+0x3c5/0x3d2
Mar 11 14:45:34 nb81 kernel: [7352493.081280]  [<ffffffff81cf3801>] ? pass_bootoption.constprop.3+0xd3/0xd3
Mar 11 14:45:34 nb81 kernel: [7352493.081286]  [<ffffffff81cf3397>] x86_64_start_reservations+0x131/0x135
Mar 11 14:45:34 nb81 kernel: [7352493.081292]  [<ffffffff81cf3120>] ? early_idt_handlers+0x120/0x120
Mar 11 14:45:34 nb81 kernel: [7352493.081298]  [<ffffffff81cf3468>] x86_64_start_kernel+0xcd/0xdc
Mar 11 14:45:34 nb81 kernel: [7352493.081300] Mem-Info:
Mar 11 14:45:34 nb81 kernel: [7352493.081303] Node 0 DMA per-cpu:
Mar 11 14:45:34 nb81 kernel: [7352493.081307] CPU    0: hi:    0, btch:   1 usd:   0
Mar 11 14:45:34 nb81 kernel: [7352493.081309] CPU    1: hi:    0, btch:   1 usd:   0
Mar 11 14:45:34 nb81 kernel: [7352493.081312] CPU    2: hi:    0, btch:   1 usd:   0
Mar 11 14:45:34 nb81 kernel: [7352493.081314] CPU    3: hi:    0, btch:   1 usd:   0
Mar 11 14:45:34 nb81 kernel: [7352493.081317] CPU    4: hi:    0, btch:   1 usd:   0
Mar 11 14:45:34 nb81 kernel: [7352493.081319] CPU    5: hi:    0, btch:   1 usd:   0
Mar 11 14:45:34 nb81 kernel: [7352493.081321] CPU    6: hi:    0, btch:   1 usd:   0
Mar 11 14:45:34 nb81 kernel: [7352493.081324] CPU    7: hi:    0, btch:   1 usd:   0
Mar 11 14:45:34 nb81 kernel: [7352493.081326] CPU    8: hi:    0, btch:   1 usd:   0
Mar 11 14:45:34 nb81 kernel: [7352493.081329] CPU    9: hi:    0, btch:   1 usd:   0
Mar 11 14:45:34 nb81 kernel: [7352493.081331] CPU   10: hi:    0, btch:   1 usd:   0
Mar 11 14:45:34 nb81 kernel: [7352493.081333] CPU   11: hi:    0, btch:   1 usd:   0
Mar 11 14:45:34 nb81 kernel: [7352493.081336] CPU   12: hi:    0, btch:   1 usd:   0
Mar 11 14:45:34 nb81 kernel: [7352493.081338] CPU   13: hi:    0, btch:   1 usd:   0
Mar 11 14:45:34 nb81 kernel: [7352493.081340] CPU   14: hi:    0, btch:   1 usd:   0
Mar 11 14:45:34 nb81 kernel: [7352493.081343] CPU   15: hi:    0, btch:   1 usd:   0
Mar 11 14:45:34 nb81 kernel: [7352493.081345] CPU   16: hi:    0, btch:   1 usd:   0
Mar 11 14:45:34 nb81 kernel: [7352493.081347] CPU   17: hi:    0, btch:   1 usd:   0
Mar 11 14:45:34 nb81 kernel: [7352493.081350] CPU   18: hi:    0, btch:   1 usd:   0
Mar 11 14:45:34 nb81 kernel: [7352493.081352] CPU   19: hi:    0, btch:   1 usd:   0
Mar 11 14:45:34 nb81 kernel: [7352493.081354] CPU   20: hi:    0, btch:   1 usd:   0
Mar 11 14:45:34 nb81 kernel: [7352493.081357] CPU   21: hi:    0, btch:   1 usd:   0
Mar 11 14:45:34 nb81 kernel: [7352493.081359] CPU   22: hi:    0, btch:   1 usd:   0
Mar 11 14:45:34 nb81 kernel: [7352493.081361] CPU   23: hi:    0, btch:   1 usd:   0
Mar 11 14:45:34 nb81 kernel: [7352493.081363] Node 0 DMA32 per-cpu:
Mar 11 14:45:34 nb81 kernel: [7352493.081367] CPU    0: hi:  186, btch:  31 usd: 155
Mar 11 14:45:34 nb81 kernel: [7352493.081369] CPU    1: hi:  186, btch:  31 usd:  63
Mar 11 14:45:34 nb81 kernel: [7352493.081372] CPU    2: hi:  186, btch:  31 usd: 135
Mar 11 14:45:34 nb81 kernel: [7352493.081374] CPU    3: hi:  186, btch:  31 usd: 170
Mar 11 14:45:34 nb81 kernel: [7352493.081377] CPU    4: hi:  186, btch:  31 usd:  79
Mar 11 14:45:34 nb81 kernel: [7352493.081379] CPU    5: hi:  186, btch:  31 usd:   0
Mar 11 14:45:34 nb81 kernel: [7352493.081381] CPU    6: hi:  186, btch:  31 usd: 118
Mar 11 14:45:34 nb81 kernel: [7352493.081384] CPU    7: hi:  186, btch:  31 usd: 176
Mar 11 14:45:34 nb81 kernel: [7352493.081386] CPU    8: hi:  186, btch:  31 usd:  53
Mar 11 14:45:34 nb81 kernel: [7352493.081389] CPU    9: hi:  186, btch:  31 usd:   0
Mar 11 14:45:34 nb81 kernel: [7352493.081391] CPU   10: hi:  186, btch:  31 usd: 183
Mar 11 14:45:34 nb81 kernel: [7352493.081393] CPU   11: hi:  186, btch:  31 usd:   1
Mar 11 14:45:34 nb81 kernel: [7352493.081396] CPU   12: hi:  186, btch:  31 usd: 168
Mar 11 14:45:34 nb81 kernel: [7352493.081398] CPU   13: hi:  186, btch:  31 usd:   0
Mar 11 14:45:34 nb81 kernel: [7352493.081401] CPU   14: hi:  186, btch:  31 usd: 180
Mar 11 14:45:34 nb81 kernel: [7352493.081403] CPU   15: hi:  186, btch:  31 usd: 156
Mar 11 14:45:34 nb81 kernel: [7352493.081406] CPU   16: hi:  186, btch:  31 usd:  55
Mar 11 14:45:34 nb81 kernel: [7352493.081408] CPU   17: hi:  186, btch:  31 usd: 183
Mar 11 14:45:34 nb81 kernel: [7352493.081410] CPU   18: hi:  186, btch:  31 usd: 138
Mar 11 14:45:34 nb81 kernel: [7352493.081413] CPU   19: hi:  186, btch:  31 usd:   0
Mar 11 14:45:34 nb81 kernel: [7352493.081415] CPU   20: hi:  186, btch:  31 usd: 174
Mar 11 14:45:34 nb81 kernel: [7352493.081418] CPU   21: hi:  186, btch:  31 usd:   0
Mar 11 14:45:34 nb81 kernel: [7352493.081420] CPU   22: hi:  186, btch:  31 usd:  62
Mar 11 14:45:34 nb81 kernel: [7352493.081422] CPU   23: hi:  186, btch:  31 usd:   0
Mar 11 14:45:34 nb81 kernel: [7352493.081424] Node 0 Normal per-cpu:
Mar 11 14:45:34 nb81 kernel: [7352493.081428] CPU    0: hi:  186, btch:  31 usd: 131
Mar 11 14:45:34 nb81 kernel: [7352493.081431] CPU    1: hi:  186, btch:  31 usd: 177
Mar 11 14:45:34 nb81 kernel: [7352493.081433] CPU    2: hi:  186, btch:  31 usd: 157
Mar 11 14:45:34 nb81 kernel: [7352493.081436] CPU    3: hi:  186, btch:  31 usd: 176
Mar 11 14:45:34 nb81 kernel: [7352493.081438] CPU    4: hi:  186, btch:  31 usd:  88
Mar 11 14:45:34 nb81 kernel: [7352493.081440] CPU    5: hi:  186, btch:  31 usd: 177
Mar 11 14:45:34 nb81 kernel: [7352493.081443] CPU    6: hi:  186, btch:  31 usd: 159
Mar 11 14:45:34 nb81 kernel: [7352493.081445] CPU    7: hi:  186, btch:  31 usd: 157
Mar 11 14:45:34 nb81 kernel: [7352493.081447] CPU    8: hi:  186, btch:  31 usd: 152
Mar 11 14:45:34 nb81 kernel: [7352493.081450] CPU    9: hi:  186, btch:  31 usd: 183
Mar 11 14:45:34 nb81 kernel: [7352493.081452] CPU   10: hi:  186, btch:  31 usd: 145
Mar 11 14:45:34 nb81 kernel: [7352493.081454] CPU   11: hi:  186, btch:  31 usd: 169
Mar 11 14:45:34 nb81 kernel: [7352493.081457] CPU   12: hi:  186, btch:  31 usd: 182
Mar 11 14:45:34 nb81 kernel: [7352493.081459] CPU   13: hi:  186, btch:  31 usd:  11
Mar 11 14:45:34 nb81 kernel: [7352493.081462] CPU   14: hi:  186, btch:  31 usd: 145
Mar 11 14:45:34 nb81 kernel: [7352493.081464] CPU   15: hi:  186, btch:  31 usd: 173
Mar 11 14:45:34 nb81 kernel: [7352493.081467] CPU   16: hi:  186, btch:  31 usd: 153
Mar 11 14:45:34 nb81 kernel: [7352493.081469] CPU   17: hi:  186, btch:  31 usd: 177
Mar 11 14:45:34 nb81 kernel: [7352493.081471] CPU   18: hi:  186, btch:  31 usd:  54
Mar 11 14:45:34 nb81 kernel: [7352493.081474] CPU   19: hi:  186, btch:  31 usd: 161
Mar 11 14:45:34 nb81 kernel: [7352493.081476] CPU   20: hi:  186, btch:  31 usd:  76
Mar 11 14:45:34 nb81 kernel: [7352493.081479] CPU   21: hi:  186, btch:  31 usd: 178
Mar 11 14:45:34 nb81 kernel: [7352493.081481] CPU   22: hi:  186, btch:  31 usd: 153
Mar 11 14:45:34 nb81 kernel: [7352493.081483] CPU   23: hi:  186, btch:  31 usd: 178
Mar 11 14:45:34 nb81 kernel: [7352493.081486] Node 1 Normal per-cpu:
Mar 11 14:45:34 nb81 kernel: [7352493.081489] CPU    0: hi:  186, btch:  31 usd: 168
Mar 11 14:45:34 nb81 kernel: [7352493.081491] CPU    1: hi:  186, btch:  31 usd: 156
Mar 11 14:45:34 nb81 kernel: [7352493.081493] CPU    2: hi:  186, btch:  31 usd: 177
Mar 11 14:45:34 nb81 kernel: [7352493.081495] CPU    3: hi:  186, btch:  31 usd:  65
Mar 11 14:45:34 nb81 kernel: [7352493.081498] CPU    4: hi:  186, btch:  31 usd: 163
Mar 11 14:45:34 nb81 kernel: [7352493.081500] CPU    5: hi:  186, btch:  31 usd: 110
Mar 11 14:45:34 nb81 kernel: [7352493.081502] CPU    6: hi:  186, btch:  31 usd: 179
Mar 11 14:45:34 nb81 kernel: [7352493.081505] CPU    7: hi:  186, btch:  31 usd:  39
Mar 11 14:45:34 nb81 kernel: [7352493.081507] CPU    8: hi:  186, btch:  31 usd: 181
Mar 11 14:45:34 nb81 kernel: [7352493.081509] CPU    9: hi:  186, btch:  31 usd: 107
Mar 11 14:45:34 nb81 kernel: [7352493.081511] CPU   10: hi:  186, btch:  31 usd: 159
Mar 11 14:45:34 nb81 kernel: [7352493.081514] CPU   11: hi:  186, btch:  31 usd: 113
Mar 11 14:45:34 nb81 kernel: [7352493.081516] CPU   12: hi:  186, btch:  31 usd: 167
Mar 11 14:45:34 nb81 kernel: [7352493.081518] CPU   13: hi:  186, btch:  31 usd: 125
Mar 11 14:45:34 nb81 kernel: [7352493.081521] CPU   14: hi:  186, btch:  31 usd: 164
Mar 11 14:45:34 nb81 kernel: [7352493.081523] CPU   15: hi:  186, btch:  31 usd:  68
Mar 11 14:45:34 nb81 kernel: [7352493.081525] CPU   16: hi:  186, btch:  31 usd: 169
Mar 11 14:45:34 nb81 kernel: [7352493.081528] CPU   17: hi:  186, btch:  31 usd: 152
Mar 11 14:45:34 nb81 kernel: [7352493.081530] CPU   18: hi:  186, btch:  31 usd: 160
Mar 11 14:45:34 nb81 kernel: [7352493.081532] CPU   19: hi:  186, btch:  31 usd: 129
Mar 11 14:45:34 nb81 kernel: [7352493.081535] CPU   20: hi:  186, btch:  31 usd: 156
Mar 11 14:45:34 nb81 kernel: [7352493.081537] CPU   21: hi:  186, btch:  31 usd:  56
Mar 11 14:45:34 nb81 kernel: [7352493.081539] CPU   22: hi:  186, btch:  31 usd: 183
Mar 11 14:45:34 nb81 kernel: [7352493.081542] CPU   23: hi:  186, btch:  31 usd: 161
Mar 11 14:45:34 nb81 kernel: [7352493.081548] active_anon:2011479 inactive_anon:465423 isolated_anon:0
Mar 11 14:45:34 nb81 kernel: [7352493.081548]  active_file:8441358 inactive_file:12481139 isolated_file:8
Mar 11 14:45:34 nb81 kernel: [7352493.081548]  unevictable:0 dirty:223271 writeback:7577 unstable:0
Mar 11 14:45:34 nb81 kernel: [7352493.081548]  free:105270 slab_reclaimable:1002710 slab_unreclaimable:35112
Mar 11 14:45:34 nb81 kernel: [7352493.081548]  mapped:7298 shmem:370 pagetables:10455 bounce:0
Mar 11 14:45:34 nb81 kernel: [7352493.081552] Node 0 DMA free:15904kB min:12kB low:12kB high:16kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15648kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes
Mar 11 14:45:34 nb81 kernel: [7352493.081561] lowmem_reserve[]: 0 2947 48307 48307
Mar 11 14:45:34 nb81 kernel: [7352493.081567] Node 0 DMA32 free:190008kB min:2744kB low:3428kB high:4116kB active_anon:30588kB inactive_anon:56160kB active_file:200180kB inactive_file:1256876kB unevictable:0kB isolated(anon):0kB isolated(file):12kB present:3017920kB mlocked:0kB dirty:19992kB writeback:4092kB mapped:4kB shmem:0kB slab_reclaimable:1213128kB slab_unreclaimable:45256kB kernel_stack:3528kB pagetables:408kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
Mar 11 14:45:34 nb81 kernel: [7352493.081575] lowmem_reserve[]: 0 0 45360 45360
Mar 11 14:45:34 nb81 kernel: [7352493.081580] Node 0 Normal free:83784kB min:42264kB low:52828kB high:63396kB active_anon:3823788kB inactive_anon:923604kB active_file:19944584kB inactive_file:19948720kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:46448640kB mlocked:0kB dirty:459668kB writeback:14692kB mapped:16260kB shmem:1456kB slab_reclaimable:1234664kB slab_unreclaimable:43432kB kernel_stack:2856kB pagetables:21028kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
Mar 11 14:45:34 nb81 kernel: [7352493.081589] lowmem_reserve[]: 0 0 0 0
Mar 11 14:45:34 nb81 kernel: [7352493.081593] Node 1 Normal free:131384kB min:45084kB low:56352kB high:67624kB active_anon:4191540kB inactive_anon:881928kB active_file:13620668kB inactive_file:28718960kB unevictable:0kB isolated(anon):0kB isolated(file):20kB present:49545216kB mlocked:0kB dirty:413424kB writeback:11524kB mapped:12928kB shmem:24kB slab_reclaimable:1563048kB slab_unreclaimable:51760kB kernel_stack:3560kB pagetables:20384kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
Mar 11 14:45:34 nb81 kernel: [7352493.081601] lowmem_reserve[]: 0 0 0 0
Mar 11 14:45:34 nb81 kernel: [7352493.081606] Node 0 DMA: 0*4kB 0*8kB 0*16kB 1*32kB 2*64kB 1*128kB 1*256kB 0*512kB 1*1024kB 1*2048kB 3*4096kB = 15904kB
Mar 11 14:45:34 nb81 kernel: [7352493.081619] Node 0 DMA32: 20628*4kB 12963*8kB 195*16kB 20*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 189976kB
Mar 11 14:45:34 nb81 kernel: [7352493.081631] Node 0 Normal: 19369*4kB 378*8kB 0*16kB 2*32kB 2*64kB 1*128kB 2*256kB 0*512kB 1*1024kB 1*2048kB 0*4096kB = 84404kB
Mar 11 14:45:34 nb81 kernel: [7352493.081643] Node 1 Normal: 21441*4kB 3184*8kB 1142*16kB 5*32kB 6*64kB 3*128kB 4*256kB 1*512kB 1*1024kB 0*2048kB 0*4096kB = 132996kB
Mar 11 14:45:34 nb81 kernel: [7352493.081674] 20923024 total pagecache pages
Mar 11 14:45:34 nb81 kernel: [7352493.081676] 736 pages in swap cache
Mar 11 14:45:34 nb81 kernel: [7352493.081679] Swap cache stats: add 17169, delete 16433, find 241775/241891
Mar 11 14:45:34 nb81 kernel: [7352493.081681] Free swap  = 911316kB
Mar 11 14:45:34 nb81 kernel: [7352493.081682] Total swap = 975868kB
Mar 11 14:45:34 nb81 kernel: [7352493.576101] 25165808 pages RAM
Mar 11 14:45:34 nb81 kernel: [7352493.576105] 425876 pages reserved
Mar 11 14:45:34 nb81 kernel: [7352493.576107] 18906312 pages shared
Mar 11 14:45:34 nb81 kernel: [7352493.576108] 5736141 pages non-shared

内存不足报警是个非常严重的问题,但是又不能对内存做调整,所以需要快速的对这个问题给出一个方案。当然,这个问题最后就到我头上了。

处理

找了半天的类似错误,找到的原因乱七八糟。有说是网络问题的,有说是硬盘swap有问题导致的,还有说是numa造成的。运维组调整了min_free_bytes,从结果来看,问题倒是减轻了不少。于是分开尝试。

swap

这个其实最好验证,关掉swap就知道了,反正我们内存也够。可惜golang1.1以前有个bug,在amd64上关闭swap会导致程序crush。所以不能关闭swap,只能替换。

运维组的老大做的实验,换个盘新建swap。用swapon启用新的swap,swapoff关闭原来的swap。然后系统没有变化,因此排除swap导致问题的可能性。

numa和内存分配碎片化问题

检查出问题设备的/proc/buddyinfo文件,可以看到所有出问题设备的DMA32大块都被耗尽了。在大部分的系统上,最大的块不过是32K。64K的块只有一两块或者根本没有。这个假设可以解释min_free_bytes调整能够减轻问题的理由。

但是经过扫描,不少没有问题的机器上也存在非常严重的内存碎片化效应。只能说碎片化属于相关现象,而不是决定性差异。而且是单向相关——报警必然伴随碎片化内存,但是内存碎片化却并不一定导致报警。

对于这个问题,我试过内核参数迫使其回收内存。使用zone_reclaim_mode改变内存回收模型(尽管解说中这个对某些业务非常有害)。但是始终没有彻底解决问题。

网络问题

我找到了某个朋友的gist,发现和我们的错误堆栈非常接近。经过询问,他有篇文章不同业务对网络的要求,里面猜测是交换机丢包导致的问题。

我找运维组的同事帮忙,检查了一下出问题的设备所连接的交换机。结果是,虽然这些设备的丢包非常多,但是其他没出问题的设备丢包也不少。两者的比例没有决定性的差异。

另一个是在设备上用netstat -s来查看丢包率。但是不是每个设备都有丢包率。所以也可以排除网络问题。

定向

在上面三种假说里,我首先可以否定swap。因为两块磁盘同时损坏的概率基本是0。其他两个假说很难区分。我始终觉得两者都不能解释很多问题。例如内存碎片化假说无法说明为什么不是每个内存碎片化的系统都出现问题。网络假说也无法说明为什么问题只出现在某些设备上。

看来再找下去也是白费,于是我改用了其他方法——根据堆栈阅读源码。

内核源码

参阅lxr的结果。堆栈如下所列:

这个问题发生在tigon3_dma_hwbug_workaround中,以下调用使用的是GFP_ATOMIC。

new_skb = skb_copy(skb, GFP_ATOMIC);

这导致问题被报告。但是在最下方,如果没有内存,函数只是不做处理,增加丢包计数,并返回成功。这使我怀疑这个报警本身只是一个警告,不需要认真处理。

在有点数之后,我修改了关键词又去google了一把。得到了以下bug:

https://bugzilla.kernel.org/show_bug.cgi?id=12135

结论

这是一种在tigon3上才出现的问题,由于网络传输速率大于内存回收速率,内核不停报警。本质上这个报警可以被忽略,或者调整min_free_bytes来减轻。内核组暂时不对这个问题做出任何修正。

OK,问题解决,洗洗睡吧。

by shell909090 at March 17, 2014 06:01 AM

March 07, 2014

@shell909090

换了一个服务器

上一家服务器的质量太差了。价钱贵,响应慢,还经常服务不可用。忍无可忍,换了东哥的虚拟主机。反正我只支持一个blog。

大家可以用新地址访问我的blog: http://shell909090.org/blog

希望没什么别的问题。如果有的话,可以发我email,或者通过twitter联系我。我现在已经不怎么上微薄了,切切。

PS: 不知为何,我这里发出去的同步到twitter没有经过短链接缩短服务,导致twitter上和facebook上的新文章通知都有问题。

by shell909090 at March 07, 2014 07:51 AM

March 06, 2014

@shell909090

移动设备的未来预期

相机

低端数码相机估计会死绝。高端相机可能会内置一点存储,并配置近程传输和控制能力。

很简单,低端相机能做的,手机能做个八成。但是手机随身携带,低端相机可就不一定了。在对比之下,有多少用户愿意再额外的花个几百大洋弄个专门的相机。还得经常维护电池,存储卡,导入导出照片呢?而且考虑到随着技术进步,手机的照相能力能够越来越接近低端相机。这部分市场利润只会逐年下降。

相比起来,高端相机的成像效果,目前手机还是无能为力的。而且没有重大技术突破的话也做不到。但是高端相机往往有个共同的缺陷——成本太高,更换速度太慢。如果买了一个4000-6000的相机,很少会在一两年的时间内就把他换掉。这导致相机的附设功能落后,软件功能严重脱节。往往好容易在相机里内置了微薄,结果现在用户都想用微信了。

解决这个问题的方案就是用手机作为相机的控制和存储。一般手机的显示屏比相机的更大更好是常识。如果相机可以和手机联动的话,相机可以省掉一块大幅高质量显示屏,改用小屏做一般性的展示。还可以用手机的触控技术提供更好的操作。省掉大容量存储,而且还可以即拍即发,数据同步/分享,而不用导入导出。

看起来最像的是蓝牙,但是2.0的速度太慢了,只有250KB/s多。一副好点的照片最低5M,需要20s传输时间,等不起。3.0的速率上升到2MB/s以上,大约是2s-3s,基本没问题。4.0更快,功耗更小。

无线局域网(wifi)技术的速度很不错,即使是11g也有2.2MB/s的传输速度。手机上虽然普遍不快,但是1M/s-1.5M/s的速度绝对没问题。一张图片3s左右完成传输,也可以接受。而且好处是,目前的手机大多已经支持11n或者开始支持。11n的网络速度可以达到10MB/s,传输40M的原始照片也只需要4s。问题是,wifi为了使得两者可以互相传输,必须将其中一个配置为AP。这样一来手机连接其他AP上网就会受到限制,这大大限制了他的应用。不过随着无线网络技术的发展,AP可能变得不那么重要。

目前从google的搜索结果来看,wifi比蓝牙拥有更多的搜索结果。

存储

从通用性存储卡的价格来看,16G的普卡已经到了百元以内,基本谁都玩的起。再往下怎么玩?加大存储对移动设备来说用处并不大。目前移动设备上面存储最大的无非是音乐和图片。8G可以存储1500多张高质量照片,或者同数量的音乐。我想一般人手机上要再存储这个数量以上的数据,也不大可能。

要说在上面存一堆历史照片或者音乐库什么的,这是拿移动设备当数据库玩的思路,边际收益很低。当年苹果就拿硬盘把mp3做成了音乐库,效果很不错。不过后来历代别人就没这么玩过。既然我们可以把大头保留在电脑上,把热数据放在手机里。在手机里保留所有数据的意义就不大。是个玩法,但是不足以驱动存储卡升级的需求。

移动存储要再玩size,只有等视频技术了。8G的存储只足够20小时的高质量视频,这还是高压缩格式。换算成美剧的话大概刚刚够放下一季的量。加上音乐和照片,差不多够驱动主流存储升级到32G或64G的水平,也就是两三年的功夫。

再往后,存储就没什么玩头了,就算是用录像功能录上三五个小时的视频(这是目前电池的极限),无非也就是2-4G的空间而已。从size上说,32G的卡足够终结一个世代。除非碰上有些极其消耗存储的杀手级应用横空出世(你也知道了什么情况下可以买入这些存储生产商的股票)。

另一个玩法就是速度。目前的吞吐速度在4MB/s-10MB/s之间,而且主流都是4M。对比一下网速,你大概就知道为什么手机的无线速度始终上不去——再快卡的吞吐就是个问题了。未来的存储可能优化到10MB/s的速度,这刚好比11n的普遍网络最高速度(大约9MB/s)更高一些。再高目前传输也解决不了。所以看起来存储暂时不会成为关键。

电源

目前移动设备的核心全部集中在电源上,核心问题在于电池技术不受摩尔效应的控制。

以手机来说。nokia的黑白机一次充电可以用一周,到了android智能机都是论小时的。不是电池没长进。实际上无论是可靠性,单位质量储能比,还是性价比,今天比起当年的电池都有相当提高。但是移动设备的能耗也随之上涨,锂电池已经越来越不敷使用,成为逐步上涨的移动设备电力消耗的瓶颈。

更让人绝望的是,锂离子电池什么时候发明的?1992年实用化,大规模使用大约隔了10年的时间。如果我们今天(2013年)希望使用什么升级技术,那他2003年就应该实用化了。问题是,我们并没有看到有这种技术。

另一项有望得到应用的技术就是快速充电。虽然电池的续航能力无法提高,但是目前的充电功率只有5W。这个功率完全可以提升到50W(比普通笔记本的电源功率略低),或者150W(和低功率的台式机持平)。如果用10倍的充电功率来换取10倍的充电速度,将2小时完成的充电换为6分钟充电50%。或者更激进的,在2分钟内充电50%(150W功率),我想电池的充电就会容易许多。

其中一种解法就是超级电容。目前超级电容事实上是一项颇为成熟的技术,但是成本高,能量密度低,和锂电池相比并没有优势。要能够缓冲锂电池所需能量同量级的水平,缓冲器的大小比锂电池本身还大。所以在大幅改进前用不上。

不过让人燃起希望的是,目前的纳米线锂离子电池的质量能量密度已经达到2.5以上(普通锂电池大约是0.5-1不等),而且可以高速冲放电(比普通锂电池快的多)。这项技术2008年看到的报道,按照预计,有望在五年(2018年)后采用。届时同样质量的电池,续航能力可以高达目前的5倍。android设备有望续航能力重新按天计算。

网络

目前的主流网络还是EDGE/WCDMA技术。TDS-CDMA完全成了个笑话。确实有不少基于他的产品,但是最好的手机生产商完全不考虑这项标准。这导致顶级的手机,顶级的手机用户完全不可能用这种网络。你见过买了Iphone还在用移动卡的么?基本TDS-CDMA就被当作上网卡和合约机用了。

下一代技术基本是4G了。什么概念?静态速率1Gbps,和千兆以太网相当,比wifi还快。问题是中国在4G上又扯淡,用的是LTE-TDD(TD-LTE),而不是LTE-FDD。参与联盟的人倒是不少,可是最终结局如何还是难料。

上面还不是主要问题。主要问题是什么?费率!3G时代忘记关流量还能卖个肾,4G时代忘记关流量卖房都不一定管用了。10多年来,官方明面上的网络费用只是从1k一分(10元1M),降低到1元1M。当然,背地里打折下来,网络费用基本在35元1G,或者更低。而有线网络的费率呢?我们按照1/10的总带宽用量来计算(现在很多人拿网络看电影看视频,平均每天2.4小时的满流量一点不多吧)。每G价格42分。。。

所以,移动网络价格降到5元/G以内前,是不会对有线网络构成冲击的,无论3G/4G。即使有,也是在特定场合,而不是总体上。作为对比,台湾数据流量价格折合人民币大约是8元/G,所以台湾用移动网络的人就多很多。问题是,台湾的有线网络也更便宜。。。

电话

总体趋势上说,电话和短信被软电话和消息替代是常规趋势。说的更通俗点,就是不再打电话和发消息,改用QQ现场通话和发消息。

这很好理解。软电话的成本要比电话更低。一分钟电话大约是10分,换成数据流量的话能够传输2.9M数据,合50KB/s左右。而5-10KB/s就可以提供非常不错的通话质量了。

问题在于两点。首先,编解码,数据传输会比直接传输更加的慢。而且在没有QoS的情况下,软电话的抖动非常大。你说的话到达对方那里的时间可能比以前长,而且可能变动幅度异常的高。

然而大多数情况下(主要是闲聊),对语音质量的邀请并不那么高,反而对价格非常敏感。这种情况下软电话就更有替代普通电话的趋势。我和老妈打过数次语音电话,除了手机耗电量高点,有的时候突然会听不清外,也没有什么特别的感觉。

于是你就大概能猜到移动通讯供应商网络为什么不能降价。10KB/s的速率,35元/G的价格,一分钟大约是2分。而移动通讯的大部分套餐里面,一分钟电话的价格都是10分。所以当网络价格低于175元/G的时候,软电话就有更大的趋势替代电话。如果价格降到17.5元/G的时候,软电话价格只有电话的1/10。移动的台面价格是1000元/G,而台面下价格则远远要低,正是因此。

by shell909090 at March 06, 2014 08:38 AM

March 05, 2014

@shell909090

昆明事件的几点补充(一)

这绝不是一个悲伤的个人所能做出的事情

因为已经超出了个人能力的极限。

在大陆这些年,看过不少充满凶戾的事件。拿刀冲进政府机关砍杀的人,冲进幼儿园砍杀的人。但是我从未见过,或者听闻过有数人,拿刀在人口密集区域无差别砍杀。一方面这不会给人带来任何的好处,另一方面则是实施太难。

不会给人带来好处,就不大会有人想做。人的本性都是趋利避害的,除非发疯一样的不计损益。一个人可能发疯(我们也听闻过不少这样的疯子),两个人就很难了。一群人同时发疯,还能这么有效率的进行杀戮。你不如说是我疯了算了。

另一方面,大陆现在禁止民众持枪,菜刀已经要实名购买。一群维族人,跑到非聚居区的昆明去,本身就够扎眼了。居然还能有效率的搞到数把凶器,同一时间发起进攻。你觉得这像是某个个人或者小群体能够做的到的事情么?如果任何个人或者小团体可以轻易做到,你真的能说维族被管制和歧视么?

凶手是维族不等于凶手是新疆分裂分子

大陆官方的措辞是,“根据现场的证据”,这是新疆分裂分子所为。这事说的不明不白,颇惹人怀疑。我有位推上的朋友是医生,有同事参与当晚抢救,也听了不少小道消息。当事者的说法很直白,“一看就是新疆人”。当然,我觉得他想说的是维族面孔。所击毙的凶手,将来也是要有照片画像之类证据的。所以我倒是对行凶者是维族没什么怀疑。

但是是不是分裂分子所为,这却不大好说。因为大陆官方拿到消息的第一处理反应肯定是往新疆独立运动的人身上推。一来这帮人确实是维族,二来这帮人明显是有组织有计划。维族里面对政府不满,对汉族不满,有能力实施策划这起事件的,也就那么多人。就算将来有充足的证据说不是,这个推论也不是说不过去。

问题是能不能以此盖棺定论呢?很难说。捉贼捉脏,捉奸成双。没有任何其他旁证的情况下,我们自己心里认定是无妨,拿来要说服他人总是欠了点什么的感觉。常规情况下,案子往下查就是了。偏偏大陆这里的案子又是出了名的不公开透明。自从事件发生后,真相就再也和你没有关系了。后续抓到的犯人?可能是地方为了交差搞来的。本来没联系,可以打出联系来。问题是,大家都知道你会这么搞的时候,明明是真的,却没有人信了——这就是“狼来了”的故事。

无论凶手是谁,必然都是个小人

任何施行袭击的人,恐怖分子也好,心怀恨意的个人也罢。基本的一点是,我的行动是我对某些事情不满的结果。我杀人,是为了达到我的目标,而且我要让你知道这一点。同时,我也承担这一行为的后果。所以你可以看到很多组织宣称对XX事件负责(当然,也有很多事情跟不不是他干的,非往自己身上扯的乌龙事件)。此所谓,不教而殺謂之虐。

问题是没人宣布对此事负责。

世维会发言人说,这事不是我们干的。大陆官方说,就是你们干的。我擦,女王怀孕了,这TM是谁干的?

不知大家有多少人看过“竹林中”这部小说,这部小说出自小说集“罗生门”。后者想必是家喻户晓。多个当事人,每个人都为了自己的利益而描述不同的客观,最后导致无法还原出一个真相来。

好吧,我也不知道谁干的。但无论是谁,从不承担其后果来看,必然是个小人。

个人觉得大陆官方自导自演的可能性不大

确实,这两天正好在搞加强管制。弄这么一出确实非常有利于大陆官方对新闻的管制,军警的运用。从最大的受益者就是第一嫌疑犯的角度说,这么怀疑没错。不,或者我们得说,对官方的阴谋论的怀疑是必要的。只有这样我们才不容易受到愚弄。

但是我个人分析了一下后,基本排除了这点。因为官方的损失大于收益,而且有未知的风险。

维稳固然要靠政府,这确实加大了对政府的依赖,可能给政府更大的权力。可是对政府是否能成功维稳的信心伤害也是很大。目前大陆政府已经做了常态化的国道检查,地铁安检,大规模城管执法,连菜刀都已经实名制了。昆明大屠杀让无数人质疑,大陆警方是否有能力保护民众的安全,那些严苛的条例是否只是针对善良的民众。

如果这个疑惑不解除的话,对官方的统治是很不利的。人人怀疑你是只纸老虎的时候,各种事情就会层出不穷。然后官方就会进一步疲于奔命。

要验证也不难。马上就是两会了。如果这两天有人提案加强对民众的监管(这是照例有的),包括禁止持刀,警察自由调动等。提案严谨,考虑周全,看起来就不像是这两天想的出来的。那值得怀疑的可能性就大大增加了。如果连像样的提案都没有,全是陈词滥调,那只能说官方也被打了个措手不及。

恐怖主义不等于对抗暴政

恐怖主义和对抗暴政的区别在哪里?关键是对对方的职能机关动手还是对平民动手。

军队和警察天然的就是暴力和杀戮机关,因此要对抗对方的暴力机关,杀伤是无法避免的。然而针对没有暴力伤害能力的平民,而且特意只针对对方的平民,这还是让我们很难接受——基于同样理由,杀害投降后的战俘一样是一件不名誉的事情。当然,我说的都是近代的事情了。你要和我讨论成吉思汗当年破城后屠戮三日的事情,我只能说你是在耍流氓。

所以呢?那些举出美国对日本扔原子弹,以及賽德克巴萊例子的人。你们说的没错,这些人是毫无异议的杀人犯。他们知道这一点,而且为了种种理由,也实施了攻击平民的行为,并承担了这一后果——这点是他们和本次幕后主使的决定性差异。

不要以为不对民众动手多么神圣,在战争的时候要不对民众动手着实不大容易——尤其是有人打着游击战的时候。路旁对你笑的孩子,也许下一秒就会拿出火箭筒。这种情况下,要保证不误伤平民着实不大容易。只是打赢了,这些事情就会大事化小。即使上了军事法庭,只要没有确凿的,“只特定针对平民的”的证据,多半也不能如何。可是若打输了,这事情就会小事化大。若不宣而战,躲躲藏藏不敢以真面目示人,不是鼠辈是什么?

另外,特别提出敝政府在新疆作为的朋友——你说对了。虽然我们的政府不承认,但是他确实需要承担群体性的杀人责任。而且这不只是针对少数民族——你以为汉族情况会比较好么?错。汉族的情况多半要更糟。

把人逼疯后,就没法再坐下来好好谈了

很多电影里面,总会有个带头人物,说要让对方知道自己的民族不可轻辱,然后以少打多。当然按照剧情需要会有不同结局,一般来说不带主角光环的大部分都悲剧了。

如果是战争,这样没什么问题。但是如果是屠杀对方平民,这就是抽风了。因为屠杀平民对施行方没有直观的好处。对方的军事力量还在,而且还更痛恨你了。要产生收益,至少要做到白起坑杀赵国四十万人那样,一次性摧毁对方的生产和供给能力。按照大陆的规模,大概要几亿人吧——那会是怎样的一场惊天屠杀啊。而不产生收益,我们就只有认为你疯了。因为只有疯子,才会做一件损人损己的事情。

而一旦被打成疯子,后面就没法再坐下来谈了。没有那个政府针对这种情况还能给出承诺的。就算政府不被愤怒的民众吞掉,对方也不敢相信民众会放过他们。当彼此双方都认同到这一点时,双方除了你死我活外没有什么太好的结局。大部分情况下都是一者输了,然后胜利者安排一场结局。

所以呢?你认为我在说我们一定要坚决打击恐怖分子么?

我是在说不要随便把人逼疯。

关于美国新闻定性的反面声音

这次争论比较大的就是美国主流新闻,对恐怖分子打引号,因而被斥责为阴阳怪气。我这里收集了两个相关的反面声音,说明为什么。

by shell909090 at March 05, 2014 09:13 AM

March 03, 2014

@shell909090

昆明大屠杀

昆明火车站一伙暴徒手持砍刀无差别杀伤群众,目前已知死者29人,伤者143人。

这大概是对民众的无差别恐怖袭击首次发生在汉人密集居住区域(金水桥恐怖袭击的目标是金水桥,民众伤亡只是顺带的牺牲品。而本次的标的即为民众)。为所有无辜受难者祈福,愿伤者早日康复,死者早日安息。

这事本没什么好多说的,却有太多话要说。当然,如果我把我要说的都说出来,也许就看不到明天的太阳了。

不可对平民动武

即使在战争中,对无反抗能力的平民实行屠杀依然是反人类罪。何况这不是战争,所杀之人和行凶者并不认识。如果这样的行为都能合理化,那天下就无不可杀之人了。如果您不认同这点,而和我扯他们被受到了多么不公正的待遇——如果您是试图解释原因,我理解这点。如果您是为其合理性辩解,请尽早离开这篇文章——他不会让你高兴的。

下面是推上某文,窃以为甚为精辟。

昨天和朋友聊,要搞独立搞独立去,拿着平民砍这是种什么逻辑啊?脑子严重进水了。朋友说,你看那些对社会不满的去砍幼儿园,烧公交车的,那些不满医疗中去砍医生的,那些因为航班延误去打工作人员的,那些因为钓鱼岛去搞自己同胞的,因为奥运抢火炬而打去家乐福买东西的平民,基本上都是这个逻辑。

和金水桥事件的差异

  1. 金水桥的目标是桥,是为了形成影响。民众伤亡只是附带结果。根据wiki上的报道,攻击者在攻击之前甚至向民众鸣笛。当然其本意未必是怜悯,但是足见其标的不是人员伤亡。
  2. 昆明大屠杀的目标就是人员伤亡。攻击者从一开始,目标就是尽可能多的造成人员伤亡。
  3. 金水桥事件官方严密封锁新闻,而昆明大屠杀则并没有那么严密的限制。这种区别可能来自于官方的形象控制——昆明大屠杀更有利于官方博得同情,而金水桥则更容易牵扯出对犯罪者的怜悯。

恐怖分子的目的

你可以首先阅读这篇文章,我基本认同里面的观点,而且说的比我想的更加透彻。

简单来说,就是一群人中的一小部分人,自我定义了一个群体(例如维族,伊斯兰教徒),然后对国家中的其他群体的普通民众进行无差别的杀伤。于是社会的主流群体会对整个群体的整体产生厌恶,而不仅仅针对这一小部分人。对整体的厌恶会使得这个群体边缘化,生存条件变差,贫困,极端,从而产生更多的恐怖分子。

当这种力量足够强大的时候,甚至可以夺取国家政权。有兴趣的可以参考这篇文章

怎么看待非恐怖分子的少数民族

如果你认同“任何针对无辜平民的集体屠杀都是不可接受的”的话,那么毋须多言,显然不可能支持对少数民族的人平民实施过于激烈的政策。包括先行射击,加紧审查,种族隔离。

另一种逻辑是认同自己的种族身份。即,昆明火车站会使得我愤怒,是因为我族人受到了伤害。

个人认为这种逻辑是危险的。将不同的人划分不同种族,并且在种族之间对立和报复,其结果就是战争和流血。你们可以骂我懦夫,不过我讨厌战争,我怕死。

而且从公平论角度来说,这种逻辑不公义。如果你依此逻辑赞成对其他民族的隔离和对立,显然就没有立场指责其他国家对你的孤立和对抗。

当然,更深刻一点的理由会比较容易被当作扯淡——民族主义更容易被煽动,操纵和利用,而我最讨厌被人摆布。

现实

但是悲哀的是,恐怖主义已经得逞——我们成功的被挑起了恐惧感。这是第一次汉人密集的城市(而不是少数民族聚居区),发生的针对民众的无差别袭击。这为我们敲响了警钟。我们一直以为在党的治下,虽然防民甚严,但对于良民来说至少安全无虞。这事告诉我们,即使在你认为“安全”的地方,也会发生一些想不到的事情。

我们不知道恐怖分子的下一个目标,在地铁制造爆炸事件?在广场制造恐怖袭击?甚至伪装成快递员进入居民楼逐户屠杀。

所以,我们每个人都在恐惧。我们不知道哪些维族人是好人,哪些是坏人。我们只能盲目的把所有维族人从身边驱离,剥夺他们融入我们的可能性。我们不会去新疆饭店吃饭,不会正常的和维族人交往,甚至在街对面走来一个维族老人时面露恐惧。

于是,维族会被逼返回自己的家乡——如果他们有的话。更多的人工作艰难,更多的人无路可走。于是肯定会有人——当然多少难说——加入恐怖分子,或者至少,对抗政府。

现在的事实就是。两拨本来理性的人被一拨疯子挑拨的互相残杀——而且他们还成功了。

囚徒博弈的问题在于,即使我们都知道这样是双方都输,而有人躲在矩阵后面偷笑,我们也只能无可奈何的选择最差解。

种族是人类流血的伤疤

关于种族问题,我们可以看看最近的乌克兰,或者看看美国和基地组织。这些都是种族问题上升到国家层面的结果。实力接近的就是种族冲突,实力差的比较远的,弱势的一方几乎无可避免的就会发展出恐怖主义。恐怖主义确实是个很恐怖的东西,虽然弱势者无力给予重创,但是却屡杀不绝。强者疲于奔命,草木皆兵。

为什么

种族和宗教是人对自己身份认同的凝聚,人们总是喜欢和自己容易理解的人打交道。当你见到一个人,他喜欢吃什么,看什么电影,喜欢狗还是吃狗,疼爱妻子还是虐待老婆,你都一无所知的时候。甚至连他偷偷在下面嘀咕什么你都完全听不懂的时候。要和他顺利交际是非常费力的。随着交际圈子的发展,不同的圈子就会被打上不同的印记,不同的圈子就开始对抗。

少数民族政策

我和少数民族的交往不多,有几次是亲身经历了朋友的某些事情,其他则是偶然看到和道听途说。

目前的少数民族政策有很大倾斜,但是双方都对倾斜不满意。很多倾斜甚至只对为非做歹的人有所帮助,却会招致其他种族的不满。例如藏族。原则上藏族是可以挎刀的。可是悖论的是,藏族离开自己的土地,到西藏其他地方住旅馆,要先开上N多证明,办理N多手续。其繁琐程度远远超过汉族去西藏旅游,甚至超过汉族来上海办居住证。朋友曾私下和我抱怨,这么管法安能不招致怨恨。我深以为然。在这个前提下,藏族“挎刀”这个特权根本是个笑话。要是在汉族大街上穿藏袍挎把刀,只怕不到10分钟就有警察前来盘问。

再说让很多民警都头痛的新疆人抢劫盗窃问题吧。有兴趣可以参考一下这篇文章。里面提到一个很神奇的事情是,维族人盗窃,警察往往无可奈何只能放人,生怕和民族问题扯上任何关系。相反,若是维族人正常工作,到汉族这里来出个差,或者想旅游一番,却是困难重重。当年七五后两个月,一位新疆的朋友奉公司令去沈阳出差,从下午4点到晚上9点,硬是没有一家旅馆敢于接待。最后无可奈何,打电话回公司,硬是找了偏僻位置的公司招待所住了下来。

如此倾斜,岂不是令良民无处谋生,而歹徒如鱼得水?

结论和呼吁

  1. 恐怖分子必须死,无论其成因是什么,以杀伤平民为目标或者手段的恐怖主义是不会得到任何人的谅解的(除了傻逼)。
  2. 不要因此敌视新疆人,维族,或者穆斯林。您有自己对安全的考虑可以理解,但是请不要过激,不要牵连同样无辜的维族平民。
  3. 民族之间必须平等,民族政策的诡异倾斜应当得到纠正。
  4. 互相之间的了解和认识是消弥民族矛盾的最好方法。有功夫的话不妨认真的学习一下维族,伊斯兰教知识。

by shell909090 at March 03, 2014 07:35 AM

February 27, 2014

@shell909090

余额宝

最近我把大笔钞票转到余额宝和理财通去了。

说是大笔,其实也还好,只有五位数而已。毕竟互联网系统的安全性和保证能力摆在那里,太多钱也不放心。而且为了安全性,两家按照获利能力分别配置,都各自存了一部分。

其实这样挺好,以前这部分头寸必须在银行存活期。1W一个月利息才3-4元。目前存支付宝里,使用上和活期没有区别,一个月利息50。当然,等shibor降下来也许就没这么多了,但是30还是有的。至少翻了10倍,一顿饭的钱就出来了。何况我转过去的还不止1W。

以前之所以不敢这么做,一方面是利息不算太高,好处并不直观。但是最重要的一方面是使用上不算便利。短期头寸不像长期投资,可以有一定的赎回时间。往往这头要付信用卡呢,那头有人结婚,又刚好感冒要看个病。三方一合,没两三个月的平时开销,很可能哪里就调不过头寸来。这时候难道还出去借钱么?但是三个月日常开销一放,加上自己懒,有的时候有点资金不及时从银行调出来,往往就这么几万躺在银行里走活期利率。

现在支付宝打通了相当多的支付渠道,结婚吃饭AA交水电煤,样样可以支付宝。使用上又是T+0,所以银行里面躺个几百应付一下就行了。要是余额宝取出到银行的到帐时间是2小时以内,这几百我都不放。

好玩的事在于。我突然想到,余额宝为什么能够拥有这么高的回报?是因为银行需要高息借钱。货币基金里面很大部分钱都去了同业拆借。银行为什么需要高息借钱?因为没有足够的钱。为什么没有足够的钱?因为本来银行可以利用的低成本活期头寸都去了余额宝了。这就是通胀和通缩的放大效用。

所以从理论上说,用余额宝的人(或同类产品)越多,其利息越高。要是银行没看明白这个原理,盲目推出类似产品。推出的越多,利率抬高越多,只会把自己累死。但是看明白也没用,别人都推自己不推,只会把自己饿死。

当然,事情并没那么复杂。国家要管,只要快速调整基准利率,使其逼近同业拆借。或者大量印钞(或者回购)稳定shibor。哪种都可以废掉余额宝。鉴于印钞往往有很大范围的副作用,因此加速基准利率变动才是正道。当然,基准利率变化越快,就越接近利率市场化。而市场化的利率比恒定利率难监管的多。

另外一点就是,银行为什么拼不过支付宝?因为银行为了应付活期资金调度头寸,需要大量的准备金。准备金无法生息,无疑降低了资金的利用率,摊薄了回报。而支付宝本身的运营模式就会产生大量的沉淀资金。当资金在从买家到卖家的发货期的时候,是必然沉淀的。这部分资金产生了形同准备金的功用。

by shell909090 at February 27, 2014 02:37 AM

February 26, 2014

@khsing

作弊条:root的shell吐核时su到root

帮朋友看个FreeBSD的机器,无法su到root用户了,查了下原因是csh吐核了,所以su就失败了。用su -m root可以保持当前用户的环境变量和当前目录,幸好这个用户的shell是/bin/sh,这样切到了root。

不过这事让我注意到还有toor的用户,就是给csh挂了用的。不过这帐号默认也用不得,得改个密码不说还只能在console用。

by Guixing at February 26, 2014 12:56 PM

February 19, 2014

@shell909090

利用cgroups隔离多个进程资源消耗的尝试

setup

Add to /etc/fstab.

cgroup                  /sys/fs/cgroup  cgroup  defaults        0       2

Then sudo mount -a.

Change directory to /sys/fs/cgroup/. Use mkdir to create a new group, and initalize it like those.

echo 0-3 >> cpuset.cpus
echo 0 > cpuset.mems

Without those two step, next operator will failure.

echo 0 > memory.swappiness
echo 52428800 > memory.limit_in_bytes

Set memory limit 50M, and forbidden swap.

python test code

import os, sys, time, random, string
def main():
    l = []
    random.seed()
    raw_input()
    for i in xrange(1000000):
        for j in xrange(1000):
            t = list(string.letters)
            random.shuffle(t)
            s = ''.join(t)
            l.append(s)
        time.sleep(0.01)

if __name__ == '__main__': main()

Finally, it triggered OOM.

by shell909090 at February 19, 2014 02:14 AM

February 17, 2014

@khsing

2012 Summary

1月5号了,我来总结一下我的2012年,先看看去年定下的这几个事儿。

  • 继续和拖沓症作战:拖沓的差了些了,继续努力。
  • 利用业余时间把自己的小项目搞出个眉目来:只是非常简单的做了一个iOS的app,有了一些新的想法。
  • 出国旅游一次:年底的时候和老婆去了一趟马尔代夫,感觉非常不错。
  • 考一次雅思,争取到6分:这个确实没能去做,还是觉的差太多,而且英文的学习上今年也不是很有进步。
  • 每2个月读1本书,其中1/3要是英文的:读了5本书,其中1本是英文的,在读的有一本,还要努力。
  • 拼RP,买车:拼到现在,RP也没有爆发,6月的时候着急买了一个2003年的别克老君威,开了半年下来感觉还行,就是油太贵。

工作上2012年我觉的相对来说还是有些失意的,在4月的时候跳槽做了lead,不过在11月的时候就又离开了,这半年感触颇深,虽然也做成了些事情,但是总的来说是非常不如意的,这经历很是珍贵。

家庭方面,终于是把父母接到了离北京比较近的河北香河,老家也经历了拆迁的风波,贵国的政府真是一个模子刻出来的。在为人父母方面我还要多多的努力,多些耐心。

年底的时候FIT的作者冯华君因病去世了,才31岁,天妒英才啊。我和华君只在gTalk上有聊过,感觉甚好,但一直未能见面,没想到的是他竟如此早的去另一个世界了。关注身体健康,别再延续IT人短命的恶谶了。

总结2012年,我对自己不是很满意。

2013年,我还是列个单子。

  • 提高效率,充分利用时间。GReader和twitter的时间有点多了,要克制。
  • 多读书,理想情况下1个月读1本,至少8本。
  • 自己的几个产品想法至少实现一个。
  • 继续学习英语。
  • 耐心的做一个好爸爸。

by Guixing at February 17, 2014 08:53 AM

February 14, 2014

@shell909090

长白山旅游——第四天

今天纯滑雪,就是滑雪,只滑雪。

从10点不到一点进场,到下午两点20离场,大约滑了4个半小时,没吃午饭,也不觉得饿。这次总计滑了有七个半小时,换成银七星的价码大约要600多了。可惜银七星三年多了还在装修不开门。。。

下面我简单说一下滑雪的注意事项吧。

不要以为有教练就没事了,自己的安全自己小心

晚上回上海的时候,看到一个小孩坐着轮椅回去。一问,滑雪时撞防护栏结果小腿骨折了。天冷也不显肿胀,家长小心,拉到抚松去照了一下X光确定是骨折了。要没确定硬用力,大概就会移位了。

问题是,这倒霉孩子当时还是教练跟着的。

所以不要以为有教练就万事大吉了,也不要以为滑雪是很安全的运动没事的。滑雪确实比溜冰安全多了也舒服多了。溜冰的时候一跤摔倒屁股痛半天爬不起来,滑雪就算摔倒也是软软的,不怎么痛。可就是这种认识容易出事。去溜冰的,技术不高的速度放的都很慢,小心翼翼的滑。滑雪的往往觉得会了点就开始加速,而且最要命的是,溜冰不主动用力就不会加速。滑雪相反,不主动减速就一直在加速。没控制好的当场摔了算好事。控制的住的加速到几十公里的速度撞上什么东西——你看看人家舒马赫。

反正我和保安聊的时候,他们说已经见惯了。蹦蹦跳跳过来坐着轮椅回去。至于手摔伤什么的更是常见。贝壳自己会摔的,只摔了一次,拉伤肩膀肌肉,到现在后脖根还有点不舒服。滑雪中心的工作人员态度则更加严谨,头盔带好才让借雪具。不戴头盔禁止入场。

滑雪的几个注意事项

首先是刹车,不会刹车的禁止到有坡度的道上练习。我们那个场地有个很平缓的坡道,很适合初学者试刹车。

刹车的时候,两个脚内八,膝盖向内脚跟外撇。可是很多人很奇怪,我内八了阿,为啥还是刹不住。

看过滑雪的都知道,左右之字转向可以减速。所以实际上把雪板横过来就可以刹车了。但是副作用就是会转向。如果不想转向的,两个脚就需要分别向两个方向横。理论上外八也是可以刹车的,但是如果下坡外八,你需要很强的力量将向外分的两个雪板拉回来,否则就要八字开。拉回来的时候又要注意中心,不要大头向坡下摔倒(翻跟头)。所以一般都是内八刹车,这时膝盖顶在一起,人的体重自然变成向外的力量分开雪板。外八刹车一般常见于倒滑(是的,就是教练顶住你时候的姿势)。我曾见一个教练顶住一个人的力量,后面又撞了一个上来,照样顶住(三个人的体重加一个人的冲力)。所以方法正确的话,刹车很可靠。

刹车的核心在于内侧(两脚中间)的雪板比外侧低。如果你内八了,但是两脚还是平行的,那是刹不住的。

这事情的悲剧在于,无论别人怎么说,都很难一次搞懂。一般都是要摔个一两次才能学会。

所以第二个要点就是摔跤。

首先,控制不住就直接立刻往地上一躺,不要等加速到顶点再撞防护栏。我在坐牵引的时候,亲眼看到一个妹子控制不住,眼睁睁的冲撞到防护栏上。左脚雪板直接插入防护网内,人被以左脚为轴整个甩飞出去。医务工作者当时就跑过去了。下到底再上去的时候,看到妹子的老公扶着,基本确定左脚大腿脱环了。这已经算是幸运的了,想想上面那个撞护栏撞的腿骨折的孩子。

其次,摔跤最好的姿势,是侧摔。向前倾会加速,向后会变成狗拉爬犁(初学者区域满地都是爬犁往下滑)。一般来说最差的姿势是向后——因为除了坚持到底你什么都不能做。向前的还可以试试转向或者侧摔。

侧摔第一个要点,是头朝坡顶,两个雪板垂直于坡度降线。这样会减低你的速度,使得你不继续加速。而且万一有碰撞,也是先撞雪板再撞脚,保护你的头部。

然后其实就没什么要点了,护住头脸往地上一躺,没意外的都会直接停在坡上。贝壳唯一一次摔倒就是侧摔。由于速度没控制好,眼看要撞防护栏了,知道撞不得。强行转向失败,侧摔摔倒。整个人在地上转了两圈才停下来,雪板还在脚上,肩膀有点拉伤,但是没有其他损伤。手一撑起身就滑出去了(当天下坡20多次,也累了)。

但是摔跤的重点在于摔完后——你需要很快的用雪杖顶一下你雪板上的锁,脱下雪板,然后尽快跑到雪道边缘。一来是礼貌,给后面的人让出路。其次你也不知道上面下来的人会还是不会。万一他一受惊吓撞到你——这次可是他的雪板撞你的脑袋了。

其次是脱雪板的方式。很多人摔了之后硬往起站,起来一看脚成180度了(我看到个妹子脚是270度的,柔韧性真好)。正解是上半身着地,脚肯定能够笔直向天。然后旋转到两个雪板平行,再顺着放到地面上。然后肯定能脱下雪板。

另外摔跤了严禁脱下头盔!最忌讳的,就是在雪道中间不脱雪板半天爬不起来,或者傻站着。这个万一被撞了纯粹活该。

牵引道的注意事项

牵引道上的正确姿势,是用一根雪杖往前顶住,一根向后顶住,支撑上半身。然后雪板分开,平行向前,人重心向前,倾斜站住。

为什么?如果你脚不够分开,一旦左右晃动就容易摔出去。而牵引道一旦摔出去就要停下,这时候会突然刹车,没有向前撑住上半身的就要靠小腿的力量了。更悲剧的是,牵引道如果上的人太多,过载会停下不说,而且上面会留下雪水。在被环境一冻就成冰。如果你踩到冰上,雪板是挂不住的,人就会向下滑。万一一滑就变成保龄球了,这个就是个大事故了。所以用一根雪杖向后支撑住以防万一。

另外出牵引道口一定要赶快跑。因为前面的人不走,后面的人什么都做不了,只有从后面贴上去,姿势很尴尬的。贝壳两次被贴成了小龙虾串(虽然前面是妹子,后面可是汉子。。。)。当然,真会的人可以从出口直接跳出去——不过那也是技术到家才行。同理,为了避免这种情况,牵引道上两个人需要间隔一定距离。

雪具和穿戴

雪具其实没啥好多说的。衣服裤子不应该算雪具,自备也可以。当然,要透气(否则运动上去后很闷),保温(否则有的时候牵引很慢,滑雪时间偏短,人会很冷),而且万一摔倒整个衣服被雪水打湿还要自己处理。所以一般都会租借服装。头盔有就穿,没有的话就算了,问题不是特别大。因为头盔主要是防止翻跟头和摔倒后后面的人撞你,作为一个老手这两种情况都不常见,如果是新手最好戴上。

雪具基本只有三样,鞋子,雪板,雪杖。注意我说的都是双板。玩单板的都是老手了,也不用我废话。

鞋子是特制的,基本把脚的运动方向限制死了。穿着鞋子是不能踮脚的。鞋子最好穿紧一点,这样控制雪板容易一点,不会有太大晃动。注意,是穿紧一点,不是让你弄双小鞋来穿。

穿的时候,脚尖插进去,用力把鞋舌往前拉,脚就能钻进去。鞋子上一般都是扣锁,两边的一搭,反向一扳就能锁住。这两个动作自己要发力都不容易,所以最好别人来帮忙。如果要自己来的话,有个比较简单的方法。一般搭扣都是两个,可以先把其中一个扣住一格,锁住。这样鞋子两边就会被这个扣锁拉紧,你就可以从容的扣另一个。然后再把原来那个锁紧一两格。

最后,专门裤子的裤脚管往往是内外两层,内层是穿到鞋子里,外层罩在外面,拉上拉链扣好。

雪板两只,注意是有手向的。先把后脚跟的扣锁按下去。然后脚尖点进雪板脚尖的卡锁里面,后脚跟对准一踩。后脚跟的扣锁就会弹起来,前后的卡锁都会和雪板卡住,整个人就锁在雪板上不会动了。这就对了。

脱雪板的时候,用手或者雪杖点一下后脚跟的扣锁,整个脚就脱出来了。

注意在坡上重新上雪板的时候,雪板要垂直于坡度降线。如果雪板平行于降线,人还没上去呢就会向下滑。就算能用脚控制住滑动,也很难穿上。或者人好容易上去一只脚,往下滑了,这更悲剧。

by shell909090 at February 14, 2014 09:50 AM

February 11, 2014

@shell909090

长白山旅游——第三天

今天去长白山天池玩,总的来说比较坑爹。

早上跑出来,大概要开两个小时。路程还好,不好的是,导游居然连续说了两个小时的东北特产。。。

最后还特意强调了一下天池的寒冷,我大概猜到后面会拉我们去租衣服。果然,景区外一个租衣服的点。我租了双鞋子,万一上面雪进鞋子里面,也不会让我没得穿。至于大衣邦腿,去你妈的吧。另外我特别说明一点——山上租衣服的和山下的价格一样,都是50。

今天人太多,你们先去看冰瀑布吧

进长白山公园,坐上大巴,我们本来以为是先去天池的。结果司机告诉我们,天池人太多,公园自动分流,你们先得去看瀑布。

瀑布就瀑布吧。下车我一眼看去——啥都没看见。最后看半天,在一堆冰柱子中间看到一条细细的瀑布。看看手里55mm的头,算了,来都来了,还是照吧。

往前走个一公里,到了一个观景台。这个观景台很有特色——他的地板是斜的。准确的说,雪在一边堆积的高,一边堆积的低,于是站上面就会不由自主的往下滑。。。

再往前是一堆温泉泉眼,在漫山白雪间,有一条清澈的小溪流过,而且上面烟雾蒸腾。不过昨天见识了雪乡温泉,这个就有点见怪不怪了。旁边有温泉水煮蛋可以吃。蛋黄几乎凝结,蛋白还是软的。轻轻一吸,蛋黄就到了嘴里。总体来说,味道还不错。

车的情况不确定,能坐就坐吧

下山的时候,我们坐了一辆中巴。结果不知为啥,理论上必须坐下的山路站了两个人。这还没啥,下午的时候,调度给我们派上了车又给我们拽下来让上另外一辆,原因未知。下午的时候有三辆车不发让我们等了10分钟坐一辆有人的车。更夸张的是上面还有个伤员——想也知道,摔的呗。

车的情况简单来说只有两个字——混乱。

见识到了比学校还难吃的午餐

吐槽完了交通来吐槽一下午餐吧,我终于吃到了比学校还难吃的伙食。

我们到的时候,自助餐还没开始准备。所以我拿到的头几分餐食都是凉的。酸菜没酸味,洋葱没洋葱味,肉没肉味。猫咪好歹帮我拿了一份热一点的汤和鱼来,结果鱼还不够入味。不是说东北菜都口味比较重么?这厨师是广东来的吧。

这是唯一一次不需要导游催促的集合——我估计大部分人宁可早点玩好了回去吃点别的。

由于天气情况随时变化,所以猎豹的钱没算在行程里

下午要上天池了,导游告诉我们,上山坐的猎豹的钱没算在行程里面,所以要自负。虽然我估计如果我现在去找,大概有无数地方会写着这个注意事项。可是无论是喵还是我事先都没留意到这点。

来都来了,洗干净脖子吧。

都说师傅的车比较猛,实际上和朱哥的车比起来天上地下。不说扎村乃村,就是珠峰十八道拐就足够甩掉这条路。除了过弯速度比较快,车的扭矩比较大之外,其余没啥好多说。

这边是中国,那边是朝鲜

上天池看了一眼,没想像中好看。想像中一汪碧水,结果现在千里冰封,上面全是雪。下面到底是个池子还是个阿里郎表演场或者根本是个足球场,完全看不清,统统一片白。而且说到雪山的雄伟壮丽,和西藏比起来差很远。不过这里倒是有几点好处。

  1. 中朝边境。我想大部分人都无缘见识朝鲜的土地,现在给你见识见识。
  2. 周围没有其他的高山,于是有种一览众山小的快感——大概就跟区重点里面年级考试前十差不多。

最后关于冷。确实是很冷。可是主要是冻脸和手指头,护膝大衣不顶事。而且穿的不是太薄的,你忍个一刻钟该照的照完是没问题的。照不完的,我想你的问题不是一条棉衣能解决的。至于还考虑到经常受冷可能以后会留下隐患——你是打算镇守祖国的边疆呢吧。

终于赶上了博物馆,可为什么是闪电

晚上我们送一批人去泡温泉,其余人去博物馆。平时博物馆是5点下班,可8号正常上班,4点关门。至于为什么正常上班的结束时间和平时不一样——不知道。

其实我也不大紧张。导游都讲了两个小时了,就指望这次的购物呢。我还没见过购物点会提前关门的。

果然,到了之后没关门。但是神奇的事情发生了。讲解员以迅雷不及掩耳盗铃之势开始讲解,语速之快连郭德纲也要自愧不如。贝壳的中文阅读能力一直很出色,可是这次完全没有发挥余地。要跟上讲解员的节奏需要的不是阅读速度,而是奔跑速度。

直到出来的时候,贝壳还是满耳朵的——东北有三宝,blahblah和blah。东北新三宝,blahblah和blah。他们能够blahblah和blah,对你很有好处。最倒霉的是,讲解员说的和导游还不一样,结果我一个没记住。在购物点终于迎来了四五个满脸兴奋的导购员,可是他们面前的是一群一脸茫然的大人和小孩。想当然,这次购物点的收银员甚至没捞到出场机会。

上车看到导游一脸不爽的样子。这个你们自己沟通去吧。

开还是不开,你猜

晚饭吃的是汉拿山韩式烤肉。照例说应该挺高级的一家馆子,没想到意外的物美价廉。

——换个说法,就是坑爹。东西倒是不错,服务员严重不足。

我们吃了一个牛肉拼盘,上面写着四种肉任选两种,可是直到吃完服务员也没空问我们要哪两种组合。不过还好,他们总算在我们结帐要走人的前夕把我们一开始要的热水给送来了。

还有牛板筋金针菇什么的。上菜速度挺快的,10多分钟就上来了,连送碳火的服务员都没来得及反应呢。我其实最后没吃饱想加两道,人来了话到嘴边改成了——服务员,买单,结帐。

然后往前走走,散个步,到雪圈公园那里打车回来。不走没事,一走一肚子气。今天雪圈公园居然开了。可是因为我们在烤肉花了太长时间,只开半个小时了。问题是,租雪圈一律30。。。

妈的,明天还是继续滑雪吧。

by shell909090 at February 11, 2014 02:37 AM

February 10, 2014

@shell909090

长白山旅游——第二天

下雪道22次无事,最后一次破功

今天早上一出门,我们就去滑雪。滑雪中心人很多,排队排半天。9点出门,折腾到10点才换好装备。

以前贝壳只在银七星滑过两三次,只会简单的下坡,刹车。而且还不保证每次都能顺利下坡。唯一值得自傲的,大概只有摔跤技术(喂)。大家知道银七星一场只有一个半小时,摔个几次基本就没了。

出了门,暂时有点不适应。前两次滑的比较小心,也比较消耗体力。后面就越滑越快越顺利。到后来,基本大部分时间都在牵引道上。基本每次下坡都能控制速度和方向,正正好好停在牵引道的入口,省去无效的时间。

猫咪滑的也不错,开始的时候撞牵引道摔了一次,但是后来滑的还很顺。就是体力不怎么好,滑到中午12点左右就没体力先回去了。

至于贝壳,保持了连续22次下坡到底无事故的记录。最后一次想了想,既然能控制方向了,试试左右转弯保持速度?结果一个弯没转过来——要撞防护栏了。所以只能中心偏移大一点,然后就摔了。

看看表,已经下午一点了,索性不滑了,回去吃饭去。

从索道上下山很省事

上楼找到猫咪,我们从索道上山观光。这个索道其实直通几个特级下山雪道。只是如果换我们下,雪道就会变成血道了。。。

这里的索道设计很有趣。坐出租到小镇要10元。坐索道不要钱(是的,无论多少次都不要钱),上山观光再坐另一根索道下山也可以到小镇。时间上也没长多少,还能顺道去山上观光一下。唯一的缺点是晚上不开放。

老北京火锅味道不错

老北京火锅是整个小镇点评有评价的餐厅里,唯一没被人猛吐槽的。今天试了试,果然不错。220元吃了精品牛肉,牛舌,牛肉丸,墨鱼,手擀面,金针菇,冻豆腐。两个人都能吃饱。

不过牛肉的费瘦分层很奇怪,而且肥肉一下水就消失了,我怀疑是注脂肪做的。牛肉丸淀粉含量太高,几乎没有牛肉味道。而且服务员给我们下错了单,一份手擀面出了两份。要不是我顺口问了一句,估计就付两份钱了。

不得不说,整个小镇里面的餐饮业很奇怪。有当地特色的餐饮价格比上海还高(你见过100元两位的饺子么?我们还只点了凉菜!),价格平易近人的味道就有点勉强。只有肯德基和麦当劳等快餐连锁还保持了一贯的价格和品质。

温泉一般,只是毛巾受到追抢,而且更衣室里面有人吸烟

吃过火锅,我们去泡温泉。这里的温泉很有趣,是开在雪地里的。人在里面泡温泉,一伸手就能摸到雪。

听起来很好,不错实际上有点问题——浴巾没货。不带浴巾出门试试?以贝壳的体质尚且觉得冷爆了。泡到温泉里面觉得暖和,只要上岸统统皮抖抖。即使雪再近也要站起来一伸手么——啊,好冷好冷——差不多是这个样子。

我们一起泡的一个池里面有对情侣在照相,妹子在那里说,我站起来咯。三二一。然后男生喀嚓喀嚓三张。整个过程不超过10秒——超过估计就能看到妹子的颤抖了。

另一个池里,有一对情侣在讨论什么东西。不过两个人在温泉池里面——吸烟??!!怎么点着的?啊不对,怎么把烟带进来的?不会是放在。咳咳,问点重点的吧。烟灰缸呢。。。说着妹子烟头上掉下一截。。。

贝壳回去后(你们知道为什么),毛巾终于到货了。在短短的半分钟内又被争抢一空,然后就是屋外人数爆增。不知道他们是不是看到了贝壳刚刚看到的东西。

所以,这种噱头听起来很有趣,实际么——就要看执行的情况了。

而且就算是擦干回去的时候,我也找不到毛巾。问了一下服务员。服务员先问了我是出去还是穿衣服。我说穿衣服。服务员从一个隐蔽的地方给了我一条小毛巾——好吧,看来他们因为没毛巾让顾客穿衣服出门被骂过。

擦干到了更衣室。我去,有个大叔在吸烟。虽然说一头白发慢慢吞云吐雾看起来是挺帅的。可是我说大叔——您能不能换一包不怎么呛的烟。那个味道我在洗澡的地方都能闻到。至于服务员——大概是去解决毛巾问题了。

哪个混蛋说的晚上雪圈乐园也开门的?

老婆问了一下,据不知道哪个混蛋(她现在自己都不记得了,不过坚持说不是自己的妄想)说,雪上乐园晚上开门到10点。

开你妹啊。我们好容易走过去。发现门口一条告示——不开门。然后只能后天起早去玩了。

然后就是更坑爹的RPG时间。我们的套餐里面包括看一场表演(表演细节后表)。所以我们就致电剧院预约。剧院说现在都6点了,表演7点半开始。直接来吧不用预约了好位置都有。我们很开心的走了过去(从乐园到剧院,对穿整个小镇,大约300-500米雪地。其实剧院就在刚刚的温泉旁边,我们刚刚走过去),结果剧院说,不好意思。如果你们订的是春秋的套票,需要在哪里哪里拿票,然后到我这里换座位。

哦,好,春秋的那家店在哪?

雪圈公园旁边。。。

好,于是贝壳和猫咪就走回刚刚的地方(这是第三次从这条路上走过了),拿到了彩虹的水滴。啊呸,是拿到了票。然后再走回剧院(第四次),换了票,出门吃饭。

小鸡炖蘑菇和猪肉酸菜水饺

不要误会,小鸡没有炖猪肉酸菜水饺。

晚饭本来是去炖锅吃的。结果猫咪喜欢的一锅炖没有。而且只有那个便宜,188。剩下都是2XX,3XX,4XX这种节奏。而且XX你们明白。要是加上我每天单程公交车钱,就会进位。。。

所以我被猫咪拽出来了。

商量了一下,还是去昨天的小吃街吧。那里的水饺看起来便宜很多。

果然便宜很多。24个水饺半斤,猪肉酸菜,只要12。价格只有山珍水饺的一半,量大一倍。可是自古说了,便宜没好货。难吃程度果然也是成正比的。幸好小鸡炖蘑菇味道相当鲜美。我们花了50多点就吃了一顿不错的晚餐。下次点个好点的水饺也许就能感受到高性价比的优势了。

我们看了一场奇葩的表演

晚上这场表演是最值得吐槽的了。风格有点像我们在成都看的川剧变脸传奇,但是更加奇葩一些。

首先是一个采参人,跌入时空隧道,穿越回了——大清朝?

又穿越,你们打算把大清朝的所有阿哥都配上现代女汉子么?我本以为这已经够奇葩了,谁知道只是个开始。

第二幕,一群穿着溜冰鞋(不是直排,就是人民广场卖玩具的小贩经常滑来滑去那种)的大臣和一群让皇帝痛不欲生的妃子在那里跳舞。由于角度关系,皇帝的脸一直看不清。等皇帝终于走了出来,没10秒,就被一个人参娃娃给吓跑了。

所以说不要以为皇帝一定就是主角,你看看甄嬛传,再看看杨家将,再看看水浒,再看看末代皇帝——不好意思搞错了。这个真是主角,但是不是皇上了。

后面更奇葩的事出现了。采参人跟着人参娃娃跑——结果丫变成了个美丽的仙子。你是想说源氏物语还是说采参人变成了萝莉控?

反正结果就是仙子和屌丝——啊不对,仙子和萝莉控——啊呸,仙子和采参人陷入了热恋。但是一个奇怪的妖怪看上了采参人(这年头有本事的都爱屌丝)。于是用毒药迷惑了采参人(啥玩意那么好使,哪买的?),还把仙子给冰进了冰山里面。

我擦,有本事的人怎么都会陷入奇怪的麻烦。是不是都等着被一个无名小卒救了然后说你骨骼清奇是万中无一的奇才,跟着我学做菜吧。你看看D2里面的大天使,能锤碎世界之石却被一条虫子困住了。主角还在菜鸟的时候干掉了这条虫子救出了大天使,可是到最后都没能锤碎世界之石。

后面更奇怪的东西出来了——变脸?收回我刚刚说的话。这个不是有点像川剧变脸传奇,这根本就是。这是川剧还是东北二人转?我刚这么说着,两个人推着一个像健身用的大呼啦圈一样的东西缓缓出场。。。

到后面八个饺子妖出场的时候,我已经完全不惊讶了。

结局还是很不错的,屌丝——啊不对,采参人用鲜血唤醒了女主角。于是女主叫召唤世界之石还不知道是什么玩意把男主复活成了——一颗人参。于是两颗人参就快乐的生活在了一起。

但是,天啊,我终于知道为什么进门的大厅里面那么奇怪的放着两锅人参汤了。。。那两个主角养老的地方不会就是在。。。

好吧,不要在意这些细节。

by shell909090 at February 10, 2014 02:49 AM

February 06, 2014

@shell909090

长白山旅游——第一天

这次去长白山旅游,是坐春秋的航班,从上海经停大连到白山机场。照例,是没有航空餐供应的。

长白山这里离朝鲜很近(好像在朝鲜被称作白头山,是金家的诞生地),从飞机上看下去全是白茫茫的雪。白山机场很小,从停机坪下去就是一个小小的转盘。转盘出去就是机场了。

气温没有想像中那么可怕,即使是夜晚,穿一件衬衫,一件毛衣,一件大衣,身上一点都不冷。在室外只要注意细节保暖(耳朵,手指,各种穿戴中间露出的部分),其他都不是什么问题。

镇子上的东西价格参差不齐。山珍水饺,两盘水饺(12个一盘),两盘凉菜要价100。另一边的小吃街,水饺只有30上下,却有24个的量。价格基本差上一倍。我们要了份羊汤,20,份量不错,味道一般。

不过小吃街实在是坑爹了点,说是一条街,实际上这条街全是银行。小吃只有街口的两家店面,每家里面有四五个小摊位上面在卖各种吃的。人很少,人气不足。当然,也可能是夜晚的原因。

而且这里的餐厅都很奇怪。菜异常的少,或者菜谱异常简单(好像东北都是这个风格)。山珍饺子菜谱上只有两页,一页写着饺子一页写着酒,中间稀稀拉拉几个凉菜。好像除了本店主打你们只要喝酒就好了的样子。另一家黄上煌则是四五页,开头几页都是XX锅,后面几页把前面的锅拼起来,然后一页酒,最后推荐多人套餐(就是把拼锅打包了卖)。小吃到还可以理解,每个小吃摊位上都是几样东西,不会太多的。

往前走能看到一条雪道。夜间看到的雪道很吓人,30-45度的坡度,大约每80米一个弯。以我的水平就这么往下滑,有没有拐弯真是一个困难的选择呢。有拐弯的地方当场撞到送医,没拐弯的地方接着往下滚,到山下一团雪人去送医。

回来才发现,那是特级雪道。我们明天大概就是在滑雪场里面简单滑一下初级就得了。

by shell909090 at February 06, 2014 10:50 PM

February 02, 2014

@khsing

从iOS7到iOS6.1.x的蛋疼

手贱的把自己的iPhone4更新到了iOS7,介于水果的一贯作风,估计iPhone4是无法承受iOS7之重,当然这不是重点,重点是我想把他给降回来了。在升级之前我还专门的去看了看自己备份的shsh,并且确认了使用ifaith 1.5.9是可以恢复回来的。刷上去是真的简单,就是确实有些慢,降回来吧,用ifaith降回来了,之后发现,回是回来了,但是中文输入法是怎么也打不开,表现为app挂掉,妈蛋啊!试了多次,发现ifaith每一次build出来的ipfw文件并不一致(MD5不一致),再也不相信爱情了。现在觉的iPhone4跑iOS7也还好。

接下来是重点了,此事表明,我们做备份,不光要验证恢复,还要做回归测试。

2014/01/17 update: 还是撤回到了6.1.3,iOS7在iPhone4上还是作死,输入法的问题已经用JB后的百度来解决了

by Guixing at February 02, 2014 05:08 AM

January 28, 2014

@shell909090

google authenticator的特性

算法

  1. 双方预先共享一对密码。
  2. 时间对30秒求整,用密码unbase64后HMAC签署。
  3. 如果当前时间前后一定时间内(几个误差)的值和用户提供值一致,就验证通过。

攻击者获得了数个时间和序列对,但是根据HMAC特性,他无法反向出密码。

因此

  1. gauth不需要联网。但是双方时间必须同步。
  2. gauth的优势在于,即使有人可以获得一次密码(例如keylogger),只要不在1分30秒内登录,获得的输入就无法使用。
  3. 对于可以取得gauth共享密码的人,gauth不能提供安全性加强。例如sudo,验证的是自己的身份。而用户密码只要登录即可读,因此没有提供加强的安全性。
  4. 对于ssh,在登录后也可以获得密码。因此只要给别人获得了一次登录权限,后续gauth不能保护你。反之,如果能保证对方一次登录都不会成功,则可以作为辅助。因此用于ssh上必须加上一个token只能使用一次,以确保对方获得了token也是作废的。
  5. 如果有人可以从手机中读取应用的信息,就可以一直冒充用户。因此越狱和root肯定会降低系统安全性。这就是为什么很多TOTP使用硬件来做这个事情。系统单纯,而且没有读取API。
  6. 缓慢的重试,每次命中概率都是1/1000000。持续试1000000次,也不能肯定猜中。实际上只有63.2%的概率猜中。如果30秒内连续重试1000000次,肯定破解了。合每秒重试3万多次,不算多。所以必须防止暴力破解。
  7. 如果没有紧急密码,安全性大约是20bit。但是数个紧急密码为破解提供了帮助。因此紧急密码一般是7位数字,综合复杂度一般评估为20bit上下。
  8. 以复杂度而言,不足以作为身份验证工具,只能作为身份验证辅助。所以gauth叫做two-factor-authentication。

by shell909090 at January 28, 2014 05:08 AM

January 24, 2014

@shell909090

openvpn auth with google authentication

client config

# base config
client
dev tun
proto udp
remote 192.168.1.122 1194
nobind
user nobody
group nogroup
persist-key
persist-tun
mute-replay-warnings
comp-lzo

# authentication config
ca ca.crt
cert shell.crt
key shell.key
ns-cert-type server
tls-auth ta.key 1
auth-user-pass

Group should be nogroup, not nobody in debian.

auth-user-pass is needed for google auth.

pam config

account [success=2 new_authtok_reqd=done default=ignore]    pam_unix.so
account [success=1 new_authtok_reqd=done default=ignore]    pam_winbind.so
account requisite           pam_deny.so
account required            pam_permit.so
auth required pam_google_authenticator.so

In /etc/pam.d/openvpn.

server config

# base config
port 1194
proto udp
dev tun
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
log-append  openvpn.log

# authentication config
ca ca.crt
cert server.crt
key server.key
dh dh2048.pem
tls-auth ta.key 0
plugin /usr/lib/openvpn/openvpn-plugin-auth-pam.so openvpn

# network config
server 10.55.66.0 255.255.255.0
ifconfig-pool-persist ipp.txt
client-to-client
duplicate-cn

Plugin should be /usr/lib/openvpn/openvpn-plugin-auth-pam.so in debian, “openvpn” behind is fit for the filename in /etc/pam.d/openvpn.

google authentication config

Look at this 在PAM中使用google authentication.

startup

shell@debws0:~$ sudo openvpn --config shell.conf
Fri Jan 24 11:17:17 2014 OpenVPN 2.3.2 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [eurephia] [MH] [IPv6] built on Nov 28 2013
Enter Auth Username:username
Enter Auth Password:
Enter Private Key Password:

The user you used to config google authentication is the username put into Auth Username.

Put verification code as Password, and you may have Private Key Password in your private key.

Have a fun.

by shell909090 at January 24, 2014 04:33 AM

January 23, 2014

@shell909090

lxc和virtualbox和物理机的简单性能测试和对比

说明

测试各种虚拟化系统下的虚拟机性能。

测试使用sysbench。

CPU采用如下指令测试。

sysbench --test=cpu --num-threads=2 --cpu-max-prime=50000 run

文件IO采用如下指令测试。

sysbench --test=fileio --file-total-size=10G prepare
sysbench --test=fileio --file-total-size=10G --file-test-mode=rndrw --init-rng=on --max-time=300 --max-requests=0 run

内存采用如下指令测试。

sysbench --test=memory --num-threads=2 --memory-access-mode=seq run
sysbench --test=memory --num-threads=2 --memory-access-mode=rnd run

线程采用如下指令。

sysbench --test=threads --num-threads=2 run
sysbench --test=mutex --num-threads=2 --mutex-locks=1000000 run

裸硬盘测试采用如下指令。

hdparm -tT <dev>

物理机上有三个文件系统,ext4/xfs/btrfs,前两者仅做fileio测试以对比性能。

另外做两个特殊文件系统对比,aufs带复制和aufs无复制。前者在只读层上准备好测试文件,而后进行随机读写测试。其中就附带了文件复制开销。后者在aufs建立后初始化测试文件,因此消除了文件复制开销。

所有测试都是测试数次,取最高者(因为低者可能受到各种干扰)。一般是2-3次。

物理机是一台DELL Intel 64位桌面系统,支持硬件虚拟化,有4G内存。系统采用debian jessie,测试于2014年1月17日-20日执行,内核3.12.6-2 (2013-12-29) x86_64。

虚拟机lxc是使用lxc切分的一台虚拟机,没有做资源限制。

虚拟机vbox是使用virtualbox切分的一台虚拟机,分配了所有CPU,打开了硬件虚拟化,分配了1G内存。

文件系统

ext4

Operations performed: 21311 Read, 14207 Write, 45440 Other = 80958 Total Read 332.98Mb Written 221.98Mb Total transferred 554.97Mb (1.8499Mb/sec) 118.39 Requests/sec executed

Test execution summary: total time: 300.0044s total number of events: 35518 total time taken by event execution: 168.4761 per-request statistics: min: 0.00ms avg: 4.74ms max: 118.67ms approx. 95 percentile: 12.48ms

Threads fairness: events (avg/stddev): 35518.0000/0.00 execution time (avg/stddev): 168.4761/0.00

xfs

Operations performed: 20789 Read, 13859 Write, 44288 Other = 78936 Total Read 324.83Mb Written 216.55Mb Total transferred 541.38Mb (1.8046Mb/sec) 115.49 Requests/sec executed

Test execution summary: total time: 300.0018s total number of events: 34648 total time taken by event execution: 172.0475 per-request statistics: min: 0.00ms avg: 4.97ms max: 96.11ms approx. 95 percentile: 12.30ms

Threads fairness: events (avg/stddev): 34648.0000/0.00 execution time (avg/stddev): 172.0475/0.00

btrfs

Operations performed: 6180 Read, 4120 Write, 13105 Other = 23405 Total Read 96.562Mb Written 64.375Mb Total transferred 160.94Mb (549.23Kb/sec) 34.33 Requests/sec executed

Test execution summary: total time: 300.0556s total number of events: 10300 total time taken by event execution: 65.8914 per-request statistics: min: 0.00ms avg: 6.40ms max: 337.28ms approx. 95 percentile: 17.01ms

Threads fairness: events (avg/stddev): 10300.0000/0.00 execution time (avg/stddev): 65.8914/0.00

aufs透明

Operations performed: 5340 Read, 3560 Write, 11279 Other = 20179 Total Read 83.438Mb Written 55.625Mb Total transferred 139.06Mb (474.65Kb/sec) 29.67 Requests/sec executed

Test execution summary: total time: 300.0084s total number of events: 8900 total time taken by event execution: 32.3634 per-request statistics: min: 0.00ms avg: 3.64ms max: 1037.04ms approx. 95 percentile: 0.02ms

Threads fairness: events (avg/stddev): 8900.0000/0.00 execution time (avg/stddev): 32.3634/0.00

aufs非透明

Operations performed: 20320 Read, 13546 Write, 43264 Other = 77130 Total Read 317.5Mb Written 211.66Mb Total transferred 529.16Mb (1.7638Mb/sec) 112.88 Requests/sec executed

Test execution summary: total time: 300.0054s total number of events: 33866 total time taken by event execution: 170.7252 per-request statistics: min: 0.00ms avg: 5.04ms max: 143.86ms approx. 95 percentile: 12.62ms

Threads fairness: events (avg/stddev): 33866.0000/0.00 execution time (avg/stddev): 170.7252/0.00

物理机

hdparm

Timing cached reads: 11980 MB in 2.00 seconds = 5992.56 MB/sec Timing buffered disk reads: 366 MB in 3.01 seconds = 121.52 MB/sec

cpu

Test execution summary: total time: 51.4463s total number of events: 10000 total time taken by event execution: 102.8828 per-request statistics: min: 9.93ms avg: 10.29ms max: 36.11ms approx. 95 percentile: 11.29ms

Threads fairness: events (avg/stddev): 5000.0000/30.00 execution time (avg/stddev): 51.4414/0.00

memory

Operations performed: 104857600 (4545662.48 ops/sec)

102400.00 MB transferred (4439.12 MB/sec)

Test execution summary: total time: 23.0676s total number of events: 104857600 total time taken by event execution: 34.1991 per-request statistics: min: 0.00ms avg: 0.00ms max: 18.05ms approx. 95 percentile: 0.00ms

Threads fairness: events (avg/stddev): 52428800.0000/69790.00 execution time (avg/stddev): 17.0995/0.01

Operations performed: 104857600 (5407739.22 ops/sec)

102400.00 MB transferred (5281.00 MB/sec)

Test execution summary: total time: 19.3903s total number of events: 104857600 total time taken by event execution: 26.8579 per-request statistics: min: 0.00ms avg: 0.00ms max: 22.46ms approx. 95 percentile: 0.00ms

Threads fairness: events (avg/stddev): 52428800.0000/7211.00 execution time (avg/stddev): 13.4289/0.14

threads

Test execution summary: total time: 1.0112s total number of events: 10000 total time taken by event execution: 2.0210 per-request statistics: min: 0.15ms avg: 0.20ms max: 11.19ms approx. 95 percentile: 0.24ms

Threads fairness: events (avg/stddev): 5000.0000/3.00 execution time (avg/stddev): 1.0105/0.00

Test execution summary: total time: 0.1665s total number of events: 2 total time taken by event execution: 0.3238 per-request statistics: min: 157.39ms avg: 161.90ms max: 166.41ms approx. 95 percentile: 10000000.00ms

Threads fairness: events (avg/stddev): 1.0000/0.00 execution time (avg/stddev): 0.1619/0.00

nginx

Concurrency Level: 10000 Time taken for tests: 5.745 seconds Complete requests: 100000 Failed requests: 0 Write errors: 0 Total transferred: 172100000 bytes HTML transferred: 160000000 bytes Requests per second: 17404.93 [#/sec] (mean) Time per request: 574.550 [ms] (mean) Time per request: 0.057 [ms] (mean, across all concurrent requests) Transfer rate: 29251.85 [Kbytes/sec] received

lxc

cpu

Test execution summary: total time: 51.4368s total number of events: 10000 total time taken by event execution: 102.8619 per-request statistics: min: 9.92ms avg: 10.29ms max: 35.08ms approx. 95 percentile: 11.68ms

Threads fairness: events (avg/stddev): 5000.0000/5.00 execution time (avg/stddev): 51.4310/0.00

fileio

Operations performed: 5548 Read, 3698 Write, 11776 Other = 21022 Total Read 86.688Mb Written 57.781Mb Total transferred 144.47Mb (493.07Kb/sec) 30.82 Requests/sec executed

Test execution summary: total time: 300.0294s total number of events: 9246 total time taken by event execution: 84.4687 per-request statistics: min: 0.01ms avg: 9.14ms max: 394.13ms approx. 95 percentile: 36.20ms

Threads fairness: events (avg/stddev): 9246.0000/0.00 execution time (avg/stddev): 84.4687/0.00

memory

Operations performed: 104857600 (4456398.83 ops/sec)

102400.00 MB transferred (4351.95 MB/sec)

Test execution summary: total time: 23.5297s total number of events: 104857600 total time taken by event execution: 34.8417 per-request statistics: min: 0.00ms avg: 0.00ms max: 20.22ms approx. 95 percentile: 0.00ms

Threads fairness: events (avg/stddev): 52428800.0000/155952.00 execution time (avg/stddev): 17.4208/0.06

Operations performed: 104857600 (5327923.43 ops/sec)

102400.00 MB transferred (5203.05 MB/sec)

Test execution summary: total time: 19.6808s total number of events: 104857600 total time taken by event execution: 27.3010 per-request statistics: min: 0.00ms avg: 0.00ms max: 16.48ms approx. 95 percentile: 0.00ms

Threads fairness: events (avg/stddev): 52428800.0000/297738.00 execution time (avg/stddev): 13.6505/0.09

threads

Test execution summary: total time: 1.2490s total number of events: 10000 total time taken by event execution: 2.4954 per-request statistics: min: 0.21ms avg: 0.25ms max: 7.39ms approx. 95 percentile: 0.28ms

Threads fairness: events (avg/stddev): 5000.0000/7.00 execution time (avg/stddev): 1.2477/0.00

Test execution summary: total time: 0.1222s total number of events: 2 total time taken by event execution: 0.2275 per-request statistics: min: 107.53ms avg: 113.77ms max: 120.02ms approx. 95 percentile: 10000000.00ms

Threads fairness: events (avg/stddev): 1.0000/0.00 execution time (avg/stddev): 0.1138/0.01

nginx

Concurrency Level: 10000 Time taken for tests: 16.976 seconds Complete requests: 100000 Failed requests: 0 Write errors: 0 Total transferred: 1551500000 bytes HTML transferred: 1539400000 bytes Requests per second: 5890.69 [#/sec] (mean) Time per request: 1697.594 [ms] (mean) Time per request: 0.170 [ms] (mean, across all concurrent requests) Transfer rate: 89252.02 [Kbytes/sec] received

vbox

hdparm

Timing cached reads: 10122 MB in 1.99 seconds = 5088.70 MB/sec Timing buffered disk reads: 300 MB in 3.00 seconds = 99.87 MB/sec

cpu

Test execution summary: total time: 54.0469s total number of events: 10000 total time taken by event execution: 108.0595 per-request statistics: min: 9.03ms avg: 10.81ms max: 61.39ms approx. 95 percentile: 14.87ms

Threads fairness: events (avg/stddev): 5000.0000/87.00 execution time (avg/stddev): 54.0297/0.00

fileio

Operations performed: 68153 Read, 45435 Write, 145280 Other = 258868 Total Read 1.0399Gb Written 709.92Mb Total transferred 1.7332Gb (5.916Mb/sec) 378.62 Requests/sec executed

Test execution summary: total time: 300.0045s total number of events: 113588 total time taken by event execution: 177.2314 per-request statistics: min: 0.01ms avg: 1.56ms max: 579.66ms approx. 95 percentile: 13.10ms

Threads fairness: events (avg/stddev): 113588.0000/0.00 execution time (avg/stddev): 177.2314/0.00

memory

一直报错,测试不出来。

threads

Test execution summary: total time: 16.0377s total number of events: 10000 total time taken by event execution: 32.0421 per-request statistics: min: 1.19ms avg: 3.20ms max: 38.39ms approx. 95 percentile: 5.74ms

Threads fairness: events (avg/stddev): 5000.0000/15.00 execution time (avg/stddev): 16.0210/0.00

Test execution summary: total time: 0.3023s total number of events: 2 total time taken by event execution: 0.5990 per-request statistics: min: 297.52ms avg: 299.50ms max: 301.47ms approx. 95 percentile: 10000000.00ms

Threads fairness: events (avg/stddev): 1.0000/0.00 execution time (avg/stddev): 0.2995/0.00

nginx

Concurrency Level: 5000 Time taken for tests: 41.758 seconds Complete requests: 50000 Failed requests: 0 Write errors: 0 Keep-Alive requests: 0 Total transferred: 890350000 bytes HTML transferred: 884250000 bytes Requests per second: 1197.38 [#/sec] (mean) Time per request: 4175.799 [ms] (mean) Time per request: 0.835 [ms] (mean, across all concurrent requests) Transfer rate: 20821.94 [Kbytes/sec] received

vbox on lvm

在物理机上开辟一个lvm卷,然后用vmdk引用物理卷的功能挂到vbox上使用,格式化为ext4文件格式。

hdparm

Timing cached reads: 10034 MB in 1.99 seconds = 5044.30 MB/sec Timing buffered disk reads: 270 MB in 3.01 seconds = 89.73 MB/sec

fileio

Operations performed: 22765 Read, 15176 Write, 48512 Other = 86453 Total Read 355.7Mb Written 237.12Mb Total transferred 592.83Mb (1.976Mb/sec) 126.47 Requests/sec executed

Test execution summary: total time: 300.0080s total number of events: 37941 total time taken by event execution: 286.5402 per-request statistics: min: 0.01ms avg: 7.55ms max: 336.67ms approx. 95 percentile: 20.49ms

Threads fairness: events (avg/stddev): 37941.0000/0.00 execution time (avg/stddev): 286.5402/0.00

vbox on vdi

基本同vbox on lvm,不过使用vdi作为存储。和vbox测试相比,内部系统换为主系统同样的debian。

hdparm

Timing cached reads: 9152 MB in 1.99 seconds = 4598.80 MB/sec Timing buffered disk reads: 352 MB in 3.00 seconds = 117.16 MB/sec

fileio

Operations performed: 151020 Read, 100680 Write, 322060 Other = 573760 Total Read 2.3044Gb Written 1.5363Gb Total transferred 3.8406Gb (13.109Mb/sec) 839.00 Requests/sec executed

Test execution summary: total time: 300.0011s total number of events: 251700 total time taken by event execution: 60.6296 per-request statistics: min: 0.01ms avg: 0.24ms max: 106.94ms approx. 95 percentile: 0.26ms

Threads fairness: events (avg/stddev): 251700.0000/0.00 execution time (avg/stddev): 60.6296/0.00

分析

计算

从CPU上说,vbox的消耗大约是5%,而lxc的消耗基本是0%。

内存测试上,vbox无法测量。lxc的性能和物理机十分相近,两者的差异在1.5%-2%之间。

在threads测试和mutex测试上,vbox显示出远远低于lxc的性能。这些基本都是内核陷入类的事务,也是预期vbox会发生性能下降的地方。

IO

从硬件设备IO上来分析,lxc和主机是共用一套物理设备的。vbox的裸设备IO比物理机低了15-18%。但是文件系统IO则表现出完全相反的景象。

lxc底层使用的是btrfs,因此性能和物理机上的btrfs性能十分相近,误差在10%以内。这一性能比物理机上的ext4/xfs低了70%以上。这个表现出btrfs的性能和ext4/xfs性能的差异(注:怎么会差这么多?)。

如果使用aufs的话,则要视复制特性而定。如果引发复制,性能会跌到和btrfs相近。而不引发复制的话,则和aufs下面的文件系统相近(误差在5%以内)。

而vbox内只有ext4,其性能高达物理机的220%。怎么可能?

network

从nginx的rps来说,lxc的性能只有物理机的1/3,vbox的更只有7%。而且vbox连10000并发都无法支撑,只能用5000并发测试。

这里固然有因为物理机目录中文件比较少的原因,但是vbox和lxc的文件数是一样的,两者性能比高达1:5是个不争的事实。

加测

因为vbox内的ext4性能太好,怀疑有鬼,所以加测了一下。果然,使用vdi后fileio性能比物理机还好(我用的是新的vdi)。这个结论在大规模读写和老的vdi上很可能退化成一点都不靠谱,否则所有的设备都应该先装一堆虚拟机做vdi。

结论

虚拟化层级

从虚拟化的深度来说,CPU虚拟化最深,完全虚拟化次之,半虚拟化其后,硬件虚拟化和半虚拟化难分伯仲,操作系统虚拟化已经很浅了。下面是简单解说。

  1. CPU虚拟化:使用CPU仿真另一块CPU的每个指令。速度最慢(大约是真实CPU的1/60),可以仿真其他CPU。bochs为其代表,qemu亦支持。
  2. 完全虚拟化:对另一个系统的部分核心调用进行处理。速度次之(大约一半略快)。必须是同种CPU,但可以是不同系统。vmware早期的虚拟机都是此种。
  3. 半虚拟化:修改另一个系统的核心代码,使其与hypervisor交互以提高性能(大约5-10%)。必须同种CPU,但是guest系统必须可以修改(排除了windows)。Xen为其代表。
  4. 硬件虚拟化:利用硬件加速完全虚拟化,使其性能接近半虚拟化,但是不需要修改内核。必须同种CPU,可以为不同系统。目前大部分虚拟机都支持。
  5. 系统虚拟化:在系统上完成另一个系统的特性。必须是同种CPU同种内核,但可以是不同系统(例如debian和centos)。linux上的lxc/openvz,bsd上的jail,windows上的Virtuozzo为其代表。
  6. 用户隔离:在同一个系统上,利用用户分割权限和限制配额。必须在同一个系统内。DAE为其代表。
  7. 沙盒:在语言内部搭建隔离平台,对API进行鉴定和抽象。GAE为其代表。

性能和隔离性的取舍

上面显然可见,隔离性越好,性能越差。使用硬件虚拟化后,nginx的rps只有原本的1/10。lxc的overload明明很低,但是因为用了虚拟网卡,所以rps下降到1/3。从效率上说,当然不希望为了虚拟化而消耗大量的资源。所以,如果服务原本可以用户隔离,就不要用系统虚拟化,如果可以系统虚拟化,就不要硬件虚拟化。所以在大规模使用虚拟化之前,不妨考虑一下是不是先好用户权限级隔离比较合适。

文件系统

从上面可以看出,对于lxc这种小消耗的虚拟方案,与其在意虚拟机的性能消耗,不如更在意文件系统的性能消耗。但是比较倒霉的是,lxc是不能在虚拟机内自行配置文件系统的,需要从主机内分配挂载。

  • ext4:适用于大部分情况,iops很高,小文件下吞吐量很不错。大部分虚拟化场景都是小系统简单服务的时候适合。
  • xfs:适用于大设备内部的大虚拟机。每个虚机的服务复杂,或者是有大文件。
  • btrfs:这个东西性能很低,但是写时复制的能力对快速clone很重要。适合用于产生一堆临时生成的环境,用于程序员测试或者测试工程师搭环境,测试完了就删除的。
  • aufs:和btrfs情况差不多,快速clone不错。不过安全起见,clone后原image不可以启动实例或者修改image。在没有COW写入时性能很高,这点比btrfs好。而在COW时瞬时开销很高。

by shell909090 at January 23, 2014 03:04 AM

January 22, 2014

@shell909090

在PAM中使用google authentication

PAM是linux系统身份验证的核心,在用户登录/ssh身份校验中均有很大用途。但是很少有人想到,其实这个东西还可以用google authentication来进行身份校验。

安装

sudo apt-get install libpam-google-authenticator

设定

使用前,需要对用户做一个用户级配置,生成配置文件。这个文件就是这个用户的身份验证凭证。配置请使用用户执行google-authenticator

上来先会问你是否使用基于时间的验证,肯定选是。但是注意,基于时间的验证要求服务器时间必须精确。更准确的说,是服务器时间和手机时间校准在30秒以内。由于手机一般都采用GSM校时,因此只需要在意服务器时间。建议是使用ntpdate来校准时间。特别注意,linux的时钟是会漂移的,必须按天级校准。

然后程序会给出一个url,还可能有QR码(真够不容易的,Console级别的QR码。。。)。记住,一定要用url去获得QR码给程序扫描。因为url获得的QR码算法是最新的,而直接生成的有可能不能跑。

下面是secret key和verification code,一般来说这两个不用关心。但是你需要记住emergency scratch codes。libpam-google-authenticator默认给你生成了5个,一般都够用了。通常用到3个就更新一遍吧。

  • 是否生成配置,选是。
  • 是否拒绝使用同一个token的人登录。如果选是,30秒内只能登录一个人。建议选是。
  • 是否放送时间验证,从1分30秒到4分钟。如果选是,允许更大的服务器时间偏差。看你服务器时间是不是够准。
  • 是否防止暴力破解,30秒内尝试不超过3次。建议选是。

OK,你的配置就完成了。如果有多个用户,请多次配置。

手机app

按照系统安装以下app,下面以android版为例介绍。

选择setup account,然后scan a barcode。程序会要求你使用barcode扫描软件扫描(推荐barcode scanner)。这时去扫描设定一节中访问url显示的那个qr码。

pam配置

对于ssh而言,请在/etc/pam.d/sshd的最后一行增加这句。

auth required pam_google_authenticator.so

注意,这样其实是密码/校验码双重验证。如果你不需要密码请注释掉下面这句。

@include common-auth

或者其他包含以下这句的地方。

auth    required            pam_permit.so

如果你希望增强sudo安全性,也可以把这句加入/etc/pam.d/sudo后面。如果同样不需要密码,请注释上面那句。

sshd配置

保证/etc/ssh/sshd_config里面,以下参数都处于正确的配置。

ChallengeResponseAuthentication yes
PasswordAuthentication no
UsePAM yes

如果你使用openssh6.2以上版本,请额外加入这句以开启publickey和验证同时启用。

AuthenticationMethods publickey,keyboard-interactive

sudo

注意,如果是NOPASSWORD,则没有校验。

参考和鸣谢

  1. Why enable SSH Two-Factor Authentication on your server?
  2. Use Google Authenticator For Two-Factor SSH Authentication in Linux
  3. Google Authenticator For SSH

感谢Scott Miller在引用2中的回答,AuthenticationMethods这个细节在其他文献中没有提及。

by shell909090 at January 22, 2014 05:31 AM

January 15, 2014

@shell909090

golang和nginx的简单性能对比

说明

测试都是ab做的,中等并发量,统一采用10000并发,100000个请求。都是本机请求本机,避免公司内网IDS的干扰。

机器是一台双核CPU的DELL:Intel(R) Pentium(R) CPU G2030 @ 3.00GHz。配4G内存。

第一组数据是ab测试nginx,nginx的配置如下:

worker_processes 4;
pid /run/nginx.pid;
worker_rlimit_nofile 30000;

events {
        worker_connections 20000;
        multi_accept on;
}

http {
        sendfile on;
        tcp_nopush on;
        tcp_nodelay on;
        ...
}

第二组是ab测试golang,返回固定是个OK。

第三组是ab测试golang,返回某个目录或文件。

err := http.ListenAndServe(":8080", http.FileServer(http.Dir("/home/shell/photo")))

nginx

Concurrency Level:      10000
Time taken for tests:   5.720 seconds
Complete requests:      100000
Failed requests:        0
Write errors:           0
Total transferred:      172100000 bytes
HTML transferred:       160000000 bytes
Requests per second:    17482.47 [#/sec] (mean)
Time per request:       572.001 [ms] (mean)
Time per request:       0.057 [ms] (mean, across all concurrent requests)
Transfer rate:          29382.16 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0  320 581.1    146    3262
Processing:     1  197 136.6    198    1886
Waiting:        1  162 120.6    154    1811
Total:          1  517 604.1    371    3558

Percentage of the requests served within a certain time (ms)
  50%    371
  66%    455
  75%    515
  80%    587
  90%   1167
  95%   1378
  98%   3375
  99%   3402
 100%   3558 (longest request)

golang with string

Concurrency Level:      10000
Time taken for tests:   5.147 seconds
Complete requests:      100000
Failed requests:        0
Write errors:           0
Total transferred:      11800000 bytes
HTML transferred:       200000 bytes
Requests per second:    19429.37 [#/sec] (mean)
Time per request:       514.685 [ms] (mean)
Time per request:       0.051 [ms] (mean, across all concurrent requests)
Transfer rate:          2238.93 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0  293 659.6      5    3020
Processing:     1   37 112.3     10    1644
Waiting:        1   34 111.9      9    1642
Total:          3  329 700.4     16    4653

Percentage of the requests served within a certain time (ms)
  50%     16
  66%     25
  75%    248
  80%   1003
  90%   1032
  95%   1431
  98%   3026
  99%   3042
 100%   4653 (longest request)

golang with file

Concurrency Level:      10000
Time taken for tests:   8.122 seconds
Complete requests:      100000
Failed requests:        0
Write errors:           0
Keep-Alive requests:    100000
Total transferred:      72200000 bytes
HTML transferred:       53500000 bytes
Requests per second:    12312.87 [#/sec] (mean)
Time per request:       812.158 [ms] (mean)
Time per request:       0.081 [ms] (mean, across all concurrent requests)
Transfer rate:          8681.54 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0   29 333.4      0    7009
Processing:     0  495  98.1    524    1918
Waiting:        0  495  98.1    524    1918
Total:          0  524 353.0    525    8086

Percentage of the requests served within a certain time (ms)
  50%    525
  66%    531
  75%    535
  80%    537
  90%    543
  95%    550
  98%    558
  99%    563
 100%   8086 (longest request)

分析

从rps来看,三者都达到了10Krps的级别以上,而且差距很小。golang在没有逻辑的情况下比nginx还要快11%,但是加入逻辑后反而落后30%(这不奇怪)。三者差距都在50%以内,基本属于同一个数量级。

如果不考虑golang本身的内存管理问题,我觉得可以用golang替代nginx+lua的方案了。至少代码好写很多。

by shell909090 at January 15, 2014 02:53 AM

January 14, 2014

@delphij

一种针对 ntp 服务的 UDP 杠杆式攻击

先挖好坑,等有空了再填。

今天(2014/01/14)发了4个安全公告和2个勘误公告,其中 FreeBSD-SA-14:02.ntpd 是针对 NTP 的这种攻击的因应措施。

攻击的原理是通过发送一个小包(GET_MONLIST),得到大体积的回应。而由于 NTP 使用了 UDP 协议,因此攻击者可以伪造源 IP,从而,通过较小的流量代价,即可利用其他服务器作为杠杆来攻击受害者。

正确配置的 NTP 服务器并不受这个问题影响。所谓正确配置是指 NTP 服务器配置为只允许其他机器向其查询时间,具体做法是在 /etc/ntp.conf 中增加类似下面的设置:

restrict default kod nomodify notrap nopeer noquery
restrict -6 default kod nomodify notrap nopeer noquery
restrict 127.0.0.1
restrict -6 ::1
restrict 127.127.1.0

(说明:上述配置是推荐的配置,实际上起作用的是 noquery)

还有一种解法是仅仅禁止 monitor 功能:

disable monitor

FreeBSD 安全公告提供的补丁采取的做法是将 monitor 功能默认禁用。用户不需要对配置文件进行修改,只需更新软件并重启 ntp 服务即可防止自己的服务器成为别人的攻击杠杆。

by Xin LI at January 14, 2014 11:55 PM

January 02, 2014

@shell909090

lxc简单介绍

基本安装

安装lxc包。

注意修改/bin/sh,链接到/bin/bash。lxc在某些版本上有一个bug,声明为/bin/sh却使用bash语法,导致不如此链接会出现错误。

镜像和设定

使用lxc-create -n name -t template生成镜像。

在/usr/share/lxc/templates可以看到可用的模板。

在/var/cache/lxc/debian会缓存生成过程的临时文件。

生成的镜像需要在镜像内安装lxc,否则无法使用lxc-execute。

资源限制

在config文件内,写入cgroup限定规则。注意,使用内存限定的话,需要在内核参数中加入cgroup_enable=memory。

在debian下,可以修改/etc/default/grub文件,使用update-grub重新生成规则。

GRUB_CMDLINE_LINUX_DEFAULT="cgroup_enable=memory quiet"

在config文件中可以如下限定。

lxc.cgroup.memory.limit_in_bytes = 512M # 限定内存
lxc.cgroup.cpuset.cpus = 0 # 限定可以使用的核
lxc.cgroup.blkio.throttle.read_bps_device = 8:0 100 # 读取速率限定
lxc.cgroup.blkio.throttle.write_bps_device = 8:0 100 # 写入速率限定
lxc.cgroup.blkio.throttle.read_iops_device = 8:0 100 # 读取频率限定
lxc.cgroup.blkio.throttle.write_iops_device = 8:0 100 # 写入频率限定

执行

lxc-start -n name /bin/echo hello

还可以用以下指令,在已经启动的container里执行进程。

lxc-attach -n name /bin/echo hello

以下指令是用来在未启动的container里执行进程的。

lxc-execute -n name /bin/echo hello

** 注意,虽然系统初始化了所有资源,但是由于sysv-init没有执行,因此系统内初始化并没完成。这导致系统不完整,例如网络部分不可用。 **

网络隔离

自行设定的网络

lxc采用veth技术,每次虚拟机建立时,都会产生一对veth。虚拟机内的一般叫做eth0,虚拟机外的叫做vethXXX。这张网卡可以以任何linux许可的方式进行配置。

  • dnsmasq所产生的dhcp封包无法被debian guest的dhcp client承认,因此无法使用dnsmasq自动部署网络。

使用iptables配置访问

在开启br-nf后,所有bridge的包都会经过iptables的过滤。因而可以用iptables的FORWARD规则限制guest堆外网的访问。

参考

  • http://lxc.teegra.net/

by shell909090 at January 02, 2014 04:48 AM

December 30, 2013

@shell909090

一个神奇的故事——为什么程序能够工作

故事的原因

今天被一个妹子问到一个专业问题。每天看你们在写程序,为什么你们写一些东西,就会出现很多神奇的功能。

好吧,这是很多“外行”很难理解的问题。大多数职业非职业程序员,只要写过一点程序,就不会对这种事情表示惊奇。然而问题是,很多人并没有深刻的认识到,这个问题其实非常难解答,可以算是计算机本质性问题之一。

我当时的解答有点奇怪和玄幻色彩。我打了个比方,例如你有个萝卜头,你扇它一下,它会往前蹦一下。你又有个电灯,按一下开关就亮,按一下开关就灭。那么你把两者组装起来,在旁边立个牌子,扇一下萝卜头灯就亮,再扇一下就灭。事情看起来就很神奇了。至于萝卜头为什么会这么做,这个事情我并不了解。

实际上,这个回答很让人莫名其妙。什么萝卜头和奇怪的世界观阿,这不是在讲程序吧。好吧,我把整个故事讲的稍微完整一点。作为对所有有这个问题的人的解答。

原型

在讲整个故事前,让我们稍微的放开一点想象力。例如我们有一个老鼠,一盒一碰就会掉下奶酪的奶酪盒,一个转笼(就是老鼠经常在里面跑的那种),一个小的皮带环,一个风扇,一个导轨,就是扔个铁球,就能沿着导轨滚动的那种。

我们把转笼和风扇用皮带环连接起来,然后里面放上白老鼠,上面放上奶酪盒,旁边放一个导轨,然后用黑盒子罩住,旁边放一张纸。这是一个神奇的设备,当你向里面投入一块钱,就会有风吹出来。因为钱沿着导轨滚下来,会碰到奶酪盒。老鼠就会开始跑,带动风扇吹出风来。

好像很神奇的样子哎,投币式风扇。

哎哎等等,你弄了那么复杂的一堆东西,就是为了吹风扇?那为什么不用电风扇呢?

其实我们的老鼠盒子和电风扇具有一样的结构。老鼠是动力源,奶酪盒是开关,皮带环是传动系统,风扇负责执行。我们只要正确的将每个具备功能的部件组合起来,就可以产生奇妙的效果。至于每个部件为什么能达到他自己的功能,这个我们并不关心。设计部件的人会为我们做出合适的实现。

同样的组合,如果是电扇,我想大部分人都不会表示不理解。然而如果换成老鼠盒子,大家就会觉得很神奇,如果换成程序,就会觉得更神奇了。

其实程序和老鼠盒子非常类似。程序的每个部件都有自己独特的功能,我们只要负责将这些部件以合适的逻辑连接起来,就可以完成新的功能。当然,如何连接部件是一个非常有技术含量的问题,需要专门的培训。

然而,程序比老鼠盒子更加复杂,更加让人觉得神秘莫测的地方是。程序经常出现一些我们听不懂的东西。同样用老鼠盒子做比方,请想象一下以下事件:

不可往复

这个系统还没上线,就被产品经理吐槽了一把。这个系统的第一个问题,就是能开不能关。一旦老鼠开始跑,直到没有力气之前系统是不会停的,无论人在不在。为了修正这点,我们再弄了一个传送带,用皮带环和转笼连接。当老鼠跑上一分钟后,传送带就会把奶酪传送到老鼠面前,老鼠就会吃掉奶酪,从而停止奔跑。

白老鼠的不稳定性

系统终于上线了,不过有奇怪的问题。系统不知道为什么,有的时候工作有的时候不工作。

经过工程师的检测,这主要是老鼠会吃饱。一旦老鼠吃饱了,奶酪就失去了吸引力。因此每隔三四块奶酪就会停止工作。不过老鼠饿的很快。所以十分钟后又恢复了工作。所以表现就是不稳定。

工程师为了紧急修复这个问题,让每次掉出来的奶酪减小到了很小的尺度,大约是原来的三分之一。这样就算十分钟连续工作,也不会吃饱。

老鼠盒子的黑客事件

没多久,这个盒子碰到了黑客。有个人掀开盒子看了一眼,发现导轨只辨识撞击,不辨识是否是货币。因此出现了大量铁球替代硬币的事情,扔个铁球就开始吹风。市场部表示工程师需要紧急解决这个问题。

工程师巧妙的将轨道绕了几个弯,并减小了弯上的轨道宽度。如果投入物是硬币,那么他的重量和形状就会使得他正确的通过弯。而铁球或轻或重会从导轨上掉下去。从而解决了这个问题。

并发请求

很快,系统又遇到了一个问题。有人一次性的投入了两个硬币,因此击中了奶酪盒两次。老鼠只跑了一分钟就吃了两块奶酪。因此这个人又重复的连续投了多次货币。这导致老鼠吃饱了,因此盒子不工作了。客户大发雷霆,打电话到售后骂人,老板很生气。

工程师发现这是因为奶酪被连续放置的缘故。于是他们设计了一个连杆。当老鼠开始工作的时候,就会启动连杆,关闭投币口。这样就不会引起老鼠连续吃东西了。而老鼠停下的时候,连杆就会打开。就可以继续投币。

老鼠饿死了

经过了一个圣诞节,大家都不去玩老鼠盒子,老鼠饿死了,老板把运营骂了一顿。

运营乖乖去换了一只老鼠,并让工程师在盒子里装了一个摄像系统,可以让他们看到老鼠是否存在。

现状

现在我们有一个神奇的盒子,投币就可以吹风。这个盒子是由一个带着摄像系统的黑色外壳,一个盘旋的及其复杂的导轨,一个奶酪盒子,一个传送带,一个连杆,两组皮带环,一个转笼,一只老鼠,一个风扇组成。为什么会这样?一个妹子问。。。

by shell909090 at December 30, 2013 03:18 AM

December 22, 2013

@khsing

信用卡安全(Secure Credit Card)

最近信用卡安全议题频发,也引发了我对信用卡用卡安全的疑惑。以前的认识是信用卡不设密码如果出现盗刷则由银行负担。现在来看不是这个样子的。我查了几家银行的信用卡章程,重点是关于挂失、网上交易、密码交易的部分。

下面是招商银行章程

第三章 使 用

第十五条 凡使用密码进行的交易,发卡机构均视为持卡人本人所为,依据密码等电子信息为持卡人办理的刷卡消费、存取款、转账结算、网上支付、手机支付、电话支付等各类交易,交易所产生的电子信息记录均为该项交易的有效凭据。凡未使用密码进行的交易,则记载有持卡人签名的交易凭证及发卡机构与持卡人约定的其他证明文件,或经确认证明持卡人本人消费的其他依据,为该项交易完成的有效凭证,但持卡人与发卡机构另有约定的除外。持卡人应在安全的技术和商户环境下在互联网上使用信用卡,否则持卡人须对该卡在互联网上使用所导致的风险和损失自行承担责任。

... ...

第十九条 信用卡遗失、被窃或遭他人占有时,持卡人应及时通过发卡机构客户服务热线办理挂失。发卡机构在核对相关资料后进行相关挂失处理。电话挂失经发卡机构确认后即生效,挂失正式生效前所发生经济损失均由持卡人(单位卡由申领单位)承担,但持卡人和发卡机构另有约定的除外。信用卡遗失、被窃或遭他人占有的,持卡人应配合发卡机构调查情况。持卡人与他人合谋、恶意串通、套现、洗钱或有其他任何违法、不诚信的行为,持卡人承担全部法律后果和责任。

国内其他银行的章程基本和招行的一样,比如工行的

第十一条 凡使用密码进行的交易,均视为持卡人本人所为,持卡人遗忘密码,可凭本人有效身份证件和牡丹信用卡办理密码重置。基于持卡人签字形成的交易凭证和/或凭牡丹信用卡磁条、芯片、卡号或密码等电子数据而办理的各项交易(包括但不限于通过销售点终端、手工受理、邮件、电话、手机、短信、传真、互联网等方式进行的信用卡交易)所产生的信息记录之一或全部均属于该项交易的有效凭据。

第十三条 持卡人遗失牡丹信用卡应立即通过中国工商银行电话银行、网上银行等电子银行渠道或到发卡机构营业网点办理挂失,挂失手续办妥,挂失即生效。持卡人对挂失生效后其牡丹信用卡发生的交易不承担任何责任,除非持卡人对该交易存在欺诈、串通他人欺诈或其他不诚信行为。挂失生效前牡丹信用卡产生的损失由持卡人承担,发卡机构不承担任何责任,但发卡机构存在法律、法规规定的过错或与持卡人另有约定的除外。挂失后如需补办新卡,可按照规定办理补办手续。

然后我又看了一下花旗银行的信用卡章程

第十九条 如持卡人选择通过互联网(INTERNET)使用信用卡的,则应在安全的技术环境和商户环境下使用,否则持卡人必须自行对该卡片在互联网上使用所导致的一切风险和损失承担责任。

  1. 您可直接通过客户服务热线设置电话银行密码及交易/取现密码。请妥善保管您的密码,任何通过密码完成的指令均视 为您本人作出,您应自行承担有关后果及损失。并且,您应妥善保管信用卡及有关交易凭证等,不得将信用卡以任何方 式交与他人使用。

  2. 如果您的密码被泄露,或您的信用卡遗失、被盗或被他人所使用,您必须立即通过客户服务热线向本行挂失。挂失一经本行确认即时生效。您应对挂失生效前发生的所有信用卡交易负责,不论该项交易您是否知悉或是否经过您的授权。如您与他人合谋或有其它不诚实行为,或者不配合本行进行有关调查的,则您须自行承担在挂失生效后发生的所有债务。

  3. 您了解,根据具体交易性质,信用卡交易可能无需或无法通过密码或签名完成,或可能没有交易单据。该等交易包括但 不限于通过电话、传真、邮寄或电子终端或媒介直接授权从信用卡账户转账付款或使用 ATM 或任何其他本行随时认可 的设备进行的交易。您不得以未凭密交易、单据上无签名或无交易单据等为由否认交易或拒绝还款。

  4. 若您因使用信用卡而使用任何第三方的服务,您需认真阅读并充分了解该等第三方服务的有关条款和条件(如有),并 同意受其约束。除非我们明确告知,否则我们与任何第三方不存在代理关系。对于非我行代理的第三方,您需自行承担 该等第三方的行为或服务的有关风险,我们对其提供的服务不提供任何保证或承担任何责任,也不因其机器设备或通讯 网络的故障或任何我们无法控制的原因承担责任。若发生任何与该等第三方的争议,您应自行与其协商解决,您不得以 任何争议为由拒绝支付所欠本行的款项,也不得以退还使用信用卡交易取得的货物等方式要求本行退款。本款所指的非 代理关系的第三方的服务包括但不限于您因使用信用卡而接受商家、特约商户、收单银行及其他受理单位向您提供的服 务,操作任何第三方的自助设备,使用第三方提供的增值服务(包括但不限于短信和移动支付等功能),选择第三方支 付平台(包括但不限于支付宝、拉卡拉等)进行支付或还款等。

浦发银行倒是有一个失卡保障的增值服务,来保障挂失前72小时的境外交易和48小时内的境内交易,但是他的章程和领卡合约中和其他银行基本一样:

第二十二条 凡使用密码进行的交易,信用卡中心均视为持卡人本人所为,依据密码等电子数据信息办理的各类结算交易所产生的电子信息交易记录均为该项交易的有效凭证。凡未使用密码进行的交易,基于持卡人签字形成的交易凭证和/或凭信用卡磁条、芯片、卡号等电子数据而办理的各项交易所产生的信息记录之一或全部均属于该项交易的有效凭据。

第二十三条 持卡人应在安全的技术和商户环境下在互联网(INTERNET)上使用信用卡,信用卡中心保留拒绝处理或支付怀疑涉及非法赌博等根据适用法律可能为不合法的互联网交易。因可能涉及非法互联网交易所导致的风险和损失由持卡人自行承担责任。

第二十四条 信用卡遗失或被窃时,持卡人应及时通过信用卡中心24小时客户服务热线办理电话挂失,挂失即时生效。挂失生效前所发生的经济损失由持卡人承担。持卡人与他人合谋或有其它不诚实行为,或者不配合信用卡中心调查情况时,由持卡人承担所有损失,信用卡中心不承担任何责任。挂失后,信用卡中心可为持卡人换发新卡。

这么看下来,基本就是:

  • 设置了密码,银行肯定免责,不设密码还有商量的可能行,但是怎么处理都是银行说了算。
  • 网上交易一水的说了都是自己负责,而且用了第三方支付平台的都是要自己负责的。
  • 挂失前产生的交易都由自己承担,工行在章程里没说挂失前的怎么办。招行是默认持卡人自己负责,除非另有合约(谁会另有合约?)。花旗直接就说持卡人自己负责。浦发的这个得看他的失卡保障服务给力不给力了。

所以自己用信用卡还是注意些吧:

  • 不要设置交易密码,在信用卡背后签名而且提醒收银员核对签名
  • 设置网上交易,单笔上限和单日上限
  • 不要把信用卡交给其他人刷卡、保管
  • 用不透明的胶贴把信用卡背后的CVV给盖上(不要刮掉,那样会破坏信用卡从而违反信用卡使用章程)

ps. 浦发信用卡的失卡保障中境外消费不包含古巴、伊朗、缅甸、叙利亚和苏丹,这几个地方也是Facebook上不去的几个地方吧。;-)

by Guixing at December 22, 2013 06:25 AM

December 20, 2013

@khsing

用https代替git-ssh来push

最近发现推送代码到github总是要账户名和密码,大多给出的解决办法是用ssh代替https就解决了,而且说是just simply。鄙人觉的这简直就是不负责任的解决办法(虽然之前我也是这么解决的),我忍你很久了。正确的方法是在家目录放一个.netrc的文件(win用户自动绕开,我不会告诉你们是在家目录放_netrc的),内容如下

machine github.com
   login <user>
   password <password>

REF: StackOverflow:Git push requires username and password

by Guixing at December 20, 2013 01:28 AM

糾結於機械鍵盤

想搞一個機械鍵盤,看來看去糾結在了三款鍵盤上面。

  • Das Keyboard: 這個是我看到評價很好的鍵盤了,主要是擊鍵的感覺很到位。缺點是太大了,我其實不想要一個全鍵位的鍵盤。
  • Filco 聖手2 87: 這個鍵盤也不錯了。缺點是鍵帽是ABS材質,用久了會變油打滑,只有側刻,沒有無刻版本。
  • HHKB Pro 2: 最喜歡這個鍵盤佈局了,而且可以編程,唯一的缺點是太貴了。

綜合下來我想要的一個機械鍵盤是

  • Cherry MX Blue(青軸)
  • Tenkeyless. (無數字鍵盤,甚至無Home,Page鍵區)
  • PBT材質鍵帽
  • 無刻

糾結啊

by Guixing at December 20, 2013 01:26 AM

December 03, 2013

@shell909090

KK行——第四日

第四天也是自由行动,总算能玩到一些好玩的了。

鉴于有些人已经去过加亚岛了,所以我们去的是另一个岛。上去后发现这里居然有降落伞,而且可以两人乘坐。上次去普吉岛的时候被鄙视太重,这次总拖的起来吧?

在海上坐降落伞其实是个非常不错的体验,你可以明显感到风的流动,并且看到海水从碧蓝到碧绿的变化。如果不会超重的话(不许笑),我下次打算体验一下热气球。

船老大还提供下水和不下水的选项。如果你有兴趣,他们会开的慢一点,让降落伞在水面擦过。然后就可以半截身子浸在水里。道哥和他老婆享受了一把这个待遇。整个水全溅起来,满头满脸。我当时没带泳裤,所以干脆的放弃了,还是在天上看看就好了。。。

降落伞的宣传价是100RM,但是讲一下价就到70RM左右了。剩下能谈到多少就看个人功力了。我们近20个人,拿到了65RM的价格。

回到岛上,换一批人出去被吊起来,剩下的人就去堆沙子和浮浅。实话说,KK作为浮浅来说比puhket和maldive差很多。鱼都是比较小的种类,而且密度比较稀疏。当然,珊瑚礁比puhket漂亮的多,而能见度也比maldive好。但是我没带泳装,而且背已经严重的晒伤了。所以还是没有下水。

当晚我们在酒店附属的酒吧里面呆到很晚,和台上的一帮国际友人唱歌玩,最后还送了人家两个牛小七。

最后是关于机场的重点。马来西亚禁止贝壳和珊瑚出口,所以如果被发现带贝壳或者珊瑚走的话,抱歉,重罚加没收。所以要带贝壳珊瑚什么的就别想了。至于海星之类的活物更没指望。原则上贝壳工艺品并不受限,但是必须在购买时索要凭证证明你是购买的,否则也不能放行。

而且他们的安检很奇怪。第一道口在办理登机的counter那里。国内出去的时候,我们只称托运重量。马来是称量所有物品,包括随身的。而春秋的额度又特别低,只有15。所以我们一帮人就紧急分配重量,谨防超标。我把公司的东西交给别人带,自己带自己东西。最后我上去的时候,能穿的都穿了,在热带穿的像只北极熊一样,还偷背着一只相机包。最后一称,16公斤。理论上一公斤45RM,合95RMB。不过还不错,没找我要。

第二道安检在过海关前,第三道在海关那里,不安检,只办理手续。在办理手续的时候,居然碰到了第一天来的时候碰到的两个妹子。和她们聊了一下。结果他们发现我们是公司出钱全包到这里来玩的时候,当场就称呼我们为土豪公司。后来我们的人就直接被叫做“土豪的同事”了。

下面就是他们安检比较奇怪的地方了。在候机厅进入另一个候机厅的时候,居然又安检一次。这次才夸张,水都不让带,必须喝光,要么留下。春秋又是不供水的。这个机场的政策让人怀疑春秋是不是买通他们了。还有这次贝壳在机场免税店里面购买了一个大贝壳(好像有点绕),结果在最后一道安检的时候被拦下。保安问我要购物凭证,我说没有,我就在你们机场里面买的。他先说不行。我说你可以打开看看。然后他打开一看——贴着一个标。当时后面有个人说这个标是我们机场的,我就被放行了。所以为了省麻烦,要买工艺品还是索要凭证的好。不过后面两个买了同样贝壳的人连开包都不用,估计是因为保安已经在我这里看到贝壳的形状了,所以后面的就没检。

后来我们讨论,安检这么严一定有什么事。前面两个妹子就说有两个游客在仙本那出事了,被人杀了。然后我就有点小庆幸,我们的运气还是不错的。

by shell909090 at December 03, 2013 01:55 AM

December 02, 2013

@shell909090

KK行——第二三日

第二天的行程是美人鱼岛,基本就是跟团运动。跑到美人鱼岛,浮浅一次,吃午饭,浮浅第二次,回去。

比较无语的是,第一次出发的时候,跑到海里才发现少了两个妹子。回去一看这俩换衣服比较慢,硬生生没赶上第一次浮浅。第二次我好歹跟着,结果一个不靠谱的给我们指到另一个船上去了。我们三个带着N贵的水下相机,只有三个人在那里浮浅。。。

所以团队出门注意随时数人,个人注意紧跟领队。否则后果很严重。

需要特别注明的是(虽然第二次说这个了),这里的深潜,需要提前预约,和泰国不一样。

第三天的行程是看长鼻猴和萤火虫,实话说很一般。因为长鼻猴距离比较远,拿着望远镜也看不清楚。这毕竟是野外,不是动物园,不能追求最好的展示效果。而萤火虫——去,初中的时候门口一大片的全是萤火虫,见太多就没感觉了。

第三天晚上我发现一个严重的问题——我的令吉严重的过多了。这次我为深潜保留了300-500RM。结果两次都没深潜成。现在这笔钱带不回去只能花掉。而且团里很多人都有类似的问题(虽然不完全是因为深潜)。所以,当晚某大陆游客团的疯狂购物传奇就开始了。

当晚我买了一堆榴莲酥(记得,生鲜水果不得上飞机),数盒红茶巧克力,还有几包咖啡。实际吃下来,榴莲酥和咖啡广受欢迎,严重不足。红茶巧克力反响一般。榴莲味咖啡则是被我当猎奇产品送了出去。好吧,幸好原来也是买着玩的。

要去的朋友可以多入榴莲酥。凯诚附近有家榴莲王,里面打工的妹子很不错。老板祖上是福建过去的,一口台湾腔。可以先试试他们的油炸冰冻榴莲,再买点新鲜的榴莲酥回来。

另外我又跑去做了个泰式按摩。按摩的妹子英文很奇怪,仔细一问原来是从泰国来打工的。我的右手大拇指原来有点摔伤,痛了很久了没法动。她拿精油推了一会,居然基本没事了。我顿时感到很惊奇,就问老板推拿的精油有没有在卖。老板说不好意思他们都是自用的,不卖的。很可惜。

by shell909090 at December 02, 2013 06:52 AM

KK行——第二三日

第二天的行程是美人鱼岛,基本就是跟团运动。跑到美人鱼岛,浮浅一次,吃午饭,浮浅第二次,回去。

比较无语的是,第一次出发的时候,跑到海里才发现少了两个妹子。回去一看这俩换衣服比较慢,硬生生没赶上第一次浮浅。第二次我好歹跟着,结果一个不靠谱的给我们指到另一个船上去了。我们三个带着N贵的水下相机,只有三个人在那里浮浅。。。

所以团队出门注意随时数人,个人注意紧跟领队。否则后果很严重。

需要特别注明的是(虽然第二次说这个了),这里的深潜,需要提前预约,和泰国不一样。

第三天的行程是看长鼻猴和萤火虫,实话说很一般。因为长鼻猴距离比较远,拿着望远镜也看不清楚。这毕竟是野外,不是动物园,不能追求最好的展示效果。而萤火虫——去,初中的时候门口一大片的全是萤火虫,见太多就没感觉了。

第三天晚上我发现一个严重的问题——我的令吉严重的过多了。这次我为深潜保留了300-500RM。结果两次都没深潜成。现在这笔钱带不回去只能花掉。而且团里很多人都有类似的问题(虽然不完全是因为深潜)。所以,当晚某大陆游客团的疯狂购物传奇就开始了。

当晚我买了一堆榴莲酥(记得,生鲜水果不得上飞机),数盒红茶巧克力,还有几包咖啡。实际吃下来,榴莲酥和咖啡广受欢迎,严重不足。红茶巧克力反响一般。榴莲味咖啡则是被我当猎奇产品送了出去。好吧,幸好原来也是买着玩的。

要去的朋友可以多入榴莲酥。凯诚附近有家榴莲王,里面打工的妹子很不错。老板祖上是福建过去的,一口台湾腔。可以先试试他们的油炸冰冻榴莲,再买点新鲜的榴莲酥回来。

另外我又跑去做了个泰式按摩。按摩的妹子英文很奇怪,仔细一问原来是从泰国来打工的。我的右手大拇指原来有点摔伤,痛了很久了没法动。她拿精油推了一会,居然基本没事了。我顿时感到很惊奇,就问老板推拿的精油有没有在卖。老板说不好意思他们都是自用的,不卖的。很可惜。

by shell909090 at December 02, 2013 06:52 AM

November 30, 2013

@shell909090

KK行——第一日

第一天的行程很郁闷。我们0点降落在KK,然后就被导游拉着上了bus,结果我没买到电话卡——这注定了后面的悲剧。

晚上到酒店,不想那么早就睡觉,就一帮人跑出去吃东西。我想要办手机卡,所以就往酒店后面走。碰到两个和我们一飞机过来的妹子要取钱,就一起过去。取完钱我们找了半天,所有人都说在7-11那里办电话卡,可是那里就是没有。

出发前我联系过潜店,得知他们的潜水都是早上8点半出门的。所以我7点半起床,去叫道哥和王伟伟。结果他们通通起不来。我只好叫上徐立去吃早饭,吃完去碰碰运气。

到了潜店那里,他们说,不好意思,你需要昨晚预约。问了数家都是这样。由于我们到的第一天是全自由行动,而且只有一天的全自由行动,所以没办法,这次没法去潜水了。

然后我们就一路逛回了酒店。在大厅里面发现韩大哥一行正要去博物馆,就跟着去了。

实话说,博物馆没啥好玩的。更那啥的是出博物馆的时候又下雨了,我们被困在博物馆动弹不得。好容易叫了三辆出租,还是分别叫的。其中一个司机还不会讲华语,又不认得地方。等到了jalan gaya,一群人分成了三份在暴雨里面凑不起来。最后只凑了两拨人,各自吃饭找地方玩。

中午吃的是其中某一家的肉骨茶,味道,一般般啦。当地并没有什么让人眼前一亮的美食,大多都是水平以上好吃一点和水平以下凑合一点的区别。唯一在国内吃不大到的只有海鲜而已。

下午在某商场的地下餐厅街吃的下午茶。我吃了半只烤鸡和鸡肉肠。这里的黑胡椒烤鸡味道不错,有兴趣的可以试试。

晚餐就是吃的海鲜。我们没点贵的要死的大龙虾,所以只有72令吉一个人。合国内大概150人民币的样子。以吃的东西而言,基本和上海持平吧。不过东西肯定要新鲜一些。

by shell909090 at November 30, 2013 05:56 PM

November 27, 2013

@shell909090

KK行——第零日

刚刚来七牛没几天,就被告知一件好事。公司组织去沙巴和普吉旅游,可带家属。想想普吉已经去过了,这次选了沙巴。当然,傻喵为了去西藏已经请过假了,这次就没有同行。

沙巴位于菲律宾南面,文莱旁边。从中国地图上看,中国南海牛舌线最下面就是。沙巴是世界知名的潜水圣地。当然,这次我们没有去最佳潜水场所——仙本娜,而是去的首府Kota Kinabalu,Kinabalu是附近知名的神山,KK的意思就是神山之城,中文叫做亞庇。没鱼虾也好,KK对面好歹有个东姑阿都拉曼公园(Tunku Abdul Rahman National Park),潜水也不错。不过有意思的是,理论上说这个公园坐落在南中国海。。。

去大马首先要换钱。令吉和人民币的比值大约在2左右,2元人民币合1令吉。令吉不在中国银行的服务范围之内,所以我们从货币兑换点换了一把令吉回来。据兑换点的服务人员说,我们提空了他们能约到的所有令吉。

种族宗教

KK当地伊斯兰教盛行,随处可见包着头巾的妇女和清真寺高耸的圆顶。当地饮食也是偏清真的,大部分地方只提供鸡肉和牛肉,偶尔能看到羊肉。

当地各种人群混杂,能明显看出区别。我碰到了很多华裔。据他们自己说,他们都是祖上三五代从大陆过来的。按时间算下来,差不多就是民国的样子。有很多当地族群,皮肤偏黑,一看就不像是中国人,却能说一口流利的中文。我曾经问过一个华裔,他说当地推行华语教育,有很多学校坚持华语教学——不限中国人。还有一些皮肤偏白,碧眼,我实在想不出解释,只能猜想是前殖民者后裔。

语言沟通

KK当地有几家手机公司,我办的是calcom的卡。17令吉一张,合35人民币左右的样子。里面有15令吉的费用,基本足够4天的所有短信和电话。如果在当地收发短信多的话,可以考虑入一张,比漫游便宜。道哥收发短信和电话不多,查下来是25人民币,办卡就亏了。

KK当地通行马来语和英语,但是华语也是非常盛行。基本上讲英语就完全能和当地人沟通。经常让人想吐血的是,你和当地人说着说这英语,他和你讲,OK,没问题。然后你发现——他会说华语。只是你和他讲英文,他就和你讲英文。而且这种现象不限于长的像华人的。。。

衣食住行

KK的饮食比较清真化,所以大部分都是鸡肉餐。去了几天,我们吃的最多的就是麦当劳和海滩BBQ。号称海滩BBQ,但是实际上并不算很好吃,也根本不是BBQ。主要食物是炒面,米饭和咖哩。唯一和烧烤有关的只有烤鸡翅。我们自己出去吃则经常去双天海鲜楼去吃海鲜大餐,里面的椰子布丁味道不错。卖椰子布丁的美女也很不错,我们中的某人很感兴趣。

吃东西当地司机和我们推荐加亚街。我们也就去吃了一顿肉骨茶。味道还不错,我带了一包药材回来烧着玩玩。

KK的出租并不好打,所以出门基本靠腿。幸好KK也不大,纵穿整个KK也不过半个小时不到的样子。只是KK作为前英国殖民地,这里的车辆行驶方向和大陆相反。因此经常担心车辆从意想不到的方向冲出来。

潜水

沙巴是潜水的好地方,但是要潜水的人需要注意。请务必在潜水的头一天电话预约。而且最后一天不要潜水(坐飞机前18小时不得潜水)。因此,推荐的行程是第一天看萤火虫(萤火虫是晚上看的,所以可以睡到中午,不受第一天到达劳累的影响),第二天去美人鱼岛,第三天去潜水。

即使要跟随去美人鱼岛的团队潜水,也请务必提前预约。这次上了岛我才知道,深潜是需要预约的。中计了,普吉岛那次完全不需要预约。

by shell at November 27, 2013 03:50 AM

November 26, 2013

@khsing

关闭ElasticSearch自动匹配

这几天在弄ElasticSearch来分析日志,突然有一天早上8:00之后的日志就进不来了,看了分析程序运行正常,服务也正常,只是ElaticSearch的日志增长很快,其中比较值得注意的就是这条了。

Caused by: org.elasticsearch.index.mapper.MapperParsingException: failed to parse date field [22-Nov-2013 12:24:30], tried both date format [yyyy/MM/dd HH:mm:ss||yyyy/MM/dd], and timestamp number with locale []

看起来应该是mapping的问题,对比了一下当前的mapping和之前的,确实有一些不一样,timestamp之前是string,现在成了date,本着调整一下mapping就可以的思路,调整了,开始有数据可以进来了,但是错误还是很多。

仔细看了一下,ES有一个date_detection的机制,得把这个给关了,停止他对时间字段的自动mapping。

CONFIG_DIR下放一个default-mapping.json就可以从cluster级别关闭了。

{
  default : {
    "date_detection" : false,
    "properties" : {
      "@timestamp" : {
         "type" : "date",
         "format" : "dateOptionalTime"
      }
    }
  }
}

by Guixing at November 26, 2013 04:18 AM