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 theqpidd
andqdroutered
services unavailable. -
If Satellite 6.9 is upgraded to Satellite 6.10, the
katello-agent
, as well as theqpidd
andqdroutered
services, remain enabled. -
If you are not using
katello-agent
and transitioned to remote execution, you can optionally disable thekatello-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
Update the Discovery template in the Satellite web UI:
- Navigate to Hosts > Provisioning templates.
-
On the
PXELinux global default
line, click Clone. -
Enter a new name for the template in the Name field, for example
ACME PXE global default
. -
In the template editor field, change the line
ONTIMEOUT local
toONTIMEOUT discovery
and click Submit. - Navigate to Administer > Settings.
-
Locate
Global default PXELinux template
and click on its Value. - Select the name of the newly created template from the menu and click the tick button.
- Navigate to Hosts > Provisioning templates.
- Click Build PXE Default, then click OK.
- 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
Verify that the Foreman Discovery package is current on Satellite Server.
# satellite-maintain packages install tfm-rubygem-foreman_discovery
If an update occurred in the previous step, restart the
satellite-maintain
services.# satellite-maintain service restart
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
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
- 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.
Go to Infrastructure > Subnets and for each subnet on which you want to use discovery:
- Click the subnet name.
- 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:
- In the Satellite web UI, navigate to Infrastructure > Subnets.
- Select the subnet you want to check.
- 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
Upgrade virt-who.
# yum upgrade virt-who
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:
- In the Satellite web UI, navigate to Content > Red Hat Repositories.
- In the Enabled Repositories area, locate Red Hat Satellite Tools 6.9 for RHEL 7 Server RPMs x86_64.
- 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
Stop all services, except for the
postgresql
service:# satellite-maintain service stop --exclude postgresql
Switch to the
postgres
user and reclaim space on the database:# su - postgres -c 'vacuumdb --full --dbname=foreman'
Start the other services when the vacuum completes:
# satellite-maintain service start
Confirm that the files exist in the
/var/lib/pgsql/
directory:# ls -l /var/lib/pgsql/ # du -sh /var/lib/pgsql/
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']
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:
-
The default tuning profile defined in the
/usr/share/foreman-installer/config/foreman.hiera/tuning/common.yaml
file -
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 -
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
Optional: If you have configured the
custom-hiera.yaml
file on Satellite Server, back up the/etc/foreman-installer/custom-hiera.yaml
file tocustom-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
-
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. 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
To view the Puppet environments, open the
/etc/puppetlabs/code/environments
file.# vim /etc/puppetlabs/code/environments
- If any of the puppet environments are missing, copy them back from the Satellite Server or the backup taken prior to upgrade.
-
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. - Save and close the file.