PUPPET安装配置MCollective+ActiveMQ——详细指导

来源：互联网发布：mobi的域名含义编辑：程序博客网时间：2024/06/05 19:15

序：

整理了下以前的文档，主要基于3.7.5（适用于3.x系列），本篇深入介绍了安装Puppet后，如何部署MCollective+ActiveMQ，用于理论指导安装和排除错误需要。介绍的相对全面，若需跳过剖析，想直接上手安装，可以按照本博客中《PUPPET安装配置MCollective+ActiveMQ——实际部署案例》篇来部署。

Mcollective用于Puppet进行实时批量操作。MCollective弥补了Puppet自身笨重的特点，原先Puppet的agent是按一定的频率上报数据，在实时性和灵活性这块有所欠缺，3.x之前的版本用的是kick来实现，之后采用了MCollective。

如下是安装MCollective和相应插件后，示例的一些mco命令：

mco rpc service status service=ntpd -vmco puppet --tags test_module -I /agentxx/ runonce -vmco puppet -v runonce  -F 'fqdn=/node1.puppet.com|node2.puppet.com/'mco inventory -W "productname=/IBM|BladeCenter/" --script inventory.mcmco puppet runall 5 -F operatingsystem=CentOS -F operatingsystemrelease=6.4mco shell run "cat /tmp/fqdn.txt"etc..

部署步骤

一般是按照如下的顺序来部署MCollective

1. 创建和收集认证文件

2. 部署和配置中间件

3. 安装MCollective（所有的服务器和管理机上，即所有机器）

4. 配置servers

5. 配置clients

6. 部署插件

step 1. 创建和收集认证文件

开始前先理解以下概念
所有下面提到的server和client是针对要安装Mcollective的机器而言的，server指的是所有安装Mcollective软件的机器，即把所有的这个集体当成servers来看，而client指的是要操作这些servers的作为admin user的客户端，即客户端来连接amq来操作Mcollective服务端，跟平时理解的c/s架构不一样。这里的Mcollective没有中心。客户端指的是peadmin用户及console控制台这些要对Mcollective服务器进行操作的个体。admin user对应的即client，而这些admin users所在的机器即workstation

下列关于证书、密钥对的生成，即申请CA认证时的name只能是由字母、数字、句号和连接号组成。

1、Mcollective的交互视图

2、标准的部署的证书密钥对

Credential
Used By:
ActiveMQ username/password
Middleware, servers, clients
CA certificate
Middleware, servers, clients
Signed certificate and private key for ActiveMQ
Middleware
Signed certificate and private key for each server
Servers
Signed certificate and private key for each user
Clients (both parts), servers (certificate only)
Shared server public and private key
Servers (both parts), clients (public key only)

所有Mcollective节点，所有的credentials都是以.pem结尾格式的，在middleware上有些还是需要转换的
使用puppet自带的证书认证机构
了解这两个目录，实际路径会因操作系统不同而不同
$certdir 和$privatekeydir，使用命令得到确切路径
Agent节点：sudo puppet agent --configprint certdir,privatekeydir
CA Master节点：sudo puppet master --configprint certdir,privatekeydir

3、预备知识清单
(即部署之前需要预备的知识，后续操作会用到)
下列的已具备和未具备等状态都是针对安装完puppet以后来说的，如果未具备则后续需要去完成这些操作，已具备是说明在安装完puppet之后，条件已经具备了，不需要再操作。
清单
状态
操作
PASSWORD
未具备
想出一对用户/密码用来连接ActiveMQ，建议用户名为mcollective，密码需要是强密码。
例如：mcollective/Guosir@eu2015
CA
已具备
每一个节点已经都有了一份Puppet CA认证中心的证书，路径在$certdir/ca.pem，
文件都是一样的，在linux系统上路径就是：/var/lib/puppet/ssl/certs/ca.pem
ACTIVEMQ CERT
已具备
获取的方式有两种（如果不想用已有的，可以采用第二种方式）
1、使用ACTIVEMQ服务器上已有的puppet agent的证书，例如：
$certdir/puppetmaster.puppet.com.pem $privatekeydir/puppetmaster.puppet.com.pem
2、使用Puppet CA认证中心生成：在CA机器上，使用命令：
sudo puppet cert generate activemq.example.com
证书名称不能重复，生成后拷贝到ACTIVEMQ服务器上：
$certdir/<NAME>.pem
$privatekeydir/<NAME>.pem
SHARED SERVER KEYS
未具备
在Puppet CA认证中心，新生成证书和密钥，建议证书名称为mcollective-servers，使用命令：
sudo puppet cert generate mcollective-servers
取得证书和私钥：
$certdir/mcollective-servers.pem
$privatekeydir/mcollective-servers.pem
SERVER CERTS
已具备
所有的服务器节点都已经有了puppet agent的证书，直接使用即可
$certdir/<NAME>.pem
$privatekeydir/<NAME>.pem
CLIENT CERTS
未具备
需要通过Puppet CA中心创建证书，在CA机器上，使用命令：
sudo puppet cert generate <NAME>
生成如下证书和私钥
$certdir/<NAME>.pem
$privatekeydir/<NAME>.pem
取得上述证书和私钥后，删除CA上私钥副本

以下是加强对Mcollective-servers部分的理解：
puppet部署mcollective之所以搞了个mcollectiv-servers的证书密钥又搞client的证书密钥，看起来是多余的，但是当client多了以后，不同client间信息也是需要保密的，例如有peadmin用户的client，也有console的client，但是mcollective间通过amq交互时只要一种加密方式即可，所以需要这个mcollective-servers的证书和密钥！
其实关键在于多client的情况出现，即peadmin用户和console控制台等clients

部署状态：还未开始.

step 2. 部署和配置中间件

安装ActiveMQ 5.5以上版本，用puppet来管理会很容易。使用activemq.xml文件模板，以及java_ks资源来管理密钥库。
1、使用puppet官方的repo安装ActiveMQ
RHEL系列、Fedora的系统可以使用puppet的repo文件来安装ActiveMQ软件
例如：Enterprise Linux 6系列（RHEL），执行如下安装repo文件
$ sudo rpm -ivhhttps://yum.puppetlabs.com/puppetlabs-release-pc1-el-6.noarch.rpm
执行yum命令安装ActiveMQ软件
$ sudo yum install ActiveMQ

2、使用puppet官方的repo安装ActiveMQ
替换自带activemq.xml文件为模板文件
<beans xmlns="http://www.springframework.org/schema/beans" xmlns:amq="http://activemq.apache.org/schema/core" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd http://activemq.apache.org/schema/core http://activemq.apache.org/schema/core/activemq-core.xsd http://activemq.apache.org/camel/schema/spring http://activemq.apache.org/camel/schema/spring/camel-spring.xsd"> <bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer"> <property name="locations"> <value>file:${activemq.base}/conf/credentials.properties</value> </property> </bean>   <broker xmlns="http://activemq.apache.org/schema/core" brokerName="localhost" useJmx="true" schedulePeriodForDestinationPurge="60000">  <destinationPolicy> <policyMap> <policyEntries> <policyEntry topic=">" producerFlowControl="false"/> <policyEntry queue="*.reply.>" gcInactiveDestinations="true" inactiveTimoutBeforeGC="300000" /> </policyEntries> </policyMap> </destinationPolicy> <managementContext> <managementContext createConnector="false"/> </managementContext> <plugins> <statisticsBrokerPlugin/>  <simpleAuthenticationPlugin> <users> <authenticationUser username="mcollective" password="marionette" groups="mcollective,everyone"/> <authenticationUser username="admin" password="secret" groups="mcollective,admins,everyone"/> </users> </simpleAuthenticationPlugin>  <authorizationPlugin> <map> <authorizationMap> <authorizationEntries> <authorizationEntry queue=">" write="admins" read="admins" admin="admins" /> <authorizationEntry topic=">" write="admins" read="admins" admin="admins" /> <authorizationEntry topic="mcollective.>" write="mcollective" read="mcollective" admin="mcollective" /> <authorizationEntry queue="mcollective.>" write="mcollective" read="mcollective" admin="mcollective" />  <authorizationEntry topic="ActiveMQ.Advisory.>" read="everyone" write="everyone" admin="everyone"/> </authorizationEntries> </authorizationMap> </map> </authorizationPlugin> </plugins>  <systemUsage> <systemUsage> <memoryUsage> <memoryUsage limit="20 mb"/> </memoryUsage> <storeUsage> <storeUsage limit="1 gb" name="foo"/> </storeUsage> <tempUsage> <tempUsage limit="100 mb"/> </tempUsage> </systemUsage> </systemUsage>  <transportConnectors> <transportConnector name="openwire" uri="tcp://0.0.0.0:61616"/> <transportConnector name="stomp+nio" uri="stomp+nio://0.0.0.0:61613"/>  </transportConnectors> </broker>  <import resource="jetty.xml"/></beans>
3、修改admin user和mcollective user的密码
mcollective user的密码就是前面想的。（mcollective/Guosir@eu2015）

4、修改stomp传输连接的端口和协议
【额外知识】：STOMP，Streaming Text Orientated Message Protocol，是流文本定向消息协议，是一种为MOM(Message Oriented Middleware，面向消息的中间件)设计的简单文本协议。

修改activemq.xml文件中的stomp配置如下
stomp+nio+ssl://0.0.0.0:61614?needClientAuth=true&transport.enabledProtocols=TLSv1,TLSv1.1,TLSv1.2
如果ActiveMQ 5.9.x之前的版本，则修改如下：（因为stomp+nio+ssl在之前的版本有bugs）
stomp+ssl://0.0.0.0:61614?needClientAuth=true&transport.enabledProtocols=TLSv1,TLSv1.1,TLSv1.2

5、使用CA证书以及ActiveMQ证书/密钥对
ActiveMQ需要单独管理证书及密钥对的原因：
由于ActiveMQ运行在JVM上，配置使用TLS加密/认证需要一对java 密钥库，不能像puppet和mcollective那样使用正常的PEM格式的证书和密钥对。

根据ActiveMQ keystores guide指南（见下面表格中的详细步骤），来使用CA证书以及ActiveMQ证书/密钥对。
步骤一：取得证书和密钥对(三种方案可选，推荐第一种，不用操作，已具备，可参考Step 1)
A、重复使用puppet agent的认证
sudo puppet agent --configprint ssldir得到ssl目录后，将如下文件拷贝到一个工作目录下
<ssldir>/certs/ca.pem
<ssldir>/certs/<node name>.pem
<ssldir>/private_keys/<node name>.pem
B、使用puppet CA重新生成新的认证，前面有介绍，不再介绍
C、使用第三方CA认证机构生成新认证，不介绍
步骤二：创建密钥库(有手动和自动两种，下面只介绍自动的，即使用puppet的方式)
使用puppetlabs/java_ks module来实现格式转换，这个方法更适用于单一的不变的ActiveMQ服务器，对于多ActiveMQ服务器及后面要变更证书的情况未必适用。
A、安装java_ks模块，使用如下命令：
sudo puppet module install puppetlabs/java_ks
B、创建puppet class，class要完成如下功能
确保PEM证书和密钥对是存在和受保护的
声明一对java_ks资源
管理密钥库文件的权限及所属关系
例如：keystores.pp文件如下，可以直接使用，可依需要修改。
(其中的keystore_password起码是6位以上的字符串如’puppet’，其实就是资源java_ks中的password属性，用来保护keystone密钥库和解锁私钥用的。跟前面ActiveMQ的mcollective用户的密码没有什么关系，但是需要对应到下面步骤四中的sslContext的配置中的密码，即将secret改为puppet)
/etc/puppet/modules/activemq/manifests/keystores.pp
步骤三：分配class到ActiveMQ服务器(即让ActiveMQ服务器使用该class，略)
步骤四：完成，在ActiveMQ中配置SSLContext来使用密钥库(即在ActiveMQ文件中添加sslContext配置)
关于TLS传输，如果使用stomp传输协议，ActiveMQ服务器需要一个密钥库文件(keystore file)，一个档案文件(truststore file)，以及相应的密码
 <sslContext> <sslContext keyStore="keystore.jks" keyStorePassword="secret" trustStore="truststore.jks" trustStorePassword="secret" /> </sslContext>
上面是给CA-verified TLS的案例，如果使用的是anonymous TLS，可以忽略truststore那行，上面的<sslContext>格式是正常的，给ActiveMQ使用的，因某种原因需要这样配置。ActiveMQ将会在与activemq.xml文件同样的目录下找到这些文件。

此步骤即是将上述sslContext配置加入activemq.xml文件中，而后需要将该文件的权限置为只有所属用户可读。注意上面的keyStorePassword="secret"需要与keystores.pp中的keystore_password对应一致。并且两个.jks文件都要是具体路径，即/etc/activemq/keystore.jks和/etc/activemq/truststore.jks 。

注意：上面的keystores.pp文件要在master机器上运行puppet run生效以后，才能添加sslContext的配置，不然会导致后面重启ActiveMQ服务失败。

6、添加sslContext配置到activemq.xml文件
在activemq.xml文件中加入sslContext配置来使用上面创建的密钥库
（详细参照上第五点中的步骤四，ActiveMQ 5.5需要元素按字母排序，不然会有xml的bug）
后来证实，ActiveMQ 5.9.1也要放到broker节点里面的transportConnectors节点前面，不然会启动ActiveMQ失败。

7、启动或重启ActiveMQ服务
在activemq主目录键入如右命令： bin/activemq start

8、确保服务器的防火墙开通61614端口
(inbound traffic on port 61614)

备注：更多关于ActiveMQ的配置参考ActiveMQ config reference for MCollective users，这里面有很详尽的描述，主要是关于网络代理和过滤方面的。对于一个标准的部署来说，你只需要配置密码，以及配置TLS，即上面的配置已经足够了。

部署状态：中间件已经完全准备好了，但是还未被使用

Step 3: 安装MCollective

1、安装步骤概览

a. 安装mcollective 包到每个Mcollective服务器上
b. 安装mcollective-client包到管理终端上(admin workstations)
c. 如果没有适合你操作系统的官方版本包，可以从这里下载源码run from source
d. 确保安装的是同一版本的包

详细如下：
确保ActiveMQ中间件已安装并运行
确保防火墙已打通(上面配置的是端口61614)
安装mcollective包，并且mcollective服务能启动
安装mcollective-client到管理终端服务器上
大多数Debian类和Red Hat类系统可以安装使用puppet官方的repo，或者直接加你自己的repo文件中(如果是Debian/Ubuntu类的系统注意下要安装Stomp Gem包)
若系统无法使用官方repo安装mcollective，先检查下系统要求，并且使用自己的repo或者源码安装

2、安装前确认条件
A、服务器上Ruby版本要求
Mcollective可以运行在所有的*nix系统和windows系统上，需要以下Ruby版本之一。
1.9.3
1.8.7
Ruby 2版本官方还未正式支持，但是应该也能用，Ruby 1.8.5和Ruby 1.8.6不能使用TLS连接到中间件，不加密去连接是可以用。Ruby 1.9.0到1.9.2都不支持，会导致失败。

B、服务器上Stomp gem版本要求
对于Stomp rubygem的版本需求是1.2.2以上

C、中间件的部署要求
已安装ActiveMQ消息中间件，作为安装Mcollective的前提。

D、防火墙的开放要求
每台服务器的防火墙能够允许Mcollective初始化连接到ActiveMQ中间件所在的服务器，开放的端口是基于前面的配置，一般是61614端口，即基于stomp/TLS协议的，如果是未加密则是61613。基于我们前面的配置，所以需要开放的端口是61614。

3、使用puppet官方包安装
A、安装官方repo文件(前面已安装可忽略)
在安装ActiveMQ步骤中已安装，详细可参考前面。
例如：Enterprise Linux 6系列（RHEL），执行如下安装repo文件
$ sudo rpm -ivhhttps://yum.puppetlabs.com/puppetlabs-release-pc1-el-6.noarch.rpm
其他版本参考：http://docs.puppetlabs.com/guides/puppetlabs_package_repositories.html
详细参考：http://docs.puppetlabs.com/mcollective/deploy/install.html#installing-with-the-official-packages

B、安装Mcollective相关包
Debian/Ubuntu需要先安装stomp gem，使用以下之一来安装，但是要确保在1.2.2版本以上
libstomp-ruby(老版本使用)
ruby-stomp(新版本)
stomp(通用)

安装MCollective需要的包如下：
mcollective
mcollective-client
mcollective-common
rubygem-stomp (基于linux一些延伸的版本，RHEL不需要)
安装步骤详细如下
(一) 、在所有服务器节点安装mcollective包
yum install mcollective
(二) 、在管理终端上安装mcollective-client包
yum install mcollective-client
安装上述包时，会自动依赖安装mcollective-common包。
(三) 、安装完后确认mcollective服务能运行，并且设置开机启动。
service mcollective status        #查看服务是否正在运行
chmod +xmcollective                     #增加执行权限
chkconfig --add mcollective             #把mcollective添加到系统服务列表
chkconfig mcollective on                 #设定mcollective的开关（on/off）
chkconfig --list mcollective               #就可以看到已经注册了mcollective的服务
备注：Mcollective包安装了一个初始化的脚本能够使用系统的正常服务工具。

部署状态：Mcollective已经安装好了，但是还不能用，mcollective服务很可能拒绝启动，因为缺少连接和安全插件

Step 4: Configure Servers

1、放置认证文件
就像在Step 1中提到的，mcollcetive每台服务器需要CA、一个独立的证书和密钥，共享的服务器密钥对，以及每个认证的客户端证书(client certificate)。
安装puppet后就已经有了CA、独立的证书和独立的密钥。
拷贝共享的服务器公钥到如右路径：/etc/mcollective/ssl/server_public.pem
拷贝共享的服务器私钥到如右路径: /etc/mcollective/ssl/server_private.pem
创建目录/etc/mcollective/ssl/clients，并且拷贝所有的客户端证书到此目录(删除或者添加admin user，每台服务器都需要更新，可以用puppet的file资源来集中配置，ensure => directory, recurse => true)

注意：上面的提到的共享的服务器公钥和私钥，即是前面Step1步骤中的用mcollective-servers生成的密钥对，我们在Puppet Master使用sudo puppet cert generate mcollective-servers生成了共享证书，而证书会保存成/var/lib/puppet/ssl/{private_keys,public_keys}/mcollective-server.pem。我们将它们分别保存成server_private.pem和server_public.pem再拷贝到每台mcollective服务器的/etc/mcollective目录

上述证书可以参考Puppet企业版的，在这些目录下
/etc/puppetlabs/mcollective/ssl /etc/puppetlabs/puppet/ssl

2、填充fact文件
每台Mcollective服务器都需要填充/etc/mcollective/facts.yaml文件用来缓存facts
(也可以不用修改这个文件，但是不修改的话，会限制你过滤请求的能力)

在你写的部署Mcollective的puppet模块中加入以下这串代码。(用puppet的方式，不然一个个去加太累)
 file{"/etc/mcollective/facts.yaml": owner => root, group => root, mode => 400, loglevel => debug, # reduce noise in Puppet reports content => inline_template("<%= scope.to_hash.reject { |k,v| k.to_s =~ /(uptime_seconds|timestamp|free)/ }.to_yaml %>"), # exclude rapidly changing facts }
3、编写server config文件
编写配置文件：/etc/mcollective/server.cfg

配置文件中很多配置都一样，但是有些配置每台机器又都不一样，这就是需要用puppet来配置的原因。如果你只使用一些agent插件并且不需要很多配置，那你可以直接使用模板文件。否则，建议将每个配置都当做资源来管理，即参考managing each setting as a resource.。一般来说，我们直接使用模板文件即可。

编辑完配置文件后都要记得重启mcollective服务，可以在puppet中使用notification relationship来管理，即notification属性。

以下文件即server.cfg的模板文件，其中默认$ssldir的路径为/var/lib/puppet/ssl(根据实际puppet的情况修改，一般*nix类系统不用修改)，但是其中的变量$activemq_server和$activemq_mcollective_password还是需要填写的(即前面想的ActiveMQ中mcollective user的密码Guosir@eu2015)。

模板文件如下
 <% ssldir = '/var/lib/puppet/ssl' %> # /etc/mcollective/server.cfg # ActiveMQ connector settings: connector = activemq direct_addressing = 1 plugin.activemq.pool.size = 1 plugin.activemq.pool.1.host = <%= @activemq_server %> plugin.activemq.pool.1.port = 61614 plugin.activemq.pool.1.user = mcollective plugin.activemq.pool.1.password = <%= @activemq_mcollective_password %> plugin.activemq.pool.1.ssl = 1 plugin.activemq.pool.1.ssl.ca = <%= ssldir %>/certs/ca.pem plugin.activemq.pool.1.ssl.cert = <%= ssldir %>/certs/<%= scope.lookupvar('::clientcert') %>.pem plugin.activemq.pool.1.ssl.key = <%= ssldir %>/private_keys/<%= scope.lookupvar('::clientcert') %>.pem plugin.activemq.pool.1.ssl.fallback = 0 # SSL security plugin settings: securityprovider = ssl plugin.ssl_client_cert_dir = /etc/mcollective/clients plugin.ssl_server_private = /etc/mcollective/server_private.pem plugin.ssl_server_public = /etc/mcollective/server_public.pem # Facts, identity, and classes: identity = <%= scope.lookupvar('::fqdn') %> factsource = yaml plugin.yaml = /etc/mcollective/facts.yaml classesfile = /var/lib/puppet/state/classes.txt # No additional subcollectives: collectives = mcollective main_collective = mcollective # Registration: # We don't configure a listener, and only send these messages to keep the # Stomp connection alive. This will use the default "agentlist" registration # plugin. registerinterval = 600 # Auditing (optional): # If you turn this on, you must arrange to rotate the log file it creates. rpcaudit = 1 rpcauditprovider = logfile plugin.rpcaudit.logfile = /var/log/mcollective-audit.log # Authorization: # If you turn this on now, you won't be able to issue most MCollective # commands, although `mco ping` will work. You should deploy the # ActionPolicy plugin before uncommenting this; see "Deploy Plugins" below. # rpcauthorization = 1 # rpcauthprovider = action_policy # plugin.actionpolicy.allow_unconfigured = 1 # Logging: logger_type = file loglevel = info logfile = /var/log/mcollective.log keeplogs = 5 max_log_size = 2097152 logfacility = user # Platform defaults: # These settings differ based on platform; the default config file created by # the package should include correct values. If you are managing settings as # resources, you can ignore them, but with a template you'll have to account # for the differences. <% if scope.lookupvar('::osfamily') == 'RedHat' -%> libdir = /usr/libexec/mcollective daemonize = 1 <% elsif scope.lookupvar('::osfamily') == 'Debian' -%> libdir = /usr/share/mcollective/plugins daemonize = 1 <% else -%> # INSERT PLATFORM-APPROPRIATE VALUES FOR LIBDIR AND DAEMONIZE <% end %>
总之，即puppet使用模板文件来管理每台mcollective机器配置server.cfg文件，然后重启mcollective服务。

部署状态：每台Mcollective的服务器准备好了，可以连接到中间件，并且可以接受和处理来自认证的客户端的请求。但是认证的客户端还没有。

Step 5: 配置Clients

其实，配置的时候应该先创建个用户，官方文档里面没有讲清楚，不然像下面的~/.mcollective、~/.mcollective.d这些都不清楚具体路径的。模仿PE版puppet创建padmin用户和组如下。
sudo groupadd padmin
sudo useradd -d /var/lilb/padmin -g padmin -s /bin/bash padmin

1、配置步骤预览
配置客户端，每个新的admin user需要完成以下步骤
请求、取回、放置admin user的认证文件
编写客户端配置文件，以适当的边界范围及每个用户相应的配置
除非客户端会以root或者系统用户的方式运行，不然的话，建议把客户端配置文件放到~/.mcollective上，把像认证文件这类的支持性文件放到~/.mcollective.d下。

2、管理客户端认证文件
对于第一个admin user，可以像Step 1中那样手动生成认证文件，并且把公钥拷贝到每台Mcollective服务器的clients目录下，可用puppet的方式来添加。
例如：puppet企业版的是在这个目录下：/etc/puppetlabs/mcollective/ssl/clients/

当再添加一个新的admin user时，需要按以下步骤来
生成该admin user 的认证文件，并且自己保管私钥(参考Step 1)
拷贝该admin user的公钥到每台Mcollective服务器上
拷贝如下文件给该admin user：共享的服务器公钥(即mcollective-servers.pem)、CA证书、ActiveMQ的用户名/密码(即mcollective/Guosir@eu2015)
注意1：其实上述前两点与添加第一个admin user的步骤一致，之所以会有第三点是为了防止这个新添加的admin user在其他机器上。总之，如果新添加的admin user也在同一机器上的话，就不需要第三点操作。
注意2：拷贝该admin user的公钥给每台Mcollective服务器的时应于客户端机器上的公钥名称保持一致，即拷贝时名称不要变。因为客户端发起请求时会使用公钥的名称来设置caller ID，而Mcollective服务器会根据该请求的caller ID来选择对应的公钥验证。(该admin user所在的机器即是客户端机器)

了解了这么多，其实完全可以用puppet来简单管理，但是前提是只有一层单一的管理结构。即每个admin user都可以命令所有的Mcollective服务器。其中，可以附带一些额外的限制，在Step 6会提到用ActionPolicy 插件来管理限制，而不是通过证书的分发来限制。

用puppet配置client的流程步骤如下
<一>、新的admin user所在的机器确认已安装puppet(或者能使用mco命令也行)
<二>、执行如下命令，注意puppet certificate和puppet cert不一样，前者会发送证书签署的请求给CA，并会保护私钥，是针对远程机器访问CA使用的。
$ mkdir -p ~/.mcollective.d/credentials$ puppet certificate generate <NAME> --ssldir ~/.mcollective.d/credentials --ca-location remote --ca_server <CA PUPPET MASTER>
<三>、新的admin user的使用者应该跟Mcollective的管理员说下使用的NAME和递交的the fingerprint of the CSR。(其实，意思就是要新的user的使用者跟Mcollective管理员报备一下情况，这点在本篇文章可忽略，因为国内一般管理员和申请新的admin user的人是同一个人。国外分的比较细，这里包括下面几点提到的管理员，说的是实际生活中的人。)
<四>、Mcollective的管理员在CA puppet Master主机上运行如下命令
sudo puppet cert sign <NAME>
然后拷贝$certdir/<NAME>.pem这个公钥到每台Mcollective的clients目录下，在下次的puppet的运行中将会识别这个新的admin user
<五>、Mcollective的管理员应该跟新的admin user的使用者说已经签署了证书请求的事，并且提供ActiveMQ密码和一个已部分填写的client配置文件，这个配置文件包含了hostnames和ports(详细参考下面的client配置文件)
<六>、新的admin user的使用者在其机器上执行如下命令
$ puppet certificate find <NAME> --ssldir ~/.mcollective.d/credentials --ca-location remote --ca_server <CA PUPPET MASTER>$ puppet certificate find mcollective-servers --ssldir ~/.mcollective.d/credentials --ca-location remote --ca_server <CA PUPPET MASTER>$ puppet certificate find ca --ssldir ~/.mcollective.d/credentials --ca-location remote --ca_server <CA PUPPET MASTER>
<七>、新的admin user的使用者应该要在其机器上，拷贝前面提供的部分client配置文件到文件~/.mcollective上，并且完成剩下的client配置(参考下面的client具体配置来完成)
总结：上述这些步骤都完成后，然后在每台Mcollective服务器上运行一下puppet run，新的admin user就能够有效的使用mco命令了。

总之，如果新的admin user是同CA puppet master是在同一台，则直接如下操作即可。
1、创建新admin user的用户和组
sudo groupadd padminsudo useradd -d /var/lilb/padmin -g padmin -s /bin/bash padmin
2、创建存放认证文件的目录
su - padminmkdir -p ~/.mcollective.d
3、创建client的认证文件
sudo puppet cert generate padmin-mcollective-client
4、拷贝认证文件到.mcollective.d目录并别名
cp /var/lib/puppet/ssl/public_keys/padmin-mcollective-client.pem /var/lib/padmin/.mcollective.d/padmin_public.pemcp /var/lib/puppet/ssl/private_keys/padmin-mcollective-client.pem /var/lib/padmin/.mcollective.d/padmin_private.pemcp /var/lib/puppet/ssl/certs/padmin-mcollective-client.pem /var/lib/padmin/.mcollective.d/padmin_cert.pemcp /var/lib/puppet/ssl/certs/ca.pem /var/lib/padmin/.mcollective.d/padmin_cacert.pem
5、在每台MCollective服务器上创建clients目录(在MCollective安装完后创建该目录)
mkdir -p /etc/mcollective/ssl/clients
6、拷贝clients的公钥到MCollective的clients目录
/etc/mcollective/ssl/clients/padmin_public.pem
7、在每台MCollective服务器上重新运行puppet run
puppet agent --test
3、编写client config文件
Mcollective的admin users在客户端机器上的，如果是一般用户，配置文件为~/.mcollective，像使用root这样的系统级别的用户的配置文件放置在/etc/mcollective/client.cfg。
详细的配置可以参考：client configuration reference，会涉及到格式以及所有可用的配置
根据Mcollective管理员提供的client配置文件，需要修改其中的这些配置项
plugin.activemq.pool.1.ssl.ca
plugin.activemq.pool.1.ssl.cert
plugin.activemq.pool.1.ssl.key
plugin.ssl_server_public
plugin.ssl_client_private
plugin.ssl_client_public
如果是admin user不是root这样的系统用户创建的，而是一般用户的话，则修改下面的<HOME>为具体的路径，相对路径不能用；如果是root这样的系统用户，则直接改为实际路径。
则：如果是上述举例的padmin用户，则下面的HOME即为/var/lib/padmin
Client配置文件如下
# ~/.mcollective# or# /etc/mcollective/client.cfg# ActiveMQ connector settings:connector = activemqdirect_addressing = 1plugin.activemq.pool.size = 1plugin.activemq.pool.1.host = <ActiveMQ SERVER HOSTNAME>plugin.activemq.pool.1.port = 61614plugin.activemq.pool.1.user = mcollectiveplugin.activemq.pool.1.password = <ActiveMQ PASSWORD>plugin.activemq.pool.1.ssl = 1plugin.activemq.pool.1.ssl.ca = <HOME>/.mcollective.d/credentials/certs/ca.pemplugin.activemq.pool.1.ssl.cert = <HOME>/.mcollective.d/credentials/certs/<NAME>.pemplugin.activemq.pool.1.ssl.key = <HOME>/.mcollective.d/credentials/private_keys/<NAME>.pemplugin.activemq.pool.1.ssl.fallback = 0# SSL security plugin settings:securityprovider = sslplugin.ssl_server_public = <HOME>/.mcollective.d/credentials/certs/mcollective-servers.pemplugin.ssl_client_private = <HOME>/.mcollective.d/credentials/private_keys/<NAME>.pemplugin.ssl_client_public = <HOME>/.mcollective.d/credentials/certs/<NAME>.pem# Interface settings:default_discovery_method = mcdirect_addressing_threshold = 10ttl = 60color = 1rpclimitmethod = first# No additional subcollectives:collectives = mcollectivemain_collective = mcollective# Platform defaults:# These settings differ based on platform; the default config file created# by the package should include correct values or omit the setting if the# default value is fine.libdir = /usr/libexec/mcollectivehelptemplatedir = /etc/mcollective# Logging:logger_type = consoleloglevel = warn
备注：上面的client配置文件内容修改完后就可以直接使用。

部署状态：Mcollective已经完全可用，任何配置的admin user都可以运行mco ping、mco inventory、mco rpc等命令。如果想要有更多的功能和执行危险的命令，可以安装配置agent插件和ActionPolicy插件。

Step 6: 部署插件

为了实现更多的Mcollective的功能，需要部署各种各样的插件或者自己写的agent插件。
1、安装ActionPolicy插件
对于长久使用的Mcollective来说，建议安装ActionPolicy 认证插件到所有的服务器上。默认情况下，上述这种标准化的部署允许所有认证的客户端可以在服务端执行所有的动作。但是，当Mcollective的admin user的使用者越来越多时并且部署的agent的插件越来越多后会明显的对生产环境的服务器产生影响。当你想限制谁不可以执行什么动作时，ActionPolicy 插件将会分发policy文件到相应的agents上，来限制某些admin users不能在这些agents上执行给定的动作。

总之，国外因为admin users的使用者及使用的插件比较多的时候考虑的这种安全的插件，国内这种情况比较少，可忽略。
安装步骤如下
下载ActionPolicy 安全插件(参考如下文件及下载路径)
安装插件到所有服务器上(参考如下安装插件方法)
取消注释：rpcauthorization、rpcauthprovider、plugin.actionpolicy.allow_unconfigured
按需要，编写每个agent的policy 文件，并且分发到其对应的服务器上。参考See the ActionPolicy documentation for details on how to write policies.编写或直接看安装包中的文档。

下载ActionPolicy安全插件
从这里下载：Download the ActionPolicy plugin at its GitHub repo

安装插件的方法：
对于老的agent插件、某些非agent类的插件(例如认证类的)、以及大多数的自定义插件，安装方式是通过直接拷贝文件到 Mcollective的libdir目录下
所有的Mcollective插件都在libdir目录下，是在client或server的配置文件中设置的。
RHEL类的libdir默认路径：/usr/libexec/mcollective
Debian类的libdir默认路径：/usr/share/mcollective/plugins
其他类的没有默认路径
在mcollective的目录有如下这些：这些目录里面都是一些.rb/.ddl/.erb结尾的文件
因此，一般情况下这些插件文件的路径都是如下这样
<LIBDIR>/mcollective/<TYPE>/<NAME>.(rb|ddl|erb)，util目录可能会包含额外的目录层级。

例如：要安装package的agent插件，采用如下的方式安装
RHEL类的系统：(注意有两层mcollective目录，下列黄色标注的目录即libdir的目录)
/usr/libexec/mcollective/mcollective/agent/package.rb
/usr/libexec/mcollective/mcollective/agent/package.ddl
Debian类的系统：
/usr/share/mcollective/plugins/mcollective/agent/package.rb
/usr/share/mcollective/plugins/mcollective/agent/package.ddl
注意1：SSL安全插件中设置message的caller ID为cert=<NAME>，这里面的<NAME>是client的公钥名去掉.pem后缀。这个字符串在policy行作为第二个字段，ActionPolicy文档uid=使用PSK的安全插件作为caller ID的案例。
注意2：修改server的配置文件，可以选择性的选择agent是否使用该插件。但是，如果没有分发policy文件，该插件的认证功能也不会生效。
注意3：因为policy文件中定义了servers使用的规则(基于facts 和其他的metadata)，可以安全的分发到所有的server机器。
总之：安装ActionPolicy插件，直接查看上面的安装包里面的README.md文档即可。

2、安装Agent插件
这个比较有用
Agent插件能做所有Mcollective的重活。Servers安装agent插件的所有部分，clients只要安装agent的插件的DDL文件即可。
已有的agent插件如下，推荐最有用的三个：puppet、package、service
地址链接：the mcollective-plugins wiki.
MCollective Plugins Wiki
The general process to follow when installing plugins can be found here
Agents
· Apt – Perform various tasks for apt/dpkg
· File Manager – create, touch, remove and retrieve information about files
· IP Tables Junkfilter Manager – Add, removes and queries rules on a specific chain
· Net Test – Performs network reachability testing
· NRPE – Runs NRPE commands using MCollective as transport
· Process – Manage server processes
· Puppet – enable, disable, run puppet daemons.
· Puppet CA – Manage the Puppet Certificate Authority
· Package – installs, uninstalls and query Operating System packages
· Packages – install, update, uninstall multiple packages in one run with fine version/revision control
· Service – stop, starts and query Operating System services
· Spam Assassin – Perform various tasks for Spam Assassin
· Stomp Utilities – helpers and utilities for the STOMP connector
Fact Sources
· Facter via YAML – Access Facter variables as YAML
· Facter – Use Puppet Labs Facter as a fact source
· Ohai – Use OpsCode Ohai as a fact source
Auditing
· Central RPC Log – Logs RPC audit logs to a central log file or MongoDB instance
· Central LogStash log – Logs RPC audit logs to a central LogStash instance
Authorization
· Action Policy – Authorization plugin with fine grain per action ACLs
Data
· Puppet Resource Status – Datasource to facilitate discovery of machines based on the state of Puppet resources
· Sysctl Value – Datasource to retrieve values from any Linux sysctl
· Agent Meta Data – Datasource to retrieve meta data about currently installed agents for nodes
Discovery
· Registration Data in MongoDB – Discover against registration data in a MongoDB NoSQL server
Security
· None – A plugin for development that provides no security
Registration
· Meta Data – Sends agents, facts and classes lists to registration agents
· Registration Monitor – Writes registration data to file and a Nagios check
· Registration Data in MongoDB – Writes registration data to a MongoDB NoSQL server
Tools
· Puppet Commander – schedule puppet runs on a group of hosts with enforced concurrency
· SSH – Discovery assisted ssh

编写自定义agent插件，例如编写日常自动化任务等，可以参考如下文章
http://docs.puppetlabs.com/mcollective/simplerpc/agents.html

安装插件方法有两种
A、用本地包安装插件的方法
使用puppet官方repo文件，使得操作起来更容易些，能自动打包，便于分发、安装、升级。
1、使得puppet官方repo文件生效可用(可参考前面，如果前面已安装，即可使用)
2、查看要安装的包，因为每个插件都有这些包：mcollective-<PLUGIN SET NAME>-<ROLE>，其中的<ROLE>有这些agent, client, common，不是每个插件都有这三个包，可以看下repo中关于该插件的包列表。例如看service的包，可以用这类命令查看：yum search all mcollective-service
3、使用puppet安装插件的agent包和common包到servers主机上。
4、重启servers上的mcollective服务(即Mcollective的守护进程)
5、安装插件的client包和common包到client的主机上。(应该要维护一张清单，上面是装了哪些插件，以方便管理员以后更新)
6、可选的(可以忽略的操作)，查看部分主机的安装效果，使用命令：mco inventory <NODE NAME>，查看更多的插件信息使用命令：$ mco rpc rpcutil agent_inventory -I some.node
注意：这种基于包安装的方法对于老的agent类插件和非agent类的插件不适用，如果需要安装这些类的插件，采用拷贝到libdir目录的方法，即参考下面那种方法。

B、用拷贝插件到libdir目录的方法
(这个在前面安装ActionPolicy插件时有提到，即拷贝到目录即可，具体可参考上面的路径)

部署状态：Mcollective现在可以做任何事了，可以运行自己写的或者下载的插件，在任意数量的servers上，以及可以按任意的metadata来过滤和分组。

(完)

1 0