mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 1. Creating the Red Hat automation hub API token Before you can interact with automation hub by uploading or downloading collections, you must create an API token. The automation hub API token authenticates your ansible-galaxy client to the Red Hat automation hub server. You can create an API token by using Token management in automation hub or API Token Management in private automation hub (PAH). 1.1. Creating the Red Hat automation hub API token Before you can interact with automation hub by uploading or downloading collections, you need to create an API token. The automation hub API token authenticates your ansible-galaxy client to the Red Hat automation hub server. You can create an API token using automation hub Token management . Prerequisites Valid subscription credentials for Red Hat Ansible Automation Platform. Procedure Navigate to https://cloud.redhat.com/ansible/automation-hub/token/ . Click Load Token . Click copy icon to copy the API token to the clipboard. Paste the API token into a file and store in a secure location. Important The API token is a secret token used to protect your content. Store your API token in a secure location. The API token is now available for configuring automation hub as your default collections server or uploading collections using the ansible-galaxy command line tool. 1.2. Creating the API token in private automation hub You can create an API token by using API Token Management in private automation hub. Prerequisites Valid subscription credentials for Red Hat Ansible Automation Platform. Procedure Navigate to your PAH. From the sidebar, navigate to Collections API Token Management . Click Load Token . Click the copy icon to copy the API token to the clipboard. Paste the API token into a file and store in a secure location. Important The API token is a secret token used to protect your content. Store your API token in a secure location. The API token is now available for configuring automation hub as your default collections server or uploading collections using the ansible-galaxy command line tool. 1.3. Keeping your offline token active Keeping an offline token active is useful when an application needs to perform action on behalf of the user, even when the user is offline. For example, a routine data backup. Offline tokens expire after 30 days of inactivity. You can keep your offline token from expiring by periodically refreshing your offline token. Note Once your offline token expires, you must request a new one. Run the following command periodically to prevent your token from expiring: curl https://sso.redhat.com/auth/realms/redhat-external/protocol/openid-connect/token -d grant_type=refresh_token -d client_id="cloud-services" -d refresh_token="{{ user_token }}" --fail --silent --show-error --output /dev/null

Commands:
curl https://sso.redhat.com/auth/realms/redhat-external/protocol/openid-connect/token -d grant_type=refresh_token -d client_id="cloud-services" -d refresh_token="{{ user_token }}" --fail --silent --show-error --output /dev/null
Chapter 2. Accessing the web console The OpenShift Container Platform web console is a user interface accessible from a web browser. Developers can use the web console to visualize, browse, and manage the contents of projects. 2.1. Prerequisites JavaScript must be enabled to use the web console. For the best experience, use a web browser that supports WebSockets . Review the OpenShift Container Platform 4.x Tested Integrations page before you create the supporting infrastructure for your cluster. 2.2. Understanding and accessing the web console The web console runs as a pod on the master. The static assets required to run the web console are served by the pod. After OpenShift Container Platform is successfully installed using openshift-install create cluster , find the URL for the web console and login credentials for your installed cluster in the CLI output of the installation program. For example: Example output INFO Install complete! INFO Run 'export KUBECONFIG=<your working directory>/auth/kubeconfig' to manage the cluster with 'oc', the OpenShift CLI. INFO The cluster is ready when 'oc login -u kubeadmin -p <provided>' succeeds (wait a few minutes). INFO Access the OpenShift web-console here: https://console-openshift-console.apps.demo1.openshift4-beta-abcorp.com INFO Login to the console with user: kubeadmin, password: <provided> Use those details to log in and access the web console. For existing clusters that you did not install, you can use oc whoami --show-console to see the web console URL. Additional resources Enabling feature sets using the web console

