23 道故障排查：启动、存储与权限练习题及答案

1. 1. 一台 dpkg 系发行版服务器的 Web 服务从今天清早开始就一直失败。`journalctl -u nginx -xe` 满屏都是同一行重复内容：`nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)`。管理员需要的是引发这串故障的最早那条记录，而不是最新的一条。哪种做法能找到它？

   • A.运行 `journalctl -u nginx -p err --since 05:00`，先看该窗口内最早的记录。✓ 答案
   • B.运行 `journalctl -xe` 并滚动到最底部，因为在这类重复报错中最后一行才指出最初故障。
   • C.运行 `journalctl --vacuum-size=100M` 先清理日志，让该单元较早的记录压缩到一页之内。
   • D.运行 `systemctl restart nginx`，只阅读重启之后出现的那些记录，因为之前的记录都已过期。

   日志按时间顺序写入，因此某个时间窗内的第一条错误通常才是原因，之后的记录多为后果。`-u` 把输出限定到该单元，`-p err` 过滤掉信息级噪声，`--since` 限定时间窗；而 `-xe` 会有意跳到最新一条，那只是同一症状的最后一次重复。

   编号 QB-SYDJHM依据： journalctl(1) manual page: --unit, --priority and --since/--until filtering报告此题的问题

2. 2. 有人报告某个 systemd 单元已停止。`systemctl status billing.service` 显示： ``` Active: failed (Result: exit-code) since Tue 03:14:07 UTC; 21min ago Main PID: 1841 (code=exited, status=1/FAILURE) Tue 01:02:55 host systemd[1]: Started Billing API. Tue 03:14:07 host systemd[1]: billing.service: Main process exited, code=exited, status=1/FAILURE ``` 这些证据能确定什么？

   • A.该单元根本没有执行过 ExecStart，说明单元文件里写的程序路径有误，必须先改正它。
   • B.该单元正常启动并运行了约两小时，之后其进程以失败状态退出；应去看应用自身的日志。✓ 答案
   • C.该单元没有设为开机自启，因此机器切换到默认 target 时 systemd 把它停掉了。
   • D.该单元被一个始终未就绪的 Requires= 依赖挡住了，必须先把那个依赖单元启动起来。

   时间戳把两种情况区分开了：systemd 在 01:02 记录了 `Started`，主进程直到 03:14 才退出，说明启动是成功的，程序是运行一段时间后自行退出的。启动失败的单元根本不会出现 `Started`，其状态会指出失败的阶段而不是某个已退出的主 PID，所以应当去查应用自身的运行日志。

   编号 QB-9G8DXK依据： systemctl(1) and systemd.service(5) manual pages: Active state, Result and main process exit reporting报告此题的问题

3. 3. 一台 RPM 系发行版服务器的 /var 已满。`df -h /var` 显示可用空间为 0，`df -i /var` 显示 inode 只用了 6%，`du -sh /var/log/*` 显示有一个 38G 的文件 /var/log/app/app.log，`ls /etc/logrotate.d` 中没有该应用的配置，`lsof +L1 /var` 也没有任何输出。证据指向什么？

   • A.该应用的日志从未被任何轮转规则覆盖，因此无限增长；应当为它添加 logrotate 配置。✓ 答案
   • B./var 上的 inode 已经耗尽，所以块空间尚存而写入失败；该文件系统只能重建。
   • C.有个已被删除的文件仍被某个进程打开着，只要重启那个进程，空间就会立刻回收。
   • D.journal 超出了容量上限，应当用 `journalctl --vacuum-size=1G` 回收空间。

   每一个竞争性原因都被其中一项证据排除了：inode 仅用 6% 排除了 inode 耗尽，`lsof +L1` 无输出排除了“已删除但仍被打开”的文件，`du` 指向的是普通磁盘日志文件而非 journal。日志文件只有在轮转规则对它改名、压缩并按期删除时才会停止增长，所以在 /etc/logrotate.d 中没有配置的文件会一直长到把文件系统占满。

   编号 QB-RY28CK依据： logrotate(8) manual page: rotation rules in /etc/logrotate.conf and /etc/logrotate.d报告此题的问题

