delphij's Chaos
选择chaos这个词是因为~~实在很难找到一个更合适的词来形容这儿了……
去年 公司给换了一台 Asus 笔记本,不过因为这个笔记本本质上是个台式机,不便于携带,因此我又买了一台 MacBook Pro 来自用。今年一月份到匹兹堡出差,发现还是需要一台能随身携带的笔记本,所以公司又订了一台 Lenovo T530。
我在 2008 年曾经对 Lenovo 产生了极坏的印象,并决定三年之内不买任何 Lenovo 产品。五年之后,我再一次成为了 Lenovo 笔记本的用户。
这款 T530 大体上沿袭了传统的 ThinkPad T 系列的设计,采用 Ivy Bridge 的 Core i5 处理器,可以选择内建显示和 nVidia 独立显卡。
系统预装了 Windows 7 操作系统,它唯一的使命是帮助升级一系列固件到最新版(主要是 UEFI BIOS);(题外话:不知道是不是现在品牌机都这毛病,上来推销一大堆东西,如 Office、Symantec Anti Virus 等等,并想尽一切办法让"购买"或"免费试用"看起来像是用户必然的选择,十分讨厌)。接下来,用一台 FreeBSD 系统上做的 U 盘启动,删掉现有分区,重做 GPT、建立启动分区和加密分区。
Lenovo T530 预设采用的是 UEFI 启动模式。目前,FreeBSD 尚未提供 UEFI 引导加载器(但这个项目已经 接近完工 了),因此采用 GPT 分区的磁盘会被 UEFI 固件认为是采用 EFI 启动(超微的 UEFI 固件没有这个问题)。因此,需要进入 UEFI 固件将引导模式改为 Legacy only。
目前初步使用发现一切正常。T 系列还是沿用了 Intel 以太网卡,没有学 Dell 用更便宜的 Broadcom 控制芯片,实测局域网可以跑满 1000Mbps 的带宽。无线网络方面因为选的是 Intel Advanced-N 6205,因此没有兼容方面的问题(ACPI模块可能需要稍微小修一下,等测试之后再说)。总体来说,这个笔记本跑 FreeBSD 应该是没有问题的。
Read more...今天在邮件列表里看到 John Nagle (就是发明 TCP Nagle 算法的 那个 John Nagle)提到希望 OpenSSL 提供一些帮助自动检测中间人攻击的 方法。简单地说,因为中间人攻击会改变双方看到的加密流(密钥变了),因此,如果上层协议包含了加密流的某些特征,攻击者想要实施中间人攻击的成本就会大大增加。他同时举了一个例子,一种早期的加密电话会在话机上显示从密文开始的部分计算的两位数字,而通话双方则通过通话来确认数字相同,这样,中间人攻击的实施者就必须解析语音并替换掉相关的字词来避免被发现。
简单的例子是,比如准备发出 HTML/XML 之前,首先发出它们在加密之后的密文的 hash。攻击者如果简单地截获并重新加密文档,则攻击会被立即发现;如果缓冲并重新计算结果,必然会引入延迟;如果事先准备好文件并做好计算,则需要在看到文件之前就准备好这些资料(不过实际应用中,攻击者很可能会选择这么做)。这些都会增加实施中间人攻击的困难。
文中提到的马里兰州大学的论文也值得一读。
Read more...试了一下这个基于 CLucene 的全文搜索,似乎还不错。这里记一下过程。
首先是给 dovecot 安装 Lucene 插件,用 FreeBSD port 来安装的话,只需 make config,选择 LUCENE 然后 portmaster dovecot 即可。
配置也还算容易,我之前已经做了索引与数据分开,因此并不需要单独的配置,只需在 dovecot.conf 中增加:
plugin {
fts = lucene
# Lucene-specific settings, good ones are:
fts_lucene = whitespace_chars=@.
}
然后重启 dovecot,运行 doveadm index -A ‘*’ 就行了。注意,-A需要userdb的支持。
日常维护方面,目前 dovecot 预设是在搜索的时候重新抓取索引,而邮件送达时则不会做任何其他处理。我目前用的解法是让 cron 每隔 11 分钟跑一次 doveadm index -A INBOX 来重做 INBOX 的索引。另外,用 FreeBSD 的 periodic 每天更新一次全部索引 (doveadm index -A ‘*’),并在每月做一次 doveadm fts rescan -A(这个其实并不是必须的,主要是防止出现直接操作Mailbox时出现不一致的情况)。
Read more...来自这里: http://www.8z1.net/a1360766206.html
作者 namcoz (namco) 看板 Gossiping
標題 Re:
為什麼唐三藏一直都不相信悟空說的話??
時間 Wed Feb 13 14:36:46 2013
孫悟空就是知道怎麼做的研發技術人員
但是如果讓孫悟空直接跟代表老闆的唐三藏講說該怎麼做
那麼唐三藏到最後都會很不爽
因為孫悟空知道怎麼回事 所以他會堅持一定要照他所說的做
但是唐三藏其實是不瞭解技術細節的
他會覺得孫悟空講話太衝動太偏激
而代表主管講求溝通的豬八戒和代表業務或庶務講求和諧的沙悟淨
也同樣會覺得孫悟空對唐三藏不禮貌
又因為不了解狀況所以會覺得孫悟空要他們只聽他一個人太自以為是
最後下場就是孫悟空被孤立
而唐三藏則是採用兼顧到和諧與溝通但卻是後患無窮的的豬八戒建言當政策
當然這個政策也會受到講究和諧的沙悟淨的支持
此時孫悟空在自己盡心盡力為團隊著想卻受到如此的對待
一定是忿忿不平
再加上善於溝通的豬八戒暗地裡向唐三藏指責孫悟空既衝動又沒禮貌
破壞團隊和諧 於是孫悟空就會被唐三藏叫過去訓一頓
在極度不爽之下 孫悟空就回家吃自己
等到豬八戒錯誤的政策發生問題以後才急叩孫悟空來救援
為什麼這種迴圈會一再的發生?
因為即使後來證明孫悟空是對的
他們也不會覺得豬八戒的政策是錯的
只是覺得豬八戒的政策需要做一些調整
加入孫悟空的小部分建議
因此真正發揮作用的是團隊集思廣益討論出來的決議
所以同樣的情節才會總是重複的發生
這篇我要說的是:
1.如果覺得這篇的比喻很眼熟 沒錯 我就是在罵你這個主管是豬八戒
2.這是解禁後我第一次在八卦板回文 感謝德政
–
Read more...现在的这个房子是在 1977 年建的,分上下两层,面积大约 2000 sqft。给房子加热的煤气炉是在房子建造时安装的,已经超过使用年限很久了,加上风扇有一些问题(在停止加热之后,风扇长时间不停转),在咨询了几家维修的价格之后决定直接换一个新的,顺便换成 Nest 来控制。
在 San Jose,由于涉及煤气管线,因此在更换煤气炉时应从市政府那里取得许可。目前,这个许可的价格是 $280。这个许可是由更换煤气炉的公司取得,在施工过程中需要张贴在房子外面。
我找的这个煤气炉维修公司是 TFF HVAC,它提供一年的warranty。更换煤气炉本身需要大约6-7个小时,如果需要更换输热管线,可能会需要一天半的时间。更换输热管线的好处是可以让房子的上下层温度分开控制,从而节约能源,但费用要比换煤气炉本身还要高。由于房子不大,所以我选择的是:一个95%效率的双档80K BTU煤气炉(Carrier Performance model 59TP5A080E17-16),但没有重铺输热管线。
煤气炉的日常维护主要是每隔几个月换一次滤网(这个型号的滤网在顶部,气流方向冲下),这个和车的日常保养类似,如果不换会影响室内的空气质量,并降低煤气炉的效率。另外,通常煤气公司会每年做一次检查。
lordhong 推荐的 Nest 初步试用了一下,感觉还不错,特别是它的账户管理等等功能设计的相当贴心,例如注册账户之后直接就会询问说"这个是不是你家的Nest设备",而添加时需要在设备上物理确认一下。
具体这次工程的节能减排效果如何,还要看过几天的 PG&E 数据才知道。
Read more...正好聽到這首 “Somewhere Only We Know”:
I walked across an empty land
I knew the pathway like the back of my hand
I felt the earth beneath my feet
Sat by the river and it made me complete
Oh simple thing where have you gone?
I’m getting old and I need something to rely on
So tell me when you’re gonna let me in
I’m getting tired and I need somewhere to begin
转自 Techweb:据一位不愿透露姓名的程序员说,基本上所有项目经理的所有要求都能总结为下面这样一幅对联儿—-上联:多态重构模块化;下联:注释解耦跨平台。横批:无Bug…
Read more...截止到目前为止, FreeBSD 基金会共募得本年度捐款 $461,119,距本年度的预定目标 $500,000 还差 $38,881 美元。今年 FreeBSD 基金会资助了相当多的项目,包括 Pawel Jakub Dawidek (pjd@) 的 Capsicum 框架、分布式审计服务 auditstd、与我厂一起资助了 Bjoern Zeeb (bz@) 对 FreeBSD IPv6 协议栈的性能剖析、Edward Tomasz Napierala (trasz@) 的在线 UFS 扩容,作为中介机构接受了 Semihalf 的 NAND 闪存文件系统和存储棧,并资助了与此相关的移植工作。此外,FreeBSD 基金会也资助了全球范围内与 FreeBSD 开发有关的一系列会议,包括欧洲的 EuroBSDCon、亚洲的 AsiaBSDCon、加州 MeetBSD、加拿大 BSDCan、澳大利亚的 BSDDay 等,并在硅谷和剑桥大学分别举行了 Vendor Summit 和 Developer Summit。
FreeBSD 基金会每年会增加 10% 到 25% 的资金投入,这些投资的成长离不开广大 FreeBSD 用户和开发人员对于基金会的直接资助支持。作为符合美国税法 501(c)3 条款的公益非盈利慈善法人,在美国境内的捐款人通常都可获得全额联邦应税收入抵免。
捐款网址: http://www.freebsdfoundation.org/donate/。
其他信息请参见 捐款将用来做什么、基金会2012年12月公告、如何申请资助、基金会财报。
Read more...我回国之前, FreeBSD 安全团队内部正在准备一项重要的安全公告,不过这次不是由于 FreeBSD 的代码本身,而是由于 FreeBSD 项目集群中的一部分受到了入侵。这份公告后来于 11 月 17 日正式 发表。
经过事后分析,这次入侵,最早可以追溯到在今年大约9月的时候的一次针对某家公司的入侵。攻击者通过穷举的方式获得了这家公司一台机器的 root 账户,并获得了对应的 master.passwd 文件。根据事后的日志分析,攻击者应该是通过离线破解的方式得到了这台机器上所有用户的密码明文(旧式 FreeBSD 系统预设的散列方式是 salted MD5),并以这台机器为跳板扫描了一系列的其他系统,并找到了一位 committer 的未经保护的 ssh 私钥。这个私钥令攻击者获得了另外一台服务器的权限(其中包括一台机器上的 root 权限),并在那台服务器上进一步获得了另外一位 committer 的未经保护的 ssh 私钥。
那位 committer 的 ssh 私钥拥有 FreeBSD 用于联编预编译包的 Pointyhat 集群的 root 权限,而这个集群尽管和 FreeBSD.org 集群在一定程度上是隔离的,但在最初建立时,为了方便,以只读方式挂载了 FreeBSD.org 集群所有用户 /home 目录的 Filer。由于两组集群上都启用了内核审计机制 (audit),集群管理员发现,有人以 root 的身份访问了部分用户的 /home 目录,并很可能复制走了一些私钥文件。
至此,我们认为整个集群已出现了重大安全风险,应立即停止有风险的服务器的运行,并根据备份对全部文件进行审计。除了切断了大部分服务器的电源之外,扫描并停用了所有在 FreeBSD.org 集群上存有私钥的公钥的登录权限,对某些系统上运行的操作系统替换成了经过审计的 -CURRENT。
由于时间关系,不可能对每个二进制包都重新做审计,因此比较简便的办法,便是全部删去,从备份中恢复没有问题的,并重新联编其他的二进制包。为了尽快恢复服务,这次经过讨论还做出了准备提前淘汰 CVSup 的计划。
公众可见的变化包括:
我从这次事件中学到的教训是:
Read more...这次回北京之前的周末,FreeBSD安全团队发表了内部通知,发现 FreeBSD.org 有些机器被入侵,最近终于做了全面披露了。目前,基本的代码审计和攻击检查已经做完,部分机器还在重装的过程中。
对 FreeBSD 这样的开源项目来说,在基础设施遭到攻击之后,首先必须被怀疑的便是有可能有人在代码库中植入了新的后门。由于代码量十分巨大,逐行审计是非常不现实的。由于 FreeBSD 在 BSD 时代即采用了版本控制系统(最早 BSD 时代是 SCCS,FreeBSD早期是CVS,现在是 subversion),因此,每一行代码的来源,包括作者、具体的修改时间,以及为什么那样修改等等,都可以很容易地查找到。
FreeBSD 采用了许多种不同的方法来同步修订历史,这包括了旧式的 CVSup、通过邮件的 CTM,以及 svnsync。CVSup类似于rsync,但是是为 CVS 优化的。FreeBSD 的 CVS 代码库之前是通过 SVN export 出来,然后通过CVSup发给所有的下游镜像,其好处是比rsync节省带宽和时间(因为CVSup会记录修改的文件信息,两相比较便不必完全传送文件的 stat 数据了),缺点和 rsync 一样,如果源站点的数据出了问题,备份也会被修改,而且是不可逆的。CTM和svnsync都是类似会计记账的方式,也就是说一旦有了修改便不可反悔(CTM更通过邮件发出,从而可以被第三方备份服务永久性记录),从而便于审计。
所幸的是,目前为止的调查中,并没有迹象显示 CVS 代码库或 subversion 代码库中混入了任何未经授权的变动。为了保险起见,FreeBSD.org 的管理员将 cvs 改为从 subversion 完全导出(因为 svn 的审计比较容易)覆盖,以避免某些没有检测到的问题给用户带来影响。
我们能够从这个事情中学习什么教训呢?我想,最重要的是,备份应该采用和源数据不一样的更新、删除逻辑,因为这样才可以知道具体发生了什么变化。也就是说,数据源这边在备份那边的权限应该是不能改变历史记录数据的,比如只允许添加,等等。
关于这次入侵的具体情况,等有时间再写出来。
Read more...