Commands:
INFO Install complete! INFO Run 'export KUBECONFIG=<your working directory>/auth/kubeconfig' to manage the cluster with 'oc', the OpenShift CLI. INFO The cluster is ready when 'oc login -u kubeadmin -p <provided>' succeeds (wait a few minutes). INFO Access the OpenShift web-console here: https://console-openshift-console.apps.demo1.openshift4-beta-abcorp.com INFO Login to the console with user: kubeadmin, password: <provided>
Chapter 3. Overview of Bare Metal certification The bare-metal certification overview provides details about product publication in the catalog, product release, certification duration, and recertification. 3.1. Publication on the catalog When you certify your server for bare metal on Red Hat OpenShift Container Platform, the following features might appear as certified component of your server depending on the certification tests the server passed: Installer Provisioned Infrastructure Assisted Installer Service Names may differ corresponding to the language of the products. 3.2. Red Hat product releases You have access to and are encouraged to test with pre-released Red Hat software. You can begin your engagement with the Red Hat Certification team before Red Hat software is generally available (GA) to customers to expedite the certification process for your product. However, conduct official certification testing only on the GA releases of Red Hat OpenShift Container Platform bare-metal hardware. 3.3. Certification duration Certifications are valid starting with the specific major and minor releases of Red Hat OpenShift Container Platform software as tested and listed on the Red Hat Ecosystem Catalog. They continue to be valid through the last minor release of the major release. This allows customers to count on certifications from the moment they are listed until the end of the product's lifecycle. 3.4. Recertification workflow You do not need to recertify after a new major or minor release of RHOCP if you have not made changes to your product. However, it is your responsibility to certify your product again any time you make significant changes to it. Red Hat recommends that you run the certification tests on your product periodically to ensure its quality, functionality, and performance with the supported versions of RHOCP. To recertify your product, open a supplemental certification.

Commands:
Chapter 19. Activation and Passivation Modes Activation is the process of loading an entry into memory and removing it from the cache store. Activation occurs when a thread attempts to access an entry that is in the store but not the memory (namely a passivated entry). Passivation mode allows entries to be stored in the cache store after they are evicted from memory. Passivation prevents unnecessary and potentially expensive writes to the cache store. It is used for entries that are frequently used or referenced and therefore not evicted from memory. While passivation is enabled, the cache store is used as an overflow tank, similar to virtual memory implementation in operating systems that swap memory pages to disk. The passivation flag is used to toggle passivation mode, a mode that stores entries in the cache store only after they are evicted from memory. 23149%2C+Administration+and+Configuration+Guide-6.628-06-2017+13%3A51%3A02JBoss+Data+Grid+6Documentation6.6.1 Report a bug 19.1. Passivation Mode Benefits The primary benefit of passivation mode is that it prevents unnecessary and potentially expensive writes to the cache store. This is particularly useful if an entry is frequently used or referenced and therefore is not evicted from memory. 23149%2C+Administration+and+Configuration+Guide-6.628-06-2017+13%3A51%3A02JBoss+Data+Grid+6Documentation6.6.1 Report a bug

Commands:
13.5. Locking Down Printing You can disable the print dialog from being shown to users. This can be useful if you are giving temporary access to a user or you do not want the user to print to network printers. Important This feature will only work in applications which support it. Not all GNOME and third party applications have this feature enabled. These changes will have no effect on applications which do not support this feature. You prevent applications from printing by locking down the org.gnome.desktop.lockdown.disable-printing key. Follow the procedure. Procedure 13.5. Locking Down the org.gnome.desktop.lockdown.disable-printing Key Create the user profile if it already does not exist ( /etc/dconf/profile/user ): Create a local database for machine-wide settings in etc/dconf/db/local.d/00-lockdown : Override the user's setting and prevent the user from changing it in /etc/dconf/db/local.d/locks/lockdown : Update the system databases by running Having followed these steps, applications supporting this lockdown key will disable printing. Among such applications there are Evolution , Evince , Eye of GNOME , Epiphany , and Gedit .

Commands:
user-db:user system-db:local
Prevent applications from printing disable-printing=true
List the keys used to configure lockdown /org/gnome/desktop/lockdown/disable-printing
dconf update
9.3. NFS Client Configuration The mount command mounts NFS shares on the client side. Its format is as follows: This command uses the following variables: options A comma-delimited list of mount options; refer to Section 9.5, "Common NFS Mount Options" for details on valid NFS mount options. server The hostname, IP address, or fully qualified domain name of the server exporting the file system you wish to mount /remote/export The file system or directory being exported from the server , that is, the directory you wish to mount /local/directory The client location where /remote/export is mounted The NFS protocol version used in Red Hat Enterprise Linux 6 is identified by the mount options nfsvers or vers . By default, mount will use NFSv4 with mount -t nfs . If the server does not support NFSv4, the client will automatically step down to a version supported by the server. If the nfsvers / vers option is used to pass a particular version not supported by the server, the mount will fail. The file system type nfs4 is also available for legacy reasons; this is equivalent to running mount -t nfs -o nfsvers=4 host : /remote/export /local/directory . Refer to man mount for more details. If an NFS share was mounted manually, the share will not be automatically mounted upon reboot. Red Hat Enterprise Linux offers two methods for mounting remote file systems automatically at boot time: the /etc/fstab file and the autofs service. Refer to Section 9.3.1, "Mounting NFS File Systems using /etc/fstab " and Section 9.4, " autofs " for more information. 9.3.1. Mounting NFS File Systems using /etc/fstab An alternate way to mount an NFS share from another machine is to add a line to the /etc/fstab file. The line must state the hostname of the NFS server, the directory on the server being exported, and the directory on the local machine where the NFS share is to be mounted. You must be root to modify the /etc/fstab file. Example 9.1. Syntax example The general syntax for the line in /etc/fstab is as follows: The mount point /pub must exist on the client machine before this command can be executed. After adding this line to /etc/fstab on the client system, use the command mount /pub , and the mount point /pub is mounted from the server. The /etc/fstab file is referenced by the netfs service at boot time, so lines referencing NFS shares have the same effect as manually typing the mount command during the boot process. A valid /etc/fstab entry to mount an NFS export should contain the following information: The variables server , /remote/export , /local/directory , and options are the same ones used when manually mounting an NFS share. Refer to Section 9.3, "NFS Client Configuration" for a definition of each variable. Note The mount point /local/directory must exist on the client before /etc/fstab is read. Otherwise, the mount will fail. For more information about /etc/fstab , refer to man fstab .

Commands:
mount -t nfs -o options server : /remote/export /local/directory
server:/usr/local/pub /pub nfs defaults 0 0
server : /remote/export /local/directory nfs options 0 0
probe::tcpmib.ActiveOpens Name probe::tcpmib.ActiveOpens - Count an active opening of a socket Synopsis tcpmib.ActiveOpens Values op value to be added to the counter (default value of 1) sk pointer to the struct sock being acted on Description The packet pointed to by skb is filtered by the function tcpmib_filter_key . If the packet passes the filter is is counted in the global ActiveOpens (equivalent to SNMP's MIB TCP_MIB_ACTIVEOPENS)

Commands:
Chapter 11. Certified Cloud and Service Provider certification workflow The Certified Cloud Provider Agreement requires that Red Hat certifies the images (templates) from which tenant instances are created to ensure a fully supported configuration for end customers. There are two methods for certifying the images for Red Hat Enterprise Linux. The preferred method is to use the Certified Cloud and Service Provider (CCSP) image certification workflow. After certifications have been reviewed by Red Hat, a pass/fail will be assigned and certification will be posted to the public Red Hat certification website at Red Hat Ecosystem Catalog . 11.1. Additional resources Red Hat Certified Cloud and Service Provider Certification Workflow Guide Product Documentation for Red Hat Certified Cloud and Service Provider Certification 7.34

Commands:
22.3. Online Resources For z/VM publications, refer to http://www.vm.ibm.com/library/ . For IBM Z I/O connectivity information, refer to http://www.ibm.com/systems/z/hardware/connectivity/index.html . For IBM Z cryptographic coprocessor information, refer to http://www.ibm.com/security/cryptocards/ . For IBM Z DASD storage information, refer to http://www-01.ibm.com/support/knowledgecenter/linuxonibm/com.ibm.linux.z.lgdd/lgdd_t_dasd_wrk.html .

Commands:
Chapter 2. Fixed issues 2.1. AMQ JMS ENTMQCL-2681 - Wait() sometimes blocks forever when closing producers In earlier releases of the product, the producer wait() operation could block indefinitely when a message send failed. In this release, the wait() operation completes as expected. ENTMQCL-2784 - Do not de-duplicate failover URIs based on name resolution In earlier releases of the product, the client performed a DNS resolution step before removing duplicates in the failover list. This caused problems for servers running behind a proxy. In this release, the client removes duplicates using the names as given in the failover list. For a complete list of issues that have been fixed in the release, see AMQ Clients 2.10.x Resolved Issues . 2.2. AMQ C++ ENTMQCL-2583 - Example build fails using CMake 2.8 In earlier releases of the product, the examples failed to build when using CMake 2.8. In this release, the examples build as expected.

Commands:
Chapter 1. Getting Started You can install Red Hat Enterprise Linux with an installation utility called Anaconda . Most users can simply follow the procedure outlined in Section 4.1, "Interactive Installation" to install Red Hat Enterprise Linux using the graphical interface in Anaconda . Users with advanced requirements can also use the graphical interface to configure many aspects of the installation, and install Red Hat Enterprise Linux on a wide variety of systems. On systems without a local interface, installation can be accessed entirely remotely. Installation can also be automated by using a Kickstart file, and performed with no interaction at all. 1.1. Graphical Installation The Red Hat Enterprise Linux installer, Anaconda , provides a simple graphical method to install Red Hat Enterprise Linux. The graphical installation interface has a built-in help system which can guide you through most installations, even if you have never installed Linux before. However, Anaconda can also be used to configure advanced installation options if required. Anaconda is different from most other operating system installation programs due to its parallel nature. Most installers follow a linear path; you must choose your language first, then you configure networking, and so on. There is usually only one way to proceed at any given time. In the graphical interface in Anaconda you are at first only required to select your language and locale, and then you are presented with a central screen, where you can configure most aspects of the installation in any order you like. While certain parts require others to be completed before configuration - for example, when installing from a network location, you must configure networking before you can select which packages to install - most options in Anaconda can be configured in any order. If a background task, such as network initialization or disk detection, is blocking configuration of a certain option, you can configure unrelated options while waiting for it to complete. Additional differences appear in certain screens; notably the custom partition process is very different from other Linux distributions. These differences are described in each screen's subsection. Some screens will be automatically configured depending on your hardware and the type of media you used to start the installation. You can still change the detected settings in any screen. Screens which have not been automatically configured, and therefore require your attention before you begin the installation, are marked by an exclamation mark. You cannot start the actual installation process before you finish configuring these settings. Installation can also be performed in text mode, however certain options, notably including custom partitioning, are unavailable. See Section 8.3, "Installing in Text Mode" , or if using an IBM Power system or IBM Z, see Section 13.3, "Installing in Text Mode" , or Section 18.4, "Installing in Text Mode" , respectively, for more information.

Commands:
14.13.8. Changing the Memory Allocation for the Domain The virsh setmaxmem domain size --config --live --current allows the setting of the maximum memory allocation for a guest virtual machine as shown: The size that can be given for the maximum memory is a scaled integer that by default is expressed in kibibytes, unless a supported suffix is provided. The following options can be used with this command: --config - takes affect boot --live - controls the memory of the running domain, providing the hypervisor supports this action as not all hypervisors allow live changes of the maximum memory limit. --current - controls the memory on the current domain

Commands:
virsh setmaxmem rhel6 1024 --current
Chapter 2. Planning an upgrade An in-place upgrade is the recommended and supported way to upgrade your SAP HANA system to the major version of RHEL. You should consider the following before upgrading to RHEL 9: Operating system: SAP HANA is installed with a version which is supported on both the source and target RHEL minor versions. SAP HANA is installed using the default installation path of /hana/shared. Public clouds: The in-place upgrade is supported for on-demand Pay-As-You-Go (PAYG) instances on Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform with Red Hat Update Infrastructure (RHUI) . The in-place upgrade is also supported for Bring Your Own Subscription instances on all public clouds that use Red Hat Subscription Manager (RHSM) for a RHEL subscription. Additional Information: SAP HANA hosts must meet all of the following criteria: Running with e4s repositories on RHEL 8.8 or normal repositories on RHEL 8.10 Running on x86_64 or ppc64le systems which are certified by the hardware partner or CCSP for SAP HANA on the source and target OS versions Running on physical infrastructure or in a virtual environment Not using Red Hat HA Solutions for SAP HANA Using the Red Hat Enterprise Linux for SAP Solutions subscription SAP NetWeaver hosts must meet the following criteria: Using the Red Hat Enterprise Linux for SAP Solutions or Red Hat Enterprise Linux for SAP Applications subscription Note RHEL 8.10 is the final RHEL 8 release. There are no EUS or E4S repositories available in RHEL 8.10. RHEL 8.10 maintenance is defined by the Maintenance Support Phase policy.

Commands:
14.3.8. Revoking an SSH CA Certificate If a certificate is stolen, it should be revoked. Although OpenSSH does not provide a mechanism to distribute the revocation list it is still easier to create the revocation list and distribute it by other means then to change the CA keys and all host and user certificates previously created and distributed. Keys can be revoked by adding them to the revoked_keys file and specifying the file name in the sshd_config file as follows: RevokedKeys /etc/ssh/revoked_keys Note that if this file is not readable, then public key authentication will be refused for all users. To test if a key has been revoked, query the revocation list for the presence of the key. Use a command as follows: ssh-keygen -Qf /etc/ssh/revoked_keys ~/.ssh/id_rsa.pub A user can revoke a CA certificate by changing the cert-authority directive to revoke in the known_hosts file.

Commands:
Chapter 5. Managing DHCP by using Capsule Satellite can integrate with a DHCP service by using your Capsule. A Capsule has multiple DHCP providers that you can use to integrate Satellite with your existing DHCP infrastructure or deploy a new one. You can use the DHCP module of Capsule to query for available IP addresses, add new, and delete existing reservations. Note that your Capsule cannot manage subnet declarations. Available DHCP providers dhcp_infoblox - For more information, see Chapter 7, Using Infoblox as DHCP and DNS providers . dhcp_isc - ISC DHCP server over OMAPI. For more information, see Section 3.6, "Configuring DNS, DHCP, and TFTP on Capsule Server" . dhcp_remote_isc - ISC DHCP server over OMAPI with leases mounted through networking. For more information, see Section 4.2, "Configuring Capsule Server with external DHCP" . 5.1. Securing the dhcpd API Capsule interacts with DHCP daemon using the dhcpd API to manage DHCP. By default, the dhcpd API listens to any host without access control. You can add an omapi_key to provide basic security. Procedure On your Capsule, install the required packages: Generate a key: Use satellite-installer to secure the dhcpd API:

Commands:
satellite-maintain packages install bind-utils
dnssec-keygen -r /dev/urandom -a HMAC-MD5 -b 512 -n HOST omapi_key cat Komapi_key.+*.private | grep ^Key|cut -d ' ' -f2-
satellite-installer --foreman-proxy-dhcp-key-name " My_Name " --foreman-proxy-dhcp-key-secret " My_Secret "
3.4. Saving a Configuration Change to a File When using the pcs command, you can use the -f option to save a configuration change to a file without affecting the active CIB. If you have previously configured a cluster and there is already an active CIB, you use the following command to save the raw xml file. For example, the following command saves the raw xml from the CIB into a file named testfile . The following command creates a resource in the file testfile but does not add that resource to the currently running cluster configuration. You can push the current content of testfile to the CIB with the following command.

Commands:
pcs cluster cib filename
pcs cluster cib testfile
pcs -f testfile resource create VirtualIP ocf:heartbeat:IPaddr2 ip=192.168.0.120 cidr_netmask=24 op monitor interval=30s
pcs cluster cib-push testfile