Built in types
So far, this control repo is limited to functionality built into the puppet agent, or that’s written from scratch. Built in types are documented by puppet, eg: https://puppet.com/docs/puppet/5.3/type.html
You can get a list from the client:
$ puppet resource --types augeas computer cron exec file filebucket [...]
In the control repo structure, add-on puppet modules go into modules/
I use a script to populate it because:
- The incantation to download modules isn’t especially memorable.
- There’s one or two modules I’ll always want, like stdlib (which provides commonly used extra functionality) that the script is coded to deploy.
Some observations:
- I don’t pull down all modules in use on my puppet master, just what I need for the new profile I’m developing.
- Module dependencies are downloaded automatically by puppet module.
- As the modules are downloaded into your workspace, the script refuses to run as root.
- For development purposes, the latest modules are usually fine. So, the script doesn’t have a mechanism to support downloading specific versions.
.gitignore
If you’re using this repository clone to develop locally, you don’t want any modules you install to be picked up by the git client as changes.
Puppet’s sample control repo (the one I’ve modified) includes the necessary configuration to address this; .gitignore in the root of the repository contains:
modules/
Add the stdlib module
The previous post’s branch adds a script (in scripts/) for installing modules.
$ git status # On branch puppetapply03 nothing to commit, working directory clean
Run it ‘as is’ to download stdlib; the script is hard coded to install that. Note: not sudo. It’ll object to running as root, as it would stick a bunch of root owned stuff in your control-repo directory structure.
scripts/puppetmodule.sh
Expect:
$ scripts/puppetmodule.sh Notice: Preparing to install into /etc/puppetlabs/code/environments/local/modules ... Notice: Created target directory /etc/puppetlabs/code/environments/local/modules Notice: Downloading from https://forgeapi.puppet.com ... Notice: Installing -- do not interrupt ... /etc/puppetlabs/code/environments/local/modules └── puppetlabs-stdlib (v5.2.0)
If you then run puppet apply, via the script, the behaviour of the profile which dumps the scope changes; a fact is defined by stdlib, and so the profile writes the file to a different location, instead of /tmp.
sudo scripts/puppetapply.sh #--noop [..] Notice: /Stage[main]/Profile::Puppet::Clientscope/File[/opt/puppetlabs/puppet/cache/site_agent_variables.yaml]/content: content changed
- The code doing this is in site/profile/manifests/puppet/clientscope.pp
- That directory tree restricts access so only root can read the file.
- The following will be in the output as well; stdlib has provided additional facts.
Info: Loading facts
add concat module
Check out the next branch:
git checkout puppetapply04
Run puppet apply, and you’ll get an error:
sudo scripts/puppetapply.sh #--noop [..] Error: Evaluation Error: Error while evaluating a Resource Statement, Unknown resource type: 'concat::fragment'
A new set of profiles for building message-of-the-day are active; in site/profiles/manifests/motd/
As written, the script offers two ways to add more modules; either:
- Modify the script in control repo permanently, to include modules you always want to download. Add them along side ‘puppetlabs-stdlib’ space separated.
- Add modules adhoc by creating /tmp/puppetmodules.list on the machine you’re working on. Each module can go on a separate line.
To add concat, do the following.
$ echo 'puppetlabs-concat' >> /tmp/puppetmodules.list $ scripts/puppetmodule.sh [..] /etc/puppetlabs/code/environments/local/modules └─┬ puppetlabs-concat (v5.2.0) ├── puppetlabs-stdlib (v5.2.0) └── puppetlabs-translate (v1.2.0)
For development and testing I find the temporary file is usually enough. Once my workspace has a module, it’ll stay there until deleted, so it doesn’t need to be coded into the script permanently.
Puppet apply should now work.
sudo scripts/puppetapply.sh #--noop
You’ll get a diff for /etc/motd because the original code padded each line with a couple of spaces. (I did it to make the original motd.pp manifest look tidier .. it’s a bug really ..)
The revised profile creates /etc/motd_local as well – the contents of this file, if there is anything, is appended to /etc/motd.
thewatertower.org 