Language:
Format:

Red Hat Training

A Red Hat training course is available for Red Hat Satellite

Installation Guide

Red Hat Network Satellite 5.5

Red Hat Network Satellite

Edition 3

Daniel Macpherson

Red Hat Engineering Content Services

dmacpher@redhat.com

Lana Brindley

Red Hat Engineering Content Services

lbrindle@redhat.com

Athene Chan

Red Hat Engineering Content Services

achan@redhat.com

Legal Notice

Abstract

Welcome to the Red Hat Network Satellite Installation Guide.

Preface

Red Hat Network Satellite description.

1. About This Guide

This guide explains how to install Red Hat Network Satellite, including initial installation, configuration, entitlements management and package synchronization.

2. Audience

The target audience for this guide includes system administrators who aim to manage updates for systems within an internal network.

Chapter 1. Introduction

This guide provides instructions for a full installation of a Red Hat Network Satellite server. This includes installation, configuration, connection to Red Hat Network, subscription management and content synchronization.

1.1. About Red Hat Network Satellite

Red Hat Network is the environment for system-level support and management of Red Hat systems and networks of systems. Red Hat Network brings together tools, services, and information repositories needed to maximize the reliability, security, and performance of their systems. System administrators use Red Hat Network to register software and hardware profiles for their client systems. These hardware and software profiles are called system profiles. When a client system requests package updates, Red Hat Network returns only the applicable packages for the client based upon the profile stored on the Red Hat Network Servers.

Red Hat Network Satellite provides organizations with the benefits of Red Hat Network without the need for public Internet access for servers or client systems. In addition, users of Red Hat Network Satellite can:

Maintain complete control and privacy over package management and server maintenance within their own networks;
Store System Profiles on a Satellite server, which connect to the Red Hat Network website via a local web server; and,
Perform package management tasks, including errata updates, through the local area network.

This gives Red Hat Network customers the greatest flexibility and power to keep servers secure and up-to-date.

Two types of Red Hat Network Satellite are available:

Stand-Alone Database — One with a stand-alone database on a separate machine; and
Embedded Database — One with an embedded database installed on the same machine as the Satellite.

This guide describes the installation of both types of Satellite.

Although the two types of Red Hat Network Satellite are functionally similar, some differences do exist. These variations are primarily limited to hardware requirements, installation steps, maintenance activities, and some troubleshooting steps. This guide identifies distinctions between the Satellite types by marking the differing instructions as either Stand-Alone Database or Embedded Database.

1.2. System Overview

Satellite consists of the following components:

Database

Satellite functions using two database types:

Stand-Alone Database — An organization's existing database or, preferably, a separate machine. Satellite supports Oracle Database 11g Release 2, Standard or Enterprise Edition for the stand-alone database.
Embedded Database — The database comes bundled with Satellite and is installed on the same machine as the Satellite during the installation process. The included database is Oracle Database 10g Release 2.

Satellite Core

The core system and entry point for Red Hat Update Agent running on client systems. Satellite also includes an Apache HTTP Server, which serves XML-RPC requests.

Satellite Web Interface

A user interface for advanced system, system group, user, and channel management. The organization configures access to the Satellite web interface from the local area network only or from both the local area network and the Internet. The Satellite's version of the Red Hat Network website allows full control over client systems, system groups, and users.

RPM Repository

Package repository for Red Hat RPM packages and custom RPM packages identified by the organization.

Management Tools

The Satellite Management Tools are used to synchronize the Satellite database and package repository with Red Hat Network. Satellite also includes management tools for:

Database and file system synchronization;
Custom RPM and repository imports;
Channel maintenance (Web-based);
Errata management (Web-based);
User management (Web-based); and
Client system and system grouping (Web-based).

Red Hat Update Agent

Reconfigure Red Hat Update Agent on client systems to retrieve updates from the organization's internal Satellite instead of the central Red Hat Network Servers. After this one-time reconfiguration, client systems retrieve updates locally using the Red Hat Update Agent. System administrators also schedule actions through the Satellite Web Interface.

Important

Red Hat strongly recommends that clients connected to Satellite be running the latest update of Red Hat Enterprise Linux to ensure proper connectivity.

When a client requests updates, the organization's internal Satellite queries its database, authenticates the client system, identifies the updated packages available for the client system, and sends the requested RPMs back to the client system. The client also installs the packages if set in preferences. If the packages are installed, the client system sends an updated package profile to the database on the Satellite. Those packages are removed from the list of outdated packages for the client.

Satellite can be used in conjunction with Red Hat Network Proxy Server to deliver a distributed, self-contained Red Hat Network deployment for the organization. For example, an organization can maintain one Satellite in a secure location and Red Hat systems connect to it via local network access connect. Other remote offices maintain Red Hat Network Proxy Server installations that connect to the Satellite. The different locations inside the organization require a networked connection, but this can be a private network; an Internet connection is not required for any of the systems. Refer to the Red Hat Network Proxy Server Installation Guide for more information.

Figure 1.1. Using Satellite and Red Hat Network Proxy Server Together

1.3. Terms to Understand

Before understanding Red Hat Network Satellite, it is important to become familiar with the following Red Hat Network terms:

Channel: A Channel is a list of software packages. There are two types of channels: base channels and child channels. A base channel consists of a list of packages based on a specific architecture and Red Hat release. A child channel is a channel associated with a base channel that contains extra packages.
Organization Administrator: An Organization Administrator is a user role with the highest level of control over an organization's Red Hat Network account. Members of this role can add other users, systems, and system groups to the organization as well as remove them. A Red Hat Network organization must have at least one Organization Administrator.
Channel Administrator: A Channel Administrator is a user role with full access to channel management capabilities. Users with this role are capable of creating channels, assigning packages to channels, cloning channels, and deleting channels. This role can be assigned by an Organization Administrator through the Users tab of the Red Hat Network website.
Certificate Authority: A Certificate Authority distributes digital signatures to users as part of public key infrastructure for encrypted authentication and communication.
Red Hat Update Agent: The Red Hat Update Agent is the Red Hat Network client application that allows users to retrieve and install new or updated packages for the client system on which the application is run.
Traceback: A Traceback is a detailed description of "what went wrong" that is useful for troubleshooting the Red Hat Network Satellite. Tracebacks are automatically generated when a critical error occurs and are mailed to the individual(s) designated in the Red Hat Network Satellite's configuration file.

For more detailed explanations of these terms and others, refer to the Red Hat Network Reference Guide.

1.4. Summary of Steps

A functional Red Hat Network Satellite requires more than installing software and a database. Client systems require configuration to use the Satellite. Creation of custom channels for custom packages is recommended. Since these tasks extend beyond the basic installation, they are covered in detail in other guides, as well as this Red Hat Network Satellite Installation Guide. For a full list of the necessary technical documents, refer to Chapter 2, Requirements.

For this reason, this section seeks to provide a definitive list of all required and recommended steps, from evaluation through custom package deployment. They should take place in this order:

Obtaining Satellite
1. After an evaluation, contact your Red Hat sales representative to purchase Red Hat Network Satellite.
2. Receive a Red Hat Network Entitlement Certificate and login information for Red Hat Network from your sales representative.
3. Log into the Red Hat Network website (rhn.redhat.com) and download the distribution ISOs for Red Hat Enterprise Linux 5 or 6 and Red Hat Network Satellite. These can be found within the Downloads tab of the respective Channel Details pages. Refer to the Red Hat Network Reference Guide for instructions.
4. While still logged into the Red Hat Network website, download the Channel Content ISOs to be served by your Satellite, also available through the Downloads tab of your Satellite's Channel Details page. These Channel Content ISOs differ from the distribution ISOs previously mentioned in that they contain metadata necessary for parsing and serving packages by Satellite.
Preparing Satellite
1. Check your software requirements. See Section 2.1, “Software Requirements”.
2. If installing a Stand-Alone Database, check your hardware fits the requirements in Section 2.2, “Stand-Alone Database Requirements” and prepare your database instance using the formula provided in Section 2.2.3, “Database Requirements for Stand-Alone Database Installations”.
3. If installing an Embedded Database, check that your hardware fits the requirements in Section 2.3, “Embedded Database Requirements”.
Installing Satellite
1. Install Red Hat Enterprise Linux on the machine to be the Satellite.
2. Check any pre-installation steps before installing Red Hat Network Satellite.
3. Mount the Red Hat Network Satellite installation media and run the script.
4. Follow the prompts as outlined in the installation instructions.
5. Open the Satellite's hostname in a web browser and create the first user account. This will be the Satellite Administrator's (also referred to as the Organization Administrator) account.
6. Finalize Satellite with any post-installation steps.
Initial Use
1. Use the Red Hat Network Satellite Synchronization Tool to import the channels and associated packages into the Satellite.
2. Register a representative machine for each distribution type or channel (such as Red Hat Enterprise Linux 5 or 6) to the Satellite.
3. Copy (using scp) rhn_register configuration files from the /etc/sysconfig/rhn/ directory of each machine individually to the /pub/ directory on the Satellite. The rhn-org-trusted-ssl-cert-*.noarch.rpm will already be there.
4. Download and install from the Satellite the configuration files and rhn-org-trusted-ssl-cert-*.noarch.rpm on the remaining client systems of the same distribution type. Repeat this and the previous step until all distribution types are complete.
5. Through the Satellite's website, create an Activation Key for each distribution aligned to the appropriate base channel. At this point, system groups and child channels may also be predefined.
6. Run the Activation Key from the command line (rhnreg_ks) of each client system. Note that this step can be scripted to batch register and reconfigure all remaining client systems in a distribution.
7. Record all relevant usernames, passwords and other login information and store in multiple secure places.
8. Now that the Satellite is populated with standard Red Hat channels and packages and all clients are connected to it, you may begin creating and serving custom channels and packages. Once the custom RPMs are developed, you can import them into the Satellite using Red Hat Network Push and add custom channels in which to store them through the Satellite's website. Refer to the Red Hat Network Channel Management Guide for details.

Chapter 2. Requirements

This chapter contains all the requirements for a Red Hat Network Satellite installation. This includes variations for both Stand-Alone Database and Embedded Database installations.

2.1. Software Requirements

To perform an installation, the following software components must be available:

Base operating system: Red Hat Network Satellite is supported with Red Hat Enterprise Linux 5 and 6. The operating system can be installed from disc, local ISO image, kickstart, or any of the methods supported by Red Hat. Red Hat Enterprise Linux installations require the @Base package group with no other package-set modifications, and without third-party configurations or software that is not directly necessary for the direct operation of the server. This restriction includes hardening or other non-Red Hat security software. If such software is required in your infrastructure, first install and verify a complete working Satellite first, and then make a backup of the system before adding any non-Red Hat software.
When installing a new Red Hat Network Satellite, it is recommended that the latest supported update to Red Hat Enterprise Linux is installed.
Satellite can be installed on Red Hat Enterprise Linux 5 or 6 in any virtualized environment supported by Red Hat, including Xen, KVM, and VMware. Functional support for virtualized environments does not always equal the same performance of running on physical hardware. Make sure to consider your virtualized environment's performance and implement any recommended tuning guidelines.
When installing Red Hat Enterprise Linux 5 or 6 from CD or ISO image, there is no need to select any package groups, only the base install is required. When installing either operating system via kickstart, select the @Base package group.
Important
Each purchased Satellite product includes one supported instance of Red Hat Enterprise Linux Server. Install Satellite on a fresh installation of Enterprise Linux where Satellite is the only application and service provided by the OS. Using the Red Hat Enterprise Linux OS included with Satellite to run other daemons, applications, or services within your environment is not supported.
Important
The Satellite base operating system requires registration to Red Hat Network Classic using Red Hat Network Client. Satellite installation fails when registering the system with Red Hat Subscription Manager.
Satellite installation disc or ISO: This contains the Satellite Installer. All packages required in order to support Satellite are installed automatically, and require no intervention from the user.
Important
Additional packages beyond @Base are required to install Red Hat Network Satellite. The Satellite installer will prompt you to either install the listed packages or ask if you want it to download the files from Red Hat Network. If your system is not registered to Red Hat Network, you should have the Red Hat Enterprise Linux installation media available during the Satellite installation process to install these additional packages as needed.
The files necessary for Satellite installation are listed in the rhelrpms file located in the updates directory on the Satellite installation ISO image.
Ensure that your Satellite host system is also subscribed to the Red Hat Enterprise Linux Optional channel to resolve package dependencies during installation.
Channel content: All software packages and data exported for all entitled Red Hat channels. This content is loaded directly on the Satellite after installation using the Red Hat Network Satellite Synchronization Tool.

2.2. Stand-Alone Database Requirements

The Stand-Alone Database version of Red Hat Network Satellite requires certain hardware considerations. This section specifies these hardware requirements when installing a Red Hat Network Satellite server and connecting to an external database.

2.2.1. x86_64 Hardware Requirements for Stand-Alone Database Installations

The following table shows the required and recommended hardware configurations on the x86_64 platform for a Satellite server using a Stand-Alone Database:

Table 2.1. Stand-Alone Database Satellite Hardware Requirements

Required	Recommended
Intel Core processor, 2.4GHz, 512K cache or equivalent	Intel multi-core processor, 2.4GHz dual processor, 512K cache or equivalent
2 GB of memory	8 GB of memory
5 GB storage for base install of Red Hat Enterprise Linux	At least 30 GB storage per software channel (including `Base` and child channels), in `/var/satellite/`, configurable at install
	An external SAN for more reliable backups

2.2.2. s/390 Hardware Requirements for Stand-Alone Database Installations

For the s/390 mainframe platform, the following table shows the requirements and recommended configurations for Red Hat Network Satellite installations with a standalone database.

Table 2.2. Stand-Alone Database Satellite Hardware Requirements for s/390 Platform

Required	Recommended
1 IFL, either in LPAR configuration or shared through z/VM	2+ IFLs on z9 or earlier, 1+ IFL on z10
2 GB of memory	8 GB of memory
1 GB swap on ECKD DASD	512 MB swap on VDISK + 1 GB swap on ECKD DASD
1xMod3 ECKD DASD or ≥ 2 GB FCP SCSI LUN for OS install	1xMod9 ECKD DASD or ≥ 2 GB multipathed FCP SCSI LUN for Red Hat Enterprise Linux installation
	At least 30 GB storage per software channel (including `Base` and child channels), in `/var/satellite/`, configurable at install
	z/VM 5.3 or later^[a]
	VSWITCH or Hipersocket LAN for high speed connections to guests
^[a] z/VM required for kickstart/provisioning of guests.

2.2.3. Database Requirements for Stand-Alone Database Installations

Red Hat supports Satellite installations on a Stand-Alone Database using Oracle Database 10g Release 2 Standard and Enterprise Edition or Oracle 11g. Ensure the Stand-Alone Database runs on a different server to the Red Hat Network Satellite.

Important

Migration from an embedded to an external database is not currently supported.

A single 12 GB tablespace is recommended for most installations, although many customers will find it possible to function with a smaller tablespace. Have an experienced Oracle database administrator (DBA) assess your sizing requirements. Use the following formula to determine the required size of your database:

250 KiB per client system
500 KiB per channel, plus 230 KiB per package in the channel (so a channel with 5000 packages would require 1.1 Gib)

For instance, an Red Hat Network Satellite containing four channels and serving 10,000 systems would require 2.5 GiB for its clients and 11 GiB for its channels. If custom channels are to be established for testing and staging of packages, they must be included in this formula.

Keep in mind that the database storage needs may grow rapidly, depending upon the variance of the following factors:

The number of public Red Hat packages imported (typical: 5000)
The number of private packages to be managed (typical: 500)
The number of systems to be managed (typical: 1000)
The number of packages installed on the average system (typical: 500)

Although you should be generous in your database sizing estimates, you must consider that size affects the time to conduct backups and adds load to other system resources. If the database is shared, its hardware and spacing are entirely dependent on what else is using it.

Additionally, block sizes must be a minimum of 8 KB for Red Hat Network Satellite to install properly.

The Oracle database should have a user assigned to Red Hat Network Satellite with full DDL and DML access to that user's default tablespace. The user needs standard connection information for the database at the time of installation.

The precise access levels required by the Oracle user are as follows:

ALTER SESSION
CREATE SEQUENCE
CREATE SYNONYM
CREATE TABLE
CREATE VIEW
CREATE PROCEDURE
CREATE TRIGGER
CREATE TYPE
CREATE SESSION

Additional database requirements include:

Security Identifier (SID)
Listener Port
Username
UTF-8 character set

Two additional suggested recommendation for user's default tablespace include:

Uniform Extent Size
Auto Segment Space Management

Important

Ensure that the NLS/charset setting is set to "UTF8"' when using an external database, not 'AL32UTF8' or other charsets. Using other charsets may lead to problems later.

The disk layout on the database machine is independent of Satellite and entirely up to the customer.

2.3. Embedded Database Requirements

The Embedded Database version of Red Hat Network Satellite requires certain hardware considerations. This section specifies these hardware requirements when installing Red Hat Network Satellite server with the included database.

2.3.1. x86_64 Hardware Requirements for Embedded Database Installations

The following table shows the required and recommended hardware configurations on the x86_64 platform for a Satellite server using an Embedded Database:

Table 2.3. Embedded Database Satellite Hardware Requirements

Required	Recommended
Intel Core processor, 2.4GHz, 512K cache or equivalent	Intel multi-core processor, 2.4GHz dual processor, 512K cache or equivalent
2 GB of memory	8 GB of memory
5 GB storage for base install of Red Hat Enterprise Linux	At least 30 GB storage per software channel (including `Base` and child channels), in `/var/satellite/`, configurable at install
	An external SAN for more reliable backups
	12 GB storage for the database repository, in the `/rhnsat` partition (local storage only)
	a SCSI drive connected to a level 5 RAID (strongly recommended)
	Separate partition (or better, a separate set of physical disks) for storing backups, which can be any directory specifiable at backup time

2.3.2. s/390 Hardware Requirements for Embedded Database Installations

For the s/390 mainframe platform, the following table shows the requirements and recommended configurations for Red Hat Network Satellite installations with embedded databases.

Table 2.4. Embedded Database Satellite Hardware Requirements for s/390 Platform

Required	Recommended
1 IFL, either in LPAR configuration or shared through z/VM	2+ IFLs on z9 or earlier, 1+ IFL on z10
2 GB of memory	8 GB of memory
1 GB swap on ECKD DASD	512 MB swap on VDISK + 1 GB swap on ECKD DASD
1xMod3 ECKD DASD or ≥ 2 GB FCP SCSI LUN for OS install	1xMod9 ECKD DASD or ≥ 2 GB multipathed FCP SCSI LUN for Red Hat Enterprise Linux installation
Estimated 12 GB disk space for embedded database	At least 30 GB storage per software channel (including `Base` and child channels), in `/var/satellite/`, configurable at install
	z/VM 5.3 or later^[a]
	VSWITCH or Hipersocket LAN for high speed connections to guests
^[a] z/VM required for kickstart/provisioning of guests.

2.4. Additional Requirements

Red Hat Network Satellite has some additional considerations before installation. Ensure to meet these additional requirements before commencing the Satellite installation.

2.4.1. Firewall

The entire Satellite solution should be protected by a firewall if the Satellite accesses or is accessed via the Internet. All unnecessary ports should be firewalled off. Client systems connect to Satellite over ports 80, 443, and 4545 (if Monitoring is enabled). In addition, if you plan to enable the pushing of actions from the Satellite to client systems, as described in Section 9.11, “Enabling Push to Clients”, you must allow inbound connections on port 5222. Finally, if the Satellite will also push to an Red Hat Network Proxy Server, you must also allow inbound connections on port 5269.

Table 2.5. Ports to open on the Satellite

Port	Protocol	Direction	Reason
67	TCP/UDP	Inbound	Open this port to configure the Satellite system as a DHCP server for systems requesting IP addresses.
69	TCP/UDP	Inbound	Open this port to configure Satellite as a PXE server and allow installation and re-installation of PXE-boot enabled systems.
80	TCP	Outbound	Satellite uses this port to reach Red Hat Network.
80	TCP	Inbound	Web UI and client requests come in via http.
443	TCP	Inbound	Web UI and client requests come in via https.
443	TCP	Outbound	Red Hat Network Satellite uses this port to reach Red Hat Network (unless running in a disconnected mode for Satellite).
4545	TCP	Inbound and Outbound	Red Hat Network Satellite Monitoring makes connections to `rhnmd` running on client systems, if Monitoring is enabled and probes are configured for registered systems.
5222	TCP	Inbound	If you plan to push actions to client systems.
5269	TCP	Inbound and Outbound	If you push actions to or via an Red Hat Network Proxy Server.

2.4.2. SELinux Policy

Red Hat Network Satellite supports SELinux targeted policy in enforcing or permissive mode on Red Hat Enterprise Linux 5 and 6. SELinux is a set of secure software policies that implement mandatory access control to Red Hat Enterprise Linux and other operating systems. Users can have SELinux in enforcing or permissive mode with the targeted policy set during installation of Proxy or Satellite.

2.4.3. DMZ Proxy Solution

Unless the Satellite server is in disconnected mode, it needs to initiate outbound connections on ports 80 and 443 to the Red Hat Network Hosted service (rhn.redhat.com, xmlrpc.rhn.redhat.com, and satellite.rhn.redhat.com). To ensure correct functioning of the satellite system, do not restrict access to these hosts and ports. If required, an http or https proxy can be used, by issuing the satellite-sync --http-proxy command.

The Satellite server needs to allow inbound connections on ports 80 and 443 from client systems and any Red Hat Network Proxy servers connected to the Satellite, as well as any system that needs to access the Satellite Web UI. WebUI and client requests come in via either http or https.

The Red Hat Network Monitoring functionality requires outbound connections to individual mMnitoring-enabled client systems on port 4545. Red Hat Network Satellite Monitoring makes connections to rhnmd running on client systems if Monitoring is enabled and probes are configured for registered systems.

The Red Hat Network push functionality requires both outbound and inbound connections on port 5269 to and from each registered Red Hat Network Proxy server with Red Hat Network push functionality enabled. This is used for two-way communications between the jabberd service on Satellite and Proxy, respectively. In addition, it needs to allow inbound connections on port 5222 from client systems directly registered to the Satellite. This is used for one-way (client to server) communications between the osad service on client systems and the jabberd service on the Satellite.

2.4.4. Synchronized System Times

There is great time sensitivity when connecting to a Web server running SSL (Secure Sockets Layer); it is imperative that the time settings on the clients and server be reasonably close together so the SSL certificate does not expire before or during use. For this reason, Red Hat requires the Satellite and all client systems to use Network Time Protocol (NTP). This also applies to the separate database machine in Red Hat Network Satellite with Stand-Alone Database, which must also be set to the same time zone as the Satellite.

2.4.5. Setting System Language and Locale

You should properly set the UTF-8 encoding for your language and locale on your Red Hat Network Satellite system via the /etc/sysconfig/i18n file. The LANG setting in the file must be in the following format:

LANG="[language_TERRITORY].UTF-8"

The language and TERRITORY are entered as two-letter codes. For example if your language is English and your locale is the United States, you set your LANG setting to en_US.UTF-8.

2.4.6. Fully Qualified Domain Name (FQDN)

The system upon which the Red Hat Network Satellite will be installed must resolve its own FQDN properly. If this is not the case, cookies will not work properly on the website.

Important

It is important that the hostname of a Satellite contains no uppercase letters. A hostname that includes uppercase letters can cause jabberd to fail.

If, at any point, you need to change your Satellite hostname, refer to Section 9.7, “Changing the Satellite Hostname”.

2.4.7. Functioning Domain Name Service (DNS)

Ensure that all clients can resolve Red Hat Network Satellite's domain name. All systems, both servers and clients, require connection to a working DNS server in the customer environment.

2.4.8. Entitlement Certificate

The customer will receive, via email from the sales representative, a signed Entitlement Certificate explaining the services provided by Red Hat through Red Hat Network Satellite. This certificate will be required during the installation process.

If you do not have an Entitlement Certificate at installation time, contact Red Hat Global Support Services at:

https://www.redhat.com/apps/support/

2.4.9. Red Hat Network Account

Customers who connect to the central Red Hat Network Servers to receive incremental updates must have an external account with Red Hat Network. This account should be set up at the time of purchase with the sales representative.

Warning

Do not subscribe your Red Hat Network Satellite to any of the following child channels available on Red Hat Network Hosted:

Red Hat Developer Suite
Red Hat Application Server
Red Hat Extras
JBoss product channels

Subscribing to these channels and updating your Satellite may install newer, incompatible versions of critical software components, causing the Satellite to fail.

2.4.10. Backups of Login Information

It is imperative that customers keep track of all primary login information. For Red Hat Network Satellite, this includes usernames and passwords for the Organization Administrator account on rhn.redhat.com, the primary administrator account on the Satellite itself, SSL certificate generation, and database connection (which also requires a SID, or net service name). Red Hat strongly recommends this information be copied onto removable storage media, printed out on paper, and stored in a fireproof safe.

2.4.11. Channel Content ISOs

An Internet connection is not required for Red Hat Network Satellites running in completely disconnected environments. This feature instead uses Channel Content ISOs that can be downloaded to a separate system to synchronize the Satellite with the central Red Hat Network Servers. All other Red Hat Network Satellites should be synchronized directly over the Internet.

Note

If you are running a disconnected Satellite that is not registered to Red Hat Network Hosted the installation program will note and return a list of any missing additional packages needed beyond @base to be installed, then the installation program will exit. This allows you to install those packages. You may want to use the installation ISO image or DVD media to create a repository for those additional packages, and then rerun the Satellite installer.

2.4.12. Service Access

No system components should be directly, publicly available. No user other than the system administrators should have shell access to these machines.

All unnecessary services should be disabled using ntsysv or chkconfig.

The following services should be enabled.

jabberd
oracle (for Embedded Database Installation)
tomcat5 (for installation on Red Hat Enterprise Linux 5)
tomcat6 (for installation on Red Hat Enterprise Linux 6)
httpd
osa-dispatcher
Monitoring
MonitoringScout
rhn-search
cobblerd
taskomatic

If the Satellite serves Monitoring-entitled systems and you wish to acknowledge via email the alert notifications you receive, you must configure sendmail or postfix to properly handle incoming mail.

2.4.13. Additional Documentation

The following additional documentation helps users perform further configuration tasks:

The Red Hat Network Client Configuration Guide — This guide explains how to configure the systems to be served by an Red Hat Network Proxy Server or Red Hat Network Satellite. (This will also likely require referencing The Red Hat Network Reference Guide, which contains steps for registering and updating systems.)
The Red Hat Network Channel Management Guide — This guide identifies the recommended methods for building custom packages, creating custom channels, and managing private errata.
The Red Hat Network Reference Guide — This guide describes how to create Red Hat Network accounts, register and update systems, and use the Red Hat Network website to its utmost potential. This guide will probably come in handy throughout the installation and configuration process.

Chapter 3. Example Topologies

The Red Hat Network Satellite can be configured in multiple ways. Select one method depending on the following factors:

The total number of client systems to be served by the Red Hat Network Satellite.
The maximum number of clients expected to connect concurrently to the Red Hat Network Satellite.
The number of custom packages and channels to be served by the Red Hat Network Satellite.
The number of Red Hat Network Satellites being used in the customer environment.
The number of Red Hat Network Proxy Servers being used in the customer environment.

The rest of this chapter describes possible configurations and explains their benefits.

3.1. Single Satellite Topology

The simplest configuration is to use a single Red Hat Network Satellite to serve your entire network. This configuration is adequate to service a medium-size group of clients and network.

The disadvantage of using one Red Hat Network Satellite is that performance will be compromised as the number of clients requesting packages grows.

Figure 3.1. Single Satellite Topology

3.2. Multiple Satellite Horizontally Tiered Topology

For very large networks, a more distributed method may be needed, such as having multiple Red Hat Network Satellites in a horizontally tiered configuration and balancing the load of client requests.

It is possible to synchronize content between Red Hat Network Satellites using the rhn-satellite-exporter and satellite-sync -m commands. Alternatively, the Inter-Satellite Sync 2 feature is designed for this purpose.

Additional maintenance is the biggest disadvantage of this horizontal structure.

Figure 3.2. Multiple Satellite Horizontally Tiered Topology

3.3. Satellite-Proxy Vertically Tiered Topology

An alternative method to balance load is to install Red Hat Network Proxy Servers below a Red Hat Network Satellite. These Proxies connect to the Satellite for RPMs from Red Hat Network and custom packages created locally. In essence, the Proxies act as clients of the Satellite.

This vertically tiered configuration requires that channels and RPMs be created only on the Red Hat Network Satellite. In this manner, the Proxies inherit and then serve packages from a central location. For details, refer to the Red Hat Network Channel Management Guide.

Similarly, you should make the Proxies' SSL certificates clients of the Satellite while also setting them to serve the client systems. This process is described in the Red Hat Network Client Configuration Guide.

Figure 3.3. Satellite-Proxy Vertically Tiered Topology

Chapter 4. Installation

This chapter describes the initial installation of the Red Hat Network Satellite. It presumes the prerequisites listed in Chapter 2, Requirements have been met. If you are instead upgrading to a newer version of Red Hat Network Satellite, contact your Red Hat representative for assistance.

4.1. Prerequisites

The following section outline the prerequisites for installing Red Hat Network Satellite.

4.1.1. Base Operation System

Red Hat Network Satellite runs on either Red Hat Enterprise Linux 5 and Red Hat Enterprise Linux 6 operating systems. The first phase is to install the base operating system, either from disc, ISO image, or kickstart.

During and after operating system installation, make sure you:

Allocate plenty of space to the partitions storing data. The default location for channel packages is /var/satellite/. For Red Hat Network Satellite with Embedded Database, remember the database RPMs go in the /opt/ partition, while the database itself is built in /rhnsat/.
Enable Network Time Protocol (NTP) on the Satellite and separate database, if it exists, and select the appropriate time zone. All client systems should already be running the ntpd daemon and be set to the correct time zone.
It is strongly advised that the /home/ partition is locally mounted.
Register to Red Hat Network Classic. Once installation of the base operating system is complete, run the following command to register your system:
```
# rhn_register
```

4.1.2. Mounting the Installation Media

The following section describes the process for mounting either the CD or ISO image containing installation media for Red Hat Network Satellite.

Procedure 4.1. Mounting from a CD

Log into the machine as root.
Insert the Red Hat Network Satellite Server CD containing the installation files.
Red Hat Enterprise Linux might automount the CD. If so, it mounts the CD to the /media/cdrom/ directory. If Red Hat Enterprise Linux does not automount the CD, manually mount it to the /media/cdrom/ directory with the following command:
```
# mkdir /media/cdrom
# mount /dev/cdrom /media/cdrom
```

Procedure 4.2. Mounting from an ISO image

Log into the machine as root.
Download the ISO image from the Red Hat Network website.
Mount the ISO image from within the directory containing it using the command:
```
# mkdir /media/cdrom
# mount -o loop iso_filename /media/cdrom
```

The installation media is mounted at /media/cdrom/. Use this location to access the Red Hat Network Satellite installation script.

4.1.3. Obtaining an Entitlement Certificate

Red Hat Network Satellite requires a copy of your Red Hat Network Entitlement Certificate in order to active it. This Entitlement Certificate is included with your subscription to Red Hat Network Satellite and is available from the Red Hat Customer Portal.

Ensure to download the Entitlement Certificate from the Red Hat Customer Portal and copy it to the Satellite server's file system in any directory. The installation program asks you for its location.

Important

Ensure your Red Hat Network account has been granted the necessary entitlements to conduct the installation.

4.2. Pre-Installation

The following instructions assume the Red Hat Network Satellite installation media is mounted at /media/cdrom/. The installation media contains the install.pl installer script.

This section outlines considerations to take in account before running the installer script.

4.2.1. Options for the Installer Script

The table below outlines the various options available for the install.pl installer script:

Table 4.1. Installation Options

Option	Usage
`--help`	Print this help message.
`--answer-file=<filename>`	Indicates the location of an answer file to be use for answering questions asked during the installation process.
`--non-interactive`	For use only with `--answer-file`. If the `--answer-file` does not provide a required response, exit instead of prompting the user.
`--re-register`	Register the system with Red Hat Network, even if it is already registered.
`--external-db`	Install Satellite with a Stand-Alone Database
`--disconnected`	Install the satellite in disconnected mode.
`--clear-db`	Clear any pre-existing database schema before installing. This will destroy any data in the Satellite database and re-create empty Satellite schema.
`--skip-system-version-test`	Do not test the Red Hat Enterprise Linux version before installing.
`--skip-selinux-test`	Do not check to make sure SELINUX is disabled.
`--skip-fqdn-test`	Do not verify that the system has a valid hostname. Red Hat Network Satellite requires that the hostname be properly set during installation. Using this option may result in a Satellite server that is not fully functional.
`--skip-db-install`	Do not install the embedded database. This option may be useful if you are reinstalling the satellite, and do not want to clear the database.
`--skip-db-diskspace-check`	Do not check to make sure there is enough free disk space to install the embedded database.
`--skip-db-population`	Do not populate the database schema.
`--skip-gpg-key-import`	Do not import Red Hat's GPG key.
`--skip-ssl-cert-generation`	Do not generate the SSL certificates for the Satellite.
`--run-updater`	Do not ask to install needed packages from Red Hat Network, if the system is registered.

4.2.2. Automated Red Hat Network Satellite Server Installation

The Red Hat Network Satellite installer provides the option to use an answer file. This file contains pre-determined responses to some, or all, of the questions asked by the installer. The installer uses the answer file to run without user interaction; this is useful in situations where Satellite requires automated installation. For an example of an answers file, view the answers.txt file found in the install/ directory of the CD or ISO.

Follow the steps below to perform an automated install with an answer file.

Procedure 4.3. Installing with an Answers File

Copy the example answers.txt file to /tmp/answers.txt
```
# cp answers.txt /tmp/answers.txt
```
Edit the file and add your organization's desired options.
Once the answer file is ready, use the --answer-file option when starting the installation process from the command line:
```
# ./install.pl --answer-file=/tmp/answers.txt
```
The Red Hat Network Satellite Installation Program then looks for answers in the file. For any option not filled out in the file, the Installer Program prompts the user for the missing information.

4.2.3. Installing Behind a HTTP Proxy: Pre-Configuration

Due to the way that Red Hat Network Satellite uses the rhn.conf to control its connection settings, there is no way to add options to that file prior to installation of Red Hat Network Satellite. If your network is behind an HTTP proxy in your organization, you cannot activate the Red Hat Network Satellite at installation time. A workaround to this issue is to first perform a disconnected installation of Red Hat Network Satellite, then switch the configuration to a connected method after installation is completed. The following demonstrates how to create a connected Red Hat Network Satellite installation behind an HTTP proxy:

Procedure 4.4. Installing Satellite behind an HTTP Proxy - Pre-Configuration

Complete a minimal installation of Red Hat Enterprise Linux 5 or 6.
Configure the system so that it can connect to Red Hat Network behind the HTTP proxy. Edit the file /etc/sysconfig/rhn/up2date as follows:
```
enableProxy=1
enableProxyAuth=1
httpProxy=<http-proxy-fqdn>
proxyUser=<proxy-username>
proxyPassword=<proxy-password>
```
Register the system to Red Hat Network.
Begin the installation of Red Hat Network Satellite with the disconnected option:
```
./install.pl --disconnected
```

4.3. Installer Script Process

The following instructions assume the Red Hat Network Satellite installation media is mounted at /media/cdrom/. The installation media contains the install.pl installer script.

This section guides the user through the installation process using the installer script.

4.3.1. Running the Installer Script

The following procedure starts the installation procedure. Ensure to run this procedure as the root user.

Warning

Users should note that the Red Hat Network Satellite Installation Program updates the kernel, as well as all required packages.

Procedure 4.5. Running Installer Script

Run the installer script with an option to install with either Embedded Database or Stand-Alone Database.
1. Embedded Database - From the /media/cdrom/ directory, enter the following command to start the Red Hat Network Satellite Installation Program:
```
# ./install.pl
```
2. Stand-Alone Database - From the /media/cdrom/ directory, enter the following command to start the Red Hat Network Satellite Installation Program:
```
# ./install.pl --external-db
```
The script first runs through a pre-requisite check. These checks make certain that all prerequisites from Chapter 2, Requirements are met before proceeding with the installation.
```
* Starting the Red Hat Network Satellite installer.
* Performing pre-install checks.
* Pre-install checks complete.  Beginning installation.
```
The Satellite is then registered with Red Hat Network Classic and all required packages are installed and updated.
```
* RHN Registration 
* Installing updates. 
* Installing RHN packages.
```

The next section sets up the database for your installation.

4.3.2. Database Configuration

The next step creates and populates the initial database. This step can take quite a while. If you would like to monitor the progress of the installation, use tail in a separate window to monitor the /var/log/rhn/install_db.log file.

Embedded Database

If you are installing Red Hat Network Satellite with an Embedded Database, this process is automatic.

** Database: Setting up database connection for Oracle backend.
** Database: Testing database connection.
** Database: Populating database.
*** Progress: ######

Stand-Alone Database

If you are installing Red Hat Network Satellite with a Stand-Alone Database, the installer asks for connection details to your Stand-Alone Database.

** Database: Setting up database connection for Oracle backend.
Database service name (SID)? orcl
Database hostname [localhost]? 10.5.63.161
Username? satuser
Password? ********
** Database: Testing database connection.
** Database: Populating database.
*** Progress: ######

Once database installation is complete, the Satellite continues configuration.

4.3.3. Initial Configuration

The installer script performs some basic configuration tasks on your Satellite environment.

The Red Hat Network Satellite Installer downloads and installs the Red Hat Network GPG key, including setting up the /root/.gnupg/ directory, if required.

* Setting up environment and users.
** GPG: Initializing GPG and importing key.
** GPG: Creating /root/.gnupg directory

Important

When running the Red Hat Network Satellite Installation Program in disconnected mode, it will not automatically download and install the Red Hat Network GPG key, which will cause the installation to fail. To import the key manually, import from your base operating system media with this command:

# rpm --import /media/RHEL/RPM-GPG-KEY-redhat-release

At the prompt, enter the email address to which you would like notifications from the Satellite to be sent. It may be a good idea to choose a general email address rather than the address of an individual, as there can be a large volume of emails.

You must enter an email address.
Admin Email Address? admin@example.com
* Performing initial configuration.

4.3.4. Entitlement Certificate Configuration

In order to activate the Satellite, you must provide it with the location of your Satellite certificate.

* Activating Satellite. 
Where is your satellite certificate file? /root/example.cert
** Loading RHN Satellite Certificate.
** Verifying certificate locally.
** Activating RHN Satellite.

4.3.5. CA Certificate Configuration

The next step is to create a CA certificate for the Satellite for SSL access. To do so, you must answer a few questions.

CA cert: Enter a password for the certificate.
Organization: Enter the name of your organization.
Organization Unit: Enter the name of your department within your organization.
Email Address: Enter an email address to be associated with this certificate, such as the admin email entered in the steps above.
City: Enter the city where the Satellite resides.
State: Enter the state where the Satellite resides.
Country: Enter the country where the Satellite resides. The country code must be exactly two letters, or the certificate generation fails. Type ? to see a list of country codes.

Once the CA Cert certificate is generated, the installer script performs final configuration and restarts the associated services.

* Final configuration. 
* Restarting services.
Installation complete. 
Visit https://your-satellite.example.com to create the satellite administrator account.

The Red Hat Network Satellite installation is now complete.

4.4. Post-Installation

The following sections outline configuration considerations after installation.

4.4.1. Installing Behind a HTTP Proxy: Post-Configuration

Once the installation is complete, modify your settings in the /etc/rhn/rhn.conf file:

server.satellite.http_proxy = <http-proxy-fqdn>
server.satellite.http_proxy_username = <proxy-username>
server.satellite.http_proxy_password = <proxy-password>

disconnected=0

You will also need to update the /etc/rhn/rhn.conf file to include the parent parameter satellite.rhn.redhat.com:

server.satellite.rhn_parent = satellite.rhn.redhat.com

Note

Alternatively, if you are using the Red Hat Network Satellite web interface, log in as a user with Administrator privileges. Browse to Admin → Red Hat Network Satellite Configuration → General. From here, enter the HTTP Proxy settings, and toggle the Disconnected Red Hat Network Satellite option.

Restart the Satellite service:

service rhn-satellite restart

Reactivate the Satellite as a connected Satellite:

rhn-satellite-activate --rhn-cert=<path-to-cert>

You should now have a connected Red Hat Network Satellite that will work behind an HTTP proxy.

4.4.2. Create Admin User

Follow the on-screen instructions and visit the FQDN of your Satellite via a web browser. Create the Satellite Administrator account - also referred to as the Organization Administrator - and click the Create Login button to move to the next screen, the Your RHN screen.

Figure 4.1. Admin Account Creation

4.4.3. Finalize Configuration

A blue text box appears at the top of the screen indicating that you can now custom-configure the Satellite and its behavior. To do so, click the bold clicking here text at the end.

Figure 4.2. Final Configuration Prompt

4.4.3.1. General Configuration

The Satellite Configuration - General Configuration page allows you to alter the most basic Satellite settings, such as the admin email address and whether Monitoring is enabled.

Figure 4.3. General Configuration

4.4.3.2. Certificate

The Red Hat Network Satellite Configuration - Certificate page allows you to upload a new Satellite certificate. To identify the certificate's path, click Browse, navigate to the file, and select it. To input its contents, open your certificate in a text editor, copy all lines, and paste them directly into the large text field at the bottom. Red Hat recommends using the file locator as it is less error prone. Click Validate Certificate to continue. If you receive errors related to DNS, ensure your Satellite is configured correctly

Figure 4.4. Certificate

4.4.3.3. Bootstrap

The Red Hat Network Satellite Configuration - Bootstrap page allows you to generate a bootstrap script for redirecting client systems from the central Red Hat Network Servers to the Satellite. This script, to be placed in the /var/www/html/pub/bootstrap/ directory of the Satellite, significantly reduces the effort involved in reconfiguring all systems, which by default obtain packages from the central Red Hat Network Servers. The required fields are pre-populated with values derived from previous installation steps. Ensure this information is accurate.

Checkboxes offer options for including built-in security SSL and GNU Privacy Guard (GPG) features, both of which are advised. In addition, you may enable remote command acceptance and remote configuration management of the systems to be bootstrapped here. Both features are useful for completing client configuration. Finally, if you are using an HTTP proxy server, complete the related fields. When finished, click Generate Bootstrap Script. The Installation Complete page appears.

Figure 4.5. Bootstrap

4.4.4. Organizations

The Red Hat Network Satellite Configuration - Organizations page contains configuration options for logical groupings of systems, software channels, subscriptions and entitlements. A Red Hat Network Satellite can manage multiple organizations, each with an individual organization administratior.

Figure 4.6. Organizations

4.4.5. Restart

The Red Hat Network Satellite Configuration - Restart page contains the final step in configuring the Satellite. Click the Restart button to restart the Satellite in order to incorporate all of the configuration options added on the previous screens. Note that it will take between four and five minutes for the restart to finish.

Figure 4.7. Restart

Once the Satellite has restarted, the countdown notice disappears. You are now free to begin using your Satellite.

4.4.6. Cobbler Rebuild

The Red Hat Network Satellite Configuration - Cobbler page contains options to rebuild or refresh Cobbler content if modified outside of Satellite.

Figure 4.8. Cobbler

4.4.7. Message Transfer Agent (MTA) Configuration

If your Satellite will serve Monitoring-entitled systems and you wish to acknowledge via email the alert notifications you receive, you must configure your Message Transfer Agent (MTA) to properly handle incoming mail. This is required by the email redirect feature, which allows you to stop notifying users about a Monitoring-related event with a single reply.

4.4.7.1. Sendmail

To configure sendmail correctly, run the following commands as root.

Create a symbolic link allowing sendmail to run the notification enqueuer with the following command:
```
# ln -s /usr/bin/ack_enqueuer.pl /etc/smrsh/.
```
Edit the /etc/aliases file on the mail server and add the following line:
```
rogerthat01: | /etc/smrsh/ack_enqueuer.pl
```

Edit the /etc/mail/sendmail.mc file and change:

"DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')dnl"

to:

"DAEMON_OPTIONS(`Port=smtp, Name=MTA')dnl"

Process the alias with the following command:
```
# newaliases
```
Update the sendmail-cf package:
```
# yum update sendmail-cf
```
Restart sendmail:
```
# service sendmail restart
```

4.4.7.2. Postfix

To configure postfix correctly, run the following commands as root.

Create a symbolic link allowing postfix to run the notification enqueuer with the following command:
```
# ln -s /usr/bin/ack_enqueuer.pl /etc/smrsh/.
```
Edit the /etc/aliases file on the mail server and add the following line:
```
rogerthat01: | /etc/smrsh/ack_enqueuer.pl
```
Ensure the following line exists in your /etc/postfix/main.cf file and change:
```
inet_interfaces = all
```
Process the alias with the following command:
```
# newaliases
```
Restart sendmail:
```
# service postfix restart
```

4.4.8. MySQL Installation for Monitoring

This section is applicable only if your Satellite will serve Monitoring-entitled systems and you wish to run MySQL probes against them. Refer to the Probes appendix of the Red Hat Network Satellite Reference Guide for a list of available probes.

If you do wish to run MySQL probes, subscribe the Satellite to the Red Hat Enterprise Linux channel and install the mysql-server package either through the Red Hat Network website or by yum.

Two extra packages will also be downloaded in the transaction. These are needed for the mysql-server package to be installed and run successfully. Once finished, your Satellite may be used to schedule MySQL probes.

Chapter 5. Entitlements

Red Hat Network Satellite provides all services to customers through entitlements. Customers purchase entitlements as needed via Red Hat Network. For Red Hat Network Satellite, entitlements are contractually agreed-upon beforehand and set at installation time. All public channels are automatically available and private channels are determined by the Red Hat Network Entitlement Certificate.

The Entitlement Certificate contains a precise set of entitlements attributed to your organization. Red Hat reserves the right to compare the contents of that Red Hat Network Entitlement Certificate with the database's entitlement settings at any time to ensure compliance with the terms of the customer's contract with Red Hat.

The Satellite Installer Program performs the steps referenced in this section during initial installation. As a result, customers do not require the steps in this section unless they import a new Entitlement Certificate, such as one reflecting an increase in the number of entitlements.

5.1. Red Hat Network Satellite Activate

For disconnected Satellites or customers who prefer to work locally, Red Hat provides a command line tool for managing your Red Hat Network Entitlement Certificate and activating the Satellite using that certificate: Red Hat Network Satellite Activate (rhn-satellite-activate). This is included with the Satellite installation as part of the spacewalk-backend-tools package.

