mtpti5iD/redhat-docs_dataset huggingface dataset:
4.3. Prerequisites for Installing a Replica The installation requirements for replicas are the same as for IdM servers. Make sure that the replica machine meets all of the prerequisites listed in Section 2.1, "Prerequisites for Installing a Server" . In addition to the general server requirements, you must also meet the following conditions: The replica must be running the same or later version of IdM For example, if the master server is running on Red Hat Enterprise Linux 7 and uses the IdM 4.4 packages, then the replica must also run on Red Hat Enterprise Linux 7 or later and use IdM version 4.4 or later. This ensures that configuration can be properly copied from the server to the replica. Important IdM does not support creating a replica of an earlier version than the version of the master. If you try to create a replica using an earlier version, the installation fails. The replica needs additional ports to be open In addition to the standard IdM server port requirements described in Section 2.1.6, "Port Requirements" , make sure you also meet the following: At domain level 0, keep the TCP port 22 open on the master server during the replica setup process. This port is required in order to use SSH to connect to the master server. Note For details on domain levels, see Chapter 7, Displaying and Raising the Domain Level . If one of the servers is running Red Hat Enterprise Linux 6 and has a CA installed, keep also TCP port 7389 open during and after the replica configuration. In a purely Red Hat Enterprise Linux 7 environment, port 7389 is not required. For information on how to open ports using the firewall-cmd utility, see Section 2.1.6, "Port Requirements" .

Commands:
Chapter 7. Data Grid ports and protocols As Data Grid distributes data across your network and can establish connections for external client requests, you should be aware of the ports and protocols that Data Grid uses to handle network traffic. If run Data Grid as a remote server then you might need to allow remote clients through your firewall. Likewise, you should adjust ports that Data Grid nodes use for cluster communication to prevent conflicts or network issues. 7.1. Data Grid Server ports and protocols Data Grid Server provides network endpoints that allow client access with different protocols. Port Protocol Description 11222 TCP Hot Rod and REST 11221 TCP Memcached (disabled by default) Single port Data Grid Server exposes multiple protocols through a single TCP port, 11222 . Handling multiple protocols with a single port simplifies configuration and reduces management complexity when deploying Data Grid clusters. Using a single port also enhances security by minimizing the attack surface on the network. Data Grid Server handles HTTP/1.1, HTTP/2, and Hot Rod protocol requests from clients via the single port in different ways. HTTP/1.1 upgrade headers Client requests can include the HTTP/1.1 upgrade header field to initiate HTTP/1.1 connections with Data Grid Server. Client applications can then send the Upgrade: protocol header field, where protocol is a server endpoint. Application-Layer Protocol Negotiation (ALPN)/Transport Layer Security (TLS) Client requests include Server Name Indication (SNI) mappings for Data Grid Server endpoints to negotiate protocols over a TLS connection. Automatic Hot Rod detection Client requests that include Hot Rod headers automatically route to Hot Rod endpoints. 7.1.1. Configuring network firewalls for Data Grid traffic Adjust firewall rules to allow traffic between Data Grid Server and client applications. Procedure On Red Hat Enterprise Linux (RHEL) workstations, for example, you can allow traffic to port 11222 with firewalld as follows: To configure firewall rules that apply across a network, you can use the nftables utility. Reference Using and configuring firewalld Getting started with nftables 7.2. TCP and UDP ports for cluster traffic Data Grid uses the following ports for cluster transport messages: Default Port Protocol Description 7800 TCP/UDP JGroups cluster bind port 46655 UDP JGroups multicast Cross-site replication Data Grid uses the following ports for the JGroups RELAY2 protocol: 7900 For Data Grid clusters running on OpenShift. 7800 If using UDP for traffic between nodes and TCP for traffic between clusters. 7801 If using TCP for traffic between nodes and TCP for traffic between clusters.

