mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 3. Using the automation controller Dashboard for IT orchestration The Dashboard offers a graphical framework for your IT orchestration needs. Use the navigation menu to complete the following tasks: Display different views Go to your resources Grant users access Administer automation controller features in the UI 3.1. Viewing the Dashboard Procedure Click the Menu icon to hide or display the navigation panel. On the main dashboard, a summary appears listing your current Job status . You can filter the job status within a period of time or by job type. You can view summaries of Recent Jobs and Recent Templates in their respective tabs. The last item in the navigation panel is Settings , which provides access to automation controller configuration settings. The Settings page allows administrators to configure the following settings: Authentication Jobs System-level attributes Customize the UI, and product license information For more information, see Automation controller Configuration in the Automation controller Administration Guide . Note To launch a simple playbook, you must set up a number of configuration options. Completing the getting started configuration tasks now ensures that automation controller is configured properly and permits easier executions of more involved playbooks later on.

Commands:
function::user_ulong_warn Name function::user_ulong_warn - Retrieves an unsigned long value stored in user space Synopsis Arguments addr the user space address to retrieve the unsigned long from Description Returns the unsigned long value from a given user space address. Returns zero when user space and warns (but does not abort) about the failure. Note that the size of the unsigned long depends on the architecture of the current user space task (for those architectures that support both 64/32 bit compat tasks).

Commands:
user_ulong_warn:long(addr:long)
Chapter 3. Red Hat Enterprise Linux Atomic Host 7.8.2 3.1. Atomic Host OStree update : New Tree Version: 7.8.2 (hash: 12729cf41c00b566cc5618247027648f8b867409728be9d263743e52472a3560) Changes since Tree Version 7.8.1 (hash: 78a6301dcd4ba61e6703e336e9b3bc0f855e6d442aa4d4ce88e3ea11e975feec) 3.2. Extras Updated packages : conmon-2.0.15-1.el7_8 container-selinux-2.119.2-1.911c772.el7_8 containernetworking-plugins-0.8.3-3.el7_8 dpdk-18.11.8-1.el7_8 rhel-system-roles-1.0-12.el7_8 skopeo-0.1.40-11.el7_8 3.2.1. Container Images Updated : Red Hat Enterprise Linux 7 Init Container Image (rhel7/rhel7-init) Red Hat Enterprise Linux 7.8 Container Image (rhel7.8, rhel7, rhel7/rhel, rhel) Red Hat Enterprise Linux Atomic Identity Management Server Container Image (rhel7/ipa-server) Red Hat Enterprise Linux Atomic Image (rhel-atomic, rhel7-atomic, rhel7/rhel-atomic) Red Hat Enterprise Linux Atomic Net-SNMP Container Image (rhel7/net-snmp) Red Hat Enterprise Linux Atomic OpenSCAP Container Image (rhel7/openscap) Red Hat Enterprise Linux Atomic SSSD Container Image (rhel7/sssd) Red Hat Enterprise Linux Atomic Support Tools Container Image (rhel7/support-tools) Red Hat Enterprise Linux Atomic Tools Container Image (rhel7/rhel-tools) Red Hat Enterprise Linux Atomic cockpit-ws Container Image (rhel7/cockpit-ws) Red Hat Enterprise Linux Atomic etcd Container Image (rhel7/etcd) Red Hat Enterprise Linux Atomic flannel Container Image (rhel7/flannel) Red Hat Enterprise Linux Atomic open-vm-tools Container Image (rhel7/open-vm-tools) Red Hat Enterprise Linux Atomic rsyslog Container Image (rhel7/rsyslog) Red Hat Enterprise Linux Atomic sadc Container Image (rhel7/sadc) Red Hat Universal Base Image 7 Container Image (rhel7/ubi7) Red Hat Universal Base Image 7 Init Container Image (rhel7/ubi7-init) Red Hat Universal Base Image 7 Minimal Container Image (rhel7/ubi7-minimal)

