RHEL 9.7生产部署：系统初始化与安全优化实践

1. 部署方案设计与事前规划

1.1 部署需求与镜像准备

RHEL 9.7这个版本，说新不新说旧不旧，但对于生产环境来说，选它做承载业务的操作系统底座，稳定性是有保障的。我这次是在一套物理服务器上做全新部署，配置是Intel Xeon 双路CPU、128GB内存、2块1TB NVMe SSD做RAID1，网络是双千兆网卡绑定。整体思路很明确：装一台干净的最小化系统，然后在上面做一轮初始化优化，让它达到能直接上生产的标准。

准备工作第一步是拿ISO镜像。如果你有Red Hat订阅，直接去官方门户下载，没有订阅也可以用开发者订阅，注册一下就能获得免费授权。拿到镜像之后，先校验一下SHA256，不要省这一步，我曾经遇到过下载损坏的镜像，装到一半报错，白白浪费了半小时。用命令：

sha256sum rhel-9.7-x86_64-dvd.iso

把输出值和官网的值比对，没问题再开始做启动盘。制作启动盘我推荐用Ventoy，比dd直接写入更方便，能直接在U盘里放多个ISO，启动时自己选。物理机如果支持UEFI，用Rufus或者Ventoy都行，注意分区格式选GPT。

1.2 分区方案与安装方式抉择

分区是安装阶段最需要想清楚的事。RHEL 9.7默认的自动分区对生产环境不够理想，它会把所有空间都分给根分区，看起来省事，但后面日志暴涨或者容器镜像堆积的时候，根分区一旦写满，系统直接进入只读状态，服务全部被拖死。我见过不止一次这种事故，一台跑监控的服务器，/var目录被历史告警日志撑爆，应用起不来，查了半天才发现是分区规划的问题。

我的推荐方案是手动分区，用LVM管理：

swap分区大小这个事，128GB内存的机器到底分多少？老规矩说swap是内存的两倍，但现在的服务器内存动不动64G起步，两倍根本不合理。我个人的习惯是：内存小于8GB的机器，swap分2倍内存；内存16GB到64GB，swap分16GB；内存超过64GB，swap可以控制在16GB以内，甚至某些纯计算节点不配swap也行。原因是内存够大的情况下，swap大量使用反而拖慢性能，系统频繁换页，IO负载直接拉高。分一个兜底的16GB，是防止某些应用突发内存占用把OOM Killer触发起来误杀关键进程。

安装方式上，单台机器不需要上Kickstart，手工安装就行。如果你是要批量部署二十台以上的同配置机器，那强烈建议用Kickstart加PXE网络安装，能省掉大量重复劳动。这次是单台部署，我直接走的图形安装界面，注意在安装时要选的软件包集合，选"Minimal Install"（最小化安装），等装完再按需装东西。最小化安装的好处是少了很多用不到的系统组件，磁盘占用小、暴露的攻击面少、启动也快，符合生产环境一贯瘦身的原则。

2. 系统初始化与基础环境配置

2.1 主机名、网络与时间设置

装完系统重启进命令行，第一件事是确认基础信息没有配置错位。主机名要跟业务规划对应，别用默认的localhost。我自己用hostnamectl设置：

hostnamectl set-hostname node01.example.local hostnamectl status

改完主机名后，旧终端里提示符可能还是localhost，重新登录一次或者执行exec bash刷新即可。另外，/etc/hosts里最好把主机名和IP对应关系加上，避免部分服务做地址反查时解析不到，白白拖慢连接建立速度。

网络配置这块，RHEL 9.7默认用NetworkManager管理网络。我见过不少老运维，打开/etc/sysconfig/network-scripts/ifcfg-ens192就直接改，文件里写IP、掩码、网关，然后重启网卡发现完全不生效。这不是你写错了，而是RHEL 9系列里NetworkManager接管了所有网络配置的激活权限，手动改ifcfg文件后必须通过nmcli重新加载才能生效。正确做法是用nmcli：

nmcli connection modify ens192 ipv4.method manual ipv4.addresses 192.168.10.20/24 ipv4.gateway 192.168.10.1 ipv4.dns "223.5.5.5 8.8.8.8" ipv4.dns-search example.local nmcli connection up ens192

如果你要做双网卡绑定，用nmcli创建bond类型连接，把两块物理网卡作为port加入就行，这里不展开，生产环境中链路聚合建议用mode=4（LACP协议），需要交换机配合配置。

