系统信息检索
在《Linux Journal》第 39 期(“Linux 足够可靠吗?”,1997 年 7 月)中,Phil Hughes 撰写了关于硬盘故障导致的停机时间
在某个时候,我们有一个用于防火墙的配置盘;但是当我们需要更换硬盘时,配置盘却不见了。这种丢失导致了数小时的工作时间和可能一天的正常运行时间损失。拥有所有内容的完整备份、所有机器的启动盘、备用电缆和磁盘驱动器以及其他各种零件,可以大大缩短处理问题所花费的时间。
我开发了一个脚本,以简化 Hughes 先生描述的 Linux 系统管理难题。我在我的所有 Linux 系统上都使用了这个脚本,并认为它对其他系统管理员以及 Hughes 先生都将有益。
我已经在四台基于英特尔奔腾的系统和七台基于英特尔 486 的系统上安装了 Linux。所有基于 486 的系统之前都被废弃了,因为它们的处理能力或内存都不足以运行 Windows for Workgroups、Windows 95 或 Windows NT,这些是我公司选择的桌面操作系统。所有这些基于 486 的系统都非常出色地运行 Linux。
我将这些 Linux 系统用于网络故障排除、测试、研究、评估、实验和程序开发。在大型企业中安装和使用 Linux 帮助我更多地了解了 DNS、网络、网络编程、HTML 和 HTTP、系统管理以及 Unix 环境的其他方面。
尽管这些 Linux 系统非常有用,但所涉及设备的年代和多样性使得系统管理任务有时变得困难。请考虑表 1“Linux 系统和主要组件”中显示的设备组合。(此表还提供了我将在本文中通篇引用的 Linux 系统名称列表)。五个计算机供应商、三种磁盘类型、七种类型的网卡(五个 NE2000 克隆来自三个供应商)和四种 CD-ROM 类型的排列组合造成了一些有趣的安装、配置和管理难题。
我还遇到了其他重大的系统管理难题
这些系统的各种硬件组件会随着研究和评估需求的变化而不断变化。
因为我正在努力争取 Linux 在我们组织内的认可,所以我大部分系统管理功能都是在自己的时间内执行的。
这些系统中没有一个配备可用的磁带备份单元。
这些系统分布在孟菲斯地区的三个地点。所有系统都通过城域网互连,这构成了简化系统管理职责方法的基础。
似乎这些问题还不够严重,在我安装了第六个 Linux 系统后不久,其硬盘就开始出现故障。由于磁盘故障缓慢,我有时间恢复所有相关的配置信息,以便在更换故障磁盘后快速重新安装和重新配置 Linux。
列表 1 显示了我创建的一个 shell 脚本,用于简化维护多个不同的 Linux 系统的繁琐工作。这个脚本,我称之为 collect,使用远程 shell 命令 (rsh) 和远程复制命令 (rcp) 将许多文件(在“收集的文件”框中简要描述)从远程 Linux 系统复制到“cuthroat”,我的主要系统管理系统。
如果我丢失了任何 Linux 文件系统(cuthroat 的文件系统除外),我都不必担心丢失重要的配置信息。正如我们稍后将看到的,由于我将 cuthroat 上的所有收集信息传播到其他几个系统,因此我不必担心丢失 cuthroat 的文件系统。
在编写和测试 collect 脚本后,我在 cuthroat 上创建了 /admin 目录,并将脚本移动到该目录。当我想从 Linux 系统(例如 barb)收集系统管理信息并将该信息存储在 cuthroat 上时,我登录到 cuthroat 并键入以下命令
cd /admin collect barb
如果 /admin/barb 目录不存在,collect 脚本会创建它,然后开始复制远程系统的文件。秉承 UNIX 的简洁性精神,唯一的屏幕输出是一行
barb: copying /proc, .config, lilo.conf, partition info此行由几个 echo -n 命令行和一个最终的 echo 命令行构建,指示远程操作的进度。一旦 collect 脚本完成,cuthroat 上的 /admin/barb 目录将包含 barb 的系统管理文件的副本。
当然,我可以为任意数量的系统运行 collect,如下所示
cd /admin for i in anthrax barb ducktape do collect $i done
在上面的示例中 collect 执行后,cuthroat 的 /admin 目录如图 1 所示。
我可以在 cuthroat 上运行 collect 以复制 cuthroat 自己的文件(而不是远程系统的文件),如下例所示
logon to cuthroat cd /admin collect cuthroat
如果 cuthroat 的 .rhost 文件命名了自身,则 collect 脚本将正确执行并将收集的文件复制到 cuthroat 的 /admin/cuthroat 目录中。
如果磁盘故障摧毁了我的某台机器,收集的系统管理信息将帮助我在更换磁盘上以最小的混乱和困难重新加载 Linux。
例如,如果 loyd 的磁盘发生故障,我将更换磁盘并使用以下步骤恢复 Linux
从 /admin/loyd/fdisk 中的信息重建分区。
重新加载 Linux。
从文件 /admin/loyd/kernel.config 中的信息重建内核。
文件 /admin/loyd/lilo.conf 包含行 append="cdu31a=0x340,5" 对于 loyd 的旧 CD-ROM 驱动器的正常运行是必要的信息。
当然,与这些步骤的偏差与 Linux 用户一样多,但展示这些步骤的目的是为了演示收集的信息在恢复 Linux 系统中是如何有用的。
尽管从灾难性错误中恢复的能力是创建 collect 脚本的最初动力,但收集的数据还有许多其他用途。
最近,我需要在 barb 上添加 IBM 令牌环网 16/4 适配器。此适配器仅适用于中断请求 (IRQ) 2、3 或 7,因此我检查了 /admin/barb/interrupt 文件,并确定 IRQ 3 未被使用。由于我已经远程收集了此信息并将其存储在 cuthroat 上,因此我确定 barb 有一个可用的 IRQ,而无需前往 barb 的位置,也无需登录 barb。事实上,由于 barb 的信息存储在 cuthroat 上,即使 barb 处于离线状态,我也可能为 barb 找到一个未使用的中断。
假设我需要清点各种 Linux 系统中的某些软件或硬件组件。让我们以网卡为例
cd /admin egrep -i "ne2000|3c|ibm tr" \ `find . -name interrupts -print`
egrep 命令将搜索每个 Linux 系统目录中的 interrupts 文件,查找 ne2000(NE2000 克隆)、3c (3Com 网卡) 或 ibm tr (IBM 令牌环网卡),并打印每个文件中所有匹配的行。
几个月前,我在 loyd 的内核中配置了增强型实时时钟 (RTC) 支持。还是 speed 的内核?我是否可能在两个内核中都配置了 RTC 支持?以下是如何判断哪些内核具有 RTC 支持
cd /admin grep CONFIG_RTC=y \ `find . -name kernel.config -print`
在不到一秒的时间内,grep 确认只有 loyd 具有 RTC 支持
./loyd/kernel.config:CONFIG_RTC=y
cuthroat 机器有一个 PC DOS 分区。最近,我在 cuthroat 上启动了 DOS,以配置 autoexec.bat 和 config.sys 文件,以便我可以在 DOS 下使用 cuthroat 的 CD-ROM。说明告诉我,如果 CD-ROM 由 IRQ 14 控制,则采取一个操作;如果 CD-ROM 由 IRQ 15 控制,则采取完全不同的操作。为了提高效率(或偷懒),我不想关闭 cuthroat,将其拆开,确定 CD-ROM 电缆插入 IDE 控制器的位置,重新组装并再次打开它。
经过一番思考,我想到了答案:查看存储在 loyd 上的 cuthroat 的 /proc/interrupt 文件的副本。我甚至不必在 cuthroat 上启动 Linux。我使用 DOS FTP 客户端将 loyd 的 /admin/cuthroat/interrupts 文件传输到 cuthroat 上的 DOS 系统。以下是该文件中的两行相关行
14: 9663 + ide0 15: 32 + ide1
IRQ 14 是第一个 IDE 设备;在 collect 脚本获取 cuthroat 的系统管理信息时,此设备上已发生 9,663 次中断。在同一时间间隔内,连接到 IRQ 15 的第二个 IDE 设备仅生成了 32 次中断。由于我知道 cuthroat 只有两个 IDE 设备,因此从中断计数可以明显看出,硬盘驱动器连接到 IRQ 14,而 CD-ROM 连接到 IRQ 15。
作为最后一个示例,让我们查找所有带有英特尔臭名昭著的浮点除法错误的奔腾处理器
cd /admin grep fdiv_bug `find . -name cpuinfo -print`\ | grep yes
如果 “solo” 中的奔腾芯片有浮点除法错误,那么 grep 将产生以下输出
./solo/cpuinfo:fdiv_bug : yes
尽管 cuthroat 是我的主要系统管理站点,但我将收集的文件保存在多个系统上以实现冗余。在将所有 Linux 站点的系统管理信息复制到 cuthroat 后,我将收集的信息从 cuthroat 传播到另一个系统
rsh loyd mkdir /admin rcp -pr /admin/* loyd:/admin
我为每个我希望拥有此信息副本的机器重复 rcp。
要使 collect 脚本工作,必须满足几个简单的要求
第一个(也是最明显的)要求是所有系统都必须互连。
根据名称解析的配置方式,所有系统名称都必须在域名服务器中或每个系统的 /etc/hosts 中。
每个系统都需要一个正确配置的 .rhost 文件来支持远程 shell 和远程复制操作。
最后,您必须在每个系统的内核中配置 /proc 文件系统。请注意,内核构建过程默认包含 /proc 文件系统。
如果您发现 /proc(或任何其他目录)包含对您重要的系统管理信息,则可以轻松扩展 collect 脚本。我的系统中没有一个使用 PPP;如果您的系统使用 PPP,请修改 collect 脚本以捕获您的 PPP 配置信息。
我的大多数 Linux 系统都运行 Apache Web 服务器,但我没有费心收集任何 Apache 配置信息,因为只有一个系统的配置与另一个系统的配置之间只有两行区别。如果您正在运行 Web 服务器并且您进行了大量配置更改,您可能希望收集 Web 服务器的配置数据。
如果您正在使用 Linux 作为防火墙,请修改 collect 脚本以保存防火墙配置。如果 Hughes 先生一直在使用 collect 脚本,那么他的防火墙硬盘的故障可能不会让他付出“数小时的工作时间和可能一天的正常运行时间”。
在一个 Linux 系统上运行 find 找到了大约十几个名称为 *.conf 形式的文件。如果您仔细查看您的系统,您可能会发现可以使用 collect 脚本收集的其他配置文件。
图 1 中命名的所有 Linux 系统都受到工业级防火墙的保护,免受 Internet 的攻击。这些系统都不是关键任务系统。我的安全考虑可能与您的安全考虑大相径庭,因此您将必须评估您收集的任何信息是否会危及您的系统,并据此采取行动。
collect 脚本通过集中配置信息简化了不同系统的远程系统管理。它易于使用且易于扩展。由于每个系统收集的文件大小总计小于 10KB,因此只需要很少的磁盘存储空间。尽管我创建 collect 脚本是为了 облегчить 从潜在灾难中恢复,但使用 collect 脚本获得的信息还有许多其他用途。
