都说RH124是入门RH134才是真正开始像“系统管理员”的地方。这门的核心不再是怎么装个系统敲敲命令而是你怎么在一个已经跑起来的Linux环境里从容地处理用户、权限、网络、存储、服务这些每天都在打交道的事。我会把这段时间梳理出来的知识点分开讲透每块都尽量按“它是干嘛的、怎么用、坑在哪”的顺序来写完全是我自己的上手笔记适合刚考完RH124、准备往RH134走的兄弟也适合那些已经在做运维但有些细节没抠明白的同事。1. 内容整体设计与思路拆解RH134这门课官方叫Red Hat System Administration II它的定位就是从“我能把Linux跑起来”到“我能让Linux按我的想法稳定跑起来”的过渡。所以它涉及的知识点没有一个花哨的全是生产环境里高频发生的事加用户、调权限、管服务、改网络、扩磁盘、监控进程、翻日志。我刚开始学的时候最大的感受是这些东西分开看都不难但放在一起就很容易乱。比如你新建了一个用户设置了密码策略又给他配了sudo权限结果第二天他登不上了你能判断是密码过期了、账户锁定了、还是sudo配错了RH134要训练的就是这种“串起来”的思维。它不像RH124那样一个命令一个命令地教而是按“任务场景”来组织要求你知道在什么情况下该翻哪组配置、跑哪些命令去验证。另一个设计上的重点是它非常强调“标准操作流程”。比如给用户配sudo不是说你直接把/etc/sudoers改了就完事而是要走visudo、语法检查、然后另开一个终端验证的完整闭环。这也是考试里容易被扣分、实际工作中容易出事故的点。整理这篇合集的时候我刻意把每个知识点都往“可复查、可回滚、可验证”这三个方向靠这也是我给自己定的标准。只有这样知识才能从“会敲命令”变成“能担事”。2. 用户与权限管理核心细节2.1 不要只盯着useradd账户管理是一套组合拳很多兄弟在新建用户的时候习惯一条useradd username就结束了。这当然没问题但如果你是在一个按照合规要求管理服务器环境里干活这远远不够。RH134考的就是你能不能考虑完整。我个人的习惯是新建一个用户之前先想三件事这个用户要不要能登录shell他的家目录要不要区别于默认路径他要不要加入特定的附加组对应到命令上最常用的组合是useradd -u 2018 -G wheel,develop -d /home/zhangsan -s /bin/bash zhangsan这里的-u指定UID通常用于保证在某些迁移场景下文件属主不变-G附加组是重点因为-g是指定主组而实际权限控制里附加组用得更多-d和-s分别解决“家目录位置”和“登录shell”这两个需求。如果你不指定这些系统虽然会给你默认值但默认值不一定符合你的管理规范。再往后就是密码策略。这个知识点是RH134的必考项也是生产环境里最容易出问题的。密码策略的核心文件有两个/etc/login.defs负责密码有效期、最短长度这类全局默认值/etc/pam.d/system-auth里的pam_pwquality模块负责密码复杂度。很多时候你会发现明明改了/etc/login.defs里PASS_MAX_DAYS用户的密码策略却不生效原因就是PAM的配置优先级更高或者用户是在策略修改之前就创建了旧账不翻。这时候就要用chage命令去手动对齐。chage -M 90 -m 7 -W 14 zhangsan-M是密码最长使用天数-m是最短天数-W是过期前多少天开始警告。我建议做完这个操作后一定要用chage -l zhangsan再看一眼确认所有字段都符合预期。之前我就在这上面踩过坑以为改了login.defs就完事了结果审计的时候发现个别老用户还是永不过期。2.2 sudo权限配置的正确姿势sudo是RH134里权重非常大的考点基本上可以说不会sudo就等于不会做Linux管理。它的重点不是让你写username ALL(ALL) ALL这种一句话配置而是让你理解/etc/sudoers的语法结构以及为什么官方强烈建议用visudo去改。/etc/sudoers这个文件语法很简洁但也很严格一个符号写错都可能导致整个sudo不可用。比如你想给一个组配置免密sudo%wheel ALL(ALL) NOPASSWD: ALL这行的意思是wheel组的成员可以在任何主机上以任何用户身份执行任何命令而且不用输密码。注意开头的%号表示组没%的就是用户ALL(ALL)里的第二个ALL代表你可以切换成哪个用户身份最后的NOPASSWD: ALL是命令权限的范围和是否免密切换的选项。配置完以后最关键的确认命令是visudo -c它会做语法检查如果输出/etc/sudoers: parsed OK才能放心退出。我一直坚持一个习惯任何时候改完sudoers都不要关闭当前已连接的终端。先另开一个窗口用sudo执行一条简单命令试试确认没问题了再关。因为如果语法检查通过了但逻辑有误这可能是你唯一一次发现问题的机会。还有个经常被忽略的点就是在sudoers里允许用户执行特定命令时最好写绝对路径。比如你想让某个用户能重启web服务应该写/usr/bin/systemctl restart nginx而不是写systemctl restart nginx。因为sudo在匹配命令的时候是按路径来的你写个不带路径的命令可能会被PATH环境变量影响导致匹配不到。细节决定成败真到了排查问题的时候这些都是救命的知识。2.3 文件权限里那些面试爱问的隐藏细节说到权限chmod、chown这些基础命令大家都会RH134更喜欢考的是你对特殊权限位和ACL的理解。特殊权限位就是setuid、setgid和sticky bit它们的数值分别对应4、2、1。setuid比较典型/usr/bin/passwd这个文件就带setuid位所以普通用户才能用它去修改/etc/shadow。设置方式很简单chmod us /path/to/file chmod 4755 /path/to/file两种写法等价但你要注意如果一个文件属主和属组都是root你给属主设了setuid那是给root设置没啥意义设到属组上也是一样的道理。只有把可执行文件的setuid位设置在普通用户能执行的场景才有实际效果。ACL则是文件权限的“扩展包”用setfacl命令操作。比如你现在需要给一个特定用户读某个文件的权限但你又不想把他加进文件属组里因为那样会连带影响组里其他成员。这时候ACL就是正解。setfacl -m u:zhangsan:r-- /data/readme.txt getfacl /data/readme.txt这里有个很重要的点文件一旦设置了ACLls -l看到的权限位末尾会多出一个号而且原来属组的权限位会变成mask的值。很多人看到-rw-r-----这种输出就懵了以为是权限错乱了其实只是ACL的mask在起作用。排查的时候别光看数字一定要跑一遍getfacl看完整信息。3. systemd服务管理与开机自启3.1 用systemctl管理服务生命周期RH134的网络服务管理部分已经完全围绕systemd展开service命令基本可以退休了。systemctl这套命令本身不难但难点在于你要理解服务单元unit文件和系统不同层级之间的关系。服务管理的常规操作我就不再啰嗦了直接给一套我工作中每天都在用的命令清单systemctl start nginx # 启动服务即时生效但不写入开机 systemctl enable nginx # 设置开机自启 systemctl enable --now nginx # 启用并立即启动推荐组合 systemctl daemon-reload # 改了unit文件之后必须执行 systemctl status nginx # 查看服务状态排障入口我要强调的是daemon-reload。每次你编辑过/etc/systemd/system/下的unit文件都必须让systemd重新加载配置否则你执行systemctl restart的时候用的还是旧配置。这个坑我踩过不止一次有时候改完配置发现重启不生效第一反应是配置写错了回头检查半天结果只是忘了reload。3.2 手写systemd服务单元文件RH134有一种很典型的考题或者说是实际工作中的常驻需求给一个自己写的小脚本配一个systemd服务让它能开机自启、崩溃自动拉起、日志正确输出。一个最小可用的unit文件长这样放在/etc/systemd/system/myapp.service[Unit] DescriptionMy Custom Application Service Afternetwork.target [Service] Typesimple Userappuser ExecStart/usr/local/bin/myapp.sh Restarton-failure RestartSec5 WorkingDirectory/opt/myapp [Install] WantedBymulti-user.target逐行拆一下关键点。Typesimple表示ExecStart启动的那个进程就是主进程如果你脚本里用把进程丢到后台然后主脚本自己退出了那systemd会认为服务已经结束Restart机制可能不会正常工作。Userappuser是安全降权绝不要让服务用root跑除非你的服务真的需要特权。Restarton-failure是我最推荐的生产配置进程异常退出时自动拉起等5秒再拉避免瞬间重启风暴。写完unit文件之后必须按这个顺序来systemctl daemon-reload然后systemctl enable --now myapp最后用systemctl status myapp看状态。如果服务起不来排查首选是journalctl -u myapp -f它会实时打印这个服务单元的所有日志。3.3 日志也在systemd的管辖范围内以前排查服务问题大概率要去翻/var/log/messages现在新一点系统上主战场已经变成了journald。journalctl是RH134的必考命令之一其实也是工作中最高频用的排障工具。几个最常用组合journalctl -u nginx # 查看指定服务的日志 journalctl -u nginx -f # 持续跟踪日志输出 journalctl -u nginx --since today # 只看今天 journalctl -u nginx --since 2024-10-01 08:00:00 --until 2024-10-01 12:00:00 # 指定时间区间 journalctl -p err -b # 查看本次开机以来的错误级别日志关于日志持久化有一个细节值得提。默认情况下journald的日志是存在内存或临时目录里的服务器重启后历史日志可能会丢。要让它持久化需要确保/var/log/journal目录存在然后执行systemctl restart systemd-journald。其实很多发行版会通过/etc/systemd/journald.conf里的Storageauto来实现有目录就用持久化模式但如果你发现日志只存在于重启前那大概率就是没建这个目录。4. 网络配置与链路管理4.1 用nmcli接管你的网络管理RH134里的网络配置已经是NetworkManager一家独大的局面。很多从老版本Linux过来的兄弟习惯直接改/etc/sysconfig/network-scripts/ifcfg-*但在这个阶段我更推荐把nmcli当作统一入口。原因是nmcli不仅命令简洁而且它把“配置”“激活”“查看状态”这几个操作都统一在一个工具里减少出错概率。创建一个新连接并设置静态IP的标准操作nmcli connection add type ethernet con-name office ifname ens33 ipv4.addresses 192.168.1.100/24 ipv4.gateway 192.168.1.1 ipv4.dns 8.8.8.8 ipv4.method manual nmcli connection up office这里con-name是这个连接配置的名字ifname是实际的网卡名。需要注意的是ipv4.method manual表示使用静态配置如果你不写这一行而写auto那它还是会去DHCP获取地址。改动了连接之后nmcli connection reload可以让配置生效但我更建议直接nmcli connection down然后up一次这个操作能根治很多“配置看着改了网络没变”的问题。还有一个常见题型是给网卡配置多个IP。在nmcli里是这么玩的nmcli connection modify office ipv4.addresses 10.10.10.100/24注意命令里这个ipv4.addresses第一次加地址用ipv4.addresses不带会覆盖原有值追加地址用ipv4.addresses这个区别很容易被忽略导致你一个IP地址被另一个覆盖了。4.2 深入理解路由与网关选择网络这块静态IP只是基础真正让很多初学者蒙圈的是路由表。RH134考试大概率会考你查路由和加静态路由。查路由最常用的是路由命令ip route show输出里那种default via 192.168.1.1 dev ens33就是默认路由也就是所谓的网关。如果你想让某个子网走特定出口就需要配静态路由。比如你有一个内部网段10.0.0.0/8需要走另一条链路ip route add 10.0.0.0/8 via 172.16.10.254 dev ens34但这么做有个问题ip route add只是临时策略重启就没了。要持久化在基于NetworkManager的系统上最好使用cooked sc把路由信息写进连接配置里。nmcli connection modify office ipv4.routes 10.0.0.0/8 172.16.10.254这里后面的地址就是下一跳指定了走哪台网关。改完之后同样操作是down/up连接。你别小看这个静态路由配置很多复杂的网络排障场景最后就卡在一条路由上日志里什么都正常ping就是不通一查路由表才发现流量走错方向了。4.3 防火墙firewalld的规则管理RH134的网络部分还会考到firewalld。它的核心不是“iptables那样的五链四表”而是“区域zone和服务service”的抽象配置方式更符合人类直觉。最常用的几个命令firewall-cmd --list-all # 查看当前区域完整规则 firewall-cmd --add-servicehttp --permanent # 放行http服务永久生效 firewall-cmd --add-port8080/tcp --permanent # 放行8080端口 firewall-cmd --reload # 重载配置这里有个关键概念必须记住--permanent决定了规则是临时还是永久的。如果你不加这个参数规则只对当前运行环境生效重启后消失适合测试加了--permanent只写入配置文件不立即生效所以要再--reload一次。很多兄弟配了规则死活不生效十有八九就是没加--permanent或者加了之后没reload。生产环境我还用到一个技巧把规则按服务分组。比如公司的web服务器通常需要开放http、https、还有某个管理端口。我会先按需要添加服务然后单独加那个管理端口这样审计的时候规则清清楚楚不像一串裸端口那么难查。5. 存储管理与LVM实战5.1 磁盘分区与文件系统创建RH134的存储相关考点挺实在的它要求你熟练使用parted或fdisk做分区、用mkfs创建文件系统、用mount挂载同时理解UUID的作用。创建分区最稳的方法是先确认裸盘lsblk fdisk -l /dev/sdb然后进入fdisk交互界面做分区。这个过程经常让人觉得有点迷糊特别是fdisk的交互字符不直观n是新建、w是保存退出、d是删除。我总结了一套自己的操作顺序先p打印当前分区表再n新建分区选主分区接受默认的起始扇区然后指定分区大小或者接受默认占满全盘最后w写入。不过要注意新版fdisk默认创建的是DOS分区表如果你需要GPT要用g在进入fdisk时先切换。文件系统创建这一步相对固定ext4是经典之选xfs是红帽系系统默认推荐两者各有优劣但在这个阶段你至少要知道mkfs.xfs和mkfs.ext4的区别。xfs在删除大量小文件时性能相对弱但大文件连续读写表现好而且可以动态扩展ext4兼容性更广。挂载的时候绝对是优先用UUID而不是设备名因为设备名可能会漂移。/etc/fstab里挂载格式如下UUID5f2f31d4-7c6a-4b4b-9e2e-4d0df4a21c2d /data xfs defaults 0 2字段依次是设备标识、挂载点、文件系统类型、挂载选项、是否dump、是否fsck检查。我在生产环境看到好多人/etc/fstab写的是/dev/sdb1平时没问题但只要重启后盘符顺序变了系统就会挂不上直接进紧急模式。这个坑一定要记住。5.2 LVM的逻辑池化 动态伸缩LVM是RH134存储部分的重头戏现实中几乎每台服务器的数据盘都会用到LVM因为它解决了物理分区大小固定、不好扩展的问题。LVM的层次关系是PV物理卷→ VG卷组→ LV逻辑卷。你可以这么理解PV是你要拿来做LVM的物理硬盘或分区VG是你把这些硬盘组合起来形成的一个总资源池LV是你从这个池子里划出来给文件系统用的一块空间。创建全套的流程pvcreate /dev/sdb1 /dev/sdc1 # 创建PV vgcreate myvg /dev/sdb1 /dev/sdc1 # 创建VG lvcreate -n data -L 100G myvg # 从VG里创建100G的LV mkfs.xfs /dev/myvg/data # 格式化LV扩展LV是LVM最爽的功能也是考题重点。流程是先扩LV再扩文件系统。顺序绝对不能反。lvextend -L 50G /dev/myvg/data xfs_growfs /data # xfs文件系统重新感知空间注意xfs只能扩不能缩ext4可以缩。如果你用ext4扩展后要用resize2fs /dev/myvg/data而不是xfs_growfs。这里如果不匹配文件系统类型轻则命令报错重则文件系统损坏。5.3 交换分区Swap的配置要点内存不够的时候Swap就是最后一道保险。RH134也会考到Swap的配置而且现在更推荐用Swap文件而不是独立的Swap分区灵活性和可管理性都好很多。创建一个2G的swap文件dd if/dev/zero of/swapfile bs1M count2048 chmod 600 /swapfile mkswap /swapfile swapon /swapfilechmod 600这一步是安全要求如果权限过宽swapon会拒绝启用提示insecure permissions。要持久化的话写一行到/etc/fstab/swapfile none swap defaults 0 0还有个系统调优参数值得说/proc/sys/vm/swappiness它控制系统使用交换空间的频率倾向默认值是通常为30。数值越大越积极使用swap越小越倾向于保留物理内存。如果服务器内存充足可以适当调小比如改成10能减少不必要的swap读写提升响应速度。6. 进程管理与系统监控6.1 用ps和top快速定位资源占用进程RH134覆盖了很多性能排查的手段进程管理这个模块讲的就是如何快速回答两个问题系统现在卡在哪哪个进程出了问题ps是静态快照top是动态排行。我最常用的几个组合参数ps -ef | grep java ps aux --sort-%mem | head -10 # 按内存占用排序 ps -eo pid,ppid,user,%cpu,%mem,cmd --sort-%cpu | head -20第三个命令在排障时特别好用它能直接列出CPU占用最高的前20个进程包括PID、父进程、属主和完整命令行。top进入交互式之后按P是按CPU排序按M是按内存排序按k可以杀掉一个进程。6.2 理解进程优先级与nice值关于进程优先级的调整一句话能讲清楚但实际场景很多值得展开。系统调度进程时nice值决定了它能获得多少CPU时间范围是-20到19数值越小优先级越高普通用户只能调高自己的nice值只有root才能调低到负值。启动时设置优先级nice -n -10 /usr/local/bin/important_task.sh对已经运行的进程调整renice -n -10 -p 12345我在线上处理过一个场景备份脚本跑起来之后直接把CPU吃满导致线上业务响应变慢。当时就是先用top找到PID然后renice -n 10 -p PID把它降级让业务进程优先。这个方法比直接kill掉备份再重启要温和得多。6.3 系统负载与性能判断标准关于负载这个概念真的值得单独说。很多人看到uptime里的load average就紧张比如看到输出load average: 8.23, 6.50, 4.20就以为是系统要垮了。其实这三个数分别代表1分钟、5分钟、15分钟的平均负载你还要结合CPU核数来看。简单粗暴的判断标准是如果负载值长期高于CPU核心数的4倍以上系统大概率已经处于超负荷状态。但是判断到底卡不卡得看负载是由CPU、内存还是IO引起的。如果你是IO密集型任务CPU使用率不高但负载很高这种时候盲目的加CPU解决不了问题反而要从存储性能和并发数入手。我常用的监控命令组合是用top看整体用vmstat 1看上下文切换和IO等待用iostat看磁盘利用率。如果iostat里%util长期超过80%基本可以断定磁盘是瓶颈。做性能排查一定要先定位瓶颈类型再动手优化不然后面很容易瞎忙一场。7. 故障排查与常见问题速查7.1 登录故障区分认证失败与策略阻断我见过最多的问题就是用户登录不上而原因五花八门排错如果没头绪会很浪费时间。我的排查顺序是固定的。第一步排除账户本身问题id zhangsan passwd -S zhangsan # 查看账户密码状态 chage -l zhangsan # 查看密码策略明细passwd -S里的输出如果显示LK代表锁定NP代表无密码PS代表有可用密码。chage -l能看出密码过期时间如果发现Password expires: never同时你设置了全局密码策略那多半是这个用户没对齐策略。第二步看PAM的认证日志。大多数发行版里SSH失败的记录都能在journalctl -u sshd里找到或者/var/log/secure。如果是sudo执行失败查/var/log/secure里的sudo日志能看到是密码错误还是不在sudoers里。7.2 服务启动失败排查三板斧服务起不来很多人第一反应是看配置、猜原因但我建议按套路来systemctl status failed-service # 第一步看状态里会有错误提示 journalctl -u failed-service -b # 第二步看本次启动的日志 systemctl cat failed-service # 第三步确认unit配置内容如果日志提示端口被占用你是哪个端口被谁占了ss -tlnp | grep 8080如果提示配置文件语法错误那就用对应服务的配置检查命令验证一下比如nginx就是nginx -tapache是apachectl configtest。我踩过最坑的一次是某个服务启动失败日志里什么都没输出后来一步步排查才发现是unit文件里的User指定的用户家目录被锁了进程连工作目录都进不去。所以查看完整日志永远比猜配置要快。7.3 分区空间满但不明显占用磁盘满是个老生常谈的问题但有时候明明df -h显示/dev/mapper/rootvg-root 100%你再du -sh /*一看却找不到哪个目录特别大。这个现象通常是被已删除但还被进程占用的文件也就是俗称的“僵尸文件”撑满了磁盘。这种情况下文件虽然被删除但文件句柄还开着所以空间没法释放而普通du统计又看不到这些文件。排查命令是lsof | grep deleted看到带deleted标志的进程后稳妥的做法是对应的服务进程平滑重启或重启服务让文件句柄释放。不要直接kill进程除非你这个服务能接受短时中断。7.4 常见问题速查表现象可能原因建议排查命令/操作用户无法ssh登录密码过期/账户锁定/shell无效passwd -S、chage -lsudo执行报错不在sudoers或语法写错visudo -c、另开终端测试nmcli改了不生效未reload或连接未重启nmcli connection reloadsystemd服务起不来unit配置错误/依赖缺失daemon-reload、journalctl -u查看磁盘空间满但du看不出来有deleted文件占用lsof这张表是我自己整理的不敢说覆盖所有情况但基本能帮你把高频故障压缩到最小范围。真要排解特殊问题还是要遵循“看日志 → 定位 → 验证 → 复盘”的闭环别靠猜。最后再分享一点个人心得RH134这个阶段考的不只是记忆力更是你在一个信息不全、环境复杂的情况下能不能按照一套合理逻辑把问题拆解掉。扎实的文档功底是基础但关键时刻更依赖的是平时积累的排查习惯——多动手、多记录、多复盘才真正能把Linux管理从“会”变成“熟”。