Move Sat 5 clients to Sat 6 manually

Latest response

Currently, we have around 200 clients on Spacewalk ( dev/test/prod ). I tried moving few dev machines using script. However, the script does "yum -y update" on each host. I do not want to do yum update on prod machines right now. How can I move those clients manually to sat 6 instead of using script?

Responses does NOT by default fully update the system. It only does that if you pass the --update option. It does however, install subscription-manager (which is mandatory), and updates yum , openssl, and python (which are optional). If you do not want to update yum, openssl, and python you can pass the --skip prereq-update option.

Rich, Are we required to install virt-who on only Satellite 6 server or we can install virt-who on client which has been registered and connected to Sat 6? The reason I am asking is I installed virt-who on Sat 6 for one VCcenter server, however due to firewall I can't get to the other 2 VCenter servers from Sat 6, so, I was thinking installing virt-who for another 2 VCenter servers on the clients which can get to those VCenters. I appreciate your help. Thanks.

You can install virt-who on any system that can connect to both the Satellite and your vCenter. We generally recommend using your Satellite server just so that all of your management tools are in one location, but that is not mandatory.

Your suggestion of using clients that are in the same network zone as the vCenter is totally valid.

Hi Shisheer Guragain,

Here's what I did to migrate all my hosts from satellite 5.x to satellite 6.2.current.

  • Provision a Satellite server with all the content you need, create the necessary content views.

Disconnected satellite? First export a content view of the content view you require (Rich Jerrido has the best method that is superior to what is listed in the official documentation here

Connected Satellite (means a satellite that faces the public internet and you can attach your clients to it), then you just follow the traditional instructions Red Hat offers.

I will write this with the assumption you have a valid working Satellite server with all the necessary content views and a current set of recent content (all necessary rpm channels).

  • Make sure you don't have any one-off yum repositories that will get in the way of your satellite server repositories upon joining to your satellite server. This means go to /etc/yum.repos.d/ and validate your repository files there are not ancient, and work and do not have conflicts. -->In our specific case, there were a subset of servers with an unusual one-off python repository some ... individuals had installed and that repo was causing issues. You might not determine there are conflicts until after you attempt to perform yum operations after subscribing a system.

Create a content view for workstation, one for server and you may want to consider making a content view for dev/test/production based on your own organizations needs. They kinda touch on this in the official Red Hat Satellite training.

  • Since you are transitioning from satellite 5.x, you will want to make sure PRIOR to the migration to add the subscription-manager rpms to the systems you're transitioning - because if you don't have it, it would be easier to have it loaded prior to attempting to join it to your new satellite. Just in case there are yum repo issues or other unforeseen issues. Why not...

IMPORTANT: Make sure for whatever organization you go to assign the system to - that you have ingested the necessary manifest and properly ascribed the necessary entitlements.

Create activation keys that contain the necessary content views you created earlier, and an activation key for server, another for workstations, and if you need more, make more. This again goes to the needs of your organization. Where I work, we have one for workstation and another activation key for server, (an activation key for server for both rhel6 and rhel7 until we drop all of rhel6).

Ingest the official Red Hat gpg keys (if you haven't already) with the /bin/rpm --import /etc/pki/rpm-gpg/* ---while this ought to not be a problem, I've added it to my own kickstarts to make sure this is done at build.

I have a bootstrap script that detects what architecture a system is (rhel6, rhel7, server or workstation) and then based on that finding, does a number of things (I have "functions" in a bash script that are invoked based on a given systems architecture etc), such as...

  • I do an rpm -ivh http://IP_ADDRESS_OF_SAT_SERVER/pub/katello-ca-consumer-latest.noarch.rpm --force

  • In all cases, I install the "katello-ca-consumer-latest.noarch.rpm so that the satellite certificate is known before you actually attempt to register the system using the subscription-manager command he cited. This sets the stage for the subscription-manager command that adds it to your new satellite. see example below...

  • Runs subscription-manager command (example below) with the proper activation key.

I do this to register a rhel7 server, if I'm doing a rhel6 server, I have an activation key for that, for a workstation, I have a separate activation key named for workstation:

## some of these commands are long and may spill over to a new line
/sbin/subscription-manager register --org="YOUR_ACTUAL_ORG_NAME_GOES_HERE" --activationkey="rhel7server" --force 2>/tmp/err
yum -y install katello-agent

Hello, Thanks for the info. I will check and see if the same works for me.