这是一个创建于 2033 天前的主题，其中的信息可能已经有所发展或是发生改变。
楼主现在在一个比较小的实施团队，老大不让在客户提供的服务器上装 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 后端开发。
 |
1
wu67 2019-05-09 09:26:29 +08:00
额, bash 还配什么...客户的服务器, 那不是生产环境吗, 最多就跑一下部署脚本, 这还要搜索补全? 一个 tab 的事...
|
 |
2
MeteorCat 2019-05-09 09:27:25 +08:00 via Android
oh my zsh 自己电脑用用得了，线上版本不要动，会影响服务器性能
|
 |
3
jinhan13789991 2019-05-09 09:27:28 +08:00
linux 所有东西都是文件，你可以自己配置一个脚本，自己用的时候使用 zsh，自己不用了，就切换回去。
|
 |
4
zhengyongtao 2019-05-09 09:28:23 +08:00  5
首先你使用 zsh 或者 htop 可能会导致现有的架构出现异常，服务器严格控制软件安装是十分合理的操作。第二是 bash 本身补全和搜索功能已经很完备了，实在不行你可以自行添加一些环境变量到~/.bash_profile 里，在 linux 下运维尽量使用原生工具减少依赖是合理的。
|
 |
5
blless 2019-05-09 09:29:36 +08:00 via Android
htop 也就算了… zsh 难道要天天去服务器上操作吗
|
 |
6
zong400 2019-05-09 09:30:56 +08:00
看到楼上的回复我就放心了哈
|
 |
7
twl007 2019-05-09 09:37:28 +08:00 via iPhone 1
@zhengyongtao 感觉你说的并没道理…… 我们有专门的工具可以把自己的 profiles 同步到所有服务器上 而且也有 zsh …… 这能影响啥啥现有架构出问题……
|
 |
8
ly4572615 2019-05-09 09:38:52 +08:00 1
等机器多了你会发现你根本不回去考虑这种问题
|
 |
9
Hieast OP PS: 团队没有专门的运维，也没有部署脚本，发布靠手动拉代码重启，热操作少不了的，htop 也只是略微一下没有监控系统的问题。
我以前一个运维小伙伴也跟各位是同样的观点，不建议生产环节安装任何多余的软件。 但是我自己的定位是开发，可能本质上不想做太多运维的工作，大家伙教育我的时候能不能举一下案例，我就是不明白有什么坑。 |
|
10
zhengyongtao 2019-05-09 09:40:21 +08:00 1
@twl007 所以我这里使用的冠词是可能，并不是一定。有些情况下随意安装软件会导致一些动态库文件被覆盖，导致一些奇怪的问题发生，如果有运维经验的同志应该经常会遇到类似问题。其次是每家公司做法不一，我们不能直接说怎么做比较好，我只能说减少依赖对于 linux 运维来说是一件合理的事情。
|
 |
11
tcpdump 2019-05-09 09:42:21 +08:00
这是玄学吧
|
 |
12
openbsd 2019-05-09 09:43:02 +08:00 1
htop 本地编译好一个文件 传过去给个 755 就好，但是 zsh,你确定生产系统有必要？
再好用，你也没必要在生产服务器上整不是 ？ |
 |
13
wuweijia 2019-05-09 09:46:10 +08:00
你是基于服务器开发？ [dog]
|
 |
14
leadfast 2019-05-09 09:46:28 +08:00 via Android
哈哈哈，看完楼上老哥们回答，我瑟瑟发抖啊
|
 |
15
eliteYang 2019-05-09 09:48:18 +08:00 1
如何是个人开发环境, 无所谓, 自己折腾就好了.
如果是线上正式运行环境, 还是建议不要装了, 而且一般稍微大点的厂商, 对线上环境都会有严格的权限控制 |
|
16
MeteorCat 2019-05-09 09:48:53 +08:00 via Android 3
主要是 zsh 你插件装多了，那种自动提示你要想清楚，还是在线上高并发的服务器上，可能你也不知道这个自动提示要检索多久，一不小心 zsh 帮你检索整个服务器卡顿了，这个谁也不好说
|
|
17
zhengyongtao 2019-05-09 09:49:00 +08:00 1
@Hieast 举个例子的话就比如说当你安装一个监控工具的时候，提示你需要升级 gcc，当你升级了 gcc 之后，动态库文件会被覆盖，进而导致其他进程(严重一些可能是生产进程)崩溃。当然这只是其中一个例子，并不是说安装了之后一定会如何如何，而是说在 linux 下安装操作应当谨慎。
|
 |
18
pmispig 2019-05-09 09:49:59 +08:00 1
因为这个属于第三方开源工具，安全性和 bash 也有一点的差距，之前 bash 的漏洞你了解不
|
 |
19
jmc891205 2019-05-09 09:50:08 +08:00 1
请自行 Google 以下关键字"zsh 安全漏洞 site:www.cnnvd.org.cn"
或点击该链接： http://letmegooglethat.com/?q=zsh%E5%AE%89%E5%85%A8%E6%BC%8F%E6%B4%9E+site%3Awww.cnnvd.org.cn |
 |
20
cominghome 2019-05-09 09:50:44 +08:00
1. 禁止对生产服务器做任何不必要的操作。除非你的老大愿意帮你背锅。我司服务器除了必须的补丁，别的一概不升级，除了一些跑容器的机器升级了内核。
|
 |
21
lzjamao 2019-05-09 09:51:43 +08:00
个人服自己的账号随便搞！
|
|
22
blless 2019-05-09 09:53:29 +08:00 via Android
我记得我们公司有个家伙就在公司内网环境装 zsh，不知道配置错了啥，bash 都进不去了
|
 |
23
KuroNekoFan 2019-05-09 09:54:02 +08:00
我之前公司的运维还不让拉 npm 的 package 呢
|
 |
24
defunct9 2019-05-09 09:54:06 +08:00
可以装，无所谓
|
 |
25
houzhimeng 2019-05-09 09:54:53 +08:00
htop 没听说过有风险
|
 |
26
inter12 2019-05-09 09:54:54 +08:00
太矫情了。这个问题也发上来问
|
 |
27
caskeep 2019-05-09 09:58:03 +08:00 via iPhone
物理服务器运维问题多多，环境上 docker 或者 k8s 是不是能解决这些问题，物理机器就可以稍微浪起来了？求教
|
 |
28
edgnoz 2019-05-09 09:58:33 +08:00
你天天没事上服务器上干嘛？ bash 不够你用？
|
|
29
twl007 2019-05-09 09:59:17 +08:00 via iPhone
@zhengyongtao 你们没有服务器配置管理工具来维护服务器配置么 就算有意外更改大部分时候下一次工具运行的时候也给还原了
@jmc891205 服务器登陆并不面向公网啊…… 不走公司内部网络怎么可能访问到服务器？ |
 |
30
zqguo 2019-05-09 10:00:46 +08:00 via Android
htop 还好
|
|
31
twl007 2019-05-09 10:01:02 +08:00 via iPhone
@zhengyongtao 同志你说的是 glibc 吧？
|
 |
32
mywaiting 2019-05-09 10:01:33 +08:00 3
这个跟团队大小没有关系的，倒是跟你们的开发文化和程度很有关系
我能说我一个人的项目，都是往 git 仓库里 push 代码就自动执行 CI 测试、自动部署、全流量测试（网站不大就全流量测试了，不搞这么多的特殊操作），后面自动收集代码运行出错的 log，数据库每天自动备份到 dropbox 除了偶尔的安全补丁更新，极少（很少）登陆过服务器 SSH 去操作什么东西 往高大上点说，作为软件工程实践的一部分，我一直认为，直接登录服务器操作什么东西是不道德的~ |
 |
33
reus 2019-05-09 10:04:17 +08:00
难不成还线上 debug ？
|
 |
34
MonoLogueChi 2019-05-09 10:04:32 +08:00 via Android
常用代码全写成脚本，可以 ssh 连上去嘛，总不能所有操作都是要跑到机房里去操作吧
|
 |
35
victorywangzhcn 2019-05-09 10:04:56 +08:00
@zhengyongtao htop 会覆盖啥？
|
|
36
victorywangzhcn 2019-05-09 10:05:40 +08:00
@twl007 我觉得也是说的 glibc...
|
 |
37
lululau 2019-05-09 10:05:48 +08:00
就是因为 low
|
 |
38
lancelock 2019-05-09 10:12:10 +08:00
那还不如改进发布流程，上个 ci
|
 |
39
rrfeng 2019-05-09 10:16:43 +08:00
htop 勉强可以，但是不是必须的。
zsh 滚一边去，生产环境绝对不允许。 |
 |
