bash严重漏洞

今天估计各大消息都在报这个漏洞,可能有些人看到有修复就放松了。目前来看,事情没那么简单。

CVE-2014-6271

第一个漏洞,编号为CVE-2014-6271。相应的dsausn

具体的文章可以看这里

简单来说,当bash执行时看到有变量定义了一个函数,函数尾部又剩余了部分代码。会直接把剩余代码执行了。导致简单的变量定义动作有机会执行任意代码。

对于未修补的系统,执行以下代码出现以下提示:

$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
vulnerable
this is a test

注意echo vulnerable应当不被执行的。

修复的系统则是以下表现:

$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
this is a test

CVE-2014-7169

第二个漏洞,编号为CVE-2014-7169

这个漏洞是第一个漏洞没有修复完全导致的,最麻烦的是,这个漏洞没有修复,细节却满天飞了。

表现如下:

$ env X='() { (a)=>\' sh -c "echo date"; cat echo
sh: X: line 1: syntax error near unexpected token `='
sh: X: line 1: `'
sh: error importing function definition for `X'
Wed Sep 24 23:25:58 PDT 2014

结论和建议

尽量不要暴露bash,能关就关,不行的自求多福吧。

送书

最近清理家中藏书,打算送掉一部分纸质书。于是顺手列了一批自己需要,但是可以外借的书。

送人的部分,如果你需要,两个月内联系我,自己想办法拿走(例如H4,或者直接上门)。逾期我就直接送去资源回收了。借阅的部分,记得好好保管图书,不管借阅多久,记得回头还我。

送人

  • delphi 5.0 开发多媒体应用 ISBN 7-5084-0470-X
  • C++语言程序设计 ISBN 7-302-03926-7
  • 计算机绘图 ISBN 7-313-01482-1/TP.273
  • borland C++ windows程序设计 ISBN 7-115-05265-4/TP.117
  • 最新C++语言精华 ISBN 7-5053-3975-3/TP.1731
  • C++语言程序设计 ISBN 7-302-04504-6
  • C++使用手册 ISBN 7-5053-2890-5/TP.959
  • microsoft visual C++ .net技术内幕 ISBN 7-302-08931-0
  • 操作系统教程 ISBN 7-04-012664-8

借阅

  • 模式识别 ISBN 7-121-02647-3
  • 深入解析Windows操作系统 ISBN 978-7-121-03969-0
  • 计算机网络 ISBN 7-302-08977-9
  • 深入浅出MFC ISBN 7-900614-93-1
  • Python源码解析 ISBN 978-7-121-06874-4
  • 数据结构与算法(Java语言版) ISBN 7-111-11902-9
  • 网络渗透技术 ISBN 7-121-01035-6
  • 密码编码学与网络安全 ISBN 7-5053-9395-2
  • 人工智能及其应用 ISBN 7-302-02127-9
  • 神经网络原理 ISBN 7-111-12759-5

如何分辨网站真假

老婆想去新疆玩,结果她居然从百度上搜了一下新疆国旅就联系开了。我一直不知道,直到她和我说,对方要求缴500元到一个支付宝帐号里。我立刻要求她不要付钱,然后开始查证真假。

第一家网站

她开始给我的是这家:http://www.17xjly.net/

老规矩,先whois,再dig,再whois。

whois域名的结果是没有任何信息?!

dig后的IP是113.10.247.20。再whois一遍,发现服务器在香港。此外也没有任何信息。

ICP是新疆的,查全国ICP登记无信息。

开始想不通,这家伙在新疆背景这么深厚?突然醒悟过来。这家伙是个.net域名,注册地不在中国,服务器不在中国,凭什么要人家ICP备案啊。就因为号称是新疆的网站?

CAO,这种网站给的支付宝,鬼知道打进去会发生什么。。。

第二家网站

百度上排名很高的是这家http://www.yuyutrip.net/和这家http://www.yoyotrip.net/。两家的页面很像,但是又明显有区别,不知道是竞争对手还是什么。

老规矩。

whois域名的结果是这个:

Registrant State/Province:Shanghai
Registrant Name:shxg shxg

注册地上海?

dig了更好玩。这两个域名的IP指向是同一个。121.52.217.137。再whois发现是这个:

netname: TopnewNET
descr: Beijing Topnew Info&Tech co., LTD.

没听说过。

ICP倒是有:

北京博通天下网络技术有限公司
U旅商旅网
2013-06-09

咳咳,漏底了吧。虽然号称国旅,但是是一家北京公司在上海注册的域名。

好玩的是,这家网站上面给出的地址,是真的(具体后面会说)。但是电话却不对。

真的国旅

google出手,马上就有。结果是这个http://www.cits.com.cn

老规矩。

whois域名可以看到这个:

Registrant: 中国国际旅行社总社有限公司

注册者看着就很NB。

dig一下,发现IP是这个,219.143.192.35。这个IP可牛逼了。whois一下:

inetnum: 219.143.192.0 - 219.143.192.255
netname: CITS

我擦,专属C类IP段!

ICP查询后结果是这样的:

中国国际旅行社总社有限公司
国旅在线
www.cits.com.cn
2014-07-23
www.cits.net
2012-11-29

这个网站上有400电话,打过去说新疆只有团体游。不过人家给了正确的地址和电话,和第二家网站的地址一致,电话却不一样。

事情到这里,我的基本判断是。和第二家网站做生意还是有点谱的,ICP是真的,地址国旅也认。最低限度,他至少是一家合法的旅行社——虽然不保证是国旅下属。第一家么,谁爱信谁信。

上海国旅

后面有点更好玩的事情。国旅在线上有上海,而google查询结果上也有不少上海国旅。那么谁是真的呢?

上海国旅1

例如这家http://www.scits.com/

域名的whois是这样的:

Registrant Organization: SHANGHAI CHINA INTERNATIONAL TRAVEL SERVICE CO.,LT
Registrant City: shanghai

dig后发现IP是210.14.68.234,再whois是这样的:

netname:        SVA
descr:          Science & Technology Network Communication Co., Ltd.

看起来很像?

ICP就漏了。

上海锦江国际旅游股份有限公司
锦江旅游网
2012-09-06

这TM哪里是国旅,分明是锦江国际。不过幸好,这也是家挺大的旅行社。只是为什么会打CITS的牌子呢?

上海国旅2

例如这家http://www.citssh.com/

域名的whois是这样的:

Registrant Organization: CITS GROUP SHANGHAI CO.,LTD

而IP,我擦,用的是阿里云。

ICP上查到是这样:

国旅集团上海有限公司商务旅行服务分公司 
国旅上海官网
长安路1001号1号楼16层

这个在国旅官网里面有上海办公室地址。校验一致,表明是真的下属网站。

不过上海国旅用阿里云?真心不怕死啊。

验证方式

好了,不光吐槽。无论是baidu还是google,都不保证结果的真假。只是baidu谁给钱就给谁排,google是计算引用数最高的。

怎么验证呢?先whois,再dig,再whois,最后查ICP。

这四步叫做基础检验,分别检查域名注册者,IP拥有者,ICP拥有者。对于大部分的网络诈骗,这三者都非常强力。

域名的注册者和IP拥有者虽然不能绝对定性,但是是很有用的参考信息。至少注册信息全无或者不对,IP地址去了香港甚至新加坡的,你就要多小心了。

ICP是比较绝对的。因为ICP和域名关联。只要有域名就能查询ICP号和注册公司。这个目前要造假只能在提交给机房到ICP审核的资料上造假(伪造文书)。如果连他们都中招了,一般人也幸免不了。

另一个是工商行政登记。如果你找到公司名,一般就可以在工商行政登记上查找注册人,注册时间,登记地址等等。如果没有,或者不对头,那就有问题了。

whois

我推荐这家网站https://who.is

直接把域名或者网站贴进去,就告诉你注册者是谁。

dig

在linux下dig xxx,windows下就是ping。能看到对应的ip。

ICP登记

网址在此:http://www.miitbeian.gov.cn/publish/query/indexFirst.action

注意一点。用域名查询的时候,注意去掉http头部,还有www。就留下主域名,例如cits.com.cn。

另外吐槽下ICP登记查询的傻验证码。真的忍不住,实在TMD太难输了。三四次成功一次。幸好我用到的机会也不多。

工商行政登记

这个没有统一网址,每个地方自己管理。例如上海的是这个:https://www.sgs.gov.cn/shaic/

这个也顺便吐个槽。身为政府机关,居然证书是自签署的。您不行不能让CNNIC帮着签一个么?

真搞不懂政府这帮IT什么逻辑。12306也是。。。

什么是危险的

  1. 400电话给你打进来。有公司就有400,不需要全国知名。要靠谱,正确做法是你查114,然后打400过去。
  2. 信任google。这和信任baidu没有本质区别。
  3. 看着网站像。李鬼太多。

服务器操作系统的选择

今天被LTN问了一下怎么看一个知乎问题:

服务器操作系统应该选择 Debian/Ubuntu 还是 CentOS?

其实我觉得他的大部分说法都没有错。如果你需要装一个服务器,确实首选是RH系的。

但是。。。

选用RH系的主要理由

其实你把回复从头看到尾,主要论点就一点:

哪个发行版,可以在长达7-10年的时间里,始终保持硬件稳定性的同时,又持续的升级补丁?

结论当然是RH!这是RH的主要卖点。

我们真的需要长达7年的硬件稳定性支持?

咳咳,今年上半年,蔽厂的运维碰到了这么一件尴尬事。

他们进货,去机房装系统,配置网络结构,加入运维管理系统,添加监控,交付。除去采购外,整个一套流程大概是一周。

我们在机房里面原本大约有10个机柜,那么一般扩充的时候,一次扩充一个机柜。

结果今年上半年的某一段时间,一周一个机柜的事情持续了两个月。运维同学辛辛苦苦装好一个机柜,周末打算轻松一下。被老大通知,又来客户了,机柜又不够用了,下周继续。

是的,我们现在20个机柜不止。机房有多少机柜我不知道,不过照这个趋势来看,我们快把机房包下来了。现在我们的带宽已经没有限制了,每个月月底按照合同秋后算账。

我们有一些有三年历史的服务器,台数不多。现在来看,性能已经远远不够。CPU不够快,也没有SSD,硬盘读写次数也太多。这些机器的下场,多数会被换下来折旧卖掉,或者作为测试服务器,搬去测试机房。而现在机房里面大半机器,都是两年以下历史的。而且至少一半服务器历史不超过半年(。。。)。从现状上看,把老服务器留在机房,其性价比并不合算。因为机房有机架密度问题,限制着我们的单机房极限,这相当于变相的租金。

如果考虑到这点,我们的线上服务器生命周期大概也就三年。最多。很多时候甚至还不到。

比我们更极端的是页游。他们的一组服务器生命周期一般是半年。半年内,要赚钱的也赚完了,不赚钱的也死完了。所以他们甚至不会新采购硬件服务器,而是直接使用虚拟机。

当然,虚拟机内的系统,支持时间是一年还是十年,对他们一点意义都没有。

为什么我们不喜欢三年以上的系统?

RH系的提供10年级别的维护性,我换个说法,也就是最近的软件在RH的官方库里面找不到。当然,装最新的RH是有的,但是在安装了三年的一个系统上?肯定没戏。

怎么办?编译呗。

这大概就是国内谈到RH必编译的由来。

可是,我引用文内的一段话。

如果我今天告诉大家,我要做一个 http 的服务器,我不用 apache 不用 nginx,
为了性能我要用 xxx 为基础重写一套出来。我相信绝大多数人会问同样的问题,
“你觉得你写的能比 ng 好么?”
再回头看看那时候你们自己吧。

同样,自己编译的软件,补丁维护速度,能和新系统比么?而且我们还得扔一个人下去搞补丁维护。

所以,正解是什么?

装一套新的,把数据导过去用呗。

我们的”数据“,都是装载在磁盘上的。而换”系统“并不需要更新这些数据,只要把系统盘擦掉重部署一遍,然后配置好deploy系统就OK。在开发之初,”环境“,”程序“和”数据“分离,就是一项基本原则。而且即使是”数据“,丢掉一台机器上的所有”数据“也不会构成问题。这应当是运维基础中的基础。只有少数几台服务器,既不能直接更换也不能停机。这些机器我们做特别的管理。

为什么蔽厂使用Ubuntu?

很简单。因为最初的开发希望在Linux上进行。直接在Linux上开发和测试,对于startup的快速开发是非常重要的。而开发用什么版本,服务器跟什么版本,这是最省事和好办的。如果你硬要和我争,说开发在Mac上,跑在Linux上一点事都没有。或者说开发一个发行,服务器一个发行也OK。

我至少得说这对于golang和python都不是事实。除非不用cgo,也不用python的C扩展。

先不提Mac下和Linux下的差异。我们今年在升14.04的时候就发现,12.04和14.04的编译互不通行。所以现在12.04的编译可以程序员自己编译了本地测,14.04的就必须在测试环境里干。一帮程序员远程tcpdump出结果,拷回本地wireshark一把。。。

看看就蛋疼。

当然,这也有个问题。就是上面”我们不喜欢三年以上的系统“。所以呢。明年我们的系统大概会轮换重装,14.04。。。

也很蛋疼。

Debian系的补丁不靠谱么?

那要看和谁比。这里有HeartBleed事件的统计。虽然不普遍,但是我觉得这种大漏洞比较有代表性。

CVE-2014-0160 – OpenSSL 安全漏洞的非技術事件

我引用他的重点整理:

RedHat 修復的速度比 OpenSSL 官方還快。
RedHat 派系的修復時間,除了 RedHat 外都算慢,如 Fedora 及 CentOS、Scentific,
他們都比 RedHat 慢 16 小時以上。
Debian 派系的修復時間,如 Debian 及 Ubuntu,都比 RedHat 慢上至少 12 小時以上。
Scentific 是列表中修復最慢的。
若以資安黃金 6 小時來說,Fedora、CentOS、OpenSUSE、Gentoo
及 Scentific 都不及格。

如果和RH比,Debian的修复速度是不及格,但是和CentOS比。。。怎么说呢?6个小时对10个小时,有种五十步笑百步的味道?

换你你愿意走几步?

另外,我也不知道原文说的升级一大包是怎么回事。我在Debian stable上查询ssl:

$ dpkg -s libssl1.0.0
Version: 1.0.1e-2+deb7u12
Depends: libc6 (>= 2.7), zlib1g (>= 1:1.1.4), debconf (>= 0.5) | debconf-2.0

但是同时。

$ dpkg -l | grep libc6
ii  libc6:i386                           2.13-38+deb7u3                i386         Embedded GNU C Library: Shared libraries

libc的依赖早就满足到不能再满足了。直到今天为止,openssl在debian上的升级还不需要你强制跟随升级libc6。而kernel根本没有依赖。

纠正原文的一点理解错误

Debian 是由社区维护、贡献的发行版本,其从选包、打包、都是由社区组织,分散行动的。
Debian 是没有真正意义的 release 概念的。Debian 有众多仓库,stable,testing,
unstable ,experimental. Debian 组织系统的方式是,一个软件先进入 experimental, 
放一段时间,有 bug 修 bug,没 bug 了,过段时间挪入 unstable,
如此循环最终挪到 stable 里面。
所以在这种情况下,Debian 的系统中,是没有一个稳定版本的概念。
今天你用 kernel 3.2.1-87 , 明天就给你更新到 kernel 3.3.2-5 。

Debian是由社区维护,这没错。但是选包并不是社区组织。Debian中,如果没有特定理由(例如dsfg)阻止你打一个包,那么只要有maintainer,就可以打包。哪怕这个包的用户其实不是很多(很多包甚至统计上只有1X个用户),这也是Debian那么一大堆包的原因。

Debian包的管理方式是,先进入unstable(是的,除了少数情况,一般不是进入experimental)。在一周后,看看没问题,就进入testing。没问题的指标是,这个包和依赖的包没有RC bug,就是致命性bug。

所以很多在unstable里面有的东西,testing里面反而没有。因为unstable里面的某个基础依赖包的RC bug并没有被修复。而且testing修漏洞的速度是最慢的。因为一出问题,unstable会直接引入新的版本。而stable会要求maintainer修复。可怜的testing只能等一个礼拜。。。

那什么时候进入stable?他不会随着你的循环进入stable。而是每1.5-2年(预期1.5年,但是RC冻结周期往往会超标,根据历史数据统计,一般两年)做一次发布,这个发布会冻结所有新包,并修正RC bug。等大家觉得差不多稳定了,OK,原本的testing就成为stable,而原本的unstable就fork出新的unstable和testing。

所以现在的testing代号就会成为下一个stable代号,而每次fork的时候,我们都是决定testing代号——就是下个发行的发行代号。

所以你看BTS的追踪,会发现每1.5年有一段时间,RC bug的数量会锐减,而新包的数量也锐减。这不是大家都冬眠了,只是新发行周期而已。

作为证据,下面是我的Packages overview。大家可以看到,python-snappy(这是我唯一维护的包了,python-formalchemy已经RFA了)在stable里面是0.4,而新的两个里面是0.5。我没有明确理由把stable里面的版本升级到0.5。

那debian怎么修bug?

这个看maintainer。一般的原则是,如果不是无法保持版本,一般直接打补丁升级。这也是原文的一点理解错误。如果用的真的是Debian stable,没有特殊理由的话,内核是不会升级到3.3的。作为证据,大家可以看一下现在stable的官配内核版本号。目前是linux-image-amd64 (3.2+46),依赖应该是linux-image-3.2.0-4-amd64 (3.2.60-1+deb7u3)。也就是说,版本号应该是3.2.60-1+deb7u3。而3.2在kernel.org上的longterm对应版本号是62。

原作者这个理解,怎么说呢。我怀疑他要么没仔细用过debian,要么用的是testing。

但是如果新老版本差异太大,老版本又拒绝提供补丁,那么逼不得已的情况下,需要评估是不是能升。例如某一段时间,mysql的版本号是5.0XXreal5.5XXX(这个是听本厂DD说的)。至于原本的兼容性问题,我也不知道他们是怎么想的,大概是认为mysql server没啥依赖性问题吧。

但是这种情况下,RH一般也没办法吧——除非他们自己出程序员给老版本做一遍补丁。不过如果这样的话,oracle一般会merge back回去,debian就跟着沾光了。

Ubuntu的误解

Ubuntu 8.04 LTS April 24, 2008
Ubuntu 8.04.4 LTS January 28, 2010
1年9个月
你说好的 LTS 呢???
Ubuntu 10.04 LTS April 29, 2010
Ubuntu 10.04.4 LTS February 16, 2012
说好的 LTS 呢?
说 End of the Date 是3年整就是一个笑话,
只要下个 release 一出,上个 release 收到的更新数量就可怜。

作者大概是RH用多了,没搞明白Ubuntu“维护”的本质。

Debian和Debian基础的系统,主要的发行方式是网络。光盘只是给你个安装的机会。这点debian更加明显——他有种光盘叫做netinst。里面只有基础包的安装包。在不联网的情况下,你只能装出一个用于联网升级的系统。没有gui,没有openssh,啥都没有。

所以,LTS归LTS,修改不够多是不够打新光盘的。

谁会持续5年,一年给你弄张新光盘出来啊——尤其是里面没几个包改了。

而LTS的维护怎么样?我们来看usn的维护情况。

在2014年6-7月,总共有26个USN涉及ubuntu lucid。

所以装好ubuntu,第一件事是去repository上面打一遍安全补丁!

”维护“的本质问题

上面说了半天,根本问题是,”维护“是个什么东西?

主要就是bug修复。尤其是一类特殊bug修复——安全补丁。

一旦一个程序基本成型,就一定会形成”接口“。API是接口,调用的程序,参数,顺序,环境变量,一样是接口。有接口就有接口兼容性。如果不考虑兼容性,一律使用最新版本的话。。。

bang。不知哪天程序就跑不动了。因为作者改了接口。

不要以为这很扯,我在实际里多次碰到这种问题。python-mongo多次修改接口,sqlalchemy0.6时写的程序,经我反复修改终于上到了0.7,却死也上不到0.8。至于docker,也是个版本号刚刚过1.0的家伙。在1.0前面,我们就作大死的做了二次开发。结果惨不忍睹。

所以我们用一种被称为“发行”的方案。即一段时间,将稳定的代码固定下来,形成某个版本的发行。例如linux-kernel-3.2.0。而后新功能在3.3上面渐进,原本使用3.2的并不受到干扰。

这本来挺完美,可惜有一个问题。bug并不一定出在最新版上面,他有可能在14年前就已经存在了。这样会使得bug横跨多个版本。而这个bug又不能不修的时候——例如安全漏洞。

这时候就蛋疼了。

上游会修多少个发行的漏洞?如果上游不修,这个发行的漏洞怎么办?大部分漏洞只是几行就可以完成修正,但是有些发行甚至要动架构,怎么办?

没有研发力量,是不能保证修复的。

在代码里面,主要有三件事情,功能发展性,接口稳定性,代码安全性。

如果我们可以去掉一件事情,那么世界很完美。

  1. 去掉接口稳定性,每次都用最新的就好了,bug肯定修光的。
  2. 去掉功能发展性,软件不再推进就好了,就修修bug。
  3. 去掉代码安全性,单纯发行就好了,发了就不用管了。

可惜,三者一般都需要。有些很古典的程序已经进入了2的情况,例如TeX。至于大部分互联网公司线上系统,则比较偏向1。但是大部分发行版内的包,可是要三者都满足的。

RH和Debian的开发差异

其实还是很大的。RH的开发是真的开发。Debian的”Developer”,其实只管开发debian打包用脚本,维护版本,补丁,仓库。而RH的开发,别的不说,你就看内核补丁贡献数吧。

这也是社区和公司不同取向的差别。社区不管商业能处理的一些问题,而且他们也管不了。先不提RH有多少人,Debian社区有多少人。我就吐槽一下中国DD数量吧。我查询了一下,总共8个(db)。其中我认识5个,超过一半。某次emfox来开会,lidaobing和zigo也在。我们开玩笑说,这次会议集中了中国近一半的DD。。。其实整个会场里面人数都没超过20。。。

也只有RH这种级别的公司,才有大量人力去折腾内核,驱动之类的事情。因为debian就算想折腾,也折腾不动啊。从某种意义上说,所有linux发行的蓬勃发展,都得益于RH的大量收入。

所以真想支持开源的,不全买,买一套RHEL也好啊。别老叫着CentOS免费,免费还说个JB的支持开源。

什么情况下用RH,什么情况下不一定

虽然在上面数了原作者的一堆问题,但是我得说,他的结论没啥错误。

除非你明白自己在干什么,否则RHEL一定是你的第一选择。

这是废话。出钱让人帮你解决问题,和你自己解决问题,哪个更专业?

凡是你干了这活,打算三五年内就上去升级升级安全补丁,此外啥都不想干的。用RHEL准没错。

如果上面这种情况会让你失业的,换Gentoo准没错。

至于什么叫做“明白自己在干什么”,其实没一个统一的标准。很多时候选择开发版有点“如人饮水,冷暖自知”。例如我们选Ubuntu,解决了发布同环境问题,却引入了运维滚动升级问题。但是经过权衡,发布和调试环境不同会导致研发效率的大幅下降,而我们的研发是不能靠花钱招的(广告:长期招聘靠谱golang研发),但是我们的运维是可以靠花钱招的。这个时候痛苦也得滚动着上了。当然,也许若干年后,发现其实我们错了。可是错的理由我们现在看不到也想不到。当然,像我们,或者页游这种奇葩公司,也不总是出现。所以大部分情况下,用RHEL都是对的(当然,原作者说的太绝对化了一点)。

用Debian用什么

Debian是非常强调dsfg的,具有非常强的开源原教旨主义的味道。

传统的开源认为,如果只有商业公司掌握发行,那么他们就会扼住我们的命脉,并以此作恶。

不得不说,老外对垄断和权威的恶和理解一点都不比我们差。

所以debian的衍生发行一点都不比RH逊色(Linux发行版列表)。最大的就是得益于dsfg规定,凡是允许进入debian的,不能仅仅授权给debian——而是必须授权给整个公有领域。因此对debian的衍生是非常安全而没有法律风险的——DD们在这个领域的专业程度非常高。

而且,由于强调自由,因此debian内所有非核心包,都具有非二进制定制性。简单来说,就是除了核心包和打包参数,其他大部分结构都是可以更改而且应当是自己更改配置的。

想用lxde换掉gnome,可以。搭配着kde的软件使?也可以。上面用什么输入法?自己配。

这是debian的强大和灵活所在,也是debian非常高的一个门槛。相比起来,Ubuntu更强调“开箱即用”。所以里面的随附配置是最完备的。但是要用lxde,推荐就是Lubuntu了。

CentOS不是RH

我上面提到的RH,大部分指的都是RHEL。至于Cent——他也是社区系统,只是背靠RH,胳膊更粗一些而已。这不代表Cent因此就靠谱了。

例如这个维基页面CentOS,里面提到说。

In July 2009, it was reported[by whom?] that CentOS's founder,
Lance Davis, had disappeared in 2008. Davis had ceased contribution
to the project, but continued to hold the registration for
the CentOS domain and PayPal account. In August 2009,
the CentOS team reportedly made contact with Davis and
obtained the centos.info and centos.org domains.[12]

那哥们直接失踪了近一年,而且捏着域名和PayPal账户不放。我记得当年这事直接导致CentOS的其他开发者出来放话,再不出来把你丫按照失踪申报。

这也直接导致我上家公司的基系统选择从CentOS改成了Scentific(是的,就是上面修复最慢的那家)。

其次,CentOS是不签合同的,所以出了事是运维自己兜着。

CentOS出了问题你能和领导交代么?这得看你们领导的SB程度。反正要是有人告诉我,他用CentOS出了事。我的第一反应都是,RHEL是不是可以避免。可以的,那就是决定用的人自己找事。

如果用RH,至少应该用RHEL,并且买订阅

我们没有用RHEL,都买了RH的订阅。RH的订阅非常有指导意义。

架构师

一个好的架构师至少要做到四点:

  1. 识别甚至提前预测到程序不同阶段的性能瓶颈,并以合理的代价消除。
  2. 识别束缚程序员生产力发展的瓶颈,并合理的消除。
  3. 解决组里面的尖端问题。
  4. 成为组员的精神支柱和旗帜。

他不应该:

  1. 总结需求。这是产品经理的事,除非他兼任。
  2. 评估工作时间,并保证工作进度。这是项目经理的事,除非他兼任。
  3. 召集,协调工作细节。这个随企业有不同划分,理论上是行政领导干的。有的企业是技术系的来做行政领导,有的是PM。
  4. 亲自写程序。除了初创,架构师亲自冲上去写大段大段的程序是找死的先兆。
  5. 预测技术的发展方向,并做出技术决策。您让CTO干什么去?
  6. 政治斗争。架构师也来搞这个,要么被搞死,要么根本没心思做事。

但是架构师应该理解办公室政治,并且能够基本掌握情况。一点办公室政治都不懂的架构师肯定被搞死。