Package groups via Foreman and puppet-yum module

Support
1

Dear All

I am a rolling out a Foreman/Katello based Linux Desktop provisioning service at an academic site.

Naturally I use Foreman + host-groups to generate a basic Kickstart file mildly customised according to site location. I would like to be able to use Foreman’s built in Puppet integration for finer configuration management as this can be quite variable.

In particular I should like to use the puppet-yum module to filter yum package groups to be installed accordining to various site criteria. According to that module’s documentation this may be achieved as follows, for example:

yum::group { 'X Window System':
  ensure          => present,
  timeout         => 600,
  install_options => ['--enablerepo=*'];
}

But there is no ‘Smart Class Parameter’ for yum::group showing in Foreman/Puppet/Classes. Does this mean that I must create a ‘Smart Variable’? If so how do I proceed: my efforts up until now have not been crowned with success …

Many Thanks in Advance

Nick Gresham

2

Hi,

the problem here is that the yum::group type is a defined type, not a class. Puppet’s design is though that an ENC (like Foreman) can only call classes. Because of that, yum::group is not shown in Foreman UI.
You will need a class (like a puppet role for example) that passes your smart-class parameter to the yum::group defined type.

Regards

3

Ah, I see. Thank you for that information.

Would I be correct in stating that the way forward would be to create a ‘local’ Foreman module collating, and exposing as classes, matters that cannot easily be arranged via existing ‘Smart Class parameters’ from downloaded modules?

As I am something of a novice when it comes to Puppet, let alone how it dovetails with Foreman, I’d be very grateful if someone could provide a simple example illustrating this technique.

Many Thanks in Advance

Nick Gresham

4

Setting up a complex management environment from scratch can indeed be a very heavy task, especially you don’t have a lot of experience with it.
The mostly agreed-upon best practice for setting up Puppet would probably be the roles and profiles concept. Here is a writedown on that toppic from the official Puppet documentation: https://puppet.com/docs/pe/2019.1/the_roles_and_profiles_method.html . It is from the Puppet Enterprise documentation, but the exact same principles apply to open source Puppet. It is a somewhat advanced topic and might look like overkill when you start, but as your codebase and environment grows, you will probably regrett not using it at some point or another.

The basic principle for your setup would look something like this:

  • You have your downloaded component modules that manage exactly one component on your system in a mostly abstract way (like your yum module)
  • Those compoent modules are called by profile modules. These are on a more abstract level of component like “Apache server”, “MySQL Server”, etc. This is where all those component classes and whatever ressources else you might need get actually called with all parameters needed for that type of server.
  • Rolls finally “glue” several profiles together to some sort of business usecase like “Jenkins Master”, “ERP Frontend” and whatnot. These should only call profile classes and not implement logic of their own.

According to Puppet, neither roles nor profiles should have any parameters of their own (what would make them kind of useless in a setup where you want to rely on your ENC for data). I do disagree with that to the extent that data that should be settable via ENC (because it might be diffent for every server you have) should be haded from ENC through roles and profiles to the actual component using it.

In conclusion, I would in general recommend a setup like this:

  • Use the concept of roles and profiles for your Puppet Code.
  • Assign Puppet roles on a hostgroup level and design your hostgroups according to your business use cases.
  • Use the hierarchical structures of Smart Class Pamaters (like Puppet defaults → hostgroups → nested hostgroups → hosts) to declare all your data on the “topmost” level possible.

I hope this helps you find a way into the right direction :slight_smile: