Replacing Satellite 6.6.2 Server with 6.10 Server
I have a Satellite 6.6.2 server in our production environment. Since 6.6.2 is longer supported we are moving to a Satellite 6.10 server. I have already previsioned a vm RHEL 7.6 server and installed Satellite 6.10 on it. I exported the manifest from Redhat.com and imported it to the 6.10 satellite server
I am confused on how to move the satellite clients over to the new satellite without causing a disruption. What are the steps to start with a test RHEL server to move it over to the new satellite 6.10 server? Would I just re-subscribe the client to the Satellite 6.10 server or are there other steps that are required?
I have already secured a new ssl cert but when I applied it on the server I was able continue access the satellite server via the i.p. address but could not access the satellite server through the dns name.
Also I want to verify that the curl kello portion will not be a problem. I thought that the virt-who server would be a concern for the hypervisor but it appears that there are no steps need for virt-who consideration from a satellite 6.6.2 to
a satellite 6.10 server
I don't see a lot of info on this process but because we only have 60+/- clients we chose to spin up a new satellite server and then migrate the clients as oppose to upgrading for each release of Satellite server to get to the current version
I know that there was a bootstrap process but I believe it is now depricated
Any help and suggestions on the subject would be greatly appreciated
Responses
Hi, unsubscribing the Content Hosts from the old Satellite just before subscribing to the new one would help you keep track of what you still need to do.
While bootstrap.py should still work the new global registration service, using the curl command, is being improved all the time.
Using the DNS name is important for many functions within Satellite Server as they depend on certificate authentication so I would concentrate on getting that working. Once you have that working, you will be ready to upgrade to Sat6.11 for all its speed improvements.
6.10 has a pretty easy-to-use 'curl-command' generator (in the UI, Hosts->Register Host) that I recently used with great success to import a few external RHEL7 servers into Satellite as content hosts. It requires that you have activation keys configured. It seems well-suited for doing a handful of servers at a time, 60+ could be slightly arduous. As mentioned above, the content hosts need to be unsubscribed from the existing Satellite server. I also removed each content host's 'katello-ca-consumer' package as well, since the curl command will install one for your new Satellite 6.10 server.
Hi, not sure what you mean by exporting the manifest, never been able to do that myself. I think you should create a new manifest for the new Satellite in your account in the Red Hat customer portal and leave the old one as is for the moment. If required, you could reduce the entitlements for the old manifest as you move systems across.
Are those subscriptions still allocated to your old Satellite server? If so, I would think that they would not be available to be applied to the new server.
Un-registering is mostly a matter of running 'subscription-manager unregister' on the hosts and then removing their 'katello-ca-consumer' certificate package (yum remove katello-ca-consumer-your_old_satellite_uri) which is pointing them to the old satellite as a subscription/content provider. Once you do that you should be able to install the certificate package from your new satellite server (yum install katello-ca-certificate-your_new_satellite_uri) and then register them with subscription-manager, specifying the activation key. The curl command utility I mentioned above largely automates registering the content hosts.
Hi, take a look at the Creating a Content View section of the Content Management Guide . You say there were no packages in your Content View, I wonder did you, as per step 2, "Add one or more repositories that you want to the Content View"? Did you sync some repos after adding the manifest? See Enabling Red Hat Repositories in the same guide.