Installation guide

Backup files are stored in the directory specified. Note that this is a cold backup; the database must be
stopped before running this command. This process takes several minutes. The first backup is a good
indicator of how long subsequent backups will take.
Once the backup is complete, return to root user mode and restart the database and related services
with the following command:
/usr/sbin/rhn-satellite start
You should then copy that backup to another system using rsync or another file-transfer utility. Red Hat
strongly recommends scheduling the backup process automatically using cron jobs. For instance, back
up the system at 3 a.m. and then copy the backup to the separate repository (partition, disk, or system)
at 6 a.m.
8.4.3. Verifying the Backup
Backing up the Embedded Database is useful only if you can ensure the integrity of the res ulting backup.
RHN DB Cont rol provides two methods for reviewing backups, one brief, one more detailed. To conduct
a quick check of the backup's timestamp and determine any missing files , issue this command as oracle:
db-control exami ne DIRNAME
To conduct a more thorough review, including running a checksum of each of the files in the backup,
issue this command as oracle:
db-control verify DIRNAME
8.4.4. Restoring the Database
RHN DB Cont rol makes Embedded Database restoration a relatively simple process. As in the creation
of backups, you will need to shut down the database and related services first by issuing the following
commands in this order as root:
/usr/sbin/rhn-satellite stop
Then switch to the oracle user and issue this command, including the directory containing the backup, to
begin the restoration:
db-control resto re DIRNAME
This not only restores the Embedded Database but firs t verifies the contents of the backup directory
using checksums. Once the restoration is complete, return to root user mode and restart the database
and related services with these commands in this order:
/usr/sbin/rhn-satellite start
8.5. Cloning the Satellite with Embedded DB
You may limit outages caused by hardware or other failures by cloning the Satellite with Embedded
Database in its entirety. The secondary Satellite machine can be prepared for use if the primary fails. To
clone the Satellite, perform these tasks:
1. Install RHN Satellite with Embedded Database (and a base install of Red Hat Enterprise Linux) on
a separate machine, skipping the SSL Certificate generation s tep.
2. Back up the primary Satellite's database daily using the commands described in Section 8.4 .2,
“Backing up the Database”. If this is done, only changes made the day of the failure will be lost.
3. Establish a mechanism to copy the backup to the secondary Satellite and keep these repositories
synchronized using a file transfer program such as rsync. If you're using a SAN, copying isn't
necessary.
4. Use RHN DB Cont rol's restore option to import the duplicate data.
5. If the primary Satellite fails, transfer the SSL key pair RPM package in /root/ssl-build from
the primary to the secondary Satellite, and install the package. T his ensures that RHN clients can
authenticate with and securely connect to the secondary Satellite.
6. Change DNS to point to the new machine or configure your load balancer appropriately.
8.6. Establishing Redundant Satellites with Stand-Alone DB
In keeping with the cloning option available to Satellite with Embedded Database, you may limit outages
on Satellites with Stand-Alone Database by preparing redundant Satellites . Unlike cloning a Satellite with
Embedded Database, redundant Satellites with Stand-Alone Database may be run as active, as well as
standby. This is entirely up to your network topology and is independent of the steps listed here.
To establish this redundancy, first install the primary Satellite normally, except the value specified in the
Common Name field for the SSL certificate must represent your high-availability configuration, rather than
the hos tname of the individual server. Then:
1. Prepare the Stand-Alone Database for failover using Oracle's recommendations for building a
fault-tolerant database. Consult your database administrator.
2. Install RHN Satellite with Stand-Alone Database (and a base install of Red Hat Enterprise Linux)
on a separate machine, skipping the database configuration, database schema, SSL certificate,
and bootstrap script generation steps. Include the same RHN account and database connection
information provided during the initial Satellite install and register the new Satellite.
If your original SSL certificate does not take your high-availability s olution into account, you may
create a new one with a more appropriate Common Name value now. In this case, you may also
generate a new bootstrap script that captures this new value.
3. After installation, copy the following files from the primary Satellite to the secondary Satellite:
/etc/rhn/rhn.conf
/etc/tnsnam es.ora
/var/www/rhns/server/secret/rhnSecret.py
4. Copy and install the server-side SSL certificate RPMs from the primary Satellite to the s econdary.
Refer to the Sharing Certificates section of the RHN Client Configuration Guide for precise
instructions. Remember, the Common Name value must represent the combined Satellite solution,
not a single machine's hostname.
If you generated a new SSL certificate during Satellite installation that included a new Common
Name value, copy the SSL certificate RPMs from the secondary to the primary Satellite and
redistribute the client-side certificate. If you also created another bootstrap script, you may us e
this to install the certificate on client sys tems.
5. If you did not create a new bootstrap script, copy the contents of
/var/www/html/pub/bootstrap/ from the primary Satellite to the secondary. If you did
generate a new one, copy that directory's contents to the primary Satellite.
6. Turn off the RHN T ask Engine on the secondary Satellite with the following command:
Chapter 8. Maintenance
37