Thank you for the reply David. We are not using Spacewalk to kickstart servers, as we have another server for that. For now, we just want to use it for patching management. I'm just learning to use Spacewalk and we have a pretty simple channel setup.
Centos6 (base) |_ centos6-updates |_ spacewalk27 |_ epel Centos7 |_ centos7-base |_ centos7-updates |_ spacewalk27 |_ epel I plan to add ULN channels as well. It sounds like doing what you suggested and having an activation key for each OS and register with the appropriate key is probably the easiest. Thanks again. Nicole -----Original Message----- From: spacewalk-list-boun...@redhat.com <spacewalk-list-boun...@redhat.com> On Behalf Of David Rock Sent: Wednesday, March 21, 2018 4:04 PM To: spacewalk-list@redhat.com Subject: Re: [Spacewalk-list] activation keys > On Mar 21, 2018, at 14:02, Nicole Beck <nsky...@syr.edu> wrote: > > Hello, > I’m looking for recommendations for setting up activation keys. Do you > normally have an activation key set for each OS version(centos6, centos7) , > and specify the appropriate base and child channels in each? I tested this, > and registering the client with “rhnreg_ks” and the appropriate key, and I my > client is subscribed to the expected channels. > > I’m also testing the “Spacewalk Default” base channel and the “Universal > Default” key, and it’s not working as I expect it to. Is there a way to > setup a “generic” spacewalk activation key so that client registering with it > is subscribed to the channels for the correct OS version? I’m thinking of > something analogous to using “rhn_register” to register a RH server with the > old RHN, or an Oracle Enterprise Server with ULN, you type in your username > and password, and something behind the scenes figures out what OS version is > installed and subscribes you to the correct channels. Is that what > “Spacewalk Default” and “Universal Default” do, or am I misunderstanding it. > I’ve created base and child channels for centos-6 and centos-7, but I don’t > have a channel named “Spacewalk Default”. > The main thing you have to be careful of is if you have config channel priorities in multiple keys. The system has no logic to determine relative priority, so last key in wins, but the order they get applied is undetermined. If you aren’t trying to manage complicated config channels, making one for the base OS, and one for “other stuff” will work ok. We created a single key that has everything for each type to avoid any confusion (we were originally getting oracle-specific configs overwritten by the more generic configs, which caused issues when we tried to get too fancy with the keys). The Spacewalk Default and Universal Defaults are not what you want. The best way to get what you expect to get is create a key for each OS that contains the parent/child channels you want to apply and use that in the KS profile. The basic workflow at build time is: 1. use the GA release from the kickstart tree in the KS profile to install the base os 2. apply the activation key with the related clone channels, etc 3. yum update to bring everything up to current that’s in your clone channel — David Rock da...@graniteweb.com _______________________________________________ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list _______________________________________________ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
