(First in a series of some finite positive number, for the greater edification of Googlers everywhere.)
If you get an error of err: Could not retrieve catalog: Could not parse for environment development: Syntax error at ‘Debian’ at /etc/puppet/master/manifests/os/Debian.pp:1 on a Debian.pp that only has one line of class Debian {}, just go ahead and change [...]
I had posted earlier about distributing stowed packages via rsync and puppet to my managed systems, but that method wasn’t quite what I wanted:
There was one more file to manage outside my regular puppet manifests, and I’d have to remember to keep them both up to date and in sync.
There wasn’t an easy way of [...]
Back at the infrastructures.org mothership, client configuration management is described as everything that makes a host unique and/or part of a particular group or domain. And for Unix-like systems, everything pretty much comes down to configuration files, services being enabled/disabled, and cron jobs.
Hmm.
Configuration files
Services
Cron jobs
Looks like Puppet pretty much handles all of that. As long [...]
The infrastructures.org folks list two primary goals of what they call “client file access“: first, consistent access to users’ home directories, and second, consistent access to end-user applications. Some of the things they warn against, such as automounters and the /net directory, we never thought of using to begin with. Their need to consider systems [...]
Back when the infrastructures.org folks were writing their pages, the page for file replication servers described a need to keep current copies of configuration files in /etc and all programs and other data from /usr/local on all the managed systems. In puppet structures, every file or other resource is just a part of a higher-order [...]