本文讲述一个很简易的利用虚拟机实现的c/s puppet master/agent实验环境，并给出一个简易的利用apache处理请求的实验环境。
关键词： puppet c/s master agent debian apache 虚拟机 virtualbox 桥接网络
注：此文可视为 翻译 总结 笔记。
实验准备：
首先利用virtualbox创建一个虚拟机，装好debian（配上开发工具，去掉图形界面）。在这里命名为svr。将此虚拟机clone出来，命名为cli。两台机的主机名分别为svr和cli，下文将用svr与cli指代此二虚拟机。
将两台机的网络接口设置为bridged adapter，这样很简易的让两台机互联并与主机处于同一网络。在/etc/hosts里写上别名。互相ping下看有没有联通。
备注：
1. 网络接口方式参考 p91
2. 如果操作后发现虚拟机中eth0网卡消失或者没有获取ip，可以 rm -rf /etc/udev 再重启。
3. 配置后效果图如下
包安装：
svr: aptitude install puppet puppetmaster facter apache libapache2-mod-passenger
cli: aptitude install puppet
备注：
debian的aptitude的确非常方便。但是出于部署的考虑，你可能不能这样安装，例如我极度不推荐用apt安装apache。这里是为了便捷搭建实验环境。
配置文件：
如果包安装这一步没有问题，puppet的配置文件应该会出现在/etc/puppet中。
分别修改两台虚拟机的puppet配置(/etc/puppet/puppet.conf).
svr: [master]域:
certname = svr.pp.com
cli: [agent]域:
server = svr.pp.com
certname = cli.pp.com
配置就这样完成了。此时就可以启动puppet了。
(先)svr: $puppet master --no-daemonize --verbose --debug --trace
(把能提示的都用上了)启动puppet master端服务。
(后)cli: $puppet agent --debug --no-daemonize --trace
启动puppet agent。
首次启动svr的puppet，会有如下提示：
包安装：
svr: aptitude install puppet puppetmaster facter apache libapache2-mod-passenger
cli: aptitude install puppet
备注：
debian的aptitude的确非常方便。但是出于部署的考虑，你可能不能这样安装，例如我极度不推荐用apt安装apache。这里是为了便捷搭建实验环境。
配置文件：
如果包安装这一步没有问题，puppet的配置文件应该会出现在/etc/puppet中。
分别修改两台虚拟机的puppet配置(/etc/puppet/puppet.conf).
svr: [master]域:
certname = svr.pp.com
cli: [agent]域:
server = svr.pp.com
certname = cli.pp.com
配置就这样完成了。此时就可以启动puppet了。
(先)svr: $puppet master --no-daemonize --verbose --debug --trace
(把能提示的都用上了)启动puppet master端服务。
(后)cli: $puppet agent --debug --no-daemonize --trace
启动puppet agent。
首次启动svr的puppet，会有如下提示：
在cli首次启动连接svr时，会有如下提示：
此时，svr会有如下提示，说明cli发送证书请求：
此时，在svr端：
svr:$puppetca --list
可以看到cli.pp.com的请求。
svr:$puppetca --sign cli.pp.com
处理后，处理再次请求，则提示，catalog编译发送成功。
至此，双虚拟机搭建的基本master/agent环境完成。
备注：
svr上需要对node做配置才能对cli起作用。这里我用了非常简单的一个示例：
master端利用apache提供服务(passenger方式) ( mainly from <<pro puppet>> )
目的: <from "pro puppet",详见原书>
As we scale Puppet up, it is important to draw the distinction between the idea of a front-end HTTP request handler and a back-end Puppet master worker process. The front-end request handler is responsible for accepting the TCP connection from the Puppet agent, selecting an appropriate back-end worker, routing the request to the worker, accepting the response and finally serving it back to the Puppet agent. This distinction between a front-end request handler and a back-end worker process is a common concept when scaling web services.
在这之前，master已经安装好了包(apache libapache2-mod-passenger)。因此只需要做master端的配置工作.
配置方法：
懒得翻译了。
注意：(非常重要)
书里面没有提到的是:master端配置必须有这两项：
[master]
ssl_client_header = SSL_CLIENT_S_DN
ssl_client_verify_header = SSL_CLIENT_VERIFY
官方文档解释如下：
ssl_client_header: The header containing an authenticated clientʼs SSL DN. Only used with Mongrel. This header must be set by the proxy to the authenticated clientʼs SSL DN (e.g., /CN=puppet.puppetlabs.com). Default: HTTP_X_CLIENT_DN
ssl_client_verify_header: The header containing the status message of the client verification. Only used with Mongrel. This header must be set by the proxy to ʻSUCCESSʼ if the client successfully authenticated, and anything else otherwise. Default: HTTP_X_CLIENT_VERIFY
参考：
而且,以上那个master,在书中紧随的那个例子中(proxy18040 18041),是不需要两个配置项的.
原因我认为是里面配置了SSL_CLIENT_S_DN, SSL_CLIENT_VERIFY.
The three RequestHeader lines statements configure the front-end load balancer to set three client request headers containing authentication information. When a back-end Puppet master virtual host receives a client request from the load balancer, it will inspect these client request headers and set environment variables based on their contents. The Puppet master process will look to these environment variables while authorizing the Puppet agent request.