这是一个创建于 2012 天前的主题，其中的信息可能已经有所发展或是发生改变。
楼主现在在一个比较小的实施团队，老大不让在客户提供的服务器上装 zsh、htop 等升级版的工具。 我觉得有一些久经考验的工具不见得比 GNU 里的那些工具稳定性差，况且工具也不应该会影响到服务。 用新的工具交互和显示更友好一些，能提高我的工作效率，我是想在生产环境用 zsh，以及其他升级版工具的。
我想请教大家两个问题，
- 服务器上用这些工具有什么风险？
- 不用 zsh，bash 怎么配置才能让补全和搜索更顺手？如何证明这种配置和插件比用 zsh 更安全？
第 1 条附言 · 2019-05-09 12:05:38 +08:00
我刚加入没多久，目前没有运维，也没有发布规范，新项目测试机器资源也不足。
以前公司用过 gitlab-ci，知道下面运维大佬们提过的 ci 流程。会写 bash 和 python 的知道这套流程以后要部署一套 ci 应该都没有技术上的困难。
我自己的问题就在于不那么想做运维开发，不想折腾服务器，只是想配个好一点的个人开发环境，自己想往其他方向发育。分布式的各种框架也只想做计算部分，不想做运维部分。
发帖也只是为了吸取大佬们的宝贵运维经验，从运维角度理解一下老大的做法。后面我会写部署脚本节省自己的生命，至于 ci 再考虑吧。
总结一下大佬们提到的影响：
1. 安全，目前 zsh 漏洞风险比 bash 高。我比较好奇，这个漏洞风险有没有可能出现反转。其他工具肯定是越少越安全。
2. 稳定，安装额外的软件会影响环境变量、动态库等，导致其他服务不可用。我的运维小伙伴喜欢编译安装应该也是这个原因。归根结底是不信任对系统提供的包管理工具。
3. 性能，补全等操作可能会卡死。这个我觉得基本无解，只能优化没法解决，算法架构没有本质区别的情况下更好的功能肯定需要更多的计算。
4. 规范，不同的人有不同的习惯。有大佬提到跟老大沟通线上软件引入规范，这个其实我很赞成，即使按照我最开始的想法，各种工具也都是用默认配置，没有太个性。对多个方面做检查后引入就 OK 了，但是做检查的人力成本也很高。
5. 别人的服务器，客户会找上门。有的客户只要
最后再次感谢各位大佬传授经验。
以前公司用过 gitlab-ci，知道下面运维大佬们提过的 ci 流程。会写 bash 和 python 的知道这套流程以后要部署一套 ci 应该都没有技术上的困难。
我自己的问题就在于不那么想做运维开发，不想折腾服务器，只是想配个好一点的个人开发环境，自己想往其他方向发育。分布式的各种框架也只想做计算部分，不想做运维部分。
发帖也只是为了吸取大佬们的宝贵运维经验，从运维角度理解一下老大的做法。后面我会写部署脚本节省自己的生命，至于 ci 再考虑吧。
总结一下大佬们提到的影响：
1. 安全，目前 zsh 漏洞风险比 bash 高。我比较好奇，这个漏洞风险有没有可能出现反转。其他工具肯定是越少越安全。
2. 稳定，安装额外的软件会影响环境变量、动态库等，导致其他服务不可用。我的运维小伙伴喜欢编译安装应该也是这个原因。归根结底是不信任对系统提供的包管理工具。
3. 性能，补全等操作可能会卡死。这个我觉得基本无解，只能优化没法解决，算法架构没有本质区别的情况下更好的功能肯定需要更多的计算。
4. 规范，不同的人有不同的习惯。有大佬提到跟老大沟通线上软件引入规范，这个其实我很赞成，即使按照我最开始的想法，各种工具也都是用默认配置，没有太个性。对多个方面做检查后引入就 OK 了，但是做检查的人力成本也很高。
5. 别人的服务器，客户会找上门。有的客户只要
最后再次感谢各位大佬传授经验。
第 2 条附言 · 2019-05-09 20:39:56 +08:00
最后再发表一下自己的意见，其他的也没什么好说的了：
1. 安全和稳定是矛盾的，这中间需要人力来调和，你一个环境一段代码什么都不变也不更新是稳定了，但是随着时间发展肯定会越来越不安全。你为了打补丁升内核啥的，那就不稳定了。
2. 我反正是不想搭在上面那两个事情上面，让别的专业的人来解决就好了，我只要这方面的意识比大部分开发强就行了。
用 htop 省下看 top 文档的时间不好嘛，起码能直接看全进程的启动指令了。
有那时间多看看计算机科学的原理，刷刷算法看看各种框架源码多好。
我是不是让很多人误会了，我不是运维开发，我是 Web 后端开发。
我是不是让很多人误会了，我不是运维开发，我是 Web 后端开发。
我是不是让很多人误会了，我不是运维开发，我是 Web 后端开发。
1. 安全和稳定是矛盾的，这中间需要人力来调和，你一个环境一段代码什么都不变也不更新是稳定了，但是随着时间发展肯定会越来越不安全。你为了打补丁升内核啥的，那就不稳定了。
2. 我反正是不想搭在上面那两个事情上面，让别的专业的人来解决就好了，我只要这方面的意识比大部分开发强就行了。
用 htop 省下看 top 文档的时间不好嘛，起码能直接看全进程的启动指令了。
有那时间多看看计算机科学的原理，刷刷算法看看各种框架源码多好。
我是不是让很多人误会了，我不是运维开发，我是 Web 后端开发。
我是不是让很多人误会了，我不是运维开发，我是 Web 后端开发。
我是不是让很多人误会了，我不是运维开发，我是 Web 后端开发。
 |
