简单用法：编辑和复制文件
要编辑文件，使用 editfiles 节。其语法相当复杂，但在我们的示例中将仅使用几条可能的命令。有关所有命令，请参阅 cfengine 参考大全（请参阅 参考资料）。
清单 2. 编辑文件
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: 节，它们是干什么的呢？
清单 3. 复制文件
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 调用它。
下面的示例演示如何重新启动进程或向它们发信号。
清单 4. 重新启动进程或向它们发信号
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 语句放到程序中，这样的临时修补不会影响任何其它东西。
结束语
本文简要地介绍了 cfengine 可做的事情。您应该自己尝试它，特别在浏览了 cfengine 参考大全之后，看看 cfengine 对您有什么样的帮助。
按照我的经验，除了 cfd 守护程序外，版本 1.6.3 非常稳定。 语法将转入下一个版本（2.0），可能会增加一些内容，所以您将要花时间去学习它。
cfengine 是一种独特的系统管理工具。即使您没有决定使用它，但其概念和执行将对您的工作产生帮助。如果您决定使用它，您将发现 cfengine 无限的灵活性和惊人的用处。
原文链接：http://www-128.ibm.com/developerworks/cn/linux/sdk/perl/culture-9/index.html
