7.5. Optional Configuration Options

The following sections show how to enable additional configuration options for the Satellite Capsule Server.

7.5.1. Configuring Red Hat Satellite Capsule Server with a Custom Server Certificate

Red Hat Satellite comes with a default certificate authority (CA) used by both the server and client SSL certificates for authentication of subservices. The server and client certificates can be replaced with custom ones. For more information on creating custom certificates, see the Red Hat Enterprise Linux 7 Security Guide.[8]
Custom server and client certificates may be implemented either when the command capsule-certs-generate is first run or any time afterward. If capsule-certs-generate has not been run before, see Procedure 7.2, “To Set a Custom Server Certificate When Running capsule-certs-generate for the First Time:”, otherwise see Procedure 7.3, “To Set a Custom Server Certificate After Running capsule-certs-generate:”.

Important

When using custom SSL certificates with chained trusts or issuers, include all certificates in the chain into a single file and use that file as the CA certificate value to katello-installer parameter --certs-server-ca-cert. It is important to concatenate the certificates in the right order so that the trust chain can be validated.
# cat 1st_ca.cert 2nd_ca.cert 3th_ca.cert > /root/sat_cert/ca.bundle
# katello-installer --certs-server-ca-cert /root/sat_cert/ca.bundle --certs-update-server-ca
The certificate's Common Name (CN) must match the fully qualified domain name of the server on which it is used.

Important

The certificate's Common Name (CN) must match the fully qualified domain name of the server on which it is used.

Prerequisites

You must have the following files:
Certificate file for the Capsule Server.
Capsule certificates generate parameter --server-cert. In this example, capsule.crt.
Certificate signing request file for the Capsule Server.
Capsule certificates generate parameter --server-cert-req. In this example, capsule.crt.req.
Capsule Server's private key used to sign the certificate.
Capsule certificates generate parameter --server-key. In this example, capsule.key.
CA certificate.
Capsule certificates generate parameter --server-ca-cert. In this example, example cacert.crt.

Other capsule-certs-generate Parameters

  • The parameter --certs-tar specifies the name of the archive file to be output by the capsule-certs-generate.
  • The parameter --capsule-fqdn is the Satellite Capsule Server's fully qualified domain name.

Procedure 7.2. To Set a Custom Server Certificate When Running capsule-certs-generate for the First Time:

Note

In this example the files are stored in the directory /root/sat_cert. Using an absolute path in the root users' directory provides a fixed location that is available to all users who log in to the server with root permissions. Before running this command, ensure the directory already exists.
  1. Run the following command on the Red Hat Satellite Server to create the certificates archive:
    # capsule-certs-generate \
    --capsule-fqdn "capsule.example.com" \
    --certs-tar /root/sat_cert/capsule.example.com-certs.tar \
    --server-cert /root/sat_cert/capsule.crt \
    --server-cert-req /root/sat_cert/capsule.crt.req \
    --server-key /root/sat_cert/capsule.key \
    --server-ca-cert /root/sat_cert/cacert.crt
    Where:
    • --capsule-fqdn is the Satellite Capsule Server's fully qualified domain name. Mandatory.
    • --certs-tar is the name of the tar file to be generated that contains the certificate to be used by the Satellite Capsule installer.
    • --server-cert is the path to your certificate, signed by your certificate authority (or self-signed).
    • --server-cert-req is the path to your certificate signing request file that was used to create the certificate.
    • --server-key is the private key used to sign the certificate.
    • --server-ca-cert is the path to the CA certificate on this system.
  2. Copy the generated archive file, capsule.example.com-certs.tar, from the Satellite Server to the Satellite Capsule Server.
  3. On the Satellite Capsule Server:
    1. Run the following commands to register your Satellite Capsule Server to the Satellite Server:
      # rpm -Uvh http://satellite.example.redhat.com/pub/katello-ca-consumer-latest.noarch.rpm
      # subscription-manager register --org "ACME_Corporation" --env [environment]/[content_view_name]
      

      Note

      The Satellite Capsule Server must be assigned to an organization, because it requires an environment to synchronize content from the Satellite Server. Only organizations have environments.
      Assigning a location is optional, but recommended, to indicate proximity to the hosts that the Satellite Capsule Server is managing.
    2. Depending on the desired Satellite Capsule Server type, choose one of the following options:
      • Satellite Capsule Server with content functionality

        Run the following command on the Satellite Capsule Server to enable the custom certificate. The significant parameter is --pulp="true", which indicates that content functionality is to be enabled.
        # capsule-installer --pulp="true" \
        --qpid-router="true" \
        --puppet="true" \
        --puppetca="true" \
        --reverse-proxy="true" \
        --certs-tar "~/capsule.example.com-certs.tar"
        
      • Satellite Capsule Server without content functionality

        Run the following command on the Satellite Capsule Server to enable the custom certificate. The significant parameter is --pulp="false", which indicates that content functionality is not to be enabled.
        # capsule-installer --pulp="false" \
        --qpid-router="false" \
        --puppet="true" \
        --puppetca="true" \
        --reverse-proxy="true" \
        --certs-tar "~/capsule.example.com-certs.tar"
        

Procedure 7.3. To Set a Custom Server Certificate After Running capsule-certs-generate:

Using custom server certificates for the Satellite Server means that the same custom server certificates need to be deployed in the Satellite Capsule Servers. Each Satellite Capsule Server requires the following steps:
  1. Run the following command as the root user on the Satellite Server to generate a new certificate based on your custom server certificate:

    Note

    In this example the files are stored in the directory /root/sat_cert. Using an absolute path in the root users' directory provides a fixed location that is available to all users who log in to the server with root permissions. Before running this command, ensure the directory already exists.
    # capsule-certs-generate \
    --capsule-fqdn "capsule.example.com" \
    --certs-tar /root/sat_cert/capsule-certs.tar \
    --server-cert /root/sat_cert/capsule.crt \
    --server-cert-req /root/sat_cert/capsule.crt.req \
    --server-key /root/sat_cert/capsule.key \
    --server-ca-cert /root/sat_cert/cacert.crt \
    --certs-update-server
    
  2. Copy the generated archive file, capsule.example.com-certs.tar, from the Satellite Server to the Satellite Capsule host system.
  3. On the Satellite Capsule Server, re-run the capsule-installer command to refresh the certificates. Depending on the desired Satellite Capsule Server type, choose one of the following options:
    • Satellite Capsule Server with content functionality

      Run the following command on the Satellite Capsule Server to refresh the certificates. The significant parameter is --pulp="true", which indicates that content functionality is to be enabled.
      # capsule-installer --pulp="true" \
      --qpid-router="true" \
      --puppet="true" \
      --puppetca="true" \
      --reverse-proxy="true" \
      --certs-tar "capsule.example.com-certs.tar"
      
    • Satellite Capsule Server without content functionality

      Run the following command on the Satellite Capsule Server to refresh the certificates. The significant parameter is --pulp="false", which indicates that content functionality is not to be enabled.
      # capsule-installer --pulp="false" \
      --qpid-router="false" \
      --puppet="true" \
      --puppetca="true" \
      --reverse-proxy="true" \
      --certs-tar "capsule.example.com-certs.tar"
      

7.5.2. Using Power Management Features on Managed Hosts

When you enable the baseboard management controller (BMC) module on the Capsule Server, you can use power management commands on managed hosts using the intelligent platform management interface (IPMI) or a similar protocol.
The BMC service on the satellite Capsule Server allows you to perform a range of power management tasks. The underlying protocol for this feature is IPMI; also referred to as the BMC function. IPMI uses a special network interface on the managed hardware that is connected to a dedicated processor that runs independently of the host's CPUs. In many instances the BMC functionality is built into chassis-based systems as part of chassis management (a dedicated module in the chassis).
To take advantage of BMC features you need to add a new network interface of type "BMC" to each managed host. IPMI interfaces are nearly always password protected, to prevent unauthorized people on the same network from gaining control of that host. Satellite uses this NIC to pass the appropriate credentials to the host.
Red Hat Satellite supports by extension everything that either ipmitool or freeipmi BMC providers support. You can switch between the two per capsule. Note that different hardware vendors might not implement all IPMI specifications, bugs, and so on.

7.5.2.1. Installing a Capsule Server with BMC Options

This section shows how to enable the BMC module as part of the Capsule Server installation process.
Prerequisites

Have a baseboard management controller (BMC) provider set up for your deployment of Capsule Server.

To add BMC functionality, you will need to append the options to the capsule-installer. You are required to choose either a Capsule Server with content functionality or one without. See Section 7.4.1, “Installing a Capsule Server” for more information.
Append the following lines to the command in each option:
--bmc "enabled"\
--bmc_default_provider "freeipmi"
For example:
  • For Capsule Server Installations with content functionality:
    # capsule-installer --pulp=true
    --foreman-oauth-key    "xmmQCGYdkoCRcbviGfuPdX7ZiCsdExf"\
    --foreman-oauth-secret "w5ZDpyPJ24eSBNo53AFybcnqoDYXgLUA"\
    --pulp-oauth-secret    "doajBEXqNcANy93ZbciFyysWaiwt6BWU"\
    --certs-tar            "~/capsule.example.com-certs.tar"\
    --qpid-router=true\
    --puppet=true\
    --puppetca=true\
    --reverse-proxy=true\
    --bmc "enabled"\
    --bmc_default_provider "freeipmi"
    
  • For Capsule Server Installations without content functionality:
    # capsule-installer --pulp=false
    --foreman-oauth-key    "xmmQCGYdkoCRcbviGfuPdX7ZiCsdExf"\
    --foreman-oauth-secret "w5ZDpyPJ24eSBNo53AFybcnqoDYXgLUA"\
    --certs-tar            "~/capsule.example.com-certs.tar"\
    --qpid-router=false\
    --puppet=true\
    --puppetca=true\
    --reverse-proxy=true
    
For more information and how to configure a BMC interface, see To Add a BMC Interface in the Red Hat Satellite 6.1 User Guide.

7.5.3. Provisioning Options for Capsule Server

There are several options that provide provisioning services such as TFTP, DHCP, DNS and Realm that can be added to either type of Capsule Server. For a full list of options, use the command:
# capsule-installer --help
Here is an example of installing a capsule server with full provisioning services:
# capsule-installer --tftp=true\
--foreman-oauth-key    "xmmQCGYdkoCRcbviGfuPdX7ZiCsdExf"\
--foreman-oauth-secret "w5ZDpyPJ24eSBNo53AFybcnqoDYXgLUA"\
--certs-tar            "~/capsule.example.com-certs.tar"\
--templates=true\
--dhcp=true\
--dhcp-gateway=192.168.122.1\
--dhcp-nameservers=192.168.122.1\
--dhcp-range="192.168.122.100 192.168.122.200"\
--dhcp-interface=eth0\
--dns=true\
--dns-forwarders=8.8.8.8\
--dns-interface=eth0\
--dns-zone=example.com
Ensure the dns-interface argument is set with the correct network interface name for the DNS server to listen on. Also ensure that the dhcp-interface argument is set correctly with the interface name for the DHCP server. After configuration, create a subnet on the Satellite server under InfrastructureSubnets for the Capsule which registers automatically.

Note

While it is possible to define the same DHCP range with the capsule-installer command and in the Satellite GUI, it is a good practice to make these ranges disjoint. In the Satellite GUI, select a range from outside the pool defined with capsule-installer, but still in the range defined on the subnet. For the example above, it is recommended to define the DHCP range from 192.168.122.1 to 192.168.122.99 in the Satellite GUI which gives the following IP address distribution:
  • 192.168.122.1 to 192.168.122.99 (reservation pool) are addresses reserved during bare-metal provisioning by Satellite.
  • 192.168.122.100 to 192.168.122.200 (lease pool) are addresses reserved for dynamic clients in the subnet (discovered hosts and unmanaged hosts).
It is possible to install a Satellite Capsule without installing DNS and DHCP services on the same server. Instead you can configure the Satellite Capsule to use external DNS and DHCP services as described in Section 7.9, “Configuring Satellite 6 with External Services”. Alternatively, you can manually allocate specific IP addresses to host names or MAC addresses, see the DHCP chapter in the Red Hat Enterprise Linux 7 Networking Guide[9].