[Spacewalk-list] Kickstart and Config management
William H. ten Bensel
WHTENBEN at up.com
Wed Mar 30 11:48:48 UTC 2016
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 <datakid at gmail.com>
To: spacewalk-list at redhat.com
Date: 03/30/2016 01:08 AM
Subject: Re: [Spacewalk-list] Kickstart and Config management
Sent by: spacewalk-list-bounces at redhat.com
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 <datakid at gmail.com> wrote:
On 30 March 2016 at 12:40, William H. ten Bensel <WHTENBEN at up.com> 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 <datakid at gmail.com>
To: spacewalk-list at redhat.com
Date: 03/29/2016 07:19 PM
Subject: Re: [Spacewalk-list] Kickstart and Config management
Sent by: spacewalk-list-bounces at redhat.com
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 <avi.miller at oracle.com> wrote:
> On 30 Mar 2016, at 10:30 AM, Lachlan Musicman <datakid at gmail.com> 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 at 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 at 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
Spacewalk-list at redhat.com
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
Spacewalk-list at redhat.com
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
Spacewalk-list at redhat.com
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
Spacewalk-list at redhat.com
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.
**
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20160330/18abcca2/attachment.htm>
More information about the Spacewalk-list
mailing list