安装和设置 Linux 的难度通常被认为是其未被更广泛使用的原因之一。人们通常认为，编辑传统的 UNIX 配置文件比使用 Microsoft Windows 等操作系统提供的图形界面更困难。对于只有一台机器的新手用户来说，这可能是事实，而且大多数商业 UNIX 供应商现在都为系统配置的至少某些方面提供了基于 GUI 的工具。在 Linux 下，像 COAS（见资源 1）和 Red Hat 发行版这样的项目正在开始满足这种需求。

对于拥有数十甚至数百台机器的大型安装来说，GUI 方法行不通——为 200 台机器输入单独的配置数据根本不切实际。除了安装大量机器的能力外，大型站点通常需要对配置进行更多控制；例如，他们可能需要安装配置保证与现有机器相同的新机器。机器也可能需要定期重新配置，因为其用途会发生变化，或者仅仅是为了跟上最新的软件和补丁。

为了有效地做到这一点，需要大量的自动化，多年来，大型 UNIX 站点一直在开发自己的工具（见资源 2）。UNIX 配置文件的灵活性和可访问性使 Linux 特别适合自动化，而那些试图安装和管理大量 NT 系统的站点通常可能会发现这个过程更加困难（见资源 3）。

爱丁堡大学信息学部门拥有 500 多台 UNIX 机器，配置种类繁多。它们中的大多数都是使用 LCFG（本地配置）系统自动安装和维护的，该系统最初是在几年前开发的（见资源 4）。客户端和服务器配置都可以轻松复制，以替换故障机器或为新实验室创建数十个相同的系统。因此，重新配置是一个持续的过程；例如，机器每晚都会调整，以确保它们运行所需软件的最新版本。Linux（我们使用的是 Red Hat 发行版的一个版本）已被证明非常适合这种环境，并且最近超过 Solaris，成为最受欢迎的桌面系统，无论是供员工使用还是学生实验室使用。

自动配置系统应该能够从头开始构建可工作的机器，而无需人工干预。这包括基本操作系统的配置（磁盘分区、网络适配器）、所需软件的加载以及特定于应用程序的服务（如 Web 服务器）的配置。这使得可以使用更换硬件快速重建故障机器，并使新机器能够高效安装，即使是初级员工也能完成。作为副作用，它还避免了备份任何系统分区的需要。

驱动此构建过程的配置信息集定义了单个机器的 特性，如果此 规范 以显式形式（如纯文本文件或数据库）提供，则非常有用。然后可以通过复制其规范并应用自动构建来简单地 克隆 机器。这对于安装多个类似的机器（例如在学生实验室中）非常重要。规范的主副本应远程保存在机器之外，以便即使机器宕机也可用。这允许程序自动验证单个配置，甚至机器之间的关系，例如确保每个客户端指定的 DNS 服务器实际上配置为运行名称守护程序。规范也可以从机器功能的更高级别描述中生成。继承模型非常有用，因为许多机器配置可以方便地描述为特定类别的通用配置的微小变体。

传统的配置系统通常是 静态的，因为配置仅在安装机器时应用。大多数供应商提供的安装过程都属于这一类，基于复制磁盘映像的克隆系统也是如此。如果后续的配置更改必须手动应用，则配置几乎肯定会“腐烂”，并且不可能确信所有机器都已正确配置。明显的配置错误只会导致用户机器出现故障。更微妙的配置错误可能会被忽视并造成严重的安全问题。即使完全 动态的 系统是不切实际的，理想的系统也会不断调整配置以符合规范。某些参数可以立即更改以跟踪规范中的更改；某些参数（如网络地址）可能仅在机器重新启动时更改；而其他参数（如磁盘分区）可能需要完全重建。

如果配置系统不完整并且需要人工干预，则许多好处都会丧失。然而，构建一个涵盖所有可想象参数的全面系统显然是不切实际的。关键问题是尝试创建一个足够灵活的可扩展框架，以便能够轻松地合并新参数和 组件。然后，系统的单个实例可以在特定站点上发展，以适应本地需求。如果它要由工作的管理员按需扩展，则该框架需要非常轻巧且在短时间内易于理解。必须可以使用熟悉的语言轻松创建组件，并将它们与需要配置的新子系统连接起来。开源软件是一个优势，因为通常很容易基于现有扩展来创建新扩展。

在引入 LCFG 之前，我们使用一系列典型的技术配置机器，包括供应商安装和磁盘复制（克隆）。随后应用了一个整体脚本，该脚本为所有不同的配置变体应用了各种“调整”。这几乎没有满足上面列出的任何要求，并且管理起来是一场噩梦。

可用的替代方案范围从大型商业系统（太昂贵且可能过于不灵活）到在各个站点为自己使用而开发的系统（通常与我们现有的流程相比没有太大改进）。最近，出现了像 COAS 和 GNU cfengine（见资源 5）这样有趣的工具，但我们仍然没有意识到有任何可比较的系统能够像 LCFG 一样满足完全相同的需求集。

考虑到有限的开发资源，我们尝试将初始系统设计为多个独立的子系统，并打算为某些我们可以利用现有技术的子系统使用临时实现

配置数据项表示为键值对，方式类似于 X 资源。键由三部分组成：主机名、组件和属性。例如，主机 wyrgly 的名称服务器 (cul) 由 DNS 组件配置

wyrgly.dns.servers: cul.dcs.ed.ac.uk

请注意，此规范是一个相当抽象的表示形式，并非直接绑定到机器实际需要的配置形式，在本例中，它以 resolv.conf 文件中的一行为例。这允许相同的表示形式用于不同的平台，并允许高级程序轻松地分析和生成资源。每台机器上的 LCFG 组件负责将这些资源转换为特定平台的适当形式。COAS 对配置参数使用了类似的表示形式。

资源目前存储在简单的文本文件中，每个主机一个文件。这些文件的集合构成了 资源库。我们打算提供一种专用语言来指定这些资源；它将支持继承、默认配置、验证和一些更高级别规范的概念。但是，我们目前正在使用基于 C 预处理器和简短 Perl 脚本的“临时”解决方案来预处理资源。C 预处理器提供文件包含和宏，可用于原始继承。Perl 脚本允许使用正则表达式修改继承的资源。还支持通配符以提供默认值。

在实践中，大多数机器都有非常短的资源文件，这些文件只是继承了一些标准模板。可以通过复制这些资源文件来简单地克隆机器。通常，会覆盖一些资源以提供细微的差异。例如

#include <generic_client.h>
#include <linux.h>
#include <portable.h>
amd.localhome:  paul
auth.users:     paul

主机名在资源键中不是必需的，因为这是从资源文件的名称生成的。

资源目前使用 NIS（Sun 的网络信息系统）分发给客户端。这是另一个“临时”解决方案，远非理想；我们希望在不久的将来替换它。

每台机器上的许多组件从资源库中获取资源，并以适合该特定平台的方式实现指定的配置。组件目前以 shell 脚本的形式实现，这些脚本采用一组标准的 方法 参数，非常像 Red Hat Linux 下的 rc.d 启动脚本

客户端-服务器程序 (om) 还允许在多台远程机器上按需执行方法。除了标准方法外，组件还可以有其他任意方法。

不同类型的组件将在不同的时间执行不同的操作。通常，守护程序可能会在启动时启动，定期重新加载，并在关闭时停止。但是，某些组件可能只是在启动时执行重新配置，或者仅响应 RUN 方法而启动（例如，备份系统）。

组件脚本通常从 通用 组件继承一组子例程。这提供了默认方法和各种实用程序过程，用于资源检索等操作。这使得简单组件易于编写，并且脚本通常非常短。

典型的主机运行 20 到 30 个组件，控制子系统，如 Web 服务器、打印机、NIS 服务、NFS 配置和各种其他守护程序。有两个组件值得更详细地提及。

boot 组件是唯一直接从系统启动文件运行的组件。这使用资源来确定要启动的其他组件。因此，在特定机器上运行的服务集由引导资源控制。

update 组件通常每晚以及在启动时运行。这使用了非常有用的 updaterpms 程序，该程序将机器上安装的 RPM 与通过资源指定的 RPM 进行比较。RPM 会自动安装或删除，以使机器的状态与规范同步。这意味着同一类中的所有机器始终保证具有相同的最新软件包集。更改继承的资源文件将自动重新配置该类中所有机器携带的 RPM。

尽可能多的配置由各种组件动态执行。但是，某些配置（如磁盘分区）必须在安装时硬连线。新机器使用安装软盘启动，该软盘从网络、CD 或 Zip 驱动器挂载根文件系统。引导过程运行一个特殊的 install 组件，该组件通过解释机器的 install 资源来确定所有必要的安装时参数。新系统上安装了一个非常小的模板，并且使用 update 组件来加载初始 RPM 集。

这支持全新机器的完全无人值守构建，以及现有机器的重建。如果对系统的完整性有任何疑问，我们通常只需从头开始重建它。

开放、轻量级框架的概念非常重要；许多人贡献了组件，因此我们机器之间几乎所有不同的东西现在都由 LCFG 处理。这使得该系统非常成功；但是，许多实现仍然基于最初打算作为临时的技术。我们目前计划将 LCFG 的使用扩展到我们自己的部门之外，这正在推动某些子系统的重新设计，尽管基本架构将保持不变

愿望清单上的其他项目包括便携机的缓存支持和资源的安全签名。

资源

致谢