mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 2. Preparing the backup node Before you back up the undercloud or control plane nodes, prepare the backup node to accept the backup images. 2.1. Preparing the NFS server ReaR can use multiple transport methods. Red Hat supports back up and restore with ReaR using NFS. Install the NFS server on the backup node. Add the NFS service to the firewall to ensure ports 111 and 2049 are open. For example: Enable the NFS server and start it. 2.2. Creating and exporting the backup directory To copy backup ISO images from the undercloud or control plane nodes to the backup node, you must create a backup directory. Prerequisites You installed and enabled the NFS server. For more information, see Preparing the NFS server . Procedure Create the backup directory: Export the directory. Replace <ip-addr>/24 with the IP address and subnet mask of the network: The entries in the /etc/exports file are in a space-delimited list. If the undercloud and the overcloud control plane nodes use different networks or subnets, repeat this step for each network or subnet, as shown in this example: Restart the NFS server: Verify that the entries are correctly configured in the NFS server:

Commands:
dnf install -y nfs-utils
firewall-cmd --add-service=nfs firewall-cmd --add-service=nfs --permanent
systemctl enable nfs-server systemctl restart nfs-server
mkdir /ctl_plane_backups
cat >> /etc/exports << EOF /ctl_plane_backups <ip-addr>/24(rw,sync,no_root_squash,no_subtree_check) EOF
cat >> /etc/exports << EOF /ctl_plane_backups 192.168.24.0/24(rw,sync,no_root_squash,no_subtree_check) /ctl_plane_backups 10.0.0.0/24(rw,sync,no_root_squash,no_subtree_check) /ctl_plane_backups 172.16.0.0/24(rw,sync,no_root_squash,no_subtree_check) EOF
systemctl restart nfs-server
showmount -e `hostname`
2.2.2. Namespace Probe alias names should take the form tapset_name.probe_name . For example, the probe for sending a signal could be named signal.send . Global symbol names (probes, functions, and variables) should be unique accross all tapsets. This helps avoid namespace collisions in scripts that use multiple tapsets. To ensure this, use tapset-specific prefixes in your global symbols. Internal symbol names should be prefixed with an underscore ( _ ).

Commands:
Chapter 2. How Instance HA Works OpenStack uses Instance HA to automate the process of evacuating instances from a Compute node when that node fails. The following procedure describes the sequence of events that are triggered when a Compute node fails. At the time of failure, the IPMI agent performs first-layer fencing and physically resets the node to ensure that it is powered off. Evacuating instances from online Compute nodes might result in data corruption or in multiple identical instances running on the overcloud. When the node is powered off, it is considered fenced . After the physical IPMI fencing, the fence-nova agent performs second-layer fencing and marks the fenced node with the "evacuate=yes" cluster per-node attribute. To do this, the agent runs the following command: Where FAILEDHOST is the hostname of the failed Compute node. The nova-evacuate agent continually runs in the background, periodically checking the cluster for nodes with the "evacuate=yes" attribute. When nova-evacuate detects that the fenced node contains this attribute, the agent starts evacuating the node using the process described in Evacuate Instances . While the failed node boots up from the IPMI reset, the nova-compute process on that node starts automatically. Because the node was fenced earlier, it does not run any new instances until Pacemaker unfences it. When Pacemaker sees that the Compute node is online again, it tries to start the compute-unfence-trigger resource on the node, reverting the force-down API call and setting the node as enabled again. 2.1. Designating specific instances to be evacuated By default, all instances are to be evacuated, but it is also possible to tag images or flavors for evacuation. To tag an image: To tag a flavor:

