[Spacewalk-list] Kickstart and Config management

Thu Mar 31 02:07:22 UTC 2016

So, Step 4 part 2 is good.  Which means that the activation key is setup 
correctly.  I am uncertain of the logging as we no longer use or depend on 
the activation key deploying files during the kickstart process. 

Also, some explanation on the "hack".  These are all historical issues for 
our needs.  They may have been fixed in newer spacewalk releases, we just 
have not adopted them.

1. Timing.
        The files from the Activation key/Configuration channels were not 
always immediately available in the first %post script that the file/files 
were needed.  If we put a sleep 90, then the files would become available.
        Determined that the "hack" was better suited for our needs vs the 
sleep.
        Note: RHEL/CentOS 4 (if anyone is still kickstarting/building), 
have to re-run the hack twice.  Sometimes rhncfg-client get fails to 
actually get all of the files the first time.
2. Backups.
        The activation key does not make backups (that we could find) of 
the original files replaced. Honestly we did not spend much time looking 
for them, so I may be mistaken in this comment.
        rhncfg-client get backup location -> /var/lib/rhncfg/backups/
3. Migrating servers from one Satellite/Spacewalk to another 
Satellite/Spacewalk (Migration of thousands of servers in < 30 days and 
still having the Spacewalks and Satellites available for new server 
builds)
        Re-use of the standard activation key vs creating a "migration 
one" to rhnreg_ks --force, when migrating
        If the activation key on the new Spacewalk/Satellite has 
Configuration File Deployment checked in the Activation key, it will 
override ANY local file that was modified outside of the config channel. 
We did not want this..
        Determined that for our needs, it was better to have Configuration 
File Deployment NOT checked, because we can use the "hack"
        If any of the files in a configuration channel needs to be pushed, 
you can use the UI or run a spacecmd script with rhncfg-client get file. 
The config will be pushed the next time the server checks in with rhnsd 
(rhn_check) or immediately if using osad. 

Suggestion: Create a wrapper around this which sources in the 
username/password/spacewalk server, so that it is not visible in bash 
history.
spacecmd -s $myspacewalk -u $myuser -p $mypass -- system_runscript 
$serverlist -u root -g root -t 7200 -f $myfile
file:
#!/bin/bash
rhncfg-client get file
- Thanks and good luck

From:   Lachlan Musicman <datakid at gmail.com>
To:     spacewalk-list at redhat.com
Date:   03/30/2016 07:49 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 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

**

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/929f63e2/attachment.htm>