Commands:
Appendix C. Using AMQ Broker with the examples The AMQ JMS Pool examples require a running message broker with a queue named queue . Use the procedures below to install and start the broker and define the queue. C.1. Installing the broker Follow the instructions in Getting Started with AMQ Broker to install the broker and create a broker instance . Enable anonymous access. The following procedures refer to the location of the broker instance as <broker-instance-dir> . C.2. Starting the broker Procedure Use the artemis run command to start the broker. USD <broker-instance-dir> /bin/artemis run Check the console output for any critical errors logged during startup. The broker logs Server is now live when it is ready. USD example-broker/bin/artemis run __ __ ____ ____ _ /\ | \/ |/ __ \ | _ \ | | / \ | \ / | | | | | |_) |_ __ ___ | | _____ _ __ / /\ \ | |\/| | | | | | _ <| '__/ _ \| |/ / _ \ '__| / ____ \| | | | |__| | | |_) | | | (_) | < __/ | /_/ \_\_| |_|\___\_\ |____/|_| \___/|_|\_\___|_| Red Hat AMQ <version> 2020-06-03 12:12:11,807 INFO [org.apache.activemq.artemis.integration.bootstrap] AMQ101000: Starting ActiveMQ Artemis Server ... 2020-06-03 12:12:12,336 INFO [org.apache.activemq.artemis.core.server] AMQ221007: Server is now live ... C.3. Creating a queue In a new terminal, use the artemis queue command to create a queue named queue . USD <broker-instance-dir> /bin/artemis queue create --name queue --address queue --auto-create-address --anycast You are prompted to answer a series of yes or no questions. Answer N for no to all of them. Once the queue is created, the broker is ready for use with the example programs. C.4. Stopping the broker When you are done running the examples, use the artemis stop command to stop the broker. USD <broker-instance-dir> /bin/artemis stop Revised on 2020-10-08 11:28:47 UTC

Commands:
<broker-instance-dir> /bin/artemis run
example-broker/bin/artemis run __ __ ____ ____ _ /\ | \/ |/ __ \ | _ \ | | / \ | \ / | | | | | |_) |_ __ ___ | | _____ _ __ / /\ \ | |\/| | | | | | _ <| '__/ _ \| |/ / _ \ '__| / ____ \| | | | |__| | | |_) | | | (_) | < __/ | /_/ \_\_| |_|\___\_\ |____/|_| \___/|_|\_\___|_| Red Hat AMQ <version> 2020-06-03 12:12:11,807 INFO [org.apache.activemq.artemis.integration.bootstrap] AMQ101000: Starting ActiveMQ Artemis Server 2020-06-03 12:12:12,336 INFO [org.apache.activemq.artemis.core.server] AMQ221007: Server is now live
<broker-instance-dir> /bin/artemis queue create --name queue --address queue --auto-create-address --anycast
<broker-instance-dir> /bin/artemis stop
9.5.2. File Permissions Once the NFS file system is mounted read/write by a remote host, the only protection each shared file has is its permissions. If two users that share the same user ID value mount the same NFS file system, they can modify each others files. Additionally, anyone logged in as root on the client system can use the su - command to become a user who could access particular files via the NFS share. For more on NFS and user ID conflicts, refer to the chapter titled Managing User Accounts and Resource Access in the Red Hat Enterprise Linux Introduction to System Adminitration . By default, access control lists (ACLs) are supported by NFS under Red Hat Enterprise Linux. It is not recommended that this feature be disabled. For more about this feature, refer to the chapter titled Network File System (NFS) in the System Administrators Guide . The default behavior when exporting a file system via NFS is to use root squashing . This sets the user ID of anyone accessing the NFS share as the root user on their local machine to a value of the server's nfsnobody account. Never turn off root squashing. If exporting an NFS share as read-only, consider using the all_squash option, which makes every user accessing the exported file system take the user ID of the nfsnobody user.

