SSH+KRB5使用IP地址登录的问题

Kerberos 是一个很方便的 SSO 方案,但比较恶心的是,如果不建立一套 DNS 域名系统来做主机的正向解析和反向解析,那么 Kerberos 是用不起来的。不光如此,使用中如果不注意,修改配置时会导致无法登录。这些问题有

1. 修改 hostname 导致名字不匹配
2. 目标服务器的 /etc/hosts 里含有自己 IP 的记录的第一项和 DNS 正向解析结果不一致
3. 登录源主机或服务器的 /etc/hosts 里有目标服务器的 IP 的记录,且和 DNS 正向解析结果不一致

如果有很大的服务器集群,且服务器分布在多个 IDC,则要维护一套 DNS 来进行解析,并保证内网失效时还能从外网访问,管理成本很高;此外,还要不断应付各种错误配置导致无法登录的事情。如果能直接用 IP 地址登录,即使集群的 DNS 解析有问题或主机配置有问题,但因为只需要正确正向解析 kdc 即可正常登录,kerberos 客户端本身支持多 kdc,管理成本很低。

在互联网上,DNS PTR 记录并不总是能受使用者的控制,无法和 A 记录一致更为常见,MIT kerberos 依赖于 DNS PTR 记录的特性限制了它的使用场景。为了解决这一实际问题,MIT kerberos 加入了 rdns 配置项,可以关闭反向解析。但这个选项似乎并不能有效工作,至少在较新的 Linux 上是如此。如果在 /etc/krb5.conf 中使用“rnds = false”,在 kinit 已经获得 k5 tgt 的情况下,形如 ssh username@hostname 的登录能成功,但是 ssh username@host_ip_address 的登录访问还是会失败,-vvv 的相关错误信息为

“debug1: Unspecified GSS failure.  Minor code may provide more information
Cannot determine realm for numeric host address”

粗看起来,这是反解失败造成的。但是,Windows 下 putty + kfw-3-2-2 和 OS X 10.6 下 ssh + krb5 可以正常登录,所以这个 Linux 下的反解行为不是必须的,看起来很奇怪。

为了解决这个问题,起先我测试了 GSSAPI 相关的 SSH patch,发现没解决问题,跟踪后发现是 krb5 运行库的问题。在 Linux 下,resolv 库的一个实现 bug 会引起 krb5 的 rdns 设置无效,编译了 glibc 发现没解决问题。随后检查 krb5 库本身,1.10.2 试图解决但没解决干净的问题有 patch,我测试了还是不行。

最终,跟踪到 krb5_get_host_realm() ,它调用 krb5int_clean_hostname() 来,在 host 为 IP 地址且关闭反解(rdns = false)时,krb5int_clean_hostname() 返回 KRB5_ERR_NUMERIC_REALM (因为无法反解到域名然后通过域名映射到 REALM)。在 MIT kerberos 1.10.x 里 krb5int_clean_hostname() 返回错误会让 krb5_get_host_realm() 直接返回错误;较旧的版本如 kfw-3-2-2 里,krb5_get_host_realm() 并不理会 krb5int_clean_hostname() 的错误,而是继续后续的流程。在 GSSAPI 的验证环节,如果有正确的 principal 且被授权,host是 IP 地址也是能通过验证的。

解决方案很简单,希望官方版本能很快并入这个改动: http://mailman.mit.edu/pipermail/kerberos/2013-April/018810.html

MIT kerberos 只支持 domain 到 REALM 的映射,而不支持 IP prefix 到 REALM 的映射,是历史遗留下来的,引起这个问题的根源问题。虽然这个问题并不大,但对于登录到多个 kerberos REALM,这些 REALM 没有交叉信任,且无法在验证时交互选择 REALM 的应用场合(比如 Linux 下的 ssh 登录),IP prefix 到 REALM 的映射能解决使用上的不便。

Nexus 7 翘屏问题的简单解决方案

