老大不让在服务器上装 zsh、htop 等升级版的工具

[Hieast]

楼主现在在一个比较小的实施团队，老大不让在客户提供的服务器上装 zsh、htop 等升级版的工具。 我觉得有一些久经考验的工具不见得比 GNU 里的那些工具稳定性差，况且工具也不应该会影响到服务。 用新的工具交互和显示更友好一些，能提高我的工作效率，我是想在生产环境用 zsh，以及其他升级版工具的。

我想请教大家两个问题，

1. 服务器上用这些工具有什么风险？
2. 不用 zsh，bash 怎么配置才能让补全和搜索更顺手？如何证明这种配置和插件比用 zsh 更安全？

联动问题 请问一下，那个 oh my zsh 好用么？

[msg7086]

@mywaiting 好奇问一句，你服务器上数据库和数据文件的 replication 和自动打包备份上传，在不登录服务器 SSH 的情况下是如何配置好的？用了什么中央管控的软件么？这方面我的确很想了解一下有没有既方便又不用手动操作的方法。

[bumz]

客户的机器，或者生产环境
能不添加额外的软件就不添加，这是默认值，不需要理由的
要添加软件才需要足够有说服力的理由，zsh 能做什么 bash 做不了的事吗？

你也说了，「应该」不会

[bumz]

不是「绝对」不会

那你就是在引入不必要的风险，这点效率的提高和风险比起来不值得一提

[bumz]

@msg7086 #80 引入不必要的软件就引入了不必要的安全隐患，这不是说有已知漏洞了才叫安全隐患
有了已知漏洞还不修就不叫安全隐患了，这等于是大门敞开

连 bash 都出过藏了很多年才发现的高危漏洞，你敢说你装一个 zsh 再装一堆插件，存在漏洞的可能性没有大大提升？

漏洞存在的可能性不需要证明，这已经是公认的常识，没漏洞才需要证明

同样能不做的事情就不做，做了就引入了操作失误的风险
你敢说你敲任何命令都绝对不可能敲错，绝对没有出错的时候？

这不是水平高低的问题，有犯错的可能，就别做多余的事情增加出错的机会
生产环境，少折腾，这也是常识

[nosay]

很多人不让乱装软件的初衷，可能仅仅只是害怕中毒而已。
见太多 22 端口，密码登陆，root 进去一把梭的。
别说你们没见过，跟这个比起来，装个 zsh 算个屁啊。

[ldrljq]

@silentstorm 对，有的是必须用 delete 删除，有的是不能前后移动光标，有的是不能按上重复前面的命令。。。

[msg7086]

@bumz 装一个 zsh 和装一个 bash 出现漏洞的机会是均等的，如果你不能证明 zsh 比 bash 的质量差，或者后者的漏洞更多，不如不要就这么拍脑袋下结论？你这个论点根本站不住脚，因为把上文 bash 和 zsh 两个词互换也是完全成立的。

另外上次那个 bash 的高危漏洞你真的搞清楚是什么吗？那个是要暴露 cgi-bin 并且允许第三方远程执行你本地的脚本才会中招。换句话说，你装了 Apache，开启了 cgi-bin，并且把 bash 设置成执行 Shell，然后在 cgi-bin 里放了脚本程序给公众执行，才会中招。

也就是说，这种情况下，别说你装了 zsh，就算是你把阿毛阿狗各种有漏洞的 shell 全装上，也只有 bash 的漏洞会被利用到。所以，与其防止别人安装 zsh，不如请你「把配置错误的 Web 服务器修一修」？

或者你来说说，还有其它哪种情况是一个有漏洞的 shell 会被第三方人士执行到的，我来学习一个。
不要拍脑袋瞎想，说点有道理的内容出来。

[julyclyde]

应用自己、应用运行时需要的配置和数据、外部依赖、依赖以外的操作系统环境
这几部分需要明确定义
你装那些工具，是属于以外的，你用着方便，但不能保证随地都有

[mywaiting]

@msg7086 不登陆服务器不敢说，就是很少需要直接 SSH 登陆的时候

一般来说，生产环境的主机在云厂商那里 initialize 出来以后，每个项目自己有一个 python fabric 的脚本，填上拿到 root 的账号密码，就可以自动执行服务器的初始化，安装环境、下载生产的代码，然后有代码可以自动配置好系列的 crontab 来定时备份数据库

