djedig Absent Member.
Absent Member.
1376 views

Linux Policies / Puppet with module dependencies

I am having trouble understanding how modules with dependencies on other modules are to be used with ZCM. What is the "proper" way for Puppet module installation for use with ZCM policies?

With a Puppet master in place, I would use "puppet module install " on the master to install all necessary modules including dependencies downloaded from PuppetForge or other configured repositories. The distribution of the necessary modules to the clients would be taken care of.

With ZCM, the process seems to be significantly more manual - I need to download the .tar.gz module files from the Puppet Forge myself, and upload them to ZCM newly created policies as "modules" which I can assign to clients afterwards.
- as a result, a module like "stdlib" assigned to a client gets extracted into a subdirectory named "puppetlabs-stdlib-4.5.1", which breaks Puppet's mechanisms for dependent modules and classes lookups as they expect the module name "stdlib" to be the containing directory's name as well. I can work around this by modifying the archive and renaming the directory to "stdlib" prior to uploading it into the policy as a module.
- as another result, the execution of the Init class of the module named in the "Module Name" parameter of the policy is triggered on each refresh. If I place the module's own name there (e.g. "stdlib"), then stdlib::init is being executed without parameters, which does introduce issues with modules written to actually *do* things on init like writing configuration files. An example for this is trlinkin-nsswitch which would create (and overwrite) an nsswitch.conf with a stock (and in my case unusable) version upon execution without prior parametrization. I can work around this as well by either simply providing an invalid class name as the "Module Name" or by modifying the module's code. The first method will introduce reported errors upon each policy refresh, the second method is creating an administrative nightmare for us.

All of this is so inefficient compared to stock Puppet/Master configurations, that I believe I am doing it wrong. Can someone provide examples of how things could be done differently in Linux Policy environments?
Labels (2)
0 Likes
1 Reply
Micro Focus Expert
Micro Focus Expert

Re: Linux Policies / Puppet with module dependencies

djedig;2384270 wrote:
I am having trouble understanding how modules with dependencies on other modules are to be used with ZCM. What is the "proper" way for Puppet module installation for use with ZCM policies?

With a Puppet master in place, I would use "puppet module install " on the master to install all necessary modules including dependencies downloaded from PuppetForge or other configured repositories. The distribution of the necessary modules to the clients would be taken care of.

With ZCM, the process seems to be significantly more manual - I need to download the .tar.gz module files from the Puppet Forge myself, and upload them to ZCM newly created policies as "modules" which I can assign to clients afterwards.
- as a result, a module like "stdlib" assigned to a client gets extracted into a subdirectory named "puppetlabs-stdlib-4.5.1", which breaks Puppet's mechanisms for dependent modules and classes lookups as they expect the module name "stdlib" to be the containing directory's name as well. I can work around this by modifying the archive and renaming the directory to "stdlib" prior to uploading it into the policy as a module.
- as another result, the execution of the Init class of the module named in the "Module Name" parameter of the policy is triggered on each refresh. If I place the module's own name there (e.g. "stdlib"), then stdlib::init is being executed without parameters, which does introduce issues with modules written to actually *do* things on init like writing configuration files. An example for this is trlinkin-nsswitch which would create (and overwrite) an nsswitch.conf with a stock (and in my case unusable) version upon execution without prior parametrization. I can work around this as well by either simply providing an invalid class name as the "Module Name" or by modifying the module's code. The first method will introduce reported errors upon each policy refresh, the second method is creating an administrative nightmare for us.

All of this is so inefficient compared to stock Puppet/Master configurations, that I believe I am doing it wrong. Can someone provide examples of how things could be done differently in Linux Policy environments?


An SR to work through this is likely the best way forward.
I personally do not have much puppet experience and I do not see lots of activity in this forum.
If others can help great, but I think it would be a disservice for me to try ping pong answers back and forth, which would likely still result in a less than ideal solution than if you worked directly wit folks who knew about puppet policies.
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.