mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 4. Preparing the RHEL 7 system for an upgrade to RHEL 8 To prepare your RHEL 7 system for the upgrade to RHEL 8, follow these steps before proceeding with the upgrade: Migrate the GRUB Legacy boot loader to GRUB After the upgrade, RHEL 7 still uses the GRUB Legacy boot loader. However, GRUB Legacy is not supported on RHEL 7 and later versions. Therefore, you must manually migrate the boot loader to GRUB. For details, see the Upgrading from GRUB Legacy to GRUB section in the RHEL 7 System Administrator's Guide . Resolve potential problems with installed packages. For details, see Section 7.1, "Ensuring that installed packages match the current major RHEL version" . Adjust custom System V and Upstart scripts to systemd services. On a RHEL 7 system, systemd replaces Upstart as the init system. To use the features systemd provides, such as parallel startup of system services at boot time, manually convert legacy System V and Upstart scripts to systemd services. For details, see Converting traditional sysV init scripts to Red Hat Enterprise Linux 7 systemd unit files . Update paths to system directories in your scripts. On a RHEL 7 system, the /bin , /sbin , /lib , and /lib64 directories have been replaced by symbolic links to their corresponding directory in /usr . For example, on RHEL 8, /bin is a symbolic link to the /usr/bin/ directory. If you use scripts or applications that expect /bin , /sbin , /lib , and /lib64 to be real directories, adjust them accordingly. For example, you can update the scripts and applications to: Use the paths in /usr , such as /usr/bin/ Accept that /bin , /sbin , /lib , and /lib64 are symbolic links instead of directories Update your YUM scripts and plug-ins to use the YUM 4 API. RHEL 8 no longer supports the Python API of YUM 3. If you use any scripts or YUM plug-ins that use the legacy API, migrate them to the YUM 4 API. For more information, see Notable changes to the YUM stack . If you miss certain packages after the upgrade, see the Section 7.3, "Installing missing packages after upgrading to RHEL 7" section in the Troubleshooting chapter. Review the Considerations in adopting RHEL 8 document and make additional changes to your system if needed. Update your system to the latest RHEL 7.9 version and reboot the host: Ensure that all your applications and services are configured and work as expected. For example, if you run a DNS server on the host, verify that the configuration is still valid after the upgrade and that the service works in the same way as it did before the upgrade. Follow the preparation steps described in the Preparing for the upgrade chapter in the Upgrading from RHEL 7 to RHEL 8 document.

Commands:
yum update reboot
8.257. webkitgtk 8.257.1. RHBA-2014:1573 - webkitgtk bug fix and enhancement update Updated webkitgtk packages that fix several bugs and add various enhancements are now available for Red Hat Enterprise Linux 6. WebKitGTK+ is the port of the portable web rendering engine WebKit to the GTK+ platform. Note The webkitgtk package has been upgraded to upstream version 1.4.0, which provides a number of bug fixes and enhancements over the version. (BZ# 1033151 , BZ# 1101400 , BZ# 1101401 , BZ# 1101403 , BZ# 1119647 ) Users of webkitgtk are advised to upgrade to these updated packages, which fix these bugs and add these enhancements.

Commands:
Appendix G. Purging the Ceph dashboard using Ansible If you no longer want the dashboard installed, use the purge-dashboard.yml playbook to remove the dashboard. You might also want to purge the dashboard when troubleshooting an issue with the dashboard or its components. Prerequisites Red Hat Ceph Storage 4.3 or later. Ceph-ansible shipped with the latest version of Red Hat Ceph Storage. Sudo-level access to all nodes in the storage cluster. Procedure Log in to the Ansible administration node. Navigate to the /usr/share/ceph-ansible/ directory: Example Run the Ansible purge-dashboard.yml playbook, and when prompted, type yes to confirm purging of the dashboard: Example Verification Run the ceph mgr services command to verify dashboard is no longer running: Syntax The dashboard URL is not displayed. Additional Resources To install the dashboard, see Installing dashboard using Ansbile in the Red Hat Ceph Storage Dashboard Guide .

Commands:
[ansible@admin ~]USD cd /usr/share/ceph-ansible/
[ansible@admin ceph-ansible]USD ansible-playbook infrastructure-playbooks/purge-dashboard.yml -i hosts -vvvv
ceph mgr services
2.2. Consistent Multipath Device Names in a Cluster When the user_friendly_names configuration option is set to yes , the name of the multipath device is unique to a node, but it is not guaranteed to be the same on all nodes using the multipath device. Similarly, if you set the alias option for a device in the multipaths section of the multipath.conf configuration file, the name is not automatically consistent across all nodes in the cluster. This should not cause any difficulties if you use LVM to create logical devices from the multipath device, but if you require that your multipath device names be consistent in every node it is recommended that you not set the user_friendly_names option to yes and that you not configure aliases for the devices. By default, if you do not set user_friendly_names to yes or configure an alias for a device, a device name will be the WWID for the device, which is always the same. If you want the system-defined user-friendly names to be consistent across all nodes in the cluster, however, you can follow this procedure: Set up all of the multipath devices on one machine. Disable all multipath devices on other machines by running the following commands: Copy the /etc/multipath/bindings file from the first machine to all the other machines in the cluster. Re-enable the multipathd daemon on all the other machines in the cluster by running the following command: If you add a new device, you will need to repeat this process. Similarly, if you configure an alias for a device that you would like to be consistent across the nodes in the cluster, you should ensure that the /etc/multipath.conf file is the same for each node in the cluster by following the same procedure: Configure the aliases for the multipath devices in the multipath.conf file on one machine. Disable all multipath devices on other machines by running the following commands: Copy the /etc/multipath.conf file from the first machine to all the other machines in the cluster. Re-enable the multipathd daemon on all the other machines in the cluster by running the following command: When you add a new device you will need to repeat this process.

Commands:
systemctl stop multipathd.service multipath -F
systemctl start multipathd.service
systemctl stop multipathd.service multipath -F
systemctl start multipathd.service
5.3. Configuring Cluster Properties In addition to configuring cluster parameters in the preceding section ( Section 5.2, "Starting the Cluster Configuration Tool " ), you can configure the following cluster properties: Cluster Alias (optional), a Config Version (optional), and Fence Daemon Properties . To configure cluster properties, follow these steps: At the left frame, click Cluster . At the bottom of the right frame (labeled Properties ), click the Edit Cluster Properties button. Clicking that button causes a Cluster Properties dialog box to be displayed. The Cluster Properties dialog box presents text boxes for Cluster Alias , and Config Version , and two Fence Daemon Properties parameters (DLM clusters only): Post-Join Delay and Post-Fail Delay . (Optional) At the Cluster Alias text box, specify a cluster alias for the cluster. The default cluster alias is set to the true cluster name provided when the cluster is set up (refer to Section 5.2, "Starting the Cluster Configuration Tool " ). The cluster alias should be descriptive enough to distinguish it from other clusters and systems on your network (for example, nfs_cluster or httpd_cluster ). The cluster alias cannot exceed 15 characters. (Optional) The Config Version value is set to 1 by default and is automatically incremented each time you save your cluster configuration. However, if you need to set it to another value, you can specify it at the Config Version text box. Specify the Fence Daemon Properties parameters (DLM clusters only): Post-Join Delay and Post-Fail Delay . The Post-Join Delay parameter is the number of seconds the fence daemon ( fenced ) waits before fencing a node after the node joins the fence domain. The Post-Join Delay default value is 3 . A typical setting for Post-Join Delay is between 20 and 30 seconds, but can vary according to cluster and network performance. The Post-Fail Delay parameter is the number of seconds the fence daemon ( fenced ) waits before fencing a node (a member of the fence domain) after the node has failed.The Post-Fail Delay default value is 0 . Its value may be varied to suit cluster and network performance. Note For more information about Post-Join Delay and Post-Fail Delay , refer to the fenced (8) man page. Save cluster configuration changes by selecting File => Save .

Commands:
3.4. Creating a SecureBoot Red Hat Enterprise Linux 7 Guest with virt-manager This procedure covers creating a SecureBoot Red Hat Enterprise Linux 7 guest virtual machine with a locally stored installation DVD or DVD image. Red Hat Enterprise Linux 7 DVD images are available from the Red Hat Customer Portal . The SecureBoot feature ensures that your VM is running a cryptographically signed OS. If the guest OS of a VM has been altered by malware, SecureBoot prevents the VM from booting, which stops the potential spread of the malware to your host machine. Procedure 3.1. Creating a SecureBoot Red Hat Enterprise Linux 7 guest virtual machine with virt-manager using local installation media Perform steps 1 to 6 of Creating a Red Hat Enterprise Linux 7 Guest with virt-manager . Name and final configuration Name the virtual machine. Virtual machine names can contain letters, numbers and the following characters: underscores ( _ ), periods ( . ), and hyphens ( - ). Virtual machine names must be unique for migration and cannot consist only of numbers. By default, the virtual machine will be created with network address translation (NAT) for a network called 'default' . To change the network selection, click Network selection and select a host device and source mode. Figure 3.1. Verifying the configuration To further configure the virtual machine's hardware, check the Customize configuration before install check box to change the guest's storage or network devices, to use the paravirtualized (virtio) drivers or to add additional devices. Verify the settings of the virtual machine and click Finish when you are satisfied. This will open a new wizard for futher configuring your virtual machine. Customize virtual machine hardware In the overview section of the wizard, select Q35 in the Chipset drop-down menu. In the Firmware drop-down menu, select UEFI x86_64. Figure 3.2. The configure hardware window Verify the settings of the virtual machine and click Apply when you are satisfied. Click Begin Installation to create a virtual machine with the specified networking settings, virtualization type, and architecture. A SecureBoot Red Hat Enterprise Linux 7 guest virtual machine is now created from an ISO installation disk image.

Commands:
function::text_strn Name function::text_strn - Escape any non-printable chars in a string Synopsis Arguments input the string to escape len maximum length of string to return (0 implies MAXSTRINGLEN) quoted put double quotes around the string. If input string is truncated it will have " ... " after the second quote Description This function accepts a string of designated length, and any ASCII characters that are not printable are replaced by the corresponding escape sequence in the returned string.

Commands:
text_strn:string(input:string,len:long,quoted:long)
11.3. Storing Certificates in NSS Databases When services use certificates, the certificates and keys can be stored in NSS databases (which may also be used by the services themselves, as well as Identity Management). Create the NSS databases. Request the certificate using certutil , an NSS tool. If the IdM domain is using Certificate System for its CA, only the CN of the subject name is used. With a self-signed CA, the subject must match the configured certificate subject base. The IdM server rejects requests with a subject base that differs from this value.

Commands:
certutil -N -d /path/to/database/dir
certutil -R -s "CN=client1.example.com,O=EXAMPLE.COM" -d /path/to/database/dir -a > example.csr
9.10. Assign Storage Devices If you selected more than one storage device on the storage devices selection screen (refer to Section 9.6, "Storage Devices" ), anaconda asks you to select which of these devices should be available for installation of the operating system, and which should only be attached to the file system for data storage. If you selected only one storage device, anaconda does not present you with this screen. During installation, the devices that you identify here as being for data storage only are mounted as part of the file system, but are not partitioned or formatted. Figure 9.33. Assign storage devices The screen is split into two panes. The left pane contains a list of devices to be used for data storage only. The right pane contains a list of devices that are to be available for installation of the operating system. Each list contains information about the devices to help you to identify them. A small drop-down menu marked with an icon is located to the right of the column headings. This menu allows you to select the types of data presented on each device. Reducing or expanding the amount of information presented might help you to identify particular devices. Move a device from one list to the other by clicking on the device, then clicking either the button labeled with a left-pointing arrow to move it to the list of data storage devices or the button labeled with a right-pointing arrow to move it to the list of devices available for installation of the operating system. The list of devices available as installation targets also includes a radio button beside each device. Use this radio button to specify the device that you want to use as the boot device for the system. Important If any storage device contains a boot loader that will chain load the Red Hat Enterprise Linux boot loader, include that storage device among the Install Target Devices . Storage devices that you identify as Install Target Devices remain visible to anaconda during boot loader configuration. Storage devices that you identify as Install Target Devices on this screen are not automatically erased by the installation process unless you selected the Use All Space option on the partitioning screen (refer to Section 9.13, "Disk Partitioning Setup" ). When you have finished identifying devices to be used for installation, click to continue.

Commands:
Chapter 7. Troubleshoot etcd To troubleshoot etcd and improve performance, configure the memory allowance for the service. 7.1. Configuring the memoryLimitMB value to set parameters for the etcd server By default, etcd uses as much memory as necessary to handle the load on the system. In memory-constrained systems, you might need to limit the amount of memory etcd uses. Procedure Edit the /etc/microshift/config.yaml file to set the memoryLimitMB value. etcd: memoryLimitMB: 128 Note The minimum required value for memoryLimitMB on MicroShift is 128 MB. Values close to the minimum value are more likely to impact etcd performance. The lower the limit, the longer etcd takes to respond to queries. If the limit is too low or the etcd usage is high, queries time out. Verification After modifying the memoryLimitMB value in /etc/microshift/config.yaml , restart MicroShift by running the following command: USD sudo systemctl restart microshift Verify the new memoryLimitMB value is in use by running the following command: USD systemctl show --property=MemoryHigh microshift-etcd.scope

Commands:
etcd: memoryLimitMB: 128
sudo systemctl restart microshift
systemctl show --property=MemoryHigh microshift-etcd.scope
Chapter 46. TieredStorageCustom schema reference Used in: KafkaClusterSpec Full list of TieredStorageCustom schema properties Enables custom tiered storage for Kafka. If you want to use custom tiered storage, you must first add a tiered storage for Kafka plugin to the Streams for Apache Kafka image by building a custom container image. Custom tiered storage configuration enables the use of a custom RemoteStorageManager configuration. RemoteStorageManager is a Kafka interface for managing the interaction between Kafka and remote tiered storage. If custom tiered storage is enabled, Streams for Apache Kafka uses the TopicBasedRemoteLogMetadataManager for Remote Log Metadata Management (RLMM). Warning Tiered storage is an early access Kafka feature, which is also available in Streams for Apache Kafka. Due to its current limitations , it is not recommended for production environments. Example custom tiered storage configuration kafka: tieredStorage: type: custom remoteStorageManager: className: com.example.kafka.tiered.storage.s3.S3RemoteStorageManager classPath: /opt/kafka/plugins/tiered-storage-s3/* config: # A map with String keys and String values. # Key properties are automatically prefixed with `rsm.config.` # and appended to Kafka broker config. storage.bucket.name: my-bucket config: ... # Additional RLMM configuration can be added through the Kafka config # under `spec.kafka.config` using the `rlmm.config.` prefix. rlmm.config.remote.log.metadata.topic.replication.factor: 1 46.1. TieredStorageCustom schema properties The type property is a discriminator that distinguishes use of the TieredStorageCustom type from other subtypes which may be added in the future. It must have the value custom for the type TieredStorageCustom . Property Property type Description type string Must be custom . remoteStorageManager RemoteStorageManager Configuration for the Remote Storage Manager.

Commands:
kafka: tieredStorage: type: custom remoteStorageManager: className: com.example.kafka.tiered.storage.s3.S3RemoteStorageManager classPath: /opt/kafka/plugins/tiered-storage-s3/* config: # A map with String keys and String values. # Key properties are automatically prefixed with `rsm.config.` # and appended to Kafka broker config. storage.bucket.name: my-bucket config: # Additional RLMM configuration can be added through the Kafka config # under `spec.kafka.config` using the `rlmm.config.` prefix. rlmm.config.remote.log.metadata.topic.replication.factor: 1
4.203. opencryptoki 4.203.1. RHBA-2011:1572 - opencryptoki bug fix and enhancement update Updated opencryptoki packages that fix several bugs and add various enhancements are now available for Red Hat Enterprise Linux 6. The openCryptoki package contains version 2.11 of the PKCS#11 API, implemented for IBM Cryptocards. This package includes support for the IBM 4758 Cryptographic CoProcessor (with the PKCS#11 firmware loaded), the IBM eServer Cryptographic Accelerator (FC 4960 on IBM eServer System p), the IBM Crypto Express2 (FC 0863 or FC 0870 on IBM System z), and the IBM CP Assist for Cryptographic Function (FC 3863 on IBM System z). Bug Fixes BZ# 734489 When setting the length of an RSA key for the IBM Cryptographic Accelerator (ICA) token, initialization of the CKA_MODULUS_BITS internal attribute of PKCS#11 was not properly tested and the RSA key length could have been set incorrectly. As a consequence, RSA key verification in the ICA token failed. To ensure that the RSA key is set correctly, two conditions have been added in the respective function in the ICA specific library. The RSA key operations now work properly on the ICA token. BZ# 730903 Prior to this update, the documentation provided with opencryptoki packages stated that users using opencryptoki needed to be members of the "pkcs11" group but did not mention the real privileges granted by adding a user to the group. Consequently, it was not clear that the members of the "pkcs11" group are assumed to be fully trusted. With this update opencryptoki(7) man page now contains a security note. BZ# 732756 Prior to this update, an unnecessary check in the attach_shared_memory() function was made which therefore required explicit group membership regardless of the current effective privileges. Consequently, upon installation of the opencryptoki packages and creation of the "pkcs11" group, the root user was added to the group. However, root user should not need access to the group to be able to access shared memory. With this update the shared memory checks have been corrected and root user no longer requires membership of the "pkcs11" group. Enhancement BZ# 693779 The openCryptoki package has been upgraded to upstream version 2.4, which provides a number of bug fixes and enhancements over the version. Users are advised to upgrade to these updated packages, which fix these bugs and add these enhancements.

Commands:
Part VI. Monitoring Performance Developers profile programs to focus attention on the areas of the program that have the largest impact on performance. The types of data collected include what section of the program consumes the most processor time, and where memory is allocated. Profiling collects data from the actual program execution. Thus, the quality of the data collected is influenced by the actual tasks being performed by the program. The tasks performed during profiling should be representative of actual use; this ensures that problems arising from realistic use of the program are addressed during development. Red Hat Enterprise Linux includes a number of different tools ( Valgrind , OProfile , perf , and SystemTap ) to collect profiling data. Each tool is suitable for performing specific types of profile runs, as described in the following sections.

Commands:
Chapter 4. Compact Node Definition (CND) Editor 4.1. Compact Node Definition (CND) Editor The ModeShape Tools Java Content Repository (JCR) Compact Node Type Definition (CND) Editor is a 2-page editor for *.cnd files. The first page is a form-based view of the CND file and the second page is a read-only source view. Note The CND Editor can be used to edit CND files for any JCR 2.0 implementation and is not limited to ModeShape users. It even can be installed separately from the ModeShape-specific features. The CND Editor's form page consists of the following sections: a header section, which displays error messages and a link to open the CND preference page, a namespaces section, which displays and allows editing of the namespace mappings defined in the CND, and a node types section, which displays and allows editing of the node type definitions defined in the CND.

Commands:
4.86. hwdata 4.86.1. RHEA-2011:1663 - hwdata enhancement update An updated hwdata package that adds various enhancements is now available for Red Hat Enterprise Linux 6. The hwdata package contains tools for accessing and displaying hardware identification and configuration data. Enhancements BZ# 682399 The pci.ids database has been updated with information about HP Laptop WiFi chipsets. BZ# 695798 The pci.ids database has been updated with information about future Intel PCH (Platform Controller Hub) devices. BZ# 712177 The pci.ids database has been updated with correct information about QLogic IBA7322 InfiniBand devices. BZ# 713070 The pci.ids database has been updated with information about future Atheros wireless devices. BZ# 739376 The pci.ids database has been updated with information about future Broadcom wireless devices. BZ# 728909 The pci.ids database has been updated according to the latest upstream changes. Users of hwdata are advised to upgrade to this updated package, which adds these enhancements.

Commands: