mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 1. Planning an upgrade An in-place upgrade is the recommended way to upgrade your system to a later major version of RHEL. Important Before you start, Red Hat recommends that you read this reference, including the linked documents, to prevent a situation when certain changes to your system have been done but you are unable to proceed with the upgrading process. Especially, ensure that your system meets the requirements described in this document and that you are aware of the known limitations. 1.1. Requirements The following are the general criteria a system must meet to upgrade from RHEL 6 to RHEL 8: The architecture is Intel 64 or 64-bit IBM Z. The RHEL Server variant is installed. The FIPS mode is disabled. The system contains no LUKS-encrypted partitions or volumes. Minimum hardware requirements for RHEL 8 are met. Access to repositories with RHEL 6, RHEL 7 and RHEL 8 content is provided. Note that there can be further requirements and limitations. For details, see: The Planning an upgrade section in the Upgrading from RHEL 6 to RHEL 7 documentation The Planning an upgrade section in the Upgrading from RHEL 7 to RHEL 8 documentation 1.2. Considerations You should consider the following before upgrading: Significant changes between the RHEL major releases For details, see: The Major changes and migration considerations chapter in the RHEL 7 Migration Planning Guide The Considerations in adopting RHEL 8 document Applications not distributed by Red Hat If you run applications on a system you want to upgrade that are not provided by Red Hat, consider the following: For RPM-based applications: You require packages that are compatible with the particular target version. The packages, including all dependencies, are available in a repository to which you have access. For non-RPM-based applications: Dependencies and libraries might have changed during these two major version upgrades. Make sure that the dependencies and libraries are available on the particular target version. If the applications are written in an interpreted language, such as Python or Ruby, review whether all libraries are available on the target version. 1.3. Overview of the upgrading process An in-place upgrade from RHEL 6 to RHEL 8 requires the following major steps: Prepare the RHEL 6 system for the upgrade and update the RHEL 6 system to the latest version of RHEL 6.10. Perform a pre-upgrade assessment of the RHEL 6 system and resolve reported problems. Perform an in-place upgrade to RHEL 7.9. Prepare the RHEL 7 system for the upgrade to RHEL 8 and update the RHEL 7 system to the latest version of RHEL 7.9. Perform a pre-upgrade assessment of the RHEL 7 system and resolve problems identified in this phase. Perform an in-place upgrade to RHEL 8. Verify the state of the upgraded system. For detailed instructions, see the following chapters.

Commands:
Chapter 9. Installing the Satellite inventory upload plugin When you are using Red Hat Satellite as a data collection tool for the subscriptions service, you must use the Satellite inventory upload plugin in combination with the virt-who tool for accurate reporting of hypervisor host-guest mapping information for Red Hat Enterprise Linux virtual data center (VDC) subscriptions and similar virtualized environments. The use of this plugin enables the uploading of host-based data from Satellite into the inventory service and enables the association of hosts with guests and with the Satellite instance that manages them. If the plugin is not enabled, the subscriptions service cannot accurately report usage for RHEL virtualized subscriptions. Note The plugin is also required by other Hybrid Cloud Console applications. In addition to the requirement for the inventory service of Red Hat Insights to enable the uploading of host inventory information, the plugin is also required for the remediations service of Red Hat Insights to enable remediation actions from both Satellite and Red Hat Insights. After the Satellite inventory upload plugin is enabled, it is active for every Satellite organization, including existing and newly created organizations. Prerequisites Red Hat Satellite 6.9 or later (versions that are under full support) Procedure For a new installation of Satellite For a new installation of Satellite, the Satellite inventory upload plugin is installed and enabled by default. No action is required to enable it. For upgraded Satellite For Satellite that is upgraded to a currently supported version, the Satellite inventory upload plugin is installed. However, you might have to enable the plugin. If the plugin was previously enabled for Satellite before the upgrade, it remains enabled. No action is required to enable it. If the plugin was not enabled for Satellite before the upgrade, then you must enable it. To enable the Satellite inventory upload plugin, use these steps: In the Satellite web interface, expand the Configure options and select Red Hat Inventory . Follow the instructions on the Red Hat Inventory page to enable the Automatic inventory upload option for Satellite. Usage tips When the Automatic inventory upload option is enabled, the Satellite inventory upload plugin automatically reports once per day by default. You can also manually send data and view the status of the extract and upload actions for individual Satellite organizations. The Satellite inventory upload plugin includes reporting settings that you can use to address data privacy concerns. Use the options on the Red Hat Inventory page to configure the plugin to exclude certain packages, obfuscate host names, and obfuscate host addresses.

Commands:
B.27.2. RHSA-2011:0413 - Important: glibc security update Updated glibc packages that fix three security issues are now available for Red Hat Enterprise Linux 6. The Red Hat Security Response Team has rated this update as having important security impact. Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) associated with each description below. The glibc packages contain the standard C libraries used by multiple programs on the system. These packages contain the standard C and the standard math libraries. Without these two libraries, a Linux system cannot function properly. CVE-2011-0536 The fix for CVE-2010-3847 introduced a regression in the way the dynamic loader expanded the USDORIGIN dynamic string token specified in the RPATH and RUNPATH entries in the ELF library header. A local attacker could use this flaw to escalate their privileges via a setuid or setgid program using such a library. CVE-2011-1071 It was discovered that the glibc fnmatch() function did not properly restrict the use of alloca(). If the function was called on sufficiently large inputs, it could cause an application using fnmatch() to crash or, possibly, execute arbitrary code with the privileges of the application. CVE-2011-1095 It was discovered that the locale command did not produce properly escaped output as required by the POSIX specification. If an attacker were able to set the locale environment variables in the environment of a script that performed shell evaluation on the output of the locale command, and that script were run with different privileges than the attacker's, it could execute arbitrary code with the privileges of the script. All users should upgrade to these updated packages, which contain backported patches to correct these issues.

Commands:
Chapter 11. Additional information 11.1. MTV performance addendum The data provided here was collected from testing in Red Hat Labs and is provided for reference only. Overall, these numbers should be considered to show the best-case scenarios. The observed performance of migration can differ from these results and depends on several factors. 11.1.1. ESXi performance Single ESXi performance Test migration using the same ESXi host. In each iteration, the total VMs are increased, to display the impact of concurrent migration on the duration. The results show that migration time is linear when increasing the total VMs (50 GiB disk, Utilization 70%). The optimal number of VMs per ESXi is 10. Table 11.1. Single ESXi tests Test Case Description MTV VDDK max_vm inflight Migration Type Total Duration cold migration, 10 VMs, Single ESXi, Private Network [a] 2.6 7.0.3 100 cold 0:21:39 cold migration, 20 VMs, Single ESXi, Private Network 2.6 7.0.3 100 cold 0:41:16 cold migration, 30 VMs, Single ESXi, Private Network 2.6 7.0.3 100 cold 1:00:59 cold migration, 40 VMs, Single ESXi, Private Network 2.6 7.0.3 100 cold 1:23:02 cold migration, 50 VMs, Single ESXi, Private Network 2.6 7.0.3 100 cold 1:46:24 cold migration, 80 VMs, Single ESXi, Private Network 2.6 7.0.3 100 cold 2:42:49 cold migration, 100 VMs, Single ESXi, Private Network 2.6 7.0.3 100 cold 3:25:15 [a] Private Network refers to a non -Management network Multi ESXi hosts and single data store In each iteration, the number of ESXi hosts were increased, to show that increasing the number of ESXi hosts improves the migration time (50 GiB disk, Utilization 70%). Table 11.2. Multi ESXi hosts and single data store Test Case Description MTV VDDK Max_vm inflight Migration Type Total Duration cold migration, 100 VMs, Single ESXi, Private Network [a] 2.6 7.0.3 100 cold 3:25:15 cold migration, 100 VMs, 4 ESXs (25 VMs per ESX), Private Network 2.6 7.0.3 100 cold 1:22:27 cold migration, 100 VMs, 5 ESXs (20 VMs per ESX), Private Network, 1 DataStore 2.6 7.0.3 100 cold 1:04:57 [a] Private Network refers to a non-Management network 11.1.2. Different migration network performance Each iteration the Migration Network was changed, using the Provider , to find the fastest network for migration. The results show that there is no degradation using management compared to non-managment networks when all interfaces and network speeds are the same. Table 11.3. Different migration network tests Test Case Description MTV VDDK max_vm inflight Migration Type Total Duration cold migration, 10 VMs, Single ESXi, MGMT Network 2.6 7.0.3 100 cold 0:21:30 cold migration, 10 VMs, Single ESXi, Private Network [a] 2.6 7.0.3 20 cold 0:21:20 cold migration, 10 VMs, Single ESXi, Default Network 2.6.2 7.0.3 20 cold 0:21:30 [a] Private Network refers to a non-Management network

