Question about puppet forge module


I’m looking into utilizing your puppet module, but have been stuck with trying to figure out how to disable package install through the module. For example, the module tries to install logrotate, which is already declared in one of our custom modules and I want to leave in place. I’ve tried with hiera and profiles, but none of my attempts were successful. I would really appreciate your help.

Thank you.

Hi and welcome! @tdockendorf can you help us out on this?

@runlolarun I will be adding a parameter to disable logrotate management as the openondemand module uses a community module to handle logrotate rules. For now you can add this to Hiera:

logrotate::manage_package: false

This would require puppet/logrotate module at least version v3.2.0. If you don’t want to add the logrotate to your environment then you’ll have to wait for the change to openondemand module which should be released in a little bit

Thank you for a quick response!

Is it possible to fully disable package management?

I really appreciate your help.

I’ve released v0.11.0 of the openondemand module so now you can set manage_logrotate to false for the openondemand module and bypass the logrotate management. The rule will be left unmanaged as it’s still added by the RPM for OnDemand so if you are purging /etc/logrotate.d you will need to ensure you define empty /etc/logrotate.d/ood file to avoid purging.

When you say disable package management, what packages specifically? There is no trick in Puppet to disable all Package management, it’s up the the individual module authors to provider parameters to disable package management. For OnDemand are you installing the ondemand package outside the module? The only package management I can disable is the one that installs the actual ondemand package. There are also packages installed through the community Apache module and that module provides no way to disable package management like logrotate does. The best I could do for Apache is add another parameter to leave Apache unmanaged but then the openondemand module is essentially doing nothing.

Thank you, @tdockendorf for such a quick resolution. I will try by disabling only logrotate and see what happens. I already have apache module installed, so it’s not an issue.

I am not sure what other packages (outside of logrotate and ondemand) your module installs. I will reach out if I have any additional questions. Again, THANK YOU!

The only direct package we install is ondemand and optionally ondemand-selinux but the ondemand packages has a very long list of dependencies that will get pulled in from numerous repos.

Indirect packages from module dependencies

  • subscription-manager for RHEL systems (not CentOS)
  • Numerous Apache packages but sounds like that’s a non issue for you
  • sudo
  • logrotate

Thank you. We do not use sudo either. Can I disable it the same way?

Question about subscription-manager. We are running our own OS (RHEL based). I do have RHEL subscription to access bug reports mostly. Will it still work?

Thank you!

Do you manage sudo at all with Puppet? Most community Puppet modules for sudo will purge /etc/sudoers.d of unmanaged files so disabling OnDemand module sudo rule would break OnDemand. Changing the behavior of sudo rule is different than logrotate as OnDemand requires sudo while OnDemand does not technically require logrotate. The sudo management will only cause a problem if you have package { 'sudo': ... } defined somewhere in your profiles or modules. If you do that it might be good to add a manage_sudo flag to those places to allow ondemands sudo management to be used and your local management disabled in that one case, if possible. If that won’t work for you I can add a manage_sudo paramater to the puppet module for ondemand but you’d have to ensure the appropriate sudo rule gets added.

As long as your systems have access to base OS repos and SCL repos, they will work just fine, subscription-manager is only required for RHEL systems to enable the SCL repos. For CentOS this is handled by installing the centos-release-scl package. OnDemand doesn’t care how you get your packages, just as long as they are all there to meet dependencies.

Thank you, @tdockendorf.

Now I am getting the following error message:

Notice: /Stage[main]/Openondemand::Install/Package[ondemand]: Dependency Rhsm_repo[rhel-server-rhscl-7-rpms] has failures: true

I haven’t looked into it further but just wanted to make you aware. We are running Springdale:

Regarding sudo, I can disable any changes with:

  class { 'sudo':
    purge               => false,
    config_file_replace => false,

Thank you again!

The error you provided means something before that dependency had a failure so you’ll need to look at logs before that entry to see what the actual failure was. I’m guessing the enabling of SCL repo failed.

Is this a RedHat host or an OS based on RedHat? If this is a RedHat host then the module expects to enable the SCL repo via subscription-manager. If that is done elsewhere in your environment then you’ll have to set openondemand::manage_scl: false in Hiera. The repo enabled is rhel-server-rhscl-7-rpms for RHEL7 , so you have to make sure that repo is accessible to your RedHat host.

Also with this module those changes to sudo should not be necessary, in fact I would not recommend them as not purging unmanaged sudo rules can lead to security issues and unexpected sudo entries lingering around.

If you have some packages defined in a profile class somewhere and don’t want conflicts you can do something like this:

$packages.each |$package| {
  if ! defined(Package[$package]) {
      package { $package: ensure => 'installed' }

This would just require that the profile class doing this is included AFTER all other profile classes otherwise the define() function won’t actually help. I don’t recommend this approach because it’s very dependent on order of classes which is not good Puppet best practice. Puppet is supposed to not care about order things are defined and order should instead be set by things like require or before parameters.

@tdockendorf: it seems like rhel-server-rhscl-7-rpms is part of the RedHat subscription services, which we don’t have. This is RedHat based OS, but not a RedHat. The module is looking for the subscription to install necessary packages.

$ facter os
   architecture => "x86_64",
   family => "RedHat",
   hardware => "x86_64",
   name => "RedHat",
   release => {
     full => "7.8",
     major => "7",
     minor => "8"

$ cat /etc/redhat-release
 Springdale Linux release 7.8 (Verona)

Thank you!

I think the issue is Springdale reports as being RedHat which is incorrect. Things like CentOS would have fact be CentOS. How does Springdale get access to SCL repos?

If Springdale does provide SCL repos you will have to enable them in a profile class and set manage_scl => false for openondemand module. Be sure that your method for adding SCL repos comes before Package['ondemand'].

If Springdale does not provide SCL you might be able to use CentOS’s repo file like this:

yum install \ \ 

You would still need to set manage_scl => false for openondemand. You can install RPMs from URLs using Puppet:

package { 'centos-release-scl-rh':
  ensure => 'installed',
  source => '',
  provider => 'rpm',
-> package { 'centos-release-scl':
  ensure => 'installed',
  source => '',
  provider => 'rpm',

We do have SCL packages, but they are all local from a local repo.

What exactly does the module get from SCL? http is not SCL. Sorry for bombarding you with questions.

Thank you.

In that case you will need to set manage_scl => false for openondemand module.

The puppet module just installs the ondemand RPM and that RPM has dependencies on numerous SCL packages for Apache, Ruby and Nodejs.

Thank you! Got a lot further now and all necessary packages. Really appreciate your help!

Have a wonderful day.