mtpti5iD/redhat-docs_dataset huggingface dataset:
3.9. Additional Configuration for the Active Directory Domain Entry Custom settings for each individual domain can be defined in the /etc/realmd.conf file. Each domain can have its own configuration section; the name of the section must match the domain name. For example: Important Changing the configuration as described in this section only works if the realm join command has not been run yet. If a system is already joined, changing these settings does not have any effect. In such situations, you must leave the domain, as described in Section 3.5, "Removing a System from an Identity Domain" , and then join again, as described in the section called "Joining a Domain" . Note that joining requires the domain administrator's credentials. To change the configuration for a domain, edit the corresponding section in /etc/realmd.conf . The following example disables ID mapping for the ad.example.com domain, sets the host principal, and adds the system to the specified subtree: Note that the same configuration can also be set when originally joining the system to the domain using the realm join command, described in the section called "Joining a Domain" : Table 3.2, "Realm Configuration Options" lists the most notable options that can be set in the domain default section in /etc/realmd.conf . For complete information about the available configuration options, see the realmd.conf (5) man page. Table 3.2. Realm Configuration Options Option Description computer-ou Sets the directory location for adding computer accounts to the domain. This can be the full DN or an RDN, relative to the root entry. The subtree must already exist. user-principal Sets the userPrincipalName attribute value of the computer account to the provided Kerberos principal. automatic-id-mapping Sets whether to enable dynamic ID mapping or disable the mapping and use POSIX attributes configured in Active Directory.

Commands:
[ad.example.com] attribute = value attribute = value
[ad.example.com] computer-ou = ou=Linux Computers,DC=domain,DC=example,DC=com user-principal = host/linux-client@AD.EXAMPLE.COM automatic-id-mapping = no
realm join --computer-ou= "ou=Linux Computers,dc=domain,dc=com" --automatic-id-mapping= no --user-principal= host/linux-client@AD.EXAMPLE.COM
4.8. Egenera BladeFrame Table 4.9, "Egenera BladeFrame" lists the fence device parameters used by fence_egenera , the fence agent for the Egenera BladeFrame. Table 4.9. Egenera BladeFrame luci Field cluster.conf Attribute Description Name name A name for the Egenera BladeFrame device connected to the cluster. CServer cserver The host name (and optionally the user name in the form of username@hostname ) assigned to the device. Refer to the fence_egenera (8) man page for more information. ESH Path (optional) esh The path to the esh command on the cserver (default is /opt/panmgr/bin/esh) Username user The login name. The default value is root . lpan lpan The logical process area network (LPAN) of the device. pserver pserver The processing blade (pserver) name of the device. Delay (optional) delay The number of seconds to wait before fencing is started. The default value is 0. Unfencing unfence section of the cluster configuration file When enabled, this ensures that a fenced node is not re-enabled until the node has been rebooted. This is necessary for non-power fence methods (that is, SAN/storage fencing). When you configure a device that requires unfencing, the cluster must first be stopped and the full configuration including devices and unfencing must be added before the cluster is started. For more information about unfencing a node, see the fence_node (8) man page. Figure 4.8, "Egenera BladeFrame" shows the configuration screen for adding an Egenera BladeFrame fence device. Figure 4.8. Egenera BladeFrame The following command creates a fence device instance for an Egenera BladeFrame device: The following is the cluster.conf entry for the fence_egenera device:

Commands:
ccs -f cluster.conf --addfencedev egeneratest agent=fence_egenera user=root cserver=cservertest
<fencedevices> <fencedevice agent="fence_egenera" cserver="cservertest" name="egeneratest" user="root"/> </fencedevices>
Release notes OpenShift Container Platform 4.17 Highlights of what is new and what has changed with this OpenShift Container Platform release Red Hat OpenShift Documentation Team