Commands:
firewall-cmd --add-port=11222/tcp --permanent success firewall-cmd --list-ports | grep 11222 11222/tcp
Common object reference OpenShift Container Platform 4.15 Reference guide common API objects Red Hat OpenShift Documentation Team

Commands:
<quantity> ::= <signedNumber><suffix>
(Note that <suffix> may be empty, from the "" case in <decimalSI>.)
(International System of units; See: http://physics.nist.gov/cuu/Units/binary.html)
(Note that 1024 = 1Ki but 1000 = 1k; I didn't choose the capitalization.)
type MyAPIObject struct { runtime.TypeMeta `json:",inline"` MyPlugin runtime.Object `json:"myPlugin"` }
type PluginA struct { AOption string `json:"aOption"` }
type MyAPIObject struct { runtime.TypeMeta `json:",inline"` MyPlugin runtime.RawExtension `json:"myPlugin"` }
type PluginA struct { AOption string `json:"aOption"` }
{ "kind":"MyAPIObject", "apiVersion":"v1", "myPlugin": { "kind":"PluginA", "aOption":"foo", }, }
5.76. gawk 5.76.1. RHBA-2012:1146 - gawk bug fix update Updated gawk packages that fix one bug are now available for Red Hat Enterprise Linux 6. The gawk packages provide the GNU version of the text processing utility awk. Awk interprets a special-purpose programming language to do quick and easy text pattern matching and reformatting jobs. Bug Fix BZ# 829558 Prior to this update, the "re_string_skip_chars" function incorrectly used the character count instead of the raw length to estimate the string length. As a consequence, any text in multi-byte encoding that did not use the UTF-8 format failed to be processed correctly. This update modifies the underlying code so that the correct string length is used. multi-byte encoding is processed correctly. All users of gawk requiring multi-byte encodings that do not use UTF-8 are advised to upgrade to these updated packages, which fix this bug. 5.76.2. RHBA-2012:0385 - gawk bug fix update An updated gawk package that fixes three bugs is now available for Red Hat Enterprise Linux 6. The gawk package contains the GNU version of awk, a text processing utility. AWK interprets a special-purpose programming language to do quick and easy text pattern matching and reformatting jobs. Bug Fixes BZ# 648906 Prior to this update, the gawk utility could, under certain circumstances, interpret some run-time variables as internal zero-length variable prototypes. When gawk tried to free such run-time variables, it actually freed the internal prototypes, that were allocated just once due to memory savings. As a consequence, gawk sometimes failed and the error message "awk: double free or corruption" was displayed. With this update the problem has been corrected and the error no longer occurs. BZ# 740673 Prior to this update, the gawk utility did not copy variables from the command line arguments. As a consequence, the variables were not accessible as intended. This update modifies the underlying code so that gawk makes copies of those variables. BZ# 743242 Prior to this update, the Yacc interpreter encountered problems handling larger stacks. As a consequence, the Yacc interpreter could fail with a stack overflow error when interpreting the AWK code. This update enlarges the stack and Yacc can now handle these AWK programs. All users of gawk are advised to upgrade to this updated package, which fixes these bugs.

Commands:
15.3. Configuring Memory Slots Reserved for the Self-Hosted Engine on Additional Hosts If the Manager virtual machine shuts down or needs to be migrated, there must be enough memory on a self-hosted engine node for the Manager virtual machine to restart on or migrate to it. This memory can be reserved on multiple self-hosted engine nodes by using a scheduling policy. The scheduling policy checks if enough memory to start the Manager virtual machine will remain on the specified number of additional self-hosted engine nodes before starting or migrating any virtual machines. See Creating a Scheduling Policy in the Administration Guide for more information about scheduling policies. To add more self-hosted engine nodes to the Red Hat Virtualization Manager, see Section 15.4, "Adding Self-Hosted Engine Nodes to the Red Hat Virtualization Manager" . Configuring Memory Slots Reserved for the Self-Hosted Engine on Additional Hosts Click Compute Clusters and select the cluster containing the self-hosted engine nodes. Click Edit . Click the Scheduling Policy tab. Click + and select HeSparesCount . Enter the number of additional self-hosted engine nodes that will reserve enough free memory to start the Manager virtual machine. Click OK .

Commands:
4.2. Tuning CPUs with Tuna Tuna commands can target individual CPUs. To list the CPUs on your system, see the Monitoring tab in Tuna GUI or the /proc/cpuinfo file for detailed information. To specify the list of CPUs to be affected by your command, use: Isolating a CPU causes all tasks currently running on that CPU to move to the available CPU. To isolate a CPU, use: Including a CPU allows threads to run on the specified CPU. To include a CPU, use: The cpu_list argument is a list of comma-separated CPU numbers. For example, --cpus=0,2 .

Commands:
tuna --cpus= cpu_list --run= COMMAND
tuna --cpus= cpu_list --isolate
tuna --cpus= cpu_list --include
Chapter 1. Installing Red Hat Developer Hub on OpenShift Dedicated on GCP using the Operator You can install Developer Hub on OpenShift Dedicated on GCP using the Red Hat Developer Hub Operator. Prerequisites You have a valid GCP account. Your OpenShift Dedicated cluster is running on GCP. For more information, see Creating a cluster on GCP in Red Hat OpenShift Dedicated documentation. You have administrator access to OpenShift Dedicated cluster and GCP project. Procedure In the Administrator perspective of the OpenShift Container Platform web console, click Operators > OperatorHub . In the Filter by keyword box, enter Developer Hub and click the Red Hat Developer Hub Operator card. On the Red Hat Developer Hub Operator page, click Install . In the OpenShift Container Platform console, navigate to Installed Operators and select Red Hat Developer Hub Operator . From the Developer Hub Operator page, click Create New Instance and specify the name and namespace where you want to deploy Developer Hub. Configure the required settings such as Git integration, secret management, and user permissions. Review the configuration, select deployment options, and click Create . Verification To access the Developer Hub, navigate to the Developer Hub URL provided in the OpenShift Container Platform web console. Additional resources Administration guide for Red Hat Developer Hub

Commands:
Updating Red Hat Enterprise Linux AI 1.3 Upgrading your RHEL AI system and models Red Hat RHEL AI Documentation Team

Commands:
sudo podman login registry.redhat.io --username <user-name> --password <user-password> --authfile /etc/ostree/auth.json
sudo skopeo login registry.redhat.io --username <user-name> --password <user-password> --authfile /etc/ostree/auth.json
sudo bootc switch <latest-rhelai-image>
sudo bootc switch registry.redhat.io/rhelai1/bootc-nvidia-rhel9:1.3
sudo reboot -n
sudo bootc upgrade --apply
ilab config init
ilab model download --repository <repository_and_model> --release latest
ilab model list
Chapter 3. Pipelines 3.1. About Red Hat OpenShift Pipelines Red Hat OpenShift Pipelines is a cloud-native, continuous integration and continuous delivery (CI/CD) solution based on Kubernetes resources. It uses Tekton building blocks to automate deployments across multiple platforms by abstracting away the underlying implementation details. Tekton introduces a number of standard custom resource definitions (CRDs) for defining CI/CD pipelines that are portable across Kubernetes distributions. Note Because Red Hat OpenShift Pipelines releases on a different cadence from OpenShift Container Platform, the Red Hat OpenShift Pipelines documentation is now available as separate documentation sets for each minor version of the product. The Red Hat OpenShift Pipelines documentation is available at https://docs.openshift.com/pipelines/ . Documentation for specific versions is available using the version selector drop-down list, or directly by adding the version to the URL, for example, https://docs.openshift.com/pipelines/1.11 . In addition, the Red Hat OpenShift Pipelines documentation is also available on the Red Hat Customer Portal at https://access.redhat.com/documentation/en-us/red_hat_openshift_pipelines/ . For additional information about the Red Hat OpenShift Pipelines life cycle and supported platforms, refer to the Platform Life Cycle Policy .

Commands:
C.3. Creating Encrypted Block Devices in Anaconda You can create encrypted devices during system installation. This allows you to easily configure a system with encrypted partitions. To enable block device encryption, check the "Encrypt System" checkbox when selecting automatic partitioning or the "Encrypt" checkbox when creating an individual partition, software RAID array, or logical volume. After you finish partitioning, you will be prompted for an encryption passphrase. This passphrase will be required to access the encrypted devices. If you have pre-existing LUKS devices and provided correct passphrases for them earlier in the install process the passphrase entry dialog will also contain a checkbox. Checking this checkbox indicates that you would like the new passphrase to be added to an available slot in each of the pre-existing encrypted block devices. Note Checking the "Encrypt System" checkbox on the "Automatic Partitioning" screen and then choosing "Create custom layout" does not cause any block devices to be encrypted automatically. Note You can use kickstart to set a separate passphrase for each new encrypted block device. C.3.1. What Kinds of Block Devices Can Be Encrypted? Most types of block devices can be encrypted using LUKS. From anaconda you can encrypt partitions, LVM physical volumes, LVM logical volumes, and software RAID arrays.

Commands:
7.20. ccid 7.20.1. RHSA-2013:0523 - Low: ccid security and bug fix update An updated ccid package that fixes one security issue and one bug are now available for Red Hat Enterprise Linux 6. The Red Hat Security Response Team has rated this update as having low security impact. A 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. Chip/Smart Card Interface Devices (CCID) is a USB smart card reader standard followed by most modern smart card readers. The ccid package provides a Generic, USB-based CCID driver for readers, which follow this standard. Security Fix CVE-2010-4530 An integer overflow, leading to an array index error, was found in the way the CCID driver processed a smart card's serial number. A local attacker could use this flaw to execute arbitrary code with the privileges of the user running the PC/SC Lite pcscd daemon (root, by default), by inserting a specially-crafted smart card. Bug Fix BZ#808115 Previously, CCID only recognized smart cards with 5V power supply. With this update, CCID also supports smart cards with different power supply. All users of ccid are advised to upgrade to this updated package, which contains backported patches to correct these issues.

Commands:
A. Revision History Revision History Revision 1-4 Wed Feb 25 2015 Laura Bailey Rebuild for sort order. Revision 1-3.7 Wed Jan 22 2014 Eliska Slobodova Added the missing eCryptfs Technology Preview. Revision 1-3.5 Mon Jun 17 2013 Eliska Slobodova Fixed broken links and links pointing to the old Product Documentation site. Revision 1-3.3 Thu Dec 13 2012 Martin Prpic Added a note about removal of multilib Python packages. Revision 1-3.1 Wed May 20 2012 Martin Prpic Republished Technical Notes to update list of included advisories. For more information, refer to the Important note in the Package Updates chapter of this book. Revision 1-2 Mon May 23 2011 Ryan Lerch Updated Technology Previews section, Removed references to 'Beta' and Updated the XFS on High Availability Technology Preview note. Revision 1-1 Thu May 19 2011 Ryan Lerch Initial Release of the Red Hat Enterprise Linux 6.1 Technical Notes

Commands:
Chapter 1. Introduction to undercloud and control plane back up and restore The Undercloud and Control Plane Back Up and Restore procedure provides steps for backing up the state of the Red Hat OpenStack Platform 16.0 undercloud and overcloud Controller nodes, hereinafter referred to as control plane nodes, before updates and upgrades. Use the procedure to restore the undercloud and the overcloud control plane nodes to their state if an error occurs during an update or upgrade. 1.1. Background The Undercloud and Control Plane Back Up and Restore procedure uses the open source Relax and Recover (ReaR) disaster recovery solution, written in Bash. ReaR creates a bootable image consisting of the latest state of an undercloud or a Control Plane node. ReaR also enables a system administrator to select files for backup. ReaR supports numerous boot media formats, including: ISO USB eSATA PXE The examples in this document were tested using the ISO boot format. ReaR can transport the boot images using multiple protocols, including: HTTP/HTTPS SSH/SCP FTP/SFTP NFS CIFS (SMB) For the purposes of backing up and restoring the Red Hat OpenStack Platform 16.0 undercloud and overcloud Control Plane nodes, the examples in this document were tested using NFS. 1.2. Backup management options ReaR can use both internal and external backup management options. Internal backup management Internal backup options include: tar rsync External backup management External backup management options include both open source and proprietary solutions. Open source solutions include: Bacula Bareos Proprietary solutions include: EMC NetWorker (Legato) HP DataProtector IBM Tivoli Storage Manager (TSM) Symantec NetBackup

Commands:
10.4.3. Problems with the X Window System (GUI) If you are having trouble getting X (the X Window System) to start, you may not have installed it during your installation. If you want X, you can either install the packages from the Red Hat Enterprise Linux installation media or perform an upgrade. If you elect to upgrade, select the X Window System packages, and choose GNOME, KDE, or both, during the upgrade package selection process. Refer to Section 35.3, "Switching to a Graphical Login" for more detail on installing a desktop environment.

Commands:
4.171. man-pages-ja 4.171.1. RHBA-2011:0962 - man-pages-ja bug fix update An updated man-pages-ja package that fixes multiple bugs is now available for Red Hat Enterprise Linux 6. The man-pages-ja package contains Japanese translations of the Linux Documentation Project man pages. Bug Fixes BZ# 579641 Prior to this update, the man-pages-ja package did not contain the Japanese translations of the man pages of the "halt", "init", "poweroff", "reboot", "runlevel", "shutdown", and "telinit" commands. With this update, the aforementioned man page translations have been added. BZ# 682122 Prior to this update, the Japanese translation of the getpriority(2) man page contained a typo in the range of "nice values". This update corrects the typo. BZ# 699301 Prior to this update, the Japanese translation of the wall(1) man page contained a typo in the description of the message length limit. This update corrects the typo. BZ# 710704 Prior to this update, the Japanese translation of the tar(1) man page did not contain descriptions of the "--selinux" and "--no-selinux" options. With this update, the missing descriptions have been added. All users of man-pages-ja are advised to upgrade to this updated package, which fixes these bugs.

Commands:
Chapter 8. Using a Red Hat Image Builder Image for Provisioning In Satellite, you can integrate with RHEL web console to perform actions and monitor your hosts. Using RHEL web console, you can access Red Hat Image Builder and build images that you can then upload to a HTTP server and use this image to provision hosts. When you configure Satellite for image provisioning, Anaconda installer partitions disks, downloads and mounts the image and copies files over to a host. The preferred image type is TAR. Note The blueprint to build the TAR image must always include a kernel package. For more information about integrating RHEL web console with Satellite, see Host Management and Monitoring Using RHEL web console in the Managing Hosts guide. Prerequisite An existing TAR image created using Red Hat Image Builder. Procedure On Satellite, create a custom product, add a custom file repository to this product, and upload the image to the repository. For more information, see Importing Individual ISO Images and Files in the Content Management Guide . In the Satellite web UI, navigate to Configure > Host Groups , and select the host group that you want to use. Click the Parameters tab, and then click Add Parameter . In the Name field, enter kickstart_liveimg . From the Type list, select string . In the Value field, enter the absolute path or a relative path in the following format custom/ product / repository / image_name that points to the exact location where you store the image. Click Submit to save your changes. You can use this image for bare metal provisioning and provisioning using a compute resource. For more information about bare metal provisioning, see Chapter 6, Using PXE to Provision Hosts . For more information about provisioning with different compute resources, see the relevant chapter for the compute resource that you want to use.

Commands: