Shell's Home

lxde使用观感

Oct 2, 2011 - 1 minute read - Comments

前一段时间,雨苍问我有没有功夫参加台湾的lxde开发,做志愿者。不巧今年结婚装修,事情比较多。除了给debian贡献几个包练习一下,没有什么别的计划,就给推了。不过推归推,当时就看到了lxde的桌面,还挺不错的。 前几天,xfce又一次大升级,整个系统加了N多功能出来,顿时感觉太庞大臃肿了。贝壳喜欢的是精简有效的桌面,不是庞大的怪物——否则我不会用gnome/kde阿?尤其是贝壳的三台纯linux,一台上网本,一台atom的低功耗机,都是低资源量的。其余系统都是虚拟机。于是就策划换掉xfce4。替代品有两个,一个是lxde,还有一个是enlightenment,两个都是以轻量级而出名的桌面。不过杯具的是,enlightenment在做vnc测试的时候总是死机,所以压根没法用。所以目前的系统就花落lxde了。 关于enlightenment,有几点补充说明。一个是,这个东西在debian下的包叫做e17,不要直接找enlightenment。另外,他的bug是,在vnc下面可以用,但是如果进行setup,就会找不到模块,然后SEG FAULT。我试过用bugreport去汇报错误,但是邮件发不出去,现在还在找为什么。 好吧,题归正传,lxde做桌面,至少有以下几点好处。 轻量。我看到的内存消耗是20M,CPU消耗很低。简洁。整个系统没有太多废物组件,也没有满天飞的各种插件。除了有限的几个组件外,其余都是自己配置的。可变。目前我用terminator替代lxterminal作为标准term,用的挺好。 OK,下面简单说一下lxde使用过程中的几个心得。 pcmanfm不支持树形目录结构。这个太坑爹了。据说版本库中的已经改出来了,debian testing还得等等。所以我觉得还可以观望一下。lxlauncher不起作用。不过幸好我也不需要这个。这个据说是为了平板或上网本做的启动系统。我现在用的是launchy,是为键盘控设计的,挺不错。快捷键不支持编辑。需要你手工修改~/.config/openbox/lxde-rc.xml。具体可以参考这个。他里面提到的两个连接是openbox的wiki,分别是Bindings和Actions。注意,wiki上有些资料是错的!下面我会讲一下哪些需要修正。没有mail notification。我自己装了一个mail-notification,还不错。可惜没有邮件的时候,托盘区图标经常失踪,不知道为啥。反正来了邮件是会出现的。自动启动不自动。可以把desktop文件放入~/.config/autostart中。也可以在~/.config/lxsession/LXDE/autostart中写,每行一个程序名,不用&结尾,不是bash脚本。我用的是后者。 下面是快捷键的一些错误。 ToggleMaximize应当写成ToggleMaximizeFull。Desktop指令下面的to标签应当是desktop标签。

Vnc动态调整分辨率

Oct 1, 2011 - 1 minute read - Comments

vnc可以调整分辨率,这个很简单。 vncserver -geometry HxV 就可以设定纵横分辨率了。 但是vnc怎么动态调整分辨率呢?RDP可以根据连接时参数来调整分辨率,vnc好像没有这个功能吧? 最近贝壳需要在电脑上和上网本上同时使用一个桌面,于是碰到了这个问题。经过寻找,这个问题的答案是这样的。 vncserver -geometry 1600x1000 -geometry 1440x900 -geometry 1024x600 然后,在进入系统后,输入xrandr,可以看到你启动时设定的多个分辨率。再用xrandr -s N,就可以选择合适的分辨率了。 这个是X的randr扩展,需要vncserver版本在4以上。我的环境是debian testing,vnc4.1.1。欢迎大家测试。

又撞了

Sep 29, 2011 - 1 minute read - Comments

我都不好意思说什么了,中国网民都是预言帝阿。 大概看了一下新闻,我整理出来几个有关的新闻,按照时间线排列。 2009-12-22 上海地铁一号线一日内连发4起事故 2011-07-23 2011年甬台温铁路列车追尾事故 2011-07-28 上海地铁10号线列车开错方向 2011-09-27 地铁10号线追尾 我觉得比较值得关注的有以下几个问题: 上海地铁,一号线出过问题,10号线又出问题,加上温州动车,据说信号系统供应商是同一家,这是不是一个巧合? 地铁据说是改为电话闭塞后出现的问题,为什么?不会又像温州事故一样说不清原因了吧。 本次问题,温州动车,都是信号系统故障后人力操作导致的问题。人力操作会出错我们都知道,那么,信号系统损坏概率有多高?(很多时候,损坏后人力操作,没事我们就完全不知道了)平均可用时间标准能达到多少? 人工操作的指令是谁下达的?在下达前是否有过对调度室工作能力的评估?调度室是否有相关演练和经验?如果有,为什么会出错? 这次的事故赔偿机制怎么算?不能因为只伤不死就算了吧? 上次一号线事故后,上海地铁是否分析过问题,结论是什么,采取过什么措施。 十号线开错方向后,是否分析过问题,结论是什么,采取过什么措施。 这家信号系统供应商,还有提供哪些线路的信号系统,是否应当公开?(关于这点,可以看这个,上海地铁一,三,四,十,十二,十三是他们供应的) 地铁的安检系统是否还有必要,看起来地铁比乘客的包更不安全。 要保证系统的安全性,有两种思路。一种是自动系统保证绝对安全,不相信人的作用。如果自动系统出现故障,就全部停止运行。这个思路的要求是系统的工业级稳定性,例如电话系统。基本接近99.999%可用,合一年停机不超过5分钟。这个标准是妖怪,从二十到三十年的周期上看,可停机时间只有1小时多点。AT&T的工业级黄金标准好像也出现过6小时的停机——直接用光了70年的配额。所以现在基本都是只能保证到99.995%。 另一个思路,是保证机械自动系统出问题后通过受培训的人紧急处理,例如供电系统。大家知道供电系统损坏概率远远高于电话,而且稳定供电的成本太高。所以大部分政府都是提供停电预案,在紧急区域(医院,学校,部分宾馆)提供备用电源,在停电期间提供巡逻,等等。大家都知道停电的时候要拔掉电器设备,留一盏灯,等待供电恢复。 最稳定的思路,是同时使用两者。即保证自动系统的绝对安全,也持续培训人,例如火警系统。即使平时碰不上,也持续的训练如何处理对应,保证万无一失。 中国的铁路系统是哪个?中国的铁路系统是自动系统出问题后,用未经培训的人来替代。为什么不用培训过的?因为不出问题就没机会培训阿。

python内存不释放原理

Sep 28, 2011 - 1 minute read - Comments

