Chapter 4. Post-Upgrade Tasks

Some of the procedures in this section are optional. You can choose to perform only those procedures that are relevant to your installation.

If you use the PXE-based discovery process, then you must complete the discovery upgrade procedure on Satellite and on any Capsule Server with hosts that you want to be listed in Satellite on the Hosts > Discovered hosts page.

  • The katello-agent is disabled with a new installation of Satellite 6.10, making both the qpidd and qdroutered services unavailable.
  • If Satellite 6.9 is upgraded to Satellite 6.10, the katello-agent, as well as the qpidd and qdroutered services, remain enabled.
  • If you are not using katello-agent and transitioned to remote execution, you can optionally disable the katello-agent as a post-upgrade task for both Satellite 6.10 and Capsule 6.10:
# satellite-installer --foreman-proxy-content-enable-katello-agent false

4.1. Upgrading Discovery

This section describes updating the PXELinux template and the boot image passed to hosts that use PXE booting to register themselves with Satellite Server.

From Satellite 6.10, provisioning templates now have a separate association with a subnet, and do not default to using the TFTP Capsule for that subnet. If you create subnets after the upgrade, you must specifically enable the Satellite or a Capsule to provide a proxy service for discovery templates and then configure all subnets with discovered hosts to use a specific template Capsule.

During the upgrade, for every subnet with a TFTP proxy enabled, the template Capsule is set to be the same as the TFTP Capsule. After the upgrade, check all subnets to verify this was set correctly.

These procedures are not required if you do not use PXE booting of hosts to enable Satellite to discover new hosts.

4.1.1. Upgrading Discovery on Satellite Server

  1. Update the Discovery template in the Satellite web UI:

    1. Navigate to Hosts > Provisioning templates.
    2. On the PXELinux global default line, click Clone.
    3. Enter a new name for the template in the Name field, for example ACME PXE global default.
    4. In the template editor field, change the line ONTIMEOUT local to ONTIMEOUT discovery and click Submit.
    5. Navigate to Administer > Settings.
    6. Locate Global default PXELinux template and click on its Value.
    7. Select the name of the newly created template from the menu and click the tick button.
    8. Navigate to Hosts > Provisioning templates.
    9. Click Build PXE Default, then click OK.
  2. In the Satellite web UI, go to Configure > Discovery Rules and associate selected organizations and locations with discovery rules.

4.1.2. Upgrading Discovery on Capsule Servers

  1. Verify that the Foreman Discovery package is current on Satellite Server.

    # satellite-maintain packages install tfm-rubygem-foreman_discovery
  2. If an update occurred in the previous step, restart the satellite-maintain services.

    # satellite-maintain service restart
  3. Upgrade the Discovery image on the Satellite Capsule that is either connected to the provisioning network with discovered hosts or provides TFTP services for discovered hosts.

    # satellite-maintain packages install foreman-discovery-image
  4. On the same instance, install the package which provides the Proxy service, and then restart foreman-proxy service.

    # satellite-maintain packages install tfm-rubygem-smart_proxy_discovery
    # service foreman-proxy restart
  5. In the Satellite web UI, go to Infrastructure > Capsules and verify that the relevant Capsule lists Discovery in the features column. Select Refresh from the Actions drop-down menu if necessary.
  6. Go to Infrastructure > Subnets and for each subnet on which you want to use discovery:

    1. Click the subnet name.
    2. On the Capsules tab, ensure the Discovery Capsule is set to a Capsule you configured above.

4.1.3. Verifying Subnets have a Template Capsule

Ensure all subnets with discovered hosts have a template Capsule:

  1. In the Satellite web UI, navigate to Infrastructure > Subnets.
  2. Select the subnet you want to check.
  3. On the Capsules tab, ensure a Template Capsule has been set for this subnet.

For more information about configuring subnets with template Capsules, see Configuring the Discovery Service in the Provisioning Guide

4.2. Upgrading virt-who

If virt-who is installed on Satellite Server or a Capsule Server, it will be upgraded when they are upgraded. No further action is required. If virt-who is installed elsewhere, it must be upgraded manually.

Before You Begin

If virt-who is installed on a host registered to Satellite Server or a Capsule Server, first upgrade the host to the latest packages available in the Satellite Tools 6.10 repository. For information about upgrading hosts, see Section 3.5, “Upgrading Satellite Clients”.

Upgrade virt-who Manually

  1. Upgrade virt-who.

    # yum upgrade virt-who
  2. Restart the virt-who service so the new version is activated.

    # systemctl restart virt-who.service

4.3. Removing the Previous Version of the Satellite Tools Repository

After completing the upgrade to Satellite 6.10, the Red Hat Satellite Tools 6.9 repository can be removed from Content Views and then disabled.

Disable Version 6.9 of the Satellite Tools Repository:

  1. In the Satellite web UI, navigate to Content > Red Hat Repositories.
  2. In the Enabled Repositories area, locate Red Hat Satellite Tools 6.9 for RHEL 7 Server RPMs x86_64.
  3. Click the Disable icon to the right.

If the repository is still contained in a Content View then you cannot disable it. Packages from a disabled repository are removed automatically by a scheduled task.

4.4. Reclaiming PostgreSQL Space

The PostgreSQL database can use a large amount of disk space especially in heavily loaded deployments. Use this procedure to reclaim some of this disk space on Satellite.

Procedure

  1. Stop all services, except for the postgresql service:

    # satellite-maintain service stop --exclude postgresql
  2. Switch to the postgres user and reclaim space on the database:

    # su - postgres -c 'vacuumdb --full --dbname=foreman'
  3. Start the other services when the vacuum completes:

    # satellite-maintain service start
  4. Confirm that the files exist in the /var/lib/pgsql/ directory:

    # ls -l /var/lib/pgsql/
    
    # du -sh /var/lib/pgsql/
  5. Delete the data from the /var/lib/pgsql/ directory:

    # rm -rf /var/lib/pgsql/*

4.5. Updating Templates, Parameters, Lookup Keys and Values

During the upgrade process, Satellite attempts to locate macros that are deprecated for Satellite 6.10 and converts old syntax to new syntax for the default Satellite templates, parameters, and lookup keys and values. However, Satellite does not convert old syntax in the custom templates that you have created and in the cloned templates.

The process uses simple text replacement, for example:

@host.params['parameter1'] -> host_param('parameter1')
@host.param_true?('parameter1') -> host_param_true?('parameter1')
@host.param_false?('parameter1') -> host_param_false?('parameter1')
@host.info['parameters'] -> host_enc['parameters']
Warning

If you use cloned templates in Satellite, verify whether the cloned templates have diverged from the latest version of the original templates in Satellite. The syntax for the same template can differ between versions of Satellite. If your cloned templates contain outdated syntax, update the syntax to match the latest version of the template.

To ensure that this text replacement does not break or omit any variables in your files during the upgrade, check all templates, parameters, and lookup keys and values for the old syntax and replace manually.

The following error occurs because of old syntax remaining in files after the upgrade:

 undefined method '#params' for Host::Managed::Jail

Fixing the outdated subscription_manager_registration snippet

Satellite 6.4 onwards uses the redhat_register snippet instead of the subscription_manager_registration snippet.

If you upgrade from Satellite 6.3 and earlier, ensure to replace the subscription_manager_registration snippet in your custom templates as follows:

<%= snippet "subscription_manager_registration" %>
               ↓
<%= snippet 'redhat_register' %>

4.6. Tuning Satellite Server with Predefined Profiles

If your Satellite deployment includes more than 5000 hosts, you can use predefined tuning profiles to improve performance of Satellite.

Note that you cannot use tuning profiles on Capsules.

You can choose one of the profiles depending on the number of hosts your Satellite manages and available hardware resources.

The tuning profiles are available in the /usr/share/foreman-installer/config/foreman.hiera/tuning/sizes directory.

When you run the satellite-installer command with the --tuning option, deployment configuration settings are applied to Satellite in the following order:

  1. The default tuning profile defined in the /usr/share/foreman-installer/config/foreman.hiera/tuning/common.yaml file
  2. The tuning profile that you want to apply to your deployment and is defined in the /usr/share/foreman-installer/config/foreman.hiera/tuning/sizes/ directory
  3. Optional: If you have configured a /etc/foreman-installer/custom-hiera.yaml file, Satellite applies these configuration settings.

Note that the configuration settings that are defined in the /etc/foreman-installer/custom-hiera.yaml file override the configuration settings that are defined in the tuning profiles.

Therefore, before applying a tuning profile, you must compare the configuration settings that are defined in the default tuning profile in /usr/share/foreman-installer/config/foreman.hiera/tuning/common.yaml, the tuning profile that you want to apply and your /etc/foreman-installer/custom-hiera.yaml file, and remove any duplicated configuration from the /etc/foreman-installer/custom-hiera.yaml file.

default

Number of managed hosts: 0-5000

RAM: 20G

Number of CPU cores: 4

medium

Number of managed hosts: 5001-10000

RAM: 32G

Number of CPU cores: 8

large

Number of managed hosts: 10001-20000

RAM: 64G

Number of CPU cores: 16

extra-large

Number of managed hosts: 20001-60000

RAM: 128G

Number of CPU cores: 32

extra-extra-large

Number of managed hosts: 60000+

RAM: 256G

Number of CPU cores: 48+

Procedure

  1. Optional: If you have configured the custom-hiera.yaml file on Satellite Server, back up the /etc/foreman-installer/custom-hiera.yaml file to custom-hiera.original. You can use the backup file to restore the /etc/foreman-installer/custom-hiera.yaml file to its original state if it becomes corrupted:

    # cp /etc/foreman-installer/custom-hiera.yaml \
    /etc/foreman-installer/custom-hiera.original
  2. Optional: If you have configured the custom-hiera.yaml file on Satellite Server, review the definitions of the default tuning profile in /usr/share/foreman-installer/config/foreman.hiera/tuning/common.yaml and the tuning profile that you want to apply in /usr/share/foreman-installer/config/foreman.hiera/tuning/sizes/. Compare the configuration entries against the entries in your /etc/foreman-installer/custom-hiera.yaml file and remove any duplicated configuration settings in your /etc/foreman-installer/custom-hiera.yaml file.
  3. Enter the satellite-installer command with the --tuning option for the profile that you want to apply. For example, to apply the medium tuning profile settings, enter the following command:

    # satellite-installer --tuning medium

4.7. Validating Puppet Environments on the External Capsule Server

After upgrading the Capsule Server to 6.10, ensure the puppet environments are available on the Capsule Server.

Procedure

  1. To view the Puppet environments, open the /etc/puppetlabs/code/environments file.

    # vim /etc/puppetlabs/code/environments
  2. If any of the puppet environments are missing, copy them back from the Satellite Server or the backup taken prior to upgrade.
  3. Ensure to have the right permissions and ownership of the missing contents inside the /etc/puppetlabs/code/environments/ file after they have been restored back.
  4. Save and close the file.