mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 5. Maintenance procedures 5.1. Updating the OS and HA cluster components Please refer to Recommended Practices for Applying Software Updates to a RHEL High Availability or Resilient Storage Cluster , for more information. 5.2. Updating the SAP HANA instances If the SAP HANA System Replication setup is managed using the HA cluster configuration described in this document, some additional steps are needed in addition to the actual process of updating the SAP HANA instances before and after the update. Execute the following steps: Put the SAPHana resource in unmanaged mode. [root]# pcs resource unmanage SAPHana_RH1_02-clone Update the SAP HANA instances using the procedure provided by SAP. When the update of the SAP HANA instances has been completed and it has been verified that SAP HANA System Replication is working again, the status of the SAPHana resource needs to be refreshed to make sure the cluster is aware of the current state of the SAP HANA System Replication setup. [root]# pcs resource refresh SAPHana_RH1_02-clone When the HA cluster has correctly picked up the current status of the SAP HANA System Replication setup, put the SAPHana resource back into managed mode so that the HA cluster will be able to react to any issues in the SAP HANA System Replication setup again. [root]# pcs resource manage SAPHana_RH1_02-clone 5.3. Manually moving SAPHana resource to another node (SAP HANA System Replication takeover by HA cluster) A manual takeover of SAP HANA System Replication can be triggered by moving the promotable clone resource: [root]# pcs resource move SAPHana_RH1_02-clone <other-node> Note What happens to the former SAP HANA primary instance after the takeover has been completed and the constraint has been removed depends on the setting of the AUTOMATED_REGISTER parameter of the SAPHana resource: If Automated_REGISTER=true , then the former SAP HANA primary instance will be registered as the new secondary and SAP HANA System Replication will become active again. If AUTOMATED_REGISTER=false , then it is up to the operator to decide what should happen with the former SAP HANA primary instance after the takeover.

Commands:
pcs resource unmanage SAPHana_RH1_02-clone
pcs resource refresh SAPHana_RH1_02-clone
pcs resource manage SAPHana_RH1_02-clone
pcs resource move SAPHana_RH1_02-clone <other-node>
5.2. Resource Properties The properties that you define for a resource tell the cluster which script to use for the resource, where to find that script and what standards it conforms to. Table 5.1, "Resource Properties" describes these properties. Table 5.1. Resource Properties Field Description resource_id Your name for the resource standard The standard the script conforms to. Allowed values: ocf , service , upstart , systemd , lsb , stonith type The name of the Resource Agent you wish to use, for example IPaddr or Filesystem provider The OCF spec allows multiple vendors to supply the same ResourceAgent. Most of the agents shipped by Red Hat use heartbeat as the provider. Table 5.2, "Commands to Display Resource Properties" . summarizes the commands that display the available resource properties. Table 5.2. Commands to Display Resource Properties pcs Display Command Output pcs resource list Displays a list of all available resources. pcs resource standards Displays a list of available resources agent standards. pcs resource providers Displays a list of available resources agent providers. pcs resource list string Displays a list of available resources filtered by the specified string. You can use this command to display resources filtered by the name of a standard, a provider, or a type.

Commands:
Chapter 7. Configuring the Podman CNI to use IPv6 In some cases, you might want to run a local instance of Red Hat Quay to use IPv6. This setup is common for development or testing purposes. By default, the Podman network for a root user does not use IPv6, and instead defaults to use IPv4. You can configure the Podman Container Network Interface (CNI) to use both IPv4 and IPv6, which allows for a local instance of Red Hat Quay using IPv6. Additional resources How to configure the default podman container network for the root user to use both IPv4 and IPv6 . 7.1. Creating a dual-stack container network Use the following procedure to create a new container network that is dual-stack. Procedure Unless there is a requirement that the default container network use both IPv4 and IPv6, it is suggested that a new container network is created that is dual-stack. As a root user, create a new container network that is dual-stack by running the following command: # podman network create ip-dual-stack --ipv6 With this command, new containers use this network are a natively dual-stack. 7.2. Deploying a local instance of Red Hat Quay in IPv6 After you have created a new dual-stack container network, you can deploy a local instance of Red Hat Quay. Prerequisites You have configured Redis, your PostgreSQL database, local image storage, and creating a config.yaml file with the desired settings. Procedure In your Red Hat Quay config.yaml file, set the FEATURE_LISTEN_IP_VERSION field to IPv6 . For example: # ... FEATURE_LISTEN_IP_VERSION: dual-stack # ... Enter the following command to start the Quay registry container, specifying the appropriate volumes for configuration data and local storage for image data. Note that if you are using dual-stack, you must specify explicit IPv6 port mapping when starting the container.

Commands:
podman network create ip-dual-stack --ipv6
FEATURE_LISTEN_IP_VERSION: dual-stack
sudo podman run -d --rm -p "[::]:80:8080" -p "[::]:443:8443" --name=quay -v USDQUAY/config:/conf/stack:Z -v USDQUAY/storage:/datastorage:Z registry.redhat.io/quay/quay-rhel8:v3.13.3
Chapter 1. Extension APIs 1.1. APIService [apiregistration.k8s.io/v1] Description APIService represents a server for a particular GroupVersion. Name must be "version.group". Type object 1.2. CustomResourceDefinition [apiextensions.k8s.io/v1] Description CustomResourceDefinition represents a resource that should be exposed on the API server. Its name MUST be in the format <.spec.name>.<.spec.group>. Type object 1.3. MutatingWebhookConfiguration [admissionregistration.k8s.io/v1] Description MutatingWebhookConfiguration describes the configuration of and admission webhook that accept or reject and may change the object. Type object 1.4. ValidatingAdmissionPolicy [admissionregistration.k8s.io/v1] Description ValidatingAdmissionPolicy describes the definition of an admission validation policy that accepts or rejects an object without changing it. Type object 1.5. ValidatingAdmissionPolicyBinding [admissionregistration.k8s.io/v1] Description ValidatingAdmissionPolicyBinding binds the ValidatingAdmissionPolicy with paramerized resources. ValidatingAdmissionPolicyBinding and parameter CRDs together define how cluster administrators configure policies for clusters. For a given admission request, each binding will cause its policy to be evaluated N times, where N is 1 for policies/bindings that don't use params, otherwise N is the number of parameters selected by the binding. The CEL expressions of a policy must have a computed CEL cost below the maximum CEL budget. Each evaluation of the policy is given an independent CEL cost budget. Adding/removing policies, bindings, or params can not affect whether a given (policy, binding, param) combination is within its own CEL budget. Type object 1.6. ValidatingWebhookConfiguration [admissionregistration.k8s.io/v1] Description ValidatingWebhookConfiguration describes the configuration of and admission webhook that accept or reject and object without changing it. Type object

Commands:
Chapter 8. Vault SPI 8.1. Vault provider You can use a vault SPI from org.keycloak.vault package to write custom extension for Red Hat Single Sign-On to connect to arbitrary vault implementation. The built-in files-plaintext provider is an example of the implementation of this SPI. In general the following rules apply: To prevent a secret from leaking across realms, you may want to isolate or limit the secrets that can be retrieved by a realm. In that case, your provider should take into account the realm name when looking up secrets, for example by prefixing entries with the realm name. For example, an expression USD{vault.key} would then evaluate generally to different entry names, depending on whether it was used in a realm A or realm B . To differentiate between realms, the realm needs to be passed to the created VaultProvider instance from VaultProviderFactory.create() method where it is available from the KeycloakSession parameter. The vault provider needs to implement a single method obtainSecret that returns a VaultRawSecret for the given secret name. That class holds the representation of the secret either in byte[] or ByteBuffer and is expected to convert between the two upon demand. Note that this buffer would be discarded after usage as explained below. For details on how to package and deploy a custom provider refer to the Service Provider Interfaces chapter. 8.2. Consuming values from vault The vault contains sensitive data and Red Hat Single Sign-On treats the secrets accordingly. When accessing a secret, the secret is obtained from the vault and retained in JVM memory only for the necessary time. Then all possible attempts to discard its content from JVM memory is done. This is achieved by using the vault secrets only within try -with-resources statement as outlined below: char[] c; try (VaultCharSecret cSecret = session.vault().getCharSecret(SECRET_NAME)) { // ... use cSecret c = cSecret.getAsArray().orElse(null); // if c != null, it now contains password } // if c != null, it now contains garbage The example uses KeycloakSession.vault() as the entrypoint for accessing the secrets. Using the VaultProvider.obtainSecret method directly is indeed also possible. However the vault() method has the benefit of ability to interpret the raw secret (which is generally a byte array) as a character array (via vault().getCharSecret() ) or a String (via vault().getStringSecret() ) in addition to obtaining the original uninterpreted value (via vault().getRawSecret() method). Note that since String objects are immutable, their content cannot be discarded by overriding with random garbage. Even though measures have been taken in the default VaultStringSecret implementation to prevent internalizing String s, the secrets stored in String objects would live at least to the GC round. Thus using plain byte and character arrays and buffers is preferrable.

Commands:
char[] c; try (VaultCharSecret cSecret = session.vault().getCharSecret(SECRET_NAME)) { // ... use cSecret c = cSecret.getAsArray().orElse(null); // if c != null, it now contains password } // if c != null, it now contains garbage
19.7. Additional Resources For more information about Kerberos, refer to the following resources. 19.7.1. Installed Documentation The /usr/share/doc/krb5-server- <version-number> / directory - The Kerberos V5 Installation Guide and the Kerberos V5 System Administrator's Guide in PostScript and HTML formats. The krb5-server package must be installed. The /usr/share/doc/krb5-workstation- <version-number> / directory - The Kerberos V5 UNIX User's Guide in PostScript and HTML formats. The krb5-workstation package must be installed. Kerberos man pages - There are a number of man pages for the various applications and configuration files involved with a Kerberos implementation. The following is a list of some of the more important man pages. Client Applications man kerberos - An introduction to the Kerberos system which describes how credentials work and provides recommendations for obtaining and destroying Kerberos tickets. The bottom of the man page references a number of related man pages. man kinit - Describes how to use this command to obtain and cache a ticket-granting ticket. man kdestroy - Describes how to use this command to destroy Kerberos credentials. man klist - Describes how to use this command to list cached Kerberos credentials. Administrative Applications man kadmin - Describes how to use this command to administer the Kerberos V5 database. man kdb5_util - Describes how to use this command to create and perform low-level administrative functions on the Kerberos V5 database. Server Applications man krb5kdc - Describes available command line options for the Kerberos V5 KDC. man kadmind - Describes available command line options for the Kerberos V5 administration server. Configuration Files man krb5.conf - Describes the format and options available within the configuration file for the Kerberos V5 library. man kdc.conf - Describes the format and options available within the configuration file for the Kerberos V5 AS and KDC.

Commands:
13.2. Cloning Volumes The new volume will be allocated from storage in the same storage pool as the volume being cloned. The virsh vol-clone must have the --pool argument which dictates the name of the storage pool that contains the volume to be cloned. The rest of the command names the volume to be cloned (volume3) and the name of the new volume that was cloned (clone1). The virsh vol-list command lists the volumes that are present in the storage pool (guest_images_disk).

Commands:
virsh vol-clone --pool guest_images_disk volume3 clone1 Vol clone1 cloned from volume3 # virsh vol-list guest_images_disk Name Path ----------------------------------------- volume1 /dev/sdb1 volume2 /dev/sdb2 volume3 /dev/sdb3 clone1 /dev/sdb4 # parted -s /dev/sdb print Model: ATA ST3500418AS (scsi) Disk /dev/sdb: 500GB Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start End Size File system Name Flags 1 4211MB 12.8GB 8595MB primary 2 12.8GB 21.4GB 8595MB primary 3 21.4GB 30.0GB 8595MB primary 4 30.0GB 38.6GB 8595MB primary
7.267. virt-v2v 7.267.1. RHBA-2013:0477 - virt-v2v bug fix and enhancement update Updated virt-v2v packages that fix several bugs and add one enhancement are now available for Red Hat Enterprise Linux 6. The virt-v2v packages provide a tool for converting virtual machines to use the Kernel-based Virtual Machine (KVM) hypervisor or Red Hat Enterprise Virtualization. The tool modifies both the virtual machine image and its associated libvirt metadata. Also, virt-v2v can configure a guest to use VirtIO drivers if possible. Bug Fixes BZ# 794680 The virt-v2v packages used to rename block devices in various guest configuration files during conversion, including the /etc/fstab file. Consequently, the virt-v2v utility returned a redundant warning message when a guest's /etc/fstab file referenced to the /etc/fd0 file as the block device did not know it. To fix this bug, warning messages concerning floppy devices have been explicitly suppressed and virt-v2v no longer returns warning messages in this situation. BZ# 803629 When reading a libvirt guest, virt-v2v uses libvirt metadata to determine the on-disk format, considering only those of "dir", "fs", and "netfs" types as meaningful. If a guest used a different type of storage pool, virt-v2v interpreted these data as a format type, which was unable to convert by libvirt guests. To address this bug, virt-v2v now only uses volume format metadata from storage pools of type "dir", "fs", and "netfs", but also all other storage pools can only hold raw data, so the format is assumed to be "raw". As a result, virt-v2v can now convert libvirt guests using any supported storage pool type. BZ# 838057 When creating a new libvirt guest, virt-v2v failed to disable caching for disks as recommended. As a consequence, guests created by virt-v2v used caching for their disks, unless explicitly disabled by the user after conversion. To address this bug, virt-v2v now explicitly disables caching for all disks when creating a new libvirt guest, and guests created by virt-v2v now have caching disabled for all disks. The user can enable it again if required after conversion. BZ#868405 Virt-v2v failed when attempting to perform an on-disk format conversion when reading a guest using the libvirtxml input method. A patch has been provided to fix this bug and virt-v2v can now perform format conversions on guests using libvirtxml. Enhancement BZ#682945 With this update, virt-v2v can do an on-disk format conversion while converting a remote libvirt guest. Note that when doing this kind of format conversion, virt-v2v must make an intermediate copy of the guest storage data on the conversion server. Other types of conversion do not require any intermediate storage on the conversion server. The user must ensure that the TMPDIR temporary directory has sufficient space for this intermediate copy. Users of virt-v2v are advised to upgrade to these updated packages, which fix these bugs and add this enhancement.

Commands:
3.3. Hardware Requirements For a list of minimum hardware requirements of Red Hat Enterprise Linux 6, see the Red Hat Enterprise Linux technology capabilities and limits page. Also note that the minimum memory requirements listed on that page assume that you create a swap space based on the recommendations in Section 9.15.5, "Recommended Partitioning Scheme" . Systems with low memory (1 GB and less) and less than the recommended amount of swap space may have issues ranging from low responsivity up to and including complete inability to boot after the installation. For installation of Red Hat Enterprise Linux on x86, AMD64, and Intel 64 systems, Red Hat supports the following installation targets: Hard drives connected by a standard internal interface, such as SCSI, SATA, or SAS BIOS/firmware RAID devices Fibre Channel Host Bus Adapters and multipath devices are also supported. Vendor-provided drivers may be required for certain hardware. Red Hat does not support installation to USB drives or SD memory cards. Red Hat also supports installations that use the following virtualization technologies: Xen block devices on Intel processors in Xen virtual machines. VirtIO block devices on Intel processors in KVM virtual machines.

Commands:
Chapter 9. Backing up storage data from Amazon EBS Red Hat recommends that you back up the data on your persistent volume claims (PVCs) regularly. Backing up your data is particularly important before deleting a user and before uninstalling OpenShift AI, as all PVCs are deleted when OpenShift AI is uninstalled. Prerequisites You have credentials for Red Hat OpenShift Cluster Manager ( https://console.redhat.com/openshift/ ). You have administrator access to the OpenShift Dedicated cluster. You have credentials for the Amazon Web Services (AWS) account that the OpenShift Dedicated cluster is deployed under. Procedure Determine the IDs of the persistent volumes (PVs) that you want to back up. In the OpenShift Dedicated web console, change into the Administrator perspective. Click Home Projects . Click the rhods-notebooks project. The Details page for the project opens. Click the PersistentVolumeClaims in the Inventory section. The PersistentVolumeClaims page opens. Note the ID of the persistent volume (PV) that you want to back up. Note The persistent volumes (PV) that you make a note of are required to identify the correct EBS volume to back up in your AWS instance. Locate the EBS volume containing the PVs that you want to back up. See Amazon Web Services documentation: Create Amazon EBS snapshots for more information. Log in to AWS ( https://aws.amazon.com ) and ensure that you are viewing the region that your OpenShift Dedicated cluster is deployed in. Click Services . Click Compute EC2 . Click Elastic Block Storage Volumes in the side navigation. The Volumes page opens. In the search bar, enter the ID of the persistent volume (PV) that you made a note of earlier. The Volumes page reloads to display the search results. Click on the volume shown and verify that any kubernetes.io/created-for/pvc/namespace tags contain the value rhods-notebooks , and any kubernetes.io/created-for/pvc/name tags match the name of the persistent volume that the EC2 volume is being used for, for example, jupyter-nb-user1-pvc . Back up the EBS volume that contains your persistent volume (PV). Right-click on the volume that you want to back up and select Create Snapshot from the list. The Create Snapshot page opens. Enter a Description for the volume. Click Create Snapshot . The snapshot of the volume is created. Click Close . Verification The snapshot that you created is visible on the Snapshots page in AWS. Additional resources Amazon Web Services documentation: Create Amazon EBS snapshots

Commands:
Chapter 1. About two-factor authentication (2FA) for Red Hat user accounts Red Hat allows users to enable two-factor authentication as an additional layer of security for logging in to their Red Hat user accounts. When two-factor authentication is enabled, you use your password plus a one-time code to log in to your account. The one-time code is the second authentication factor. The two-factor authentication feature is available to customers in one of two ways: Organizational two-factor authentication. When your organization enables two-factor authentication, all users who belong to a specific organization account will be required to use a second factor each time they authenticate. Users will be prompted to enable two-factor authentication upon the first log in attempt after the organization account is enrolled. Individual opt-in two-factor authentication. Individual users can enable or disable two-factor authentication for their Red Hat account. When organizational two-factor authentication is turned on, individual users cannot disable it. Note The current implementation of two-factor authentication only applies to applications using a browser-based authentication flow. It does not apply to command line authentication flows. 1.1. Organizational two-factor authentication The Organization Administrator for an account can enable organization-wide two-factor authentication. When enabled, all users on that account must use two-factor authentication for authentication when they log in. See Section 2.1, "Configuring organization-wide authentication factors" . 1.2. Two-factor authentication and token support Token support for two-factor authentication is limited to smartphones or other devices that can install either of the following applications from Apple App Store or Google Play . Google Authenticator FreeOTP Authenticator Google Authenticator and FreeOTP Authenticator are the only supported token generators. Hardware tokens, SMS (text-message) tokens, and other apps are not supported.

Commands:
Chapter 12. Tuning server connection management The nsslapd-numlisteners attribute specifies the number of listener threads the Directory Server can use to monitor established connections. You can improve the response times when the server experiences a large number of client connection by increasing the attribute value. 12.1. Managing the number of connection listener threads by using the command line You can manage the number of connection listener threads by using the command line. The default value is 1 . Procedure List the number of connection listener threads: Modify the number of connection listener threads: Restart the instance:

Commands:
dsconf -D "cn=Directory Manager" ldap://server.example.com config get nsslapd-numlisteners
dsconf -D "cn=Directory Manager" ldap://server.example.com config replace nsslapd-numlisteners=4
dsctl instance_name restart