在maillist里面看到无数次的有人问,python速度为什么这么慢,python内存管理很差。实话说,我前面已经说过了。如果你在意内存/CPU,不要用python,改用C吧。就算C不行,起码也用个go或者java。不过今天还是说说,python的内存为什么不释放。 首先,python的初始内存消耗比C大,而且大很多。这个主要来自python解释器的开销,没什么好解释的。用解释器,就得承担解释器运行开销。然后,python中的每个对象,都有一定的对象描述成本。因此一个long为例,在C下面一般是4个字节(不用int是因为int在不同平台下是变长的),而python下面至少是16个字节。如果你生成100W个对象,那么C的内存消耗是4M,python的是16M。这些都是常规内存消耗,搞不明白的就别问了,不再解释。 下面解释一下python的内存释放情况。 如果是C,通常是用long array[1024 * 1024]的方法来生成1M个对象空间。当然,实际这样是不一定能运行的。因为linux的默认栈空间是8M,而Windows默认栈空间只有1M。所以代码在linux下可以通过,而windows下会跑爆掉。怎么办?下面说。当这个函数执行完毕后,当RET的时候,会自动退栈,空间就会自动释放掉(虽然在逻辑上这部分空间还是保留没有释放的,然而空间不活跃了,不过统计的时候还是占用的)。当然,更好的办法是使用malloc。malloc会从系统中自动提取和管理空间,free自动释放。这样无论是linux还是windows,都没有栈空间不足的问题。free后就会自动交还系统(4M已经超过了交还的最大阀值,一般glibc不会自己闷掉不交给系统的)。如果你忘记free,这部分内存就会一直占用,直到进程退出未知,这就是很有名的内存泄露。 python下的情况更加复杂一些,python没有直接使用malloc为对象分配细粒度内存,而是使用了三层堆结构,加上三色标记进行回收。所谓三层堆,细节我们不说了,在源码阅读笔记里面写的比较详细。但是有一点需要我们记住的——当我们分配某个大小的内存的时候,内存管理器实际上是向上对齐到8字节,然后去对应的内存池中切一块出来用的。也就是说,如果我们运气比较差,申请了10个对象,偏偏每个对象大小差8字节。这样系统就要给我们分配10个堆,而不是刚刚好。如果你的对象粒度都比较散,那么内存开销比较大也不奇怪。 python下还有一个更坑爹的事情,也是大部分内存不释放的根本原因。在int/str等对象的模块中,有个模块级别的对象缓存链表,static PyObject * free_list。当对象释放的时候,压根不会还到池中,而是直接在free_list中缓存。根据我的搜索,python内部没有地方对此进行干预。就是说,一旦你真的生成了1M个数字对象,然后释放。这1M个对象会在free_list链表中等待重用,直到天荒地老,这16M内存压根不会返还。而且,int的对象缓存链表和str的还不通用。如果你又做了1M个str对象,他的开销还是会继续上涨。几乎所有的内建对象都有这种机制,因此对于大规模对象同时生成,python会消耗大量内存,并且永不释放。 解决的机制,基本只有用yield来将列表对象转换为生成器对象。列表对象会同时生成所有元素,从而直接分配所有内存。而生成器则是一次生成一个元素,比较节约内存。

uwsgi under debian

Sep 27, 2011 - 1 minute read - Comments

好了,debian官方的uwsgi总算出来了。包已经到了testing,stable暂时别指望了,等下一次release吧。这次打的包,比贝壳打的复杂多了。贝壳自己只打了python专用的包,debian官方的包将多个语言分别打成了plugins。 下面说说,使用debian官方的包如何做uwsgi发布,还是vhost模式哦。 首先安装uwsgi,uwsgi-plugin-python这两个包。uwsgi-plugin-greenlet-python也可以考虑,装不装看你的需求。 然后在/etc/uwsgi/apps-available/sites.xml下面写一个文本文件,内容如下: <uwsgi> <vhost/> <no-site/> </uwsgi> 再从/etc/uwsgi/apps-enabled/sites.xml链接过去,重启uwsgi服务,事情就搞定了。 默认的配置在/usr/share/uwsgi/conf/default.ini,可以看看是否都满意了。一般来说,master和no-orphans都建议打开,chmod-socket最高660,改成600应该也可以工作。贝壳的机器负载小,只用一个worker就够了,所以完整的配置是这样的: <uwsgi> <plugins>greenlet,ugreen</plugins> <workers>1</workers> <reload-on-as>128</reload-on-as> <vhost/> <no-site/> </uwsgi> nginx里面如此设定: location /asdf { include uwsgi\_params; uwsgi\_param UWSGI\_PYHOME /usr; uwsgi\_param UWSGI\_CHDIR /var/web/hosts; uwsgi\_param UWSGI\_SCRIPT main; uwsgi\_pass unix:/run/uwsgi/sites/socket; } 其中,我的程序放在/var/web/hosts底下,使用系统环境来运行(而不是virtualenv),主脚本(带applications那个)是main.py。unix socket和上文default.ini里面的socket正好对应上。 同理,我们其实还可以开多个uwsgi应用,只要放置多个xml配置就好。不过既然都采用了vhost模式,何必还开多个呢?这毕竟不是虚拟网站,要给其他人使用的。

合用两个路由器的几种方案

Sep 26, 2011 - 1 minute read - Comments

为什么用两个路由器?最常见的理由是延长信号。在超级大的场地中,中间放一个路由器,用四根线连接到周围的几个路由器上面,信号覆盖整个场地。这是最常见的理由。也有可能是因为你的主路由器LAN接口不足了。当然,也可能是因为蛋疼,或者其他原因。不论如何,为了在多个路由器上达到同时上网的目的,你有以下几个选项。桥接模式,路由模式,双层NAT模式。 我先解说一下一些基础的环境。我假定你有一个互联网线,有一个路由器的WAN口接到了互联网上面,这个路由器称为M。其他路由器分别称为S1,S2…。直接连接到M的LAN口的电脑称为ML1,ML2…,通过无线连接的就称为MW1,MW1…。同样,连接到路由器S1的LAN和无线的分别叫做S1L1,S1W1,类推。 1.桥接模式 这是你第一个应当尝试的模式,连接方法是路由器S1的LAN口直接连接路由器M的LAN口。这个模式不一定能够配通,原因是因为要求路由器S必须支持桥接模式。基于某些理由,很多路由器并不支持桥接。一般来说,有可能LAN口支持桥接而WIFI不支持。因此S1L1支持桥接成功的概率比S1W1支持桥接成功的概率高。如果你需要一台支持桥接的路由器,TP-LINK的TL-WR*系列路由器好像大多支持。希望大家补充哪款路由器支持桥接或者不支持。 桥接是将路由器S完全的作为一个交换机使用,所以你的ML1和S1L1在同一个网段,两者可以互相ping通,发送各种包,也可以看到对方的广播。这种模式一旦连接成功,连接模式是透明的。因此,应当关闭DHCP,只启用一台路由器的DHCP功能。或者最好手工分配IP。 严格来说,只有S是一个无线路由的时候,这个模式才叫做桥接。如果只做有线连接,这个模式应当叫做交换模式。 2.路由模式 路由模式,是一个比桥接复杂,效果好,但是用途相对比较窄的方案。接法是路由器S1的WAN口连接路由器M的LAN口,并且为S手工指定IP,再关闭S的NAT功能。M的网段和S的网段必须不为同一个网段,例如M配置为192.168.0.0/24网段,S配置为192.168.1.0/24网段。S的WAN口手工指定为192.168.0.2。然后在M1上配置人工路由,将192.168.1.0的所有包交由路由器192.168.0.2处理。并在S1上配置默认路由为192.168.0.1(M的地址)。 这个模式是将路由器S和M作为路由器使用。当S1L1发送包时,会被S1转发到M去处理。而M收到要发送给S1L1的包时,会交由S1处理。这一模式能够工作的基础是你能够控制M的路由表,并且S可以关闭NAT。通常情况下,这个S最好是OpenWRT/DDWRT。这也是为什么用途比较窄的原因,毕竟支持桥接的路由器好找,OpenWRT/DDWRT就相对小众了。 当这个模式连接完成后,ML1和S1L1在不同网段,但是两者可以互相ping通,发送各种包,却无法看到对方的广播。因此这种模式的效果比桥接好一些,因为地址范围更大,而且很容易隔离广播风暴。这种模式一旦连接成功,连接模式是透明的。 3.双层NAT模式 如果上两种模式都不工作,你就必须使用双层NAT模式。这种模式保证一定工作,但是在使用上比较麻烦,需要用户自行计算访问规则。 接法是路由器S1的WAN口连接路由器M的LAN口,并且将S配置为DHCP。M的网段和S的网段必须不为同一个网段,例如M配置为192.168.0.0/24网段,S配置为192.168.1.0/24网段。 S的数据包会被NAT两次再发到互联网上,要进行端口转发也必须配置两次。性能相对比较差,而且无法做NAT穿透。 当这个模式连接完成后,ML1和S1L1在不同网段,S1L1可以ping通ML1,但是反过来不行。因此,S1L1可以主动连接上ML1,而反过来不行。这种模式不是透明的,两者进行连接时必须考虑网络转换和端口转发。

密码管理规范

Sep 22, 2011 - 1 minute read - Comments

下面是贝壳自己总结的密码管理规范,大家可以参考一下。 概念解说 网络密码和本地密码。网络密码通常很难暴力攻击,尝试速度受到网络限制,而且尝试一定次数后还可能被管理员发现。而本地密码则相对比较容易攻击,我假定本地密码攻击可以达到每秒测试2\^30个密码。 密码长度推定使用如下计算方式。使用年数乘以攻击频率,得出攻击者在密钥使用期限内能尝试的最大次数。为了安全起见,尝试范围不应当超过总体密码空间的一定比例。以此推算出密码空间大小,进而推算出信息位数,然后还原为密码位数。 数字密码,字母密码,数字字母混合密码,大小写数字混合密码。数字密码的信息量是3.3bit/位,字母为4.7bit/位,混合为5.17bit/位,全混合5.96bit/位。 密码原则 一次一密。除了零级密码,不要为多个系统设定一样的密码。有些系统并不像我们想像的安全,一旦这个系统出问题,被还原原始密码,就会牵连到其他系统。 定期更换。没有什么密码能用一辈子。 写下来。因为一次一密,所以我们会有大量的散碎密码。不写下来是不保险的,写下来是不安全的。折衷一下,还是写下来,保存好吧。推荐用高级密码加密低级密码的方法,例如keepass。 生成型密码。用一个特定字符串+网站名,做sha-1然后取最后8位。这样的密码满足一次一密,不容易破解,不需要写下来,唯一的问题是你要现算… 零级密码 零级密码是有些不需要保护的情况下,又非设定密码不可。对于这种情况,你只能设定一个不算密码的密码。例如常用机器的用户密码。这些密码可以通过livecd/liveusb轻易修改,因此没有一点保密价值。 零级密码不需要安全性和保密性,因此好记就行。例如111,222,选一个常用的,爱用多久用多久。 低级密码 低级密码是用于保护一些你不希望别人看到,然而别人看到并没有直接损失的内容。例如家里机器的性能数据,普通相册的访问密码。这些内容被别人看到不会产生伤害,然而无成本的放出这些内容有潜在的风险,或是你自己主观意愿希望保护,内容安全性要求又不特别高。 我假定低级密码在网络上会受到100次/年的攻击,本地密码会受到1小时/年的攻击,可用时间五年,穷举空间不超过总密码空间的1/1000。 网络密码的攻击信息量为log2(100 * 5 * 1000) = 18.93bit。使用数字密码应在6位以上,字母,混合,全混合应在4位以上。 本地密码的攻击信息量为log2(2\^30 * 3600 * 5 * 1000) = 54.10bit。使用数字密码在17位以上,字母在12位以上,混合在11位以上,全混合在9位以上。 结论,低等级的密码长度小,使用数字也并不难记。推荐使用4位以上字母(反正混合使用长度也没有下降),不要使用常见组合还有单词。推荐方式是将自己喜欢的一句英文首字母简写前后颠倒使用。例如:I will be back,对应密码bbwi。 中级密码 中级密码用于保护一些你不希望别人看到,别人看到会对你产生损失的内容。例如你的帐薄,日记等等。中级密码使用时,最主要的风险已经不来自于密码本身,而是使用密码的环境。包括电脑是否安全,中途网络是否安全,旁边人的肩窥攻击。 我假定中级密码在网络上可能会受到10000次/年的攻击,本地密码会受到100小时/年的攻击,可用时间1年,穷举空间不超过总密码空间的1/100000。 网络密码的攻击信息量为log2(10000 * 1 *100000) = 29.90bit。使用数字密码应在9位以上,字母在7位以上,混合应在6位以上,全混合应当在4位以上。 本地密码的攻击信息量为log2(2\^30 * 3600 * 100 * 1 *100000) = 65.07。使用数字密码在20位以上,字母在14位以上,混合在13位以上,全混合应当在11位以上。 结论,中级密码开始,数字密码的位数就太长了,人类记忆很难记得。推荐使用8位以上字母密码,产生方式同上。 高级密码 高级密码用于保护一些有价内容,例如公司标书,银行账户。高级密码要注意更换,最长不要超过半年。 我假定中级密码在网络上可能受到1000000次/年的攻击,本地密码会受到8700小时/年的攻击,可用时间0.5年,穷举空间不超过总密码空间的1/10000000。 网络密码的攻击信息量为log2(1000000* 0.5 *10000000) = 42.19bit。使用数字密码应在12位以上,字母和混合应在9位以上上,全混合应当在8位以上。 本地密码的攻击信息量为log2(2\^30 * 3600 *8700* 0.5 *10000000)

悲崔的六类线

Sep 21, 2011 - 1 minute read - Comments

大家知道,贝壳家里用的是千兆交换机对吧?最近贝壳在装修(好吧,回头看情况,也许有装修手册出来),所以——布线的时候打算用六类线。 先普及一下常识,六类线和超五类的区别在哪里? 百兆网使用的是五类和超五类线,最大长度100m,接线规范使用EIA-768B,实际使用1236四根线进行通讯,频率100MHz。考虑双工后,可以在整根线上提供100Mbps的速率。而千兆网使用六类线,接线规范也是EIA-768B,但是实际使用了12364578全部接线(所以六类线必须全部连通,否则掉速,不要用五类的经验想当然)。频率250MHz,在整根线上可以提供1000Mbps的速率(别看我,我也觉得有点问题,资料来源wikiCAT-5CAT-6)。 为了在中间没有四根地线作为缓冲的情况下支持高速的数据传输,六类线通常使用22-23AWG的铜芯制作。尽管标准上允许24AWG的六类线出现,但是这通常是不堪使用的。而五类线和超五类大部分都是24AWG的线芯,粗细是0.51mm。23AWG线芯粗细0.57mm,22AWG粗细0.64mm。而为了隔离串扰,六类线中心通常有旋转的十字龙骨,将四对缠绕线分割在四个区域,防止电容效应干扰。 OK,有了基础常识,我们可以讲一下京东的问题了。他们提供的线问题其实很简单。有一箱线在中间有部分区域十字龙骨缺失。 如果我买的是普通线就算了,5元多一米的秋叶原线,在京东这种商城,居然会在中心位置龙骨缺失。我很怀疑我埋下去的另一箱是否也有类似问题呢。 更郁闷的是,我打给京东,他们的客服不道歉就算了,也没个活人出面解释一下这个是什么问题。就只有“你可以退货阿”,“你这样就可以退货拉”,的提示。退退退退你妹阿,尼玛另一根线回头出了问题我得重新埋线呐。更可气的是有个客服脑子堪比芙蓉姐姐,给我一个厂家电话,让我打给厂家。我说如果厂家不予解决呢?她说,你可以再打4006065500转3。我说那不就是你们的电话么?她说,你可以再打4006065500转3。我说是不是再打到你们这里?她说,你可以再打4006065500转3。。。尼玛你是鹦鹉阿,直接说再打我们电话不就完了么。再说了,你给我的方案就是打给厂家,厂家不解决,再打给你,你再咋办?哦,对了,这时候就不是你办了。真是好办法。 可见在天朝这种地方,产品质量是完全不用关心的,有退货就是最大的慈悲了。至于产品造成了后果,赔偿什么的。售后经理笑脸迎人,可以阿,有检验结果我们就赔。问题是TMD国家质检中心不给力阿,不但价格贵,而且很多事情根本不检。你不信在07年拿瓶三聚氰胺奶过去,就算清清楚楚的告诉他们有什么问题,得到的答复还是——抱歉,我们没这个检验项目。再说检验通过,厂家立刻变脸,抱歉,这个我们有规定,只能赔偿多少。然后你只能进行漫长的“调解-仲裁-一审-二审”过程。厂家有的是时间精力,不怕玩不残你。就算你侥幸通过,终于能获得赔偿,听上去天价的赔偿还不够你的时间成本。更不谈有些事情,损失十多万,按国家规定赔偿只有不足千元——“因为国家就是这么规定的”。

给初创小公司的几句话(四)

Sep 16, 2011 - 1 minute read - Comments

第四个故事来自一个朋友的笑话。说某人从一家公司辞职了,朋友问说什么情况。某人说,和老板相处不来。老板看到有人上班看网页,就出了条规定,不许上班时间看网页,否则罚款。看到有人带朋友进办公室,就出条规定,不许上班时带朋友进办公室,否则罚款。上个月老婆出差,没人照顾家里的仓鼠,带去两天,出条规定,不得带宠物上班。某人情感受到了强烈的伤害,所以愤而辞职。 其实说起来,这些事情都不是什么大事,鸡毛蒜皮到了我们可以当笑话说的地步。细究起来也确实是员工应当执行的,属于正常雇员的基本素养。不过如果您自己开家公司,照着上面的做,搞不好手下还真就一堆辞职的。 从某种意义上说,这是一个心理问题。在IBM,或者Oracle这种大公司,出现这些条款没人觉得有什么不对,关键在于两点。一方面,大公司本身就给人一种正儿八经,板着个脸的印象。员工进公司的时候,就知道自己随时会碰到各种狗屁倒灶的规定,有一定的心理准备。小公司通常老总天天见,搞不好下班还一起吃饭喝酒,上班的时候板起脸来做规矩,情感上受得了受不了就不好说了。另一方面,大公司的规定相对完备,什么可以什么不可以都规定的非常详细。小公司难免挂一漏万,天天改规矩,确实不怎么好看。 反过来说,这也是初创公司对大公司的优势。在大公司里,管理层显然不会留意到每个人的特性,并且针对性的管理。然而初创公司就那么几号人,大部分都是熟人。要针对管理不是一件不可能的事情。老婆出差,家里仓鼠可以带到公司,顺便睡在公司做程序得了,反正家里也没人。诸如此类的事情并不怎么难做。当然,当初创公司上了一定规模(推荐大概是10-30人)后,管理转换必然要产生阵痛。然而也远好过在三两个人的公司里面规定四五十条的规范。

gnupg的基础概念

Sep 15, 2011 - 1 minute read - Comments

上次gnupg签名写完后,雨苍跑过来问我gnupg里面的一些细节,讲,为什么不写清楚呢?我说不是写过一篇gnupg基础么?回去翻blog,居然没有!好吧,那就现场写一篇gnupg的基础概念。 非对称密钥 gnupg是一种签名/加密系统,通常而言,多数被用在mail和deb包签署上。普通加密程序的最大区别在于,gnupg是一种公钥/私钥结构。 我们简单点说,你可以用gpg --gen-key生成一个密钥对(是的,一次一对密钥),一个密钥对包含一个公钥和一个私钥。公钥是公布在网络上的,私钥自己持有,并且可以加一个密码,以防私钥泄漏。学过非对称密码体系的同学应该知道,公钥加密,私钥解密,私钥加密,公钥解密。因此,这个密钥对可以用于签署。方法是,对你的目标数据进行哈希,然后使用私钥加密这个哈希,得到签名数据。如果别人可以用你的公钥解密这个签名数据,然后和目标数据的哈希对比,那么这个数据就一定是私钥签署的。 附加资源 下面是最精彩的地方。一个密钥对里面,其实不仅包含一对密钥,而是包含多对。刚刚生成的公钥(pub)和私钥(sec)这对,被称为主密钥。而除去主密钥外,还可以加入三种资源,子密钥,uid,签名。 子密钥是另一个合法的对称或者非对称密钥。子密钥的常见用途是延长密钥的可用期,或者提供不同强度的加密(通常是减弱)。 密钥长期被用于加密数据后,可能会被已知明文攻击,因此一般密钥都有一个合理的使用周期。对于大量加密数据的人来说,这个合理使用周期可能比较短。看过上一篇互相签署的应当知道,对一个密钥每三四年乃至一年就签署一遍太麻烦了。因此,你可以使用子密钥。这个密钥的使用和吊销就比主密钥更加方便,生成一个,用六个月,然后废弃。而使用主密钥签署过的子密钥,同样可以认证该密钥属于某人。 uid则是认证这个人的合理名字,主要是姓名,昵称,邮箱。通过主密钥签署,别人可以认可这个网络身份真实的属于你。 签名则是别人对你的uid的认可。一般一个uid上可以有一个或者多个签名(至少需要自己主密钥的签名)。 常见参数选择 主密钥过期时间,建议选择5-10年,推荐10年。因为主密钥过期后需要重新签署,每三四年就重新签署一遍你的密钥实在是太麻烦了。 主密钥长度,我建议选择你能选择的最长长度。因为主密钥有相当长的过期时间,过短的密钥很快就不实用了。在2000年的时候,1024位还是比较安全的,但是2009年,RSA-768被成功破解,威胁到了1024位密钥的安全性。目前debian推荐密钥都是4096位长。至于对此造成的计算压力增加,你可以通过子密钥来解决。 主密钥一般是RSA的,gpg -k可以看到4096R之类的标示。 公钥的网络管理 上面说到,公钥需要公布在网络上。现在网络上就有一种专门的服务器,用于提供公钥的上传和管理。我用的是pgp.mit.edu,很有名(主要是比较短,好记)。你可以在上面放置一个你的公钥,里面附加各种uid和签名,吊销凭证,等等。 文件签名 密钥对可以对文件进行签署,生成分离的(.sig文件)或者内含的签名。签名方法是gpg -s,你可以用gpg --verify来验证。 FAQ: Q: 有什么机构对gpg进行认证么? A: 这个真没有,虽然你可以从公钥服务器上获得很多人的公钥,但你无法确认他们的身份。确认身份唯一可靠的办法就是线下交换fingerprint并且签署。作为替代,完全信任和勉强信任也部分的可靠。 Q: 签署和加密有什么区别? A: 签署表示这个内容是被你确认过的(由你发出或者经你许可),所有人都能看到。加密表示这个内容只有你能看到,所有人都能发出。如果你打算给一个人发送一个内容,内容是经你确认的,并且只想被他看到。你可以同时签名和加密。 Q: 签名可以伪造么? A: 这个应该不行,如果可以,你可以写个paper,全球奖金就数百万美元,更不提领域上的名声。 Q: 国家可以调动专用服务器来进行破解。 A: 目前已知破解的最长的密钥是RSA-768,长度768bit,因此1024位密钥有可能被政府机关破解。然而破解难度随着位数增加以几何级数增长,因此2048位的破解目前还遥遥无期。目前而言,2048以上长度的密钥还是无解的。 Q: 真的不行么?我知道各国军队都有保密的研究成果。 A: 如果你相信所谓的“秘密成果”,我也无话可说。仅公共领域流通的成果而言,离可接受的破解方法还差很远。目前已知最好的算法是普通数域筛选法,有希望成为可接受的破解方法的是基于量子计算机的Shor算法——不过量子计算机还没有制造出来。 Q: 既然2048位密钥不可破解,为什么还要选择4096位? A: 一个不幸的事实是,虽然破解难度随着位数增加几何级数增长,然而破解速度随着时间流逝也在几何级数增长。如果你打算长期使用,还是使用4096位的比较保险。