This post I am going to talk about what RHEL Satellite is still lacking and why that is a big deal. Implementing it would probably mean even heavier specs for the RHEL server thats running satellite, but I still think they would be valuable add-ons for Satellite.
- Puppet Database (puppetdb).
- Remote Execution (planned in 6.2)
- Openscap maturity
- Better Puppet modules management
- Puppet updated to 4.0
Using a puppet database, would mean that many things become available that are now a pain to implement in Puppet / Satellite.
I am talking about Puppet exported resources. If I want to use Satellite now to provision -say- a nagios monitoring host, I can’t make a puppet exported resources to allow for easy management of client hosts. I will have to either edit the nagios host manually (ouch!) or I will have to query the Foreman database for which hosts exist and what properties I need to assign them to complete my monitoring clients.
PuppetDB stores all facts and most recent report from its client-nodes. It also stores 14 days of history (a few config changes) which means that functionality can be chosen to be inside satellite, or inside PuppetDB.
Remote execution needs little explaining, but after checking back with the Rhel Satellite 6.2 roadmap, I see Remote execution is already planned, so the point became moot 🙂
What I mean by this point is, that the current Openscap implementation in Satellite is a bit sloppy. It doesn’t completely implement the Openscap editor tools, you need to know quite a lot about Openscap to write your own client policies and assign them to hosts. Of course you can download other people’s policies from the Internet and assign those, but then they aren’t auditted by your administration to make sure they fit company policy. Furthermore, Openscap currently crashes on me, leaving all reports on Satellite’s harddisk and not loaded in the GUI. Finding the faulty report is a pain and I have no idea why it is denied, as browsing it with a text-browser it seems fine.
Better puppet modules management.
Currently puppet modules are imported ‘as-is’ and assigned to content views and lifecycle management. However, despite the version-management of the content views, it is still unclear sometimes where puppet errors (duplicate class definitions , strange variables that appear and dissapear because of previous versions in other content views) come from. Whenever I encounter such an error, I try to push to the most recent puppet module verison on all my content views to be rid of old versions quickly.
Update to Puppet 4.0
Puppet 4.0 has many new features that are a boon to system administrators like myself.
- Iteration over arrays / hashes
- Bugs in facter solved (Primary ethernet interface anyone?)
- Package collections. Read more about those on the Puppet BLOG
- Better GIT integration
- Robot 10000 (r10k)
- HEREDOC support
- Better TYPE support
- Better performance on puppet server and clients (Faster catalog compile