This is a how-to guide on using:

https://github.com/camptocamp/puppet-ghostbuster

First get this working so that you can access this gui dashboard:

https://puppet.com/docs/puppetdb/5.1/maintain_and_tune.html#monitor-the-performance-dashboard

Install rvm:

$ gpg --keyserver hkp://keys.gnupg.net --recv-keys 409B6B1796C275462A1703113804BB82D39DC0E3 7D2BAF1CF37B13E2069D6956105BD0E739499BDB
$ \curl -sSL https://get.rvm.io | bash -s stable --ruby

Check rvm install is successful:

schowdhury@Shers-MacBook-Pro:~$ rvm --version
rvm 1.29.3 (latest) by Michal Papis, Piotr Kuczynski, Wayne E. Seguin [https://rvm.io]
schowdhury@Shers-MacBook-Pro:~$ rvm list

rvm rubies

=* ruby-2.4.1 [ x86_64 ]

# => - current
# =* - current && default
# * - default

schowdhury@Shers-MacBook-Pro:~$ ruby --version
ruby 2.4.1p111 (2017-03-22 revision 58053) [x86_64-darwin16]

Next install the following gems:

gem install puppet-ghostbuster
gem install r10k

Then clone your repo onto your laptop, and while in this repo, switch to the appropriate branch, then run:

$ r10k puppetfile install --verbose

then in a seperate bash terminal tab, run:

$ ssh -L 8080:localhost:8080 {puppetmaster-fqdn}

Now test this ssh tunnel by opening up a web browser and went to:
http://localhost:8080

This

External facts is a great way to attach (arbitrary) metadata to a machine during the the launch of a new machine. E.g. when building a Centos 7 aws ec2 instance, you can generate the external facts via userdata.

Puppet can use these external facts in the way as any other fact. You can create external facts by simply creating a file. This file can be a:

• shell script
• yaml file

This file needs to be created inside any of the following 2 folders on a CentOS machine:

• /opt/puppetlabs/facter/facts.d/
• /etc/facter/facts.d

Note: you might need to create the above folders if they don’t already exist.

For example, let’s say I want to create 3 external facts, the ‘key-name=key-values’ are:

role='blog-site'
pipeline_color='Blue'
standby_mode=true

First off, let’s confirm that these facts don’t already exist:

[root@puppetagent1 ~]# facter -p role

[root@puppetagent1 ~]# facter -p pipeline_color

[root@puppetagent1															

You can query the PuppetDB API to identify which puppet environments and classes that are no longer being used. This is handy for housekeeping purposes.

The commands covered in this tutorial needs to be run as the root user on the puppetmaster.

Note: I am using version 4 of the puppetdb api. So you might need to tweak these commands in order for them to work on other versions.

Also note, there is a really cool rubygem for identifying dead puppet code: https://github.com/camptocamp/puppet-ghostbuster

Identifying obselete control repo environments

The following command lists all the control repo environments that has one or more puppet agents attached to them:

$ curl -s -X GET http://localhost:8080/pdb/query/v4/nodes --data-urlencode 'pretty=true' | grep 'report_environment' | sort | uniq | awk '{print $NF}' | cut -d'"' -f2
dev1
dev2
test1
test2
staging
prod

This

Exported Resources

https://docs.puppet.com/puppet/latest/reference/lang_collectors.html

https://docs.puppet.com/pe/latest/node_deactivation.html

querying puppetdb with postgres command line, psql

psql -h localhost -U puppetdb puppetdb

However to connect to puppet enterprise’s puppetdb, then follow:

https://gist.github.com/tnolet/7133083

\q
\h
\l

\d
select * FROM catalog_resources
\X
\x
SELECT * FROM catalog_resourcesSELECT * FROM factsselect * from factsssselect * from reports
\q
SELECT * FROM catalog_resourcesSELECT * FROM factsselect * from factsssselect * from reports
\x
select * from facts;
\d
lsSELECT * FROM catalog_resources
\l
\c puppetdb
lsSELECT * FROM catalog_resources;
lsSELECT * FROM catalog_resources
\q
\l
\c puppetdb
\l
\d
\x
\d
SELECT * FROM certnames ;
SELECT * FROM facts ;
\d
SELECT * FROM catalog_resources ;
\x
SELECT * FROM catalog_resources ;
SELECT * FROM catalog_resources ;
\d
SELECT * FROM catalog_resources ;
\d
SELECT * FROM environments ;
SELECT * FROM catalog_resources ;
SELECT

http://docs.puppetlabs.com/puppetdb/latest/

https://github.com/spotify/puppetexplorer

The fastest way to learn Puppet is to get a full picture of the puppet infrastrucutre. The best way to do to this is if you have a story (aka narrative) to follow along that starts from the puppet basics to the advanced stuff. When you learn something new about puppet you can then link it back to the narrative. This will help you understand the bigger picture of using Puppet.

Learning approach checklist

1. Run a Puppet resource command, with a resource definition itself on the command line. Run this on all demo machines. E.g.:

   [root@puppetagent1 ~]# puppet resource file /tmp/testfile.txt ensure=present content="hello world"
   Notice: /File[/tmp/testfile.txt]/ensure: created
   file { '/tmp/testfile.txt':
     ensure  => 'file',
     content => '{md5}5eb63bbbe01eeed093cb22bb8f5acdc3',
   }
   [root@puppetagent1 ~]# cat /tmp/testfile.txt
   hello world
   [root@puppetagent1 ~]#
   
   

   This demonstrate how puppet is standardising how changes are

The “Puppetfile” is list of all puppet modules you want downloaded into your puppet master’s modules folder:

The first line of this file should be:

forge "http://forge.puppetlabs.com"

After that any puppet forge modules are listed as:

mod 'puppetlabs/stdlib',  '4.5.1'

Next any puppet modules hosted on git (e.g. github or any other git server, e.g. stash) can also be added, based on git’s commit id:

mod 'sudo',
  :git => 'https://github.com/saz/puppet-sudo.git',
  :ref => '231e15fb9311233ee0fe12f4d9bd6ec978d54a2c'

or a particular, irrespective of branch:

mod 'sudo',
  :git => 'https://github.com/saz/puppet-sudo.git',
  :ref => '231e15fb9311233ee0fe12f4d9bd6ec978d54a2c'

or a particular branche’s latest commit:

mod 'sudo',
  :git => 'https://github.com/saz/puppet-sudo.git',
  :ref => '{branch-name}'

Or even a particular git (version) tag:

mod 'sudo',
  :git => 'https://github.com/saz/puppet-sudo.git',
  :tag => '1.2.0'

Note, ensure you include all module dependencies. Then to check that you all dependencies are included, run:

$ puppet module															

this is common, for example, sometimes once class installs dbg software, and then the next class creates the db istself.

class mainclass {
  include class1
  include class2
  include class3
  include class4

  Class['class1']
  -> Class['class2']
  -> Class['class3']
  -> Class['class4']
} 

So far we have looked at order resources, and ordering classes.

Run Stages let you do ordering at a higher level.

https://docs.puppetlabs.com/puppet/latest/reference/lang_run_stages.html

When you use the user resource, you’ll notice that it contains a password attribute. This can only be used to enter an encrypted password, aka a hashed password. For security reasons, you cannot use a plain text password.

Also for some reason, you can’t use the passwd command to create hash value and retrieve that value from teh /etc/shadow file either. However Puppet passes the password supplied in the user type definition into the /etc/shadow file.

You have to use the openssl command to generate the hash:

 
#openssl passwd -1  
#Enter your password here 
Password: 
Verifying - Password: 
 $1$HTumvYUGYUGwsxQxCp3F/nGc4DCYM

You then insert this password into your resource:

user { 'TestUser': 
  ensure   => present,
  password => '$1$HTumvYUGYUGwsxQxCp3F/nGc4DCYM',
}