mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 7. Container Images Based on Red Hat Software Collections 3.4 Component Description Supported architectures Application Images rhscl/nodejs-12-rhel7 Node.js 12 platform for building and running applications (EOL) x86_64, s390x, ppc64le Daemon Images rhscl/nginx-116-rhel7 nginx 1.16 server and a reverse proxy server (EOL) x86_64, s390x, ppc64le Database Images rhscl/postgresql-12-rhel7 PostgreSQL 12 SQL database server x86_64, s390x, ppc64le Legend: x86_64 - AMD64 and Intel 64 architectures s390x - 64-bit IBM Z ppc64le - IBM POWER, little endian All images are based on components from Red Hat Software Collections. The images are available for Red Hat Enterprise Linux 7 through the Red Hat Container Registry. For detailed information about components provided by Red Hat Software Collections 3.4, see the Red Hat Software Collections 3.4 Release Notes . For more information about the Red Hat Developer Toolset 9.0 components, see the Red Hat Developer Toolset 9 User Guide . For information regarding container images based on Red Hat Software Collections 2, see Using Red Hat Software Collections 2 Container Images . EOL images are no longer supported.

Commands:
Chapter 9. PackageKit Red Hat provides PackageKit for viewing, managing, updating, installing and uninstalling packages compatible with your system. PackageKit consists of several graphical interfaces that can be opened from the GNOME panel menu, or from the Notification Area when PackageKit alerts you that updates are available. For more information on PackageKit's architecture and available front ends, see Section 9.3, "PackageKit Architecture" . 9.1. Updating Packages with Software Update PackageKit displays a starburst icon in the Notification Area whenever updates are available to be installed on your system. Figure 9.1. PackageKit's icon in the Notification Area Clicking on the notification icon opens the Software Update window. Alternatively, you can open Software Updates by clicking System Administration Software Update from the GNOME panel, or running the gpk-update-viewer command at the shell prompt. In the Software Updates window, all available updates are listed along with the names of the packages being updated (minus the .rpm suffix, but including the CPU architecture), a short summary of the package, and, usually, short descriptions of the changes the update provides. Any updates you do not want to install can be de-selected here by unchecking the check box corresponding to the update. Figure 9.2. Installing updates with Software Update The updates presented in the Software Updates window only represent the currently-installed packages on your system for which updates are available; dependencies of those packages, whether they are existing packages on your system or new ones, are not shown until you click Install Updates . PackageKit utilizes the fine-grained user authentication capabilities provided by the PolicyKit toolkit whenever you request it to make changes to the system. Whenever you instruct PackageKit to update, install or remove packages, you will be prompted to enter the superuser password before changes are made to the system. If you instruct PackageKit to update the kernel package, then it will prompt you after installation, asking you whether you want to reboot the system and thereby boot into the newly-installed kernel. Setting the Update-Checking Interval Right-clicking on PackageKit's Notification Area icon and clicking Preferences opens the Software Update Preferences window, where you can define the interval at which PackageKit checks for package updates, as well as whether or not to automatically install all updates or only security updates. Leaving the Check for updates when using mobile broadband box unchecked is handy for avoiding extraneous bandwidth usage when using a wireless connection on which you are charged for the amount of data you download. Figure 9.3. Setting PackageKit's update-checking interval

Commands:
Chapter 1. Event-Driven Ansible controller overview Event-Driven Ansible is a highly scalable, flexible automation capability that works with event sources such as other software vendors' monitoring tools. These tools monitor IT solutions and identify events and automatically implement the documented changes or response in a rulebook to handle that event. The following procedures form the user configuration: Credentials Credential types Projects Decision environments Simplified event routing Red Hat Ansible Automation Platform credential Rulebook activations Rulebook activations troubleshooting Rule audit Performance tuning for Event-Driven Ansible controller Event filter plugins Event-Driven Ansible logging strategy Note API documentation for Event-Driven Ansible controller is available at https://<gateway-host>/api/eda/v1/docs To meet high availability demands, Event-Driven Ansible controller shares centralized Redis (REmote DIctionary Server) with the Ansible Automation Platform UI. When Redis is unavailable, you will not be able to create or sync projects, or enable rulebook activations. Additional resources For information on how to set user permissions for Event-Driven Ansible controller, see the following in the Access management and authentication guide : Adding roles for a user Roles If you plan to use Event-Driven Ansible 2.5 with a 2.4 Ansible Automation Platform, see Using Event-Driven Ansible 2.5 with Ansible Automation Platform 2.4 .

Commands:
Chapter 9. Generating a cryptographic key pair To ensure secure data transmission between the Red Hat Update Appliance (RHUA), content delivery system (CDS), and HAProxy nodes, and to use rhui-manager to set up those nodes, you must generate a key pair on the RHUA node and copy the public key to CDS and HAProxy nodes. You can generate either an RSA or an ECDSA key, depending on your use case. 9.1. Generating an RSA key pair The following steps explain how to generate an RSA key pair for version 2 of the SSH protocol. Procedure On the RHUA node, run the ssh-keygen command with the RSA argument, and save the key in the default location. Warning Leave the passphrase field blank. CDS installation and registration fails if you provide a passphrase while generating the key pair. Confirm that the permissions for the ~/.ssh/ directory are set to rwx------ , or 700 in octal notation. Copy the public key to the CDS and HAProxy nodes. 9.2. Generating an ecdsa key pair The following steps explain how to generate an ECDSA key pair for version 2 of the SSH protocol. Procedure On the RHUA node, run the ssh-keygen command with the ECDSA argument, and save the key in the default location. Warning Leave the passphrase field blank. CDS installation and registration fails if you provide a passphrase while generating the key pair. Confirm that the permissions for the ~/.ssh/ directory are set to rwx------ , or 700 in octal notation. Copy the public key to the CDS and HAProxy nodes.

Commands:
ssh-keygen -t rsa Generating public/private rsa key pair. Enter file in which to save the key (/home/USER/.ssh/id_rsa): Created directory '/home/USER/.ssh'. Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/USER/.ssh/id_rsa. Your public key has been saved in /home/USER/.ssh/id_rsa.pub. The key fingerprint is: e7:97:c7:e2:0e:f9:0e:fc:c4:d7:cb:e5:31:11:92:14 USER@rhua.example.com The key's randomart image is: +--[ RSA 2048]----+ | E. | | . . | | o . | | . .| | S . . | | + o o ..| | * * +oo| | O +..=| | o* o.| +-----------------+
ls -ld ~/.ssh drwx------. 2 USER USER 54 Nov 25 16:56 /home/USER/.ssh/
ssh-copy-id user@<haproxy1> USD ssh-copy-id user@<cds1> USD ssh-copy-id user@<cds2>
ssh-keygen -t ecdsa Generating public/private ecdsa key pair. Enter file in which to save the key (/home/USER/.ssh/id_ecdsa): Created directory '/home/USER/.ssh'. Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/USER/.ssh/id_ecdsa. Your public key has been saved in /home/USER/.ssh/id_ecdsa.pub. The key fingerprint is: fd:1d:ca:10:52:96:21:43:7e:bd:4c:fc:5b:35:6b:63 USER@rhua.example.com The key's randomart image is: +--[ECDSA 256]---+ | .+ +o | | . =.o | | o o + ..| | + + o +| | S o o oE.| | + oo+.| | + o | | | | | +-----------------+
ls -ld ~/.ssh drwx------. 2 USER USER 54 Nov 25 16:56 /home/USER/.ssh/
ssh-copy-id user@<haproxy1> USD ssh-copy-id user@<cds1> USD ssh-copy-id user@<cds2>
10.5. Supported Installation Targets An installation target is a storage device that will store Red Hat Enterprise Linux and boot the system. Red Hat Enterprise Linux supports the following installation targets for AMD64 and Intel 64 systems: Storage connected by a standard internal interface, such as SCSI, SATA, or SAS Fibre Channel Host Bus Adapters and multipath devices. Some can require vendor-provided drivers. Virtualized installation on IBM Power Systems servers is also supported when using Virtual SCSI (vSCSI) adapters in virtual client LPARs Red Hat does not support installation to USB drives or SD memory cards. For information about the support for third-party virtualization technologies, see the Red Hat Hardware Compatibility List , available online at https://hardware.redhat.com . Important On IBM Power Systems servers, the eHEA module fails to initialize if 16GB huge pages are assigned to a system or partition and the kernel command line does not contain the huge page parameters. Therefore, when you perform a network installation through an IBM eHEA ethernet adapter, you cannot assign huge pages to the system or partition during the installation. Use large pages instead.

