Linux运维老手也常踩的5个Unix环境搭建坑

　　Linux运维老手也常踩的5个Unix环境搭建坑——这标题不是标题党，是我去年4月在阿里云ECS上部署PostgreSQL 15.3高可用集群时摔出来的血泪结论。当时用的是CentOS Stream 9，kernel 5.14.0-284.11.1.el9_2.x86_64，连SSH都调通了，结果pg_rewind死活同步失败，查日志发现是/tmp挂载了noexec——而默认systemd-tmpfiles.d/里那条规则，根本没考虑/usr/local/bin/pg_rewind被硬链接到/tmp/.tmpXXXXX执行的路径。

　　第二个坑：OpenSSL版本锁死在1.1.1w不升级，表面看很稳——但去年4月某天下午3点17分，我们给Go 1.21.0应用加mTLS双向认证，curl能连通，Go http.Transport却持续报x509: certificate signed by unknown authority。折腾四小时才发现golang.org/x/crypto/acme/autocert依赖libcrypto.so.1.1内部一个未公开的ERR_load_crypto_strings符号加载顺序，而RHEL9默认yum install openssl-libs会静默覆盖/usr/lib64/libcrypto.so.1.1，却漏掉/usr/lib64/engines-1.1/padlock.so这个引擎模块——它没签名，但被dlopen()强制加载，直接让整个crypto init流程panic。运维老手？他们刚手动删过/etc/yum.repos.d/CentOS-Base.repo里的gpgcheck=1，还夸自己“绕过了验证”。

　　第三个坑更隐蔽：/etc/sysctl.conf里net.ipv4.ip_forward=1开了，但容器网络始终不通。排查三天，最后发现是systemd-networkd接管了veth0@if11的UP状态，而它默认读取/etc/systemd/network/99-default.link——文件末尾写着LinkLocalAddressing=no，强行关掉了LLA地址分配。但Docker daemon v24.0.7启动时居然不校验link-local可达性，就直接往169.254.1.1发ARP……直到tcpdump抓到那一帧被DROP的ARP reply才发现真相。这不是文档缺失，是systemd-networkd的man page第4版才悄悄把LinkLocalAddressing参数从"yes/no"扩成"yes/no/ipv4/ipv6"，但绝大多数生产镜像装的还是v239版。

文章配图，仅供参考

　　第五个坑，关于shell兼容性。以为zsh 5.9和bash 5.1差异不大？去年4月上线新构建系统，用zsh写了个deploy.sh，里面用了${array[@]:0:3}语法，在Ubuntu 22.04的bash 5.1.16上正常，但某台老机器跑着bash 4.4.20——数组切片语法直接报错，CI流水线崩溃。更绝的是，这台机器上/usr/bin/sh竟然是dash，而dash根本不认$(( ))中的负数索引。没人想到该在#!/bin/bash后面加一行set -o pipefail；也没人敢动客户现场那台运行11年没重启过的FreeBSD 12.3——它默认sh连echo -n都不支持。

　　新技术总在边缘地带咬人。

　　我昨天刚在macOS Sonoma 14.5上复现了第一个坑的变种：Homebrew安装的coreutils 9.4把stty改成了用ioctl(TCGETS2)而非TCGETS，但某国产终端模拟器驱动里TCGETS2被硬编码为0x542A——比Linux标准值0x5429大3，导致stty sane反复失败。这事连glibc都没修，只改了musl libc的头文件。要不你先fork一份musl，把include/asm-generic/termbits.h里那个宏改成0x542A试试？

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!