Commands:
1.2. Red Hat Certificate System and the Enterprise Security Client Red Hat Certificate System creates, manages, renews, and revokes certificates and keys. For managing smart cards, the Certificate System has a token management system to generate keys, create certificate requests, and receive certificates. Two subsystems - the Token Key Service (TKS) and Token Processing System (TPS) - are used to process token-related operations. The Enterprise Security Client is the interface which allows the smart card and user to access the token management system. A total of four Certificate System subsystems are involved with managing tokens, two for managing the tokens (TKS and TPS) and two for managing the keys and certificates within the public-key infrastructure (CA and DRM). The Token Processing System (TPS) interacts with smart cards to help them generate and store keys and certificates for a specific entity, such as a user or device. Smart card operations go through the TPS and are forwarded to the appropriate subsystem for action, such as the Certificate Authority to generate certificates or the Data Recovery Manager to archive and recover keys. The Token Key Service (TKS) generates, or derives, symmetric keys used for communication between the TPS and smart card. Each set of keys generated by the TKS is unique because they are based on the card's unique ID. The keys are formatted on the smart card and are used to encrypt communications, or provide authentication, between the smart card and TPS. The Certificate Authority (CA) creates and revokes user certificates stored on the smart card. Optionally, the Data Recovery Manager (DRM) archives and recovers keys for the smart card. Figure 1.1. How Certificate System Manages Smart Cards As Figure 1.1, "How Certificate System Manages Smart Cards" shows, the TPS is the central hub in the Red Hat Certificate System token management system. The token communicates with the TPS directly. The TPS then communicates with the TKS to derive a set of unique keys that can be used for TPS-token communication (1). When the smart card is enrolled, new private keys are created for the token; those keys can be archived in a DRM (2), if key archival is configured. The CA then processes the certificate request (3) and issues the certificates to store on the token. The TPS sends those certificates back to the Enterprise Security Client (4), and they are saved to the token. The Enterprise Security Client is the conduit through which TPS communicates with each token over a secure HTTP channel (HTTPS), and, through the TPS, with the Certificate System. To use the tokens, the Token Processing System must be able to recognize and communicate with them. The tokens must first be enrolled to populate the tokens with required keys and certificates and add the tokens to the Certificate System. The Enterprise Security Client provides the user interface for users to format and manage smart cards.

Commands:
5.4. System Specifications List The installation program automatically detects and installs your computer's hardware and you do not usually need to supply the installation program with any specific details about your system. However, when performing certain types of installation, it is important to know specific details about your hardware. For this reason, it is recommended that you record the following system specifications for reference during the installation, depending on your installation type. If you plan to use a customized partition layout, record: The model numbers, sizes, types, and interfaces of the hard drives attached to the system. For example, Seagate ST3320613AS 320 GB on SATA0, Western Digital WD7500AAKS 750 GB on SATA1. This will allow you to identify specific hard drives during the partitioning process. If you are installing Red Hat Enterprise Linux as an additional operating system on an existing system, record: Information about the partitions used on the system. This information can include file system types, device node names, file system labels, and sizes. This will allow you to identify specific partitions during the partitioning process. Remember that different operating systems identify partitions and drives differently, therefore even if the other operating system is a Unix operating system, the device names can be reported by Red Hat Enterprise Linux differently. This information can usually be found by executing the equivalent of the mount command and blkid command and in the /etc/fstab file. If you have other operating systems already installed, the Red Hat Enterprise Linux 7 installation program attempts to automatically detect and configure to boot them. You can manually configure any additional operating systems if they are not detected properly. For more information, see Section 8.14.1, "Boot Loader Installation" . If you plan to install from an image on a local hard drive: The hard drive and directory that holds the image. If you plan to install from a network location: The make and model numbers of the network adapters on your system. For example, Netgear GA311. This will allow you to identify adapters when manually configuring the network. IP, DHCP, and BOOTP addresses Netmask Gateway IP address One or more name server IP addresses (DNS) The location of the installation source on an FTP server, HTTP (web) server, HTTPS (web) server, or NFS server. If any of these networking requirements or terms are unfamiliar to you, contact your network administrator for assistance. If you plan to install on an iSCSI target: The location of the iSCSI target. Depending on your network, you might also need a CHAP user name and password, and perhaps a reverse CHAP user name and password. If your computer is part of a domain: You should verify that the domain name will be supplied by the DHCP server. If not, you will need to input the domain name manually during installation.

Commands:
4.2. Configuring Static Routes Using nmcli To configure static routes using the nmcli tool, use one of the following: the nmcli command line the nmcli interactive editor Example 4.1. Configuring Static Routes Using nmcli To configure a static route for an existing Ethernet connection using the command line: This will direct traffic for the 192.168.122.0/24 subnet to the gateway at 10.10.10.1 Example 4.2. Configuring Static Routes with nmcli Editor To configure a static route for an Ethernet connection using the interactive editor:

Commands:
~]# nmcli connection modify enp1s0 +ipv4.routes "192.168.122.0/24 10.10.10.1"
~]USD nmcli con edit ens3 ===| nmcli interactive connection editor |=== Editing existing '802-3-ethernet' connection: 'ens3' Type 'help' or '?' for available commands. Type 'describe [<setting>.<prop>]' for detailed property description. You may edit the following settings: connection, 802-3-ethernet (ethernet), 802-1x, dcb, ipv4, ipv6, tc, proxy nmcli> set ipv4.routes 192.168.122.0/24 10.10.10.1 nmcli> save persistent Connection 'ens3' (23f8b65a-8f3d-41a0-a525-e3bc93be83b8) successfully updated. nmcli> quit
5.3.2. Present-Day Industry-Standard Interfaces Unlike the proprietary interfaces mentioned in the section, some interfaces were more widely adopted, and turned into industry standards. Two interfaces in particular have made this transition and are at the heart of today's storage industry: IDE/ATA SCSI 5.3.2.1. IDE/ATA IDE stands for Integrated Drive Electronics. This interface originated in the late 80s, and uses a 40-pin connector. Note Actually, the proper name for this interface is the "AT Attachment" interface (or ATA), but use of the term "IDE" (which actually refers to an ATA-compatible mass storage device) is still used to some extent. However, the remainder of this section uses the interface's proper name -- ATA. ATA implements a bus topology, with each bus supporting two mass storage devices. These two devices are known as the master and the slave . These terms are misleading, as it implies some sort of relationship between the devices; that is not the case. The selection of which device is the master and which is the slave is normally selected through the use of jumper blocks on each device. Note A more recent innovation is the introduction of cable select capabilities to ATA. This innovation requires the use of a special cable, an ATA controller, and mass storage devices that support cable select (normally through a "cable select" jumper setting). When properly configured, cable select eliminates the need to change jumpers when moving devices; instead, the device's position on the ATA cable denotes whether it is master or slave. A variation of this interface illustrates the unique ways in which technologies can be mixed and also introduces our industry-standard interface. ATAPI is a variation of the ATA interface and stands for AT Attachment Packet Interface. Used primarily by CD-ROM drives, ATAPI adheres to the electrical and mechanical aspects of the ATA interface but uses the communication protocol from the interface discussed -- SCSI.

