[Spacewalk-list] Kickstart and Config management
Lachlan Musicman
datakid at gmail.com
Thu Mar 31 00:35:01 UTC 2016
On 30 March 2016 at 22:48, William H. ten Bensel <WHTENBEN at up.com> wrote:
> 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
>
Ok, this is what I got with current set up:
Thu Mar 31 11:05:08 AEDT 2016
Using server name emts-res-utils1
modified /etc/cntlm.conf
missing /etc/cron.d/15min
missing /etc/cron.quarter_hour/check_nfs_mounts.sh
missing /etc/munge/munge.key
missing /etc/profile.d/proxy.sh
missing /etc/samba/user
missing /etc/slurm/slurm.conf
missing /etc/slurm/slurmdbd.conf
Thu Mar 31 11:05:10 AEDT 2016
Using server name emts-res-utils1
/etc/cntlm.conf
/etc/cron.d/15min
/etc/cron.quarter_hour/check_nfs_mounts.sh
/etc/munge/munge.key
/etc/profile.d/proxy.sh
/etc/samba/user
/etc/slurm/slurm.conf
/etc/slurm/slurmdbd.conf
When I did the below exactly as you have it described, I got exactly the
same result - ie, for some reason, Spacewalk is not delivering the files
before I ratchet them in.
Note: The problem only exists when I do the first option in step 4, the
rebuild/re-kickstart. When I do the second option, it is successful - which
reflects that I can deploy manually after the server has installed and
first booted, not during the kickstart.
I can't see anything in the logs that would indicate where the Kickstart
process has attempted and failed to get the files. Would that error be
logged?
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.
>
------
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/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*
> <datakid at gmail.com>> wrote:
> On 30 March 2016 at 12:40, William H. ten Bensel <*WHTENBEN at up.com*
> <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* <datakid at gmail.com>>
> To: *spacewalk-list at redhat.com* <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*
> <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*
> <avi.miller at oracle.com>> wrote:
>
> > On 30 Mar 2016, at 10:30 AM, Lachlan Musicman <*datakid at gmail.com*
> <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* <http://www.oracle.com/>>
> Avi Miller | Product Management Director | *+61 (3) 8616 3496*
> <%2B61%20%283%29%208616%203496>
> Oracle Linux and Virtualization
> 417 St Kilda Road, Melbourne, Victoria 3004 Australia
>
>
> _______________________________________________
> Spacewalk-list mailing list
> *Spacewalk-list at redhat.com* <Spacewalk-list at redhat.com>
> *https://www.redhat.com/mailman/listinfo/spacewalk-list*
> <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* <Spacewalk-list at redhat.com>
> *https://www.redhat.com/mailman/listinfo/spacewalk-list*
> <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* <Spacewalk-list at redhat.com>
> *https://www.redhat.com/mailman/listinfo/spacewalk-list*
> <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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20160331/d228a480/attachment.htm>
More information about the Spacewalk-list
mailing list