Why is the title puppetserver instead of puppet you ask, simply because as I am starting with puppet from scratch I have no interest in learning how to use the old “puppet-master” setup but will concentrate on the new puppetserver implementation… mainly because the old “puppet-master” setup is completely different as far as directory structures, software dependencies, configuration etc. so I see no point in learning how it used to be done in the old days (at least from google posts I have looked at they seem to be different, it may just be that I am using the puppetlabs packages and 3rd party re-packagers have moved the directry structures about; but I am using the puppetlabs packages so this post covers those).
As I have a smallish home lab comprised mainly of Fedora26 servers and VMs the “puppetserver” with the inbuilt webserver provides all I need for my own playing with how to use it.
My personal interest for using puppet is to enable my to update configuration files shared across all machines in one place and have the changed propogated. Happy to say it works perfectly for that purpose… the but I need to learn how to… is covered at the end of the post.
I have installed puppetserver onto a CentOS7 VM, the main reason for that is that there was no puppetserver available for F25 and I have only just (in the last week) upgraded all my Fedora servers from F25 to F26 and have not got around to seeinpuppetserver_centos7_2agents.yamlg if puppetserver is available for F26… plus of course I have been testing puppetserver installs/configurations on CentOS7 over the last few months to work out a suitable config for my use (refer to my earlier post on installing a puppetserver instance and puppet agent instance into openstack with a heat template if you want a repeatable trow-up/tear-down test environment, if you have a openstack test system of course).
Setup used was
- I created my puppetserver puppet host in a new CentOS7 VM with only 2Gb of memory assigned, and changed the configuration for the java memory to 1Gb and the startup delay values as described in the heat template covered in the above post. Configured the VM to use a fixed ip in this case of course. Also using automatic signing of certificates as I have a lot of VMs to setup.
- Created a “nrpe” configuration module so there was something to test with… the configuration is pasted later in the post
- to avoid having to update the /etc/hosts file on all my VMs I created a complete hosts file on my two main vmhost servers, started dnsmasq, and updated all VMs to use those as the first two nameservers. And no it was not a lot of effort as the alternative would be updating the /etc/hosts file on all VM servers to have an entry for the “puppet” host anyway… so as I had to update all VMs anyway I chose to alter them to use dns to avoid any need for updating hosts files on VMs in the future
- and one-by-one on the F26 VMs installed from the Fedora repositories with “yum -y install puppet”,”systemctl enable puppetagent”,”systemctl start puppetagent”
- watched them register certificates and sync the nrpe commands I use onto each VM from the puppet host
As noted at the start of the post puppetserver and puppet-master use different configurations, including the directory structures (if posts found on google are anything to go by anyway… it may just be because I am using puppetlabs packages instead of the 3rd party distros). But I include a banner at the start of each file, for my reference also, so you know where these should go in a puppetserver install.
This is working to customise the nrpe commands across all my VMs, but see the what I still need to learn section below the code examples.
# ==================================================================
# /etc/puppetlabs/code/environments/production/modules/nrpe/manifests/init.pp
# ==================================================================
class nrpe {
# install nrpe package
package { 'nrpe':
ensure => installed,
}
# install nagios plugins packages
package { 'nagios-plugins-all':
ensure => installed,
}
# replace the allowed_hosts line with out host list
# note: file_line is from puppetlabs/stdlib (not a core module),
# so cannot use it, supply the entire file (Fedora, have to rethink CentOS deploys)
# file_line { 'allowed_hosts':
# path => '/etc/nagios/nrpe.cfg',
# line => 'allowed_hosts=192.168.1.170,192.168.1.183,127.0.0.1',
# match => '^allowed_hosts=127\.0\.0\.1*',
# }
#
# install a nrpe configuration file that allows connections from all both nagios hosts
file { 'nrpe.cfg': # file resource name
path => '/etc/nagios/nrpe.cfg', # destination path
ensure => file,
owner => 'root',
group => 'root',
mode => '0644',
source => 'puppet:///modules/nrpe/nrpe.cfg', # specify location of file to be copied
}
# IMPORTANT NOTE ON FILES, PUPPET INSERTS A /files/ into the source URL
# source => 'puppet:///modules/nrpe/md_check_bacula_client'
# is physically on puppetserver the below structure
# /etc/puppetlabs/code/environments/production/modules/nrpe/files/md_check_bacula_client
#
# move on to ensuring all my custom nrpe scripts and commands exist
file { 'md_check_bacula_client':
path => '/usr/lib64/nagios/plugins/md_check_bacula_client',
ensure => file,
owner => 'root',
group => 'root',
mode => '0644',
source => 'puppet:///modules/nrpe/md_check_bacula_client'
}
file { 'md_check_snort':
path => '/usr/lib64/nagios/plugins/md_check_snort',
ensure => file,
owner => 'root',
group => 'root',
mode => '0644',
source => 'puppet:///modules/nrpe/md_check_snort'
}
file { 'md_check_tripwire':
path => '/usr/lib64/nagios/plugins/md_check_tripwire',
ensure => file,
owner => 'root',
group => 'root',
mode => '0644',
source => 'puppet:///modules/nrpe/md_check_tripwire'
}
# ....... lots more commands .......
#
# nrpe additional commands now
# note: the notify will endure the nrpe service is restarted to pick up
# changed when this file is modified
file { 'nrpe_extra_commands':
path => '/etc/nrpe.d/marks_extras.cfg',
ensure => file,
owner => 'root',
group => 'root',
mode => '0645',
source => 'puppet:///modules/nrpe/marks_extras.cfg',
notify => Service['nrpe'],
}
# we can now ensure nrpe service is running
service { 'nrpe':
ensure => running,
}
} # end nrpe class
# ==================================================================
# /etc/puppetlabs/code/environments/production/manifests/site.pp
# ==================================================================
# apply to all nodes without an explicit entry
node default {
include nrpe
}
# override the defaults for server specific customisation
node 'nagios' {
include nrpe
}
What I still need to learn
- how to include facter information into a template file (hmm, did I answer my own question, template file) so I can push out config files that only differ by hostname vaules within the config files
Anyway I have downloaded the puppetlabs tutorial/training ISO to look at, always knew paying for a vmware workstation license would come in handy one day :-). But that seems to be more for puppet ‘enterprise’ training than the basic foundation components I need to learn but I will give it a go.
I think the puppet core components have the potential to keep me interested for a while.
