How things are often: something gets done, and for whatever reason I don’t write up the notes very well.
(Yes, there’s the larger issue of why I actually am duplicating any effort at all, but it’s a long story. Later.)
I’ve been working on setting up several Puppet installations over several different networks, and I’d actually gotten a simple set of tasks working. So, I said there’d be no problems in setting up a new network. After all, my notes said:
Well, now, that shouldn’t be a problem. Look at 2) . I’m sure I would have added notes later if that wasn’t true.
Two hours later, the page looked a bit different:
Two additions:
First, my reminder to myself that misleading documentation is worse than none.
Second: needed firewall update, the autosign.conf file wasn’t there, another old config, and the kicker: Puppet wouldn’t start – just like when I when I worked this the first time in March, and that took some time to figure out, again.
It turns out that Puppet (server) needs access to temporary space that’s generally allocated in /opt/puppetlabs (I think). The problem is that our security baseline has all filesystems except for those with system-supplied binaries (so, places like /data which is where we put configuration and payloads for services, /tmp, etc.), mounted with the noexec option, meaning no file on the filesystem can be executed. Puppet’s default temporary allocation apparently needs to write and execute something there, which breaks Puppet Server startup.
My recollection of this is that it’s only an issue during initialization, so I decided the cleanest place to allocate the space was in /boot.
(Meta-apology: I should have documented better how exactly I came to this conclusion, but what makes this meta is that since I had to go back unexpectedly and re-hash this, I jumped to the conclusion – not recording what led me to it. But now that I’ve set up this category for just that type of thing, I’ll help someone worthy – probably me, in 2019 – with the next thing I run into.)
KMP on Technology 