Satellite

Satellite Server Automated Reboot

Automating the patch cycle with Satellite v6 series is not all that difficult, with one gotcha, rebooting.  My initial setup had a test to see if there were any patches that would require a reboot and if so reboot.  However, the servers did not reboot as expected.  It seems the remote execution process was skipping the reboot command due to some delay.  The fix is to issue the following command which provides enough of a delay to have the reboot command picked up and executed.  The same holds true when using the shutdown command.

echo restart host && sleep 3
reboot

 

hammer time

On a Satellite Server the Hammer command line management tool for provision hosts; editing the attributes; manipulating Satellite structures and mine for data. The annoying part of the hammer command is it (understandably) requires a username and password each time you issue the command. Something I would rather not expose in the bash history. So here is how to configure hammer so it doesn’t need to ask for the username and password.

Create the directory /root/.hammer (if you have used the command it should exist)

Create a file with a name “cli_config.yml” and put the following in the file:

:foreman:
 :host: 'https://satellite.server.url'
 :username: 'admin'
 :password: 'your-admin-password'

Make sure you set the permissions to secure this:

chmod 700 /root/.hammer
chmod 600 /root/.hammer/cli_config.yml

That is it!

Active Directory / LDAP for Satellite 6

Servers should be:
dcg5.grove.ad.uconn.edu
dcg2.grove.ad.uconn.edu
dcg1.grove.ad.uconn.edu

Ports:
LDAPS = 636
LDAP = 389

Account Username format for AD:
CN=satellite.ldap.svc,OU=Accounts,OU=Satellite,OU=Services,OU=SSG,OU=UConn,DC=grove,DC=ad,DC=uconn,DC=edu

Password for satellite.ldap.svc

Base DN:
DC=grove,DC=ad,DC=uconn,DC=edu

Groups base DN:  OU=Groups,OU=Satellite,OU=Services,OU=SSG,OU=UConn,DC=grove,DC=ad,DC=uconn,DC=edu

LDAP filter: (objectClass=User)

Satellite needed the following box checked:
“LDAP users will have their Satellite 6 account automatically created the first time they log into Satellite 6”.

Using redhat-support-tool in 10 space

OK, Private IP space, but you should know that 10 space means private IP space.

The command redhat-support-tool is useful when working with a Red Hat support ticket. Once a ticket is opened with Red Hat your next step should be to create and attach an sosreport to the ticket. If you don’t then you will waste valuable time as their first response will be, you guessed it, please attach an sosreport. Even attaching one is no guarantee they won’t still ask as they follow the script pretty closely.

The 90% use case for using the command redhat-support-tool is adding attachments, like this:

redhat-support-tool addattachment -c CASE_NUMBER /tmp/sosreport.tar.xz

If you have not configured /root/redhat-support-tool/redhat-support-tool.conf you will be prompted for your RHN user name and password.  Since I mentioned it please note that /root/redhat-support-tool contains your configuration file and a log file.  Please note: that if you configure global setting (more on that below) those settings are stored in /etc/redhat-support-tool.conf

Back to Private IP space use.  Supposedly you can configure this using the redhat-support-tool -> config option for example:

# redhat-support-tool
Command (? for help): config proxy_url proxy.your-url.domain

OR

# redhat-support-tool
Command (? for help): config proxy_url http://proxy.your-url.domain

OR setting it globally (sets it to /etc/redhat-support-tool.conf)

# redhat-support-tool
Command (? for help): config -g proxy_url http://proxy.your-url.domain

This however doesn’t always work, here is why with an explanation, thanks to my colleague Doug B:

I figured out the redhat-support-tool issue.

– It’s always connecting to proxy via https, so you have to use “http://proxy.url.edu:80” in order to force it.
– It may conflict with an http_proxy environment variable.

Even unsetting the variable within the tool (with –unset proxy_url) didn’t seem to clear out an incorrect entry – even though nothing was in the config file!

In the end it’s easiest to just to export http_proxy=http://proxy.url.edu:80 and not modify anything within the support tool itself.

As you can see a frustrating problem, yes we could have just transferred the file and uploaded it using the webUI or from another system but what would we have learned from that?!

Again, thanks to Doug B. for working with me on this.

Here is a link (account required) to more details about the redhat-support-tool: https://access.redhat.com/articles/445443

 

yum Invalid System Credential error

I ran across the following yum error after migrating a system from being a client of Satellite 5.6 to Satellite 6.1.  First here is the error:

# yum update
Loaded plugins: package_upload, priorities, rhnplugin, search-disabled-repos, security, subscription-manager
There was an error communicating with RHN.
RHN Satellite or RHN Classic support will be disabled.

Error Message:
    Please run rhn_register as root on this client
Error Class Code: 9
Error Class Info: Invalid System Credentials.
Explanation: 
     An error has occurred while processing your request. If this problem
     persists please enter a bug report at bugzilla.redhat.com.
     If you choose to submit the bug report, please be sure to include
     details of what you were trying to do when this error occurred and
     details on how to reproduce this problem.

Setting up Update Process
rhel-6-server-rpms                                                                                                                                                            | 2.0 kB     00:00     
rhel-6-server-satellite-tools-6.1-rpms                                                                                                                                        | 2.1 kB     00:00     
No Packages marked for Update
This left me scratching my head for a few and a quick search didn’t produce much so I thought I should document this for prosperity.
The problem was with the contents of the file /etc/yum/pluginconf.d/rhnplugin.conf
Part of my transition is running this command:
sed -i -e 's/enabled=1/enabled=0/g' /etc/yum/pluginconf.d/rhnplugin.conf
The problem was unlike all of my other systems, this file must have been edited because instead of containing “enabled=1” it contained “enabled = 1”
To correct that I modified my sed command to ignore white space:
sed -i -e 's/enabled\s*=\s*1/enabled=0/g' /etc/yum/pluginconf.d/rhnplugin.conf

More details can be found using the yum.conf man page.

Hope that is helpful.