The rhn-satellite-activate tool offers a handful of command line options for activating a Satellite using its Red Hat Network Entitlement Certificate:

Table 5.1. Red Hat Network Entitlement Certificate Options

Option	Description
`-h`, `--help`	Display the help screen with a list of options.
`--sanity-only`	Confirm certificate sanity. Does not activate the Satellite locally or remotely.
`--disconnected`	Activates locally but not on remote Red Hat Network Servers.
`--rhn-cert=/PATH/TO/CERT`	Uploads new certificate and activates the Satellite based upon the other options passed (if any).
`--systemid=/PATH/TO/SYSTEMID`	For testing only - Provides an alternative system ID by path and file. The system default is used if not specified.
`--no-ssl`	For testing only - Disable SSL.

To use these options, insert the option and the appropriate value, if needed, after the rhn-satellite-activate command.

5.2. Activate Satellite with a New Entitlement Certificate

Use the options in Table 5.1, “Red Hat Network Entitlement Certificate Options” to accomplish the following tasks in this order:

Validate the Red Hat Network Entitlement Certificate's sanity (or usefulness).
Activate the Satellite locally by inserting the Red Hat Network Entitlement Certificate into the local database.
Activate the Satellite remotely by inserting the Red Hat Network Entitlement Certificate into the central Red Hat Network (remote) database. This is typically accomplished during local activation but may require a second step if you chose the --disconnected option.

Here are some examples depicting use of the tool and these options.

To validate an Red Hat Network Entitlement Certificate's sanity only:

rhn-satellite-activate --sanity-only --rhn-cert=/path/to/demo.cert

To validate an Red Hat Network Entitlement Certificate and populate the local database:

rhn-satellite-activate --disconnected --rhn-cert=/path/to/demo.cert

To validate an Red Hat Network Entitlement Certificate and populate both the local and the Red Hat Network database:

rhn-satellite-activate --rhn-cert=/path/to/demo.cert

Once you run this final command, the Satellite is running and able to serve packages locally and synchronize with the central Red Hat Network Servers. Refer to Chapter 6, Content and Synchronization.

5.3. Satellite Entitlement Certificate Expiration

Satellite certificates expire at 11:59:59 PM on the date listed in the certificate's expires field, and new certificates become active at 12:00:00 AM on their issued date.

A standard grace period of seven (7) days exists between the date of Satellite certificate expiration and when the Satellite becomes inactive. This grace period is provided in order for customers to contact Red Hat Support and obtain a new certificate. During the grace period, the following things happen:

The Satellite remains active.
Each user that logs into the Satellite sees a banner on their Overview page that explains that the Satellite certificate has expired.
Once a day, for all seven days, the Satellite Administrator's email receives notification that the certificate has expired.

When the grace period is over, the Satellite becomes unavailable: users will be unable to login to the web UI and all client-side tools will present an Expired Certificate message.

Finally, the Satellite Administrator receives a daily email alerting them that the certificate has expired.

Chapter 6. Content and Synchronization

Your Red Hat Network Satellite Server is now installed. The next step is to provide it with packages and channels to be served to client systems. This chapter explains how to import content and keep it up to date.

Ensure to meet the following prerequisites before performing a Red Hat Network Satellite synchronization:

The Red Hat Network Satellite installation must have been performed successfully.
The Red Hat Network Channel Content ISOs or Red Hat Network Satellite Exporter data must be available, or the Satellite must have access to the Internet and the Red Hat Network website.

6.1. Red Hat Network Satellite Synchronization Tool

The Red Hat Network Satellite Synchronization Tool (satellite-sync) enables an Red Hat Network Satellite to update its database metadata and RPM packages with various sources.

Important

satellite-sync imports a large amount of data, especially on newly installed Satellite servers. If your database has performance issues after a significant amount of data changes, consider gathering statistics on the database. Refer to Section 9.4, “Using RHN DB Control” for more information.

To launch the Red Hat Network Satellite Synchronization Tool, execute the following command as root:

# satellite-sync

The Red Hat Network Satellite Synchronization Tool works incrementally. For it to obtain errata information, it must first know the packages contained. For the packages to be updated, the tool must first identify the associated channel(s). For this reason, the Red Hat Network Satellite Synchronization Tool performs its actions in the following order:

channel-families — Import/synchronize channel family (architecture) data.
channels — Import/synchronize channel data.
rpms — Import/synchronize RPMs.
packages — Import/synchronize full package data for those RPMs retrieved successfully.
errata — Import/synchronize errata information.

Each of these steps can be initiated individually for testing purposes with the effect of forcing the tool to stop when that step is complete. All steps that precede it, however, will have taken place. Therefore, calling the rpms step will automatically ensure the channels and channel-families steps take place first. To initiate an individual step, use the --step option.

# satellite-sync --step=rpms

In addition to --step, the Red Hat Network Satellite Synchronization Tool provides other command line options. To use them, insert the option and the appropriate value after the satellite-sync command when launching import/synchronization.

Table 6.1. satellite-sync Options

Option	Description
`-h`, `--help`	Display this list of options and exit.
`-d=`, `--db=DB`	Include alternate database connect string: username/password@SID.
`-m=`, `--mount-point=MOUNT_POINT`	Import/sync from local media mounted to the Satellite. To be used in closed environments (such as those created during disconnected installs).
`--list-channels`	List all available channels and exit.
`-c CHANNEL`, `--channel=CHANNEL_LABEL`	Process data for this channel only. Multiple channels can be included by repeating the option. If no channels are specified, the Satellite updates all channels.
`-p, --print-configuration`	Print the current configuration and exit.
`--no-ssl`	Not Advisable - Turn off SSL.
`--step=STEP_NAME`	Perform the sync process only to the step specified. Typically used in testing.
`--no-rpms`	Do not retrieve actual RPMs.
`--no-packages`	Do not process full package data.
`--no-errata`	Do not process errata information.
`--no-kickstarts`	Do not process kickstart data (provisioning only).
`--force-all-packages`	Forcibly process all package data without conducting a diff.
`--debug-level=LEVEL_NUMBER`	Override the amount of messaging sent to log files and generated on the screen set in `/etc/rhn/rhn.conf`, 0-6 (2 is default).
`--email`	Email a report of what was imported/synchronized to the designated recipient of traceback email.
`--traceback-mail=TRACEBACK_MAIL`	Direct sync output (from `--email`) to this email address.
`-s=`, `--server=SERVER`	Include the hostname of an alternative server to connect to for synchronization.
`--http-proxy=HTTP_PROXY`	Add an alternative HTTP proxy server in the form hostname:port.
`--http-proxy-username=PROXY_USERNAME`	Include the username for the alternative HTTP proxy server.
`--http-proxy-password=PROXY_PASSWORD`	Include the password for the alternative HTTP proxy server.
`--ca-cert=CA_CERT`	Use an alternative SSL CA certificate by including the full path and filename.
`--systemid=SYSTEM_ID`	For debugging only - Include path to alternative digital system ID.
`--batch-size=BATCH_SIZE`	For debugging only - Set maximum batch size in percent for XML/database-import processing. Open man satellite-sync for more information.

6.2. Synchronization with Local Media

Although it is possible to conduct the import directly from the Red Hat Network website, this should be done only if Channel Content ISOs are not available. It takes a long time to populate a channel from scratch over the Internet. For this reason, Red Hat urges you to use ISOs, if they are available, for initial import.

6.2.1. Preparing for Import from Local Media

Channel Content ISOs are special collections that contain both packages and XML dumps of metadata. The ISO images can be downloaded from the Red Hat Network website on a machine connected to the Internet and then transferred to the Satellite.

Procedure 6.1. Obtain the Channel Content ISOs

Log into the Web UI.
Click Channels in the top navigation bar.
Click on the Red Hat Network Satellite channel. Ensure you select the Satellite channel that corresponds to your version of Satellite.
Click the Downloads tab and use the instructions on the page to obtain the Channel Content ISOs, available by version of Red Hat Enterprise Linux.
If the desired Channel Content ISOs do not appear, ensure your Red Hat Network Entitlement Certificate has been uploaded to Red Hat Network and correctly identifies the target channels.

This next procedure mounts the Channel Content ISOs and copies the contents to a temporary repository directory.

Procedure 6.2. Mount and copy Channel Content ISOs

Log into the machine as root.
Create a directory in /mnt/ to store the file(s) with the command:
```
# mkdir /mnt/import/
```
Mount the ISO file using the following command:
```
# mount [iso_filename] /mnt/import -o loop
```
Create a target directory for the files:
```
# mkdir /var/rhn-sat-import/
```
This sample command assumes the administrator wants to copy the contents of the ISO (mounted in /mnt/import/) into /var/rhn-sat-import/:
```
# cp -ruv /mnt/import/* /var/rhn-sat-import/
```
Then unmount /mnt/import in preparation for the next ISO:
```
# umount /mnt/import
```
Repeat these steps for each Channel Content ISO of every channel to be imported.

6.2.2. Import from Local Media

The following process assumes in the previous step the user has copied all data to /var/rhn-sat-import.

List the channels available for import.

# satellite-sync --list-channels --mount-point /var/rhn-sat-import

Initiate the import of a specific channel using a channel label presented in the previous list.
```
# satellite-sync -c [channel-label] --mount-point /var/rhn-sat-import
```
Note
Importing package data can take up to two hours per channel. Register systems to channels as soon as they appear in the Red Hat Network Satellite Web Interface. No packages are necessary for registration, although updates cannot be retrieved from the Satellite until the channel is completely populated.
Repeat this step for each channel or include them all within a single command by passing each channel label preceded by an additional -c flag, like so:
```
# satellite-sync -c [channel-label-1] -c [channel-label-2] --mount-point /var/rhn-sat-import
```

After running the preceding command, the population of the channel should be complete. All of the packages should have been moved out of the repository; this can be verified with the following command:

# cd /var/rhn-sat-import/; ls -alR | grep rpm

If all RPMs have been installed and moved to their permanent locations, then this count will be zero, and the administrator may safely remove the temporary /var/rhn-sat-import/ repository.

6.3. Synchronization via Satellite Export

The Red Hat Network Satellite Exporter (rhn-satellite-exporter) tool exports Satellite content in an XML format, which a user imports into another identical Satellite. Export the content into a chosen directory with the -d option, transport the directory to another Satellite, and use the Red Hat Network Satellite Synchronization Tool to import the contents. This synchronizes the two Satellites.

The Red Hat Network Satellite Exporter provides the following content:

Channel Families
Architectures
Channel metadata
Blacklists
RPMs
RPM metadata
Errata
Kickstarts

To perform a Red Hat Network Satellite Exporter export, the following prerequisites must be met:

The Satellite installation must have been performed successfully.
There must be sufficient disk space in the directory specified in the --dir option to contain the exported contents.

6.3.1. Performing an Export

Configure the Satellite in the manner to duplicate into another Satellite or backup to a storage solution. Execute the command as root.

# rhn-satellite-exporter --dir=/var/rhn-sat-export --no-errata

When finished, the export directory may be moved to another Satellite or a storage solution using rsync or scp -r.

The Red Hat Network Satellite Exporter offers several command line options. To use them, insert the option and appropriate value after the rhn-satellite-exporter command.

Table 6.2. Red Hat Network Satellite Exporter Options