40
yalin 2019-05-09 10:18:48 +08:00 1
新潮的软件，虽然更新快，特性多，反过来说就是可能不稳定
|
 |
41
fiht 2019-05-09 10:22:09 +08:00
zsh 确实有性能问题
当 memory 和 swap 都满了的时候 zsh 不能响应但是 bash 是可以的 =，= 以及文件夹下面有 NNN 多文件需要自动补全时 zsh 响应时间会很长，bash 就没有这个问题 |
 |
42
8a9a09dw12 2019-05-09 10:23:45 +08:00
要么忍,要么滚
|
 |
43
kevinhwang 2019-05-09 10:24:02 +08:00 via Android
楼主还没分清什么是客户端，什么是服务端。
客户端注重交互，服务端注重功能和性能。请问 htop 和 zsh 能提升服务端什么功能和性能。 |
 |
44
uncat 2019-05-09 10:29:32 +08:00 3
回答第二个问题的第一部分.
> 不用 zsh，bash 怎么配置才能让补全和搜索更顺手？ https://github.com/scop/bash-completion -> 自动补全 https://github.com/Bash-it/bash-it -> 类似于 OMZ https://github.com/tj/git-extras -> 删除已经合并的远程分支 https://github.com/BurntSushi/ripgrep -> grep 替代 https://github.com/sharkdp/fd -> find 替代 https://github.com/junegunn/fzf -> CTRL-R 替代 https://github.com/rupa/z -> 类似与 autojump. 快速跳转 |
 |
45
rockyou12 2019-05-09 10:39:22 +08:00
做个 ci 流程吧……哪怕写几个部署脚本也不用考虑装不装了
|
 |
46
junjieyuanxiling 2019-05-09 10:41:12 +08:00 via Android
@openbsd #12 555 就够了
|
 |
47
jesnridy 2019-05-09 10:49:12 +08:00
之前线上 Mac 机器被人替换了默认 shell 为 zsh，导致一个跑了很久的服务在家目录下执行 find 命令找不到包，必须 cd 到绝对路径下才能行，所以线上环境还是不要瞎搞。（当然引起上面这个问题，代码层面也可以直接使用 bash -c 'xx'执行，但是为啥要瞎搞线上环境呢，自己本地玩玩行了）
|
 |
48
lihongjie0209 2019-05-09 10:51:09 +08:00
htop 还能理解，zsh ？ 你在逗我
|
 |
49
wangchonglie 2019-05-09 10:51:56 +08:00 1
装了 oh my zsh 后, 默认的编码方式被改变为 ASCII, 去配置文件修改后, 默认环境改为 utf-8, 代码也能正常运行, 但是使用 pycharm 远程调试发现, locale 查看出来的和服务器端的不一致, 导致所有中文路径的代码都有问题。所以, 公共环境还是不要尝试这些新奇的工具了。
|
 |
50
fhsan 2019-05-09 10:54:47 +08:00
按标准的规范流程，开发完成、自动打包构建、自动测试、自动部署发布，所有的日志都搜集起来。
日志提供检索、服务器有监控告警（磁盘数据库负载网络） 服务器有个统一的 sudo 用户，不允许使用 root，也没必要登录服务器。 现在我们这基本上都是 git 部署，手动重启，线上 debug。 你们不是运维，流程规范没遵守，也不是开发，没走标准的流程，运维开发很尴尬。 运维就是保证配置能正确下发生效，有问题能迅速回滚，你考虑过回滚吗？ 至于 zsh、htop、npm、pip 之类的，都有内部源，有安全审计的。 |
 |
51
impl 2019-05-09 11:05:27 +08:00 via Android
服务器要的是安全稳定。想玩这些在自己机器上玩。
|
 |
52
victor 2019-05-09 11:06:57 +08:00
跟同事当面沟通和请教 ×
上网来问 √ |
 |
53
corvofeng 2019-05-09 11:09:33 +08:00 via Android
我不止装了 htop，zsh 还装了 tmux，感觉运维的时候真的很需要啊
|
 |
54
CEBBCAT 2019-05-09 11:10:33 +08:00
这个问题问得好，提前规避了未来被老大拎起来打的可能性
|
 |
55
wr410 2019-05-09 11:12:09 +08:00 1
有种东西叫做静态编译，拷上去直接用，别说是我教的。
|
 |