Nexus 7 是一款很好用的 Android 平板,由于控制成本的原因,部分产品出现了制造瑕疵,其中,翘屏问题最为多见。

翘屏问题网上有很多解释。其中一个是很有误导性的,即安装屏幕的螺丝松动。对应的解决办法是打开后盖,拧紧螺丝;有的还建议在螺丝孔下方的缝隙中垫上一定厚度的纸片或塑料片。但这个方法实际解决不了问题。打开后盖多次后,会因为后盖松动,使用中发出让人不快的响声。

翘屏真正的原因是屏幕是使用工业双面胶粘到机身内部框架上,粘连不牢。框架材料是工业塑料而不是更为坚固的合金,塑料本身的弹性变形以及使用工程中受热引起的变形,会导致粘连部分脱落,发生翘屏。机身内部框架设计左边窄右边宽,所以左边相比右边粘连面积小,发生翘屏问题大都是左边。发生翘屏,除了设计、材料等本身的原因,还和生产过程有关。粘连需要稳定足够的时间,而生产中可能时间控制没有做好;温度控制也可能是问题所在,导致装配时胶的粘性不够而不牢固。

解决这个问题有个简单的办法:使用家用干发吹风机。将吹风机调到低温或中温档(视吹风机的档位设计而定),使吹出的风温度在 50-70 度左右,控制好吹风机出风口和 Nexus 7 之间的距离,向 Nexus 7 的屏幕吹热风,吹风时注意摆动吹风机,使屏幕受热较为均匀。用手触摸屏幕,确保屏幕温度处于烫手但还可以忍受的程度,然后保持住这个温度,这样屏幕后面的双面胶会软化,用手指按屏幕翘屏部分,确保其和框架粘连,但要控制好手指压力。持续一分钟到两分钟左右,屏幕后的双面胶就应该完全粘连好。关掉吹风机,手指在屏幕边轻轻按压,待屏幕自然冷却。放置一小段时间后,就可以正常使用了。

另外,后盖的嘎嘎异响问题,装上保护套以后多数可以消除。

2012-09-17 更新:大陆可以拨打免费客服电话 400-6006655 按提示按键 2-3 转到 E-PAD 售后服务,提供 SSN 号(在保修卡上)来确认能否保修,然后会提供一个最近的售后服务点。

术语 Tethering Hotspot 的翻译问题

Tethering Hotspot 不是一个新术语,在 iPhone 流行以前这个术语就出现了,iPhone 流行以后,这个术语被更多的人知道。

Tethering Hotspot 是指用 wifi hotspot 的形式,给多个设备分享无线接入,无线接入可以是 2G 的 GPRS、CDMA,3G 的 WCDMA、CDMA2000,4G 的 LTE 等。这个术语包含显式和隐式两方面的信息。显式的是 hotspot ,是其提供服务的形式,有的时候还会显式地增加 wifi 以和其它领域(比如社会学)的 hotspot 相区分;隐式的信息是 tethering 暗示另外一端接入到移动数据网络。

可惜的是,中文圈里这个术语的翻译是个看起来解决实际上没解决的问题。比如,今天从做手机软件开发的人那里看到“wifi热点发射”这个说法,虽然从上下文可以理解在说什么,但这个说法字面上是很难理解的。用 google 一查,有很多的人这么用。

在翻译术语的时候,如果省掉隐含信息进行翻译,有可能会和其它术语混淆,比如 iphone 4 上提到这个功能的官方用语是“private hotspot”,仅进行字面翻译,会和家用 wifi 路由器或AP没有区别。

我想到的一个“tethering hotspot”的翻译是“桥接热点”,这个翻译将 tethering 和 hotspot 两个词都翻译出来,“桥接”虽然没有说明另外一端是无线接入,但在手机、移动设备上使用这个术语时,上下文会使得其含义十分明确。最大的问题是“桥接”是个过于专业的术语,不够友好。

iPhone4 的信号问题

iPhone 4 正式销售以后,销量爆棚,天线事件也沸沸扬扬。

根据 Anandtech 所做的分析和测试,iPhone4 左手握持时的信号衰减大约在 24db。iPhone 4 的信号强度显示是对数标尺(dbm),但标尺不是线性的。从 0 格到 5 格信号强度为 低于 -113db, -107db, -103db, -101db, -91db, -51db。如果是信号满,24db 的衰减后还是 4 格;如果是 4 格,衰减后就是 0 格。

iPhone4 signal bars

换句话说,iPhone 4 没有“正确”显示当前信号强度,而是将当前信号强度“夸大”了。我个人认为这是苹果为了掩盖 iPhone 系列 (或 iPhone 4 这一款) 信号接收不佳所做的修改,这样按均匀标尺距离算 1 格的信号强度能显示为现在的 3 格;而 1 格半的信号强度能显示为 4 格,即在多数情况下,“iPhone 的信号不好是谣言”。但这个小把戏在 iPhone 4 上,由于天线设计问题,握持方式导致信号衰减过度,而产生了意料之外的负作用,被曝光于天下。

据苹果官方说法,这个“软件错误”在整个 iPhone 系列里面都存在,耐人寻味。

年前的好消息之一

昨天晚上更新了服务器上的 debian testing,惊喜地发现 freeradius 2.1.8 默认有 EAP-TLS 了。因为 OpenSSL 的 License 和 GPL 不兼容的原因,很早以前的某个版本以后,debian 的 freeradius 就不编译进 TLS 支持。所以每次更新,我都得重新编译一遍,有时候还得费很大周折去 fix debian/rules。重新支持是因为 OpenSSL 提供了 GPL 例外,兼容了。

现在爽了,不用每次折腾了,真是个好消息。

BTW:家里老人可能要在电脑上看电视,我就把奥运会时买的的神州数码 DCDTV330 USB 高清电视棒翻了出来。Windows 7 下用 WMC 还挺方便,但台式机是 XP 的,得搞搞 VLC 了。顺便看了一下最新内核,里面还不支持这款电视棒的 LGS-8G45 芯片。凌讯的网页半夜竟然打不开,我都以为这公司垮掉了,但想想 Intel 刚投资,不会这么快。好在白天能打开。看看能不能拿到芯片资料。

新Home Server

从1999年在亚信上班开始,就习惯在住的地方有server了,那个时候还是住的员工宿舍,拨的是 33.6k modem。后来到深圳工作一段时间,又回到北京,即便是租房子,也一直都有 home server,不过 modem 拨号,不是 always online 的。

最近的 home server 是2003 年搬进属于自己的家时买的,AMD Athlon Thunderbird 800Mhz CPU,128M 内存,主板是经典的 Gigabyte 7VA (所以在两年的时候经典地爆浆了),配上 2M 小区宽带和 DIY 的动态 DNS,给工作和娱乐带来了很多方便。用到现在,主板换过两次,电源换过两次,硬盘从一个 40G 的换成了两个 120G 的,最后一次配置变更是 2007 年。内存少,CPU 慢,功耗不算低,慢慢的就有换掉的念头了。

去年一度打算换成 EeeBox 202,但大陆买不到行货 EeeBox,单核 Atom N270 相对 AMD TB 800MHz 的升级力度也还是不够,我也就忍了。EeeBox 陆续出了一些新品,和我的需求总有些差距,最后决定自己攒一个小机箱、性能足够好的低功耗 home server 出来。前后看了很长时间,最后买散件攒出了新的 home server。

以上没算快递费总共 48 元和若干车马费,最后总价RMB 2000左右,比在淘宝上买一个 EeeBox 202 便宜 RMB 200 左右。

攒的过程还是有些曲折的。这主板一开始没有卖的,只有 886LCD-M/mITX,我撺掇店主去弄 986-LCD-M/mITX,到货了以后,才注意到是二手板子,犹豫了几天,再买就没有了,只好又撺掇店主继续进,等了近一个月在第二批买到。机箱我买的时候中关村还没有,等我在淘宝上买完了以后不久中关村也有了。CPU 买得有些后悔,应该买 U7200 的,编译程序不见得慢多少,功耗可以实实在在地降低。在机箱到货以前,买了一个 478 薄风扇,偏高,不能用在这个机箱里面,送人了,而这个超薄的则需要处理一下,要把底座的那一面的四个角锉平一部分,让过散热器座上四个角上的塑料铆钉,才能接触到 CPU。1TB 台式机硬盘发热量很大,如果笔记本硬盘有 1TB 的就好了,500GB 还是少了些。北桥被动散热非常烫,所以去买了一个北桥风扇,但北桥散热片的鳍间距比较大,回家以后风扇固定不上去,隔了半个月又带着板子单独去了一次店家那里,店主教了一个法子,就是把北桥散热鳍用手捏在一起,固定用的螺丝就能夹在里面了。风扇减速线是在北桥风扇那一家店一起买的,当时只是试试看,但事后证明我的直觉是正确的,BIOS 的CPU自动风扇调整功能有问题,把风扇调速后,经常停转,关掉调速功能,用两个减速线串接能减速到 1950 RPM,还不用担心停转,噪音也低于硬盘噪音。总结起来,自己攒这种非主流机器还是挺折腾的,尤其是第一次,会花去不少时间和精力。

整机的功耗估计是 45w,和 TB 800 一个 CPU 相当;要是用 U7200 和 5400RPM 的笔记本硬盘,功耗能再减少 10w。噪音在夜间密闭门窗的情况下,能听见,但低于闹钟嘀嗒声,开空调就听不到了,估计为 26-30 db。

服务器上跑的主要服务有:基于apache/mysql/wordpress 的本博客、用于家里无线 WPA2 EAP-TLS 验证的 radius 服务、mldonkey。当然,最大的用途是做为家庭网关。

正式使用这个新服务器 1 周,特此撰文留念。

2009地球一小时和脑残

3月28日20:30到21:30是2009地球一小时时间,这个活动的目的是“让全球社会民众了解到气候变化所带来的威胁,并让他们意识到个人及企业的一个小小动作将会给他们所居住的环境带来怎样深刻的影响”。

活动本身没什么可说,但是互联网上突然流传起一种观点

“今晚8:30-9:30 正 是cctv向全球直播庆祝西藏解放50年晚会的时间!不应该相信有地球一小时这个所谓的口号,希望你们尽快撤除了”

“同志们,最近美国所谓的环保组织发起“地球一小时”的关灯活动,大家千万别相应啊,因为2009年3月28日晚上8:30——9:30正好是中央电视1到4台并机在全球播出的庆祝西藏民主解放五十周年纪念晚会,很明显,这个时候,所谓的环保分子发起的“地球一小时”,阴谋大家可想而知,“地球一小时”这个活动,为什么这次偏偏在这个时候提出,而且为什么是中央电视台公布的这个晚会后,才在中国传播?时间真那么巧合吗?”

还有民间科学家的建议

“(我查过,明天晚8点确实是有这个节目)+请勿响应328关灯计划,众所周知,发电机输出的功率不变的情况下,要是电网的负载突然减少,电流或电压就会急剧上升,电网就会过压,要是超过了电网承受最大值,联着的电器就可能烧毁。关1小时灯根本节约不了能源(因为电厂仍按原计划在发电,多出来的电无法储存起来,只会造成灾难),节约能源要靠大家平时点点滴滴,而不是搞这种害人害己的形式主义!”

这种稍微有思维能力就不会轻信的阴谋论,在很短时间内流传广泛。一个地球一小时,暴露出这么多脑残,让人愤怒和无奈。不知道在party的响亮耳光下,他们会不会惊呆。

OpenWrt 增加 TL-WR941N 的支持

在我通过读带有符号的反汇编代码,写了TL-WR941N 固件 fixsum 工具后,通过TL-WR941N的管理页面上传修改后的固件或者第三方固件成为可能。我最初的目的是想让 dd-wrt 开发者给 dd-wrt 增加对 TL-WR941N 的支持,但是 dd-wrt 的开发者对 TL-WR941N 的兴趣并不大,在 dd-wrt 上迟迟没有动作。

2月19日,TP-Link 发布了新的 GPL 源代码,其中包括了 u-boot 源代码。OpenWrt 的开发者 jusohg 之后就利用 fixsum 和TP-Link 发布出来的源代码完成了对 WR941N 的支持。今天我测试了 dev snapshot build,局域网、无线都能正常工作了(我使用的是 WPA2 EAP-TLS)。相信不久以后,正式版本就能出来了。

TL-WR941N 使用了一个修改过的 u-boot,在最初发布的源代码中并不包括 u-boot 源代码。虽然我的 fixsum 能对头部做必要的处理,但使用其他的内核启动时,总是会跳出内核启动步骤,返回到 u-boot 提示符,没有任何有用的提示。我一直以为是 u-boot 对内核做了 checksum 检查(因为在头部还有另外一个没有用到的 checksum),但在 u-boot 的二进制映像中,并没有找到相关的痕迹。今天 jusohg 告诉我是因为 kernel entry point  需要修改,真是够简单的问题。头部中另外一个 checksum 是干什么用的,还是一个未解的谜。

OpenWrt 的 Web 界面 LuCI 没有中文翻译,我有空的话(做梦)会去翻译一下。

更新:目前的 ath9k 驱动有问题,我测试的时候,在没有 rx 的情况下,tx 丢包,所以还不能算正常工作。

融雪剂之灾

2月17日凌晨,北京迎来了2008-2009 年冬季第一场真正意义上的雪。当然,从农历上看,这是春天的雪,而不是冬天的雪。17日早上,从窗户往外看,小区内有较厚的积雪,我以为上班的交通会是个问题,坐公交车到建德门桥东,已然发现情况和猜想的不一样,打车去静安中心,还不到三环,就基本看不到雪的痕迹了。2 月 17 日晚,北京迎来更大的一场雪,大风卷着雪花,直往身上扑;从静安中心打车回家,看着车窗外和车行方向相同的横飞的雪花,不由得感叹雪真大。但是,我也注意到路上完全没有积雪的现象。18日早上,直接打车上班,和17日差不多,路上基本没有积雪。中午吃饭的时候,发现静安中心附近的街道上也没有什么积雪。

细心的人会注意到这场雪来得快,去得也快,和往年大雪很长时间才化完不同;一般化雪天会感觉很冷,而这次则没有这种感觉。虽然春天气温高是个原因,但主因是是融雪剂。

在18日,我注意到静安中心附近街边人行道上可以看到未融化的融雪剂颗粒。而19日,未融化的融雪剂、融化但没有流走又风干的融雪剂痕迹则到处都是了。今天中午出去吃饭,在小区的路边看见大量未融化的融雪剂,甚至有成块堆积的。在阳光下,还有一些看起来是未化掉的雪的条带,用鞋去刮就分辨出是正在干燥的融雪剂,从条带的方向和分布,以及残留融雪剂的量,可以看出抛洒融雪剂的密度和量都是惊人的。

2003-2003年的冬季,北京市政府使用的是挂名某名牌大学的某高科技公司开发的“高科技无盐环保融雪剂”,据说是绿色环保,无污染无公害。后来真相显露,大量的绿化植物死亡,根据有关调查研究,是融雪剂盐分导致的。这充分说明,这种高科技融雪剂,既不绿色环保,也不高科技,还含盐分。

根据一些相关报导,今年这次持续三天的雪,不仅把 6000 吨储备的融雪剂用完,还用掉了紧急采购的 3000 吨融雪剂。(注:各个报导中的数字很混乱,数字都对不上,这里使用 6000 吨和 3000 吨这两个数字)。这才是大雪来得快去得也快的真正原因。

融雪剂中的盐分有好几种危害:残留的盐分会污染土壤,让植物很难存活;盐分会对路面和桥梁产生腐蚀,缩短使用寿命,增加维护成本;盐分也会腐蚀金属,车辆、路边设施等都会被影响到;融雪剂还会污染水体,影响饮用水源。

这次融雪剂的过量使用,很可能对北京的绿化产生较大的影响。在以前,环卫工人清扫雪以后,习惯把雪堆在路边的树干旁,还有花坛旁边,在融雪剂造成绿化植物枯死的案例中,这个应该是最多的。近两年扫雪作业的要求中应该已经把这个因素考虑进去,所以这样的情况已经比较少,但在一些小区里面,还是有不少这样做的。我们假定扫雪不存在问题,但这次过量使用融雪剂,融雪剂颗粒和粉末会直接进入土壤。可以想象,开春以后路边树木的惨状。北京的降水量较少,虽然这两年的降水量有较大增加,但在稀释盐分污染方面,降水能起的作用还不够,长期这么做的后果就是土壤盐化,“绿色北京”的口号到时候是很难实现了,退而求其次,可以用“绿色中南海”的口号。

融雪剂粉末的残留则会影响政府支出,浪费纳税人的钱。很多地方柏油路边都被融雪剂粉末染白,这样的路面其破损会提前发生,政府养路费方面的开支会相应增加。而腐蚀路桥,缩短桥梁使用寿命,所造成的浪费也是很可观的。做为一个长期纳税人,我很生气。

而金属腐蚀和对水体的影响,则更隐蔽和广泛,超出我的想象力了。每个受到影响的车主,每个需要饮水的市民,都应该关注这个问题。

为什么这次会产生这种过量使用的问题?我猜测有两个因素,一个政府开支的预算机制,另外一个是执行人员。

政府预算通常是今年不花玩,下年会减少。这个冬天长时间没下雪,预算储备的融雪剂没有用到,明年冬天就无需或者仅需很小的量。相关的采购链上涉及的背后利益肯定受到影响。遇到这种下雪的良机,还不使劲用?用完储备再额外增加一些,明年的预算增加是顺理成章,有关决策人员对过量使用肯定是支持的。

在扫雪作业方面,通过前几年的使用经验积累,其实已经有较严格和科学的规范,比如公开能查到的机械为主、融雪剂为辅的原则,洒下融雪剂后必须在规定时间内将雪用机械清理走的规定。但如果执行没有很好监控的话,执行人员就会偷懒,省掉那些能够减少污染的步骤,或者不按规定的作业流程来实施。了解现场、指挥、配合这些环节有问题的话,不需要撒融雪剂的地方照样撒,可以少撒的地方多撒,过量就是不可避免的。

那谁会对这次的过量使用融雪剂造成的灾难负责呢?到目前为止,我还没有看到融雪剂相关报导。比我专业,比我敏感的人大把大把,不可能我是先知先觉的第一人。所以,按惯例,这件事情要到后果显现出来才会开始被提出来,而结果也很可能是和2003年那次一样,不了了之。

相关链接:

  1. 融雪剂之害
  2. 融雪剂的功与过
  3. 融雪剂造成的绿化损失

非常强悍的谷歌搜索结果

因为工作需要,又开始打智能手机的主意。除了让朋友从国外带手机回来外,在国内买支持 wifi 的智能手机也是一个选项。试着用“手机 wifi 解禁”在 google.cn 上搜索了一下,结果让人惊异:前面7页搜索结果,每一项都有“该网站可能含有恶意软件,有可能会危害您的电脑。”提示。

原因是什么?除了这些网站确实被植入了危险代码外,更可能的是谷歌的恶意软件识别出了问题。试了下其他关键词,结果发现任意关键词搜索的结果中,所有结果项都标为“该网站可能含有恶意软件,有可能会危害您的电脑。”

这是谷歌新年祝福吗?

awesome_g_cn