Option	Description
`-d, --dir=`	Place the exported information into this directory.
`-cCHANNEL_LABEL`, `--channel=CHANNEL_LABEL`	Process data for this specific channel (specified by label) only. NOTE: the channel's label is NOT the same as the channel's name.
`--list-channels`	List all available channels and exit.
`--list-steps`	List all of the steps that rhn-satellite-exporter takes while exporting data. These can be used as values for --step.
`-p --print-configuration`	Print the configuration and exit.
`--print-report`	Print a report to the terminal when the export is complete.
`--no-rpms`	Do not retrieve actual RPMs.
`--no-packages`	Do not export RPM metadata.
`--no-errata`	Do not process errata information.
`--no-kickstarts`	Do not process kickstart data (provisioning only).
`--debug-level=LEVEL_NUMBER`	Override the amount of messaging sent to log files and generated on the screen set in `/etc/rhn/rhn.conf`, 0-6 (2 is default).
`--start-date=START_DATE`	The start date limit that the last modified dates are compared against. Must be in the format YYYYMMDDHH24MISS (for example, `20071225123000`)
`--end-date=END_DATE`	The end date limit that the last modified dates are compared against. Must be typed in the format YYYYMMDDHH24MISS (for example, `20071231235900`)
`--make-isos=MAKE_ISOS`	Create a channel dump ISO directory called `satellite-isos` (for example, `--make-isos=cd` or `dvd`
`--email`	Email a report of what was exported and what errors may have occurred.
`--traceback-mail=EMAIL`	Alternative email address for --email.
`--db=DB`	Include alternate database connect string: username/password@SID.
`--hard-links`	Export the RPM and kickstart files with hard links to the original files.

Select the contents, such as RPMs, errata, or kickstarts, you would like to export using these command line options.

The amount of time it takes rhn-satellite-exporter to export data is dependent on the number and size of the channels being exported. Using the --no-packages, --no-kickstarts, --no-errata, and --no-rpms options reduces the amount of time required for rhn-satellite-exporter to run, but also prevents potentially useful information from being exported. For that reason, these options should only be used when you are certain that you will not need the content that they exclude. Additionally, you must use the matching options for satellite-sync when importing the data. For example, if you use --no-kickstarts with rhn-satellite-exporter you must specify the --no-kickstarts option when importing the data.

When exporting an Red Hat Network base channel, ensure to export the tools channel associated with that base channel. The tools channels contain the auto-kickstart packages, which install packages for kickstarting a machine through the Satellite.

6.3.2. Moving Red Hat Network Satellite Exporter Content

The following procedure copies the Red Hat Network Satellite Exporter data onto the local system for import.

Procedure 6.3. Moving Exporter Content

Log into the machine as root.
Create a target directory for the files, such as:
```
# mkdir /var/rhn-sat-import/
```
Make the export data available on the local machine in the directory created in the previous step. This can be done by copying the data directly, or by mounting the data from another machine using NFS. Copy the data into the new directory with the following command:
```
# scp -r root@storage.example.com:/var/rhn-sat-export/* /var/rhn-sat-import
```

Now that the data is available, you can procede to performing the import.

6.3.3. Performing an Import

The following process assumes in the previous step the user has copied all data to /var/rhn-sat-import.

List the channels available for import with the command:

# satellite-sync --list-channels --mount-point /var/rhn-sat-import

Initiate the import of a specific channel using a channel label presented in the previous list. Run the following command :
```
# satellite-sync -c [channel-label] --mount-point /var/rhn-sat-import
```
Note
Importing package data can take up to two hours per channel. You may begin registering systems to channels as soon as they appear in the Red Hat Network Satellite's website. No packages are necessary for registration, although updates cannot be retrieved from the Satellite until the channel is completely populated.
Repeat this step for each channel or include them all within a single command by passing each channel label preceded by an additional -c flag:
```
# satellite-sync -c channel-label-1 -c channel-label-2 -mount-point /var/rhn-sat-import
```
The population of channels is complete. Verify all of the packages are moved out of the repository with the following command:
```
# cd /var/rhn-sat-import/; ls -alR | grep rpm
```
This count will be zero if all RPMs have been installed and moved to their permanent locations. Remove the temporary /var/rhn-sat-import/ repository:
```
# rm -rf /var/rhn-sat-import
```

6.4. Synchronization with Red Hat Network

The satellite-sync command also synchronizes a connected Red Hat Network Satellite with Red Hat Network. This updates database metadata and RPM packages from the Red Hat Network servers.

Procedure 6.4. Synchronize with Red Hat Network

List available channels on your connected Red Hat Network Satellite using the --list-channels command.
```
# satellite-sync --list-channels
```
Synchronize with a Red Hat Network channel using the -c option.
```
# satellite-sync -c [channel-label]
```

For more satellite-sync options, see Section 6.1, “Red Hat Network Satellite Synchronization Tool”.

Chapter 7. Inter-Satellite Synchronization

Red Hat Network Satellite 5.5 supports synchronization between two Satellites. This synchronization allows administrators to simplify the process of coordinating content from one Red Hat Network Satellite source to another or several others.

The following are the basic requirements:

At least two Red Hat Network Satellite (version 5.3 or greater) servers;
At least one Red Hat Network Satellite populated with at least one channel; and,
Master Red Hat Network Satellite SSL certificate available on each of the Slave Red Hat Network Satellites for secure connection.

7.1. Recommended Models for Inter-Satellite Sync

The Inter-Satellite Sync feature for Satellite provides facilities for synchronizing content between two or more Satellites. The following are some of the more typical uses that show the possibilities of Inter-Satellite Sync and help guide you in determining how to make the most of this feature in your environment.

Figure 7.1. Staging Satellite

In this example, the Stage Satellite is used to prepare the content and perform quality assurance (QA) work — to make sure that packages are fit for production use. After content is approved to go to production, the Production Satellite will then synchronize the content from the Stage Satellite.

Figure 7.2. Master Server and Slave Peers that include their own custom content

In this example, the Master Satellite is the development channel, from which content is distributed to all Production Slave Satellites. Some Slave Satellites have extra content not present in Master Satellite channels. These packages are preserved, but all changes from Master Satellite are synchronized to Slave Satellite.

Figure 7.3. Slave Satellites are maintained exactly as the Master Satellite

In this example, the Master Satellite (for example, a software or Hardware vendor) provides data to its customer. These changes are regularly synchronized to Slave Satellites.

7.2. Configuring the Master Red Hat Network Satellite Server

To use the inter-satellite sync feature, you must first ensure that you have it enabled. Make sure that the /etc/rhn/rhn.conf contains the following line:

disable_iss=0

In the same file is the variable:

allowed_iss_slaves=

By default, no Slave Satellites are specified to sync from the Master server, so you must enter the hostname of each Slave Satellite server, separated by commas. For example:

allowed_iss_slaves=slave1.satellite.example.org,slave2.satellite.example.org

Once you finished configuring the rhn.conf file, restart the httpd service by issuing the following command:

service httpd restart

7.3. Configuring the Slave Red Hat Network Satellite Servers

To configure Red Hat Network Satellite Slave servers for Inter-Satellite Sync, ensure that you have the ORG-SSL certificate from your Master Red Hat Network Satellite server so you can securely transfer content. This can be downloaded over http from the /pub/ directory of any Satellite. The file is called RHN-ORG-TRUSTED-SSL-CERT, but can be renamed and placed anywhere on the Slave Satellite, such as the /usr/share/rhn/ directory.

For information about SSL configuration for use with Red Hat Network Satellite, refer to Chapter 3, "SSL Infrastructure" in the Red Hat Network Satellite Client Configuration Guide

Once the SSL certificate is placed on the Slave server, you can see the list of channels available to sync from the Master Satellite server by running the following command (replacing the master.satellite.example.com with the hostname of the Master Satellite server):

satellite-sync --iss-parent=master.satellite.example.com --ca-cert=/usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT --list-channels

This command lists both Red Hat Network Hosted channels as well as any custom channels available on the Master Satellite server.

7.4. Using Inter-Satellite Sync

Now that Inter-Satellite Sync is configured, you can now use it to synchronize channels from the Master Satellite to the Slave servers.

On the Slave servers, configure the Master server hostname and SSL certificate file path in the following lines of the /etc/rhn/rhn.conf file:

iss_parent      = master.satellite.domain.com
iss_ca_chain    = /usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT

Then run the satellite-sync command by typing:

# satellite-sync -c your-channel

Note

Any command line options to the satellite-sync command will override any default or customized settings in the /etc/rhn/rhn.conf file

7.4.1. Syncing between a Development Staging Server and a Production Satellite

There may be instances where an administrator wants to sync data from a staging server that has custom channels that are ready for production use to a Production Satellite server.

For example, a Production Satellite Server normally syncs directly from Red Hat Network Hosted servers for content updates, but will occasionally sync production-ready information from a Red Hat Network Satellite development server.

Figure 7.4. Syncing from Red Hat Network Hosted and a Satellite Staging Server

Normally, the administrator runs:

satellite-sync -c your-channel

This command downloads directly from data from rhn_parent (usually Red Hat Network Hosted, rhn.redhat.com). Then, to sync from the staging Satellite server address , the administrator runs:

satellite-sync --iss-parent=staging-satellite.example.com -c custom-channel

7.4.2. Bi-directional sync

Administrators can configure an environment where two Red Hat Network Satellite servers act as Masters of each other. For example, Satellite A and B can sync content from one another.

Figure 7.5. Bi-directional syncing

Both Satellites would need to share SSL certificates, then set the iss_parent option in the /etc/rhn/rhn.conf file of Satellite A to point to the hostname of Satellite B, and do the same for Satellite B to point to Satellite A as the iss_parent.

7.5. Synchronizing by Organization

The satellite-sync tool offers the ability to import content to any specific organization. This can be done locally or via a remote syncing from hosted or another satellite.

The aim is for Satellite sync to be able to import content with respect to orgid. This targets two sets of users. One is the disconnected Multi-Org case, where the main source of content for the user is either to get content from channel dumps or to export them from connected satellites and import it to the Satellite. The user mainly hosts custom channels from disconnected satellites. If they wish to export custom channels from connected satellites, they can do so by organizational sync.

The other case is a connected Multi-Org satellite customer. These new flags could work as a means of moving content between multiple orgs.

Synchronizing by organization has a few rules that it follows to maintain the integrity of the source org.

If the source content belongs to a base org (any Red Hat content) it will default to the base org even if a destination org is specified. This ensures that the specified content is always in that privileged base org.
If an org is specified at the command line, it will import content from that org.
If no org is specified, it will default to org 1.

The following are three example scenarios where organizational IDs (orgid) are used to synchronize between Satellites:

Example 7.1. Import content from Master to Slave satellite.

# satellite-sync --parent-sat=master.satellite.domain.com -c channel-name --orgid=2

Example 7.2. Import content from an exported dump of a specific org

# satellite-sync -m /dump -c channel-name --orgid=2

Example 7.3. Import content from Red Hat Network Hosted

# satellite-sync -c channel-name

Chapter 8. Upgrades

This chapter examines how to upgrade a pre-existing Red Hat Network Satellite to version 5.5. Please ensure to meet the requirements listed in Section 8.1, “Upgrade Requirements” before running the upgrade procedure.

8.1. Upgrade Requirements

An upgrade from one version of Satellite to another requires the following items:

An updated Satellite certificate;
Satellite Upgrade Package (rhn-upgrade);
New Installation ISO;

The following procedure explain how to obtain these items.

Procedure 8.1. Preparing for Satellite Upgrade

Obtain Satellite Certificate
1. Obtain a Satellite certificate from the Red Hat Customer Portal at https://access.redhat.com/home under Subscriptions.
2. Save this Certificate on your Satellite server.
Obtain Satellite Upgrade Package (rhn-upgrade)
1. Ensure the Satellite is registered to the Red Hat Network Satellite Channel.
2. Install the rhn-upgrade package with the following commmand:
```
# yum install rhn-upgrade
```
  This package installs scripts and a comprehensive set of instructions for a Satellite upgrade within the /etc/sysconfig/rhn/satellite-upgrade directory.
Obtain Installation ISO
1. Obtain a Red Hat Network Satellite 5.5 ISO from the Red Hat Customer Portal at https://access.redhat.com/home under Downloads.
2. Download this ISO to your Satellite server.

8.2. Upgrading a Satellite

Once you have obtained the required items for the Satellite upgrade, follow the next procedure to upgrade.

Important

The following is a basic procedure for upgrading Satellite from version 5.4 to 5.5. For comprehensive instructions, refer to the /etc/sysconfig/rhn/satellite-upgrade/README file in the rhn-upgrade package.

Procedure 8.2. Upgrade a Satellite

Mount the ISO as specified in Section 4.1.2, “Mounting the Installation Media”
Change your directory to the mounted ISO and run the Installer Program using the --upgrade option.
```
# cd /mount/cdrom
# ./install.pl --upgrade
```
Important
Ensure to use additional options if your Red Hat Network Satellite is disconnected or using a Stand-Alone Database. For more information, read Section 4.2.1, “Options for the Installer Script”.
Disable all services on the Satellite server:
```
# /usr/sbin/rhn-satellite stop
```
Important
The next step will upgrade the database schema. Ensure the database is running on your Stand-Alone Database. If using an Embedded Satabase, ensure the database is running via the following command:
```
# service oracle start
```
Upgrade the database with spacewalk-schema-upgrade:
```
# /usr/bin/spacewalk-schema-upgrade
```
Important
It is recommended to backup your database before upgrading.

Activate the Satellite. If using a connected Satellite:

# rhn-satellite-activate --rhn-cert [PATH-TO-NEW-CERT] --ignore-version-mismatch

If disconnected, run:

# rhn-satellite-activate --rhn-cert [PATH-TO-NEW-CERT] --disconnected --ignore-version-mismatch

Rebuild search indexes with the following command:
```
# service rhn-search cleanindex
```
This command makes the rhn-search service clean search indexes and restart.
Enable Monitoring and Monitoring Scout. To enable Monitoring without enabling Monitoring Scout, run the following command:
```
# /usr/share/spacewalk/setup/upgrade/rhn-enable-monitoring.pl
```
To enable both Monitoring and Monitoring Scout, run the following command:
```
# /usr/share/spacewalk/setup/upgrade/rhn-enable-monitoring.pl --enable-scout
```
Restart Satellite services:
```
# /usr/sbin/rhn-satellite restart
```

The upgrade procedure is complete and the Satellite is ready to use again.

Chapter 9. Maintenance

A Red Hat Network Satellite often also requires periodic maintenance to provide customers with the full benefit of service. This chapter discusses administrative functions outside of standard use, as well as to apply patches to the Red Hat Network Satellite.

9.1. Managing the Satellite with `rhn-satellite`

Since the Red Hat Network Satellite consists of a multitude of individual components, Red Hat provides a command-line tool that allows you to stop, start, or retrieve status information from the various services in the appropriate order: rhn-satellite. This tool accepts all of the typical commands:

/usr/sbin/rhn-satellite start
/usr/sbin/rhn-satellite stop
/usr/sbin/rhn-satellite restart
/usr/sbin/rhn-satellite reload
/usr/sbin/rhn-satellite enable
/usr/sbin/rhn-satellite disable
/usr/sbin/rhn-satellite status

Use rhn-satellite to shut down and bring up the entire Red Hat Network Satellite and retrieve status messages from all of its services at once.

9.2. Updating the Satellite

If any critical updates are made to Red Hat Network Satellite, they will be released in the form of an Erratum for the Red Hat Network Satellite.

For Red Hat Network Satellite systems that may be connected to the Internet, the best method for applying these errata updates is using the Red Hat Update Agent via Red Hat Network. Since the Red Hat Network Satellite is subscribed to Red Hat Network during initial installation, the user should be able to run yum update on the Red Hat Network Satellite or use the website at https://rhn.redhat.com to apply the updates.

Important

Apache RPMs do not restart the httpd service upon installation. Therefore, after conducting a full update of an Red Hat Network Satellite Server (such as with the command yum update), Apache may fail. To avoid this, make sure you restart the httpd service after upgrading it.

For Red Hat Network Satellite systems that may not be connected to the Internet, the packages themselves may be retrieved using a customer account at https://rhn.redhat.com. Then, they can be applied manually by the customer according to instructions in the Errata Advisory.

Warning

It is very important to read the Errata Advisory before applying any Red Hat Network Satellite Errata Updates. Additional configuration steps may be required to apply certain Red Hat Network Satellite updates, especially if they involve the database. In such cases, the advisory will contain specific and detailed information about necessary steps that may be required.

If instead of installing new Satellite packages, you are attempting to update the server's Red Hat Network Entitlement Certificate, such as to increase its number of client systems, refer to Chapter 5, Entitlements for instructions.

9.3. Backing up the Satellite

Backing up an Red Hat Network Satellite can be done in several ways. Regardless of the method chosen, the associated database also needs to be backed up. For the Stand-Alone Database, consult your organization's database administrator. For the Embedded Database, refer to Section 9.4, “Using RHN DB Control” for a complete description of this process and the options available.

Here are the minimum files and directories Red Hat recommends backing up:

/rhnsat/ - Embedded Database only (never to be backed up while the database is running - refer to Section 9.4.2, “Backing up the Database”)
/etc/sysconfig/rhn/
/etc/rhn/
/etc/sudoers
/etc/tnsnames.ora
/var/www/html/pub/
/var/satellite/redhat/1 - custom RPMs
/root/.gnupg/
/root/ssl-build/
/etc/dhcp.conf
/etc/httpd
/tftpboot/
/var/lib/cobbler/
/var/lib/rhn/kickstarts/
/var/www/cobbler
/var/lib/nocpulse/

If possible, back up /var/satellite/, as well. In case of failure, this will save lengthy download time. Since /var/satellite/ (specifically /var/satellite/redhat/NULL/) is primarily a duplicate of Red Hat's RPM repository, it can be regenerated with satellite-sync. Red Hat recommends the entire /var/satellite/ tree be backed up. In the case of disconnected satellites, /var/satellite/ must be backed up.

Backing up only these files and directories would require reinstalling the Red Hat Network Satellite ISO RPMs and reregistering the Satellite. In addition, Red Hat packages would need to be resynchronized using the satellite-sync tool. Finally, reinstall the following file:

/root/ssl-build/rhn-org-httpd-ssl-key-pair-MACHINE_NAME-VER-REL.noarch.rpm

Another method would be to back up all of the files and directories mentioned above but reinstall the Red Hat Network Satellite without reregistering it. During the installation, cancel or skip the Red Hat Network registration and SSL certificate generation sections.

The final and most comprehensive method would be to back up the entire machine. This would save time in downloading and reinstalling but would require additional disk space and back up time.

Important

Regardless of the back-up method used, when you restore the Satellite from a back-up, you must run the following command to schedule the recreation of search indexes the next time the rhn-search service is started:

/etc/init.d/rhn-search cleanindex

9.4. Using RHN DB Control

Red Hat Network Satellite with Embedded Database requires a utility for managing that database. Red Hat provides just such a tool: RHN DB Control. This command line utility allows you to do everything from make, verify, and restore backups to obtain database status and restart it when necessary. You must be the oracle user to invoke RHN DB Control. To begin, switch to the oracle user:

su - oracle

Next, issue the following command:

db-control option

9.4.1. DB Control Options

RHN DB Control offers many command line options. To use them, as oracle insert the option and the appropriate value, if needed, after the db-control command.

Table 9.1. RHN DB Control Options

Option	Description
`help`	Lists these `db-control` options with additional details.
`backup DIRNAME`	Backs up the database to the directory specified.
`examine DIRNAME`	Examines the contents of a backup directory. Returns the timestamp of backup creation and reports on its contents.
`extend`	Increase the Red Hat Network Oracle tablespace
`gather-stats PCT`	Gather statistics on Red Hat Network Oracle database objects. PCT is the percentage of rows to estimate (the default is 15%).
`report`	Reports on current usage of database space.
`report-stats`	Reports on segments with stale or empty statistics.
`restore DIRNAME`	Restores the database from backup kept in DIRNAME. Database must be stopped for this command to run successfully.
`start`	Starts the database instance. This can also be accomplished by issuing the `service oracle start` command as root.
`shrink-segments`	Shrinks Red Hat Network Oracle database segments with signifcant amounts of free space.
`status`	Shows the current status of the database, either "running" or "offline".
`stop`	Stops the database instance. This can also be accomplished by issuing the `service oracle stop` command as root.
`tablesizes`	Show space report for each table
`verify DIRNAME`	Verifies the contents of the backup kept in DIRNAME. This command runs a checksum of each of the files kept in the backup.

Note

Database statistics are collections of data that describe more details about the database and the objects in the database. These statistics are used by the query optimizer to choose the best execution plan for each SQL statement. Because the objects in a database can be constantly changing, statistics must be regularly updated so that they accurately describe these database objects. Statistics are maintained automatically by Oracle. However, if your database has performance issues after a significant amount of data changes, consider performing manual gathering of statistics.

Note

After deleting large amount of data, use the segment-shrink feature to reclaim fragmented free space in an Oracle Database segment. The benefits of segment-shrink are compaction of data that leads to better cache utilization and the compacted data requires fewer blocks to be scanned in full table scans, which both lead to better performance.

The segment shrink feature works only on newly created Oracle Database 10g Release 2 that comes with Red Hat Network Satellite Server. Due to different default database settings in Oracle Database 9i this feature does not work on databases that were upgraded from previous Red Hat Network Satellite Server releases.

9.4.2. Backing up the Database

Red Hat recommends performing nightly backups of the Embedded Database and moving the resulting directory to another system via NFS, SCP, FTP, etc. Preferably, this backup system resides off-site. To conduct a backup, shut down the database and related services first by issuing the following command as root:

/usr/sbin/rhn-satellite stop

Then switch to the oracle user and issue this command to initiate the backup:

db-control backup DIRNAME

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.

9.4.3. Verifying the Backup

Backing up the Embedded Database is useful only if you can ensure the integrity of the resulting backup. RHN DB Control 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 examine 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

9.4.4. Restoring the Database

RHN DB Control 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 restore DIRNAME

This not only restores the Embedded Database but first 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 following command:

/usr/sbin/rhn-satellite start

9.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:

Install Red Hat Network Satellite with Embedded Database (and a base install of Red Hat Enterprise Linux) on a separate machine, skipping the SSL Certificate generation step.
Back up the primary Satellite's database daily using the commands described in Section 9.4.2, “Backing up the Database”. If this is done, only changes made the day of the failure will be lost.
Establish a mechanism to copy the backup to the secondary Satellite and keep these repositories synchronized using a file transfer program such as rsync. Copying is not necessary if using a SAN.
Use RHN DB Control's restore option to import the duplicate data.
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. This ensures that Red Hat Network clients can authenticate with and securely connect to the secondary Satellite.
Change DNS to point to the new machine or configure your load balancer appropriately.

9.6. Establishing Redundant Satellites with Stand-Alone Database

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.

Procedure 9.1. Creating Redundant Satellites with Stand-Alone Database

Prepare the Stand-Alone Database for failover using Oracle's recommendations for building a fault-tolerant database. Consult your database administrator.
Install Red Hat Network Satellite with Stand-Alone Database on a separate machine, skipping the database configuration, database schema, SSL certificate, and bootstrap script generation steps. Include the same Red Hat Network account and database connection information provided during the initial Satellite install and register the new Satellite. For more information, see Section 4.3, “Installer Script Process”.
If your original SSL certificate does not take your high-availability solution into account, create a new one with a more appropriate Common Name value (see 3.2. The RHN SSL Maintenance Tool in the Red Hat Network Satellite Client Configuration Guide). In this case, generate a new bootstrap script (as defined in 5.2. Generating RHN Bootstrap Scripts in the Red Hat Network Satellite Client Configuration Guide) that captures this new value. Ensure the Common Name value represents the combined Satellite solution, not a single machine's hostname.
After installation, copy the following files from the primary Satellite to the secondary Satellite:
- /etc/rhn/rhn.conf
- /etc/tnsnames.ora
- /var/www/rhns/server/secret/rhnSecret.py
Copy and install the server-side SSL certificate RPMs from the primary Satellite to the secondary.
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, use it to install the certificate on client systems.
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.
Turn off the Red Hat Network Task Engine on the secondary Satellite with the following command:
```
/sbin/service taskomatic stop
```
You may use custom scripting or other means to establish automatic start-up/failover of the Red Hat Network Task Engine on the secondary Satellite. Regardless, it will need to be started upon failover.
Share channel package data (by default located in /var/satellite) between the Satellites over some type of networked storage device. This eliminates data replication and ensures a consistent store of data for each Satellite.
Share cache data (by default located in /var/cache/rhn) between the Satellites over some type of networked storage device. This eliminates data replication and ensures a consistent store of cached data for each Satellite.
Make the various Satellites available on your network via Common Name and a method suiting your infrastructure. Options include round-robin DNS, a network load balancer, and a reverse-proxy setup.

9.7. Changing the Satellite Hostname

If you need to change the hostname or IP address of your Satellite server, the spacewalk-utils package contains the spacewalk-hostname-rename script.

To use the spacewalk-hostname-rename script, you must first ensure that you know your SSL CA passphrase by performing the following command:

openssl rsa -in path/RHN-ORG-PRIVATE-SSL-KEY

Then enter passphrase when prompted.

spacewalk-hostname-rename requires one mandatory argument, which is the IP address of the Satellite server, regardless of whether the IP address will change along with the hostname or not.

The usage of spacewalk-hostname-rename is as follows:

spacewalk-hostname-rename <ip address> [ --ssl-country=<country> --ssl-state=<state>\
--ssl-org=<organization/company> --ssl-orgunit=<department> --ssl-email=<email address> --ssl-ca-password=<password>]

If there is a need to generate a new SSL certificate, all necessary information will be asked interactively via series of prompts, unless options are passed at the command-line (as in the above example). When the system hostname has not changed, the regeneration of a new SSL server certificate is not necessary. However, if at least one SSL option is specified, then spacewalk-hostname-rename will generate a certificate.

For more information about using spacewalk-hostname-rename, refer to the following Red Hat Knowledgebase entry:

https://access.redhat.com/kb/docs/DOC-32318.

9.8. Conducting Satellite-Specific Tasks

Using a Red Hat Network Satellite is quite similar to using the hosted version of Red Hat Network. For this reason, you should consult the Red Hat Network Reference Guide to obtain detailed instructions to standard tasks, such as editing System Profiles and updating packages. Tasks directly related to managing custom channels and errata are covered in the Red Hat Network Channel Management Guide. This section seeks to explain activities available only to Satellite customers.

9.8.1. Deleting Users

Because of the isolated environment in which Red Hat Network Satellites operate, Satellite customers have been granted the ability to delete users. To access this functionality, click Users in the top navigation bar of the Red Hat Network website. In the resulting User List, click the name of the user to be removed. This takes you to the User Details page. Click the delete user link at the top-right corner of the page.

Figure 9.1. User Deletion

A confirmation page appears explaining that this removal is permanent. To continue, click Delete User at the bottom-right corner of the page.

Note

The Organization Administrator role must be removed from the user's profile before deleting the user from the Red Hat Network Satellite. Failing to do so causes the delete operation to fail.

The Organization Administrator role may be removed by any Organization Administrator (provided they are not the sole Organization Administrator for the organization) by clicking on the Users tab and then visiting the Details subtab.

Figure 9.2. User Delete Confirmation

Many other options exist for managing users. You can find instructions for them in the Red Hat Network website chapter of the Red Hat Network Reference Guide.

9.8.2. Configuring Satellite Search

Satellite Administrators may want to configure certain search options to customize search results for their own optimization requirements.

Red Hat Network Satellite search results can be customized via the /etc/rhn/search.rhn-search.conf file. The following list defines the search configuration and their default values in parentheses.

search.index_work_dir

Specifies where Lucene indexes are kept (/usr/share/rhn/search/indexes).

search.rpc_handlers

Semi-colon separated list of classes to act as handlers for XMLRPC calls.

(filename>index:com.redhat.satellite.search.rpc.handlers.IndexHandler,
db:com.redhat.satellite.search.rpc.handlers.DatabaseHandler,
admin:com.redhat.satellite.search.rpc.handlers.AdminHandler)

search.max_hits_returned

Maximum number of results which will be returned for the query (500).

search.connection.driver_class

JDBC driver class to conduct database searches (oracle.jdbc.driver.OracleDriver).

search.score_threshold

Minimum score a result needs to be returned back as query result (.10).

search.system_score_threshold

Minimum score a system search result needs to be returned back as a query result (.01).

search.errata_score_threshold

Minimum score an errata search result needs to be returned back as a query result (.20).

search.errata.advisory_score_threshold

Minimum score an errata advisory result needs to be returned back as a query result (.30).

search.min_ngram

Minimum length of n-gram characters. Note that any change to this value requires clean-index to be run, and doc-indexes need to be modified and rebuilt (1).

search.max_ngram

Maximum length of n-gram characters. Note that any change to this value requires clean-index to be run, and doc-indexes need to be modified and rebuilt (5).

search.doc.limit_results

Type true to limit the number of results both on search.score_threshold and restrict max hits to be below search.max_hits_returned; type false means to return all documentation search matches (false).

search.schedule.interval

Input the time in miliseconds to control the interval with which the SearchServer polls the database for changes; the default is 5 minutes (300000).

search.log.explain.results

Used during development and debugging. If set to true, this will log additional information showing what influences the score of each result (false).

9.9. Automating Synchronization

Manually synchronizing the Red Hat Network Satellite repository with Red Hat Network can be a time-intensive task. United States business hours tend to be the peak usage time for Red Hat Network, so synchronization at that time may be slow. For these reasons, Red Hat encourages you to automate synchronization at other times to better balance load and ensure quick synchronization. Continental United States business hours are roughly 8:00 AM to 9:00 PM EST (UTC -5), due to four time zones, Monday through Friday. These hours may vary seasonally by one hour. Further, Red Hat strongly recommends that synchronization occur randomly for best performance.

This automation can be set easily by the addition of a simple cron job. To do this, edit the crontab as root:

crontab -e

This opens the crontab in a text editor, by default Vi. Another editor can be used by first changing the EDITOR variable, like so: export EDITOR=gedit.

Once opened, use the first five fields (minute, hour, day, month, and weekday) to schedule the synchronization. Ensure to use 24-hour clock format. Edit the crontab to include random synchronization, like so:

0 1 * * * perl -le 'sleep rand 9000' && satellite-sync --email >/dev/null \
2>/dev/null

This particular job will run randomly between 1:00 a.m. and 3:30 a.m. system time each night and redirect stdout and stderr from cron to prevent duplicating the more easily read message from satellite-sync. Options other than --email can also be included. Refer to Table 6.1, “satellite-sync Options” for the full list of options. Once you exit from the editor, the modified crontab is installed immediately.

9.10. Implementing PAM Authentication

Red Hat Network Satellite supports network-based authentication systems such as LDAP and Kerberos, using Pluggable Authentication Modules (PAM). PAM is a suite of libraries that helps system administrators integrate the Satellite with a centralized authentication mechanism, thus eliminating the need for remembering multiple passwords.

Note

To ensure that PAM authentication functions properly, install the pam-devel package.

Configuring Red Hat Network Satellite to use PAM

Create a PAM service file in the /etc/pam.d/ directory:
```
touch /etc/pam.d/rhn-satellite
```

Edit the file with the following information:

auth        required      pam_env.so
auth        sufficient    pam_sss.so 
auth        required      pam_deny.so
account     sufficient    pam_sss.so
account     required      pam_deny.so

Instruct the satellite to use the PAM service file by adding the following line to the /etc/rhn/rhn.conf file:
```
pam_auth_service = rhn-satellite
```
Restart the service to pick up the changes:
```
rhn-satellite restart
```
To enable a user to authenticate against PAM, select the checkbox labeled Pluggable Authentication Modules (PAM). It is positioned below the password and password confirmation fields on the Create User page.

9.11. Enabling Push to Clients

In addition to allowing client systems to regularly poll the Satellite for scheduled actions, you may enable the Satellite to immediately initiate those tasks on Provisioning-entitled systems. This bypasses the typical delay between scheduling an action and the client system checking in with Red Hat Network to retrieve it. This support is provided by the OSA dispatcher (osa-dispatcher).

OSA dispatcher is a service that periodically runs a query that checks the Satellite server to see if there are any commands to be executed on the client. If there are, it sends a message through jabberd to the osad instances running on the clients.

Important

SSL must be employed between the Satellite and its clients systems for this feature to work. If the SSL certificates are not available, the daemon on the client system fails to connect.

To take advantage of this feature, you must first configure your firewall rules to allow connections on the required port(s), as described in Section 2.4, “Additional Requirements”.

Then you must install the osa-dispatcher package, which can be found in the Red Hat Network Satellite software channel for the Satellite within the central Red Hat Network website. Once installed, start the service on the Satellite as root using the command:

service osa-dispatcher start

Finally, install the osad package on all client systems to receive pushed actions. The package can be found within the Red Hat Network Tools child channel for the systems on the Red Hat Network Satellite.

Warning

Do not install the osad package on the Satellite server, as it will conflict with the osa-dispatcher package installed on the Satellite.

Once installed, start the service on the client systems as root using the command:

service osad start

Like other services, osa-dispatcher and osad accept stop, restart, and status commands, as well.

Keep in mind, this feature depends on the client system recognizing the fully qualified domain name (FQDN) of the Satellite. This name and not the IP address of the server must be used when configuring the Red Hat Update Agent. Refer to the Red Hat Network Client Configuration Guide for details.

Now when you schedule actions from the Satellite on any of the push-enabled systems, the task will begin immediately rather than wait for the system to check in.

Chapter 10. Troubleshooting

This chapter provides tips for determining the cause of and resolving the most common errors associated with Red Hat Network Satellite. If you need additional help, contact Red Hat Network support at https://access.redhat.com/support/. Log in using your Satellite-entitled account to see the full list of options.

To begin troubleshooting general problems, examine the log file or files related to the component exhibiting failures. A useful exercise is to issue the tail -f command for all log files and then run yum list. You should then examine all new log entries for potential clues.

A common issue is full disk space. An almost sure sign of this is the appearance of halted writing in the log files. If logging stopped during a write, such as mid-word, you likely have filled disks. To confirm this, run this command and check the percentages in the Use% column:

# df -h

In addition to log files, you can obtain valuable information by retrieving the status of your Red Hat Network Satellite and its various components. This can be done with the command:

# /usr/sbin/rhn-satellite status

In addition, you can obtain the status of components such as the Apache Web server and the Red Hat Network Task Engine individually. For instance, to view the status of the Apache Web server, run the command:

# service httpd status

10.1. Installing and Updating

Q: SELinux keeps giving me messages when I'm trying to install. Why?
Q: I changed /var/satellite to an NFS mount, and now SELinux is stopping it working properly. What do I need to do?
Q: My Satellite is failing. Any idea why?

10.2. Services

Q: Why isn't the Apache Web server running?
Q: How do I find out what the status of the Red Hat Network Task Engine is?
Q: How do I find out what the status of the Satellite's Embedded Database is?
Q: What do I do if yum, up2date, or the push capability of the Red Hat Network Satellite stops working?

10.3. Connectivity

Q: I can't connect! How do I work out what is wrong?
Q: What do I do if importing or synchronizing a channel fails and I can't recover it?
Q: I'm getting "SSL_CONNECT" errors. What do I do now?

10.4. Logging and Reporting

Q: What are the different log files?
Q: How do I use spacewalk-report?
Q: How do I work out what version of the database schema I have?
Q: How do I work out what character set types I have?
Q: Why isn't the administrator getting email?
Q: How do I change the sender of the traceback mail?

10.5. Errors

Q: I'm getting an "Error validating satellite certificate" error during Red Hat Network Satellite installation. How do I fix it?
Q: I'm getting an "ERROR: server.mount_point not set in the configuration file" error when I try to activate or synchronize the Red Hat Network Satellite. How do I fix it?
Q: Why does cobbler check give an error saying that it needs a different version of yum-utils?
Q: I'm getting a "unsupported version" error when I try to activate the Red Hat Network Satellite certificate. How do I fix it?
Q: I'm getting an "Internal Server Error" complaining about ASCII when I try to edit the kickstart profile. What's going on?
Q: I'm getting "Host Not Found" or "Could Not Determine FQDN" errors. What do I do now?
Q: I'm getting a "This server is not an entitled Satellite" when I try to synchronize the Red Hat Network Satellite server. How do fix it?

10.1. Installing and Updating

SELinux keeps giving me messages when I'm trying to install. Why?

If you encounter any issues with SELinux messages (such as AVC denial messages) while installing Red Hat Network Satellite, be sure to have the audit.log files available so that Red Hat Support personnel can assist you. You can find the file in /var/log/audit/audit.log and can attach the file to your Support ticket for engineers to assist you.

I changed /var/satellite to an NFS mount, and now SELinux is stopping it working properly. What do I need to do?

You will need to tell SELinux about the NFS mount in order for it to allow that traffic. You can do this with the command:

# /usr/sbin/setsebool -P spacewalk_nfs_mountpoint on

If you are using Red Hat Enterprise Linux 6, you will also need to run the command:

# /usr/sbin/setsebool -P cobbler_use_nfs on

My Satellite is failing. Any idea why?

Do not subscribe your Red Hat Network Satellite to any of the following child channels available from Red Hat Network's central servers:

Red Hat Developer Suite
Red Hat Application Server
Red Hat Extras
JBoss product channels

Subscribing to these channels and updating your Satellite might install newer, incompatible versions of critical software components, causing the Satellite to fail.

10.2. Services

Why isn't the Apache Web server running?

If the Apache Web server isn't running, entries in your /etc/hosts file may be incorrect.

How do I find out what the status of the Red Hat Network Task Engine is?

To obtain the status of the Red Hat Network Task Engine, run the command:

# service taskomatic status

How do I find out what the status of the Satellite's Embedded Database is?

To view the status of the Satellite's Embedded Database, if it exists, run the command:

# service oracle status

What do I do if yum, up2date, or the push capability of the Red Hat Network Satellite stops working?

If yum, up2date, or the push capability of the Red Hat Network Satellite ceases to function, it is possible that old log files may be at fault. Stop the jabberd daemon before removing these files. To do so, issue the following commands as root:

# service jabberd stop
# rm -f /var/lib/jabberd/db/_db*
# service jabberd start

10.3. Connectivity

I can't connect! How do I work out what is wrong?

The following measures can be used to troubleshoot general connection errors:

Attempt to connect to the Red Hat Network Satellite's database at the command line using the correct connection string as found in /etc/rhn/rhn.conf:
```
# sqlplus username/password@sid
```
Ensure the Red Hat Network Satellite is using Network Time Protocol (NTP) and set to the appropriate time zone. This also applies to all client systems and the separate database machine in Red Hat Network Satellite with Stand-Alone Database.
Confirm the correct package:
```
rhn-org-httpd-ssl-key-pair-MACHINE_NAME-VER-REL.noarch.rpm 
```
is installed on the Red Hat Network Satellite and the corresponding rhn-org-trusted-ssl-cert-*.noarch.rpm or raw CA SSL public (client) certificate is installed on all client systems.
Verify the client systems are configured to use the appropriate certificate.
If also using one or more Red Hat Network Proxy Servers, ensure each Proxy's SSL certificates are prepared correctly. The Proxy should have both its own server SSL key-pair and CA SSL public (client) certificate installed, since it will serve in both capacities. Refer to the SSL Certificates chapter of the Red Hat Network Client Configuration Guide for specific instructions.
Make sure client systems are not using firewalls of their own, blocking required ports as identified in Section 2.4, “Additional Requirements”.

What do I do if importing or synchronizing a channel fails and I can't recover it?

If importing/synchronizing a channel fails and you can't recover it in any other way, run this command to delete the cache:

# rm -rf temporary-directory

Note

Section 6.2.1, “Preparing for Import from Local Media” specifies /var/rhn-sat-import/ as the temporary directory.

Next, restart the importation or synchronization.

I'm getting "SSL_CONNECT" errors. What do I do now?

A common connection problem, indicated by SSL_CONNECT errors, is the result of a Satellite being installed on a machine whose time had been improperly set. During the Satellite installation process, SSL certificates are created with inaccurate times. If the Satellite's time is then corrected, the certificate start date and time may be set in the future, making it invalid.

To troubleshoot this, check the date and time on the clients and the Satellite with the following command:

# date

The results should be nearly identical for all machines and within the "notBefore" and "notAfter" validity windows of the certificates. Check the client certificate dates and times with the following command:

# openssl x509 -dates -noout -in /usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT

Check the Satellite server certificate dates and times with the following command:

# openssl x509 -dates -noout -in /etc/httpd/conf/ssl.crt/server.crt

By default, the server certificate has a one-year life while client certificates are good for 10 years. If you find the certificates are incorrect, you can either wait for the valid start time, if possible, or create new certificates, preferably with all system times set to GMT.

10.4. Logging and Reporting

What are the different log files?

Virtually every troubleshooting step should start with a look at the associated log file or files. These provide invaluable information about the activity that has taken place on the device or within the application that can be used to monitor performance and ensure proper configuration. See Table 10.1, “Log Files” for the paths to all relevant log files:

There may be numbered log files (such as /var/log/rhn/rhn_satellite_install.log.1, /var/log/rhn/rhn_satellite_install.log.2, etc.) within the /var/log/rhn/ directory. These are rotated logs, which are log files created with a .<NUMBER> extension when the current rhn_satellite_install.log file fills up to a size as specified by the logrotate(8) daemon and the contents written to a rotated log file. For example, the rhn_satellite_install.log.1 contains the oldest rotated log file, while rhn_satellite_install.log.4 contains the most recently rotated log.

Table 10.1. Log Files

Component/Task	Log File Location
Apache Web server	`/var/log/httpd/` directory
Red Hat Network Satellite	`/var/log/rhn/` directory
Red Hat Network Satellite Installation Program	`/var/log/rhn/rhn_satellite_install.log`
Database installation - Embedded Database	`/var/log/rhn/install_db.log`
Database population	`/var/log/rhn/populate_db.log`
Red Hat Network Satellite Synchronization Tool	`/var/log/rhn/rhn_server_satellite.log`
Monitoring infrastructure	`/var/log/nocpulse/` directory
Monitoring notifications	`/var/log/notification/` directory
Red Hat Network DB Control - Embedded Database	`/var/log/rhn/rhn_database.log`
Red Hat Network Task Engine (taskomatic)	`/var/log/messages`
yum	`/var/log/yum.log`
XML-RPC transactions	`/var/log/rhn/rhn_server_xmlrpc.log`

How do I use spacewalk-report?

There are instances where administrators may need a concise, formatted summary of their Red Hat Network Satellite resources, whether it is to take inventory of their entitlements, subscribed systems, or users and organizations. Rather than gathering such information manually from the Satellite Web interface, Red Hat Network Satellite includes the spacewalk-report command to gather and display vital Satellite information at once.

Note

To use spacewalk-report you must have the spacewalk-reports package installed.

spacewalk-report allows administrators to organize and display reports about content, errata, systems, system event history, and user resources across the Satellite. The spacewalk-report command is used to generate reports on:

System Inventory — Lists all of the systems registered to the Satellite.
Entitlements — Lists all organizations on the Satellite, sorted by system or channel entitlements.
Errata — Lists all the errata relevant to the registered systems, sorts errata by severity as well as the systems that apply to a particular erratum.
Users — Lists all the users registered to the Satellite, and lists any systems associated with a particular user.
System History — Lists all, or a subset, of the system events that have occurred.

To get a report in CSV format, run the following at the command prompt of your Satellite server.

# spacewalk-report report_name

The following reports are available:

Table 10.2. spacewalk-report Reports

Report	Invoked as	Description
System Inventory	`inventory`	List of systems registered to the server, together with hardware and software information
Entitlements	`entitlements`	Lists all organizations on the Satellite with their system or channel entitlements
Errata in channels	`errata-channels`	Lists errata in channels
All Errata	`errata-list-all`	Complete list of all errata
Errata for systems	`errata-systems`	Lists applicable errata and any registered systems that are affected
Users in the system	`users`	Lists all users registered to the Satellite
Systems administered	`users-systems`	Lists systems that can be administered by individual users
Kickstart Trees	`kickstartable-trees`	Lists trees able to be kickstarted
System history	`system-history`	Lists system event history
System history channels	`system-history-channels`	Lists system event history
System history configuration	`system-history-configuration`	Lists system configuration event history
System history entitlements	`system-history-entitlements`	Lists system entitlement event history
System history errata	`system-history-errata`	Lists system errata event history
System history kickstart	`system-history-kickstart`	Lists system kickstart and provisioning event history
System history packages	`system-history-packages`	Lists system package event history

For more information about an individual report, run spacewalk-report with the --info or --list-fields-info and the report name. The description and list of possible fields in the report will be shown.

For further information, the spacewalk-report(8) manpage as well as the --help parameter of the spacewalk-report program can be used to get additional information about the program invocations and their options.

How do I work out what version of the database schema I have?

To determine the version of your database schema, run the command:

# rhn-schema-version

How do I work out what character set types I have?

To derive the character set types of your Satellite's database, run the command:

# rhn-charsets

Why isn't the administrator getting email?

If the administrator is not getting email from the Red Hat Network Satellite, confirm the correct email addresses have been set for traceback_mail in /etc/rhn/rhn.conf.

How do I change the sender of the traceback mail?

If the traceback mail is marked from dev-null@rhn.redhat.com and you would like the address to be valid for your organization, include the web.default_mail_from option and appropriate value in /etc/rhn/rhn.conf.

10.5. Errors

I'm getting an "Error validating satellite certificate" error during Red Hat Network Satellite installation. How do I fix it?

An "Error validating satellite certificate" error during Red Hat Network Satellite installation is caused by having an HTTP proxy in the environment. This can be confirmed by looking at the install.log file, and locating the following error:

ERROR: unhandled exception occurred: 
Traceback (most recent call last): 
  File "/usr/bin/rhn-satellite-activate", line 45, in ? 
    sys.exit(abs(mod.main() or 0)) 
  File "/usr/share/rhn/satellite_tools/rhn_satellite_activate.py", line 585, in main 
    activateSatellite_remote(options) 
  File "/usr/share/rhn/satellite_tools/rhn_satellite_activate.py", line 291, in activateSatellite_remote 
    ret = s.satellite.deactivate_satellite(systemid, rhn_cert) 
  File "/usr/lib/python2.4/site-packages/rhn/rpclib.py", line 603, in __call__ 
    return self._send(self._name, args) 
  File "/usr/lib/python2.4/site-packages/rhn/rpclib.py", line 326, in _request 
    self._handler, request, verbose=self._verbose) 
  File "/usr/lib/python2.4/site-packages/rhn/transports.py", line 171, in request 
    headers, fd = req.send_http(host, handler) 
  File "/usr/lib/python2.4/site-packages/rhn/transports.py", line 698, in send_http 
    self._connection.connect() 
  File "/usr/lib/python2.4/site-packages/rhn/connections.py", line 193, in connect 
    sock.connect((self.host, self.port)) 
  File "<string>", line 1, in connect 
socket.timeout: timed out

To resolve the issue:

Run the install script in disconnected mode, and skip the database installation which has already been done:
```
# ./install.pl --disconnected --skip-db-install
```
Open /etc/rhn/rhn.conf with your preferred text editor, and add or modify the following line:
```
server.satellite.rhn_parent = satellite.rhn.redhat.com
```
Remove the following line:
```
disconnected=1
```
If you are using a proxy for the connection to Red Hat Network, you will also need to add or modify the following lines to reflect the proxy settings.
```
server.satellite.http_proxy = <hostname>:<port>
server.satellite.http_proxy_username = <username>
server.satellite.http_proxy_password = <password>
```
Re-activate the Satellite in connected mode, using the rhn-satellite-activate command as the root user, including the path and filename of the satellite certificate:
```
# rhn-satellite-activate --rhn-cert=/path/to/file.cert
```

Alternatively, try running the install.pl script in connected mode, but with the --answer-file=answer file option. Ensure the answer file has the HTTP proxy information specified as follows:

rhn-http-proxy = <hostname>:<port>
rhn-http-proxy-username = <username>
rhn-http-proxy-password = <password>

I'm getting an "ERROR: server.mount_point not set in the configuration file" error when I try to activate or synchronize the Red Hat Network Satellite. How do I fix it?

An "ERROR: server.mount_point not set in the configuration file" error during Red Hat Network Satellite activation or synchronization can occur if the mount_point configuration parameter in /etc/rhn/rhn.conf does not point to a directory path, or the directory path it points to is not present or does not have permission to access the directory.

To resolve the issue, check the value of the mount_point configuration parameter in /etc/rhn/rhn.conf. If it set to the default value of /var/satellite, verify that the /var/satellite and /var/satellite/redhat directories exist. For all values, check that path to the file is accurate, and that the permissions are set correctly.

Why does cobbler check give an error saying that it needs a different version of yum-utils?

Sometimes, running the cobbler check command can give an error similar to the following:

# cobbler check 
The following potential problems were detected: 
#0: yum-utils need to be at least version 1.1.17 for reposync -l, current version is 1.1.16

This is a known issue in Cobbler's reposync package. The error is spurious and can be safely ignored. This error will be resolved in future versions of Red Hat Network Satellite.

I'm getting a "unsupported version" error when I try to activate the Red Hat Network Satellite certificate. How do I fix it?

If your Red Hat Network Satellite certificate has become corrupted, you could get one of the following errors:

ERROR: <Fault -2: 'unhandled internal exception: unsupported version: 96'>

RHN_PARENT: satellite.rhn.redhat.com
     Error reported from RHN: <Fault -2: 'unhandled internal exception: unsupported version: 115'>
     ERROR: unhandled XMLRPC fault upon remote activation: <Fault -2: 'unhandled internal exception: unsupported version: 115'>
     ERROR: <Fault -2: 'unhandled internal exception: unsupported version: 115'>

Invalid satellite certificate

To resolve this issue, contact Red Hat support services for a new certificate.

I'm getting an "Internal Server Error" complaining about ASCII when I try to edit the kickstart profile. What's going on?

If you have recently added some kernel parameters to your kickstart profile, you might find that when you attempt to View a List of Kickstart Profiles that you get the following Internal Server Error:

'ascii' codec can't encode character u'\u2013'

This error occurs because some text in the profile is not being recognised correctly.

To resolve the issue:

Ssh directly onto the Satellite server as the root user:
```
# ssh root@satellite.fqdn.com
```
Find the kickstart profile that is causing the problem by looking at the dates of the files in /var/lib/cobbler/config/profiles.d and locating the one that was edited most recently:
```
# ls -l /var/lib/cobbler/config/profiles.d/
```
Open the profile in your preferred text editor, and locate the following text:
```
\u2013hostname
```
Change the entry to read:
```
--hostname
```
Save changes to the profile and close the file.

Restart the Red Hat Network Satellite services to pick up the updated profile:

# rhn-satellite restart
Shutting down rhn-satellite...
Stopping RHN Taskomatic...
Stopped RHN Taskomatic.
Stopping cobbler daemon:                                   [  OK  ]
Stopping rhn-search...
Stopped rhn-search.
Stopping MonitoringScout ...                               [  OK  ]
Stopping Monitoring ...                                    [  OK  ]
Stopping httpd:                                            [  OK  ]
Stopping tomcat5:                                          [  OK  ]
Shutting down osa-dispatcher:                              [  OK  ]
Shutting down Oracle Net Listener ...                      [  OK  ]
Shutting down Oracle DB instance "rhnsat" ...              [  OK  ]
Shutting down Jabber router:                               [  OK  ]
Done.
Starting rhn-satellite...
Starting Jabber services                                   [  OK  ]
Starting Oracle Net Listener ...                           [  OK  ]
Starting Oracle DB instance "rhnsat" ...                   [  OK  ]
Starting osa-dispatcher:                                   [  OK  ]
Starting tomcat5:                                          [  OK  ]
Starting httpd:                                            [  OK  ]
Starting Monitoring ...                                    [  OK  ]
Starting MonitoringScout ...                               [  OK  ]
Starting rhn-search...
Starting cobbler daemon:                                   [  OK  ]
Starting RHN Taskomatic...
Done.

Return to the web interface. Note that interface can take some time to resolve the services, but should return to normal after a minute or so.

I'm getting "Host Not Found" or "Could Not Determine FQDN" errors. What do I do now?

Because Red Hat Network configuration files rely exclusively on fully qualified domain names (FQDNs), it is imperative that key applications are able to resolve the name of the Red Hat Network Satellite into an IP address. Red Hat Update Agent, Red Hat Network Registration Client, and the Apache Web server are particularly prone to this problem with the Red Hat Network applications issuing errors of "host not found" and the Web server stating "Could not determine the server's fully qualified domain name" upon failing to start.

This problem typically originates from the /etc/hosts file. You may confirm this by examining /etc/nsswitch.conf, which defines the methods and the order by which domain names are resolved. Usually, the /etc/hosts file is checked first, followed by Network Information Service (NIS) if used, followed by DNS. One of these has to succeed for the Apache Web server to start and the Red Hat Network client applications to work.

To resolve this problem, identify the contents of the /etc/hosts file. It may look like this:

127.0.0.1 this_machine.example.com this_machine localhost.localdomain \ localhost

First, in a text editor, remove the offending machine information, like so:

127.0.0.1 localhost.localdomain.com localhost

Then, save the file and attempt to re-run the Red Hat Network client applications or the Apache Web server. If they still fail, explicitly identify the IP address of the Satellite in the file, such as:

127.0.0.1 localhost.localdomain.com localhost
123.45.67.8 this_machine.example.com this_machine

Replace the value here with the actual IP address of the Satellite. This should resolve the problem. Keep in mind, if the specific IP address is stipulated, the file will need to be updated when the machine obtains a new address.

I'm getting a "This server is not an entitled Satellite" when I try to synchronize the Red Hat Network Satellite server. How do fix it?

If satellite-sync reports that the server is not activated as an Red Hat Network Satellite, it isn't subscribed to the respective Red Hat Network Satellite channel. If this is a newly installed system then the satellite certificate is possibly not activated on the system. If it was activited earlier, then it has become deactivated.

Check the system's child channels to discover if it is subscribed to any Red Hat Network Red Hat Network Satellite channel. View subscribed channels with the following command:

# yum repolist

Activate the same Satellite certificate again on your Satellite using this command as the root user:

# rhn-satellite-activate -vvv --rhn-cert=/path/to/certificate

Note

If you have exhausted these troubleshooting steps or want to defer them to Red Hat Network professionals, Red Hat recommends you take advantage of the strong support that comes with Red Hat Network Satellite. The most efficient way to do this is to aggregate your Satellite's configuration parameters, log files, and database information and send this package directly to Red Hat.

Red Hat Network provides a command line tool explicitly for this purpose: The Satellite Diagnostic Info Gatherer, commonly known by its command satellite-debug. To use this tool, issue the command as root. You will see the pieces of information collected and the single tarball created, like so:

# satellite-debug
Collecting and packaging relevant diagnostic information.
Warning: this may take some time...
    * copying configuration information
    * copying logs
    * querying RPM database (versioning of RHN Satellite, etc.)
    * querying schema version and database character sets
    * get diskspace available
    * timestamping
    * creating tarball (may take some time): /tmp/satellite-debug.tar.bz2
    * removing temporary debug tree
 
Debug dump created, stored in /tmp/satellite-debug.tar.bz2
Deliver the generated tarball to your RHN contact or support channel.

Once finished, email the new file from the /tmp/ directory to your Red Hat representative for immediate diagnosis.

Appendix A. Sample Red Hat Network Satellite Configuration File

The /etc/rhn/rhn.conf configuration file for the Red Hat Network Satellite provides a means for you to establish key settings. Be warned, however, that errors inserted into this file may cause Satellite failures. So make configuration changes with caution.

You should be particularly concerned with the following parameters: traceback_mail, default_db, and server.satellite.http_proxy. Review the sample and its comments, beginning with a hash mark (#), for additional details.

#/etc/rhn/rhn.conf example for an RHN Satellite
#----------------------------------------------

# Destination of all tracebacks, such as crash information, etc.
traceback_mail = test@pobox.com, test@redhat.com

# Location of RPMs (Red Hat and custom) served by the RHN Satellite
mount_point = /var/satellite

# Corporate gateway (hostname:PORT):
server.satellite.http_proxy = corporate_gateway.example.com:8080
server.satellite.http_proxy_username = 
server.satellite.http_proxy_password = 

# Database connection information username/password@SID
default_db = test01/test01@test01


### DON'T TOUCH ANY OF THE FOLLOWING ###
web.satellite = 1

web.session_swap_secret_1 = ea6c79f71cfcf307d567fed583c393b9
web.session_swap_secret_2 = 01dee83a7b7f27157f5335744eb02327
web.session_swap_secret_3 = 4e89e7697ce663149ca9e498cbc08b4f
web.session_swap_secret_4 = a0fed2d77a950fc9a800b450a45e89d2

web.session_secret_1 = 24bc562e04c9b93f5be94f793738e104
web.session_secret_2 = 7667a7c2db311b1ea04271ecc1b82314
web.session_secret_3 = 442e7dc4f06f63eba9a0408d499c6a8d
web.session_secret_4 = 587a0db47856f685d989095629a9bd6f

encrypted_passwords = 1

web.param_cleansers = RHN::Cleansers->cleanse
web.base_acls = RHN::Access

web.default_taskmaster_tasks = RHN::Task::SessionCleanup,
                               RHN::Task::ErrataQueue, 
                               RHN::Task::ErrataEngine, 
                               RHN::Task::DailySummary, 
                               RHN::Task::SummaryPopulation, 
                               RHN::Task::RHNProc, 
                               RHN::Task::PackageCleanup

web.rhn_gpg_backend_module = RHN::GPG::OpenPGP

web.restrict_mail_domains =

Appendix B. Revision History

Revision History

Revision 3-18.401

Thu Aug 20 2015

Dan Macpherson

Mass publication of all Satellite 5.5 books

Revision 3-18.400

2013-10-31

Rüdiger Landmann

Rebuild with publican 4.0.0

Revision 3-18

Thu Sept 27 2012

Dan Macpherson

Minor typo fixes

Revision 3-17

Wed Sept 19 2012

Dan Macpherson

Final packaging for 5.5

Revision 3-16

Thu Aug 22 2012

Daniel Macpherson

Minor addition to Troubleshooting chapter

Revision 3-15

Thu Aug 22 2012

Daniel Macpherson

Minor fix to table

Revision 3-14

Wed Aug 21 2012

Daniel Macpherson

Added Author Group and frontpage graphic

Revision 3-13

Tue Aug 21 2012

Daniel Macpherson

Final QE revisions

Redundant graphics and file cleaning

Revision 3-12

Tue Aug 21 2012

Daniel Macpherson

Final QE revisions

Revision 3-11

Tue Aug 21 2012

Daniel Macpherson

Revising screenshots

Revision 3-10

Tue Aug 21 2012

Daniel Macpherson

Minor edits to content

Revision 3-9

Tue Aug 21 2012

Daniel Macpherson

Minor edits to content

Revision 3-8

Mon Aug 20 2012

Daniel Macpherson

Added Upgrades chapter

Revision 3-7

Mon Aug 20 2012

Daniel Macpherson

Implemented feedback from QE review

Revision 3-6

Mon Aug 13 2012

Daniel Macpherson

Revised graphics in Red Hat style

Revision 3-5

Mon Aug 13 2012

Daniel Macpherson

BZ#847295 - Added feedback from technical review

Revision 3-4

Mon Aug 06 2012

Daniel Macpherson

BZ#839503 - Warning note in Chapter 2.4 needs to mention not to subscribe to JBoss Channels

BZ#812737 - RHN Satellite installation guide should explain that system has to be registered to be registered by RHN Classic way

BZ#705164 - Not all applications use only TCP ports

Revision 3-2

Mon Aug 06 2012

Daniel Macpherson

Book-wide revisions to all chapters

Revision 3-1

Wed Jul 11 2012

Daniel Macpherson

Revisions to Introduction chapter

Revision 3-0

Tue May 22 2012

Athene Chan

BZ#822704 - Updated package name "satellite-utils" to "spacewalk-utils", updated command from "satellite-hostname-rename" to "spacewalk-hostname-rename"

BZ#783340 - Updated "s390x" to "IBM System z"

Revision 2-8

Wed Jan 4 2012

Lana Brindley

BZ#719289 - Install instructions

BZ#735539 - Updated Install using HTTP Proxy instructions

BZ#739582 - Updated PAM instructions

Revision 2-7

Wed Jan 4 2012

Lana Brindley

BZ#719289 - Install instructions

BZ#632303 - Hardware Req's

BZ#717165 - Layout error

BZ#735539 - Updated Install using HTTP Proxy instructions

BZ#736549 - Changed name of tools package

BZ#738805 - Updated spacewalk report info in Troubleshooting chapter

BZ#739582 - Updated PAM instructions

BZ#767979 - Updated PAM instructions

Revision 2-6

Wed Oct 26 2011

Lana Brindley

BZ#705164 - Additional Req's

BZ#709100 - FAQs

BZ#717165 - Layout error

BZ#719289 - Add note to Install instructions

BZ#735539 - Added extra setting to Install using HTTP Proxy instructions

BZ#736549 - Changed name of tools package

BZ#739582 - Updated PAM instructions

Revision 2-5

Mon Aug 15 2011

Lana Brindley

Folded z-stream release into y-stream

Revision 2-4

Wed Jul 6 2011

Lana Brindley

BZ#717165 - Added RHEL 6 references

Revision 2-3

Wed Jun 22 2011

Lana Brindley

BZ#713550 - Added RHEL 6 references

Revision 2-2

Wed Jun 15 2011

Lana Brindley

Prepared for publication

Revision 2-1

Fri May 27 2011

Lana Brindley

Updates from translators

Revision 2-0

Fri May 6 2011

Lana Brindley

Prepared for translation

Revision 1-36

Tue May 3 2011

Lana Brindley

BZ#701292 - Remove outdated section

Revision 1-35

Wed April 27 2011

Lana Brindley

BZ#637809 - QE review

Revision 1-34

Wed April 13 2011

Lana Brindley

BZ#695989 - Technical review

Revision 1-33

Tue Feb 8 2011

Lana Brindley

Reorganised Troubleshooting chapter

Revision 1-32

Mon Feb 7 2011

Lana Brindley

BZ#535468 - Maintenance

BZ#663225 - Database Requirements

BZ#671085 - Topologies

Revision 1-31

Mon Feb 7 2011

Lana Brindley

BZ#637809 - Database Requirements

Turned Troubleshooting chapter into Q&A set

BZ#484689 - Troubleshooting

Revision 1-30

Mon Jan 31 2011

Lana Brindley

BZ#462396 - Additional Requirements

BZ#589375 - Installation

BZ#591259 - Introduction

Legal Notice

This document is licensed by Red Hat under the Creative Commons Attribution-ShareAlike 3.0 Unported License. If you distribute this document, or a modified version of it, you must provide attribution to Red Hat, Inc. and provide a link to the original. If the document is modified, all Red Hat trademarks must be removed.

Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.

Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.

Linux® is the registered trademark of Linus Torvalds in the United States and other countries.

Java® is a registered trademark of Oracle and/or its affiliates.

XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.

MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.

Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.

The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.

All other trademarks are the property of their respective owners.

Language and Page Formatting Options

Red Hat Training

Installation Guide

Red Hat Network Satellite

Daniel Macpherson

Lana Brindley

Athene Chan

Preface

1. About This Guide

2. Audience

Chapter 1. Introduction

1.1. About Red Hat Network Satellite

1.2. System Overview

1.3. Terms to Understand

1.4. Summary of Steps

Chapter 2. Requirements

2.1. Software Requirements

2.2. Stand-Alone Database Requirements

2.2.1. x86_64 Hardware Requirements for Stand-Alone Database Installations

2.2.2. s/390 Hardware Requirements for Stand-Alone Database Installations

2.2.3. Database Requirements for Stand-Alone Database Installations

2.3. Embedded Database Requirements

2.3.1. x86_64 Hardware Requirements for Embedded Database Installations

2.3.2. s/390 Hardware Requirements for Embedded Database Installations

2.4. Additional Requirements

2.4.1. Firewall

2.4.2. SELinux Policy

2.4.3. DMZ Proxy Solution

2.4.4. Synchronized System Times

2.4.5. Setting System Language and Locale

2.4.6. Fully Qualified Domain Name (FQDN)

2.4.7. Functioning Domain Name Service (DNS)

2.4.8. Entitlement Certificate

2.4.9. Red Hat Network Account

2.4.10. Backups of Login Information

2.4.11. Channel Content ISOs

2.4.12. Service Access

2.4.13. Additional Documentation

Chapter 3. Example Topologies

3.1. Single Satellite Topology

3.2. Multiple Satellite Horizontally Tiered Topology

3.3. Satellite-Proxy Vertically Tiered Topology

Chapter 4. Installation

4.1. Prerequisites

4.1.1. Base Operation System

4.1.2. Mounting the Installation Media

4.1.3. Obtaining an Entitlement Certificate

4.2. Pre-Installation

4.2.1. Options for the Installer Script

4.2.2. Automated Red Hat Network Satellite Server Installation

4.2.3. Installing Behind a HTTP Proxy: Pre-Configuration

4.3. Installer Script Process

4.3.1. Running the Installer Script

4.3.2. Database Configuration

4.3.3. Initial Configuration

4.3.4. Entitlement Certificate Configuration

4.3.5. CA Certificate Configuration

4.4. Post-Installation

4.4.1. Installing Behind a HTTP Proxy: Post-Configuration

4.4.2. Create Admin User

4.4.3. Finalize Configuration

4.4.3.1. General Configuration

4.4.3.2. Certificate

4.4.3.3. Bootstrap

4.4.4. Organizations

4.4.5. Restart

4.4.6. Cobbler Rebuild

4.4.7. Message Transfer Agent (MTA) Configuration

4.4.7.1. Sendmail

4.4.7.2. Postfix

4.4.8. MySQL Installation for Monitoring

Chapter 5. Entitlements

5.1. Red Hat Network Satellite Activate

5.2. Activate Satellite with a New Entitlement Certificate

5.3. Satellite Entitlement Certificate Expiration

Chapter 6. Content and Synchronization

6.1. Red Hat Network Satellite Synchronization Tool

6.2. Synchronization with Local Media

6.2.1. Preparing for Import from Local Media

6.2.2. Import from Local Media

9.1. Managing the Satellite with `rhn-satellite`