mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 4. Deploying NFS-Ganesha on Red Hat Gluster Storage NFS-Ganesha can be installed using any of the following methods: Installing NFS-Ganesha using yum Installing NFS-Ganesha during an ISO Installation Warning Gluster-NFS is considered deprecated as of Red Hat Gluster Storage 3.5. Red Hat no longer recommends the use of Gluster-NFS, and does not support its use in new deployments and existing deployments that upgrade to Red Hat Gluster Storage 3.5.3. You can use NFS-Ganesha as an alternative. 4.1. Prerequisites To install NFS-Ganesha on Red Hat Gluster Storage you require access to the installation media either through an ISO or a properly configured software repository. For Red Hat Gluster Storage 3.5 on Red Hat Enterprise Linux 8.2 and later Enable the channel where the NFS-Ganesha packages are available: If you have registered your machine using Red Hat Subscription Manager, enable the repository by running the following command: To add the HA repository, execute the following command: If you have registered your machine using Satellite server, enable the channel by running the following command: To subscribe to the HA channel, execute the following command: For Red Hat Gluster Storage 3.5 on Red Hat Enterprise Linux 7.7 and later Enable the channel where the NFS-Ganesha packages are available: If you have registered your machine using Red Hat Subscription Manager, enable the repository by running the following command: To add the HA repository, execute the following command: If you have registered your machine using Satellite server, enable the channel by running the following command: To subscribe to the HA channel, execute the following command:

Commands:
subscription-manager repos --enable=rh-gluster-3-nfs-for-rhel-8-x86_64-rpms
subscription-manager repos --enable=rhel-8-for-x86_64-highavailability-rpms
rhn-channel --add --channel rh-gluster-3-nfs-for-rhel-8-x86_64-rpms
rhn-channel --add --channel rhel-8-for-x86_64-highavailability-rpms
subscription-manager repos --enable=rh-gluster-3-nfs-for-rhel-7-server-rpms
subscription-manager repos --enable=rhel-ha-for-rhel-7-server-rpms
rhn-channel --add --channel rhel-x86_64-server-7-rh-gluster-3-nfs
rhn-channel --add --channel rhel-x86_64-server-ha-7
16.4.2. Modifying Files with guestfish To modify files, create directories or make other changes to a guest virtual machine, first heed the warning at the beginning of this section: your guest virtual machine must be shut down . Editing or changing a running disk with guestfish will result in disk corruption. This section gives an example of editing the /boot/grub/grub.conf file. When you are sure the guest virtual machine is shut down you can omit the --ro option in order to get write access via a command such as: Commands to edit files include edit , vi and emacs . Many commands also exist for creating files and directories, such as write , mkdir , upload and tar-in .

Commands:
guestfish -d RHEL3 -i Welcome to guestfish, the libguestfs filesystem interactive shell for editing virtual machine filesystems. Type: 'help' for help on commands 'man' to read the manual 'quit' to quit the shell Operating system: Red Hat Enterprise Linux AS release 3 (Taroon Update 9) /dev/vda2 mounted on / /dev/vda1 mounted on /boot ><fs> edit /boot/grub/grub.conf
7.48. enchant 7.48.1. RHBA-2015:0668 - enchant bug fix update Updated enchant packages that fix one bug are now available for Red Hat Enterprise Linux 6. The enchant packages contain a library that wraps other spell-checking back ends. Bug Fix BZ# 1015310 Previously, the enchant library opened the user's custom dictionary file in write mode. Consequently, the content of the file was always erased, and any words added to the dictionary earlier were forgotten. With this update, the dictionary file is opened in append mode. As a result, new additions to the custom dictionary no longer delete previously saved words. Users of enchant are advised to upgrade to these updated packages, which fix this bug.

Commands:
9.13. Registering Custom Mapper and Publisher Plug-in Modules New mapper or publisher plug-in modules can be registered in a Certificate Manager's publishing framework. Unwanted mapper or publisher plug-in modules can be deleted. Before deleting a module, delete all the rules that are based on this module. Create the custom job class. For this example, the custom publisher plug-in is called MyPublisher.java . Compile the new class. Create a directory in the CA's WEB-INF web directory to hold the custom classes, so that the CA can access them. Copy the new plug-in files into the new classes directory, and set the owner to the Certificate System system user ( pkiuser ). Register the plug-in. Log into the Certificate Manager Console. In the Configuration tab, select Certificate Manager from the navigation tree on the left. Select Publishing . To register a mapper module, select Mappers , and then select the Mapper Plugin Registration tab. To register a publisher module, select Publishers , and then select the Publisher Plug-in Registration tab. To register a plug-in, click Register . Set the plug-in name and plug-in class name. The class name is, the path to the implementing Java class. If this class is part of a package, include the package name. For example, to register a class named customMapper in a package named com.customplugins , the name is com.customplugins.customMapper . Note pkiconsole is being deprecated.

Commands:
javac -d . -classpath USDCLASSPATH MyPublisher.java
mkdir /var/lib/pki/ instance_name /ca/webapps/ca/WEB-INF/classes
cp -pr com /var/lib/pki/ instance_name /ca/webapps/ca/WEB-INF/classes chown -R pkiuser:pkiuser /var/lib/pki/ instance_name /ca/webapps/ca/WEB-INF/classes
pkiconsole https://server.example.com:8443/ca
9.4. Configuring Authentication and Role Mapping using JBoss EAP Login Modules When using Red Hat JBoss EAP log in module for querying roles from LDAP, you must implement your own mapping of Principals to Roles, as JBoss EAP uses its own custom classes. The following example demonstrates how to map a principal obtained from JBoss EAP login module to a role. It maps user principal name to a role, performing a similar action to the IdentityRoleMapper : Example 9.1. Mapping a Principal from JBoss EAP's Login Module Example 9.2. Example of JBoss EAP LDAP login module configuration Example 9.3. Example of JBoss EAP Login Module Configuration When using GSSAPI authentication, this would typically involve using LDAP for role mapping, with JBoss EAP server authenticating itself to the LDAP server via GSSAPI. For more information on how to configure this, see the JBoss EAP Administration and Configuration Guide . Important For information about how to configure JBoss EAP login modules, see the JBoss EAP Administration and Configuration Guide and see the Red Hat Directory Server Administration Guide how to configure LDAP server, and specify users and their role mapping. Report a bug

Commands:
public class SimplePrincipalGroupRoleMapper implements PrincipalRoleMapper { @Override public Set<String> principalToRoles(Principal principal) { if (principal instanceof SimpleGroup) { Enumeration<Principal> members = ((SimpleGroup) principal).members(); if (members.hasMoreElements()) { Set<String> roles = new HashSet<String>(); while (members.hasMoreElements()) { Principal innerPrincipal = members.nextElement(); if (innerPrincipal instanceof SimplePrincipal) { SimplePrincipal sp = (SimplePrincipal) innerPrincipal; roles.add(sp.getName()); } } return roles; } } return null; } }
<security-domain name="ispn-secure" cache-type="default"> <authentication> <login-module code="org.jboss.security.auth.spi.LdapLoginModule" flag="required"> <module-option name="java.naming.factory.initial" value="com.sun.jndi.ldap.LdapCtxFactory"/> <module-option name="java.naming.provider.url" value="ldap://localhost:389"/> <module-option name="java.naming.security.authentication" value="simple"/> <module-option name="principalDNPrefix" value="uid="/> <module-option name="principalDNSuffix" value=",ou=People,dc=infinispan,dc=org"/> <module-option name="rolesCtxDN" value="ou=Roles,dc=infinispan,dc=org"/> <module-option name="uidAttributeID" value="member"/> <module-option name="matchOnUserDN" value="true"/> <module-option name="roleAttributeID" value="cn"/> <module-option name="roleAttributeIsDN" value="false"/> <module-option name="searchScope" value="ONELEVEL_SCOPE"/> </login-module> </authentication> </security-domain>
<security-domain name="krb-admin" cache-type="default"> <authentication> <login-module code="Kerberos" flag="required"> <module-option name="useKeyTab" value="true"/> <module-option name="principal" value="admin@INFINISPAN.ORG"/> <module-option name="keyTab" value="USD{basedir}/keytab/admin.keytab"/> </login-module> </authentication> </security-domain>
Chapter 6. Registering Virtual Machines to use a Host-based Subscription Use an auto-attach activation key to register virtual machines so that they inherit a subscription from their hypervisor. For more information about activation keys, see Managing Activation Keys in Managing Content . Prerequisites Create an activation key with auto-attach enabled and no subscriptions attached. Attach a host-based subscription to the virtual machine's hypervisor. Create and deploy a virt-who configuration that queries the virtual machine's hypervisor. Procedure Configure the virtual machine to register with Satellite Server: Register the virtual machine using the auto-attach activation key: The virtual machine receives a temporary subscription while Satellite Server waits for virt-who to provide information about which hypervisor the virtual machine is running on. After virt-who provides this information, Satellite Server attaches a permanent subscription to the virtual machine. If the virtual machine migrates to another hypervisor that reports to virt-who and has a host-based subscription attached, the virtual machine inherits a subscription from that hypervisor. If the hypervisor does not have a host-based subscription attached, Satellite Server automatically attaches a host-based subscription to the hypervisor, and the virtual machine inherits that subscription. If the virtual machine migrates to another hypervisor that does not report to virt-who, or there are insufficient subscriptions available to attach to the hypervisor, the virtual machine cannot inherit a subscription. To avoid this, either ensure that all hypervisors the virtual machine can migrate to have host-based subscriptions attached and report to virt-who, or limit the virtual machine's migration to specific hypervisors.

Commands:
yum install http:// satellite.example.com /pub/katello-ca-consumer-latest.noarch.rpm
subscription-manager register --org= organization_label --activationkey= activation_key_name
Chapter 12. Updating and upgrading the Load-balancing service Perform regular updates and upgrades so that you can use the latest Red Hat OpenStack Platform Load-balancing service features, and avoid possible lengthy and problematic issues caused by infrequent updates and upgrades. Section 12.1, "Updating and upgrading the Load-balancing service" Section 12.2, "Updating running Load-balancing service instances" 12.1. Updating and upgrading the Load-balancing service The Load-balancing service (octavia) is a part of a Red Hat OpenStack Platform (RHOSP) update or upgrade. Prerequisites Schedule a maintenance window to perform the upgrade, because during the upgrade the Load-balancing service control plane is not fully functional. Procedure Perform the RHOSP update as described in the Keeping Red Hat OpenStack Platform Updated guide. After the maintenance release is applied, if you need to use new features, then rotate running amphorae to update them to the latest amphora image. Additional resources Keeping Red Hat OpenStack Platform Updated guide Section 12.2, "Updating running Load-balancing service instances" Section 2.2, "Load-balancing service (octavia) feature support matrix" 12.2. Updating running Load-balancing service instances Periodically, you can update a running Load-balancing service instance (amphora) with a newer image. For example, you might want to update an amphora instance during the following events: An update or upgrade of Red Hat OpenStack Platform (RHOSP). A security update to your system. A change to a different flavor for the underlying virtual machine. During an RHOSP update or upgrade, director automatically downloads the default amphora image, uploads it to the overcloud Image service (glance), and then configures the Load-balancing service (octavia) to use the new image. When you fail over a load balancer, you force the Load-balancing service to start an instance (amphora) that uses the new amphora image. Prerequisites New images for amphora. These are available during an RHOSP update or upgrade. Procedure Source your credentials file. Example List the IDs for all of the load balancers that you want to update: Fail over each load balancer: Note When you start failing over the load balancers, monitor system utilization, and as needed, adjust the rate at which you perform failovers. A load balancer failover creates new virtual machines and ports, which might temporarily increase the load on OpenStack Networking. Monitor the state of the failed over load balancer: The update is complete when the load balancer status is ACTIVE . Additional resources loadbalancer in the Command Line Interface Reference

Commands:
source ~/overcloudrc
openstack loadbalancer list -c id -f value
openstack loadbalancer failover <loadbalancer_id>
openstack loadbalancer show <loadbalancer_id>
Chapter 2. Red Hat Enterprise Linux AI product architecture Red Hat Enterprise Linux AI contains various distinct features and consists of the following components. 2.1. Bootable Red Hat Enterprise Linux with InstructLab You can install RHEL AI and deploy the InstructLab tooling using a bootable RHEL container image provided by Red Hat. This RHEL AI image includes InstructLab, RHEL 9.4, and various inference and training software, including vLLM and DeepSpeed. After you boot this image, you can download various Red Hat and IBM developed Granite models to serve or train. The image and all the tools are compiled to specific Independent Software Vendors (ISV) hardware. For more information about the architecture of the image, see Installation overview . 2.1.1. InstructLab model alignment The Red Hat Enterprise Linux AI bootable image contains InstructLab and its tooling. InstructLab uses a novel approach to LLM fine-tuning called LAB (Large-Scale Alignment for ChatBots). The LAB method uses a taxonomy-based system that implements high-quality synthetic data generation (SDG) and multi-phase training. Using the RHEL AI command line interface (CLI), which is built from the InstructLab CLI, you can create your own custom LLM by tuning a Granite base model on synthetic data generated from your own domain-specific knowledge. For general availability, the RHEL AI LLMs customization workflow consists of the following steps: Installing and initializing RHEL AI on your preferred platform. Using a CLI and Git workflow for adding skills and knowledge to your taxonomy tree. Running synthetic data generation (SDG) using the mixtral-8x7B-Instruct teacher model. SDG can generate hundreds or thousands of synthetic question-and-answer pairs for model tuning based on user-provided specific samples. Using the InstructLab to train the base model with the new synthetically generated data. The prometheus-8x7B-V2.0 judge model evaluates the performance of the newly trained model. Using InstructLab with vLLM to serve the new custom model for inferencing. 2.1.2. Open source licensed Granite models With RHEL AI, you can download the open source licensed IBM Granite family of LLMs. Using the starter Granite model as a base, you can create your model using knowledge or skills data. You can keep these custom LLMs private or you can share them with the AI community. Red Hat Enterprise Linux AI also allows you to serve and chat with Granite models created and fine-tuned by Red Hat and IBM.

Commands:
Chapter 8. Preparing a system with UEFI Secure Boot enabled to install and boot RHEL beta releases To enhance the security of your operating system, use the UEFI Secure Boot feature for signature verification when booting a Red Hat Enterprise Linux Beta release on systems having UEFI Secure Boot enabled. 8.1. UEFI Secure Boot and RHEL Beta releases UEFI Secure Boot requires that the operating system kernel is signed with a recognized private key. UEFI Secure Boot then verifies the signature using the corresponding public key. For Red Hat Enterprise Linux Beta releases, the kernel is signed with a Red Hat Beta-specific private key. UEFI Secure Boot attempts to verify the signature using the corresponding public key, but because the hardware does not recognize the Beta private key, Red Hat Enterprise Linux Beta release system fails to boot. Therefore, to use UEFI Secure Boot with a Beta release, add the Red Hat Beta public key to your system using the Machine Owner Key (MOK) facility. 8.2. Adding a Beta public key for UEFI Secure Boot This section contains information about how to add a Red Hat Enterprise Linux Beta public key for UEFI Secure Boot. Prerequisites The UEFI Secure Boot is disabled on the system. The Red Hat Enterprise Linux Beta release is installed, and Secure Boot is disabled even after system reboot. You are logged in to the system, and the tasks in the Initial Setup window are complete. Procedure Begin to enroll the Red Hat Beta public key in the system's Machine Owner Key (MOK) list: USD(uname -r) is replaced by the kernel version - for example, 4.18.0-80.el8.x86_64 . Enter a password when prompted. Reboot the system and press any key to continue the startup. The Shim UEFI key management utility starts during the system startup. Select Enroll MOK . Select Continue . Select Yes and enter the password. The key is imported into the system's firmware. Select Reboot . Enable Secure Boot on the system. 8.3. Removing a Beta public key If you plan to remove the Red Hat Enterprise Linux Beta release, and install a Red Hat Enterprise Linux General Availability (GA) release, or a different operating system, then remove the Beta public key. The procedure describes how to remove a Beta public key. Procedure Begin to remove the Red Hat Beta public key from the system's Machine Owner Key (MOK) list: Enter a password when prompted. Reboot the system and press any key to continue the startup. The Shim UEFI key management utility starts during the system startup. Select Reset MOK . Select Continue . Select Yes and enter the password that you had specified in step 2. The key is removed from the system's firmware. Select Reboot .

Commands:
mokutil --import /usr/share/doc/kernel-keys/USD(uname -r)/kernel-signing-ca.cer
mokutil --reset
8.2. Restoring a Virtual Machine Restore a virtual machine that has been backed up using the backup and restore API. This procedure assumes you have a backup virtual machine on which the software used to manage the backup is installed. Procedure 8.2. Restoring a Virtual Machine Attach the disk to the backup virtual machine: Use the backup software to restore the backup to the disk. Detach the disk from the backup virtual machine: Create a new virtual machine using the configuration data of the virtual machine being restored: Attach the disk to the new virtual machine: You have restored a virtual machine using a backup that was created using the backup and restore API .

Commands:
POST /ovirt-engine/api/vms/ 22222222-2222-2222-2222-222222222222 /disks/ HTTP/1.1 Accept: application/xml Content-type: application/xml <disk id=" 11111111-1111-1111-1111-111111111111 "> </disk>
DELETE /ovirt-engine/api/vms/ 22222222-2222-2222-2222-222222222222 /disks/ 11111111-1111-1111-1111-111111111111 HTTP/1.1 Accept: application/xml Content-type: application/xml <action> <detach>true</detach> </action>
POST /ovirt-engine/api/vms/ HTTP/1.1 Accept: application/xml Content-type: application/xml <vm> <cluster> <name>cluster_name</name> </cluster> <name> NAME </name> </vm>
POST /ovirt-engine/api/vms/ 33333333-3333-3333-3333-333333333333 /disks/ HTTP/1.1 Accept: application/xml Content-type: application/xml <disk id=" 11111111-1111-1111-1111-111111111111 "> </disk>
Chapter 48. limits This chapter describes the commands under the limits command. 48.1. limits show Show compute and block storage limits Usage: Table 48.1. Optional Arguments Value Summary -h, --help Show this help message and exit --absolute Show absolute limits --rate Show rate limits --reserved Include reservations count [only valid with --absolute] --project <project> Show limits for a specific project (name or id) [only valid with --absolute] --domain <domain> Domain the project belongs to (name or id) [only valid with --absolute] Table 48.2. Output Formatters Value Summary -f {csv,json,table,value,yaml}, --format {csv,json,table,value,yaml} The output format, defaults to table -c COLUMN, --column COLUMN Specify the column(s) to include, can be repeated --sort-column SORT_COLUMN Specify the column(s) to sort the data (columns specified first have a priority, non-existing columns are ignored), can be repeated Table 48.3. CSV Formatter Value Summary --quote {all,minimal,none,nonnumeric} When to include quotes, defaults to nonnumeric Table 48.4. JSON Formatter Value Summary --noindent Whether to disable indenting the json Table 48.5. Table Formatter Value Summary --max-width <integer> Maximum display width, <1 to disable. you can also use the CLIFF_MAX_TERM_WIDTH environment variable, but the parameter takes precedence. --fit-width Fit the table to the display width. implied if --max- width greater than 0. Set the environment variable CLIFF_FIT_WIDTH=1 to always enable --print-empty Print empty table if there is no data to show.

Commands:
openstack limits show [-h] [-f {csv,json,table,value,yaml}] [-c COLUMN] [--quote {all,minimal,none,nonnumeric}] [--noindent] [--max-width <integer>] [--fit-width] [--print-empty] [--sort-column SORT_COLUMN] (--absolute | --rate) [--reserved] [--project <project>] [--domain <domain>]
B.2. The URI Failed to Connect to the Hypervisor Several different errors can occur when connecting to the server (for example, when running virsh ). B.2.1. Cannot read CA certificate Symptom When running a command, the following error (or similar) appears: Investigation The error message is misleading about the actual cause. This error can be caused by a variety of factors, such as an incorrectly specified URI, or a connection that is not configured. Solution Incorrectly specified URI When specifying qemu://system or qemu://session as a connection URI, virsh attempts to connect to host names system or session respectively. This is because virsh recognizes the text after the second forward slash as the host. Use three forward slashes to connect to the local host. For example, specifying qemu:///system instructs virsh connect to the system instance of libvirtd on the local host. When a host name is specified, the QEMU transport defaults to TLS . This results in certificates. Connection is not configured The URI is correct (for example, qemu[+tls]://server/system ) but the certificates are not set up properly on your machine. For information on configuring TLS, see Setting up libvirt for TLS available from the libvirt website.

Commands:
virsh -c name_of_uri list error: Cannot read CA certificate '/etc/pki/CA/cacert.pem': No such file or directory error: failed to connect to the hypervisor