Commands:
Chapter 5. Configuring the Nagios Plugins for Ceph Configure the Nagios plug-ins for Red Hat Ceph Storage cluster. Prerequisites Root-level access to the Ceph Monitor host and Nagios Core Server. A running Red Hat Ceph Storage cluster. Procedure Log in to the Ceph monitor host and create a Ceph key and keyring for Nagios. Example Each plug-in will require authentication. Repeat this procedure for each host that contains a plug-in. Add a command for the check_ceph_health plug-in: Example Enable and restart the nrpe service: Example Repeat this procedure for each Ceph plug-in applicable to the host. Return to the Nagios Core server and define a check_nrpe command for the NRPE plug-in: Example Syntax On the Nagios Core server, edit the configuration file for the node and add a service for the Ceph plug-in. Example Syntax Replace HOSTNAME with the hostname of the Ceph host you want to monitor. Example Note The check_command setting uses check_nrpe! before the Ceph plug-in name. This tells NRPE to execute the check_ceph_health command on the remote node. Repeat this procedure for each plug-in applicable to the host. Restart the Nagios Core server: Example Before proceeding with additional configuration, ensure that the plug-ins are working on the Ceph host: Syntax Example Note The check_ceph_health plug-in performs the equivalent of the ceph health command. Additional Resources See Nagios plugins for Ceph for more information about Ceph Nagios plug-ins usage.

Commands:
ssh user@host01 [user@host01 ~]USD sudo su - cd /etc/ceph ceph auth get-or-create client.nagios mon 'allow r' > client.nagios.keyring
vi /usr/local/nagios/etc/nrpe.cfg
command[check_ceph_health]=/usr/lib/nagios/plugins/check_ceph_health --id nagios --keyring /etc/ceph/client.nagios.keyring
systemctl enable nrpe systemctl restart nrpe
cd /usr/local/nagios/etc/objects vi commands.cfg
define command{ command_name check_nrpe command_line USDUSER1USD/check_nrpe -H USDHOSTADDRESSUSD -c USDARG1USD }
vi /usr/local/nagios/etc/objects/host01.cfg
define service { use generic-service host_name HOSTNAME service_description Ceph Health Check check_command check_nrpe!check_ceph_health }
define service { use generic-service host_name host01 service_description Ceph Health Check check_command check_nrpe!check_ceph_health }
systemctl restart nagios
/usr/lib/nagios/plugins/check_ceph_health --id NAGIOS_USER --keyring /etc/ceph/client.nagios.keyring
/usr/lib/nagios/plugins/check_ceph_health --id nagios --keyring /etc/ceph/client.nagios.keyring HEALTH OK
Chapter 9. Integrating with Google Cloud Storage You can integrate with Google Cloud Storage (GCS) to enable data backups. You can use these backups for data restoration in the case of an infrastructure disaster, or corrupt data. After you integrate with GCS, you can schedule daily or weekly backups and do manual on-demand backups. The backup includes the Red Hat Advanced Cluster Security for Kubernetes entire database, which includes all configurations, resources, events, and certificates. Make sure that backups are stored securely. Note If you are using Red Hat Advanced Cluster Security for Kubernetes version 3.0.53 or older, the backup does not include certificates. 9.1. Configuring Red Hat Advanced Cluster Security for Kubernetes To configure data backups on Google Cloud Storage (GCS), create an integration in Red Hat Advanced Cluster Security for Kubernetes. Prerequisites An existing bucket . To create a new bucket, see the official Google Cloud Storage documentation topic Creating storage buckets . A service account with the Storage Object Admin IAM role in the storage bucket you want to use. See Using Cloud IAM permissions for more information. Either a workload identity or a Service account key (JSON) for the service account. See Creating a service account and Creating service account keys for more information. Procedure In the RHACS portal, go to Platform Configuration Integrations . Scroll down to the External backups section and select Google Cloud Storage . Click New Integration ( add icon). Enter a name for Integration Name . Enter the number of backups to retain in the Backups To Retain box. For Schedule , select the backup frequency (daily or weekly) and the time to run the backup process. Enter the Bucket name in which you want to store the backup. When using a workload identity, check Use workload identity . Otherwise, enter the contents of your service account key file into the Service account key (JSON) field. Select Test to confirm that the integration with GCS is working. Select Create to generate the configuration. Once configured, Red Hat Advanced Cluster Security for Kubernetes automatically backs up all data according to the specified schedule. 9.1.1. Perform on-demand backups on Google Cloud Storage Uses the RHACS portal to trigger manual backups of Red Hat Advanced Cluster Security for Kubernetes on Google Cloud Storage. Prerequisites You must have already integrated Red Hat Advanced Cluster Security for Kubernetes with Google Cloud Storage. Procedure In the RHACS portal, go to Platform Configuration Integrations . Under the External backups section, click Google Cloud Storage . Select the integration name for the GCS bucket in which you want to do a backup. Click Trigger Backup . Note Currently, when you select the Trigger Backup option, there is no notification. However, Red Hat Advanced Cluster Security for Kubernetes begins the backup task in the background. 9.1.1.1. Additional resources Backing up Red Hat Advanced Cluster Security for Kubernetes Restoring from a backup

