Moving Satellite from 32-bit to 64-bit OS

Latest response

Our current Satellite (5.4.1) is running on a 32-bit RHEL5 box. We need to run on 64-bit if we're going to eventually move to 5.5 or 5.6 (eventually 6.0). Does anyone have any thoughts or recommendations as to which scenario would be better?

Scenario #1:

  1. Build a RHEL6 64-bit box
  2. Install Satellite
  3. Backup the old Satellite server
  4. Restore it onto the new one
  5. Decommission the old Satellite

or

Scenario #2:

  1. Build RHEL6 64-bit box
  2. Install Satellite
  3. Run side-by-side and register each server with new Satellite
  4. Once all servers are registered to new Satellite, decommission the old one

Or, perhaps there is an even better option?

Any feedback would be appreciated!! Thanks!!

Responses

In general, IMO the Scenario#1 you mentioned is much better compared to Scenario#2 unless you have a some reason to not migrate the old data to new server.

Registrations/system profiles using the new satellite server is just one part. But along with that if you do not do a restore of the database then you would loose out on the system profile's history, kickstart profiles, activation keys, groups, configuration files etc. So if you go ahead with Scenario#1 you will not loose any data. But if you do not care about other data and want to register the systems only to fetch updates then Scenario#2 would be better as it keep the satellite clean (without any unwanted data). But with this scenario it would have the additional task of re-registering the systems to the new satellite.

hth,
Paresh

Additionally for the detailed steps you can install the latest rhn-upgrade package and refer : /etc/sysconfig/rhn/satellite-upgrade/README which has the details describing various scenarios of upgrades.

Thanks, Paresh. I am a bit on the fence as I would like to keep the history (nor do I want to recreate all of the config files, custom channels, etc., but on the other had, I DO want to "clean things up" a bit as well. In the end, I think I'll lean toward scenario #1 just because cleaning things up may not be as great a benefit as avoiding all the work of building from scratch.

Hey Dan, First off - great question. I am about to go through the same exercise, which I am tweaking to actually be more of a passive DR/BC solution.
One thing I am wondering regarding what you propose - what types of things are you hoping to clean up? As I ponder this - there are 2 things I consider I will need to clean up (well 3, actually)
- things managed internal to Satellite (logs, hosts, profiles, configs)
- things that may have been part of Sat, but no longer are (i.e. if we created a custom channel, but since deleted it, yet there are RPMs in the cache directories
- /var/www/html content. Which is not really managed by Satellite, but was initially populated by Satellite (and we since have added more content to)

What things have I missed that I should consider migrating over? My ORG is at-risk currently as we don't have a clean/simple way to continue using Satellite if our main Sat System was to fail. My goal is to build the new system primarily with the Sat-specific data on the SAN, possibly to use snapshots.

Yes building from scratch would be a big task. As you are looking for cleaning things up, here are few suggestions you might want to do :
- delete-old-systems-interactive - delete inactive systems from Spacewalk server.
- Delete/Archive old completed/failed Actions under the Schedule Tab. There are API's to do it or you can do it through the web interface
- Delete duplicate system profiles - Under Systems -> Duplicate Systems page the list of such systems is displayed. You can verify and delete the duplicate systems.

Paresh,

Thanks a bunch for your input. I think that's the way I'm going to go and I'll go through the cleanup tasks you mention which should get me to just about the same situation (as far as cleanup goes) as a fresh install.

Close

Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.