分析和排查系统故障
要求：
- 日志文件分析
- 将/etc/Bluetooth文件夹改名；然后启动Bluetooth服务，观察故障现象；通过分析/var/log/messages文件中的相关记录，判断故障原因，并修复该故障。
步骤：
- 1. 将/etc/bluetooth目录改名为/etc/bluetooth.bak，执行“service Bluetooth start”命令尝试启动服务，将出现错误提示信息“Can’t open RFCOMM config file：No such file or directory”。如图所示：
- 2. 查看/var/log/messages文件，分析末尾关于Bluetooth服务的日志记录，会发现类似于“Can’t open config file /etc/Bluetooth/hcid.conf”的记录条目。将/etc/bluetooth.bak目录改名为/etc/bluetooth。重新启动bluetooth服务，将可恢复正常，观察/var/log/messages文件中相关日志记录的变化。如图所示：
- 在终端tty3中尝试以不存在的用户账号Administrator进行登录；新建用户账号kitty并以此账号在终端tty4种进行登录，第一次输入错误的密码，第二次再输入正确的密码；查看前述用户的登录情况记录。
步骤：
- 1. 切换到tty3，使用账号Administrator登录，密码任意。
- 2. 重建用户Kitty，设置密码为123456；切换到tty4，首先尝试以账号Kitty、密码为Kitty进行登录，然后以账号Kitty、密码为123456登录。如图所示：
- 3. 使用last命令查看成功的登录记录。如图所示：
- 4. 使用lastb命令查看失败的登录记录。如图所示：
- 5. 查看/var/log/secure文件中新增的安全信息，观察Administrator、Kitty用户登录及验证失败的事件记录。如图所示：
- 故障模拟及修复
- 备份磁盘sda的MBR扇区到其他硬盘，并联系MBR的回复操作。
步骤：
- 1. 将第1块硬盘（sda）的MBR扇区备份到第2块硬盘的sdb1分区中（挂载到/backup目录下）。
- 2. 模拟MBR扇区故障。从设备文件zero中读取512字节的数据，将其覆盖到第1块硬盘（sda），从而破坏MBR扇区中的数据。如图所示：
- 3. 重启系统后，将会出现“Operating system not found”的提示信息，表示无法找到可用的操作系统，因此无法启动主机。如图所示：
- 4. 以使用RHEL 5 安装光盘为例。当出现安装向导的“boot：”提示符时，在后边输入“linux rescue”并回车，将以“急救模式”引导光盘中的Linux系统。如图所示：
- 5. 在接受的默认语言界面，选择“English”，然后点击“OK”。如图所示：
- 6. 在键盘格式界面，选择“us”，然后点击“OK”。如图所示：
- 7. 在提示是否配置网卡时一般选择“NO”。如图所示：
- 8. 在如图所示界面中，点击“Continue”。如图所示：
- 9. 在是否初始化磁盘的警告窗口，建议选择“NO”，避免对硬盘数据造成不必要的损坏。如图所示：
- 10. 最后选择“OK”确认后将进入到带“sh-3.2#”提示符的Bash Shell环境。如图所示：
- 11. 执行相应的命令挂载保存有备份文件的硬盘分区（sdb1），并将数据恢复到硬盘“/dev/sda”中即可。需要注意的是：当前使用的系统环境是光盘中的Linux目录结构。如图所示：
- 12. 完成恢复操作以后，执行“exit”命令退出临时Shell环境，系统将会自动重启。
- u 通过单用户模式进入Linux系统，重设root账号的密码。
步骤：
- 1. 重启主机，在出现GRUB菜单时按上下方向键取消倒计时，并定位到要进入的操作系统选择项（如“Red Hat Enterprise Linux Server”），按e键进入编辑模式。如图所示：
- 2. 定位到以kernel开头的一行并按e键。如图所示：
- 3. 在行尾添加“1”的启动参数，其中数字“1”也可以换成字母“s”或“single”，也可以表示进入到单用户模式。如图所示：
- 6. 在单用户模式的Shell环境中，可以执行“passwd root”命令重新设置root用户的密码。如图所示：
若使用RHEL5的安装光盘进入急救模式的shell环境，则只需切换到待修复Linux系统的根目录环境，直接执行“passwd root”命令重设root用户的密码即可；或者修改/etc/shadow文件，将root用户的密码字段清空，重启后以空密码可登录系统。如图所示：
sh-3.2# chroot /mnt/sysimage
sh-3.2# passwd root
- 将/etc/inittab、/boot/grub/grub.conf文件移动至/opt目录下，重启系统。
步骤：
- GRUB引导故障
- 模拟GRUB引导故障。将grub.conf文件移动至/opt目录下。如图所示：
- 2. 重启系统，Linux主机启动后可能只出现“grub>”的提示符，无法完成进一步的系统启动过程。如图所示：
- 3. 在该提示符后进行编辑，通过输入对应的引导命令，然后再执行“boot”命令即可正常引导Linux系统。如图所示：
或：kernel /vmlinuz-2.6.18-194.e15 ro root=/dev/VolGroup00/LogVol00 rhgb quiet
- 4. 进入系统后，将之前移动到/opt目录里的grub.conf文件重新复执一份到原目录/boot/grub/里。如图所示：
由于在“grub>”环境中使用的命令较为复杂，而且一般难以也难以记住相关的命令选项、内核加载参数等，因此用户可以采用另一种修复办法，同样使用RHEL5的安装光盘引导进入急救模式，如果分区表并未被破坏，则急救模式将会找到硬盘中的Linux根分区，并将其挂载到光盘目录结构中的/mnt/sysimage/文件夹中。
进入“sh-3.2#”的shell环境以后，执行“chroot /mnt/sysimage”命令可以将目录结构切换到待修复的Linux系统中，然后重写（或通过之前备份的文件恢复）grub.conf（/boot/grub/目录下）配置文件即可。如图所示：
sh-3.2# chroot /mnt/sysimage
sh-3.2# vim/boot/grub/grub.conf
sh-3.2# exit
sh-3.2# exit
在上例中，若未执行“ chroot/mnt/sysimage”命令，则重新建立的grub.conf配置文件应该位于/mnt/sysimage/boot/grub/grub.conf。
如果是MBR扇区中的引导程序出现损坏，可能在重建grub.conf配置文件后仍然无法成功启动系统，这时候可以通过RHEL5救援模式的shell环境重新安装gurb引导程序。切换到待修复的Linux系统根环境，执行“grub-install /dev/sda”命令可以重新将grub引导程序安装到第1块硬盘sda的MBR扇区。如图所示：
sh-3.2# chroot /mnt/sysimage
sh-3.2# grub-install /dev/sda
sh-3.2# exit
sh-3.2# exit
上述方法同样适用于在Linux主机中重装Windows系统（不覆盖Linux系统）后导致Linux系统无法启动的情况。因为对于使用双操作系统的主机，后安装的Windows系统将使用自己的引导数据覆盖MBR扇区中的记录，导致开机后不再出现GRUB菜单从而无法进入Linux系统。如果是后安装Linux系统，GRUB程序将会自动识别硬盘中的Windows系统并将其加载到GRUB菜单配置中。
经验总结：
执行“dd if=/dev/zero of=/dev/sda bs=446 count=1”命令可以模拟出对MBR扇区中GRUB引导程序的破坏（注意先做好备份），但并不会破坏分区表（实际上分区表保存在MBR扇区中的第447~第510字节中）。
- 模拟/etc/inittab文件丢失
步骤：
- 1. 将inittab文件移动至/opt目录下，模拟/etc/inittab文件丢失。如图所示：
- 2. 重启系统后，将会出现“INIT：No inittab file found”的错误提示信息。如图所示：
- 3. 这类故障同样可以在RHEL 5 安装光盘的急救模式下进行修复。如何编辑如图所示：
日志文件分析
- 1. 内核及系统日志
内核及系统日志功能主要由默认安装的sysklogd-1.4.1-39.2软件包提供，该软件包安装了klog、syslogd两个程序，并通过syslog服务进行控制，分别用于记录系统内核的消息和各种应用程序的消息。Syslog服务所使用的配置文件为/etc/syslog.conf。通过查看/etc/syslog.conf文件中的内容，可以了解到系统默认的日志设置。
在Linux内核中，根据日志消息的重要程度不同，将其分为不同的优先级别（数字等级越小，优先级越高，消息越重要）：
- 0 EMERG（紧急）：会导致主机系统不可用的情况
- 1 ALERT （警告）：必须马上采取措施解决的问题
- 2 CRIT （严重）：比较严重的情况
- 3 ERR （错误）：运行出现错误
- 4WARNING（提醒）：可能影响系统功能，需要提醒用户的重要事件
- 5 NOTICE （注意）：不会影响正常功能，但是需要注意的事件
- 6 INFO （信息）：一般信息
- 7 DEBUG （调试）：程序或系统调试信息等
- 用户日志
在wtmp、btmp、lastlog等日志文件中，保存了系统用户登录、退出等相关的事件消息。
- 查询当前登录的用户情况——users、who、w命令
user命令只是简单的输出当前登录的用户名称，每个显示的用户名对应一个登录会话。
who命令用于报告当前登录到系统中的每个用户的信息。使用该命令，系统管理员可以查看当前系统存在哪些不合法用户，从而对其进行审计和处理。who的默认输出包括用户名、终端类型、登录日期及远程主机。
w命令用于显示当前系统中的每个用户及其所运行的进程信息，比users、who命令的输出内容要更加丰富一些。
- 查询用户登录的历史记录——last、lastb命令
last命令用于查询成功登录到系统的用户系统，最近的登录情况将显示在最前面。通过last命令可以及时掌握Linux主机的登录情况，若发现未经授权的用户登录过，表示当前主机可能已被入侵。
lastb命令用于查询登录失败的用户记录，比如登录的用户名错误、密码不正确等情况都将记录在案。用于登录失败的情况属于安全事件，因为这表示可能有人在尝试猜解你的密码。除了使用lastb命令查看以外，也可以直接从安全日志文件/var/log/secure中获得相关信息。
- 程序日志
在Linux系统中，还有相当一部分应用程序并没有使用syslog服务来管理日志，而是由程序自己维护日志记录。
总的来说，作为一名合格的系统管理人员，应该提高警惕，随时注意各种可疑状况，定期并随机的检查各种系统日志文件，包括一般信息日志、网络连接日志、文件传输日志以及用户登录日志记录等。在检查这些日志时，要注意是否有不合常理的时间或操作记录，例如出现以下一些现象就应多加注意：
- 用户在非常规的时间登录，或者用户登录系统的IP地址和以往的不一样
- 用户登录失败的日志记录，尤其是那些一再连续尝试进入失败的日志记录
- 非法使用或不正当使用超级用户权限
- 无故或者非法重新启动各项网络服务的记录
- 不正常的日志记录，比如日志的残缺不全，或者是诸如wtmp这样的日志文件无故缺少了中间的记录文件。
另外，尤其提醒管理人员需要注意的是：日志并不是完全可靠的，高明的黑客在入侵系统后，经常会打扫现场。所以需要综合运用以上的系统命令，全面、综合的进行审查和检测，切忌断章取义，否则将可能做出错误的判断。
- 修复文件系统
在Linux主机中，可能会因为非正常关机、突然断电、设备数据读写异常等原因导致文件系统的破坏。比较常见的是超级块（super-block）损坏。超级块是文件系统的核心“档案”，他记录了该文件系统的类型、大小、空闲磁盘块等信息。
当文件系统的超级块数据损坏时，Linux将无法识别该文件系统，挂载时会出现“you must specify the filesystem type”的提示而不能正常使用。例如，模拟/dev/sdb1文件系统的超级块数据库损坏，尝试挂载时将不能成功。如图所示：
对于通过/etc/fstab文件自动挂载且设置了fsck参数（第6列的值非0）的文件系统，若超级块出现错误则Linux系统在启动时会报错，并提示用户需要进行修复操作。例如：当/dev/sdb1分区的超级块出现错误时，启动后系统将提示“Give root password for maintenance”，如图所示：
出现这种情况时，只需根据提示输入root用户的密码，即可进入到一个临时的shell环境，在这里用户可以对出现错误的文件系统进行修复。修复完毕后执行exit命令即可退出并重启系统。
修复一般的文件系统错误可以使用fsck命令进行，结合“-t”选项指定文件系统类型，结合“-y”选项对发现的问题自动回答“yes”。需要注意的是：如果该文件系统遭受破坏的情况很严重，则修复完毕后可能仍然会丢失一些数据，因此请慎重决定是否进行恢复（必要时也可以先用dd命令将损坏的分区进行备份）。
- 磁盘资源耗尽故障
显而易见，当一个文件系统的磁盘空间耗尽以后，将无法继续在该分区中创建新的文件数据，从而导致故障的出现。例如，当根分区“/”中德磁盘空间耗尽以后，将可能导致部分程序乃至整个系统无法正常启动或运行，因为一些临时性的运行文件将无法建立。
当根分区磁盘空间不足而无法启动进入Linux系统时，可以通过RHEL5的安装光盘进入急救模式，转移或清理根分区中占用大量空间的文件，具体过程不再赘述。使用dd命令可以模拟出根分区耗尽的故障，例如：执行“dd if=/dec/zero of=/somefile bs=1M count=999999”命令。
除此以外，在每一个ext3文件系统中，能够使用的文件数量（对应i节点数量）也是有限的。当一个文件系统被格式化以后，其i节点数也即文件数量就已经固定下来了。如果用户在该分区中创建了巨量的细小文件（耗尽i节点），将可能出现这种情况：虽然该分区中仍然有大量的剩余磁盘空间，但是用户却无法再建立新的文件。
模拟i节点耗尽故障
具体步骤：
- 1. 新建一个约32MB大小（磁盘容量越小，修复时间越短）的ext3文件系统，将其挂载到/data目录下。并使用带“-i”选项的df命令确认该文件系统中i节点的使用情况。
- 2. 编写一个测试程序，运行该程序后可以耗尽/dev/sdb2分区中所有可用的i节点。
- 3. 当i节点耗尽以后，在该文件系统中再创建新的文件时，将会出现“设备上没有空间”的错误现象。通过df命令可以查看到该分区中实际上还有可用的剩余空间，但是因为i节点数已经用完，所以无法创建新的文件。
修复i节点耗尽故障
具体步骤：
理解i节点耗尽故障的根结以后，问题就比较好解决了。只需要找出该分区中占用大量i节点的细小文件，并进行转移或者删除即可。对于许多用户公用的文件系统，建议为相关用户设置磁盘限额（包括文件数量、磁盘空间两方面）。
- 检测硬盘坏道
磁盘坏道分为逻辑坏道和物理坏道两种，前者主要由于软件操作不当造成，可以使用软件修复；而后者是物理性损坏，只能通过更改磁盘分区或扇区的占用位置来进行改善，排除掉包含有坏道的磁盘空间。当磁盘出现以下现象时，有可能是磁盘出现坏道，需要进行检测和修复：
- 读取磁盘中的数据时，磁盘设备发出异常声响
- 访问磁盘中的某个文件时，反复读取且出错，提示文件损坏
- 对于新建立的分区无法完成格式化
- 系统使用该磁盘时频繁死机
在Linux系统中，检测磁盘的坏道情况可以使用badblocks命令进行，结合“-s”选项用于显示进度信息，“-v”选项用于显示详情。如图所示：