1. 从RH134考纲出发说说哪些知识点最值得反复啃RH134是红帽认证体系里系统管理员二阶段的核心课程也是RHCSA考试后半段的主要覆盖范围。它跟RH124的区别在于RH124解决的是“能不能上手操作”的问题而RH134解决的是“能不能系统化地管理一台Linux机器”的问题。课程主线围绕用户与权限、进程与服务、存储管理、网络配置、软件包管理、系统日志与监控、计划任务等几个大块展开听起来好像都是基础但实际动手就会发现真正的门槛全藏在命令背后的细节里。这篇文章是“常用知识点汇总合集”的续篇。前一篇大概已经把RH124阶段的基础命令和常规操作梳理过了这次我换个角度不按考纲章节逐条罗列而是以我在实际机器上反复用到的场景为线索把RH134里那些“考了无数次、工作中几乎天天碰到、但很多人到考试当天才搞明白”的点挑出来逐个拆开讲透。适合看这篇内容的人我觉得有三类一是正在备考RHCSA、需要把知识点串成体系的人二是刚接触Linux运维、想绕过教材直接上手干活的实习生或转行者三是已经工作一两年、发现自己一直只会用某几个命令、遇到报错就只能搜索的初级运维。如果你属于其中任何一类这篇内容应该能帮你省掉不少碰壁的时间。我会尽量按“为什么要这样配、怎么落地执行、踩坑是什么”的顺序来写涉及命令时会给出可以直接复制使用的写法涉及配置文件时会展示完整内容。下面正式开始。2. 用户与文件权限的深水区不止是useradd和chmod2.1 用户管理的隐藏参数与删除用户的真实困境RH134阶段对用户管理的考察已经不完全停留在useradd和passwd这种最基础的层面了。考试和实际运维场景里更常见的是带参数的用户创建系统账户、无登录shell、附加组、主组、有效期、家目录模板这些才是真正拉开差距的地方。我常用的用户创建组合是这样的useradd -r -s /sbin/nologin -d /opt/app -M appuser这里四个参数的用意要拆开看-r表示创建系统用户UID会落在系统账户区间通常是1000以下具体看发行版配置这类账户用于跑服务而不是给人登录-s /sbin/nologin指定不能交互式登录的shell防止有人真的切到该账户下执行命令-d指定家目录位置-M则告诉系统不要在创建时自动生成家目录。这类组合常见于部署中间件或自研程序时既能让进程以独立身份运行又不暴露可登录的shell入口。另一个容易翻车的点是删除用户。userdel如果直接不带参数执行只会删除用户账户本身它的家目录、收件目录、临时文件全都留在磁盘上。这对个人练习环境无所谓但生产环境里通常会连带清理标准写法是userdel -r它会一并删除家目录和邮件池。真正让人头疼的是“删不掉”的故障比如某个用户的进程还活着系统会提示userdel: user xxx is currently used by process xxx。此时需要先确认进程再处理pgrep -u username pkill -u username userdel -r username安全生产前最好先备份该用户的数据再执行清理。如果你只是想临时禁用某人而不删除数据用usermod -L锁住密码或者把用户的shell改成/sbin/nologin这两种方式都比直接删账户温和回滚也方便。实际管理服务器时我很少直接删除用户多数情况下先用锁定的方式让账户失效观察一段时间确认没有服务依赖后才真正清理这样既安全又能随时恢复。2.2 umask、setuid、setgid与粘滞位的叠加逻辑权限部分RH134的题目经常把umask、特殊权限位和目录权限混在一起考。umask的本质是“权限掩码”它决定新建文件和目录的默认权限其中文件的基准权限是666目录的基准权限是777最终权限等于基准权限减去掩码中存在的权限位。例如umask 022时新建文件的权限是666-022也就是644新建目录是777-022即755。这里有个新手常犯的认知错误umask 022是“减”而不是“与”。如果掩码是027文件默认权限是666-027640而不是拿二进制位去逐个与运算。理解了这一点做题就不会错。特殊权限位的表现和计算也比较容易混淆。setuid4、setgid2、sticky1三个位可以叠加在普通权限之上使用方式像是chmod 4755 script或chmod 2770 /data/shared。它们各自的实际效果是setuid作用于可执行文件让执行者临时拥有文件属主的身份。典型例子是/usr/bin/passwd普通用户执行它时能以root身份修改自己的密码。setgid作用于目录时新创建的文件会自动继承目录的属组而不是创建者的基本组。这个在团队协作目录里特别有用。sticky作用于目录时只有文件属主、目录属主或root才能删除目录内的文件/tmp就是最典型的例子。把这些位组合使用时要格外小心。我最常踩的坑是chmod -R 777和递归设置特殊权限位的组合操作。比如想设置一个共享目录为2770结果手滑写成chmod -R 2777不仅把目录和所有子文件的权限全部放大还会让普通用户可以在目录里互相删文件——因为没加sticky位。建议是每次递归授权后都先跑一遍ls -lR /path/to/dir确认权限位没有越界再正式上线。2.3 ACL权限的日常用法与mask的坑ACL访问控制列表在RH134的考纲里占有一席之地原因在于传统的u/g/o权限模型搞不定“多个用户对同一目录拥有不同权限”的需求。ACL允许对独立用户、独立组单独授权而不用把所有人都塞进同一个组里。基础操作不复杂setfacl -m u:zhangsan:rwx /data/project setfacl -m g:devteam:rw /data/project setfacl -x u:zhangsan /data/project getfacl /data/project但ACL有一个很容易被忽略的机制mask。当目录设置了ACL之后mask值会自动出现在getfacl的输出中它实际上限制了所有命名用户、命名组以及所属组能够获得的最大权限。换句话说即使你给某个用户设了rwx如果mask是r-x那么该用户实际能用的权限只有r-xACL中记录的名字不会消失但生效范围被mask截断了。我遇到过不止一次这样的情况开发反馈“我给某个账号授权的写权限怎么不生效”登上去一看getfaclmask是r-x改动setfacl -m m::rwx之后立刻正常。所以记住排查ACL问题时第一件事就是看mask它负责卡住权限上限。生产环境里如果团队协作频繁变动人员建议干脆别依赖手写多条ACL把目录的属组固定好组内成员统一加组再用一个默认ACLsetfacl -d -m给新建文件自动继承权限维护成本会低很多。3. systemd现代Linux服务管理的核心3.1 为什么RH134绕不开systemdRH134很大一部分考试内容围绕systemd展开这个趋势不是红帽自己拍脑袋决定的而是整个Linux生态随着RHEL 7引入systemd之后形成的现实。service、chkconfig、rc.local这些传统工具仍然存在但已经全面让位于systemctl。考试不会问“systemd比SysV init好在哪”这种理论题但会要求你完成“写unit文件、启动服务、设置开机自启、查看服务状态”这一整套动作。理解systemd的关键在于它把“服务”抽象成unit常见的有service服务、socket套接字、target启动目标、timer定时器等。systemctl的绝大多数操作都围绕unit展开而unit的定义则写在.service文件、.socket文件等地方。和传统init脚本相比systemd最大的优势是并行启动、按依赖关系启动、崩溃自动拉起以及统一管理日志。日常工作中最常用的几条命令值得反复盘systemctl start/stop/restart/reload 服务名 systemctl enable --now 服务名 systemctl status 服务名 systemctl list-units --typeservice --staterunning systemctl daemon-reload systemctl is-enabled 服务名其中enable --now是实践里非常顺手的组合它把“设置开机自启”和“立刻启动”合并成一步省去了两条命令两个步骤的冗余。写unit文件后一定要先执行daemon-reload否则systemd仍按旧配置执行这是一个非常高频的低级失误。3.2 手写一个Tomcat自启动服务把unit文件吃透很多公司的中间件服务不是通过标准包管理器安装的而是解压tar包直接部署的这类服务不会自动注册到systemd需要自己写unit文件。Tomcat就是一个很典型的目标我之前花了不少时间踩这个坑写清楚之后对其他Java服务就一通百通了。在/etc/systemd/system/下创建tomcat.service[Unit] DescriptionApache Tomcat Web Application Container Afternetwork.target [Service] Typeforking Usertomcat Grouptomcat EnvironmentJAVA_HOME/usr/lib/jvm/java-1.8.0 EnvironmentCATALINA_PID/opt/tomcat/temp/tomcat.pid EnvironmentCATALINA_HOME/opt/tomcat EnvironmentCATALINA_BASE/opt/tomcat ExecStart/opt/tomcat/bin/startup.sh ExecStop/opt/tomcat/bin/shutdown.sh Restarton-failure RestartSec10s [Install] WantedBymulti-user.target这个文件里有几个细节需要解释。Typeforking是关键startup.sh启动Tomcat后主进程会fork出子进程然后自己退出systemd需要知道“父进程退出不代表服务失败”所以必须用Typeforking告诉它去认PID文件。而Tomcat的PID文件路径通过CATALINA_PID指定systemd也要在ExecStart里能看到这个环境变量。如果你用Typesimplesystemd会认为启动进程就是服务主进程而startup.sh很快就退出了服务会被判定失败。User和Group指定了服务运行的账户身份这一点在生产环境里相当重要。用root跑Tomcat虽然省事但一旦应用被入侵攻击者直接获得root权限风险极大。正规做法是创建一个专用账户比如useradd -r -s /sbin/nologin tomcat再把这个账户关联到Tomcat目录的属主上。Restarton-failure表示只在非正常退出时由systemd自动拉起进程配合RestartSec10s设置重启间隔这样既能容忍偶发崩溃又不会由于快速循环重启把系统资源耗尽。写好之后的操作顺序我也说一下很多人会漏掉某个环节导致失败chown -R tomcat:tomcat /opt/tomcat systemctl daemon-reload systemctl enable --now tomcat systemctl status tomcat --no-pager排错时优先看journalctl -u tomcat -e这里会直接给出Java进程的启动日志比看状态码更直观。Tomcat服务最常出现的“ExecStart格式错误”通常是因为行尾多了空格、路径写错、引号不匹配不要慌一行一行检查就行。3.3 systemd故障排查的顺序与常用手段服务启动失败我习惯按以下顺序排查第一步systemctl status 服务名 --no-pager查看主进程状态、PID、最近日志。如果显示failed第二步立刻journalctl -u 服务名 -n 100重点看最后几十行有没有明确的报错关键字比如Permission denied、No such file or directory、Executable path is not absolute等。第三步检查配置文件语法。unit文件里最常见的坑是ExecStart要求路径绝对化且不能包含变量引用除非在用/bin/sh -c等特定写法时After少了目标会用默认顺序启动导致依赖网络的服务在网卡还没就绪时就开始启动。另外unit文件的权限也值得注意chmod 777的unit文件会导致systemd拒绝加载看到“permission denied”时先查文件权限。第四步如果确认unit没问题再看SELinux或AppArmor的拦截日志命令是ausearch -m avc -ts recent或查/var/log/messages。这个方法救过我好几次很多奇怪的“服务起不来、看日志又不报错”最后都落在SELinux身上。4. 网络与远程管理的正确姿势4.1 静态IP配置nmcli与配置文件的取舍RH134阶段网络配置不会考得太深但一定会要求你完成“把一台机器的IP从DHCP改成静态地址”这个任务。CentOS/RHEL系列管理网络的主流方式已经是NetworkManager配置文件在/etc/NetworkManager/system-connections/下而不是老教程里那个/etc/sysconfig/network-scripts/ifcfg-eth0。我推荐优先使用nmcli它比直接改配置文件可靠得多原因是NetworkManager会在后台监听配置文件变化某些版本下手动改完不会自动重载而nmcli会保持状态一致。完整配置过程如下nmcli con add type ethernet con-name static-eth0 ifname eth0 ipv4.addresses 192.168.1.100/24 ipv4.gateway 192.168.1.1 ipv4.dns 8.8.8.8 114.114.114.114 ipv4.method manual nmcli con up static-eth0这里注意几个参数con-name是连接的名称可以自定义ifname是实际网卡接口名必须对应系统的真实接口ipv4.method manual意为手动配置而不是DHCP。配置完成后验证网络是否生效ip addr show eth0 ip route show ping -c 4 192.168.1.1如果我必须改配置文件也会在改动后通过nmcli con reload和nmcli con up来激活而不是直接重启网络服务。这里有个实践小建议在生产环境操作网络前最好准备一个备用登录通道比如带外管理或IPMI否则一旦改错IPSSH断掉之后只能去机房或靠应急恢复手段非常被动。我在很多文档里都写过这句话但还是每次都会有人踩。4.2 主机名管理与SSH连接实用习惯hostnamectl set-hostname是修改主机名的标准命令同时建议手动维护/etc/hosts。有些环境下重启后主机名会被DHCP或云平台重置需要考虑使用nmcli general hostname来告诉NetworkManager持久化设置或修改/etc/sysconfig/network。SSH远程管理这块我一般会注意三个细节一是推荐用ssh-copy-id把公钥推到目标机器上后续登录免密且比定期输入密码安全得多二是限制/etc/ssh/sshd_config里的PermitRootLogin和PasswordAuthentication的值避免root直接密码登录三是改完配置务必重启sshd服务并开第二个会话验证防止配置错误把自己锁在外面。这些习惯看似琐碎但每一条都来自真实事故的教训。4.3 firewalld的zone与端口开放firewalld是后iptables时代管理防火墙的主要工具RH134涉及它的常见操作。最基础的思路是理解zone区域的概念每个zone代表一组规则网络接口可以绑定到某个zonezone里定义允许或拒绝的端口、服务和来源。常用操作如下firewall-cmd --get-default-zone firewall-cmd --list-all firewall-cmd --add-port8080/tcp --permanent firewall-cmd --reload firewall-cmd --list-ports--permanent参数的意思是写入持久规则不加的话规则只在内存中生效重启后消失。加了永久规则后必须--reload否则当前运行时不会变化。这是一个非常经典的易错点如果只加--permanent而不reload当前防火墙状态不变看起来“没生效”如果只加不加永久参数当前生效但重启后丢失。如果服务本身启动了但外部访问不到我通常先本机ss -lntp确认端口是否监听再curl本机验证然后检查firewalld规则最后再看SELinux布尔值。按照这个顺序排查多数问题能在前三步解决。5. 系统日志与监控关键时刻能救命的技能5.1 journalctl的高频率用法整理日志是系统运维最重要的信息源RH134阶段需要掌握的是用journalctl快速定位问题。我用得最多的几个参数组合journalctl -u 服务名 -e # 查看某服务最新日志 journalctl -u 服务名 -n 50 # 查看最近50条 journalctl --since 10 minutes ago --until 5 minutes ago journalctl -p err -b # 查看本次启动以来的错误级日志 journalctl -f -u 服务名 # 实时追踪服务日志不同优先级日志用-p过滤是排查问题时的利器。err及以上通常对应真正的故障warning多可忽略debug则用于深入跟踪。我接到告警时通常先看-p err -b把当次启动的错误全捞出来再逐条分析。如果日志太多导致磁盘满了可以设置SystemMaxUse参数限制journal占用空间具体位置在/etc/systemd/journald.confSystemMaxUse500M改完记得重启journald服务journalctl --vacuum-size500M则能立即压缩现有日志占用。5.2 日志持久化的关键前提/var/log/journal很多人没注意到一个细节默认情况下journald把日志存在内存里的/run/log/journal重启之后历史日志全没了。这在个人测试环境没问题但在生产环境里如果遇到故障需要事后排查丢日志的后果相当严重。正确做法是手动创建持久化目录并设置正确权限mkdir -p /var/log/journal systemctl restart systemd-journald创建之后journalctl就会自动把日志写入磁盘。建议在部署新系统时尽早完成这一步因为等到你发现已经晚了——历史日志早就没了。另外不同服务日志分开看比如Web服务的访问日志和错误日志一般由应用自己输出到/var/log/下不要只依赖journald两个体系配合使用才能覆盖完整排查链路。rsyslog那边也值得一提/etc/rsyslog.conf里的规则把日志分门别类写入/var/log/secure、/var/log/messages等文件对后续审计和故障回溯帮助很大。5.3 日常监控命令组合top、ss、free、iostat怎么搭配监控不是只盯一个指标而是多维度组合。我常用的组合是top看CPU和负载free -h看内存ss -lntp看端口监听和连接状态iostat -x 1看磁盘IO。下面分别说明各命令的注意点。top里最容易被忽略的是load average这个数字。有人一看到load高就以为CPU爆了实际上load还受磁盘IO和进程等待的影响。应该结合%Cpu(s)里的waiowait来判断如果wa很高且进程普遍处于D状态问题大概率在磁盘而不在CPU。free -h的重点是看available而不是简单看free列。Linux会把空闲内存用作缓存来加速读写free值小不代表内存不够available才是真正可用的余量。只要available足够缓冲区占用高不用紧张。ss -lntp替代了老的netstat输出格式更清晰。排查“端口被占用”时ss -lntp | grep 端口号能得到PID和进程名再用ps -fp 该PID定位具体程序。生产环境里出现过同一个端口被残留进程占用导致新服务无法启动的问题这类情况在ss输出里一目了然。iostat -x 1着重看%util和await。如果%util持续接近100%说明磁盘已接近吞吐上限await过高则可能是排队时间增长单个请求时延变大。两者同时偏高基本可以确定磁盘性能瓶颈。6. 软件包管理与dnf/rpm的细节6.1 dnf与rpm的配合使用思路RH134对软件管理的考察主要在dnf和rpm。处理好这两个工具的配合关系是重点dnf关心的是依赖关系和仓库rpm更关心已安装包的文件级信息。日常使用中装软件用dnf查文件属于哪个包用rpm验证包完整性也用rpm。以下组合是我多年来用顺手的dnf install -y 包名 dnf search 关键字 dnf provides /etc/nginx/nginx.conf rpm -qf /usr/bin/systemctl rpm -ql 包名 rpm -V 包名dnf provides在处理“某个文件找不到但不知道它属于哪个包”的场景里非常高效rpm -qf则用于反向查询文件来自哪个安装包线上排查时十分有用——比如你想知道/etc/my.cnf是从哪个包来的一条命令就能定位。6.2 配置本地仓库的完整思路生产环境内网常常无法访问外网仓库所以配置本地仓库是运维基本功。思路是准备一台内网服务器把ISO解压或挂载进去用createrepo生成仓库元数据然后在客户端配置.repo文件。仓库配置文件位置在/etc/yum.repos.d/下内容模板如下[local-base] nameLocal Base Repository baseurlhttp://192.168.1.10/repo/BaseOS enabled1 gpgcheck0配置完执行dnf clean all dnf makecache dnf repolist如果客户端提示找不到仓库或元数据过期多半是baseurl路径不匹配或者仓库端没有执行createrepo。建议先在服务器上用浏览器或curl确认目录能否访问再检查客户端配置文件最后dnf clean all强制刷新缓存很多时候问题就出在旧缓存上。6.3 版本锁定与包验证的实战技巧生产系统最怕的一件事是“重启后服务莫名不可用”而常见原因之一是某个依赖包被意外升级。dnf versionlock可以锁住指定包的版本dnf install -y python3-dnf-plugin-versionlock dnf versionlock add nginx dnf versionlock list这个插件把指定包锁定为当前版本后续执行dnf update时会自动跳过锁定项。使用时机是在重要服务部署完成后立刻锁定不是等事故发生了才想起来。rpm -V用于验证已安装包的关键文件是否被修改。比如怀疑/bin/ls被人动过手脚可以执行rpm -V coreutils输出里出现S.5....T.等标志说明文件的权限、大小、修改时间至少有一项和安装时不一样这时候就要进一步排查。这个功能在安全审计场景里特别常用却很少有人知道掌握之后能帮你在系统异常时快速定位文件级别的变化。7. 计划任务at、crontab与systemd timer的取舍7.1 at一次性任务的注意事项Linux计划任务分三类at处理一次性任务crontab处理周期性任务systemd timer作为更现代的方案逐渐流行。RH134要求至少掌握前两者但实际工作中三者都值得了解。at的用法很简单echo sh /opt/scripts/backup.sh | at 02:30 atq atrm 任务IDat运行前需要atd服务处于运行状态并且用户必须被允许使用at命令相关配置在/etc/at.allow和/etc/at.deny里。我个人的习惯是只要任务会重复执行就优先用crontab而不是每次都写at因为at任务清单不够直观时间久了容易忘记有哪些遗留任务在等你。7.2 crontab的时间格式与环境变量坑crontab -l查看任务crontab -e编辑任务这是最基础的操作。时间格式“分 时 日 月 周”五个字段分别对应其中最需要仔细的是“星期”字段取值范围是0到70和7都表示周日。我踩过最大的坑是cron任务里PATH环境变量不全的问题。crontab执行环境不像登录shell那样有完整的PATH所以/usr/bin/python3可能直接找不到python3。解决方式有两种要么在crontab文件顶部设置PATH/usr/local/bin:/usr/bin:/bin要么在脚本内部使用绝对路径执行所有外部命令。第二种方式我自己更推荐因为它不依赖cron服务端的配置脚本拿到哪里都能跑。%符号是另一个大坑。crontab中%有特殊含义会被当作换行如果命令里需要用到date %Y%m%d这种带百分号的内容必须转义为\%。不转义的结果是命令被截断且日志里全是aur error非常难排查。查看cron执行情况的方法grep CRON /var/log/cron tail -f /var/log/cron journalctl | grep crond7.3 systemd timer更适合复杂任务的现代方案如果你需要更精确的控制或者任务涉及服务依赖关系建议使用systemd timer。它的优势是支持日志统一收集、失败重试、随机延迟避免“整点风暴”还能准确查看上次执行时间和下次执行时间。一个最小示例是两个文件/etc/systemd/system/backup.service[Service] Typeoneshot ExecStart/usr/local/bin/backup.sh/etc/systemd/system/backup.timer[Unit] DescriptionRun backup daily [Timer] OnCalendar*-*-* 02:00:00 Persistenttrue [Install] WantedBytimers.target启动方式跟普通服务一样systemctl enable --now backup.timer systemctl list-timers journalctl -u backup.servicePersistenttrue表示如果错过了预定执行时间比如机器当时关机下次开机后会立刻补跑这一点是cron做不到的。我建议任务简单就继续用crontab任务多、依赖强、需要可靠记录时迁移到systemd timer。8. 一些实在话从头到尾把RH134的这些知识点再过一遍其实看不出哪个是“难点中的难点”但确实能感受到知识点之间的联系非常紧密。用户管理一定关联到文件和目录权限权限又联系到进程运行身份进程再关联到systemd服务服务又绕不开网络与防火墙。考试时间紧张时很多人的问题不是“不会”而是“知识是散的”遇到题目要从零开始拼接上下文自然慢。我个人的体会是学到这里必须用手里的机器把每个环节串起来跑一遍而不是一个个孤立的命令去背。准备一台干净的虚拟机从建立用户、分配组、设置ACL、写unit文件、配防火墙、设计划任务到模拟一次内存告警或磁盘告警并修复整套流程演练下来比刷两遍考纲更有用。最后分享一个小技巧如果你在实验环境里搞坏了某个服务别急着重装系统先systemctl status和journalctl -u把日志看明白再尝试恢复。这个过程比单纯“能跑起来”更能锻炼排查能力。等到你遇到故障的第一反应不是“重启试试”而是“先查日志再动手”RH134的实操目标也就基本达成了。