56
mcfog 2019-05-09 11:18:04 +08:00 11
公共服务器不应当有任何这类效率软件，要提升效率应该做的是运维自动化上监控，上 provision tool，提升 ssh 操作“体验”是反模式，你觉得效率提升了，其实是离专业的，可靠的生产环境越跑越远
别说 zsh 了，profile，vimrc 之类都不应该有什么个性化的配置，你喜欢 oh my fish 你就装了用，别人喜欢 prezto 的呢，fish 的呢，小张习惯 alias 掉 rm，然后你发现清理日志回收空间磁盘还是爆满，小王作为资深 vim 党用过以后你发现 vi 你都用不来了，后天生产要加机器，你初始化一台机器以后发现怎么都装不好，原来是生产的服务不知不觉已经依赖了小张小王和你的各种魔法，哦对，还有已经离职的小李的 |
 |
57
ldrljq 2019-05-09 11:19:48 +08:00
没用过 zsh 的表示能用上 bash 的已经超级美滋滋了。。。各种补全，快捷键感觉已经超级爽了。。。
尼玛 Solaris 和 HP-UX 上自带的奇葩 shell，什么 ksh/csh/sh 各种反人类啊啊啊。。。 |
 |
58
iyaozhen 2019-05-09 11:21:53 +08:00 via Android 1
等你有几万台机器的时候你就啥都不想装了。
当然为了工作方便。你需要和老大沟通一个线上软件引入规范，本地自己使用方便和线上使用完全是两回事，至少 zsh （你肯定想用 oh my zsh ）绝对是不行的 |
 |
59
Kobayashi 2019-05-09 11:23:16 +08:00 1
线上服务器不让就不让呗，你总不能自己偷着搞个上去吧。
第 1 个问题，风险我不清楚，因为 ZSH 有更多特性更容易引入 Bug ？不过 ZSH 没有被发行版选为默认 shell 的原因，应该是因为 Bash 属于 GNU 项目。 第 2 个问题，目前知道的 Bash 框架只有 Bash-it，以前用过，觉得这个框架可能写的并不咋样。试举两例，一，整个项目代码缩进混合了 2 个空格、4 个空格，Tab。二，稍微看了一下， 就看到如下这种脱裤子放屁的写法（引入不必要 subshell ）。 [[ `which pyenv` ]] && eval "$(pyenv init - bash)" 而且单从速度上来说，command 查找命令比 which 块，可惜 bash 没有 (( $+commands[tree] )) 这种写法。 说回配置方案上，Bash 补全可能没有办法向 ZSH 那样顺手，Bash 并不能列出个下拉表让你按着 Tab 切换过去。至于安全，没人能证明你装的框架、插件绝对安全。 |
 |
60
ThomasZ 2019-05-09 11:27:20 +08:00 via Android
不说稳定性，不是自己的服，你搞那么多到时候客户找上门来还得给你擦屁股，要是我也肯定不让你装
|
 |
61
longxiaoyun 2019-05-09 11:28:51 +08:00 1
只能说明 你老大依据他的经验 认为安装这些存在隐患，在公司中很重要一条是 服从领导安排。
|
 |
62
Sharuru 2019-05-09 11:32:47 +08:00
服务器多不是理由啦，Ansible 一把梭（
我只想说，这是别人的服务器。举个例子别人到你家装修，在不委托的情况下装修师傅能按照自己的审美给你设计吗？ 或者说，这些额外安装的第三方工具会告知客户吗？以后出 bug 了楼主公司负责维护吗？ |
 |
63
opengps 2019-05-09 11:35:35 +08:00
服务端上，用的软件越单一越安全，至少查后门相当容易
|
 |
64
HackerPainter 2019-05-09 11:37:13 +08:00
搞不懂为啥要在生产环境装这种东西，什么 zsh，vim 插件等等，见一个就行打一个
|
 |
65
wizardoz 2019-05-09 11:39:51 +08:00 4
有些东西不是技术问题，但是却对技术人员影响很大的。
比方说，不是很常规的功能，就不应该花精力把它搞的很方便。因为一旦做得好了以后会被滥用。 你把生产服务器配置的很顺手，下意识的你就会在上面搞事情。 |
 |
66
nocrush 2019-05-09 11:42:56 +08:00
测试环境我就装了，zsh 和 htop 我觉得 好用
|
 |
67
xiaolanger 2019-05-09 11:46:51 +08:00
多个软件多份风险
|
 |