4. 4. 管理员在一台 systemd 主机上运行 `journalctl -b -p warning`。该命令会返回哪些记录？

   • A.仅返回严重级别恰好为 warning 的记录，err 和 crit 级别会被过滤掉。
   • B.返回 warning 级别以及所有比它更严重的级别，一直到 emerg 为止。✓ 答案
   • C.仅返回那些在单元文件中设置了 warning 阈值的单元在本次启动中的记录。
   • D.返回 warning 及以下级别，因此 notice、info 和 debug 也都包含在内。

   `-p` 设定的是一个上限而不是精确匹配：journal 沿用经典的 syslog 严重级别序列，emerg 最严重、debug 最轻，指定某一级别就会返回该级别及所有更严重的记录。`-b` 把输出限制在本次启动，管理员正是用它把本次启动的故障与上一次的区分开。

   编号 QB-8GV2SJ依据： journalctl(1) manual page: --priority and the syslog severity levels it accepts报告此题的问题

5. 5. 管理员在一台 dpkg 系发行版服务器上把 /etc/default/grub 里改成 `GRUB_CMDLINE_LINUX_DEFAULT="quiet elevator=none"` 并重启，但 `cat /proc/cmdline` 显示的仍是旧参数。为什么？

   • A.该系列的重新生成命令是 `grub2-mkconfig -o /boot/grub2/grub.cfg`，未执行。
   • B.生成出来的引导器配置文件一直没有重新生成；要靠运行 `update-grub` 把新设置写进去。✓ 答案
   • C.内核参数要等 `systemctl daemon-reload` 让 PID 1 重读引导配置之后才会生效。
   • D./etc/default/grub 只管救援条目；普通条目需手工编辑 /boot/grub/grub.cfg。

   /etc/default/grub 只是输入文件，并不是引导器实际读取的文件：生成工具会据此产出引导器自己的配置，在生成工具运行之前，引导时用的仍是旧的生成结果。在 dpkg 系发行版上，这个包装命令是 `update-grub`；生成出的文件不应手工编辑，因为下一次生成会把它覆盖掉。

   编号 QB-QYPV6J依据： GNU GRUB manual and grub-mkconfig(8); the update-grub wrapper on dpkg-based distributions报告此题的问题

6. 6. 在一台 RPM 系发行版服务器上把根文件系统迁到新的 LVM 逻辑卷之后，启动停在 `ALERT! /dev/mapper/vg0-root does not exist. Dropping to a shell!` 并出现 `(initramfs)` 提示符。用安装介质启动后检查，该逻辑卷及其文件系统都完好。最可能的原因和修法是什么？

   • A.引导菜单条目指向了错误的设备；必须手工编辑 /boot/grub2/grub.cfg 让它指向该卷。
   • B.该卷上的文件系统已损坏；应在 (initramfs) 提示符下对它运行 `xfs_repair`。
   • C.初始内存文件系统缺少激活该卷所需的组件；用 `dracut --force` 重新生成它。✓ 答案
   • D./etc/fstab 的根条目用了设备名而非 UUID；应改成 `blkid` 给出的值。

   这个提示符本身就定位了故障：内核和初始内存文件系统都已加载并运行，说明引导器没问题，但镜像里的代码无法组装出承载根的设备。激活 LVM、RAID 或加密的根设备需要镜像内含有相应模块与工具，安装后才加上这一层，就必须在下次启动前重新生成镜像。

   编号 QB-7GHQKH依据： dracut(8) manual page: regenerating the initramfs so required modules are present at boot报告此题的问题

