What happened to Software Channels in Satellite 6?

Latest response

Is there any builtin feature to apply a package baseline to a group of hosts?

In Satellite 5 we had the Software Channels which were useful when you wanted to bring new and existing hosts to a desired RPM baseline.
This feature has not been kept in Satellite 6.

The closest feature I've found is the bulk actions under Host Collection, but that's a one-off momentary action and not a desired state / declarative measure.

I suspect that the real answer is "puppet" but that leaves a pretty huge gap in the out-of-box product, and a lot of (imo) unnecessary wheel reinventing as every org migrating to satellite 6 have to figure this out on their own.

Is there a common, well-documented practice or did this particular ball simply fly past as everyone wanted to work on containers?

Responses

Hello, please see the Transitioning Custom and Cloned Channels to Content Views section of the Red Hat Satellite 6 Transition Guide.

'hammer import' is OBE after 6.2. Unfortunately Puppet is the answer and a sad one at that.
Since software channels may change and if you re-published the clone/snapshot, the new clone/snapshot is the latest and greatest since last sync - which would defeat the purpose of a snapshot/clone of rpms. To get around this create a separate non-composite puppet content view, then create a new content view (i.e. baselinexyz) that includes this new puppet content view and the clone/snapshot content view - select auto-publish. When you change the puppet files, the new composite content view (baselinexyz) will be updated with the puppet changes only. Subscribe your client to this composite content view (baselinexyz) and run 'puppet agent -tv' to pull the changes to the clients like you did with sat5.x rhncfg-client commands.

For those who don't 'speak puppet' - here's a quick hack I came up with to push out 3 files using puppet: [/etc/sudoers.d/20-library-users, /etc/sudoers.d/90-admin-users, and /root/.ssh/authorized_keys]

  • Run 'puppet module generate username-name_of_module_no_dashes' - (i.e. puppet module generate grawl-common_files). This creates a puppet directory structure /etc/puppetlabs/code/modules/common_files

  • Edit /etc/puppetlabs/code/modules/common_files/manifests/init.pp to contains class ‘common_files’ and sub-classes sudoers and authorized_keys:

class common_files {
  include 'common_files::sudoers'
  include 'common_files::authorized_keys'
}
  • Then create the 2 sub-class .pp files also in the manifest directory with the permission info of the files. /etc/puppetlabs/code/modules/common_files/manifests/sudoers.pp:
class common_files::sudoers {
  file { '/etc/sudoers.d/20-library-users':
        mode => '0600',
        owner => 'root',
        group => 'root',
        source => 'puppet:///modules/common_files/20-library-users',
  }
  file { '/etc/sudoers.d/90-admin-users':
        mode => '0600',
        owner => 'root',
        group => 'root',
        source => 'puppet:///modules/common_files/90-admin-users',
  }
}

/etc/puppetlabs/code/modules/common_files/manifests/authorized_keys.pp:

class common_files::authorized_keys {
  file { '/root/.ssh/authorized_keys':
        mode => '0600',
        owner => 'root',
        group => 'root',
        source => 'puppet:///modules/common_files/authorized_keys',
  }
  • Then placed the 3 files (20-library-users, 90-admin-users, and authorized_keys) in the /etc/puppetlabs/code/modules/common_files/files/ directory.

  • Test the module w/o installing any of the files (-noop) by running the example/init.pp that is created module generate command. Note: The .pp file syntax is very strict – just like ansible.

cd /etc/puppetlabs/code/modules; 
puppet apply --modulepath=/etc/puppetlabs/code/modules common_files/examples/init.pp –noop
#Notice: Compiled catalog for rhnsat6-udtf.devlnk.net in environment production in 0.03 seconds
#Notice: /Stage[main]/Common_files::Sudoers/File[/etc/sudoers.d/20-library-users]/ensure: current_value 'absent', should be 'file' (noop)
#Notice: /Stage[main]/Common_files::Sudoers/File[/etc/sudoers.d/90-admin-users]/ensure: current_value 'absent', should be 'file' (noop)
#Notice: Class[Common_files::Sudoers]: Would have triggered 'refresh' from 2 events
#Notice: /Stage[main]/Common_files::Authorized_keys/File[/root/.ssh/authorized_keys]/ensure: current_value 'absent', should be 'file' (noop)
#Notice: Class[Common_files::Authorized_keys]: Would have triggered 'refresh' from 1 event
#Notice: Stage[main]: Would have triggered 'refresh' from 2 events
#Notice: Applied catalog in 0.62 seconds
  • If it ran successfully you now can build it and upload the tgz file that’s created in the pkg directory to the puppet module Content View created in prior post.
'puppet module build common_files'
Note: If you make changes the version info should be updated – all of that data is stored in the metadata.json, edit as needed before ‘building’. Hope this helps someone break through the poor puppet documentation from Redhat and on the web. Seems like there are only 3 examples everyone uses. Good luck!