68
motecshine 2019-05-09 11:49:45 +08:00
头像...
|
|
69
Hieast OP @motecshine 是你画的嘛？我用了几年了，要交保护费嚒。
|
 |
70
AstroProfundis 2019-05-09 12:14:44 +08:00
问题难到不是楼主试图在生产环境做开发吗
|
|
71
Hieast OP @AstroProfundis 之前 supervisor/systemctl 都没有，nohup 直接上了，一个进程一个日志，光是查日志就很烦。进程管理和日志合并还是我来之后才改的，但是查日志依旧很麻烦。日志和监控系统暂时没精力弄了。
|
 |
72
huiyifyj 2019-05-09 12:23:10 +08:00 via Android
zsh 不让装就算了，htop 都不让？
|
 |
73
abcbuzhiming 2019-05-09 12:48:47 +08:00
htop 不让装有点过了，就是个软件而已，zsh 绝对不要随便动，生产环境的 shell 你要是弄错了，当心进都进不去
|
 |
74
thedrwu 2019-05-09 13:00:16 +08:00 via Android
|
 |
75
silentstorm 2019-05-09 13:04:03 +08:00
@ldrljq
我记得好像连退格键都不支持，简直就是奇葩。 |
 |
76
sunmonster 2019-05-09 13:16:28 +08:00
就只有一个原因，水平不行而已
|
 |
77
littlewing 2019-05-09 13:20:17 +08:00
你要在客户服务器上做开发？
|
 |
78
tailf 2019-05-09 13:54:38 +08:00
htop 随便用，zsh 这种东西还是不要装到生产环境上
|
 |
79
yuhr123 2019-05-09 13:56:09 +08:00
首先，客户的生产服务器，各路英豪都可以登录使用，这已经是硬伤了。
|
 |
80
msg7086 2019-05-09 14:00:14 +08:00 4
这一大楼的回复把我看得一愣一愣的。
首先是团队规模。大团队，生产服务器都是自动化的。小团队，甚至有些一个公司就几个人的，你让人家全上自动化，puppet/chef/ansible，你是想提供免费服务给楼主公司呢，还是想逼着人家天天加班啊？是不是看楼主晚上睡太多了觉得不舒服啊。 然后说 zsh 有安全风险的，哇塞厉害了啊，什么安全风险赶紧给 RHEL 报一个让他们修啊，藏着掖着干什么？还有说 zsh 第三方的兄弟们，不知道你们是从哪个第三方下的 zsh，不过我们都是从第一方，也就是发行版自己维护的软件仓库里下的呢。 还有说啥，配 zsh 配到把 bash 搞坏的？咱们能不能别把 v2 论坛用户都当傻逼啊。你同事没这个本事你可以让他别碰服务器，或者让他多学习一个啊。因为他把系统搞坏了，所以全 v2 论坛用户也都得什么都不能碰？有人用 rm 还删错文件了呢，和 Redhat 说说让他们把 rm 命令给去掉？ 说到没本事，当仁不让就要说到脚本的 Shell 设置了。一个脚本如果不指定运行的脚本，那么就必须限制在所有 Shell 共用的 feature 中。说不要随便换 Shell 的，可别忘记 Ubuntu 早就把默认的脚本 Shell 改成了 dash。如果脚本不指定 bash 而去用默认 Shell 然后炸了，那与其去怪改 Shell 的人，我觉得倒不如请人把原本就「写错了」的脚本给「改正确」来得好哦。 还有说装了 zsh 或者 vim 插件影响服务器性能的。能不能给我表演一下平时不登录服务器不运行这些程序的时候，这些静静待在硬盘上一动不动的二进制文件是如何影响到你们宝贵的服务器性能的？我想了半天也就是可能多吃了 SSD 的几个块导致主控 GC 时候少一个候选空页吧。 总结一句话。请不要因为自己、自己的同事、自己周围的人写脚本、配服务器的水平太蔡，就随随便便把别人也当成脚本都写不好、服务器都配不好的蔡鸡。虽说近年来 v2 新人水平下降得厉害，但是也不能全让你们给当成傻子教吧。 PS: 上面还有一位说装软件能把 glibc 搞坏的，我也不想多回了。你要是装发行版自带的包能搞坏 glibc，赶紧找 Redhat 之类的领赏去。你要是装的第三方软件搞坏了服务器，请看上一段。 |
|
81
msg7086 2019-05-09 14:02:39 +08:00
@mywaiting 好奇问一句，你服务器上数据库和数据文件的 replication 和自动打包备份上传，在不登录服务器 SSH 的情况下是如何配置好的？用了什么中央管控的软件么？这方面我的确很想了解一下有没有既方便又不用手动操作的方法。
|
 |
82
bumz 2019-05-09 14:02:55 +08:00
客户的机器，或者生产环境
能不添加额外的软件就不添加，这是默认值，不需要理由的 要添加软件才需要足够有说服力的理由，zsh 能做什么 bash 做不了的事吗？ 你也说了，「应该」不会 |
|
83
bumz 2019-05-09 14:04:05 +08:00
不是「绝对」不会
那你就是在引入不必要的风险，这点效率的提高和风险比起来不值得一提 |
|
84
bumz 2019-05-09 14:14:41 +08:00
@msg7086 #80 引入不必要的软件就引入了不必要的安全隐患，这不是说有已知漏洞了才叫安全隐患
有了已知漏洞还不修就不叫安全隐患了，这等于是大门敞开 连 bash 都出过藏了很多年才发现的高危漏洞，你敢说你装一个 zsh 再装一堆插件，存在漏洞的可能性没有大大提升？ 漏洞存在的可能性不需要证明，这已经是公认的常识，没漏洞才需要证明 同样能不做的事情就不做，做了就引入了操作失误的风险 你敢说你敲任何命令都绝对不可能敲错，绝对没有出错的时候？ 这不是水平高低的问题，有犯错的可能，就别做多余的事情增加出错的机会 生产环境，少折腾，这也是常识 |
 |
85
nosay 2019-05-09 14:16:05 +08:00
很多人不让乱装软件的初衷，可能仅仅只是害怕中毒而已。
见太多 22 端口，密码登陆，root 进去一把梭的。 别说你们没见过，跟这个比起来，装个 zsh 算个屁啊。 |
|
86
ldrljq 2019-05-09 14:36:18 +08:00
@silentstorm 对，有的是必须用 delete 删除，有的是不能前后移动光标，有的是不能按上重复前面的命令。。。
|
|
87
msg7086 2019-05-09 14:41:31 +08:00
@bumz 装一个 zsh 和装一个 bash 出现漏洞的机会是均等的，如果你不能证明 zsh 比 bash 的质量差，或者后者的漏洞更多，不如不要就这么拍脑袋下结论？你这个论点根本站不住脚，因为把上文 bash 和 zsh 两个词互换也是完全成立的。
另外上次那个 bash 的高危漏洞你真的搞清楚是什么吗？那个是要暴露 cgi-bin 并且允许第三方远程执行你本地的脚本才会中招。换句话说，你装了 Apache，开启了 cgi-bin，并且把 bash 设置成执行 Shell，然后在 cgi-bin 里放了脚本程序给公众执行，才会中招。 也就是说，这种情况下，别说你装了 zsh，就算是你把阿毛阿狗各种有漏洞的 shell 全装上，也只有 bash 的漏洞会被利用到。所以，与其防止别人安装 zsh，不如请你「把配置错误的 Web 服务器修一修」？ 或者你来说说，还有其它哪种情况是一个有漏洞的 shell 会被第三方人士执行到的，我来学习一个。 不要拍脑袋瞎想，说点有道理的内容出来。 |
 |
88
julyclyde 2019-05-09 14:43:45 +08:00
应用自己、应用运行时需要的配置和数据、外部依赖、依赖以外的操作系统环境
这几部分需要明确定义 你装那些工具，是属于以外的，你用着方便，但不能保证随地都有 |
|
89
mywaiting 2019-05-09 15:08:37 +08:00
@msg7086 不登陆服务器不敢说，就是很少需要直接 SSH 登陆的时候
一般来说，生产环境的主机在云厂商那里 initialize 出来以后，每个项目自己有一个 python fabric 的脚本，填上拿到 root 的账号密码，就可以自动执行服务器的初始化，安装环境、下载生产的代码，然后有代码可以自动配置好系列的 crontab 来定时备份数据库 需要参考的 fabric 脚本的话，你可以去参考 Newsblur 项目下面的 fabfile，我的也基本一样的 小项目，没有必要上那些重型装备，方便顺手就可以了 |
|
90
zhengyongtao 2019-05-09 15:09:11 +08:00
@msg7086 乍看之下你说的很有道理，但是仔细看看就知道你是在偷换概念，上边多数人说的是可能发生的情况以及这种情况下常规的处理方法。对于喜欢折腾的人来说，bug 不是病是良药，对于喜欢稳定的人来说，服务器不出问题就是最好的良方，身在不同岗位不同环境下，处理方式也不同。在题主的前提是客户提供的服务器这个大前提下，我认为处理手段更倾向于后者。更何况你怎么知道服务端上跑着什么进程，安装的软件是否会影响到服务端进程？在 v2 上无非求同存异，把建议当结论，把大家都当成没经验的小白，这种习惯可不好。
|
 |
92
Navee 2019-05-09 15:41:52 +08:00
其实 zsh 没必要，htop 还行
|
|
93
victorywangzhcn 2019-05-09 15:47:33 +08:00
@zhengyongtao 大哥能不能不要跑题，我就问问 htop 能影响啥，他有什么依赖，你 ldd 之后给你答案了吗？照你这个理论大家啥东西都别装了，libssh2 前两天还有个 userkey auth 认证的大问题，稳不稳定？ 少说方法论，来点干货
|
 |
94
sleepm 2019-05-09 15:48:34 +08:00
可以上 fish
bash 真心不友好 |
 |
95
bengxy 2019-05-09 15:58:03 +08:00
理论上不应该在生产环境的机器上做任何的编辑工作啊
所有的东西都应该是线下编辑打包好，直接推送到线上部署的 |
 |
96
mrco 2019-05-09 16:04:54 +08:00
这个其实就是原则问题,服务器上就最小化轻量运行,统一配置.
不是个人 PC 可以各种自定义,明白了吧 ? |
|
97
bumz 2019-05-09 16:32:37 +08:00
@msg7086 #87 如果服务器自带的是 zsh，额外装一个 bash 同样会增加风险
并不关乎 bash 和 zsh 谁更安全 此外我举的那个漏洞只是为了说明高危漏洞出现的机会，并不是想说只要防范了这一个漏洞就高枕无忧了 安装的软件越多，潜在的攻击面越多，少装不必要的软件减少的风险不是正确的配置能替代的 在那个特定漏洞的利用场景之下，只有默认 shell 的漏洞有机会触发 并不意味着安装有漏洞的软件不会增加其它场景下的攻击面 例如，在某些场景下，攻击者获得了以普通用户身份执行某些代码的权限 假如用户安装了一个不必要的，带有提权漏洞的软件（用户对此不知情） 该软件的存在就使得「以普通用户身份执行某些代码的权限」 得以成为「以超级用户身份执行某些代码的权限」 后者的破坏性显然大于前者 而这样的事情本可以通过不安装该不必要的软件来避免 也就是说，确实存在至少一种场景，多安装一个不必要的软件，由于其中含有未知漏洞的可能性，一些本来不可能出现的攻击得以出现 也就是说安装不必要的软件增加了攻击面，这个风险不是由已知的信息带来的，而是由未知带来的，无法通过正确配置防范 |
 |
98
xderam 2019-05-09 16:58:44 +08:00
12 年的时候也有开发想让我在服务器上装 zsh，被我拒绝了。
后来想想，其实无所谓，又不是让我把 root 的默认 sh 改为 zsh。 但如果现在有开发让我把所有生产服务器都装上 zsh，从技术角度没啥，但我会怀疑这开发是不是在坑我。 |
 |
99
ipwx 2019-05-09 17:05:30 +08:00
我觉得 puppet / openstack 之类的对于小团队确实过分了。
但是 CI & ansible 又不费多少事。装个 GitLab 就有 CI，ansible 自己机器装个也都有了。这有什么好回避的。。。 |
 |
100
wenzhoou 2019-05-09 17:23:59 +08:00 via Android
要是我，我不会不让你装，你先写一份报告证明装了没问题，我要全部是干货的论文。
然后，你要装，给你权限， 第一：你给我整一套：以后大家往服务器上安装自己想用的东西的时候的，安装规范和反安装规范出来。第二：然后整个安装了之后有可能碰到的常用问题解决方案 list 出来， 第三：以及后继运维看得懂得使用说明。 用规范的制度压死你。看你还装不装。 想学习想玩另外弄台电脑。不差钱。要动生产环境可要悠着点。 |
Select Language