Commands:
Chapter 36. System and Subscription Management The yum updateinfo commands now respect skip_if_unavailable option If a repository was configured with the skip_if_unavailable=1 option, the yum commands operating on the updateinfo metadata, such as yum updateinfo or yum check-update --security , did not work correctly. Consequently, yum terminated with an error instead of skipping the repository. With this update, the underlying source code has been fixed to respect the skip_if_unavailable option. As a result, the affected yum commands now skip the unavailable repository as expected under the described circumstances. (BZ#1528608)

Commands:
10.5.19. ServerName ServerName specifies a hostname and port number (matching the Listen directive) for the server. The ServerName does not need to match the machine's actual hostname. For example, the Web server may be www.example.com , but the server's hostname is actually foo.example.com . The value specified in ServerName must be a valid Domain Name Service (DNS) name that can be resolved by the system - do not make something up. The following is a sample ServerName directive: When specifying a ServerName , be sure the IP address and server name pair are included in the /etc/hosts file.

Commands:
ServerName www.example.com:80
Chapter 1. Dynamically provisioned OpenShift Data Foundation deployed on AWS 1.1. Replacing operational or failed storage devices on AWS user-provisioned infrastructure When you need to replace a device in a dynamically created storage cluster on an AWS user-provisioned infrastructure, you must replace the storage node. For information about how to replace nodes, see: Replacing an operational AWS node on user-provisioned infrastructure . Replacing a failed AWS node on user-provisioned infrastructure . 1.2. Replacing operational or failed storage devices on AWS installer-provisioned infrastructure When you need to replace a device in a dynamically created storage cluster on an AWS installer-provisioned infrastructure, you must replace the storage node. For information about how to replace nodes, see: Replacing an operational AWS node on installer-provisioned infrastructure . Replacing a failed AWS node on installer-provisioned infrastructure .

Commands:
6.4. CPU Quality of Service CPU quality of service defines the maximum amount of processing capability a virtual machine can access on the host on which it runs, expressed as a percent of the total processing capability available to that host. Assigning CPU quality of service to a virtual machine allows you to prevent the workload on one virtual machine in a cluster from affecting the processing resources available to other virtual machines in that cluster. 6.4.1. Creating a CPU Quality of Service Entry Create a CPU quality of service entry. Creating a CPU Quality of Service Entry Click Compute Data Centers . Click a data center's name to open the details view. Click the QoS tab. Under CPU , click New . Enter a QoS Name and a Description for the quality of service entry. Enter the maximum processing capability the quality of service entry permits in the Limit (%) field. Do not include the % symbol. Click OK . You have created a CPU quality of service entry, and can create CPU profiles based on that entry in clusters that belong to the data center. 6.4.2. Removing a CPU Quality of Service Entry Remove an existing CPU quality of service entry. Removing a CPU Quality of Service Entry Click Compute Data Centers . Click a data center's name to open the details view. Click the QoS tab. Under CPU , select a CPU quality of service entry and click Remove . Click OK . If any CPU profiles were based on that entry, the CPU quality of service entry for those profiles is automatically set to [unlimited] .

Commands:
2.2.3.2. Use a Password-like NIS Domain Name and Hostname Any machine within a NIS domain can use commands to extract information from the server without authentication, as long as the user knows the NIS server's DNS hostname and NIS domain name. For instance, if someone either connects a laptop computer into the network or breaks into the network from outside (and manages to spoof an internal IP address), the following command reveals the /etc/passwd map: ypcat -d <NIS_domain> -h <DNS_hostname> passwd If this attacker is a root user, they can obtain the /etc/shadow file by typing the following command: ypcat -d <NIS_domain> -h <DNS_hostname> shadow Note If Kerberos is used, the /etc/shadow file is not stored within a NIS map. To make access to NIS maps harder for an attacker, create a random string for the DNS hostname, such as o7hfawtgmhwg.domain.com . Similarly, create a different randomized NIS domain name. This makes it much more difficult for an attacker to access the NIS server.

Commands:
A.6. Virtualization Logs The following methods can be used to access logged data about events on your hypervisor and your guests. This can be helpful when troubleshooting virtualization on your system. Each guest has a log, saved in the /var/log/libvirt/qemu/ directory. The logs are named GuestName .log and are periodically compressed when a size limit is reached. To view libvirt events in the systemd Journal , use the following command: # journalctl _SYSTEMD_UNIT=libvirtd.service The auvirt command displays audit results related to guests on your hypervisor. The displayed data can be narrowed down by selecting specific guests, time frame, and information format. For example, the following command provides a summary of events on the testguest virtual machine on the current day. You can also configure auvirt information to be automatically included in the systemd Journal. To do so, edit the /etc/libvirt/libvirtd.conf file and set the value of the audit_logging parameter to 1 . For more information, see the auvirt man page. If you encounter any errors with the Virtual Machine Manager, you can review the generated data in the virt-manager.log file in the USDHOME/.virt-manager/ directory. For audit logs of the hypervisor system, see the /var/log/audit/audit.log file. Depending on the guest operating system, various system log files may also be saved on the guest. For more information about logging in Red Hat Enterprise Linux, see the System Administrator's Guide .

Commands:
auvirt --start today --vm testguest --summary Range of time for report: Mon Sep 4 16:44 - Mon Sep 4 17:04 Number of guest starts: 2 Number of guest stops: 1 Number of resource assignments: 14 Number of related AVCs: 0 Number of related anomalies: 0 Number of host shutdowns: 0 Number of failed operations: 0
Chapter 6. Creating Ansible playbooks with the all-in-one Red Hat OpenStack Platform environment The deployment command applies Ansible playbooks to the environment automatically. However, you can modify the deployment command to generate Ansible playbooks without applying them to the deployment, and run the playbooks later. Include the --output-only option in the deploy command to generate the standalone-ansible-XXXXX directory. This directory contains a set of Ansible playbooks that you can run on other hosts. Procedure To generate the Ansible playbook directory, enter the deploy command with the option --output-only : To run the Ansible playbooks, enter the ansible-playbook command, and include the inventory.yaml file and the deploy_steps_playbook.yaml file:

Commands:
[stack@all-in-one]USD sudo openstack tripleo deploy --templates --local-ip=USDIP/USDNETMASK -e /usr/share/openstack-tripleo-heat-templates/environments/standalone/standalone-tripleo.yaml -r /usr/share/openstack-tripleo-heat-templates/roles/Standalone.yaml -e USDHOME/containers-prepare-parameters.yaml -e USDHOME/standalone_parameters.yaml --output-dir USDHOME --standalone --output-only
[stack@all-in-one]USD cd standalone-ansible-XXXXX [stack@all-in-one]USD sudo ansible-playbook -i inventory.yaml deploy_steps_playbook.yaml