7. 7. 有人在 /etc/fstab 中加了一条数据盘条目，后来那块盘被重新创建过。服务器现在启动进入 `Welcome to emergency mode!`，日志显示 `Timed out waiting for device /dev/disk/by-uuid/3f2a9c1e-...`、`Dependency failed for /data.` 和 `Dependency failed for Local File Systems.`。管理员应该怎么做？

   • A.用 `blkid` 读出真实标识符，改正 /etc/fstab 条目，重启前再用 `mount -a` 验证一遍。✓ 答案
   • B.用 `dracut --force` 重建初始内存文件系统，因为这次挂载失败发生在 PID 1 启动之前。
   • C.给 /data 条目加上 `noexec,nosuid`，这样失败的挂载会被跳过，启动可继续到默认 target。
   • D.在紧急模式 shell 中对该数据设备运行 `fsck`，因为进入紧急模式说明文件系统已损坏。

   重新创建磁盘会让它得到新的标识符，于是挂载表中的条目指向了已不存在的东西，本地文件系统 target 失败，PID 1 退回紧急 shell。`blkid` 会报出该设备当前真正的标识符，而 `mount -a` 会立刻处理整张挂载表，这正是在重启依赖它之前验证修改的办法。让可选设备不至于拖垮启动的选项是 `nofail`，而不是那些加固类选项。

   编号 QB-PYBJZG依据： fstab(5) and mount(8) manual pages: device identifiers, the nofail option, and mount -a报告此题的问题

8. 8. 一台 RPM 系发行版服务器更新内核后，启动以 `Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)` 结束。GRUB 菜单里仍列有上一个内核及其 initramfs。业务必须马上恢复。第一步该做什么？

   • A.在引导菜单中选择上一个内核条目先把业务恢复起来，随后再去排查新内核的 initramfs。✓ 答案
   • B.给新内核条目追加 `systemd.unit=emergency.target` 进入 shell 修复单元。
   • C.用安装介质重装操作系统，因为 PID 1 之前发生的 panic 意味着配置已无法恢复。
   • D.用安装介质进入救援模式并重置 root 密码，因为这次 panic 挡住了正常的身份验证。

   这种 panic 发生在用户空间尚不存在的阶段，因此任何 target、单元或密码提示都不可能到达，追加 systemd target 参数毫无作用。包管理器保留旧内核及与之匹配的初始内存文件系统作为菜单条目，正是为了在内核或镜像出问题时通过选择上一条目回滚，这既恢复了业务，也让出问题的那一对留在系统里供后续修复。

   编号 QB-EGZ2TS依据： GNU GRUB manual, menu entry selection; Linux kernel root filesystem mount panic messages报告此题的问题

9. 9. 一台使用 dracut、且 SELinux 处于 enforcing 模式的 RPM 系发行版服务器，root 密码已无人知晓，也没有其他账号具备 sudo 权限。管理员可以在 GRUB 菜单处操作控制台。哪一组步骤能重置它？

   • A.正常启动之后在任意用户会话中运行 `passwd root` 改密码，因为控制台被视为受信任的本地终端。
   • B.追加 `systemd.unit=rescue.target`，然后在救援 target 给出的 shell 提示符下运行 `passwd` 改密码。
   • C.追加 `selinux=0`，再把 /etc/passwd 中 root 那一行的第二个字段清空，这样登录就不需要密码了。
   • D.追加 `rd.break`，把 /sysroot 挂为读写，`chroot /sysroot`，运行 `passwd`，再 `touch /.autorelabel`。✓ 答案

   在真正的根被交接之前中断启动，可以得到一个无需凭据的 shell，而真正的根位于 /sysroot，它初始为只读，必须重新以读写挂载才能修改密码文件。在引导环境中写这个文件会让它带上错误的安全上下文，因此那个请求下次启动时重新打标签的标志文件才是保证系统之后仍可用的关键；救援 target 帮不上忙，因为它恰恰要求那个已丢失的密码。

   编号 QB-WYTV7S依据： dracut.cmdline(7) manual page (rd.break), passwd(1), and the SELinux /.autorelabel relabel flag报告此题的问题

10. 10. 某云实例上的邮件投递报 `No space left on device`： ``` $ df -h /var/spool Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg0-spool 20G 8.2G 11G 44% /var/spool $ df -i /var/spool Filesystem Inodes IUsed IFree IUse% Mounted on /dev/mapper/vg0-spool 1310720 1310720 0 100% /var/spool ``` 这些证据说明了什么？

    • A.该文件系统在发生 I/O 错误后被重新挂载为只读，内核把这种情况报成空间错误。
    • B.有个已删除的文件仍处于打开状态，`df` 与 `du` 因此不一致；重启持有者后空间回来。
    • C.该文件系统的 inode 已耗尽，所以尽管还有空闲块，也无法再创建新文件。✓ 答案
    • D.该逻辑卷已没有剩余的扩展区，因此文件系统再也无法为新的数据分配块。

    文件系统分别统计块和 inode，而每个文件、目录和符号链接无论多小都要占用一个 inode，因此装满细碎邮件的 spool 可能在容量大半闲置的情况下把 inode 用尽。`No space left on device` 这个错误同时覆盖两种短缺，这正是要用 `df -i` 去区分的原因；对于 inode 数量在创建时即已固定的文件系统，真正的解法只有删文件或重建更大的文件系统。

    编号 QB-7M8USM依据： df(1) manual page: --inodes reporting, and inode allocation fixed at filesystem creation报告此题的问题

11. 11. 一台 dpkg 系发行版服务器的 /var 已满： ``` $ df -h /var /dev/sda3 50G 47G 0 100% /var $ du -sh /var 9.8G /var $ sudo lsof +L1 /var COMMAND PID USER FD TYPE DEVICE SIZE/OFF NLINK NODE NAME rsyslogd 912 root 7w REG 8,3 39421337600 0 418 /var/log/syslog.1 (deleted) ``` 应该怎样把空间收回来？

    • A.再执行一次 `rm -f /var/log/syslog.1`，因为第一次删除后目录项其实还在。
    • B.下次重启时对 /var 运行 `fsck`，以修正 `df` 与 `du` 互相矛盾的块统计。
    • C.用 `lvextend -r` 扩大文件系统，因为 `df` 报出的占用是真实且不会消失的。
    • D.重启 rsyslogd，让那个已删除文件的描述符被释放，内核随即把这些块回收。✓ 答案

    取消链接只是删掉目录项；只要还有进程持有打开的描述符，inode 及其数据块就依然存在，这正是 `+L1` 专门用来暴露的 `NLINK 0` 记录。`df` 会把这些块算进去，因为文件系统仍占有它们，而 `du` 看不到没有名字的文件，所以只有让持有它的进程重启并释放描述符，这个差额才会消失。

    编号 QB-Q4EZCN依据： lsof(8) manual page: +L link-count selection for unlinked open files; unlink(2) semantics报告此题的问题

12. 12. 一台 RPM 系发行版服务器上，/data 的用户报告 `Read-only file system`，尽管文件属于他们本人且权限为 0775。`dmesg` 末尾是： ``` blk_update_request: critical medium error, dev sdb, sector 41945280 EXT4-fs error (device sdb1): ext4_journal_check_start:83: Detected aborted journal EXT4-fs (sdb1): Remounting filesystem read-only ``` 原因是什么？

    • A.该目录丢失了执行位，而内核会把这种情况向写入方报告成只读文件系统。
    • B.内核遇到介质错误并中止了文件系统日志，于是把该文件系统重新挂载为只读。✓ 答案
    • C.这条挂载在 /etc/fstab 中带了 `ro` 选项，重新挂载为读写即可恢复写入。
    • D.有 SELinux 拒绝阻止了写入，运行 `restorecon` 就能恢复正确的上下文。

    只读文件系统这个错误根本不是权限判定：块层返回介质错误、日志已不可信之后，内核把整个文件系统撤出了写服务，这正是“出错即重新挂载为只读”这一错误策略所要求的保护行为。权限位、挂载选项和强制访问控制给出的都会是 `Permission denied`，而这里的处理要从故障设备入手，而不是从文件系统入手。

    编号 QB-6MVGMK依据： mount(8) manual page (ext4 errors=remount-ro) and the ext4 administration documentation in the Linux kernel tree报告此题的问题

13. 13. 一台 dpkg 系发行版服务器上的存储告警指向 md0： ``` $ cat /proc/mdstat Personalities : [raid1] md0 : active raid1 sdc1[2](F) sdb1[0] 2930134016 blocks super 1.2 [2/1] [U_] ``` 这说明了什么，下一步该做什么？

    • A.两个成员都已离线、数据已无法访问，因此在任何写入之前都要先从备份恢复该卷。
    • B.该阵列正在重启之后重新同步；应等重建完成，在此期间不要触碰任何一个成员设备。
    • C.元数据版本与当前内核不匹配，因此必须先停止该阵列，然后再手工重新组装它。
    • D.有一个成员被标记为故障，镜像降级运行；用 `mdadm --detail` 确认后加入替换设备。✓ 答案

    该行中的三处细节彼此印证：`(F)` 标出被内核判为故障的成员，`[2/1]` 表示两个预期成员中只剩一个在线，`[U_]` 画出一个正常、一个缺失。因此阵列仍在提供数据，但已毫无冗余，正确做法是准确认定故障成员并加入健康设备让镜像重建；若真在重新同步，输出里会另有一行带百分比的恢复进度。

    编号 QB-P43P7M依据： mdadm(8) manual page and the md driver documentation in the Linux kernel tree: /proc/mdstat status fields报告此题的问题

14. 14. 在一台 RPM 系发行版服务器上： ``` $ sudo lvextend -L +5G /dev/vg0/data Insufficient free space: 1280 extents needed, but only 0 available $ sudo vgs VG #PV #LV #SN Attr VSize VFree vg0 1 3 0 wz--n- 99.00g 0 ``` 首先必须做什么？

    • A.运行 `lvextend -r`，让文件系统随卷一起调整大小，从而腾出所需的扩展区。
    • B.先运行 `xfs_growfs /data`，因为文件系统必须先占下空间，卷才能随之增长。
    • C.对现有成员运行 `pvresize`，它会从卷组元数据中预留出更多的扩展区。
    • D.先给卷组增加容量：对新设备执行 `pvcreate`，再 `vgextend vg0`，最后才扩展该卷。✓ 答案

    逻辑卷只能从所属卷组已有的空闲扩展区中扩展，而 `VFree` 为 0 说明卷组无可分配的扩展区，因此扩展命令上加什么参数都变不出容量。增加容量的顺序是自下而上的：先初始化新的物理卷，把它加入卷组，然后再扩展逻辑卷并增长其上的文件系统。

    编号 QB-9MXG5Q依据： lvextend(8), vgextend(8) and pvcreate(8) manual pages: extent allocation within a volume group报告此题的问题

15. 15. 一台 RPM 系发行版服务器记录到 /data 上的 XFS 元数据损坏，该 XFS 文件系统位于 /dev/vg0/data。管理员卸载 /data 后运行 `xfs_growfs /data`，得到 `xfs_growfs: /data is not a mounted XFS filesystem`。正确的处理方式是什么？

    • A.先把 /data 挂载上再对挂载点运行 `xfs_repair`，因为该工具需要活动元数据。
    • B.运行 `fsck.xfs /dev/vg0/data`，它会做 `xfs_repair` 故意跳过的那种完整元数据检查。
    • C.在保持卸载状态下用 `xfs_repair /dev/vg0/data` 修复；只有增长操作才要求它处于挂载状态。✓ 答案
    • D.用 `xfs_growfs -D` 收缩文件系统以丢弃受损区域，挂载之后再把它重新增长回去。

    这两个操作的前提恰好相反，误解正来源于此：修复要重写元数据，必须独占该文件系统，因此要在未挂载的状态下针对设备运行；而增长是在线操作，针对活动文件系统的挂载点执行。此外 XFS 只能单向增长、完全无法收缩，而 `fsck.xfs` 这个辅助程序只是为了应付开机检查，本身什么也不做。

    编号 QB-S45PQQ依据： xfs_repair(8), xfs_growfs(8) and fsck.xfs(8) manual pages: mount-state requirements报告此题的问题