需要参考的 fabric 脚本的话，你可以去参考 Newsblur 项目下面的 fabfile，我的也基本一样的

小项目，没有必要上那些重型装备，方便顺手就可以了

[zhengyongtao]

@msg7086 乍看之下你说的很有道理，但是仔细看看就知道你是在偷换概念，上边多数人说的是可能发生的情况以及这种情况下常规的处理方法。对于喜欢折腾的人来说，bug 不是病是良药，对于喜欢稳定的人来说，服务器不出问题就是最好的良方，身在不同岗位不同环境下，处理方式也不同。在题主的前提是客户提供的服务器这个大前提下，我认为处理手段更倾向于后者。更何况你怎么知道服务端上跑着什么进程，安装的软件是否会影响到服务端进程？在 v2 上无非求同存异，把建议当结论，把大家都当成没经验的小白，这种习惯可不好。

[zong400]

@msg7086 看你的回复你日常是用 zsh ？ zsh 比 bash 优胜在什么地方？

[Navee]

其实 zsh 没必要，htop 还行

[victorywangzhcn]

@zhengyongtao 大哥能不能不要跑题，我就问问 htop 能影响啥，他有什么依赖，你 ldd 之后给你答案了吗？照你这个理论大家啥东西都别装了，libssh2 前两天还有个 userkey auth 认证的大问题，稳不稳定？ 少说方法论，来点干货

[sleepm]

可以上 fish
bash 真心不友好

[bengxy]

理论上不应该在生产环境的机器上做任何的编辑工作啊

所有的东西都应该是线下编辑打包好，直接推送到线上部署的

[mrco]

这个其实就是原则问题,服务器上就最小化轻量运行,统一配置.

不是个人 PC 可以各种自定义,明白了吧 ?

[bumz]

@msg7086 #87 如果服务器自带的是 zsh，额外装一个 bash 同样会增加风险

并不关乎 bash 和 zsh 谁更安全

此外我举的那个漏洞只是为了说明高危漏洞出现的机会，并不是想说只要防范了这一个漏洞就高枕无忧了
安装的软件越多，潜在的攻击面越多，少装不必要的软件减少的风险不是正确的配置能替代的

在那个特定漏洞的利用场景之下，只有默认 shell 的漏洞有机会触发
并不意味着安装有漏洞的软件不会增加其它场景下的攻击面

例如，在某些场景下，攻击者获得了以普通用户身份执行某些代码的权限
假如用户安装了一个不必要的，带有提权漏洞的软件（用户对此不知情）
该软件的存在就使得「以普通用户身份执行某些代码的权限」
得以成为「以超级用户身份执行某些代码的权限」
后者的破坏性显然大于前者
而这样的事情本可以通过不安装该不必要的软件来避免

也就是说，确实存在至少一种场景，多安装一个不必要的软件，由于其中含有未知漏洞的可能性，一些本来不可能出现的攻击得以出现
也就是说安装不必要的软件增加了攻击面，这个风险不是由已知的信息带来的，而是由未知带来的，无法通过正确配置防范

[xderam]

12 年的时候也有开发想让我在服务器上装 zsh，被我拒绝了。
后来想想，其实无所谓，又不是让我把 root 的默认 sh 改为 zsh。
但如果现在有开发让我把所有生产服务器都装上 zsh，从技术角度没啥，但我会怀疑这开发是不是在坑我。

[ipwx]

我觉得 puppet / openstack 之类的对于小团队确实过分了。

但是 CI & ansible 又不费多少事。装个 GitLab 就有 CI，ansible 自己机器装个也都有了。这有什么好回避的。。。

[wenzhoou]

要是我，我不会不让你装，你先写一份报告证明装了没问题，我要全部是干货的论文。
然后，你要装，给你权限，
第一：你给我整一套：以后大家往服务器上安装自己想用的东西的时候的，安装规范和反安装规范出来。第二：然后整个安装了之后有可能碰到的常用问题解决方案 list 出来，
第三：以及后继运维看得懂得使用说明。
用规范的制度压死你。看你还装不装。
想学习想玩另外弄台电脑。不差钱。要动生产环境可要悠着点。