mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 35. Deployment and Tools systemd component, BZ# 1178848 The systemd service cannot set cgroup properties on cgroup trees that are mounted as read-only. Consequently, the following error message can ocasionally appear in the logs: You can ignore this problem, as it should not have any significant effect on you system. systemd component, BZ# 978955 When attempting to start, stop, or restart a service or unit using the systemctl [start|stop|restart] NAME command, no message is displayed to inform the user whether the action has been successful. subscription-manager component, BZ# 1166333 The Assamese (as-IN), Punjabi (pa-IN), and Korean (ko-KR) translations of subscription-manager 's user interface are incomplete. As a consequence, users of subscription-manager running in one these locales may see labels in English rather than the configured language. systemtap component, BZ#1184374 Certain functions in the kernel are not probed as expected. To work around this issue, try to probe by a statement or by a related function. systemtap component, BZ#1183038 Certain parameters or functions cannot be accessible within function probes. As a consequence, the USDparameter accesses can be rejected. To work around this issue, activate the systemtap prologue-searching heuristics.

Commands:
Failed to reset devices.list on /machine.slice: Invalid argument
25.3. Setting up the Challenge-Handshake Authentication Protocol After configuring an ACL and creating an iSCSI initiator, set up the Challenge-Handshake Authentication Protocol (CHAP). For more information on configuring an ACL and creating an iSCSI initiator, see Section 25.1.6, "Configuring ACLs" and Section 25.2, "Creating an iSCSI Initiator" . The CHAP allows the user to protect the target with a password. The initiator must be aware of this password to be able to connect to the target. Procedure 25.8. Setting up the CHAP for target Set attribute authentication: Set userid and password: Procedure 25.9. Setting up the CHAP for initiator Edit the iscsid.conf file: Enable the CHAP authentication in the iscsid.conf file: By default, the node.session.auth.authmethod option is set to None . Add target user name and password in the iscsid.conf file: Restart the iscsid service: For more information, see the targetcli and iscsiadm man pages.

Commands:
/iscsi/iqn.20...mple:444/tpg1> set attribute authentication=1 Parameter authentication is now '1'.
/iscsi/iqn.20...mple:444/tpg1> set auth userid= redhat Parameter userid is now 'redhat'. /iscsi/iqn.20...mple:444/tpg1> set auth password= redhat_passwd Parameter password is now 'redhat_passwd'.
vi /etc/iscsi/iscsid.conf node.session.auth.authmethod = CHAP
node.session.auth.username = redhat node.session.auth.password = redhat_passwd
systemctl restart iscsid.service
Chapter 4. Known Issues 4.1. Reboot requirement detection The reboot requirement detection is not reliable on RHEL 8.5 and later on platform ppc64le. A failed reboot requirement detection can lead to unnecessary reboots at the end of a playbook which calls the preconfiguration roles. Role parameters are available for avoiding reboots, and playbooks can be extended to unconditionally reboot a system. See bug 2166444 for more information. 4.2. RHEL 9 packages for SAP HANA On RHEL 9, some packages are not getting installed and some are installed which are not required for SAP HANA. SAP note 3108316 has been published with some updates which were not known at the time this version of the RHEL System Roles for SAP had been finalized. The additional package that has to be installed for SAP HANA is compat-openssl11 . See this comment for instructions on how to quickly define a list of packages to be installed. 4.3. Extended check (Assert) function Be careful when using the extended check (=assert) function of the preconfigure roles. The preconfigure roles can run in an assert mode, in which case they do not modify managed nodes but report the compliance of a node with the applicable SAP notes. When using the same control node also for modifying the system configuration, by running the preconfigure roles in normal mode, extra caution needs to be applied to ensure that a "normal" playbook is not accidentally used for checking the system configuration. It is strongly recommended to only run the roles on production systems after testing them on test and QA systems first. 4.4. DNS name resolution Role sap_general_preconfigure fails if the DNS domain is not set on the managed node. In case there is no DNS domain set on the managed node, which is typically the case on cloud systems, the role sap_general_preconfigure will fail in task Verify that the DNS domain is set . To avoid this, set the role variable sap_domain in the vars section of your playbook, in an inventory file for the managed node or run the ansible-playbook command with parameter -e "sap_domain=example.com" (replace example.com by your own DNS domain name).

Commands:
Chapter 16. Guest Virtual Machine Disk Access with Offline Tools 16.1. Introduction Red Hat Enterprise Linux 6 comes with tools to access, edit and create host physical machine disks or other disk images. There are several uses for these tools, including: Viewing or downloading files located on a host physical machine disk. Editing or uploading files onto a host physical machine disk. Reading or writing host physical machine configuration. Reading or writing the Windows Registry in Windows host physical machines. Preparing new disk images containing files, directories, file systems, partitions, logical volumes and other options. Rescuing and repairing host physical machines that fail to boot or those that need boot configuration changes. Monitoring disk usage of host physical machines. Auditing compliance of host physical machines, for example to organizational security standards. Deploying host physical machines by cloning and modifying templates. Reading CD and DVD ISO and floppy disk images. Warning You must never use these tools to write to a host physical machine or disk image which is attached to a running virtual machine, not even to open such a disk image in write mode. Doing so will result in disk corruption of the guest virtual machine. The tools try to prevent you from doing this, however do not catch all cases. If there is any suspicion that a guest virtual machine might be running, it is strongly recommended that the tools not be used, or at least always use the tools in read-only mode. Note Some virtualization commands in Red Hat Enterprise Linux 6 allow you to specify a remote libvirt connection. For example: However, libguestfs in Red Hat Enterprise Linux 6 cannot access remote guests, and commands using remote URLs like this do not work as expected. This affects the following Red Hat Enterprise Linux 6 commands: guestfish guestmount virt-alignment-scan virt-cat virt-copy-in virt-copy-out virt-df virt-edit virt-filesystems virt-inspector virt-inspector2 virt-list-filesystems virt-list-partitions virt-ls virt-rescue virt-sysprep virt-tar virt-tar-in virt-tar-out virt-win-reg

Commands:
virt-df -c qemu://remote/system -d Guest
Chapter 6. Uninstalling a cluster on Azure Stack Hub You can remove a cluster that you deployed to Azure Stack Hub. 6.1. Removing a cluster that uses installer-provisioned infrastructure You can remove a cluster that uses installer-provisioned infrastructure from your cloud. Note After uninstallation, check your cloud provider for any resources not removed properly, especially with User Provisioned Infrastructure (UPI) clusters. There might be resources that the installer did not create or that the installer is unable to access. Prerequisites You have a copy of the installation program that you used to deploy the cluster. You have the files that the installation program generated when you created your cluster. Procedure From the directory that contains the installation program on the computer that you used to install the cluster, run the following command: USD ./openshift-install destroy cluster \ --dir <installation_directory> --log-level info 1 2 1 For <installation_directory> , specify the path to the directory that you stored the installation files in. 2 To view different details, specify warn , debug , or error instead of info . Note You must specify the directory that contains the cluster definition files for your cluster. The installation program requires the metadata.json file in this directory to delete the cluster. Optional: Delete the <installation_directory> directory and the OpenShift Container Platform installation program.

Commands:
./openshift-install destroy cluster --dir <installation_directory> --log-level info 1 2
5.167. libxklavier 5.167.1. RHBA-2012:0923 - libxklavier bug fix update Updated libxklavier packages that fix three bugs are now available for Red Hat Enterprise Linux 6. The libxklavier library provides a high-level API for the X Keyboard Extension (XKB) that allows extended keyboard control. This library supports X.Org and other commercial implementations of the X Window system. The library is useful for creating XKB-related software, such as layout indicators. Bug Fixes BZ# 657726 , BZ# 766645 Prior to this update, an attempt to log into the server using an NX or VNC client triggered an XInput error that was handled incorrectly by the libxklavier library due to the way how the NoMachine NX Free Edition server implements XInput support. As a consequence, the gnome-settings-daemon aborted unexpectedly. This update modifies the XInput error handling routine in the libxklavier library. Now, the library ignores this error and the gnome-settings-daemon runs as expected. BZ# 726885 Prior to this update, the keyboard layout indicator did not show if the layout was changed for the first time. As a consequence, users could, under certain circumstances, not log in. This update modifies the gnome-settings-daemon so that the indicator now shows the correct layout. All users of libxklavier are advised to upgrade to these updated packages, which fix these bugs.

Commands:
Chapter 4. An active/active Samba Server in a Red Hat High Availability Cluster (Red Hat Enterprise Linux 7.4 and Later) As of the Red Hat Enterprise Linux 7.4 release, the Red Hat Resilient Storage Add-On provides support for running Samba in an active/active cluster configuration using Pacemaker. The Red Hat Resilient Storage Add-On includes the High Availability Add-On. Note For further information on support policies for Samba, see Support Policies for RHEL Resilient Storage - ctdb General Policies and Support Policies for RHEL Resilient Storage - Exporting gfs2 contents via other protocols on the Red Hat Customer Portal. This chapter describes how to configure a highly available active/active Samba server on a two-node Red Hat Enterprise Linux High Availability Add-On cluster using shared storage. The procedure uses pcs to configure Pacemaker cluster resources. This use case requires that your system include the following components: Two nodes, which will be used to create the cluster running Clustered Samba. In this example, the nodes used are z1.example.com and z2.example.com which have IP address of 192.168.1.151 and 192.168.1.152 . A power fencing device for each node of the cluster. This example uses two ports of the APC power switch with a host name of zapc.example.com . Shared storage for the nodes in the cluster, using iSCSI or Fibre Channel. Configuring a highly available active/active Samba server on a two-node Red Hat Enterprise Linux High Availability Add-On cluster requires that you perform the following steps. Create the cluster that will export the Samba shares and configure fencing for each node in the cluster, as described in Section 4.1, "Creating the Cluster" . Configure a gfs2 file system mounted on the clustered LVM logical volume my_clv on the shared storage for the nodes in the cluster, as described in Section 4.2, "Configuring a Clustered LVM Volume with a GFS2 File System" . Configure Samba on each node in the cluster, Section 4.3, "Configuring Samba" . Create the Samba cluster resources as described in Section 4.4, "Configuring the Samba Cluster Resources" . Test the Samba share you have configured, as described in Section 4.5, "Testing the Resource Configuration" . 4.1. Creating the Cluster Use the following procedure to install and create the cluster to use for the Samba service: Install the cluster software on nodes z1.example.com and z2.example.com , using the procedure provided in Section 1.1, "Cluster Software Installation" . Create the two-node cluster that consists of z1.example.com and z2.example.com , using the procedure provided in Section 1.2, "Cluster Creation" . As in that example procedure, this use case names the cluster my_cluster . Configure fencing devices for each node of the cluster, using the procedure provided in Section 1.3, "Fencing Configuration" . This example configures fencing using two ports of the APC power switch with a host name of zapc.example.com .

Commands:
Using Ansible plug-ins for Red Hat Developer Hub Red Hat Ansible Automation Platform 2.5 Use Ansible plug-ins for Red Hat Developer Hub Red Hat Customer Content Services

Commands:
--- - name: Open HTTPS and SSH on firewall hosts: rhel become: true tasks: - name: Use rhel system roles to allow https and ssh traffic vars: firewall: - service: https state: enabled permanent: true immediate: true zone: public - service: ssh state: enabled permanent: true immediate: true zone: public ansible.builtin.include_role: name: redhat.rhel_system_roles.firewall
3.4. RAID and Other Disk Devices Important Red Hat Enterprise Linux 6 uses mdraid instead of dmraid for installation onto Intel BIOS RAID sets. These sets are detected automatically, and devices with Intel ISW metadata are recognized as mdraid instead of dmraid. Note that the device node names of any such devices under mdraid are different from their device node names under dmraid . Therefore, special precautions are necessary when you migrate systems with Intel BIOS RAID sets. Local modifications to /etc/fstab , /etc/crypttab or other configuration files which refer to devices by their device node names will not work in Red Hat Enterprise Linux 6. Before migrating these files, you must therefore edit them to replace device node paths with device UUIDs instead. You can find the UUIDs of devices with the blkid command. 3.4.1. Hardware RAID RAID, or Redundant Array of Independent Disks, allows a group, or array, of drives to act as a single device. Configure any RAID functions provided by the mainboard of your computer, or attached controller cards, before you begin the installation process. Each active RAID array appears as one drive within Red Hat Enterprise Linux. On systems with more than one hard drive you may configure Red Hat Enterprise Linux to operate several of the drives as a Linux RAID array without requiring any additional hardware.

Commands:
probe::ioscheduler.elv_add_request.kp Name probe::ioscheduler.elv_add_request.kp - kprobe based probe to indicate that a request was added to the request queue Synopsis ioscheduler.elv_add_request.kp Values disk_major Disk major number of the request disk_minor Disk minor number of the request rq_flags Request flags elevator_name The type of I/O elevator currently enabled q pointer to request queue rq Address of the request name Name of the probe point

Commands:
Chapter 6. Listing available SCAP contents Use this procedure to view what SCAP contents are already loaded in Satellite. To use the CLI instead of the Satellite web UI, see the CLI procedure . Prerequisites Your user account has a role assigned that has the view_scap_contents permission. Procedure In the Satellite web UI, navigate to Hosts > Compliance > SCAP contents . CLI procedure Run the following Hammer command on Satellite Server:

Commands:
hammer scap-content list --location " My_Location " --organization " My_Organization "
3.5. Date and Time Conversions JBoss Data Virtualization can implicitly convert properly formatted literal strings to their associated date-related data types as follows: Table 3.4. Date and Time Conversions String Literal Format Possible Implicit Conversion Type yyyy-mm-dd DATE hh:mm:ss TIME yyyy-mm-dd hh:mm:ss.[fff...] TIMESTAMP The formats above are those expected by the JDBC date types. To use other formats see the functions PARSEDATE , PARSETIME , PARSETIMESTAMP .

Commands:
3.4.4. Modifying User Settings When a user already exists and you need to specify any of the options now, use the usermod command. The logic of using usermod is identical to useradd as well as its syntax: If you need to change the user's user name, use the -l option with the new user name (or login). Example 3.10. Changing User's Login The -l option changes the name of the user from the login emily to the new login, emily-smith . Nothing else is changed. In particular, emily 's home directory name ( /home/emily ) remains the same unless it is changed manually to reflect the new user name. In a similar way you can change the user's UID or user's home directory. See the example below: Note Find all files owned by the specified UID in system and change their owner. Do the same for Access Control List (ACL) referring to the UID. It is recommended to check there are no running processes as they keep running with the old UID. Example 3.11. Changing User's UID and Home Directory The command with -a -u and -d options changes the settings of user robert . Now, his ID is 699 instead of 501, and his home directory is no longer /home/robert but /home/dir_2 . With the usermod command you can also move the content of the user's home directory to a new location, or lock the account by locking its password. Example 3.12. Changing User's In this sample command, the -m and -d options used together move the content of jane 's home directory to the /home/dir_3 directory. The -L option locks the access to jane 's account by locking its password. For the whole list of options to be used with the usermod command, see the usermod (8) man page or run usermod --help on the command line.

Commands:
usermod option(s) username
~]# usermod -l "emily-smith" emily
~]# usermod -a -u 699 -d /home/dir_2 robert
~]# usermod -m -d /home/jane -L jane
Preface Cryostat is a container-native Java application that connects your Java workloads running inside an OpenShift cluster to your desktop JDK Mission Control (JMC) application. The primary feature for Cryostat 2.0 is that you can install and deploy Cryostat through the OpenShift Operator in the OperatorHub of the OpenShift Container Platform web console. After you install and deploy Cryostat, you can access a fully featured Cryostat instance and then explore any of the additional features listed in the Release notes for the Red Hat build of Cryostat 2.0 guide. Important Red Hat build of Cryostat is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process. For more information about the support scope of Red Hat Technology Preview features, see Technology Preview Features Support Scope (Red Hat Customer Portal).

Commands:
11.12. Setting up Shared Storage Volume Features like Snapshot Scheduler, NFS Ganesha and geo-replication require a shared storage to be available across all nodes of the cluster. A gluster volume named gluster_shared_storage is made available for this purpose, and is facilitated by the following volume set option. This option accepts the following two values: enable When the volume set option is enabled, a gluster volume named gluster_shared_storage is created in the cluster, and is mounted at /var/run/gluster/shared_storage on all the nodes in the cluster. Note With the release of 3.5 Batch Update 3, the mount point of shared storage is changed from /var/run/gluster/ to /run/gluster/ . Note This option cannot be enabled if there is only one node present in the cluster, or if only one node is online in the cluster. The volume created is a replica 3 volume. This depends on the number of nodes which are online in the cluster at the time of enabling this option and each of these nodes will have one brick participating in the volume. The brick path participating in the volume is /var/lib/glusterd/ss_brick. The mount entry is also added to /etc/fstab as part of enable . Before enabling this feature make sure that there is no volume named gluster_shared_storage in the cluster. This volume name is reserved for internal use only After successfully setting up the shared storage volume, when a new node is added to the cluster, the shared storage is not mounted automatically on this node. Neither is the /etc/fstab entry added for the shared storage on this node. To make use of shared storage on this node, execute the following commands: disable When the volume set option is disabled, the gluster_shared_storage volume is unmounted on all the nodes in the cluster, and then the volume is deleted. The mount entry from /etc/fstab as part of disable is also removed. For example: Important After creating a cluster excute the following command on all nodes present in the cluster: This is applicable for Red Hat Enterpise Linux 7 (RHEL 7) and Red Hat Enterpise Linux 8 (RHEL 8).

Commands:
cluster.enable-shared-storage
mount -t glusterfs <local node's ip>:gluster_shared_storage /var/run/gluster/shared_storage cp /etc/fstab /var/run/gluster/fstab.tmp echo "<local node's ip>:/gluster_shared_storage /var/run/gluster/shared_storage/ glusterfs defaults 0 0" >> /etc/fstab
gluster volume set all cluster.enable-shared-storage enable volume set: success
systemctl enable glusterfssharedstorage.service
11.3. JSON Representation of a Network Resource Example 11.2. A JSON representation of a network resource

Commands:
{ "network" : [ { "data_center" : { "href" : "/ovirt-engine/api/datacenters/00000002-0002-0002-0002-000000000255", "id" : "00000002-0002-0002-0002-000000000255" }, "stp" : "false", "mtu" : "0", "usages" : { "usage" : [ "vm" ] }, "name" : "ovirtmgmt", "description" : "Management Network", "href" : "/ovirt-engine/api/networks/00000000-0000-0000-0000-000000000009", "id" : "00000000-0000-0000-0000-000000000009", "link" : [ { "href" : "/ovirt-engine/api/networks/00000000-0000-0000-0000-000000000009/permissions", "rel" : "permissions" }, { "href" : "/ovirt-engine/api/networks/00000000-0000-0000-0000-000000000009/vnicprofiles", "rel" : "vnicprofiles" }, { "href" : "/ovirt-engine/api/networks/00000000-0000-0000-0000-000000000009/labels", "rel" : "labels" } ] } ] }
7.144. microcode_ctl 7.144.1. RHBA-2013:0348 - microcode_ctl bug fix and enhancement update Updated microcode_ctl packages that fix a bug and add various enhancements are now available for Red Hat Enterprise Linux 6. The microcode_ctl packages provide utility code and microcode data to assist the kernel in updating the CPU microcode at system boot time. This microcode supports all current x86-based, Intel 64-based, and AMD64-based CPU models. It takes advantage of the mechanism built-in to Linux that allows microcode to be updated after system boot. When loaded, the updated microcode corrects the behavior of various processors, as described in processor specification updates issued by Intel and AMD for those processors. Bug Fix BZ#740932 Previously, a udev rule in /lib/udev/rules.d/89-microcode.rules allowed the module to load more than once. On very large systems (for example, systems with 2048 or more CPUs), this could result in the system becoming unresponsive on boot. With this update, the udev rule has been changed to ensure the module loads only once. Very large systems now boot as expected. Enhancements BZ#818096 The Intel CPU microcode file has been updated to version 20120606. BZ# 867078 The AMD CPU microcode file has been updated to version 20120910. All users of microcode_ctl are advised to upgrade to these updated packages, which fix this bug and add these enhancements. Note: a system reboot is necessary for this update to take effect.

Commands: