Red Hat SummitEste contenido no está disponible en el idioma seleccionado.
Chapter 6. Known issues
The following known issues have been identified in Red Hat Satellite 6.19. Review them to anticipate potential problems and identify workarounds for your environment.
6.1. Web UI
- All Hosts page always links to the new host details UI
The links on the Hosts > All Hosts page always point to the new host details UI, even if the setting New host details UI is set to No.
To work around this problem, display the old host details UI by clicking the options menu in the upper right and selecting Legacy UI.
6.2. Installation and upgrade
- "Permission Denied" errors on Lightspeed pages in secured systems
Incorrect file permissions on the
/var/lib/foreman/public/assets/appsdirectory in combination with a non-default umask cause Lightspeed pages to fail with 403 "Permission Denied" errors. This occurs, for example, in systems secured in accordance with CIS and STIG profiles, which use non-default umasks.To work around this problem, manually change the file permissions. For more information, see the Red Hat Knowledgebase solution Several 'Permission Denied' errors on the iop-core-engine container and other files/services after installing or upgrading to Satellite 6.18 with IOP enabled when non-default umask is applied.
6.3. Red Hat Lightspeed
- Red Hat Lightspeed vulnerability CVE map download fails with proxy
Satellite servers configured for the Red Hat Lightspeed vulnerability service in Satellite fail to download CVE mapping files if the Satellite server uses an HTTP proxy to reach https://security.access.redhat.com. This issue is caused by the
iop-cvemap-download.serviceservice lacking HTTP proxy configuration.To work around this problem, manually set the
HTTPS_PROXYandNO_PROXYenvironment variables for theiop-cvemap-downloadservice. For more information, see Installing Red Hat Lightspeed in Satellite on a connected Satellite Server.
- Red Hat Lightspeed might fail on Satellite servers with managed DNS
When the
namedservice is already running on a Satellite server, theaardvark-dnsservice, which is required for running containers, fails to start. This is caused by a conflict betweennamedandpodmanconfigurations for IPv4 connections. As a consequence, Red Hat Lightspeed installations might fail on Satellite servers configured for managed DNS. To work around this problem, perform the following steps:Set managed DNS in
satellite-installertounmanaged:# satellite-installer --foreman-proxy-dns-managed=falseConfigure your Satellite server to only listen on the local IP addresses by adding the following content to the
/etc/named/options.conffile:listen-on-v6 { fd00:4::25; }; listen-on { 192.168.4.25; };-
Restart the
namedservice. You can verify that the configuration works by checking that the DNS service is listening on port
53:[root@satellite6:/root]# netstat -tulpn| grep 53 tcp 0 0 10.130.0.1:53 0.0.0.0:* LISTEN 2199/aardvark-dns tcp 0 0 192.168.122.1:53 0.0.0.0:* LISTEN 2252/dnsmasq tcp 0 0 192.168.4.25:53 0.0.0.0:* LISTEN 1016/named tcp 0 0 127.0.0.1:953 0.0.0.0:* LISTEN 1016/named tcp6 0 0 fd00:4::25:53 :::* LISTEN 1016/named
- Cannot easily select all CVEs in Red Hat Lightspeed vulnerability
On the Red Hat Lightspeed vulnerability page, you cannot easily select all CVEs.
To work around this problem, manually click the drop-down list near the Select button and choose Select page (100 items) for each page individually.
6.4. Security and authentication
- FIPS-enabled hosts running RHEL 9.3 or earlier cannot upload OpenSCAP reports
On hosts that run RHEL 9.3 or earlier versions with FIPS mode enabled, uploading an OpenSCAP report fails with the following error:
Unable to load certs Neither PUB key nor PRIV keyFor more details, see a related Knowledgebase solution. Note that the problem is fixed for hosts that run RHEL 9.4 or later versions.
No known workaround exists.
6.5. Content management
- Unable to synchronize custom repositories by using only the upstream username without password
Attempts to synchronize a custom repository by using only the upstream username fail with errors about unauthorized access.
Satellite web UI displays the following error message:
An error occurred saving the repository: Validation failed: Upstream username requires upstream password to be set.Hammer CLI displays the following error message:
401, message='Unauthorized', url=<upstream_url>No known workaround is available.
- Unable to upload more than 127 packages at once from the Satellite web UI
When uploading packages to a repository from the Satellite web UI, you can upload up to only 127 RPMs or other files. This known issue occurs due to a limitation with the Rack gem.
To work around this problem, use the API bulk uploader for operations that involve a large number of files.
- Legacy empty CCVs that were previously published and promoted cannot be deleted
In some situations, composite content views (CCVs) that do not contain any content views cannot be deleted. This issue affects CCVs that were created before Satellite 6.18 and were previously published and promoted.
For example, when attempting to remove the CCV with the
hammer content-view removecommand, the command displays the following error:Could not remove objects from content view: PG::NotNullViolation: ERROR: null value in column "katello_content_view_version_id" of relation "katello_content_view_histories" violates not-null constraintTo work around this problem, publish a new version of the empty CCV and then delete it.
- Flatpak content becomes inaccessible after upgrading to Satellite 6.19
Upgrading to Satellite 6.19 prevents hosts from consuming Flatpak content managed by your Satellite Server. The Flatpak registry static index endpoint located at
https://<satellite.example.com>/pulpcore_registry/index/staticreturns a server error.This issue exists because the Pulp Core version included in Satellite 6.19 implements response caching that requires JSON-serializable responses, while the pulp-container FlatpakIndex view returns a Python set in its response data.
No known workaround is available.
6.6. Host provisioning and management
- PXE/TFTP provisioning of RHEL 7 hosts on UEFI (EFI-based) firmware fails due to incompatible bootloaders
During provisioning, Satellite copies the bootloader from the
/bootdirectory of the underlying OS to the/tftpbootdirectory. Because RHEL 9.7 and later versions provide a bootloader that is incompatible with RHEL 7 and earlier versions, the provisioning of RHEL 7 with PXE/TFTP on UEFI (EFI-based) firmware fails.To work around this problem, manually provide the RHEL 7 systems with an older bootloader. For more information, see the Red Hat Knowledgebase solution Provisioning a RHEL 7 client system stuck at "Booting Kickstart default PXEGrub2" on Red Hat Satellite Capsule 6.18.
- Logs incorrectly show missing resources in Red Hat OpenShift Virtualization host creation
In deployments with the Red Hat OpenShift Virtualization compute resource, which is a Technology Preview feature, the production log shows
<Kubeclient::ResourceNotFoundError> virtualmachineinstances.kubevirt.io "host.example.com" not founderrors even though no resources are missing from the provisioning. This is caused by attempts to access a missing VirtualMachineInstance (VMI) that report a warning due tofog-kubevirtexception handling.To work around this problem, ignore these warnings. No action is needed.
- Concurrent host registration fails with a database error
When you register multiple hosts of the same operating system version, the hosts initially fail to register. The redundant creation of an operating system entry in the Red Hat Subscription Management (RHSM) fact parser triggers a unique constraint violation.
To work around this problem, rerun the registration. Note that this leads to an increase in registration time due to the need for retries.
6.7. Backup and restore
- Restoring from backup fails due to inconsistencies in the data
If the backup is generated from a database with inconsistencies, the restore fails. The
satellite-maintaintool uses the PostgreSQLamcheckextension to detect inconsistencies in the data before backup to prevent issues during restore.To work around this problem, contact Red Hat customer support to fix any detected inconsistencies before proceeding with the backup. For more information, see Restoring Red Hat Satellite 6.16+ fails complaining about db duplicates on CREATE UNIQUE INDEX in the Red Hat Knowledgebase.
6.8. IPv6
virt-whois not supported on IPv6-only networksSatellite does not support the
virt-whoagent in an IPv6-only network.No known workaround exists.
- Additional configuration is required in IPv6-only networks when using
kinitfor IdM and AD users If your Satellite Server runs in an IPv6-only network and also runs on RHEL 9.6 and earlier versions, Kerberos authentication for external users from Identity Management (IdM) and Active Directory (AD) fails. This known issue is caused by a bug in the System Security Services Daemon (SSSD) and occurs when the DNS name of the IdM or AD server can be translated to both an IPv4 and IPv6 address but the IPv4 address is not accessible, for example because it is blocked by a firewall.
To work around this problem, configure the
lookup_family_orderoption in the[domain/<domain_name>]in the/etc/sssd/sssd.conffile:[domain/example.com] lookup_family_order = ipv6_only
- Mismatch of the IPv6 address entry when using a DHCPv6 server
When you use a DHCPv6 server to assign an IP address dynamically and you provision a host in an IPv6 network, Satellite contains an IPv6 address that does not match the actual IPv6 address of the host. This mismatch impairs host management capabilities, such as remote execution.
To work around this problem, perform one of the following steps:
-
Execute
subscription-manager facts --uploadon the host. -
Wait for the next facts upload to resolve the issue. Note that the Ignore interfaces facts for provisioning (
ignore_puppet_facts_for_provisioning) setting can disable updating the interfaces from facts.
-
Execute
- Host discovery fails in an IPv6 network
When you attempt to discover an unknown host in an IPv6 network, the discovery fails with
Error: 1001: Failed to open TCP connection to satellite.example.com:443.No known workaround exists.
- Failure to provision hosts in PXE-less Discovery over IPv6
After PXE-less host discovery on an IPv6 Satellite, when the host starts provisioning, fails to resolve the DNS entry for Satellite. As a result, the host fails to fetch Kickstart and the required files.
No known workaround exists.
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}