Commands:
conditionalGathererEndpoint: https://console.redhat.com/api/gathering/v2/%s/gathering_rules
The kube-controller-manager logs might contain more details.
The cloud-controller-manager logs may contain more details.
apiVersion: v1 data: enable-nodeip-debug: "true" kind: ConfigMap metadata: name: logging namespace: openshift-vsphere-infra
2024/08/02 12:18:03 [ERROR]: [OperatorImageCollector] pinging container registry localhost:55000: Get "https://localhost:55000/v2/": http: server gave HTTP response to HTTPS client.
[ERROR] : [OperatorImageCollector] pinging container registry registry.redhat.io: Get "http://registry.redhat.io/v2/": dial tcp 23.217.255.152:80: i/o timeout
[ERROR]: Detected a v2 ImageSetConfiguration, please use --v2 instead of -v2.
controlPlane: platform: azure: {}
oc adm release info 4.17.20 --pullspecs
oc adm release info 4.17.19 --pullspecs
oc adm release info 4.17.18 --pullspecs
oc adm release info 4.17.17 --pullspecs
oc adm release info 4.17.16 --pullspecs
oc adm release info 4.17.15 --pullspecs
oc adm release info 4.17.14 --pullspecs
oc adm release info 4.17.12 --pullspecs
oc adm release info 4.17.11 --pullspecs
oc adm release info 4.17.10 --pullspecs
oc adm release info 4.17.9 --pullspecs
oc adm release info 4.17.8 --pullspecs
oc adm release info 4.17.7 --pullspecs
oc adm release info 4.17.6 --pullspecs
oc adm release info 4.17.5 --pullspecs
oc adm release info 4.17.4 --pullspecs
oc adm release info 4.17.3 --pullspecs
oc adm release info 4.17.2 --pullspecs
Invalid log bundle or the bootstrap machine could not be reached and bootstrap logs were not collected
oc adm release info 4.17.1 --pullspecs
oc adm release info 4.17.0 --pullspecs
Chapter 1. Getting started with AMQ Interconnect on OpenShift Container Platform AMQ Interconnect is a lightweight AMQP 1.0 message router for building large, highly resilient messaging networks for hybrid cloud and IoT/edge deployments. AMQ Interconnect automatically learns the addresses of messaging endpoints (such as clients, servers, and message brokers) and flexibly routes messages between them. This document describes how to deploy AMQ Interconnect on OpenShift Container Platform by using the AMQ Interconnect Operator and the Interconnect Custom Resource Definition (CRD) that it provides. The CRD defines an AMQ Interconnect deployment, and the Operator creates and manages the deployment in OpenShift Container Platform. 1.1. What Operators are Operators are a method of packaging, deploying, and managing a Kubernetes application. They take human operational knowledge and encode it into software that is more easily shared with consumers to automate common or complex tasks. In OpenShift Container Platform 4.0, the Operator Lifecycle Manager (OLM) helps users install, update, and generally manage the life cycle of all Operators and their associated services running across their clusters. It is part of the Operator Framework, an open source toolkit designed to manage Kubernetes native applications (Operators) in an effective, automated, and scalable way. The OLM runs by default in OpenShift Container Platform 4.0, which aids cluster administrators in installing, upgrading, and granting access to Operators running on their cluster. The OpenShift Container Platform web console provides management screens for cluster administrators to install Operators, as well as grant specific projects access to use the catalog of Operators available on the cluster. OperatorHub is the graphical interface that OpenShift Container Platform cluster administrators use to discover, install, and upgrade Operators. With one click, these Operators can be pulled from OperatorHub, installed on the cluster, and managed by the OLM, ready for engineering teams to self-service manage the software in development, test, and production environments. Additional resources For more information about Operators, see the OpenShift documentation . 1.2. Provided Custom Resources The AMQ Interconnect Operator provides the Interconnect Custom Resource Definition (CRD), which allows you to interact with an AMQ Interconnect deployment running on OpenShift Container Platform just like other OpenShift Container Platform API objects. The Interconnect CRD represents a deployment of AMQ Interconnect routers. The CRD provides elements for defining many different aspects of a router deployment in OpenShift Container Platform such as: Number of AMQ Interconnect routers Deployment topology Connectivity Address semantics

