作者：刘宇
出版社：机械工业出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
Puppet实战试读：
前言
为什么要写这本书
子曰：“工欲善其事，必先利其器。”作为系统管理员，最应该具备的一种技能就是利用各种优秀开源软件快速完成自己的工作，让自己变得更轻松。但并不是所有的软件都适合你，你需要根据自己的环境及需求进行选择。
Puppet就是系统管理员的一把利器。几年前我开始学习Puppet的时候，不少朋友都问我：为什么选择Puppet？它有什么优势？当时pssh、CFEngine等都已经很成熟，并且也能帮助系统管理员有效地解决繁重的工作。为什么还要选择Puppet？“需求决定产品”。Luke Kanies（Puppet作者，以下简称Luke）曾经全面参与了重写CFEngine的解析器和开发ISConf3的工作，但是他还是觉得现有的工具已经无法满足他的工作需求，需要自己创造一个全新的工具，才能彻底使他的工作更加高效、便捷。这便是Puppet诞生的背景和原因。
Puppet注重设计简洁、先框架后应用两个中心思想。这也造就了Puppet今日的成功，它的“三板斧”——资源、类、模板，可以轻松地帮我们完成复杂的业务逻辑关系管理。同时，Puppet并不具备执行功能，因此在某些程度上存在短板，（比如exec是为解决特定系统管理员蹩脚的执行命令需求而开发的，但Luke一再强调不建议使用。）
或许更多的系统管理员抱怨Puppet没有命令执行功能。Luke早就考虑到了这一点，并提前收购了MCollective，采用消息型总线的中间件来实现命令执行、系统管理、Puppet客户端管理等，以弥补了Puppet在这方面的不足，可见Puppetlabs非常有远见。伴随着Puppet各子功能及扩展工具的遍地开花，Puppet的商业化及各种开源社区的支持，Puppet可谓是蒸蒸日上。
在新兴的同类工具中，我的另一个关注点是SaltStack，它天生具备命令执行和配置管理两大核心功能，相比Puppet来说有一定优势，但SaltStack的成长还需要我们耐心等待。Puppet打败1993年“出生”的老牌系统配置管理工具CFEngine就花费了近7年时间。而Puppet与Salt Stack真正鹿死谁手，我们拭目以待。相信以后的市场竞争会越来越激烈。
为了让更多的系统管理员了解并深入学习Puppet，可以利用Puppet的集成方案解决系统管理复杂而繁重的任务，而不是盲目地寻找问题，我觉得有必要结合自己在学习Puppet过程中走过的弯路将工作中的经验和总结以实战形式呈现给大家。我也希望更多的人能加入开源社区，拥抱开源，拥抱变化，通过学习Puppet，体会到与开源爱好者交流的乐趣，而不是为了工具选型而犹豫甚至争斗。这也是我写作本书的初衷。
本书技术深入而阅读简单，涉及系统管理员所需的很多方面的基础知识，同时通过穿插各种实例及代码详解以便使读者能够快速掌握Puppet，并迅速将其运用到工作环境当中。通过这样一本以系统管理员为核心的书，希望能给读者带来的不只是技术能力提升，更多的是开源与奉献精神。也希望更多的系统管理员通过多阅读、多交流，建立起享受分享的技术氛围。
读者对象
根据本书内容定位，适合阅读本书的读者有：Puppet用户和爱好者UNIX与Linux系统管理员运维工程师
如何阅读本书
本书分为四大部分：
第一部分为准备篇（第1～4章），简单地介绍了Puppet的发展历程和相关理论，帮助读者了解一些基础背景知识，并快速搭建测试环境。
第二部分为基础篇（第5～10章），着重讲解Puppet的基础理论知识，包括语法、资源、类、模板、模块、节点、Facter、数组、函数、变量。结合不同实例让读者感觉理论知识不再那么枯燥。
第三部分为实战篇（第11～13章），从实战角度进行讲解，结合流行监控系统Nagios和Zabbix，包括最为热门的云计算OpenStack的部署，使读者能快速掌握Puppet并运用到实践中。
第四部分为进阶篇（第14～20章），通过对Puppet扩展模式、版本控制、报告系统、控制台、扩展工具及MCollective的综合讲解，让读者了解一个完整的Puppet生产流程。
其中第三部分以实战来讲解Puppet应用，相比于前两部分更加复杂。如果你是一名经验丰富的资深用户，能够理解Puppet的相关基础知识和工作原理，那么你可以直接阅读这部分内容。但是如果你是一名初学者，请一定从第1章的基础理论知识开始学习。
勘误和支持
由于作者的水平有限，加之编写时间仓促，书中难免会出现一些错误或者不准确的地方，恳请读者批评指正。为此，我特意在博客（http://liuyu.github.io）的基础上开辟了在线支持与应急方案的站点http://puppet.bubbyroom.com。你可以将书中的错误以及遇到的有关Puppet的任何问题，通过访问该站点的Q&A页面提交给我。书中的全[1]部源文件除可以从华章网站下载外，还可以从这个站点下载。同时我也会将相应的功能更新在这个站点上及时发布出来。如果你有更多的宝贵意见，也欢迎发送邮件至邮箱liuyu105#gmail.com（sed's/#/@/g'），标题请注明《Puppet实战》，期待能够得到你们的真挚反馈。同样你也可以关注我为本书建立的微信公共平台（puppetchina），我会在此公共平台定期发布Puppet相关信息。
致谢
首先要感谢伟大的Puppet作者Luke Kanies，他开发了一款影响我整个人生的软件。
特别感谢刘长元、王广胜、吴问志、刘继伟、王哲，感谢你们对本书提出的宝贵修改意见。
感谢为本书撰写的童剑先生、窦哲先生、田逸先生、程辉先生，感谢你们在繁忙的工作中抽出时间，阅读了本书的样稿并写下推荐和评论。
感谢机械工业出版社华章公司的编辑杨福川，是你的引导才促使我完成这本书。特别感谢姜影编辑，在这一年多的时间中始终帮我校对并支持我的写作，你的鼓励和帮助引导我顺利完成全部书稿。
最后感谢我的笨笨，一如既往地支持我写作，给予我无尽的支持与灵感，并时时刻刻为我灌输着信心和力量！
谨以此书献给我即将出生的Baby，以及众多热爱Puppet的朋友们！刘宇（守住每一天）于中国北京[1]参见华章网站www.hzbook.com.——编辑注第一部分 准备篇
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 为什么要使用Puppet1.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_Puppet1.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 文件结合图1-4 文件编译过程
在Puppet组织结构中我们了解了Puppet的树结构。那么结合数据流，这些目录的关系是如何关联起来的呢？
1） Puppet通过编译Manifest中的内容，将编译好的代码存入catelog。
2） 在执行前先进行代码的验证，再执行，完成最开始所定义好的状态。
代码编译过程如图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用来存放缓存数据、配置、
客户端传回的报告及文件备份
试读结束[说明：试读内容隐藏了图片]