16. 16. 在一台 dpkg 系发行版服务器上，一块新卷被分区为 /dev/sdc1。`mount /dev/sdc1 /srv/data` 返回 `mount: /srv/data: wrong fs type, bad option, bad superblock on /dev/sdc1, missing codepage or helper program, or other error`，而 `blkid /dev/sdc1` 完全没有任何输出。最可能的原因是什么？

    • A.该分区表是 MBR 而卷容量超出 MBR 可寻址范围，因此必须把它转换为 GPT。
    • B.挂载点 /srv/data 并不存在，而 mount 会把目录缺失报告成超级块损坏。
    • C.该分区上还没有创建任何文件系统，所以 mount 找不到超级块，也读不到类型。✓ 答案
    • D.该文件系统的内核模块没有加载，必须先用 `modprobe` 载入才能挂载成功。

    决定性的证据是 `blkid` 毫无输出：该工具读取的是文件系统写入其超级块的签名，没有输出就意味着没有签名，也就意味着该分区上根本没有文件系统。分区只是划出空间，必须先用相应的 `mkfs` 命令在分区上创建文件系统，挂载才可能成功；而挂载点缺失会给出另一条点名该目录的提示。

    编号 QB-8MK6YN依据： mount(8), mkfs(8) and blkid(8) manual pages: superblock detection and filesystem signatures报告此题的问题

17. 17. analysts 组的一位成员报告了一个故障： ``` $ ls -l /data/reports/q3.csv -rw-r--r--. 1 root analysts 18422 Sep 2 09:11 /data/reports/q3.csv $ ls -ld /data/reports drw-r-----. 2 root analysts 4096 Sep 2 09:10 /data/reports $ cat /data/reports/q3.csv cat: /data/reports/q3.csv: Permission denied ``` 原因是什么？

    • A.该组对这个目录并没有执行权限，因此无法穿越路径去访问到里面的那个文件。✓ 答案
    • B.该文件的 SELinux 上下文阻止读取，对它运行 `restorecon -v` 即可修复。
    • C.该文件对其他人可读但对组不可读，因此组权限位拒绝了 analysts 的成员。
    • D.该目录设置了不可变属性，`lsattr` 能看到它，用 `chattr -i` 可以清除。

    对目录而言，执行位表示穿越该目录并解析其中名字的权限，它与读权限是分开的，读权限只允许列出名字。这里目录的组字段是 `r--`，所以 analysts 的成员可以列出目录，却无法穿越它，文件本身再宽松的权限也用不上；而且路径上的每一级目录都要通过这项穿越检查。

    编号 QB-R4SBJP依据： chmod(1) manual page and POSIX file permission semantics: directory search (execute) permission报告此题的问题

18. 18. 一台 RPM 系发行版 Web 服务器上 SELinux 处于 enforcing，/srv/www/upload 权限为 0777、属主为 apache:apache，但上传仍报 `Permission denied`。/var/log/audit/audit.log 中有 `avc: denied { write } for pid=2210 comm="httpd" name="upload" scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:default_t:s0 tclass=dir`。正确的修法是什么？

    • A.对该目录运行 `chcon -t httpd_sys_rw_content_t`，这是唯一能在下次策略重新打标签后保留的改动。
    • B.运行 `setenforce 0` 让拒绝停止，并把该设置写进 /etc/selinux/config 以便重启后仍然有效。
    • C.先用 `semanage fcontext -a -t` 登记该路径应有的上下文，再用 `restorecon -Rv` 把它应用上去。✓ 答案
    • D.递归放宽该目录的权限位，并把 apache 账号加入 wheel 组，这样这次写入就会被允许。

    权限很宽、属主也对却依然被拒，这正是强制访问控制的特征，而审计记录明确指出被拒的是哪一对组合：处于 Web 服务器域中的进程去写一个仍带默认类型的目录。持久的修法是在本地策略中为该路径登记应有的类型，然后重新打标签，因为单纯的手工打标签会在下一次文件系统重新打标签时被丢弃，而关闭强制模式是撤掉保护，并没有修好标签。

    编号 QB-BMN6GS依据： semanage-fcontext(8) and restorecon(8) manual pages; SELinux audit AVC denial records报告此题的问题

19. 19. 在一台 RPM 系发行版服务器上以 root 身份操作： ``` # echo "nameserver 10.0.0.53" >> /etc/resolv.conf -bash: /etc/resolv.conf: Operation not permitted # lsattr /etc/resolv.conf ----i---------e------- /etc/resolv.conf ``` 这该如何解释，又该怎样解除？

    • A.该文件属于另一个用户，写入之前必须先用 `chown root:root` 更正属主。
    • B.该文件设置了不可变属性，它连 root 也会阻止，直到用 `chattr -i` 把它去掉为止。✓ 答案
    • C.存在 SELinux 拒绝，对该文件运行 `restorecon -v` 可使其回到策略期望的上下文。
    • D.根文件系统被挂载为只读，用 `mount -o remount,rw /` 可恢复对该文件的写权限。

    有两条线索彻底排除了权限模型：报错是 `Operation not permitted` 而不是 `Permission denied`，而且 `lsattr` 的属性串中出现了 `i` 标志。带不可变属性的文件不能被任何用户（包括 root）修改、改名、删除或新增链接，只有具备更改文件属性能力的进程才能清除该标志，这正是先执行 `chattr -i` 再重试编辑的原因。

    编号 QB-U4UB3T依据： chattr(1) and lsattr(1) manual pages: the immutable attribute报告此题的问题

20. 20. deploy 账号无法写入某个文件，其 ACL 如下： ``` $ getfacl /srv/app/config.yml # owner: root # group: root user::rw- user:deploy:rw- #effective:r-- group::r-- mask::r-- other::r-- ``` 这该如何解释，又该怎样修复？

    • A.那条具名条目其实从未真正生效，必须对该文件重新运行一次 `setfacl -m u:deploy:rw`。
    • B.父目录缺少默认 ACL，必须在那个目录上设置 `setfacl -d -m u:deploy:rw` 才行。
    • C.`other` 条目会覆盖具名条目，因此要靠对该文件 `chmod o+w` 才能给 deploy 写权限。
    • D.ACL 掩码把具名条目上限压到只读，用 `setfacl -m m::rw /srv/app/config.yml` 抬高它。✓ 答案

    掩码是所有具名用户条目、具名组条目以及属组条目的上限，因此已授予但不在掩码之内的权限只会被记录下来而无法生效。`getfacl` 用 `#effective:` 注释把这一点写得很清楚：这里写权限已授予 deploy，却被只读的掩码剥掉了，所以抬高掩码才能让既有的授权真正起作用。

    编号 QB-P96A2J依据： acl(5) and setfacl(1) manual pages: the mask entry and effective permissions报告此题的问题

21. 21. 一台 RPM 系发行版服务器上，某厂商程序必须以其属主的权限运行，但它实际以普通权限运行： ``` $ ls -l /opt/tools/bin/netcheck -rwsr-xr-x. 1 root root 48120 Aug 14 10:02 /opt/tools/bin/netcheck $ findmnt /opt TARGET SOURCE FSTYPE OPTIONS /opt /dev/mapper/vg0-opt xfs rw,nosuid,nodev,relatime ``` 原因是什么？

    • A.该程序缺少 set-user-ID 位，必须对该文件执行 `chmod u+s` 把它补回来。
    • B.该文件系统是以 `nosuid` 挂载的，这个选项让内核忽略 set-user-ID 位。✓ 答案
    • C.SELinux 正在限制该程序，对相应布尔值执行 `setsebool -P` 就能允许它运行。
    • D.该程序位于 XFS 上，而 XFS 在为文件保存的元数据里并不记录 set-user-ID 位。

    属主字段里的 `s` 已经证明该位在文件上是设置好的，缺的并不是这个位；作出裁决的是上一层的挂载。以 `nosuid` 挂载的文件系统会告诉内核忽略其中所有文件的 set-user-ID 与 set-group-ID 位，这是一种有意的加固选择，因此要么把程序迁到没有该选项的挂载点，要么经审批修改该挂载选项。

    编号 QB-6SY4FH依据： mount(8) manual page: the nosuid mount option and set-user-ID handling报告此题的问题

22. 22. 对一台 RPM 系发行版服务器的密钥登录退回到了密码提示。/var/log/secure 记录 `Authentication refused: bad ownership or modes for directory /home/deploy/.ssh`。对该目录执行 `ls -ld` 显示 `drwxrwxr-x`，`authorized_keys` 显示 `-rw-rw-r--`。应该改正什么？

    • A.为该账号重新生成更长的密钥对，因为服务端拒绝了客户端提供的那种密钥算法。
    • B.在 sshd_config 中把 PasswordAuthentication 设为 no，这样服务端就会接受那个密钥。
    • C.把该目录改为 700、authorized_keys 改为 600，因为 StrictModes 会拒绝服务端上组内可写的路径。✓ 答案
    • D.把该账号加入 sshd_config 的 AllowUsers 列表，因为服务端会拒绝未列出账号的密钥。

    这条日志点名的是失败的检查项，而不是密钥本身：启用严格模式检查后，服务端不会信任那些目录或属主可被非属主改动的密钥文件，因为组内可写的路径会让别的账号装上自己的密钥。把目录与密钥文件收紧到仅属主可访问就能恢复信任，而退回密码提示只是密钥被忽略后的正常结果。

    编号 QB-N9TXUG依据： sshd_config(5) and sshd(8) manual pages: StrictModes ownership and mode checks on ~/.ssh报告此题的问题

23. 23. 一台 RPM 系发行版服务器上，/etc/sudoers.d/devops.conf 的内容是 `%devops ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart app`。该文件权限 0440、属主为 root，`visudo -c` 未报语法错误，用户也确实属于 devops 组，但 `sudo -l` 并不列出这条规则。最可能的原因是什么？

    • A.该文件名里含有一个点号，而 sudo 会直接跳过名字中带点号或以波浪号结尾的投放文件。✓ 答案
    • B.该组必须写成不带百分号的 `devops ALL=(ALL)`，因为百分号在这里标记的是主机别名。
    • C.NOPASSWD 不能与具体的命令路径搭配使用，所以整条规则会被解析之后丢弃掉。
    • D.这条规则要先执行 `systemctl daemon-reload`，sudo 才会重读该投放目录。

    对该投放目录的包含是有意忽略名字中含点号或以波浪号结尾的文件的，这样软件包备份和编辑器残留文件就不会悄悄改动授权规则。这里的文件语法正确、属主也对，所以语法检查器不会报错，但它根本不会被读取；把文件名中的点号去掉，规则就会生效，`sudo -l` 随后也会列出它。

    编号 QB-5SMS9G依据： sudoers(5) manual page: #includedir and drop-in file names that are ignored报告此题的问题

练习题依据 CompTIA 公布的 Linux+ 考试大纲及 Linux 系统管理的通行实践编写。CompTIA 和 Linux+ 是 CompTIA 的商标，Linux 是 Linus Torvalds 的注册商标；本网站与 CompTIA 无关联，也未获其认可。真实考试除选择题外还包含实操题（performance-based questions），要求在模拟环境中实际完成任务——四选一的题型无法复现这一部分，因此本题库覆盖的是知识部分，请同时在真实系统上动手练习。CompTIA 会定期修订大纲并为每个版本编号：报考前请向 CompTIA 确认现行大纲、考试代码与报考要求。 关于 CompTIA Linux+ 认证 →