Commands:
8.231. syslinux 8.231.1. RHBA-2014:1461 - syslinux bug fix update Updated syslinux packages that fix several bugs are now available for Red Hat Enterprise Linux 6. The syslinux packages provide a suite of boot loaders, currently supporting DOS FAT file systems, Linux ext2 and ext3 file systems (EXTLINUX), PXE network boots (PXELINUX), or ISO 9660 CD-ROMs (ISOLINUX). It also includes a tool, MEMDISK, which loads legacy operating systems from these media. This update also fixes the following bugs: Note The syslinux packages have been upgraded to upstream version 4.04, which provides a number of bug fixes over the version, including a patch that corrects the PXE chain functionality. (BZ# 970946 ) This update also fixes the following bugs: Bug Fixes BZ# 980671 , BZ# 1085780 The pxelinux.0 file incorrectly used a BIOS interrupt call when booting up from a local hard drive through the Pre-Boot Execution Environment (PXE). As a consequence, the booting process became unresponsive. With this update, the behavior of pxelinux.0 has been fixed and PXE booting now functions as expected. BZ# 989867 The syslinux-tftpboot program incorrectly installed tftp files into the /tftpboot/ directory. Consequently, these files could not be located and used by the appropriate programs, such as tftp. With this update, tftp files are installed into the /var/lib/tftpboot/ directory as expected. The syslinux packages have been upgraded to upstream version 4.04, which provides a number of bug fixes over the version, including a patch that corrects the PXE chain functionality. (BZ#970946) Users of syslinux are advised to upgrade to these updated packages, which fix these bugs.

Commands:
probe::linuxmib.ListenOverflows Name probe::linuxmib.ListenOverflows - Count of times a listen queue overflowed Synopsis linuxmib.ListenOverflows Values sk Pointer to the struct sock being acted on op Value to be added to the counter (default value of 1) Description The packet pointed to by skb is filtered by the function linuxmib_filter_key . If the packet passes the filter is is counted in the global ListenOverflows (equivalent to SNMP's MIB LINUX_MIB_LISTENOVERFLOWS)

Commands:
Chapter 6. Reviewing monitoring dashboards OpenShift Container Platform 4.7 provides a comprehensive set of monitoring dashboards that help you understand the state of cluster components and user-defined workloads. In the Administrator perspective you can access dashboards for core OpenShift Container Platform components, including: API performance etcd Kubernetes compute resources Kubernetes network resources Prometheus USE method dashboards relating to cluster and node performance Figure 6.1. Example dashboard in the Administrator perspective In the Developer perspective you can access dashboards that provide the following statistics for a selected project: CPU usage Memory usage Bandwidth information Packet rate information Figure 6.2. Example dashboard in the Developer perspective Note In the Developer perspective, you can view dashboards for only one project at a time. 6.1. Reviewing monitoring dashboards as a cluster administrator In the Administrator perspective, you can view dashboards relating to core OpenShift Container Platform cluster components. Prerequisites You have access to the cluster as a user with the cluster-admin role. Procedure In the Administrator perspective in the OpenShift Container Platform web console, navigate to Monitoring Dashboards . Choose a dashboard in the Dashboard list. Some dashboards, such as etcd and Prometheus dashboards, produce additional sub-menus when selected. Optional: Select a time range for the graphs in the Time Range list. Optional: Select a Refresh Interval . Hover over each of the graphs within a dashboard to display detailed information about specific items. 6.2. Reviewing monitoring dashboards as a developer In the Developer perspective, you can view dashboards relating to a selected project. You must have access to monitor a project to view dashboard information for it. Prerequisites You have access to the cluster as a developer or as a user with view permissions for the project that you are viewing the dashboard for. Procedure In the Developer perspective in the OpenShift Container Platform web console, navigate to Monitoring Dashboard . Choose a project in the Project: list. Choose a workload in the All Workloads list. Optional: Select a time range for the graphs in the Time Range list. Optional: Select a Refresh Interval . Hover over each of the graphs within a dashboard to display detailed information about specific items. Additional resources Monitoring project and application metrics using the Developer perspective 6.3. steps Accessing third-party UIs

Commands:
Chapter 5. Kernel Module Management Operator release notes 5.1. Release notes for Kernel Module Management Operator 2.2 5.1.1. New features KMM is now using the CRI-O container engine to pull container images in the worker pod instead of using HTTP calls directly from the worker container. For more information, see Example Module CR . The Kernel Module Management (KMM) Operator images are now based on rhel-els-minimal container images instead of the rhel-els images. This change results in a greatly reduced image footprint, while still maintaining FIPS compliance. In this release, the firmware search path has been updated to copy the contents of the specified path into the path specified in worker.setFirmwareClassPath (default: /var/lib/firmware). For more information, see Example Module CR . For each node running a kernel matching the regular expression, KMM now checks if you have included a tag or a digest. If you have not specified a tag or digest in the container image, then the validation webhook returns an error and does not apply the module. For more information, see Example Module CR . 5.2. Release notes for Kernel Module Management Operator 2.3 5.2.1. New features In this release, KMM uses version 1.23 of the Golang programming language to ensure test continuity for partners. You can now schedule KMM pods by defining taints and tolerations. For more information, see Using tolerations for kernel module scheduling .

Commands:
4.42. cyrus-imapd 4.42.1. RHBA-2012:0708 - cyrus-imapd bug fix update Updated cyrus-imapd packages that fix one bug are now available for Red Hat Enterprise Linux 6. The cyrus-imapd packages contain a high-performance mail server with IMAP, POP3, NNTP, and SIEVE support. Bug Fix BZ# 818209 Previously, the idled daemon incorrectly used signals for communication with the imapd daemon. This could cause a user's mailbox to become unresponsive. To prevent this problem, idled no longer uses signals to communicate with imapd; the AF_UNIX datagram sockets are now used instead. All users of cyrus-imapd are advised to upgrade to these updated packages, which fix this bug.

Commands: