mtpti5iD/redhat-docs_dataset huggingface dataset:
28.3. Adding a New Password Policy When adding a new password policy, you must specify: a user group to which the policy will apply (see Section 28.2.2, "Global and Group-specific Password Policies" ) a priority (see Section 28.2.3, "Password Policy Priorities" ) To add a new password policy using: the web UI, see the section called "Web UI: Adding a New Password Policy" the command line, see the section called "Command Line: Adding a New Password Policy" Web UI: Adding a New Password Policy Select Policy Password Policies . Click Add . Define the user group and priority. Click Add to confirm. To configure the attributes of the new password policy, see Section 28.4, "Modifying Password Policy Attributes" . Command Line: Adding a New Password Policy Use the ipa pwpolicy-add command. Specify the user group and priority: Optional. Use the ipa pwpolicy-find command to verify that the policy has been successfully added: To configure the attributes of the new password policy, see Section 28.4, "Modifying Password Policy Attributes" .

Commands:
ipa pwpolicy-add Group: group_name Priority: priority_level
ipa pwpolicy-find
3.7. Starting a Process in a Control Group Launch processes in a manually created cgroup by running the cgexec command. The syntax for cgexec is: where: controllers is a comma-separated list of controllers, or /* to launch the process in the hierarchies associated with all available subsystems. Note that, as with the cgset command described in Section 3.5, "Setting Cgroup Parameters" , if cgroups of the same name exist, the -g option creates processes in each of those groups. path_to_cgroup is the path to the cgroup relative to the hierarchy; command is the command to be executed in the cgroup; arguments are any arguments for the command. It is also possible to add the --sticky option before the command to keep any child processes in the same cgroup. If you do not set this option and the cgred service is running, child processes will be allocated to cgroups based on the settings found in /etc/cgrules.conf . The process itself, however, will remain in the cgroup in which you started it.

Commands:
cgexec -g controllers : path_to_cgroup command arguments
Chapter 12. Red Hat Enterprise Linux Atomic Host 7.6.6 12.1. Atomic Host OStree update : New Tree Version: 7.6.6 (hash: 33bb37a7d207ce653eab70306d18deea7daf444b6b7f7aeadef722f96d7e8e6d) Changes since Tree Version 7.6.5 (hash: 5b1058baee886a346301af3b250e51cd6deef7344206afff638d07d5b73b34da) Updated packages : microdnf-2-8.el7 12.2. Extras Updated packages : buildah-1.9.0-1.el7 container-selinux-2.107-1.el7_6 containernetworking-plugins-0.8.1-1.el7 docker-1.13.1-102.git7f2769b.el7 oci-umount-2.5-1.el7_6 podman-1.4.4-2.el7 runc-1.0.0-64.rc8.el7 skopeo-0.1.37-1.el7 12.2.1. Container Images Updated : Red Hat Enterprise Linux 7 Init Container Image (rhel7/rhel7-init) Red Hat Enterprise Linux 7.6 Container Image (rhel7.6, rhel7, rhel7/rhel, rhel) Red Hat Enterprise Linux 7.6 Container Image for aarch64 (rhel7.6, rhel7, rhel7/rhel, rhel) Red Hat Enterprise Linux Atomic Identity Management Server Container Image (rhel7/ipa-server) Red Hat Enterprise Linux Atomic Image (rhel-atomic, rhel7-atomic, rhel7/rhel-atomic) Red Hat Enterprise Linux Atomic Net-SNMP Container Image (rhel7/net-snmp) Red Hat Enterprise Linux Atomic OpenSCAP Container Image (rhel7/openscap) Red Hat Enterprise Linux Atomic SSSD Container Image (rhel7/sssd) Red Hat Enterprise Linux Atomic Support Tools Container Image (rhel7/support-tools) Red Hat Enterprise Linux Atomic Tools Container Image (rhel7/rhel-tools) Red Hat Enterprise Linux Atomic cockpit-ws Container Image (rhel7/cockpit-ws) Red Hat Enterprise Linux Atomic etcd Container Image (rhel7/etcd) Red Hat Enterprise Linux Atomic flannel Container Image (rhel7/flannel) Red Hat Enterprise Linux Atomic open-vm-tools Container Image (rhel7/open-vm-tools) Red Hat Enterprise Linux Atomic rsyslog Container Image (rhel7/rsyslog) Red Hat Enterprise Linux Atomic sadc Container Image (rhel7/sadc) Red Hat Universal Base Image 7 Container Image (rhel7/ubi7) Red Hat Universal Base Image 7 Init Container Image (rhel7/ubi7-init) Red Hat Universal Base Image 7 Minimal Container Image (rhel7/ubi7-minimal) 12.3. New Features docker-latest no longer available The docker-latest package is no longer available beginning with RHEL Atomic 7.6.6. Only the docker package is available.

Commands:
14.2. Attaching and Updating a Device with virsh For information on attaching storage devices refer to Section 13.3.1, "Adding File-based Storage to a Guest" Procedure 14.1. Hot plugging USB devices for use by the guest virtual machine The following procedure demonstrates how to attach USB devices to the guest virtual machine. This can be done while the guest virtual machine is running as a hotplug procedure or it can be done while the guest is shutoff. The device you want to emulate needs to be attached to the host physical machine. Locate the USB device you want to attach with the following command: Create an XML file and give it a logical name ( usb_device.xml , for example). Make sure you copy the vendor and product IDs exactly as was displayed in your search. <hostdev mode='subsystem' type='usb' managed='yes'> <source> <vendor id='0x17ef'/> <product id='0x480f'/> </source> </hostdev> ... Figure 14.1. USB Devices XML Snippet Attach the device with the following command: In this example [rhel6] is the name of your guest virtual machine and [usb_device.xml] is the file you created in the step. If you want to have the change take effect in the reboot, use the --config option. If you want this change to be persistent, use the --persistent option. If you want the change to take effect on the current domain, use the --current option. See the Virsh man page for additional information. If you want to detach the device (hot unplug), perform the following command: In this example [rhel6] is the name of your guest virtual machine and [usb_device.xml] is the file you attached in the step

Commands:
lsusb -v idVendor 0x17ef Lenovo idProduct 0x480f Integrated Webcam [R5U877]
<hostdev mode='subsystem' type='usb' managed='yes'> <source> <vendor id='0x17ef'/> <product id='0x480f'/> </source> </hostdev>
virsh attach-device rhel6 --file usb_device.xml --config
virsh detach-device rhel6 --file usb_device.xml
9.12. Upgrading an Existing System Important The following sections only apply to upgrading Red Hat Enterprise Linux between minor versions, for example, upgrading Red Hat Enterprise Linux 6.4 to Red Hat Enterprise Linux 6.5 or higher. This approach is not supported for upgrades between major versions, for example, upgrading Red Hat Enterprise Linux 6 to Red Hat Enterprise Linux 7. In-place upgrades between major versions of Red Hat Enterprise Linux can be done, with certain limitations, using the Red Hat Upgrade Tool and Preupgrade Assistant tools. See Chapter 37, Upgrading Your Current System for more information. The installation system automatically detects any existing installation of Red Hat Enterprise Linux. The upgrade process updates the existing system software with new versions, but does not remove any data from users' home directories. The existing partition structure on your hard drives does not change. Your system configuration changes only if a package upgrade demands it. Most package upgrades do not change system configuration, but rather install an additional configuration file for you to examine later. Note that the installation medium that you are using might not contain all the software packages that you need to upgrade your computer. 9.12.1. The Upgrade Dialog If your system contains a Red Hat Enterprise Linux installation, a dialog appears asking whether you want to upgrade that installation. To perform an upgrade of an existing system, choose the appropriate installation from the drop-down list and select . Figure 9.35. The Upgrade Dialog Note Software you have installed manually on your existing Red Hat Enterprise Linux system may behave differently after an upgrade. You may need to manually reinstall or recompile this software after an upgrade to ensure it performs correctly on the updated system.

Commands:
6.2. I/O Scheduling with Red Hat Enterprise Linux as a Virtualization Guest You can use I/O scheduling on a Red Hat Enterprise Linux guest virtual machine, regardless of the hypervisor on which the guest is running. The following is a list of benefits and issues that should be considered: Red Hat Enterprise Linux guests often benefit greatly from using the noop scheduler. The scheduler merges small requests from the guest operating system into larger requests before sending the I/O to the hypervisor. This enables the hypervisor to process the I/O requests more efficiently, which can significantly improve the guest's I/O performance. Depending on the workload I/O and how storage devices are attached, schedulers like deadline can be more beneficial than noop . Red Hat recommends performance testing to verify which scheduler offers the best performance impact. Guests that use storage accessed by iSCSI, SR-IOV, or physical device passthrough should not use the noop scheduler. These methods do not allow the host to optimize I/O requests to the underlying physical device. Note In virtualized environments, it is sometimes not beneficial to schedule I/O on both the host and guest layers. If multiple guests use storage on a file system or block device managed by the host operating system, the host may be able to schedule I/O more efficiently because it is aware of requests from all guests. In addition, the host knows the physical layout of storage, which may not map linearly to the guests' virtual storage. All scheduler tuning should be tested under normal operating conditions, as synthetic benchmarks typically do not accurately compare performance of systems using shared resources in virtual environments. 6.2.1. Configuring the I/O Scheduler for Red Hat Enterprise Linux 7 The default scheduler used on a Red Hat Enterprise Linux 7 system is deadline . However, on a Red Hat Enterprise Linux 7 guest machine, it may be beneficial to change the scheduler to noop , by doing the following: In the /etc/default/grub file, change the elevator=deadline string on the GRUB_CMDLINE_LINUX line to elevator=noop . If there is no elevator= string, add elevator=noop at the end of the line. The following shows the /etc/default/grub file after a successful change. Rebuild the /boot/grub2/grub.cfg file. On a BIOS-based machine: On an UEFI-based machine:

Commands:
cat /etc/default/grub [...] GRUB_CMDLINE_LINUX="crashkernel=auto rd.lvm.lv=vg00/lvroot rhgb quiet elevator=noop" [...]
grub2-mkconfig -o /boot/grub2/grub.cfg
grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg
F.4. About RELAY2 The RELAY protocol bridges two remote clusters by creating a connection between one node in each site. This allows multicast messages sent out in one site to be relayed to the other and vice versa. JGroups includes the RELAY2 protocol, which is used for communication between sites in Red Hat JBoss Data Grid's Cross-Site Replication. The RELAY2 protocol works similarly to RELAY but with slight differences. Unlike RELAY , the RELAY2 protocol: connects more than two sites. connects sites that operate autonomously and are unaware of each other. offers both unicasts and multicast routing between sites. Report a bug

Commands:
Chapter 1. Overview of model registries Important Model registry is currently available in Red Hat OpenShift AI 2.18 as a Technology Preview feature. 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 . A model registry is an important component in the lifecycle of an artificial intelligence/machine learning (AI/ML) model, and a vital part of any machine learning operations (MLOps) platform or ML workflow. A model registry acts as a central repository, holding metadata related to machine learning models from inception to deployment. This metadata ranges from high-level information like the deployment environment and project origins, to intricate details like training hyperparameters, performance metrics, and deployment events. A model registry acts as a bridge between model experimentation and serving, offering a secure, collaborative metadata store interface for stakeholders of the ML lifecycle. Model registries provide a structured and organized way to store, share, version, deploy, and track models. To use model registries in OpenShift AI, an OpenShift cluster administrator must configure the model registry component. For more information, see Configuring the model registry component . After the model registry component is configured, an OpenShift AI administrator can create model registries in OpenShift AI and grant model registry access to the data scientists that will work with them. For more information, see Managing model registries . Data scientists with access to a model registry can store, share, version, deploy, and track models using the model registry feature. For more information, see Working with model registries .

Commands:
32.10. Making the Installation Tree Available The kickstart installation must access an installation tree . An installation tree is a copy of the binary Red Hat Enterprise Linux DVD with the same directory structure. If you are performing a DVD-based installation, insert the Red Hat Enterprise Linux installation DVD into the computer before starting the kickstart installation. If you are performing a hard drive installation, make sure the ISO images of the binary Red Hat Enterprise Linux DVD are on a hard drive in the computer. If you are performing a network-based (NFS, FTP or HTTP) installation, you must make the installation tree or ISO image available over the network. Refer to Section 4.1, "Preparing for a Network Installation" for details.

Commands:
Chapter 7. Logical Volume Manager (LVM) 7.1. What is LVM? LVM is a method of allocating hard drive space into logical volumes that can be easily resized instead of partitions. With LVM, a hard drive or set of hard drives is allocated to one or more physical volumes . A physical volume cannot span over more than one drive. The physical volumes are combined into logical volume groups , with the exception of the /boot/ partition. The /boot/ partition cannot be on a logical volume group because the boot loader cannot read it. If the root ( / ) partition is on a logical volume, create a separate /boot/ partition which is not a part of a volume group. Since a physical volume cannot span over multiple drives, to span over more than one drive, create one or more physical volumes per drive. Figure 7.1. Logical Volume Group The logical volume group is divided into logical volumes , which are assigned mount points, such as /home and / m and file system types, such as ext2 or ext3. When "partitions" reach their full capacity, free space from the logical volume group can be added to the logical volume to increase the size of the partition. When a new hard drive is added to the system, it can be added to the logical volume group, and partitions that are logical volumes can be expanded. Figure 7.2. Logical Volumes On the other hand, if a system is partitioned with the ext3 file system, the hard drive is divided into partitions of defined sizes. If a partition becomes full, it is not easy to expand the size of the partition. Even if the partition is moved to another hard drive, the original hard drive space has to be reallocated as a different partition or not used. LVM support must be compiled into the kernel, and the default Red Hat kernel is compiled with LVM support. To learn how to configure LVM during the installation process, refer to Chapter 8, LVM Configuration .

Commands:
Chapter 4. The DM-Multipath Configuration File By default, DM-Multipath provides configuration values for the most common uses of multipathing. In addition, DM-Multipath includes support for the most common storage arrays that support DM-Multipath. The default configuration values and the supported devices can be found in the /usr/share/doc/device-mapper-multipath-0.4.9/multipath.conf.defaults file. You can override the default configuration values for DM-Multipath by editing the /etc/multipath.conf configuration file. If necessary, you can also add a storage array that is not supported by default to the configuration file. Note You can run set up multipathing in the initramfs file system. If you run multipath from the initramfs file system and you make any changes to the multipath configuration files, you must rebuild the initramfs file system for the changes to take effect. For information on rebuilding the initramfs file system with multipath, see Section 3.4, "Setting Up Multipathing in the initramfs File System" . This chapter provides information on parsing and modifying the multipath.conf file. It contains sections on the following topics: Configuration file overview Configuration file blacklist Configuration file defaults Configuration file multipaths Configuration file devices In the multipath configuration file, you need to specify only the sections that you need for your configuration, or that you wish to change from the default values specified in the multipath.conf.defaults file. If there are sections of the file that are not relevant to your environment or for which you do not need to override the default values, you can leave them commented out, as they are in the initial file. The configuration file allows regular expression description syntax. An annotated version of the configuration file can be found in /usr/share/doc/device-mapper-multipath-0.4.9/multipath.conf.annotated . 4.1. Configuration File Overview The multipath configuration file is divided into the following sections: blacklist Listing of specific devices that will not be considered for multipath. blacklist_exceptions Listing of multipath candidates that would otherwise be blacklisted according to the parameters of the blacklist section. defaults General default settings for DM-Multipath. multipaths Settings for the characteristics of individual multipath devices. These values overwrite what is specified in the defaults and devices sections of the configuration file. devices Settings for the individual storage controllers. These values overwrite what is specified in the defaults section of the configuration file. If you are using a storage array that is not supported by default, you may need to create a devices subsection for your array. When the system determines the attributes of a multipath device, first it checks the multipath settings, then the per devices settings, then the multipath system defaults.

Commands:
2.4. Configuring a High Availability pcsd Web UI When you use the pcsd Web UI, you connect to one of the nodes of the cluster to display the cluster management pages. If the node to which you are connecting goes down or becomes unavailable, you can reconnect to the cluster by opening your browser to a URL that specifies a different node of the cluster. It is possible, however, to configure the pcsd Web UI itself for high availability, in which case you can continue to manage the cluster without entering a new URL. To configure the pcsd Web UI for high availability, perform the following steps. Ensure that PCSD_SSL_CERT_SYNC_ENABLED is set to true in the /etc/sysconfig/pcsd configuration file, which is the default value in RHEL 7. Enabling certificate syncing causes pcsd to sync the pcsd certificates for the cluster setup and node add commands. Create an IPaddr2 cluster resource, which is a floating IP address that you will use to connect to the pcsd Web UI. The IP address must not be one already associated with a physical node. If the IPaddr2 resource's NIC device is not specified, the floating IP must reside on the same network as one of the node's statically assigned IP addresses, otherwise the NIC device to assign the floating IP address cannot be properly detected. Create custom SSL certificates for use with pcsd and ensure that they are valid for the addresses of the nodes used to connect to the pcsd Web UI. To create custom SSL certificates, you can use either wildcard certificates or you can use the Subject Alternative Name certificate extension. For information on the Red Hat Certificate System, see the Red Hat Certificate System Administration Guide . Install the custom certificates for pcsd with the pcs pcsd certkey command. Sync the pcsd certificates to all nodes in the cluster with the pcs pcsd sync-certificates command. Connect to the pcsd Web UI using the floating IP address you configured as a cluster resource. Note Even when you configure the pcsd Web UI for high availability, you will be asked to log in again when the node to which you are connecting goes down.

Commands:
Chapter 11. 4.8 Release Notes 11.1. New Features The following major enhancements have been introduced in Red Hat Update Infrastructure 4.8. RHUA Server Can Be Updated During the Update Process A native Ansible module is now used to update the packages on the RHUA server, during the update process. This update can be prevented by using the --ignore-newer-rhel-packages flag. New Pulp version This update introduces a newer version of Pulp, 3.39. 11.2. Bug Fixes The following bugs have been fixed in Red Hat Update Infrastructure 4.8 that have a significant impact on users. Installation no longer fails on RHEL 8.10 Beta The rhui-installer failed on RHEL 8.10 Beta due to the use of distutils. This has been addressed by updating to a newer version of ansible-collection-community-crypto which does not use the distutils.

Commands:
Chapter 14. Integrating with the Red Hat build of Debezium for change data capture The Red Hat build of Debezium is a distributed change data capture platform. It captures row-level changes in databases, creates change event records, and streams the records to Kafka topics. Debezium is built on Apache Kafka. You can deploy and integrate the Red Hat build of Debezium with Streams for Apache Kafka. Following a deployment of Streams for Apache Kafka, you deploy Debezium as a connector configuration through Kafka Connect. Debezium passes change event records to Streams for Apache Kafka on OpenShift. Applications can read these change event streams and access the change events in the order in which they occurred. Debezium has multiple uses, including: Data replication Updating caches and search indexes Simplifying monolithic applications Data integration Enabling streaming queries To capture database changes, deploy Kafka Connect with a Debezium database connector. You configure a KafkaConnector resource to define the connector instance. For more information on deploying the Red Hat build of Debezium with Streams for Apache Kafka, refer to the product documentation . The documentation includes a Getting Started with Debezium guide that guides you through the process of setting up the services and connector required to view change event records for database updates.

Commands:
function::user_string_n_warn Name function::user_string_n_warn - Retrieves string from user space. Synopsis Arguments addr The user space address to retrieve the string from. n The maximum length of the string (if not null terminated). General Syntax user_string_n_warn:string(addr:long, n:long) Description Returns up to n characters of a C string from a given user space memory address. Reports " <unknown> " on the rare cases when userspace data is not accessible and warns (but does not abort) about the failure.

Commands:
function user_string_n_warn:string(addr:long,n:long)