企业官网建设流程全解析

RH134 学到第四篇，基础命令和文件权限已经不是障碍了。系列笔记走到这里，我想把最贴近真实运维的三块内容——网络配置、存储管理、自动化任务——放到一起讲。为什么把它们揉在一起？因为在企业环境里，用户能感知到的故障往往不是“某个命令记不住”，而是“网络不通”“磁盘满了”“任务没有按计划跑”。这三件事在 RH134 考纲里各自独立，但到了实际场景中经常以连锁反应的方式出现：磁盘耗尽导致日志写不进去，日志服务异常又让 cron 任务在静默中失败。这类综合故障，恰恰是这门课真正想训练的东西。

这篇总结适合三类人：刚考完 RHCSA、准备进入 RHCE 阶段的同学；日常工作需要管理 Linux 服务器、但知识还停留在零散命令上的运维；还有像我一样喜欢把考试内容重新翻译成实战场景的人。我会把自己做过、也踩过坑的实验过程写出来，照着敲一遍基本都能跑通。

1. 整体设计与思路拆解

1.1 为什么第四篇要聚焦“网络、存储、自动化”

RH134 不是 RHCSA 的简单重复，它的最大特点是场景化。官方课程会把你学过的碎片技能组装成一个完整任务，比如“部署一台可以被客户端访问的文件共享服务器”，这个任务就需要网络配置、存储挂载、防火墙放行、SELinux 上下文调整、日志跟踪这些模块协同。只看单个命令，考试可能也能过，但到生产环境里仍然做不了事。所以我在这篇总结里没有按官方 PPT 的线性顺序走，而是先把“系统如何连出去”“数据放在哪里”“活谁去定时干”这三件事说透。

这三者之间的依赖关系非常强：NFS 服务首先要有一个稳定的固定 IP，然后要有一块能随时扩容的磁盘，最后还要有一个每天凌晨自动执行的同步任务。单独练任何一个环节都不会出问题，合在一起才是真正的考验。RH134 考试里有一种综合题，表面上是配置某个 Web 服务，实际上你在操作过程中一定会碰到网络地址写错、目录挂在错误的分区、服务起不来时日志没有打开这类连环坑。所以第四篇更像一个“集结点”：前几篇讲的是零件，这篇讲怎么把零件装成能跑的机器。

1.2 正确的练习顺序与验收标准

我建议按照“网络 -> 存储 -> 自动化”的顺序来练，因为这是依赖关系决定的。先保证服务器能被外界访问，再让数据落在一块可扩展的存储上，最后用调度器把整个流程串起来。不要敲完命令就觉得自己会了，给每个模块设置一个可验收的小目标：

• 网络模块：重启后 IP、网关、DNS、静态路由全部不变。
• 存储模块：磁盘空间不足时，能在 5 分钟内完成逻辑卷扩容并生效。
• 自动化模块：任务跑挂时能看到日志，并且能立刻确定是调度问题还是脚本问题。

这样练下来，后面学 SELinux、防火墙、服务配置的时候会轻松很多。它们本质上是网络和存储的组合应用：防火墙决定网络通道是否开放，SELinux 决定服务有没有权限访问存储上的文件，日志则把两者之间的错误暴露出来。这篇总结不是孤立的知识点，而是承上启下的关键一棒。

2. 核心细节解析与实操要点

2.1 网络配置：nmcli 才是持久化配置的正道

很多新手还停留在 vim /etc/sysconfig/network-scripts/ifcfg-ens160 再 systemctl restart network 的老办法。这个办法在旧系统上能用，但在现代环境里既容易写错格式，又可能和 NetworkManager 冲突。RH134 认可的做法是用 nmcli 管理网络连接。

先分清两个概念：设备（device）是物理网卡，连接（connection）是 NetworkManager 里保存的一套配置。一个设备可以有多个连接配置，但同一时间只能激活一个。我们平时用 ip addr show 看到的是设备状态，而 nmcli connection show 看到的是连接配置。如果改了连接配置却没有激活，或者激活的不是当前设备对应的连接，就会出现“配置看起来改了但 IP 没变”的怪象。

给网卡配置静态 IP 的标准流程如下：

nmcli con mod ens160 ipv4.addresses 192.168.1.100/24 nmcli con mod ens160 ipv4.gateway 192.168.1.1 nmcli con mod ens160 ipv4.method manual nmcli con mod ens160 ipv4.dns "223.5.5.5 8.8.8.8" nmcli con up ens160

注意最后一步不能省，否则连接不会重新加载。想要开机自动连接，再加一句：

nmcli con mod ens160 connection.autoconnect yes

这也解释了为什么有时重启后配置失效：连接配置确实写了，但 autoconnect 是 no，NetworkManager 启动后不会自动激活它。另外，配置静态路由可以这样追加：

nmcli con mod ens160 +ipv4.routes "192.168.200.0/24 192.168.1.254"

如果需要改主机名，用 hostnamectl set-hostname 是首选，不要手动去改 /etc/hostname。

2.2 存储管理：LVM 是设计给扩容用的

RH134 的存储部分重点放在 LVM 上，而不是单纯分区。原因很现实：传统分区建好后想扩容非常麻烦，而 LVM 把所有物理磁盘抽象成一个“存储池”，逻辑卷是从池子里划出来的，随时可以增减。只要池子里还有空间，就不用停机加盘。

三个层级记清楚：

• PV（物理卷）：磁盘上初始化的存储单元。
• VG（卷组）：多个 PV 组成的大池子。
• LV（逻辑卷）：从 VG 里划分出来、可以被格式化并挂载的块设备。

完整创建流程：

pvcreate /dev/sdb vgcreate vg_data /dev/sdb lvcreate -L 5G -n lv_data vg_data mkfs.xfs /dev/vg_data/lv_data mkdir /data mount /dev/vg_data/lv_data /data

扩容流程：

vgs lvextend -L +2G /dev/vg_data/lv_data xfs_growfs /data

这里有个关键区别：xfs 文件系统只能扩大不能缩小，ext4 用 resize2fs 可以扩大也可以缩小。如果题目给的是 xfs，扩容后必须执行 xfs_growfs，否则 df -h 根本看不到容量变化，这是 RH134 实操题最常见的丢分点。

2.3 计划任务：cron、at、systemd timer 怎么选

RH134 会考 crontab 和 at，但在实际运维中，systemd timer 正在慢慢替代 cron。我的建议是三种都要会，但更重要的是知道什么场景选哪个。

at 适合一次性任务，比如“下午三点重启服务”：

at 15:00 systemctl restart some-service # 按 Ctrl+D 结束输入

cron 适合固定周期任务，格式是“分 时 日 月 周 命令”。比如每天凌晨 2 点 30 分执行备份：

30 2 * * * /usr/local/bin/backup.sh

systemd timer 适合需要精确到秒、依赖关系多、或者怕漏跑的任务。它由 service 和 timer 两个单元组成。服务单元负责真正的执行，定时单元负责触发。比如每天凌晨 2 点 10 分跑备份，可以写两个文件：

# /etc/systemd/system/backup.service [Unit] Description=Backup data [Service] Type=oneshot ExecStart=/usr/local/bin/backup.sh

# /etc/systemd/system/backup.timer [Unit] Description=Run backup daily at 2:10 [Timer] OnCalendar=*-*-* 02:10:00 Persistent=true [Install] WantedBy=timers.target

启动命令：

systemctl daemon-reload systemctl enable --now backup.timer

Persistent=true 是 cron 没有的优点：如果定时器设定的时间点机器恰好关机，下次开机后会自动补跑错过的任务。这一点在备份场景里非常实用。

2.4 日志排查：journalctl 永远是第一个工具

日志这块，RH134 会涉及 systemd 日志和 rsyslog 两类。我排查故障的顺序永远是先用 journalctl 把时间窗和错误级别过滤出来，再去翻 rsyslog 的长期归档。

快速定位服务问题的几个命令：

journalctl -u sshd --since "1 hour ago" journalctl -p err -b journalctl -x -u nginx

-x 会给出增强提示，-b 表示只看本次启动以来的日志。如果重启后看不到以前的日志，说明日志没有持久化，需要修改 /etc/systemd/journald.conf 里的 Storage=persistent 并重启 systemd-journald。

我习惯把时间参数写完整，比如--since "2025-01-10 00:00:00" --until "2025-01-10 08:00:00"。这样在日志量大的服务器上能避免反复翻页。journalctl 配合 -u 指定服务，很快就能把“服务突然挂掉”的时间点圈出来。

3. 实操过程与核心环节实现

3.1 一块新磁盘从识别到 LVM 挂载

我以一台 RHEL 9 虚拟机为例，系统里加了一块 20G 的新盘，显示为 /dev/sdb。目标是做成卷组，划分一个 5G 逻辑卷挂到 /data，并且重启后依旧生效。

先确认磁盘：

lsblk

看到 sdb 后，初始化物理卷并创建卷组：

pvcreate /dev/sdb pvs vgcreate vg_data /dev/sdb

创建逻辑卷：

lvcreate -L 5G -n lv_data vg_data

格式化并挂载：

mkfs.xfs /dev/vg_data/lv_data mkdir -p /data mount /dev/vg_data/lv_data /data

为了开机自动挂载，用 blkid 查 UUID：

blkid /dev/vg_data/lv_data

在 /etc/fstab 里追加一行：

UUID=xxxx-xxxx /data xfs defaults 0 2

然后执行 mount -a，再用 findmnt /data 确认。注意不要在 fstab 里写设备路径 /dev/vg_data/lv_data，因为这个路径在重启后可能因为卷组名称变化而失效，UUID 更稳定。

接下来模拟空间不足。往 /data 里写入文件，然后扩容：

vgs lvextend -L +5G /dev/vg_data/lv_data xfs_growfs /data df -h /data

如果忘记 xfs_growfs，df 看到的容量不会变化。我在考试和实际环境中都吃过这个亏，写出来希望你别重复踩。

3.2 重启后 IP 消失的排查实录

某次实验环境里，一台虚拟机重启后突然 ping 不通网关。我的排查顺序如下，前后不到五分钟定位到根因。

先看 IP 是否还在：

ip addr show ens160

发现 ens160 没有 IPv4 地址。再看 NetworkManager 的设备状态：

nmcli device status

设备状态显示 disconnected。设备还在，说明是连接配置没被激活。列出所有连接：

nmcli connection show

有一条名为 ens160 的连接，状态是 down。执行激活：

nmcli connection up ens160

IP 立刻恢复。为了弄清楚为什么重启后不自动连，我检查了 autoconnect：

nmcli connection show ens160 | grep autoconnect

结果值是 no。根因是之前手动 down 过这条连接，NetworkManager 顺带把 autoconnect 关了。修复：

nmcli connection modify ens160 connection.autoconnect yes nmcli connection up ens160

这类问题在考试里非常容易出现，尤其是题目要求“重启后网络配置仍然有效”时，只改 IP 忘了检查 autoconnect，丢分就很冤。

3.3 用 systemd timer 替代 cron 做每日备份

在某台内部服务机器上，我写过一个备份脚本：每天凌晨把项目目录打包，保留最近七天的备份。以前用 cron，后来换成 systemd timer，因为希望错过执行时间后能补跑。

脚本 /usr/local/bin/backup.sh 如下：

#!/bin/bash mkdir -p /data/backup tar czf /data/backup/project-$(date +\%F).tar.gz /srv/project find /data/backup -name "*.tar.gz" -mtime +7 -delete logger "backup completed"

脚本内所有路径必须写绝对路径，因为 systemd 和 cron 执行时的环境变量很少，PATH 基本是空的。

然后创建 service 和 timer，内容见 2.3 节。启用后验证：

systemctl list-timers --all systemctl status backup.timer journalctl -u backup.service

我的习惯是在脚本最后用 logger 记一条时间戳。这样排查时可以快速判断任务是“真的没跑”还是“跑了但失败”，而不是靠猜。

4. 实验环境与工具链速览

4.1 建议准备两台虚拟机

RH134 的学习离不开动手环境。我的建议是准备两台虚拟机：一台当服务器，一台当客户端，网络模式设为内部虚拟网络而不是纯 NAT。两台机器装同一个版本的发行版，服务器至少 2 核 2G 内存，再加一块 20G 的空白数据盘，方便做 LVM 实验。客户端不需要数据盘，但需要能访问到服务器上配置的 NFS、Web 等服务。

这样的环境能覆盖 90% 的 RH134 实验场景。不要为了省事把所有服务装在一台机器上，因为很多故障只有在跨机器访问时才会暴露。比如防火墙规则、SELinux 上下文、路由表这些坑，单机环境根本看不出来。

4.2 常用工具清单

这些工具不一定在 RH134 考纲里明确列出，但工作里几乎天天用：

• ip、ss：查看网络和端口。
• nmcli：管理网络连接。
• lsblk、blkid、findmnt：查看块设备、UUID、挂载关系。
• vgs、lvs、pvs：快速查看 LVM 状态。
• journalctl：查看 systemd 日志。
• tar、rsync：备份和数据同步。
• set -x：调试脚本时逐行追踪执行过程。

安装 bash-completion 也很值，敲命令配合 Tab 补全能省很多时间。考试环境一般自带补全，但平时练习就养成这个习惯，速度会快不少。

4.3 让 Shell 更顺手的小技巧

我习惯在 /root/.bashrc 里加几个别名，比如：

alias ip='ip -color=auto' alias grep='grep --color=auto' alias lv='lvs -o +lv_size,vg_name'

虽然这只是个人偏好，但在实验里能更快扫一眼输出。写脚本时我强烈建议用 set -e 让出错立即退出，避免脚本中途失败还继续往下跑。排查脚本逻辑时再加 set -x，可以看到每一步展开的实际命令。这两个开关是脚本调试的利器。

4.4 给新手的实验验收清单

我练完每个模块后，会用一张清单检查自己是不是真的掌握。网络部分：重启后 IP 是否不变？能否 ping 通网关？用 ss -tlnp 能不能看到服务监听在预期端口？存储部分：是否知道怎么用 pvs、vgs、lvs 反查当前状态？能不能删除一个逻辑卷并重新创建？自动化部分：cron 日志里有没有自定义脚本的记录？systemd timer 的 next elapse 时间是否正确？这些结果记在本子上，比反复看视频有效。学技术最怕的是眼睛会了手不会，清单验收就是把手会这个环节卡死。

5. 常见问题与排查技巧实录

5.1 LVM 扩容后 df -h 容量没变

原因通常只有一个：扩展了 LV，但没有同步文件系统。xfs 用 xfs_growfs，ext4 用 resize2fs。先用 blkid 确认文件系统类型：

blkid /dev/vg_data/lv_data

如果是 xfs：

xfs_growfs /data

如果是 ext4：

resize2fs /dev/vg_data/lv_data

注意 xfs 只能扩大不能缩小。如果有人在挂载状态下对 xfs 执行 lvreduce，数据损坏几乎是必然的，所以生产环境里遇到 xfs 卷，只考虑扩容就好。

5.2 nmcli 修改了 IP 但重启后还是旧地址

先执行 nmcli connection up 看当前是否生效，再检查 autoconnect。还有一个容易忽略的坑：如果同一个设备关联了多条连接，NetworkManager 会按优先级选择，很可能激活的不是你改的那条。用 nmcli device status 看看设备实际关联的是哪个 connection，把多余的配置 nmcli connection delete 掉。

直接改 ifcfg 文件的话，改完必须执行 nmcli connection reload，让 NetworkManager 重新读取文件，否则磁盘上的配置和进程里的配置不一致。

5.3 cron 任务不执行，手动执行却正常

第一嫌疑是环境变量。cron 执行时 PATH 通常只有 /usr/bin:/bin，脚本里用了 /usr/local/bin 下的命令，要么写全路径，要么在脚本开头 export PATH。第二个嫌疑是权限：脚本没有执行权限，或者脚本所在目录其他人无法进入。第三个可能性是任务压根没被触发，查看 /var/log/cron 或 journalctl -u crond 验证。

我在每个脚本入口都加一行 logger "task started"，目的就是让调度器是否触达这件事有据可查。日志里没有这一条，说明问题在调度层；有这一条但后续没执行，则说明问题在脚本内部，排查范围立刻小了一半。

5.4 服务起不来，先查 SELinux 而不是关掉它

服务状态显示 active 但实际访问路径一直 permission denied，这是服务配置模块最常见的故障。别急着 setenforce 0，先看 SELinux 的拒绝记录：

ausearch -m avc -ts recent

如果确认是上下文不对，用 chcon 临时调整，再用 semanage fcontext 设置持久规则。关闭 SELinux 虽然能让服务跑起来，但生产环境里等于放弃了一层重要防护，考试同样不认可。

6. 备考心得与复盘方法

6.1 考试中最容易丢分的三个动作

结合我和周围同事的复盘，RH134 的丢分点往往不在操作难度，而在“持久化”和“验证”两个动作上。第一个是 fstab 写完不执行 mount -a 验证，重启后才发现挂载失败。第二个是改完网络配置不激活连接，配置写了等于没写。第三个是逻辑卷扩容后忘记做文件系统扩容，用 df 看容量没有任何变化。

我给自己定的规矩是：每完成一个题目，反问一句“reboot 之后它还能正常吗？”如果答案不确定，就真的重启一次验证。这个习惯在考试里救过我很多次，也在生产环境里避了不少坑。

6.2 如何把 RH134 练成肌肉记忆

最有效的方法是搭建一个可以反复破坏的实验环境。我通常准备两台虚拟机，一台做服务器、一台做客户端，然后故意制造故障：删除连接配置、移动逻辑卷、修改 SELinux 上下文、改错 fstab 里的挂载顺序，再只靠命令行把系统恢复正常。第一次可能要半小时，多练几次后，遇到真实故障反而不慌了。

RH134 这门课最值钱的地方，不是知识点数量，而是逼你理解系统组件之间的依赖关系。当你能在脑子里画出“网络配置影响服务监听、存储挂载影响数据读写、日志记录影响故障判断”这条链路时，很多命令都不用死记。你清楚每一步操作会牵动什么，自然就知道该查哪里。

6.3 遇到不理解的地方，先 man 再实验

很多人觉得命令记不住，其实是没理解机制。我最常用的学习路径是：man 命令看选项，再看文档示例，最后在虚拟机里做一个最小实验。比如不理解 fstab 前两个字段，就故意写错一个，观察系统启动时会发生什么。实验做多了，知识就不再是孤立的考点。RH134 很多题目其实都在考“你知道这个概念为什么存在”，而不是单纯考“你会敲哪条命令”。

最后再分享一个我个人的习惯：每完成一台服务器的配置，把关键操作整理成一个以日期命名的文本文件放到 /root 下。里面记录改了哪些网络参数、建了哪些逻辑卷、加了哪些定时任务。这个习惯来自一次 RH134 实验后的教训——当时一切正常，两周后出了问题，却完全想不起当时做过什么。现在每次排障，我第一个翻的就是这份“操作日记”。RH134 考的是系统管理的确定性，而确定性来自记录和验证。希望这篇总结能让你在下一台服务器上少踩几个坑。