101
zong400 2019-05-09 17:29:02 +08:00
@victorywangzhcn 看这么多人说 htop 我刚刚装了个看看，也没发现比 top 好用多少啊？不喜欢 top 我推荐试下 nmon，当年第一次用 nmon 是在 AIX 上，起码 unix 出来的东西，而且真比 top 强很多。
htop 装了有什么不好，估计没人能说出个具体事例，毕竟就是个简单的工具，也不联网不开端口的。但是真有必要装么？ |
 |
102
boris1993 2019-05-09 17:31:58 +08:00 via Android
@ldrljq #57 哈，UNIX 世界的经典 shell 啊，第一次知道这仨还是在《 UNIX 大全》里面
|
 |
103
jugggao 2019-05-09 17:53:33 +08:00
如果用 Htop，我会使用 Docker 镜像跑一个，取消 PID Namespace 的隔离就可以监控主机了。我也不太能忍受在系统装一些额外的工具，想用就把工具打包镜像就好。
|
 |
104
ldrljq 2019-05-09 17:58:15 +08:00
@boris1993 其实也能装 bash，很多都不装罢了= =
所以觉得 bash 已经很好用了，难道 zsh 这么棒吗？有空也尝试一下~ |
 |
105
victorywangzhcn 2019-05-09 18:40:10 +08:00
@zong400 我也 nmon... 只想听听那位的理论，不一会儿换了好几个说法，一点干货没有都在鬼扯。
|
|
106
boris1993 2019-05-09 18:40:47 +08:00 via Android
@ldrljq #104 见仁见智吧，我是 zsh 装 oh-my-zsh 用的，自动补全啊、打一部分命令然后上下翻相关历史啊之类的用的挺舒服
|
 |
107
Imr 2019-05-09 19:45:03 +08:00 via iPhone
我天天摸服务器命令行，lz 你说这俩我是真的一个都不想装，对一个熟手运维来说 zsh 除了好看没有意义，htop 和 top 比也没有实质提升，负载高时候 ps 都要显示好久谁去看这种华而不实的玩意
|
 |
108
luozic 2019-05-09 20:54:17 +08:00 via iPhone
没有内外网和详细的审计体系的情况下，大家倾向于做 SB 最快乐
|
 |
109
Actrace 2019-05-09 21:23:17 +08:00
看来运维确实是一个划水的好职业，各路大佬用作文来诠释划水姿态。
|
 |
110
zgqq 2019-05-09 21:47:18 +08:00
生产坏境搞 zsh ？有点东西
|
 |
111
msg7086 2019-05-09 22:20:10 +08:00  1
@zong400 更智能一些？我用 oh-my-zsh，比如说在各个配置目录间跳转的时候可以 popd （甚至你可以安装 z ），以及自动补全的时候更聪明，而且可以避免一些奇怪的手残。
比如有个叫~的文件你要删，rm -rf ~你家就炸了。但是 zsh 的话，你可以直接用 tab 补全来选择，并且会自动给你选成「\~」，就不会出现这种乌龙的情况。比如你 wget 文件里有&，如果用 zsh 的话会自动给你的链接补上反斜线，免得启动一大堆后台进程出事。 然后我这默认还有 rm *保护，万一手残敲了，还会多提示你一次。 总之，对于「确实」要登录上服务器进行操作的环境来说，zsh 比 bash 更不容易误操作，更友好。 我们用 SSH 操作很少误操作（很少很少），就是因为用了这些更友好的工具（ htop zsh 等）。误操作多的怕不是 bash 之类不太智能的工具用多了然后觉得别人也会手残吧…… |
 |
112
Felix2Yu 2019-05-09 23:15:22 +08:00
看到有几个人的理由是 bash 安全、稳定，实现 zsh 的特性你可以装第三方插件、框架。但是你 bash 装了这些难道就还安全稳定了？
|
 |
113
Admstor 2019-05-09 23:46:05 +08:00 1
运维本来就要对码农是"奇思妙想"作出限制才行
让码农折腾服务器,呵呵呵呵... |
 |
114
feelinglucky 2019-05-10 00:14:08 +08:00
说明负责的机子还不够多，哈哈…
说真的，工作的生产机还是不要折腾了，我从来都是起了 docker 服务就不管了的，越简单越好。自己的开发机子想装什么自己喜欢吧，例如我用测试机跑 Arch 定期 pacman -Syu 下都没人管。 |
|
115
feelinglucky 2019-05-10 00:16:24 +08:00
噢，对了，还有台 FreeBSD 机子，我换成了 zsh （默认的 csh 实在不习惯）表示情绪稳定，但线上的肯定不会那么干
|
 |
116
secondwtq 2019-05-10 03:37:48 +08:00 1
楼主你在机器上有自己的用户不？
建一个 ~/.local 目录，底下放 bin lib share 之类的，把 binary 下下来拷进去（有些可能需要自己编译一下，比如依赖 glibc/libstdc++ 版本过高啊，对路径有依赖啊之类的） 然后 PATH，LD_LIBRARY_PATH 之类的设置一下，除了安装麻烦一点，平常使用时 90% 情况下和系统包管理器安装是没有区别的，一些语言的包管理器比如 pip npm 之类的也是允许在 HOME 下装包的。 总之除了没法改默认 shell （这个只是登录时需要手动切一下），是完全用不着 root 的，根本不需要谁给权限，也不需要覆盖什么系统文件 当然还是可能工具出现奇葩 bug 把一个 core 占满这种情况，不过我觉得既然都人肉运维了，其实风险和不装没差别。就算是自动化运维，也难保自动化工具不出问题啊 |
 |
117
ww2000e 2019-05-10 08:29:25 +08:00
几百台服务器，你准备开几百个窗口看 htop ？
|
 |
118
ifconfig 2019-05-10 11:17:43 +08:00
曾经在服务器装 b 装了 zsh，结果进不去了。。。。。
相信作死永无止境可以一试 |
 |
119
jiejiss 2019-05-10 11:39:30 +08:00 1
别在服务器上用 zsh，zsh 有的地方跟 bash 表现不一样的
比如 echo -n 比如 nohup npm start &无法真正 nohup，需要用 nohup npm start &! 才能实现 bash 里的 nohup npm start &功能 还有各种环境变量的不同 |
 |
120
JerryCha 2019-05-10 14:24:51 +08:00
勇士啊
不敢 100%保证不会出错的东西绝对不会去弄，哪怕 0.1%的出错概率，只要发生了能救的回来算是浪费了时间，救不回来那要走流程问责了。 |
 |
122
scoful 2021-08-17 13:45:33 +08:00
|
Select Language