时间同步必须在系统装完就处理，否则日志时间和业务时间对不上，排障的时候痛苦指数飙升。RHEL 9.7自带chrony，我的配置习惯是这样：

vim /etc/chrony.conf # 添加国内可用的时间服务器 server ntp.aliyun.com iburst server time1.aliyun.com iburst server time.cloud.tencent.com iburst # 允许系统时钟漂移修正 makestep 1 3

改完重启chronyd并确认同步状态：

systemctl restart chronyd chronyc sources -v chronyc tracking

能看到System time的偏移量在毫秒级以内，说明时间同步正常工作。同步时间这个问题故障隐蔽，但影响范围极大，比如数据库主从复制是基于时间戳的，时间一偏，复制直接出乱子；日志审计定位安全事件时，时间错乱会导致证据链断裂。所以这一步务必做扎实。

2.2 dnf源配置与基础工具补齐

RHEL 9.7默认的软件源指向Red Hat的CDN，如果你的机器能访问外网并且已用subscription-manager注册，直接就能用。但很多生产环境处于内网隔离区，没有外网访问权限，这种情况下有两条路可以选。

第一条路，在内网搭一套本地仓库镜像，把Red Hat源、EPEL源镜像下来，客户端配置repo地址指向内网服务器。这个方案灵活，但需要一台维护成本。第二条路，直接用安装光盘做本地方源，简单粗暴：

mkdir -p /mnt/cdrom mount -o loop /dev/sr0 /mnt/cdrom cat > /etc/yum.repos.d/local.repo <<'EOF' [local-baseos] name=Local BaseOS baseurl=file:///mnt/cdrom/BaseOS enabled=1 gpgcheck=0 [local-appstream] name=Local AppStream baseurl=file:///mnt/cdrom/AppStream enabled=1 gpgcheck=0 EOF dnf clean all dnf makecache

光盘上的BaseOS和AppStream两个源能覆盖绝大部分系统基础软件包，但像nginx、redis这类第三方软件就不够了。如果需要，可以再从EPEL源下载相关rpm包传到内网装。EPEL（Extra Packages for Enterprise Linux）是Fedora社区维护的扩展仓库，RHEL 9对应epel-9版本，配置方式：

dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm

装完基础源之后，我习惯把一批通用工具先装上，这是从多年运维经验里总结出的"标配"：

dnf install -y vim wget curl telnet lsof tree net-tools bind-utils tar unzip gdisk pciutils sysstat iotop htop psmisc lrzsz dnf groupinstall -y "Development Tools"

Development Tools这个组包里面有gcc、make、git等编译链工具，后续如果要在机器上编译安装软件就离不开它们。sysstat提供sar、iostat、mpstat这些性能采集命令，生产环境排障必备。

3. 系统优化细节：从装完变成能用

3.1 内核参数调整策略

RHEL 9.7装完默认的内核参数是"兼容模式"，很多参数按最保守的方式设置，对于业务服务器来说太浪费。我做的内核优化，核心思路是：不要照抄网上的"性能调优"大集合，而是根据这台机器将来跑什么业务来选参数。

举个例子，机器将来主要跑Web服务和数据库读写，那网络栈和文件系统相关的参数优先调整；如果只是做内部监控采集，内核参数几乎不需要动。我在/etc/sysctl.conf里添加了这样一组参数：

# 降低swap使用倾向，优先用物理内存 vm.swappiness = 10 # 增加单个进程允许的最大文件句柄数 fs.file-max = 2097152 # 网络连接队列相关，应对短连接高并发 net.core.somaxconn = 65535 net.ipv4.tcp_max_syn_backlog = 65535 net.ipv4.ip_local_port_range = 1024 65535 net.ipv4.tcp_tw_reuse = 1 net.ipv4.tcp_fin_timeout = 30 # 脏页回写策略，减少突发IO，保证数据安全 vm.dirty_ratio = 30 vm.dirty_background_ratio = 5

逐个说下为什么这么配。vm.swappiness设成10，物理内存128GB的机器平时几乎用不到swap，设置太低比如0或1的话，有些内存回收机制可能在特殊场景下反而出问题，10是个兼顾稳妥和性能的值。net.core.somaxconn和tcp_max_syn_backlog关系到高并发连接的排队能力，如果你的服务用Nginx做反向代理，这两个值调大后，突发流量来临时不会因为半连接队列溢出而丢请求。ip_local_port_range扩大到1024到65535，是因为大量短连接场景下源端口不够用，系统会报Cannot assign requested address这个经典错误。

tcp_tw_reuse这个参数争议比较大，内核文档里明确说在NAT环境下慎用，因为TIME_WAIT状态的连接如果被复用，而TCP序号又恰好冲突，可能造成数据错乱。我自己的经验是，纯内网、无NAT、服务端和客户端都在可控范围内的场景，开启没有问题；跨公网的场景就关掉它，用调整tcp_fin_timeout代替。调优没有一揽子方案，必须结合网络拓扑判断。

配置写完后，执行sysctl -p重载，再用sysctl -a | grep net.core.somaxconn确认生效。

另外注意一点，容器场景下内核参数不能只改宿主机，例如podman容器内部读到的somaxconn值，受宿主机netns和容器netns隔离机制影响，如果是host网络模式则直接继承宿主机参数，bridge模式需要单独调优。这个坑后文会提到。

3.2 用户级资源限制与systemd限额

文件描述符的限制是另一个高频坑点。默认情况下，进程的文件句柄上限是1024，生产环境完全不够用。你只要遇到过Java应用报Too many open files，或者数据库连接池大一点服务起不来，你就知道这个参数有多重要。

修改方式有几种，传统做法是改/etc/security/limits.conf：

cat >> /etc/security/limits.conf <<'EOF' * soft nofile 65535 * hard nofile 65535 * soft nproc 65535 * hard nproc 65535 EOF

但注意，这种方式对登录会话有效，对systemd托管的服务不一定生效。RHEL 9.7上很多服务是用systemd unit管理的，必须单独设置服务文件的LimitNOFILE属性。比如调整sshd服务：

mkdir -p /etc/systemd/system/sshd.service.d cat > /etc/systemd/system/sshd.service.d/limits.conf <<'EOF' [Service] LimitNOFILE=65535 EOF systemctl daemon-reload systemctl restart sshd

确认进程实际生效值：

cat /proc/$(pgrep -u root sshd | head -1)/limits | grep "open files"

如果输出是65535，说明改成了。很多人在limits.conf里改了但发现不生效，十有八九就是没查systemd层面的限制，这两个层级并不是简单的继承关系，各自有独立默认值，都得配。

3.3 日志管理与journald瘦身

RHEL 9.7的日志系统继承了systemd时代的journald，同时保留rsyslog。默认配置下，journald会无限积累系统日志，长期运行下来journal目录能占到几GB甚至几十GB磁盘空间。这不是危言耸听，我处理过一次故障，一台跑了大半年的机器，/var/log/journal占了37GB，终端操作都卡顿，根因就是journald默认上限是磁盘空间的10%，磁盘越大日志攒得越狠。

因此我调整了journald配置：

vim /etc/systemd/journald.conf # 关键参数 SystemMaxUse=1G MaxRetentionSec=30d RuntimeMaxUse=256M

SystemMaxUse指持久化日志放在/var/log/journal最多占1GB，超过这个量，系统会自动清理最老的日志。MaxRetentionSec是保留30天，对大多数业务排查场景够了，审计要求高的系统可以适当调大，但配合SystemMaxUse一起看。改完重启journald生效：

systemctl restart systemd-journald

日志轮转这块，如果还用rsyslog处理特定应用日志，/etc/logrotate.d下的规则也要检查一遍，比如nginx的access.log，默认按天轮转，但如果你调整了日志格式或者增加输出量，轮转频率也要同步调整。我的习惯是把重要业务日志通过rsyslog单独写到独立目录，配好logrotate，避免全部堆在/var/log/messages里；messages这种汇总日志一旦被占满，很多应用的写日志操作直接阻塞。

4. 安全加固与日常运维底座

4.1 SELinux策略选择与排错

SELinux是每个RHEL运维都绕不开的话题。社区里有一种声音是"装完直接setenforce 0，省心"，我强烈建议不要在生产环境这样做。SELinux的设计初衷是强制访问控制，就算进程被攻破，也只能在受限域内活动，不能越权访问其他资源。关闭它是图一时省事，但把系统的纵深防御拆掉了一面。

