That is a "hack" work around. After the 1-3 steps below is done, add this before and after the "hack" to add some validation in the %post script. This should see/validate if the activation key is pushing the files as expected while the server is being kickstarted/built. date > /root/verify_configs.out rhncfg-client verify >> /root/verify_configs.out "hack" date >> /root/verify_configs.out rhncfg-client verify >> /root/verify_configs.out
The bug that caused the "touch /var/log/rhncfg-actions" is fixed, however we have kept it in our scripts as it does not cause any issues. https://bugzilla.redhat.com/show_bug.cgi?id=1006480 Note: To prevent updating multiple kickstarts when you need to add/remove software to ie: rhn, or base software, you can use snippets in kickstart profile -> Software. So, if you plan on using the same software across multiple kickstarts (ie. The rhn software), you would only have to update one file without updating all of the kickstarts. ie: @ Base $SNIPPET('spacewalk/1/rhnsoftware') File location: (/var/lib/rhn/kickstarts/snipppets/1/rhnsoftware) 1. Now lets concentrate on resetting the activation key: For each activation key that you want config files pushed when a system activates/registers with this key: Systems -> Activation Keys -> {activation key} -> details -> take note of the key (ie: {org#}-{what you named it} or {some long number}) Systems -> Activation Keys -> {activation key} -> details -> uncheck Configuration File Deployment. Select: Update Activation key then recheck Configuration File Deployment Select: Update Activation key Validate that the Config channels are part of this activation key. Systems -> Activation Keys -> {activation key} -> Configuration 2. Now go to the kickstart: Systems -> kickstarts -> profiles -> {profile name} -> Activation Keys -> uncheck the key Select: Update Activation keys then recheck the key Select: Update Activation keys 3. Validate that the kickstart has been updated: Systems -> kickstarts -> profiles -> {profile name} -> Kickstart File Verify AND take note of the Activation key(s) is there. You will use those in re-registration. ie: key=1-xxxxxxxxxxxxxxxxx,1-yourkey 4. Now you can do the following: Re-kickstart / rebuild the server with the kickstart. OR add a test file to the configuration channel that is NOT on the server. delete the server from the Spacewalk force register from the server: rhnreg_ks --force --serverUrl=https://spacewalk.server.domain/XMLRPC --sslCACert=/usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT --activationkey="keys from kickstart" validate the file is on the server. (This will tell you if the activation key is pushing the files as expected with the above configuration) Remove test file from the configuration channel. - Thanks and good luck From: Lachlan Musicman <[email protected]> To: [email protected] Date: 03/30/2016 01:08 AM Subject: Re: [Spacewalk-list] Kickstart and Config management Sent by: [email protected] This email originated from outside of the company. Please use discretion if opening attachments or clicking on links. Now I'm confused. I've set up the config channel, I've set up an activation key, I've associated both to the kickstart profile, without success. I have not been able to find any mention of /var/log/rhncfg-actions in any documentation, although I do now touch it in a post installation script. This doesn't work with regard to getting the managed files to deploy to the newly installed server. Various helpful responders have mentioned forcing and/or checking that the files have deployed during installation (*well, after installation, but before reboot). What I have found that works is the post script that William posted for myconfigs in `rhncfg-client list |egrep -v "myspacewalk.server.domain|Config Channel" |awk '{print $3}'`; do rhncfg-client get $myconfigs thanks. Was it always the case that I should have had something like this, or is this a hack to get around the "something isn't working, but we don't know what it is" problem? I don't mind - I am happy to have it working :) L. ------ The most dangerous phrase in the language is, "We've always done it this way." - Grace Hopper On 30 March 2016 at 13:19, Lachlan Musicman <[email protected]> wrote: On 30 March 2016 at 12:40, William H. ten Bensel <[email protected]> wrote: *Deployed*... Does that mean activate/re-activate OR the installation of the rpms did not get the files OR an rhncfg-client get failed? Sorry, I'm not 100% with the lingo yet. Deployed in that context meant "kickstart install on just provisioned bare metal vm, via cobbler" Activate/re-activate should have pushed the files. Installation of the rpms by themselves, will not push the files. rhncfg-client get or a schedule through the UI, api, or spacecmd. Right. Late last week I moved the installation of the rhncfg-* files from the Configuration Channel to the Kickstart profile "Software" tab, in order to confirm that the rpms were installed before the Configuration Channel kicked in? This are some of the options you can do in the kickstart: 1. Ensure that the rpms Avi gave are installed. 2. This has been part of our default kickstart for years. # Per rhncfg-client documentation, the first get or deploy of files can fail if this file does not exist. # The work around is either reschedule, rerun, or touch the file touch /var/log/rhncfg-actions Ah, I'll try this now. I am putting it into an early run post-install script - is that what you are suggesting here? OR do you put this in the Kickstart Details -> Advanced options ? 3. In a %post script, verify all of the files were deployed. for myconfigs in `rhncfg-client list |egrep -v "myspacewalk.server.domain|Config Channel" |awk '{print $3}'`; do rhncfg-client get $myconfigs done Hmmm. ok - I'll test. Thanks cheers L. ------ The most dangerous phrase in the language is, "We've always done it this way." - Grace Hopper From: Lachlan Musicman <[email protected]> To: [email protected] Date: 03/29/2016 07:19 PM Subject: Re: [Spacewalk-list] Kickstart and Config management Sent by: [email protected] This email originated from outside of the company. Please use discretion if opening attachments or clicking on links. On 30 March 2016 at 10:43, Avi Miller <[email protected]> wrote: > On 30 Mar 2016, at 10:30 AM, Lachlan Musicman <[email protected]> wrote: > > > If this doesn't work, where should I look for information on why? I'm not seeing anything in the log files. Post-provisioning, check that you have the following RPMs installed: rhncfg-management rhncfg-client rhncfg rhncfg-actions And check that configuration management is allowed: # rhn-actions-control --report deploy is enabled diff is enabled upload is enabled mtime_upload is enabled run is enabled If you don't have the RPMs, the rhn-actions-control won't work. If you're not installing the RPMs as part of the provisioning process (i.e. if they're not available in any channel enabled for kickstart), then the enabling options won't work. Thanks Avi. Here's the output on a machine that I *just* deployed: [root@vmpr-res-head-node ~]# rpm -qa | grep rhncfg rhncfg-5.10.85-1.el7.noarch rhncfg-actions-5.10.85-1.el7.noarch rhncfg-client-5.10.85-1.el7.noarch rhncfg-management-5.10.85-1.el7.noarch [root@vmpr-res-head-node ~]# rhn-actions-control --report deploy is enabled diff is enabled upload is enabled mtime_upload is enabled run is enabled So everything looks right from that perspective. But, no file deployment? Hmmm.. ------ The most dangerous phrase in the language is, "We've always done it this way." - Grace Hopper Cheers, Avi -- Oracle <http://www.oracle.com> Avi Miller | Product Management Director | +61 (3) 8616 3496 Oracle Linux and Virtualization 417 St Kilda Road, Melbourne, Victoria 3004 Australia _______________________________________________ Spacewalk-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/spacewalk-list This email originated from outside of the company. Please use discretion if opening attachments or clicking on links. _______________________________________________ Spacewalk-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/spacewalk-list ** This email and any attachments may contain information that is confidential and/or privileged for the sole use of the intended recipient. Any use, review, disclosure, copying, distribution or reliance by others, and any forwarding of this email or its contents, without the express permission of the sender is strictly prohibited by law. If you are not the intended recipient, please contact the sender immediately, delete the e-mail and destroy all copies. ** _______________________________________________ Spacewalk-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/spacewalk-list This email originated from outside of the company. Please use discretion if opening attachments or clicking on links. _______________________________________________ Spacewalk-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/spacewalk-list ** This email and any attachments may contain information that is confidential and/or privileged for the sole use of the intended recipient. Any use, review, disclosure, copying, distribution or reliance by others, and any forwarding of this email or its contents, without the express permission of the sender is strictly prohibited by law. If you are not the intended recipient, please contact the sender immediately, delete the e-mail and destroy all copies. **
_______________________________________________ Spacewalk-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/spacewalk-list
