介绍用于系统管理的 cfengine

editfiles:

 development::

  { /etc/sudoers

    DeleteLinesContaining "cpa "

  }

 accounting::

  { /etc/sudoers

    SetLine "cpa ALL=(ALL) ALL"

    AppendIfNoLineMatching "cpa .*"

  }

在清单 2 中，我们看到当用户“cpa”从 Development 部门移到 Accounting 部门时发生的情况。必需取消他对 Development 机器的 sudo 访问权， 同时他需要对 Accounting 机器的 sudo 访问权。我们使用您应该已在 AddInstallable() 下的 control: 节中声明的机器类。根据机器类，采取适当的操作。请注意，名为“cpa1”的用户在这些规则中不会出现问题， 因为在“a”的后面我们明确地请求了一个空格。

另一个简单的通用用法是复制文档。在清单 1 中的框架示例中，我们看到配置 sshd 的 copy: 和 links: 节，他们是干什么的呢？

copy:

# set up the sshd startup script

  /etc/cfengine/sshd dest=/etc/init.d/sshd repository=/etc/cfengine/repository

links:

 any::

# link the sshd init.d script to /etc/rc3.d

  /etc/rc3.d/S72local_sshd ->! /etc/init.d/sshd

在我们的站点上，在运行 cfengine 之前，我们使用一个中央可信位置来执行 rsync /etc/cfengine。也就是说，/etc/cfengine 是我们要使用的可信文档的本地副本。/etc/cfengine/sshd 是其中一个文档，他是 SSH 守护程式的启动脚本。然后，假如可信的启动脚本和 /etc/init.d 中的脚本不同，则 copy: 节会将该脚本复制到该目录中。 这样，恶意的攻击者将看到他的更改不见了（我们以这种方式维护大多数 /etc/init.d 脚本）。同样，能够用“signalled pull”方法以这种方式方便地传播启动脚本中的更改。

copy: 的 repository 选项只是告诉 cfengine 放置旧 sshd 脚本的位置（假如必须覆盖他）。该选项是防止意外事件发生的可靠保障。

links: 节产生到正确启动目录的链接。请注意这是 Solaris 或 System V 启动层次结构。Linux 的等价启动层次结构将在 solaris::/linux:: 类部分中处理，但是这一代码片段使用简单的方法来使示例更简单。惊叹号（!）是可选的，他表示是否应该覆盖现有的链接（从不覆盖现有文档）。

能够立即复制或链接整个目录的内容。 例如，能够一次将 /etc/cfengine/sbin 中的任何文档复制或链接到 /usr/local/sbin。仅产生必需的副本或链接。cfengine 允许 copy: 命令带远程复制选项，但这些复制是通过 cfd 完成的， 我发现由于 cfd 本身的问题，他们对于生产环境是不够的。预先运行 rsync 是 cfengine 1.6.3 及更低版本的较好选项。

高级用法：重新启动进程
最好用定期运行的 cfengine 子配置来处理进程，他通常存储在 /etc/cfengine/cf.minute 或相似的文档中。 使 cf.minute 包含 cfengine.conf 使用的相同 cf.groups 组定义，并用 cfengine -f /etc/cfengine/cf.minute 调用他。

下面的示例演示如何重新启动进程或向他们发信号。

processes:

 any::

# restart cfd if it's not running already

  "/usr/local/sbin/cfd" restart "/etc/init.d/start-cfd start"

# restart sshd if it's not running already

  "/usr/local/sbin/sshd" restart "/etc/init.d/sshd start"

# HUP inetd if the HupInetd class is defined, see listing 1

 inetd.HupInetd::

  "inetd" signal=hup

cfd 是 cfengine 守护程式。尽管频繁地重新启动，但经过证实他相当不稳定， 这就是我使用版本 1.6.3 时抛弃他的原因。2.0 和更新版本的守护程式应该会更好。

象任何电脑软件相同，作为一个组的守护程式软件会经历各种各样实现。 对于 cfengine 而言， 有两种类型的守护程式：使用 fork 和 exit 的守护程式（inetd、sshd 和 cfd 是这种类型的最好示例）， 和不使用 fork 和 exit 的守护程式（例如，qmail 启动守护程式）。

我个人相信守护程式应该有可选的任一行为，所以我们不会有两种类型完全不同的程式要监控。但现在他不是大多数守护程式的选项，所以我们不得不应付他。

对于使用 fork 和 exit 的守护程式，cfengine 运行得很顺利。守护程式创建子进程，而 cfengine 继续其愉快的“旅程”。然而，对于不创建子进程的守护程式（并且这包括大多数内部守护程式软件），cfengine 需要特别帮助。在版本 2.0 中，应该以某种方式解决这一问题， 但在版本 1.6.3 中，软件必须打印出后跟回车的“cfengine-die”， 以便让 cfengine 知道保留他是安全的。还能够用类似由 Dan Bernstein 研发的 daemontools（请参阅 参考资料）软件来监控不创建子进程的守护程式，但这本身就是一种冒险。通常更加容易的方法是： 将 print