Linux运维老手也常踩的5个Unix环境搭建坑
|
文章配图,仅供参考 Linux运维老手也常踩的5个Unix环境搭建坑——这标题不是标题党,是我两个月之前在阿里云华北2可用区(cn-beijing-b)用CentOS 7.9部署PostgreSQL 13.6高可用集群时,亲手撞上的真实事故链。当时凌晨三点三十七分,pgpool-II健康检查连续超时17次后挂掉,日志里只有一行“backend 0: connect timeout”,但ss -tuln显示5432端口明明在监听。第一个坑是/etc/hosts文件里混用了IPv6 localhost ::1和IPv4 127.0.0.1却没加注释说明优先级——我们团队六个人有四个人在重装系统时照抄了公司模板里的双栈写法,结果Java应用连本地Redis时偶尔走v6通路,而redis.conf中bind只写了127.0.0.1,触发“connection refused”。实测:把::1那行注释掉后,连接失败率从每千次1.8次降到0;但如果你用systemd-resolved且未禁用,哪怕注释掉也会通过lo接口偷偷转发。这点几乎没人提过,手册里也没警告。 第二个坑是shell启动顺序陷阱。我两个月之前调试一个Zabbix agent自启脚本,发现/usr/local/zabbix/bin/zabbix_agentd --config /etc/zabbix/zabbix_agentd.conf总报“error while loading shared libraries: libldap-2.4.so.2: cannot open shared object file”,ldd一查确实缺,但ldconfig -p又显示libldap确实在/etc/ld.so.conf.d/openldap-x86_64.conf里。最终查到是/etc/profile.d/目录下有个00-zabbix-env.sh被source两次——第一次在login shell读取,第二次在非交互式bash -c调用时又读,导致LD_LIBRARY_PATH被重复拼接,路径长度爆了PATH_MAX(4096字节),glibc直接截断最后三个库。删掉第二处source后,问题消失。你猜多少家银行的Zabbix定制镜像还在用这个配置? 第三个坑更隐蔽:NTP服务启用chrony后,/etc/chrony.conf里默认的driftfile /var/lib/chrony/drift权限是600,但很多国产安全加固脚本会统一将/var/lib/目录设为700,导致chronyd进程因无法写入driftfile而降级为仅校准、不保存漂移数据,一周后误差累积到83ms——刚好超过Kerberos 5分钟容忍窗口。我们产线有两台服务器因此在周二凌晨批量拒绝AD域登录,重启chronyd也不恢复,必须手动touch /var/lib/chrony/drift && chown chrony:chrony /var/lib/chrony/drift && chmod 600 /var/lib/chrony/drift。这是新技术带来的新裂缝:chrony比ntpd更依赖状态持久化,但加固策略还活在2012年。 第四个坑在SELinux布尔值误设。我两个月之前在一台刚装完RHEL 8.6的机器上配nginx反代Docker API,死活连不上unix:/var/run/docker.sock,strace看connect返回-13(Permission denied)。sestatus确认是enforcing,但ausearch -m avc -ts recent | audit2why输出全是“allowed by boolean samba_export_all_ro”,完全无关。后来用sesearch -A -s httpd_t -t container_var_run_t -c unix_stream_socket才发现缺的是httpd_can_network_connect_db,但文档说它只管TCP。实际上,RHEL 8.6的selinux-policy-3.14.3-87.el8.noarch里,这个布尔值也控制对某些AF_UNIX socket的connect权限——是最近两个补丁悄悄扩展的,连红帽KB都没更新。打开它就通了。这种变更根本不会出现在release notes里。 第五个坑是tmux会话恢复时的$SHELL污染。我们在测试服务器上用systemd user unit管理tmux,重启后ps aux显示所有pane的SHELL还是/bin/bash,但实际执行env | grep SHELL返回/bin/sh——因为/usr/lib/systemd/system/user@.service中默认的Environment=SHELL=/bin/sh覆盖了用户~/.bashrc里的export SHELL=/bin/bash。导致所有cron job通过tmux session启动的脚本都丢了bash特性,比如[[ ]]判断直接报语法错。修法不是改systemd,而是改tmux.conf加set-option -g default-shell "/bin/bash"。这点连tmux官网FAQ都漏写了。 Linux运维老手也常踩的5个Unix环境搭建坑——我认为它优点在新技术。新技术像一层薄冰,下面全是老工具留下的暗流,踩上去不响,但裂痕在水下延展。 下一步?我打算把这五条写成Ansible role,附上自动检测脚本,但不确定能否覆盖openEuler 22.03 LTS SP3的容器化场景。 (编辑:站长网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |


5G模组低功耗:嵌入式运维的新标尺
差评变引擎:点评驱动的闭环运维法
Linux数据库环境搭建:七步稳态实战指南
PHP防SQL注入:11年运维总结的3层硬核防御体系
Unix高效包管理:创业者的技术基建必修课
硬核巡检日志里的创业闭环:从运维到 tech startup 的实战逻辑
Linux下H5开发环境与数据库一体化配置方案