第一部分
准备篇
Puppet可谓是配置管理工具中的旗舰产品，有别于chef等其他配置管理工具，它可以让系统管理员的工作变得更轻松，从而提升工作效率，并且只需要维护简单的关系就能掌握一切。使用Puppet，我们可以实现从系统安装、配置管理、系统监控地一体化、流水线化、产品化。通过简单的后台系统我们就可以完成所有的动作，并且能查看机器的进度与当前状态。是不是觉得这项工作非常让人振奋呢？那就让我们一起探究Puppet的奥秘吧！
本篇主要是为了更好地为学习和使用Puppet做好准备。我们通过第1章来了解Puppet，看看它的发展历程，重点掌握它的工作原理；通过第2章对安装配置Puppet的讲解进一步加深对工作原理的理解；通过第3章的实例创建一个属于自己的配置，进而掌握基本的配置方法；最后通过第4章学习Puppet的几种工作环境，使我们以后能够更好地利用Puppet实现不同环境的配置管理。
第1章 认识Puppet
本章首先介绍什么是Puppet，为什么它具有这么优秀的特征，以及它的发展历程。随后将Puppet和当前主流开源配置管理工具进行对比，阐述为什么要使用Puppet。了解Puppet的组织结构并掌握Puppet的工作原理，这是本章的重点，希望读者多次阅读这部分内容，以便完全理解。Puppet最新版本为3.0，不同版本之间新的特性及是否可以混合使用，以及配置文件的详解，这些都是本章将要介绍的内容。
1.1 Puppet的起源与发展现状
1.1.1 什么是Puppet
官方的定义是这样的：Puppet是一个开源的新一代的集中化配置管理工具，它由自己所声明的语言表达系统配置，通过客户端与服务端之间的连接，维护着关系库。Puppet的设计目标是：让Puppet具有一个由富有表现力的语言支撑的足够强大的库。这样只需要编写短短的几行自动化应用程序即可实现设计目标。并且Puppet是开放的，允许添加任何新的功能。
通常认为：Puppet是一个跨平台的集中化配置管理系统，它使用自有的描述语言，可管理配置文件、用户、Cron、软件包，系统服务等，Puppet把这些统称为“资源”。Puppet的设计目标就是简化对这些资源的管理以及妥善处理资源之间的依赖关系。
Puppet是基于Ruby语言（http://www.ruby-lang.org/）并使用Apache协议授权的开源软件（在Puppet2.7.0与Facter1.6.0之前是基于GPLv2协议授权的），它既能以客户端-服务端（C/S）的方式运行，也能独立运行。客户端默认30分钟会与服务端确认一次更新，以确保配置的一致性。
1.1.2 Puppet起源与发展
Puppet主要由Luke Kanies和它的公司Puppet Labs开发，于2005年正式面世。Luke Kanies于1997年就涉足UNIX和系统管理，由于平常需要进行大量的开发工作，在试用当时的配置管理软件不满意后，他想开发一套工具来管理资源。他认为实现的关键是如何使每个资源成为一个合集，每个资源又有自己的行为，并且产生相应的行为动作。在Luke Kanies的努力下才有了今天出色的Puppet产品，当然也感谢Ruby语言。
Puppet于2005年面世，至今7个年头，发行版本也由0.2到3.0。Puppet Labs的目标不只是把它当做配置工具，而是当作“拯救世界”的工具。特别是在近几年的发展势头迅猛。Puppet Labs 2011年11月份共融资1600万美元，加上商业软件Puppet Enterprise的发布，Mcollective软件的收购，版本更新也更加迅速，但Puppet Labs的目标不只是让版本发行更迅速，而是极大的提升性能。我们可以看到2.7较之前版本在编译性能上60%以上的提升、3.0版本对Ruby1.9的完美支持、Master在CPU消耗上6倍的性能提升、更多发行版操作系统的支持。特别是在2012年5月率先与OpenStack的整合，振奋人心。我们可以看到Puppet Labs的前景不可估量。
Puppet从0.25.x直接跳到大版本2.6并且逐渐不再维护0.25.x，在2010年时采用Yum安装Puppet的还是0.25.x版本。有人会问2.6就比0.25.x性能好吗？其实不然，2.6主要是在功能上的改进，为此Puppetlabs改变了版本命令方式，增加了新的特性与取消XML-RPC传输层，除此之外没有其他大的改动。因此我们可以理解为只是命令方式的变更。
虽然目前Puppet在短短2年内由2.6发展至3.0，从3.0.0版本开始，Puppet使用严格的3段版本号，最左边为大版本并向后兼容，中间为新功能变化，最右为修复bug。伴随着版本的更新官方文档也在快速更新当中，这为我们学习提供了很大的便捷，也增强了我们掌握Puppet的信心。
由于Puppet 0.2x支持的特性非常少，不建议再安装使用。对于正在使用的用户，建议升级成最新版。对于新安装使用的用户，建议直接安装Puppet 3.0版本。对于正在在使用Puppet 2.6或2.7的用户，建设逐步升级且先升级，然后再升级Agent，平滑过渡，以避免遇到不可预知的问题。
提示
更多Puppet版本信息可参考：http://projects.puppetlabs.com/projects/1/wiki/Release_Notes。
1.1.3 版本语言特征
Puppet各版本之间的语言也存在着差异，当然，版本越高，支持的特征越多。具体见表1-1所示。
表1-1 Puppet各版本语言特征差异对比
1.1.4 命令差异
Puppet命令在2.6版本发布时进行了变更，且在发布3.0版本时将2.6版本之前的旧命令完全丢弃。具体差异对比如表1-2所示。
表1-2 Puppet命令差异对比
1.1.5 Puppet 3.0新特性
目前Puppet最新版为3.0，其中增添了许多新特性。
□ 性能提升：目录编译采用JSON作为目录缓存。
□ 增强操作系统与平台支持：Ruby1.9的完美支持，操作系统Windows、Solaris包和服务的更多支持，Yumrepo对ssl的支持。
□ 使用Rubygems加载插件：可以通过Rubygems来安装和使用Puppet的扩展代码。
□ Server自动发现：通过DNS SRV寻找CA、Master、Report和Fileserver。
□ DSL/config变化：auth.conf增加allow_ip配置选项，unless支持，插件同步默认改为True，更新configure的语法。
□ 其他BUG的修复：3.0Agent与2.7Master工作的问题，kick无法工作，rack安装启动出错等。
注意
Puppet 3.0将不再支持Ruby 1.8.5以下版本。
1.2 为什么要使用Puppet
1.2.1 都有谁在使用Puppet
在笔者编写本书时，Puppet目前已有拥有250家客户，包括Zynga、Twitter、纽约证券交易所、迪斯尼、Citrix、Oracle/Sun、Constant Contact、Match.com、Shopzilla、Google、RedHat等。国内越来越多大公司也在采用，例如，新浪、阿里巴巴、豆瓣、好乐买、趣游、PPTV等。
1.2.2 常见集中化管理工具对比
目前开源的工具非常多，很多人在选择的时候犹豫不定，不知道那个好。如果担心在使用过程中遇到问题没有人回答，资料太少而无从查起，那么就选择当前最流行的工具。现在毫无疑问应该选Puppet。
针对当前开源的配置管理工具，这里进行简单的汇总：Puppet，Chef，Func，Fabric，Capistrano，Cfengine等。就最常用的Puppet与Chef进行简单对比，主要是从用户、开发、平台、实例等几个角度出发，从中发现Puppet的优势。在使用用户上与第三方支持方面，Puppet更胜于Chef。详细对比如表格1-3所示。
表1-3 Puppet和Chef对比
提示
Puppet所支持的操作系统：http://docs.puppetlabs.com/guides/platforms.html
Chef所支持的操作系统：http://wiki.opscode.com/display/chef/Installing+Chef+Server Chef
使用者：http://www.opscode.com/customers/Puppet
使用者：http://projects.puppetlabs.com/projects/1/wiki/Whos_Using_Puppet
1.2.3 推荐Puppet的理由
有很多人问笔者：学习Puppet是否需要开发基础？需要会Ruby吗？笔者的回答都是“不需要”。其实我们使用任何一个工具，都不需要掌握此工具所采用的语言，只要会使用工具即可。如何更深入地理解工具的特性，最大化地发挥出它的优势才是我们的首要任务，除非想在它的基础上做二次开发。通常做二次开发都有现成的框架，调用工具的API接口即可完成。因此我们也不需要掌握这类语言的开发。而且开发类语言都互通的，掌握一门，其他的学起来也不难。初学者在入门时一定要意识到这一点：明确自己的目的，而不要被工具本身所吓住了，"Just Do It"。
1.3 Puppet作用和特色
1.3.1 为什么要有自己的语言
为什么不使用XML or YAML配置格式？为什么不直接采用Ruby输出？Puppet开发者非常巧妙用一个比喻回答了这个问题：在使用浏览器访问网站的时候为什么不直接读HTML呢？所以说Puppet使用自有语言是为了更好地处理人机接口。而Ruby输出实际上在Puppet2.6版本中已经支持，只是没有当做主输出而已。管理员可以进行自定义等相关操作。
1.3.2 为什么是Ruby
用Kanies的话来说，Ruby太适合Puppet了。最开始Kanies的大量工作都是使用Perl语言来完成的，然而当他想要开发工具时，发现在Perl中得不到想要的类关系。于是试用了一下Python，虽然很多人都说它非常棒，但也满足不了需求。这时有人说Ruby很酷，Kanies进行了尝试，没想到四个小时就做出了原型。为此直到后来为Puppet Labs选择语言时，Kanies一直也没有后悔选择了Ruby。因此选择适合自己的语言才是硬道理。我们不能一味的追求时尚，就像我们选择Puppet一样。
1.3.3 管理任何机器
目前Puppet支持所有的客户端，主流的有：RedHat、Centos、Gentoo、FreeBSD、Debian、OpenBSD、Mac os x、Ubuntu、SuSE、Solaris、Windows等。不需要担心所管理的设备无法使用Puppet，它已经尽可能地支持一切操作系统。不过使用Windows的朋友需要注意：目前Puppet所支持的资源有：File、Package、Host、Group、Service、Exec，支持的类型有限，不过刚刚发布的Puppet3.0对Windows的支持进行了加强。
提示
更多信息可参考：http://docs.puppetlabs.com/windows/writing.html。
处理资源与资源之间的依赖关系是Puppet的优势。Puppet管理一台主机的整个生命周期为：初始化安装、升级、维护、服务迁移及下载。在Puppet世界中，一台主机的每个生命周期内的每个动作被抽象成一个“资源”。我们更多的是要维护一台主机上的每个“资源”，梳理好关系后交给Puppet维护。对于系统管理员而言，一切的配置将变得简单而有趣。后续我们将在第6章来讲Puppet的资源。
1.4 Puppet组织结构
在了解了什么是Puppet后我们再来看下它的组织结构，以便在后续章节中能更好地掌握其工作原理。
通常在安装好Puppet之后的/etc/puppet目录下运行tree就能看到下面的树结构：
|-- auth.conf #ACL权限控制文件 |-- fileserver.conf #文件服务配置文件 |-- manifests #节点存储目录（Puppet会首先加载site.pp） | `-- site.pp #定义Puppet变量和默认配置 |-- modules #模块配置目录 | `-- nginx #以Nginx为例 | |-- manifests | | `-- init.pp #模块主配置文件，定义类class相关信息。读取模块后先读取它 | `-- templates | `-- nginx.conf.erb #模板配置文件(erb为主) |-- namespaceauth.conf #命名空间配置文件（配置权限） |-- puppet.conf #Puppet主配置文件 `-- tagmail.conf #邮件报告配置文件
注意
不同安装包的树结构会不一样，为了便于读者理解，这里列举主要的配置文件进行说明。
1.5 Puppet工作原理
下面进入本章重点：Puppet工作原理，将分别从基础结构，Puppet是如何工作的，数据流，文件结构，详细交互过程等几方面循序渐进地学习，以便读者理解并掌握。
1.5.1 Puppet基本结构
我们先看一下Puppet基本结构，如图1-1所示。Puppet模块的配置主要是配置文件、应用程序及系统底层相关。配置完成后发送给报告系统，见图1-1右上角。
图1-1 Puppet基本结构
1.5.2 Puppet是如何工作的
接着我们来看一下Puppet是如何工作的。简单来说分4步进行。
图1-2 Puppet工作过程
1）定义：使用Puppet特定的语言定义基础配置信息。通常我们把这些信息写在Modules中。
2）模拟：在配置执行之前检测代码。并不真正执行。
3）执行：按1）步定义的配置自动部署。检测并记录下所发生变化的部分。
4）报告：将期待的变化与实际发生的变化及任何修改发送给报告系统。
整个工作过程如图1-2所示。
1.5.3 Puppet数据流
在了解了Puppet如何工作之后我们需要了解它的数据流走向。
1）Node节点将Facts和本机信息发送给Master。
2）Master告诉Note节点应该如何配置，将这些信息写入catalog后传给Node。
3）Node节点在本机进行代码解析验证并执行，将结果反馈给Master。
4）Master通过API将数据发给分析工具。报告完全可以通过开放API或与其他系统集成。
整个数据流的走向是基于ssl安全协议的，如图1-3所示。
图1-3 Puppet数据流
1.5.4 文件结合
在Puppet组织结构中我们了解了Puppet的树结构。那么结合数据流，这些目录的关系是如何关联起来的呢？
1）Puppet通过编译Manifest中的内容，将编译好的代码存入catelog。
2）在执行前先进行代码的验证，再执行，完成最开始所定义好的状态。
代码编译过程如图1-4所示。
图1-4 文件编译过程
1.5.5 详细交互过程
通过以上的学习，相信大家对Puppet的工作原理有了基本的了解，接下来我们将分析Puppet的Agent 与Master的详细交互过程。通过学习这部分内容，大家可加深对Puppet的理解，以便在今后的使用过程中遇到任何问题都能在大脑里呈现如图1-5所示的内容，进而能快速定位故障并解决它。所有交互过程都是建立在签发证书的前提下执行的。
1）Puppet客户端Agent将节点名与facts信息发送给Master。
2）Puppet服务端Master通过分类判断请求的客户端是谁，它将要做什么。这个判断是通过site.pp里面包含的Node.pp配置文件定义的。
3）Puppet服务端Master将所需要的Class类信息进行编译后存入catalog并发送给Puppet客户端Agent，到此完成第一次交互。这一步是1.5.4小节的内容。
4）Puppet客户端Agent对catalog进行代码验证（语法检查及错误检查）并执行。主要是代码的验证，并将执行过程的信息及结果写入日志。
5）Puppet客户端Agent最终达到最开始所定义的状态，并且将结果及任何执行数据通过开放API的形式发送给Puppet服务端Master。
Puppet Master和Puppet Agent的交互过程如图1-5所示。
图1-5 Puppet Master与Puppet Agent详细交互过程
1.5.6 安全与认证
Puppet通信都采用ssl安全加密协议，以保障所有数据传输的安全性，为此我们不用担心数据的安全性问题。通常我们使用Puppet管理设备时也有可能建立在公司内网的基础之上，这样就更加安全了。当然，如果你所在的公司没有属于自己的内网也没有关系。Puppet所采用的SSL安全加密协议已经为我们解决了数据传输的安全问题。
提示
SSL（Secure Sockets Layer，安全套接层）及其继任者TLS（Transport Layer Security，传输层安全）是为网络通信提供安全及数据完整性的一种安全协议。TLS与SSL在传输层对网络连接进行加密。
在学习了Puppet安全之后，我们来学习下Puppet的认证。由于Puppet采用的是SSL加密协议，因此申请证书验证是必须的。
□ Puppet Master在启动后会给自己签发证书和key。我们可以在var/puppet/ssl（3.1版本在/var/lib/puppet/ssl/下面）目录下看得到它们。
□ Puppet Agent在运行puppet apply--test时添加参数（--verbose）可以在客户端终端看到申请证书的详细过程。
□ Puppet Master同样也可以使用puppet cert list查看到申请证书的客户端列表。使用命令puppet cert signagent_name来签发证书。
□ Puppet Agent就可以收到notice：Finished等相关字样。如果Master一直不签发证书，客户端会每2分钟请求一次。
证书相关的命令将会在第5章时详细讲解。
Puppet只允许经过安全认证的客户端请求，这极大地保证了数据的安全。同时当客户端发起https：//master.domain.com：8140/｛environment｝/｛resource｝/｛key｝这样的请求时，我们需要配置auth.conf与namespaceauth.conf。有关于这两个配置文件的详解参考1.7节。
思考
当客户端要输出“Hello World！”时，整个Puppet的数据流走向？
1.6 Puppet核心配置文件详解
在学习Puppet原理及版本差异后，我们需要掌握他的核心配置文件。Puppet所有的配置都围绕着Puppet.conf展开。读者可以回顾下在1.4节讲的组织结构，以便快速掌握本节内容。
1.6.1 主配置文件puppet.conf
主配置文件puppet.conf主要用于设置相关的参数，认证文件，文件系统配置文件，插件配置等。Puppet版本不同，配置选项命令方式也有所不同。Puppet2.6以前的命名方式还以〔puppetmaster〕，〔puppetagent〕为主。Puppet 2.6以后都以〔main〕，〔master〕，〔agent〕为主。为了防止读者混淆，建议都采用Puppet 2.6以上版本。本书都以Puppet 2.6以上版本为主。
先看如何生成Puppet配置文件puppet.conf：
puppetd --genconfig> /etc/puppet/puppet.conf puppetmasterd--genconfig> /etc/puppet/puppet.conf
以上命令会覆盖原文件。
在本地查看配置参考手册：
puppet doc --reference configuration
如果不知道配置文件在哪个目录下，可以使用以下命令查看：
puppet agent --configprint confdir
默认目录是/etc/puppet。
由于puppet.conf配置文件内容较多，下面笔者将列举核心配置、常用配置选项（不区分Master与Agent）：
[main] #通用配置选项
vardir = /var/lib/puppet
confdir = /etc/puppet
logdir = /var/log/puppet
rundir = /var/run/puppet
ssldir = $vardir/ssl
fileserverconfig = /etc/puppet/fileserver.conf
manifestdir = /etc/puppet/manifests #可不指定默认读取此目录
manifest = /etc/puppet/manifests/site.pp #主机文件默认读取
modulepath = /etc/puppet/modules:/usr/share/puppet/modules
authconfig = /etc/puppet/namespaceauth.conf
#如果开启Listen为true需要配置此文件
pluginsync = true #插件同步配置对facter自定义有效
reportdir = /var/lib/puppet/reports
#报告文件生成目录，目录以主机名命令开头
reports = log, foreman #报告的方式与类型
# environment = production 运行环境配置，默认为生产环境
[agent] #客户端配置选项
classfile = $vardir/classes.txt
localconfig = $vardir/localconfig
runinterval = 1800 #客户端默认探测时间，可按需求修改
listen = true #是否监听，执行puppet kick时需要配置
report = true #客户端的报告系统配置，不同于Master
#此项的主要目的是将报告发送至Master，主要用于客户端puppet.conf配置
report_port = 8140 #监听端口，如果服务器配置有防火墙，需开放此端口
report_server = server #默认不填，此时以下面的$server变量值为准
server = server.domain.com
[master] #服务端配置选项
certname = server.domain.com #也可以不定义，以主机名为准
reports = store, http, tagmail, log
reporturl = http://server.domain.com:3000/reports/upload
#报告发送地址，可配置在dashboard或foreman配置文件中
#有关报告系统的配置我们将在第17章讲解
autosign = /etc/puppet/autosign.conf #自动认证配置文件
提示
不同版本的配置文件可参考：http://docs.puppetlabs.com/references/。
通常我们应该如何配置主配置文件呢？下面分别进行介绍：
PuppetMaster服务器端主配置文件——puppet.conf。
[main] #全局配置
#vardir用来存放缓存数据、配置、客户端传回的报告及文件备份
vardir = /var/lib/puppet
# Puppet日志文件配置目录默认为'$vardir/log'
logdir = /var/log/puppet
#PID文件目录，默认为'$vardir/run'
rundir = /var/run/puppet
#SSL签发认证文件目录，默认为 '$confdir/ssl'
ssldir = $vardir/ssl
[master] #服务器端配置
pluginsync = true #开启插件同步
reports = log, foreman #报告发送至log和foreman
environment = production #指定运行环境为生产环境
certname = server.domain.com #配置主机名为server.domain.com
Puppet Agent客户端主配置文件——puppet.conf
[main]
logdir = /var/log/puppet
rundir = /var/run/puppet
ssldir = $vardir/ssl
pluginsync = true
[agent] #客户端配置
#关联与检索配置文件目录，默认为 '$confdir/classes.txt'，也可以使用
#(--loadclasses)参数指定
classfile = $vardir/classes.txt
#本地缓存配置目录，默认为'$confdir/localconfig'
localconfig = $vardir/localconfig
runinterval = 1800 #检测时长1800秒，30分钟
listen = true #监听进程
report = true #发送报告
server = puppet.domain.com #指定Master地址
1.6.2 主机配置文件site.pp
site.pp的目的主要是告诉Puppet去哪里寻找并载入所有主机相关的配置，默认存放在/etc/puppet/manifests目录中。通常我们在会此文件中定义一些全局变量。
注意
“清单”（Manifests）是Puppet中的术语，指的是包含配置信息的文件。清单文件的后缀是.pp。
生成Puppet主机配置文件site.pp：
puppet apply --genmanifest> /etc/puppet/manifests/site.pp
通常不使用以上命令生成的site.pp配置，主要填写的内容为：
# site.pp - all agent configure
Exec { path => "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" }
#设置环境变量
$fileserver = "puppet.domain.com" #指定全局fileserver变量
$ntpserver = "ntp.domain.com" #指定ntpserver变量
#建议读者动手配置以上内容
Package { provider => "yum" } #指定软件包的安装方法为yum
#可以直接写节点配置文件，在所有Agent上创建其内容为"Hello World"的
#/tmp/temp1.txt文件
#node default {
# file { "/tmp/temp1.txt": content => "Hello World!"; }
# }
import "modules.pp" #加载模块配置文件，可以不配置
import "nodes/*.pp" #加载主机信息，可以使用通配符，也可以定义多组目录
import "test.domain.com.pp" #加载测试主机
1.6.3 认证与安全配置文件
Namespaceauth.conf文件的目的是：可以指定允许谁访问每个名称空间。要创建Namespaceauth.conf文件必须添加对每个名称空间的访问权限。以下就是针对不同名称空间的权限配置，通常不用做大的变动。
以下是配置的内容：
[fileserver] allow *.domain.com [puppetmaster] allow *.domain.com [puppetrunner] allow culain.domain.com [puppetbucket] allow *.domain.com [puppetreports] allow *.domain.com [resource] allow server.domain.com
注意
当puppet.conf配置Listen=true时必须要配置此文件，否则Puppet启动时会报出"Will not start without authorization file/etc/puppet/namespaceauth.conf"的错误提示。
auth.conf认证配置文件是Puppet中的ACL，主要应用于Puppet's REST API。例如客户端请求https://yourpuppetmaster:8140/{environment}/{resource}/{key}时，服务器可以根据资源定义访问权限。其配置参考如下：
# 以auth.conf为例 path / auth any environment override allow magpie.example.com path /certificate_status auth any environment production allow magpie.example.com path /facts method save auth any allow magpie.example.com path /facts auth yes method find, search allow magpie.example.com, dashboard.example.com
只看上面auth.conf配置文件，读者可能难以理解配置文件的意义，参考Puppet ACL配置语法就容易理解了。其语法规则如下：
path [~] {/path/to/resource|regex} #目录配置
[environment {list of environments}] #环境配置
[method {list of methods}] #方法命令配置
[auth[enthicated] {yes|no|on|off|any}] #授权配置
[allow {hostname|certname|*}] #允许配置
我们再来看auth.conf的配置文件：
path /facts auth yes method find, search allow magpie.example.com, dashboard.example.com #现在就不难理解这段配置的意思了。允许主机名为"magpie.example.com"和 #"dashboard.example.comd的两台客户端在facts目录进行find和search操作
提示
详细信息可参考：http://docs.puppetlabs.com/guides/rest_auth_conf.html
1.6.4 客户端自动认证配置
autosign.conf允许配置文件中的客户端自动进行签名验证，省去人工交互的过程。这对自动化配置来说省去了很多工作。下一章在介绍安装时也会讲到。
配置文件参考如下：
#允许单一客户端或者域名匹配，主机名匹配 rebuilt.example.com *.scratch.example.com *.local
同时Puppet客户端的证书也可以采用提前在master上生成的方法，将生成的证书文件拷贝到客户端对应目录下实现自动认证的配置。
自动生成证书命令为：
puppet cert generate client.domain.com
这时将在本地生成client.domain.com客户端证书文件，文件及其所在目录为：
/var/lib/puppet/ssl/private_keys/client.domain.com.pem /var/lib/puppet/ssl/certs/client.domain.com.pem /var/lib/puppet/ssl/certs/ca.pem
将这些文件复制到客户端相同的目录下即可。
1.6.5 报告系统配置
tagmail.conf将配置的报告内容按要求发送给谁。要使用此项功能，需要在Puppet Master端配置：reports=tagmail，需要在Puppet Agent端配置report=true，同时也可以配置smtp由谁来发送。在Puppet Master端配置reportform为smtpserver or sendmail即可。默认由本机sendmail发送。
all: log-archive@example.com webserver, !mailserver: httpadmins@example.com emerg, crit: james@example.com, zach@example.com, ben@example.com #日志的级别可以是：debug、info、notice、warning、err、alert、emerg、crit或者 verbose #也可以是一个类的名字class names，一个标签名tags
1.6.6 文件系统配置文件
fileserver.conf是一项安全配置，结合puppet.confauth.conf一起使用。针对那个目录，哪些客户端允许访问，哪些禁止访问。fileserver.conf的使用非常灵活，后续将在第16章节来讲解它的优化及配置。
# 配置方法 [mount_point] path /path/to/files allow *.example.com deny *.wireless.example.com #举例：允许通配主机为"*.domain.com"的主机获取/etc/puppet/files目录下 #的文件。以下为其配置方法 [files] path /etc/puppet/files allow *.domain.com
1.7 本章小结
通过本章的学习，我们了解到Puppet的发展历程，各版本存在的差异，Puppet2.6版本的大幅度变动，Puppet3.0版本的最新特征。接着通过学习Puppet组织结构，Puppet的工作原理，核心配置文件的相关知识，使读者能够熟练掌握Puppet的基本用法和工作原理。
如果你没有了解过Puppet，通过本章我们能大致了解Puppet是什么，它有什么用途，是否适合在你的环境当中使用。如果你用过Puppet并有使用经验，通过本章的学习能够更深入地掌握它的原理。
将Puppet原理及核心信息放在第1章来讲解，是为了让大家能更全面的了解Puppet，毕竟任何一款软件的使用都离不开基础原理的掌握。
接下来一章将介绍Puppet在不同操作系统平台的安装与使用。