Commands:
4.60. file 4.60.1. RHBA-2011:0934 - file bug fix update Updated file packages that fix several bugs are now available for Red Hat Enterprise Linux 6. The file command is used to identify a particular file according to the type of data contained in the file. [Updated 7 September 2011] This update fixes a bug in which the file utility did not parse ELF (Executable and Linkable Format) binary files correctly. If an entry in the program header table contained a file offset beyond the end of file, dynamically linked files were reported as being linked statically. The file utility now recognizes files in the described scenario correctly. (BZ# 730336 ) Bug Fixes BZ# 676045 , BZ# 712992 , BZ# 712988 Prior to this update, the file utility could have been unable to recognize RPM files for certain supported architectures. This update improves the file type recognition, and the RPM files for all supported architectures are now correctly identified as expected. BZ# 688700 Prior to this update, the file utility did not correctly recognized the IBM System z kernel images. This problem has been corrected so that the IBM System z kernel images are now correctly recognized as expected. BZ# 692098 Prior to this update, the file utility attempted to show information related to core dumps for binary files that were not core dumps. This undesired behavior has been fixed in this update so that information related to core dumps is showed only for core dumps and not for the binary files which are not core dumps. BZ# 675691 Prior to this update, file patterns for LaTeX checked only the first 400 bytes of a file to determine the pattern type. This caused an incorrect pattern type recognition as some files could have contained a larger number of comments at the beginning of the file. Furthermore, file patterns which matched a Python script were tried before the LaTeX patterns and this undesired behavior could have caused an incorrect pattern type recognition as LaTeX files could have included a source code written in Python. With this update, the aforementioned problems have been fixed by increasing the number of first bytes checked for a LaTeX file to 4096 bytes, and by trying the LaTeX patterns before the Python patterns. BZ# 690801 Prior to this update, there were several spelling mistakes contained in the magic(5) manual page. This update corrects the spelling mistakes in the respective manual page. BZ# 716665 Prior to this update, the file utility treated MP3 files as text files, and therefore was unable to recognize the MP3 files. This undesired behavior has been fixed in this update, and the file utility now treats the MP3 files as binary files and is able to properly recognize them. All users of file are advised to upgrade to these updated packages, which fix these bugs.

Commands:
Chapter 14. Log Record Fields The following fields can be present in log records exported by OpenShift Logging. Although log records are typically formatted as JSON objects, the same data model can be applied to other encodings. To search these fields from Elasticsearch and Kibana, use the full dotted field name when searching. For example, with an Elasticsearch /_search URL , to look for a Kubernetes pod name, use /_search/q=kubernetes.pod_name:name-of-my-pod . The top level fields may be present in every record.

Commands:
2.8. Programmatic Control Red Hat JBoss Data Virtualization exposes a bean that implements the org.teiid.events.EventDistributor interface. You can find it in JNDI under the name teiid/event-distributor-factory. The EventDistributor exposes methods like dataModification (which affects result set caching) or updateMatViewRow (which affects internal materialization) to alert the Teiid engine that the underlying source data has been modified. These operations, which work cluster wide will invalidate the cache entries appropriately and reload the new cache contents. Note If your source system has any built-in change data capture facilities that can scrape logs, install triggers and so forth to capture data change events, they can be captured and propagated to the Red Hat JBoss Data Virtualization engine through a pojo bean/MDB/Session bean. This code shows how you can use the EventDistributor interface in their own code that is deployed in the same JBoss EAP virtual machine using a Pojo/MDB/Session Bean: Important The EventDistributor interface also exposes many methods that can be used to update the costing information on your source models for optimized query planning. Note that these values are volatile and will be lost during a cluster re-start, as there is no repository to persist.

Commands:
public class ChanageDataCapture { public void invalidate() { InitialContext ic = new InitialContext(); EventDistributor ed = ((EventDistributorFactory)ic.lookup("teiid/event-distributor-factory")).getEventDistributor(); // this below line indicates that Customer table in the "model-name" schema has been changed. // this result in cache reload. ed.dataModification("vdb-name", "version", "model-name", "Customer"); } }
Chapter 5. Device Drivers This chapter provides a comprehensive listing of all device drivers that are new or have been updated in Red Hat Enterprise Linux 7. 5.1. New Drivers Graphics Drivers and Miscellaneous Drivers halt poll cpuidle driver (cpuidle-haltpoll.ko.xz) Intel(R) Trace Hub controller driver (intel_th.ko.xz) Intel(R) Trace Hub ACPI controller driver (intel_th_acpi.ko.xz) Intel(R) Trace Hub Global Trace Hub driver (intel_th_gth.ko.xz) Intel(R) Trace Hub Memory Storage Unit driver (intel_th_msu.ko.xz) Intel(R) Trace Hub PCI controller driver (intel_th_pci.ko.xz) Intel(R) Trace Hub PTI/LPP output driver (intel_th_pti.ko.xz) Intel(R) Trace Hub Software Trace Hub driver (intel_th_sth.ko.xz) dummy_stm device (dummy_stm.ko.xz) stm_console driver (stm_console.ko.xz) System Trace Module device class (stm_core.ko.xz) stm_ftrace driver (stm_ftrace.ko.xz) stm_heartbeat driver (stm_heartbeat.ko.xz) Basic STM framing protocol driver (stm_p_basic.ko.xz) MIPI SyS-T STM framing protocol driver (stm_p_sys-t.ko.xz) Network Drivers gVNIC Driver (gve.ko.xz): 1.0.0. Failover driver for Paravirtual drivers (net_failover.ko.xz) 5.2. Updated Drivers Network Driver Updates Emulex OneConnect NIC Driver (be2net.ko.xz) has been updated to version 12.0.0.0r. Intel(R) Ethernet Connection XL710 Network Driver (i40e.ko.xz) has been updated to version 2.8.20-k. The Netronome Flow Processor (NFP) driver (nfp.ko.xz) has been updated to version 3.10.0-1122.el7.x86_64. Storage Driver Updates QLogic FCoE Driver (bnx2fc.ko.xz) has been updated to version 2.12.10. Driver for HP Smart Array Controller version (hpsa.ko.xz) has been updated to version 3.4.20-170-RH4. Emulex LightPulse Fibre Channel SCSI driver (lpfc.ko.xz) has been updated to version 0:12.0.0.13. Broadcom MegaRAID SAS Driver (megaraid_sas.ko.xz) has been updated to version 07.710.50.00-rh1. LSI MPT Fusion SAS 3.0 Device Driver (mpt3sas.ko.xz) has been updated to version 31.100.01.00. QLogic QEDF 25/40/50/100Gb FCoE Driver (qedf.ko.xz) has been updated to version 8.37.25.20. QLogic FastLinQ 4xxxx iSCSI Module (qedi.ko.xz) has been updated to version 8.37.0.20. QLogic Fibre Channel HBA Driver (qla2xxx.ko.xz) has been updated to version 10.01.00.20.07.8-k.

Commands:
Chapter 2. Program policies 2.1. Cloud Instance Type An Instance Type is a specific hardware configuration known by a unique name that will be made available to customers as part of a CCSP solution. The hardware defined in the specification can be physical, virtual, complete, or partitioned. An Instance Type may also be available in multiple configuration specifications where each configuration includes a unique name within a common naming convention. These configurations (sizes) may be certified and listed together in the Red Hat Ecosystem Certification Catalog. For more information see, SuperSet Instance Type certification If an Instance Type size configuration is above or below the limits of RHEL the other sizes within the Instance Type may still be certified. 2.2. Policy Changes Typically, Red Hat limits major revisions in the certification tests and criteria to major releases of RHEL. Red Hat may also release updates to the CCSP Instance Type for the following: Policy and/or workflow, Criteria, Minor OS releases; where new hardware support features are introduced or At any other point as deemed necessary. Only a single version of the policy is active at any one time. This current policy is effective upon its release and supersedes all versions. Note The CCSP Instance Policy Guide version applied during the certification process will be recorded in certifications upon successful completion. Changes to the workflow guide will be documented in the workflow guide errata notification and package changelog. 2.3. Original Provider Partner support of certified Instance Type is a fundamental part of Red Hat CCSP Instance type certification. All requests and information about the Instance Type to be certified, including details for the physical and virtual hardware contained within must be submitted by the original provider of the Instance Type to Red Hat. You may choose to use your own internal or outside Partners for any portion of their testing however any such arrangement are the exclusive responsibility of the CCSP Partner. Red Hat will only interact with the CCSP Partner who is responsible for submitting the certification request and Red Hat will only post original certifications that will be easily identifiable. 2.4. Submission Window New Instance Type certifications for a given, major release of RHEL can typically be submitted until the 2nd, subsequent major version of RHEL is released. Certification requests that fall outside of the window must be raised with your EPM or SA. These requests are reviewed on a case-by-case basis.

Commands:
Appendix B. Restoring Manual Changes Overwritten by a Puppet Run If your manual configuration has been overwritten by a Puppet run, you can restore the files to the state. The following example shows you how to restore a DHCP configuration file overwritten by a Puppet run. Procedure Copy the file you intend to restore. This allows you to compare the files to check for any mandatory changes required by the upgrade. This is not common for DNS or DHCP services. Check the log files to note down the md5sum of the overwritten file. For example: Restore the overwritten file: Compare the backup file and the restored file, and edit the restored file to include any mandatory changes required by the upgrade.

Commands:
cp /etc/dhcp/dhcpd.conf /etc/dhcp/dhcpd.backup
journalctl -xe /Stage[main]/Dhcp/File[/etc/dhcp/dhcpd.conf]: Filebucketed /etc/dhcp/dhcpd.conf to puppet with sum 622d9820b8e764ab124367c68f5fa3a1
puppet filebucket restore --local --bucket /var/lib/puppet/clientbucket /etc/dhcp/dhcpd.conf \ 622d9820b8e764ab124367c68f5fa3a1
Chapter 20. console This chapter describes the commands under the console command. 20.1. console log show Show server's console output Usage: Table 20.1. Positional arguments Value Summary <server> Server to show console log (name or id) Table 20.2. Command arguments Value Summary -h, --help Show this help message and exit --lines <num-lines> Number of lines to display from the end of the log (default=all) 20.2. console url show Show server's remote console URL Usage: Table 20.3. Positional arguments Value Summary <server> Server to show url (name or id) Table 20.4. Command arguments Value Summary -h, --help Show this help message and exit --novnc Show novnc console url (default) --xvpvnc Show xvpvnc console url --spice Show spice console url --rdp Show rdp console url --serial Show serial console url --mks Show webmks console url Table 20.5. Output formatter options Value Summary -f {json,shell,table,value,yaml}, --format {json,shell,table,value,yaml} The output format, defaults to table -c COLUMN, --column COLUMN Specify the column(s) to include, can be repeated Table 20.6. JSON formatter options Value Summary --noindent Whether to disable indenting the json Table 20.7. Shell formatter options Value Summary --prefix PREFIX Add a prefix to all variable names Table 20.8. Table formatter options Value Summary --max-width <integer> Maximum display width, <1 to disable. you can also use the CLIFF_MAX_TERM_WIDTH environment variable, but the parameter takes precedence. --fit-width Fit the table to the display width. implied if --max- width greater than 0. Set the environment variable CLIFF_FIT_WIDTH=1 to always enable --print-empty Print empty table if there is no data to show.

Commands:
openstack console log show [-h] [--lines <num-lines>] <server>
openstack console url show [-h] [-f {json,shell,table,value,yaml}] [-c COLUMN] [--noindent] [--prefix PREFIX] [--max-width <integer>] [--fit-width] [--print-empty] [--novnc | --xvpvnc | --spice | --rdp | --serial | --mks] <server>
5.343. util-linux-ng 5.343.1. RHBA-2012:1427 - util-linux-ng bug fix update Updated util-linux-ng packages that fix a bug are now available for Red Hat Enterprise Linux 6. The util-linux-ng packages contain a set of low-level system utilities that are necessary for a Linux operating system to function. Bug Fix BZ# 864367 When the telnetd daemon was used to log in to a server, the login utility failed to update the /var/run/utmp file properly. Consequently, the line used for a session in /var/run/utmp was not reused, thus growing the file unnecessarily. A patch has been provided to address this issue and the login utility now always updates /var/run/utmp as expected. Users of util-linux-ng are advised to upgrade to these updated packages, which fix this bug. 5.343.2. RHBA-2012:0925 - util-linux-ng bug fix update Updated util-linux-ng packages that fix several bugs are now available for Red Hat Enterprise Linux 6. The util-linux-ng packages contain a set of low-level system utilities that are necessary for a Linux operating system to function. Bug Fixes BZ# 588419 The console login time-out value was set to 60 seconds. This could cause the login to time out during the name lookup process on systems with broken DNS (Domain Name Service). With this update, the timeout value has been prolonged to 180 seconds to allow the login process to complete name lookups under these circumstances. BZ# 740163 The "fdisk -l" and "sfdisk -l" commands returned confusing warnings for unpartitioned devices similar to the following: With this update, the commands ignore unpartitioned devices and the problem no longer occurs. BZ# 785142 Previously, after the installation of the uuidd package, the uuidd daemon was not enabled by default. With this update, the underlying code has been modified and the uuidd daemon is enabled after installation as expected and can be started by the init script after reboot. BZ# 797888 Previously, the script command did not work correctly if called from the csh shell in the /etc/csh.login file. The child processes created by the script inherited the SIGTERM ignore property from csh and could not be terminated with the signal. With this update, the script resets the SIGTERM setting so that the shell is started with the default SIGTERM behavior and its children accept signals as expected. All users of util-linux-ng are advised to upgrade to these updated packages, which fix these bugs.

Commands:
Disk /dev/mapper/[volume name] doesn't contain a valid partition table