Commands:
4.6. Growing a File System The gfs2_grow command is used to expand a GFS2 file system after the device where the file system resides has been expanded. Running a gfs2_grow command on an existing GFS2 file system fills all spare space between the current end of the file system and the end of the device with a newly initialized GFS2 file system extension. When the fill operation is completed, the resource index for the file system is updated. All nodes in the cluster can then use the extra storage space that has been added. Warning A regression was found in kernel-2.6.32-754.el6 that can cause the gfs2_grow command to fail and potentially cause GFS2 metadata corruption. Before running the gfs2_grow command, ensure that you update to kernel-2.6.32-754.6.3.el6 . The gfs2_grow command must be run on a mounted file system, but only needs to be run on one node in a cluster. All the other nodes sense that the expansion has occurred and automatically start using the new space. Note Once you have created a GFS2 file system with the mkfs.gfs2 command, you cannot decrease the size of the file system. Usage MountPoint Specifies the GFS2 file system to which the actions apply. Comments Before running the gfs2_grow command: Back up important data on the file system. Determine the volume that is used by the file system to be expanded by running a df MountPoint command. Expand the underlying cluster volume with LVM. For information on administering LVM volumes, see Logical Volume Manager Administration . After running the gfs2_grow command, run a df command to check that the new space is now available in the file system. Examples In this example, the file system on the /mygfs2fs directory is expanded. Complete Usage MountPoint Specifies the directory where the GFS2 file system is mounted. Device Specifies the device node of the file system. Table 4.3, "GFS2-specific Options Available While Expanding A File System" describes the GFS2-specific options that can be used while expanding a GFS2 file system. Table 4.3. GFS2-specific Options Available While Expanding A File System Option Description -h Help. Displays a short usage message. -q Quiet. Turns down the verbosity level. -r MegaBytes Specifies the size of the new resource group. The default size is 256MB. -T Test. Do all calculations, but do not write any data to the disk and do not expand the file system. -V Displays command version information.

Commands:
gfs2_grow MountPoint
gfs2_grow /mygfs2fs FS: Mount Point: /mygfs2fs FS: Device: /dev/mapper/gfs2testvg-gfs2testlv FS: Size: 524288 (0x80000) FS: RG size: 65533 (0xfffd) DEV: Size: 655360 (0xa0000) The file system grew by 512MB. gfs2_grow complete.
gfs2_grow [ Options ] { MountPoint | Device } [ MountPoint | Device ]
8.3. Snapshot Creation In Red Hat Virtualization the initial snapshot for a virtual machine is different from subsequent snapshots in that the initial snapshot retains its format, either QCOW2 or raw. The first snapshot for a virtual machine uses existing volumes as a base image. Additional snapshots are additional COW layers tracking the changes made to the data stored in the image since the snapshot. As depicted in Initial Snapshot Creation , the creation of a snapshot causes the volumes that comprise a virtual disk to serve as the base image for all subsequent snapshots. Figure 8.1. Initial Snapshot Creation Snapshots taken after the initial snapshot result in the creation of new COW volumes in which data that is created or changed after the snapshot is taken will be stored. Each newly created COW layer contains only COW metadata. Data that is created by using and operating the virtual machine after a snapshot is taken is written to this new COW layer. When a virtual machine is used to modify data that exists in a COW layer, the data is read from the layer, and written into the newest layer. Virtual machines locate data by checking each COW layer from most recent to oldest, transparently to the virtual machine. Figure 8.2. Additional Snapshot Creation

Commands:
Chapter 4. Red Hat build of OpenJDK features The latest Red Hat build of OpenJDK 11 release might include new features. Additionally, the latest release might enhance, deprecate, or remove features that originated from Red Hat build of OpenJDK 11 releases. Note For all the other changes and security fixes, see OpenJDK 11.0.24 Released . Red Hat build of OpenJDK new features and enhancements Review the following release notes to understand new features and feature enhancements that Red Hat build of OpenJDK 11.0.24 provides: DTLS 1.0 is disabled by default OpenJDK 9 introduced support for both version 1.0 and version 1.2 of the Datagram Transport Layer Security (DTLS) protocol ( JEP-219 ). DTLSv1.0, which is based on TLS 1.1, is no longer recommended for use, because this protocol is considered weak and insecure by modern standards. In Red Hat build of OpenJDK 11.0.24, if you attempt to use DTLSv1.0, the JDK throws an SSLHandshakeException by default. If you want to continue using DTLSv1.0, you can remove DTLSv1.0 from the jdk.tls.disabledAlgorithms system property either by modifying the java.security configuration file or by using the java.security.properties system property. Note Continued use of DTLSv1.0 is not recommended and is at the user's own risk. See JDK-8256660 (JDK Bug System) . RPATH preferred over RUNPATH for USDORIGIN runtime search paths in internal JDK binaries Native executables and libraries in the JDK use embedded runtime search paths (rpaths) to locate required internal JDK native libraries. On Linux systems, binaries can specify these search paths by using either DT_RPATH or DT_RUNPATH . If a binary specifies search paths by using DT_RPATH , these paths are searched before any paths that are specified in the LD_LIBRARY_PATH environment variable. If a binary specifies search paths by using DT_RUNPATH , these paths are searched only after paths that are specified in LD_LIBRARY_PATH . This means that the use of DT_RUNPATH can allow JDK internal libraries to be overridden by any libraries of the same name that are specified in LD_LIBRARY_PATH , which is undesirable from a security perspective. In earlier releases, the type of runtime search path used was based on the default search path for the dynamic linker. In Red Hat build of OpenJDK 11.0.24, to ensure that DT_RPATH is used, the --disable-new-dtags option is explicitly passed to the linker. See JDK-8326891 (JDK Bug System) . GlobalSign R46 and E46 root certificates added In Red Hat build of OpenJDK 11.0.24, the cacerts truststore includes two GlobalSign TLS root certificates: Certificate 1 Name: GlobalSign Alias name: globalsignr46 Distinguished name: CN=GlobalSign Root R46, O=GlobalSign nv-sa, C=BE Certificate 2 Name: GlobalSign Alias name: globalsigne46 Distinguished name: CN=GlobalSign Root E46, O=GlobalSign nv-sa, C=BE See JDK-8316138 (JDK Bug System) .

Commands:
4.13. RHEA-2012:0798 - new packages: libreoffice New libreoffice packages are now available for Red Hat Enterprise Linux 6. LibreOffice is an Open Source, community-developed, office productivity suite. It includes the key desktop applications, such as a word processor, spreadsheet, presentation manager, formula editor and drawing program. LibreOffice replaces OpenOffice.org and provides a similar but enhanced and extended Office Suite. This enhancement update adds the libreoffice packages to Red Hat Enterprise Linux 6. (BZ# 747431 ) All users who require libreoffice are advised to install these new packages.

Commands:
Chapter 16. Configuring SSH to use RSA SSH is used to clone Git repositories. By default, the DSA encryption algorithm is provided by Business Central. However, some SSH clients, for example SSH clients in the Fedora 23 environment, use the RSA algorithm instead of the DSA algorithm. Business Central contains a system property that you can use to switch from DSA to RSA if required. Note SSH clients on supported configurations, for example Red Hat Enterprise Linux 7, are not affected by this issue. For a list of supported configurations, see Red Hat Decision Manager 7 Supported Configurations . Procedure Complete one of the following tasks to enable this system property: Modify the ~/.ssh/config file on the client side as follows to force the SSH client to accept the deprecated DSA algorithm: Include the -Dorg.uberfire.nio.git.ssh.algorithm=RSA parameter when you start Business Central, for example:

Commands:
Host <SERVER_IP> HostKeyAlgorithms +ssh-dss
./standalone.sh -c standalone-full.xml -Dorg.uberfire.nio.git.ssh.algorithm=RSA
1.2. Configuration Basics To set up a cluster, you must connect the nodes to certain cluster hardware and configure the nodes into the cluster environment. Configuring and managing the Red Hat High Availability Add-On consists of the following basic steps: Setting up hardware. Refer to Section 1.3, "Setting Up Hardware" . Installing Red Hat High Availability Add-On software. Refer to Section 1.4, "Installing Red Hat High Availability Add-On software" . Configuring Red Hat High Availability Add-On Software. Refer to Section 1.5, "Configuring Red Hat High Availability Add-On Software" .

Commands:
Chapter 1. Quay.io overview Quay.io is a registry for storing and building container images, but can also be used to distribute both container images and other artifacts. It offers both free and paid tiers to cater to various user needs, and is primarily hosted in the United States ( us-east-1 region of Amazon Web Services) with CDN edge servers scattered throughout the world. Quay.io is flexible, easy to use, and allows users to upload and manage container images. Developers can create private repositories, ensuring sensitive or proprietary code remains secure within their organization. Additionally, users can set up access controls and manage team collaboration, enabling seamless sharing of container images among designated team members. Quay.io addresses container security concerns through its integrated image scanner, Clair . The service automatically scans container images for known vulnerabilities and security issues, providing developers with valuable insights into potential risks and suggesting remediation steps. Quay.io excels in automation and supports integration with popular Continuous Integration/Continuous Deployment (CI/CD) tools and platforms, enabling seamless automation of the container build and deployment processes. As a result, developers can streamline their workflows, significantly reducing manual intervention and improving overall development efficiency. Quay.io caters to the needs of both large and small-scale deployments. The platform can handle significant container image traffic and offers efficient replication and distribution mechanisms to deliver container images to various geographical locations. With Quay.io, developers can discover a collection of pre-built, public container images shared by other users, making it easier to find useful tools, applications, and services for their projects.

Commands:
10.6. Renaming Machines and Reconfiguring IdM Client Configuration The hostname of a system is critical for the correct operation of Kerberos and SSL. Both of these security mechanisms rely on the hostname to ensure that communication is occurring between the specified hosts. Infrastructures which use virtual machines or clustered servers will commonly have hosts which are renamed because systems are copied, moved, or renamed. Red Hat Enterprise Linux does not provide a simple rename command to facilitate the renaming of an IdM host. Renaming a host in an IdM domain involves deleting the entry in IdM, uninstalling the client software, changing the hostname, and re-enrolling using the new name. Additionally, part of renaming hosts requires regenerating service principals. To reconfigure the client: Identify which services are running on the machine. These need to be re-created when the machine is re-enrolled. Each host has a default service which does not appear in the list of services. This service can be referred to as the "host service". The service principal for the host service is host/<hostname> , such as host/server.example.com . This principal can also be referred to as the host principal . Identify all host groups to which the machine belongs. Identify which of the services have certificates associated with them. This can be done using the ldapsearch command to check the entries in the IdM LDAP database directly: For any service principals (in addition to the host principal), determine the location of the corresponding keytabs on server.example.com . The keytab location is different for each service, and IdM does not store this information. Each service on the client system has a Kerberos principal in the form service_name/hostname@REALM , such as ldap/server.example.com@EXAMPLE.COM . Unenroll the client machine from the IdM domain: For each identified keytab other than /etc/krb5.keytab , remove the old principals: On an IdM server, as an IdM administrator, remove the host entry. This removes all services and revokes all certificates issued for that host: At this point, the host is completely removed from IdM. Rename the machine. Re-enroll the system with IdM: This generates a host principal for with the new hostname in /etc/krb5.keytab . On an IdM server, add a new keytab for every service: To generate certificates for services, use either certmonger or the IdM administration tools. Re-add the host to any applicable host groups.

Commands:
ipa service-find server.example.com
kinit admin ipa hostgroup-find server.example.com
ldapsearch -x -b "cn=accounts,dc=example,dc=com" "(&(objectclass=ipaservice)(userCertificate=*))" krbPrincipalName -D "cn=directory manager" -w secret -h ipaserver.example.com -p 389
ipa-client-install --uninstall
ipa-rmkeytab -k /path/to/keytab -r EXAMPLE.COM
kinit admin ipa host-del server.example.com
ipa-client-install
ipa service-add serviceName/new-hostname