我见过一个最新最典型的场景，一台跑Nginx的RHEL 9.7机器，管理员给Nginx配置了一个非标准端口8443来对外的业务，结果防火墙放行了、selinux状态也是Enforcing，可服务就是访问不了。查日志才看到日志里面明确写着类型为httpd_t的进程访问端口被SELinux拦了，原因是SELinux针对端口定义了一个类型上下文，默认只有80、443等标准端口允许监听，非标准的需要手动加白。

处理方式很简单：

semanage port -l | grep http semanage port -a -t http_port_t -p tcp 8443

同理，如果你的Web服务要连接后端的3306端口，但SELinux布尔值没打开httpd_can_network_connect，也会被拦截。排查这类问题，我的习惯步骤如下：

先看SELinux日志：

grep -i selinux /var/log/messages | tail -20 ausearch -m avc -ts recent

有AVC拒绝记录时，使用audit2why解析：

ausearch -m avc -ts recent | audit2why

输出会直接告诉你哪个布尔值没开，哪个端口没放，照做即可。对业务上确实需要放宽的项，用setsebool -P打持久化标记，重启不会丢失。

在生产环境里，真正需要setenforce 0的情况基本是：第三方闭源软件没有适配SELinux上下文、或者新装好的系统在做POC验证，时间紧想先跑通功能。这种时候我的建议也是先用permissive模式，而不是直接disabled。permissive模式下SELinux策略不会阻止操作，但会把违规行为全部记录到日志里，你可以根据日志追查问题，最后还是要切回enforcing。我记得很清楚，有一次把一个数据采集程序从permissive切到enforcing后，网络连接直接失败，查日志才发现它调用的一个共享库需要访问/var/tmp下的临时文件，SELinux上下文件类型不对，我把文件放到了允许访问的目录，顺手修了这个潜在问题。

4.2 SSH安全加固与防火墙配置

SSH是Linux服务器的生命线，也是最常被暴力扫描的攻击目标。RHEL 9.7默认的sshd配置还算规整，但还是有几个点必须强化。

第一，禁止root远程登录。root账号密码一旦被爆破成功，就等于把整个系统的钥匙交出去了。合理做法是用普通用户登录，需要提权时用sudo。编辑/etc/ssh/sshd_config，找到PermitRootLogin项改成no。如果你确认只有固定运维IP会连这台机器，可以配合Match Address限定来源IP：

Match Address 10.10.0.0/16 PermitRootLogin no

第二，优先使用密钥认证替代密码认证。把公钥复制到服务器后，在sshd_config里设置PasswordAuthentication no。切换之前千万确认无论普通用户还是root，钥匙都能正常登录，否则你把自己锁在门外就只能去物理控制台捞人了。

第三，改SSH默认端口的问题。有人认为改端口是"调优刚需"，我个人的习惯是：对内网服务器，默认22没问题，内网一般有防火墙ACL控制；对公网暴露的机器，改端口确实能挡住大量批量扫描流量，但要注意SELinux和firewalld双保险都要带上。改端口不是安全方案的全部，还得配合fail2ban做暴力破解拦截。fail2ban在EPEL源里有，装完配置好sshd的jail，五分钟内同一IP连续失败三次以上就临时封禁，效果立竿见影。

防火墙方面，RHEL 9.7默认启用firewalld，管理命令是firewall-cmd。最小化安装后默认只放行ssh端口，我的配置习惯是先把默认区改成drop：

firewall-cmd --set-default-zone=drop firewall-cmd --reload systemctl enable firewalld --now

默认区改成drop意味着所有未显式放行的流量直接丢弃，比默认的public区（仅放行少量服务）更严格。然后按需放行端口：

firewall-cmd --permanent --zone=public --add-port=443/tcp firewall-cmd --permanent --zone=public --add-port=3306/tcp firewall-cmd --reload firewall-cmd --list-all

注意firewall-cmd加--permanent是写配置，不加则是临时规则，但如果只做临时放行没有--permanent，服务器一重启就丢了。这个细节踩过坑的人才会记得住。

4.3 系统软件更新与自动安全补丁策略

补丁管理是生产环境的核心问题。很多运维不重视，系统装完就放那儿跑，三年不更新，直到被漏洞打穿才追悔莫及。RHEL 9.7默认支持dnf-automatic，可以设置自动下载并安装安全补丁。

但我不建议设置成全自动毫无提醒，尤其是对企业级数据库、核心业务服务所在节点，某个内核补丁自动装上，重启之后服务起不来，造成的损失比漏洞攻击还大。我的方案是：

配置dnf-automatic只自动下载不自动安装，配合监控检查更新情况：

dnf install -y dnf-automatic vim /etc/dnf/automatic.conf # 修改如下 downstream_method = dnf apply_updates = no emit_via = motd

apply_updates设成no，系统会定时下载更新但不会自动装，然后通过/run/motd.d系通知你有哪些更新可以装。我每周一看一次更新列表：

dnf check-update --security

评估安全补丁级别，测试服务器先装、验证通过后再滚动到生产节点。这样既不冒进也不放任，兼顾安全性和稳定性。

日常巡检我还习惯用systemctl status排查异常服务、ss -lntp查看端口监听情况，配合前文提到的sysstat工具定期抓取CPU、内存、磁盘IO基线数据，这些数据可以在问题发生时快速定位异常点。你自己心里要有一条基线线，比如这台机器平时CPU使用率一般不超过20%，某天突然涨到80%还持续稳定，那十有八九有异常进程或者部署了新的定时任务没评估好资源占用。运维里面"设备健康检查"做得好，故障引发的救火次数会大幅减少。

5. 常见问题与踩坑记录

实际部署过程中，有几类问题是反复出现的，我按"现象-原因-处理"整理成表，方便你对照排查：

再单独说两个我这次部署中真实踩到的坑，很有代表性。

第一个坑是网卡的命名问题。RHEL 9.7在部分服务器上，网卡的名称不是传统的eth0，而是根据BIOS槽位生成的enp3s0、ens192这种命名。老运维写脚本时还按eth0、eth1去匹配，结果脚本完全失效。我的建议是：所有涉及网卡名的脚本、服务配置，用nmcli确认实际名称后统一改成变量，别在脚本里硬编码。如果你实在需要传统命名，安装时在内核启动参数里加一个biosdevname=0或net.ifnames=0，RHEL 9.7上这个参数依然有效，但注意这会影响系统初始化的网络链路顺序，尽量在装机阶段定好，后面改容易引起混乱。

第二个坑是systemd服务的资源上限。用systemd托管一个高并发的Java应用时，我按照老经验修改了limits.conf的nofile和nproc，结果应用照样报文件句柄不够。排查了很久才发现问题出在Java服务unit的文件里，systemd对这个服务有自己独立的限制，在service文件里加：

[Service] LimitNOFILE=1048576 LimitNPROC=65536

然后daemon-reload重启服务才彻底解决。这个问题比较典型：RHEL 9系列对systemd的服务隔离做得彻底，修改limits.conf已经管不到systemd管理的进程了，必须每个unit单独设置。这也是RHEL 9和旧版本一个很大的运维习惯差异。

6. 优化效果与后续扩展思路

写这篇记录的时候，系统已经稳定运行了一段时间。部署完成时，我用脚本做了一轮基本检查：sshd正常监听、firewalld规则齐备、SELinux处于Enforcing且无风险告警、chrony时钟偏差低于1ms、journald日志占控在1GB以内、原生资源限制全部落实。内网压测的结果，Nginx短连接QPS比默认配置下提升大约是30%到40%，注意这只是一个参考数据，具体提升幅度跟业务场景关系极大——如果你的瓶颈在应用代码本身，内核参数调优能带来的提升微乎其微，这也是为什么我一直强调"先搞清楚瓶颈在哪再动参数，别照抄任何调优清单"。

整个部署流程走下来，最有价值的经验其实是：RHEL这种企业级系统，安装只是起点，优化成一套适合你自己业务的底座才是关键。装完系统就丢到机架上不管，和花半天时间做初始化配置，后续维护成本能差出一大截。建议你在做完一轮配置后顺手做个记录文档，把每个参数为什么这么设写清楚。一两个月后再回看，你会有新的理解，这些理解才是运维经验真正沉淀下来的部分。

如果你想在更多机器上复现这套配置，下一步值得投入的方向是自动化：把分区的kickstart文件、post-install的初始化脚本、sysctl的配置模板都固化下来，用Ansible把上面所有步骤写成playbook，新机器一键部署，效率和一致性都能大幅提升。RHEL 9.7对Red Hat Ansible Automation Platform原生支持很好，跑这套方案运维成本会显著下降。