Commands:
attrd_updater -n evacuate -A name="evacuate" host=" FAILEDHOST " value="yes"
openstack image set --tag evacuable ID-OF-THE-IMAGE
nova flavor-key ID-OF-THE-FLAVOR set evacuable=true
Chapter 10. Configuring trusted certificates When Red Hat build of Keycloak communicates with external services or has an incoming connection through TLS, it has to validate the remote certificate in order to ensure it is connecting to a trusted server. This is necessary in order to prevent man-in-the-middle attacks. The certificates of these clients or servers, or the CA that signed these certificates, must be put in a truststore. This truststore is then configured for use by Red Hat build of Keycloak. 10.1. Configuring the System Truststore The existing Java default truststore certs will always be trusted. If you need additional certificates, which will be the case if you have self-signed or internal certificate authorities that are not recognized by the JRE, they can be included in the conf/truststores directory or subdirectories. The certs may be in PEM files, or PKCS12 files with extension .p12 or .pfx . If in PKCS12, the certs must be unencrypted - meaning no password is expected. If you need an alternative path, use the --truststore-paths option to specify additional files or directories where PEM or PKCS12 files are located. Paths are relative to where you launched Red Hat build of Keycloak, so absolute paths are recommended instead. If a directory is specified, it will be recursively scanned for truststore files. After all applicable certs are included, the truststore will be used as the system default truststore via the javax.net.ssl properties, and as the default for internal usage within Red Hat build of Keycloak. For example: bin/kc.[sh|bat] start --truststore-paths=/opt/truststore/myTrustStore.pfx,/opt/other-truststore/myOtherTrustStore.pem It is still possible to directly set your own javax.net.ssl truststore System properties, but it's recommended to use the --truststore-paths instead. 10.2. Hostname Verification Policy You may refine how hostnames are verified by TLS connections with the tls-hostname-verifier property. WILDCARD (the default) allows wildcards in subdomain names, such as *.foo.com. ANY means that the hostname is not verified. When using STRICT , the Common Name (CN) must match the hostname exactly. Please note that this setting does not apply to LDAP secure connections, which require strict hostname checking. 10.3. Relevant options Value tls-hostname-verifier The TLS hostname verification policy for out-going HTTPS and SMTP requests. CLI: --tls-hostname-verifier Env: KC_TLS_HOSTNAME_VERIFIER ANY , WILDCARD (default), STRICT truststore-paths List of pkcs12 (p12 or pfx file extensions), PEM files, or directories containing those files that will be used as a system truststore. CLI: --truststore-paths Env: KC_TRUSTSTORE_PATHS

Commands:
bin/kc.[sh|bat] start --truststore-paths=/opt/truststore/myTrustStore.pfx,/opt/other-truststore/myOtherTrustStore.pem
Updating Red Hat Enterprise Linux AI 1.4 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 registry.redhat.io/rhelai1/bootc-<hardware-vendor>-rhel9:<rhel-ai-version>
sudo bootc switch registry.redhat.io/rhelai1/bootc-nvidia-rhel9:1.4
sudo reboot -n
cp /etc/skel/.config/containers/storage.conf <user-home>/.config/containers/storage.con
sudo bootc upgrade --apply
ilab config init
ilab model download --repository <repository_and_model> --release latest
ilab model list
Chapter 28. Using the sudo system role As an administrator, you can consistently configure the /etc/sudoers files on multiple systems by using the sudo RHEL system role. 28.1. Applying custom sudoers configuration by using RHEL system roles You can use the sudo RHEL system role to apply custom sudoers configuration on your managed nodes. That way, you can define which users can run which commands on which hosts, with better configuration efficiency and more granular control. Prerequisites You have prepared the control node and the managed nodes . You are logged in to the control node as a user who can run playbooks on the managed nodes. The account you use to connect to the managed nodes has sudo permissions on them. Procedure Create a playbook file, for example ~/playbook.yml , with the following content: --- - name: "Configure sudo" hosts: managed-node-01.example.com tasks: - name: "Apply custom /etc/sudoers configuration" ansible.builtin.include_role: name: rhel-system-roles.sudo vars: sudo_sudoers_files: - path: "/etc/sudoers" user_specifications: - users: - <user_name> hosts: - <host_name> commands: - <path_to_command_binary> The settings specified in the playbook include the following: users The list of users that the rule applies to. hosts The list of hosts that the rule applies to. You can use ALL for all hosts. commands The list of commands that the rule applies to. You can use ALL for all commands. For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.sudo/README.md file on the control node. Validate the playbook syntax: Note that this command only validates the syntax and does not protect against a wrong but valid configuration. Run the playbook: Verification On the managed node, verify that the playbook applied the new rules. Additional resources /usr/share/ansible/roles/rhel-system-roles.sudo/README.md file /usr/share/doc/rhel-system-roles.sudo/sudo/ directory

Commands:
--- - name: "Configure sudo" hosts: managed-node-01.example.com tasks: - name: "Apply custom /etc/sudoers configuration" ansible.builtin.include_role: name: rhel-system-roles.sudo vars: sudo_sudoers_files: - path: "/etc/sudoers" user_specifications: - users: - <user_name> hosts: - <host_name> commands: - <path_to_command_binary>
ansible-playbook --syntax-check ~/playbook.yml
ansible-playbook ~/playbook.yml
cat /etc/sudoers | tail -n1 <user_name> <host_name> = <path_to_command_binary>
4.206. openoffice.org 4.206.1. RHSA-2012:0705 - Important: openoffice.org security update Updated openoffice.org packages that fix multiple security issues are now available for Red Hat Enterprise Linux 5 and 6. The Red Hat Security Response Team has rated this update as having important security impact. Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) associated with each description below. OpenOffice.org is an office productivity suite that includes desktop applications, such as a word processor, spreadsheet application, presentation manager, formula editor, and a drawing program. Security Fixes CVE-2012-2334 An integer overflow flaw, leading to a buffer overflow, was found in the way OpenOffice.org processed an invalid Escher graphics records length in Microsoft Office PowerPoint documents. An attacker could provide a specially-crafted Microsoft Office PowerPoint document that, when opened, would cause OpenOffice.org to crash or, potentially, execute arbitrary code with the privileges of the user running OpenOffice.org. CVE-2012-1149 Multiple integer overflow flaws, leading to heap-based buffer overflows, were found in the JPEG, PNG, and BMP image file reader implementations in OpenOffice.org. An attacker could provide a specially-crafted JPEG, PNG, or BMP image file that, when opened in an OpenOffice.org application, would cause the application to crash or, potentially, execute arbitrary code with the privileges of the user running the application. Upstream acknowledges Sven Jacobi as the original reporter of CVE-2012-2334 , and Tielei Wang via Secunia SVCRP as the original reporter of CVE-2012-1149 . All OpenOffice.org users are advised to upgrade to these updated packages, which contain backported patches to correct these issues. All running instances of OpenOffice.org applications must be restarted for this update to take effect.

Commands:
8.248. tzdata 8.248.1. RHEA-2014:1621 - tzdata enhancement update Updated tzdata packages that add one enhancement are now available for Red Hat Enterprise Linux 6. The tzdata packages contain data files with rules for various time zones. Enhancement BZ# 1147318 This update contains the changes implemented in tzdata-2014h that are all related to historical transition times. In particular, transition to standard time in Asia/Novokuznetsk on Jan 5 1920 actually took place on Apr 30 1924, transition to saving time in Jamaica took place not on Apr 28 1974, but already on Jan 6. In addition, a number of African zones (Africa/Blantyre, Bujumbura, Gaborone, Harare, Kigali, Lubumbashi, and Lusaka) have been merged with Africa/Maputo, because their transition times do not differ in post-1970 era. Africa/Maseru and Africa/Mbabane have now been merged to Africa/Johannesburg for the same reason. Users of tzdata are advised to upgrade to these updated packages, which add this enhancement.

Commands:
9.7.2. The exportfs Command Every file system being exported to remote users with NFS, as well as the access level for those file systems, are listed in the /etc/exports file. When the nfs service starts, the /usr/sbin/exportfs command launches and reads this file, passes control to rpc.mountd (if NFSv2 or NFSv3) for the actual mounting process, then to rpc.nfsd where the file systems are then available to remote users. When issued manually, the /usr/sbin/exportfs command allows the root user to selectively export or unexport directories without restarting the NFS service. When given the proper options, the /usr/sbin/exportfs command writes the exported file systems to /var/lib/nfs/etab . Since rpc.mountd refers to the etab file when deciding access privileges to a file system, changes to the list of exported file systems take effect immediately. The following is a list of commonly-used options available for /usr/sbin/exportfs : -r Causes all directories listed in /etc/exports to be exported by constructing a new export list in /etc/lib/nfs/etab . This option effectively refreshes the export list with any changes made to /etc/exports . -a Causes all directories to be exported or unexported, depending on what other options are passed to /usr/sbin/exportfs . If no other options are specified, /usr/sbin/exportfs exports all file systems specified in /etc/exports . -o file-systems Specifies directories to be exported that are not listed in /etc/exports . Replace file-systems with additional file systems to be exported. These file systems must be formatted in the same way they are specified in /etc/exports . This option is often used to test an exported file system before adding it permanently to the list of file systems to be exported. Refer to Section 9.7.1, "The /etc/exports Configuration File" for more information on /etc/exports syntax. -i Ignores /etc/exports ; only options given from the command line are used to define exported file systems. -u Unexports all shared directories. The command /usr/sbin/exportfs -ua suspends NFS file sharing while keeping all NFS daemons up. To re-enable NFS sharing, use exportfs -r . -v Verbose operation, where the file systems being exported or unexported are displayed in greater detail when the exportfs command is executed. If no options are passed to the exportfs command, it displays a list of currently exported file systems. For more information about the exportfs command, refer to man exportfs . 9.7.2.1. Using exportfs with NFSv4 In Red Hat Enterprise Linux 6, no extra steps are required to configure NFSv4 exports as any filesystems mentioned are automatically available to NFSv2, NFSv3, and NFSv4 clients using the same path. This was not the case in versions. To prevent clients from using NFSv4, turn it off by sellecting RPCNFSDARGS= -N 4 in /etc/sysconfig/nfs .

Commands:
4.6. PHP PHP changes are listed below: PHP has been upgraded to version 5.3. Compatibility issues require some scripts to be updated. For further details, refer to the following URLs: http://php.net/manual/migration52.php http://php.net/manual/migration53.php The following changes have been made to the default configuration ( /etc/php.ini ): error_reporting is now set to E_ALL & ~E_DEPRECATED (previously E_ALL ) short_open_tag is now set to Off (previously On ) variables_order is now set to GPCS (previously EGPCS ) enable_dl is now to set to Off (previously On ) The mime_magic , dbase , and ncurses extensions are no longer distributed.

Commands:
F.6. Search Menu The Search menu presents several specific search options. Figure F.7. Search Menu Teiid Designer contributes a submenu (i.e. Teiid Designer > ) to the main search menu, as shown above. Figure F.8. Search Menu The individual actions in the Teiid Designer submenu are described below: Transformations... - Launches the Transformation Search dialog. User can search models in the workspace for matching SQL text. Search results appear in the dialog and user can select and view SQL as well as open desired transformations for editing. Metadata... - Launches the Search dialog. User can search for models in the workspace by specifying an Object Type, and/or a Data Type, and/or a property value. Search results appear in the Search Results view, and double-clicking a result will open that model in the appropriate editor. Find Model Object - Launches the Find Model Object dialog, which can be used to find an object in the workspace by specifying all or part of its name. Selecting the object will open it in the appropriate editor.

Commands:
H.3. Virtualization Host User Accounts A number of system user accounts are created on the virtualization host when the vdsm and qemu-kvm-rhev packages are installed. Each system user has a default user identifier (UID). The system user accounts created are: The vdsm user (UID 36 ). The qemu user (UID 107 ). The sanlock user (UID 179 ). The ovirt-vmconsole user (UID 498 ). Important The user identifiers (UIDs) and group identifiers (GIDs) allocated may vary between systems. The vdsm user is fixed to a UID of 36 and the kvm group is fixed to a GID of 36 . If UID 36 or GID 36 is already used by another account on the system a conflict will arise during installation of the vdsm and qemu-kvm-rhev packages.

Commands: