Puppet is a wonderful tool and as Foreman/RH Satellite now support puppet out of the box, it is time to explore. For the purpose of this blog post, I shall assume
RH Satellite == Foreman!
The first thing to be noted, is that puppet is severely under-documented in the redhat and foreman documentation. Little is provided and even those little things are creating more questions than answering them. I will write a few blog posts on this very subject, of which this is post 1.
First topic in this series: Facts!.
The Foreman project is adding facts to the satellite server through facter , which is part of puppet. But what if these facts aren’t complete. Its all nice and dandy to know standard stuff like a hosts ip-address and hostname and cpu and stuff, but what if we need to know for instance , the names of the IDM servers for the NTP configuration which has been integrated in Satellite. You won’t find those anywhere.
First lets apply a few logic rules to determine whether we need this new fact, or would rather use it as a variable to be declared in some class::param concept.
When to use a fact in my opinion
– It never changes! This seems obvious, but I have seen administrators getting this wrong, I have seen guys write ruby code to change a fact almost every run! Don’t do this people, if something isn’t solid, use a class:param and not a fact! (for instance, the system time 🙂 this is not a fact guys, its completely variable!, it changes as fast as the clock resolution of your computer!)
The fact will be either master-side , or client-side compiled. Facts created on the puppet-master for instance might include the ntp-servers to use. Client-side facts might be dependant of the environment , like the nfs-homeserver of your cloud environment. Production might have a different one than Development but other than that it is static, it can be put into fact.
Next post: Server-side facts.