mtpti5iD/redhat-docs_dataset huggingface dataset:
1.5. Configuring netconsole If disk logging fails or using the serial console is not possible, you might need to use kernel debugging. The netconsole kernel module enables to log kernel messages to another computer over the network. To be able to use netconsole , you need to have an rsyslog server that is properly configured on your network. Procedure 1.1. Configuring an rsyslog server for netconsole Configure the rsyslogd daemon to listen on the 514/udp port and receive messages from the network by uncommenting the following lines in the MODULES section of the /etc/rsyslog.conf file: Restart the rsyslogd service for the changes to take effect: Verify that rsyslogd is listening on the 514/udp port: The 0.0.0.0:syslog and [::]:syslog values in the netstat -l output mean that rsyslogd is listening on default netconsole port defined in the /etc/services file: Netconsole is configured using the /etc/sysconfig/netconsole file, which is a part of the initscripts package. This package is installed by default and it also provides the netconsole service. If you want to configure a sending machine, follow this procedure: Procedure 1.2. Configuring a Sending Machine Set the value of the SYSLOGADDR variable in the /etc/sysconfig/netconsole file to match the IP address of the syslogd server. For example: Restart the netconsole service for the changes to take effect: Enable netconsole.service to run after rebooting the system: View the netconsole messages from the client in the /var/log/messages file (default) or in the file specified in rsyslog.conf . Note By default, rsyslogd and netconsole.service use port 514. To use a different port, change the following line in /etc/rsyslog.conf to the required port number: On the sending machine, uncomment and edit the following line in the /etc/sysconfig/netconsole file: For more information about netconsole configuration and troubleshooting tips, see Netconsole Kernel Documentation .

Commands:
USDModLoad imudp USDUDPServerRun 514
]# systemctl restart rsyslog
]# netstat -l | grep syslog udp 0 0 0.0.0.0:syslog 0.0.0.0:* udp6 0 0 [::]:syslog [::]:*
]USD cat /etc/services | grep syslog syslog 514/udp syslog-conn 601/tcp # Reliable Syslog Service syslog-conn 601/udp # Reliable Syslog Service syslog-tls 6514/tcp # Syslog over TLS syslog-tls 6514/udp # Syslog over TLS syslog-tls 6514/dccp # Syslog over TLS
SYSLOGADDR= 192.168.0.1
]# systemctl restart netconsole.service
]# systemctl enable netconsole.service
]# cat /var/log/messages
USDUDPServerRun <PORT>
SYSLOGPORT=514
B.2. Storing Certificates in NSS Databases By default, certmonger uses plaintext files to store the key and the certificate, but these keys and certificates can also be stored in NSS databases. This is done using the -d option to set the security database location and -n to give the certificate nickname which is used for the certificate in the database. These options are used instead of the PEM files given in the -f and -k options. For example:

Commands:
ipa-getcert request -d /export/alias -n ServerCert
Chapter 4. Set Up Expiration 4.1. About Expiration Red Hat JBoss Data Grid uses expiration to attach one or both of the following values to an entry: A lifespan value. A maximum idle time value. Expiration can be specified on a per-entry or per-cache basis and the per-entry configuration overrides per-cache configurations. If expiration is configured at the cache level, then the expiration defaults apply to all entries which do not explicitly specify a lifespan or maxIdle value. If expiration is not configured at the cache level, cache entries are created immortal (i.e. they will never expire) by default. Any entries that have lifespan or maxIdle defined are mortal, as they will eventually be removed from the cache once one of these conditions are met. Expired entries, unlike evicted entries, are removed globally, which removes them from memory, cache stores and the cluster. Expiration automates the removal of entries that have not been used for a specified period of time from the memory. Expiration and eviction are different because: expiration removes entries based on the period they have been in memory. Expiration only removes entries when the life span period concludes or when an entry has been idle longer than the specified idle time. eviction removes entries based on how recently (and often) they are used. Eviction only removes entries when too many entries are present in the memory. If a cache store has been configured, evicted entries are persisted in the cache store. Report a bug

Commands:
7.222. usbredir 7.222.1. RHBA-2015:1381 - usbredir bug fix update Updated usbredir packages that fix one bug are now available for Red Hat Enterprise Linux 6. The usbredir packages provide a network protocol for sending USB device traffic over a network connection and a number of libraries to help implement support for this protocol. Bug Fix BZ# 1085318 Previously, USB redirection over plain Transmission Control Protocol (TCP) sockets with the usbredir packages installed did not work. The USB was not properly redirected in this situation, even though USB redirection over Spice channels worked as expected. This update fixes a bug in the usbredir protocol parser that was causing this problem. As a result, USB redirection over plain TCP sockets now works as expected. Users of usbredir are advised to upgrade to these updated packages, which fix this bug.

Commands:
11.11. Aggregate Function Options Property Data Type or Allowed Values Description ANALYTIC 'TRUE'|'FALSE' indicates the aggregate function must be windowed. default false. ALLOWS-ORDERBY 'TRUE'|'FALSE' indicates the aggregate function supports an ORDER BY clause. default false ALLOWS-DISTINCT 'TRUE'|'FALSE' indicates the aggregate function supports the DISTINCT keyword. default false DECOMPOSABLE 'TRUE'|'FALSE' indicates the single argument aggregate function can be decomposed as agg(agg(x) ) over subsets of data. default false USES-DISTINCT-ROWS 'TRUE'|'FALSE' indicates the aggregate function effectively uses distinct rows rather than all rows. default false Note that virtual functions defined using the Teiid procedure language cannot be aggregate functions. Note If you have defined a UDF (virtual) function without a Teiid procedure definition, then it must be accompanied by its implementation in Java. To configure the Java library as dependency to the VDB, see Support for User-Defined Functions in Red Hat JBoss Data Virtualization Development Guide: Server Development .

Commands:
8.129. lsvpd 8.129.1. RHBA-2014:1442 - lsvpd bug fix and enhancement update Updated lsvpd packages that fix several bugs and add various enhancements are now available for Red Hat Enterprise Linux 6. The lsvpd packages provide a set of tools to gather and display the Vital Product Data (VPD) information about hardware components. This information can be used by higher-level serviceability tools. This update also fixes the following bugs: Note The lsvpd packages has been upgraded to upstream version 1.7.4, which provides a number of bug fixes and enhancements over the version. (BZ# 739121 ) This update also fixes the following bugs: Bug Fixes BZ# 868757 Previously, the output from the lscfg command contained duplicate entries for various hardware components. This bug has been fixed and lscfg no longer returns duplicate entries. BZ# 1088401 Previously, it was not possible to link code between the libsvpd and librtas libraries, because libsvpd is distributed under the GNU General Public License (GPL) whereas librtas is under commercial public license (CPL). This update grants a special permission to link part of the code for libsvpd against the librtas library and distribute linked combinations which include both libraries. You must obey the GNU General Public License in all respects for all of the code used other than librtas. The lsvpd packages has been upgraded to upstream version 1.7.4, which provides a number of bug fixes and enhancements over the version. (BZ#739121) In addition, this update adds the following Enhancement BZ# 1006855 This update adds support for the Firmware Entitlement Checking on IBM PowerPC server systems. Users of lsvpd are advised to upgrade to these updated packages, which fix these bugs and add these enhancements.

Commands:
Chapter 3. Enhancements This section describes the major enhancements introduced in Red Hat OpenShift Data foundation 4.9. Deletion of data is allowed when the storage cluster is full Previously, when the storage cluster was full, the Ceph Manager hung on checking pool permissions while reading the configuration file. The Ceph Metadata Server (MDS) did not allow write operations to occur when the Ceph OSD was full, resulting in an ENOSPACE error. When the storage cluster hit full ratio, users could not delete data to free space using the Ceph Manager volume plugin. With this release, the new FULL capability is introduced. With the FULL capability, the Ceph Manager bypasses the Ceph OSD full check. The client_check_pool_permission option is disabled by default whereas, in releases, it was enabled. With the Ceph Manager having FULL capabilities, the MDS no longer blocks Ceph Manager calls. This results in allowing the Ceph Manager to free up space by deleting subvolumes and snapshots when a storage cluster is full. Standalone Multicloud Object Gateway component deployment With this release, you can deploy OpenShift Data Foundation with only the Multicloud Object Gateway component in a standalone mode. In this mode, there is no CephCluster accompanying the StorageCluster, and hence Multicloud Object Gateway is not using a Ceph-based storage volume. Movement of Core and DB pods is enabled when a node fails OpenShift Container Platform does not mark the node as disconnected unless it is deleted. As a result, Core and DB pods, which are the statefulsets are not automatically evicted on such failed nodes. With this update, when a node fails, the DB and Core pods are evicted and moved to a new node. Volume snapshot restore to a different pool With this update, you can restore a volume snapshot of persistent volume claim (PVC) into a different pool than the parent volume. Previously, a volume snapshot could only be restored into the same pool. Multiple file systems are not created with existing pools With this update, after you create the filesystem.yaml , multiple file systems with the existing pool are not created even if you delete or recreate the filesystem.yaml . This avoids data loss. Auto-detection of Vault's Secret Key/Value store version With this enhancement, Vault's Secret Key/Value store version is auto-detected. Configuring VAULT_BACKEND parameter for HashiCorp Vault is now allowed With this update, you can configure the VAULT_BACKEND parameter for selecting the type of backend used by HashiCorp Vault. The autodetection of the backend used by HashiCorp Vault does not always work correctly. In case of a non-common configuration, the automatically detected configuration parameter might be set incorrectly. By allowing you to configure the VAULT_BACKEND parameter, non-common configurations can be forced to use a particular type of backend. Human-readable format for output of time in the Multicloud Object Gateway CLI With this release, the output of time in the Multicloud Object Gateway (MCG) CLI shows human-readable format (days-hours-minutes-seconds) instead of minutes and seconds.

Commands:
Chapter 6. Checking audit logs You can use audit logs to identify pod security violations. 6.1. Identifying pod security violations through audit logs You can identify pod security admission violations on a workload by viewing the server audit logs. The following procedure shows you how to access the audit logs and parse them to find pod security admission violations in a workload. Prerequisites You have installed jq . You have access to the cluster as a user with the cluster-admin role. Procedure To retrieve the node name, run the following command: USD <node_name>=USD(oc get node -ojsonpath='{.items[0].metadata.name}') To view the audit logs, run the following command: USD oc adm node-logs <node_name> --path=kube-apiserver/ 1 1 Replace <node_name> with the name of the node retrieved from the step. Example output rhel-94.lab.local audit-2024-10-18T18-25-41.663.log rhel-94.lab.local audit-2024-10-19T11-21-29.225.log rhel-94.lab.local audit-2024-10-20T04-16-09.622.log rhel-94.lab.local audit-2024-10-20T21-11-41.163.log rhel-94.lab.local audit-2024-10-21T14-06-10.402.log rhel-94.lab.local audit-2024-10-22T06-35-10.392.log rhel-94.lab.local audit-2024-10-22T23-26-27.667.log rhel-94.lab.local audit-2024-10-23T16-52-15.456.log rhel-94.lab.local audit-2024-10-24T07-31-55.238.log To parse the affected audit logs, enter the following command: USD oc adm node-logs <node_name> --path=kube-apiserver/audit.log \ | jq -r 'select((.annotations["pod-security.kubernetes.io/audit-violations"] != null) and (.objectRef.resource=="pods")) | .objectRef.namespace + " " + .objectRef.name + " " + .objectRef.resource' \ | sort | uniq -c 1 1 Replace <node_name> with the name of the node retrieved from the step.

Commands:
<node_name>=USD(oc get node -ojsonpath='{.items[0].metadata.name}')
oc adm node-logs <node_name> --path=kube-apiserver/ 1
rhel-94.lab.local audit-2024-10-18T18-25-41.663.log rhel-94.lab.local audit-2024-10-19T11-21-29.225.log rhel-94.lab.local audit-2024-10-20T04-16-09.622.log rhel-94.lab.local audit-2024-10-20T21-11-41.163.log rhel-94.lab.local audit-2024-10-21T14-06-10.402.log rhel-94.lab.local audit-2024-10-22T06-35-10.392.log rhel-94.lab.local audit-2024-10-22T23-26-27.667.log rhel-94.lab.local audit-2024-10-23T16-52-15.456.log rhel-94.lab.local audit-2024-10-24T07-31-55.238.log
oc adm node-logs <node_name> --path=kube-apiserver/audit.log | jq -r 'select((.annotations["pod-security.kubernetes.io/audit-violations"] != null) and (.objectRef.resource=="pods")) | .objectRef.namespace + " " + .objectRef.name + " " + .objectRef.resource' | sort | uniq -c 1
E.3.6. /proc/irq/ This directory is used to set IRQ to CPU affinity, which allows the system to connect a particular IRQ to only one CPU. Alternatively, it can exclude a CPU from handling any IRQs. Each IRQ has its own directory, allowing for the individual configuration of each IRQ. The /proc/irq/prof_cpu_mask file is a bitmask that contains the default values for the smp_affinity file in the IRQ directory. The values in smp_affinity specify which CPUs handle that particular IRQ. For more information about the /proc/irq/ directory, see the following installed documentation:

Commands:
/usr/share/doc/kernel-doc- kernel_version /Documentation/filesystems/proc.txt
4.3. Tracking the Bind DN for Plug-in Initiated Updates One change to an entry can trigger other, automatic changes across the directory tree. When a user is deleted, for example, that user is automatically removed from any groups it belonged to by the Referential Integrity Postoperation plug-in. The initial action is shown in the entry as being performed by whatever user account is bound to the server, but all related updates (by default) are shown as being performed by the plug-in, with no information about which user initiated that update. For example, using the MemberOf Plug-in to update user entries with group membership, the update to the group account is shown as being performed by the bound user, while the edit to the user entry is shown as being performed by the MemberOf Plug-in: The nsslapd-plugin-binddn-tracking parameter enables the server to track which user originated an update operation, as well as the internal plug-in which actually performed it. The bound user is shown in the modifiersname and creatorsname operational attributes, while the plug-in which performed it is shown in the internalModifiersname and internalCreatorsname operational attributes. For example: The nsslapd-plugin-binddn-tracking parameter tracks and maintains the relationship between the bound user and any updates performed for that connection. Note The internalModifiersname and internalCreatorsname attributes always show a plug-in as the identity. This plug-in could be an additional plug-in, such as the MemberOf Plug-in. If the change is made by the core Directory Server, then the plug-in is the database plug-in, cn=ldbm database,cn=plugins,cn=config . 4.3.1. Enabling Tracking the Bind DN for Plug-in Initiated Updates Using the Command Line To enable tracking the Bind DN for plug-in-initiated updates using the command line: Set the nsslapd-plugin-binddn-tracking parameter to on : Restart the instance: 4.3.2. Enabling Tracking the Bind DN for Plug-in Initiated Updates Using the Web Console To enable tracking the Bind DN for plug-in-initiated updates using the web console: Open the Directory Server user interface in the web console. See Section 1.4, "Logging Into Directory Server Using the Web Console" . Select the instance. Open the Server Settings menu, and select the Server Settings entry. On the Advanced Settings tab, select Enable Plugin Bind DN Tracking . Click Save . Restart the instance. See Section 1.5.2, "Starting and Stopping a Directory Server Instance Using the Web Console" .

Commands:
dn: cn= example_group ,ou=groups,dc=example,dc=com modifiersname: uid= example ,ou=people,dc=example,dc=com dn: uid= example ,ou=people,dc=example,dc=com modifiersname: cn=memberOf plugin,cn=plugins,cn=config
dn: uid= example ,ou=people,dc=example,dc=com modifiersname: uid= admin ,ou=people,dc=example,dc=com internalModifiersname: cn=memberOf plugin,cn=plugins,cn=config
dsconf -D "cn=Directory Manager" ldap://server.example.com config replace nsslapd-plugin-binddn-tracking=on
dsctl instance_name restart
Chapter 23. Branding a Red Hat Quay deployment on the legacy UI You can brand the UI of your Red Hat Quay deployment by changing the registry title, logo, footer image, and by directing users to a website embedded in the footer image. Procedure Update your Red Hat Quay config.yaml file to add the following parameters: BRANDING: logo: 1 footer_img: 2 footer_url: 3 --- REGISTRY_TITLE: 4 REGISTRY_TITLE_SHORT: 5 1 The URL of the image that will appear at the top of your Red Hat Quay deployment. 2 The URL of the image that will appear at the bottom of your Red Hat Quay deployment. 3 The URL of the website that users will be directed to when clicking the footer image. 4 The long-form title for the registry. This is displayed in frontend of your Red Hat Quay deployment, for example, at the sign in page of your organization. 5 The short-form title for the registry. The title is displayed on various pages of your organization, for example, as the title of the tutorial on your organization's Tutorial page. Restart your Red Hat Quay deployment. After restarting, your Red Hat Quay deployment is updated with a new logo, footer image, and footer image URL.

Commands:
BRANDING: logo: 1 footer_img: 2 footer_url: 3 --- REGISTRY_TITLE: 4 REGISTRY_TITLE_SHORT: 5
Chapter 1. Disaster Recovery Solutions Red Hat Virtualization supports two types of disaster recovery solutions to ensure that environments can recover when a site outage occurs. Both solutions support two sites, and both require replicated storage. Active-Active Disaster Recovery This solution is implemented using a stretch cluster configuration. This means that there is a single RHV environment with a cluster that contains hosts capable of running the required virtual machines in the primary and secondary site. Virtual machines automatically migrate to hosts in the secondary site if an outage occurs. However, the environment must meet latency and networking requirements. See Active-Active Overview for more information. Active-Passive Disaster Recovery Also referred to as site-to-site failover, this disaster recovery solution is implemented by configuring two separate RHV environments: the active primary environment, and the passive secondary (backup) environment. Failover and failback between sites must be manually executed, and is managed by Ansible. See Active-Passive Overview for more information.

Commands:
Chapter 23. Other Configurations 23.1. Configuring the kernel on overcloud nodes OpenStack Platform director includes parameters that configure the kernel on overcloud nodes. ExtraKernelModules Kernel modules to load. The modules names are listed as a hash key with an empty value: ExtraKernelPackages Kernel-related packages to install prior to loading the kernel modules from ExtraKernelModules . The package names are listed as a hash key with an empty value. ExtraSysctlSettings Hash of sysctl settings to apply. Set the value of each parameter using the value key. This example shows the syntax of these parameters in an environment file: 23.2. Configuring External Load Balancing An Overcloud uses multiple Controllers together as a high availability cluster, which ensures maximum operational performance for your OpenStack services. In addition, the cluster provides load balancing for access to the OpenStack services, which evenly distributes traffic to the Controller nodes and reduces server overload for each node. It is also possible to use an external load balancer to perform this distribution. For example, an organization might use their own hardware-based load balancer to handle traffic distribution to the Controller nodes. For more information about configuring external load balancing, see the dedicated External Load Balancing for the Overcloud guide for full instructions. 23.3. Configuring IPv6 Networking As a default, the Overcloud uses Internet Protocol version 4 (IPv4) to configure the service endpoints. However, the Overcloud also supports Internet Protocol version 6 (IPv6) endpoints, which is useful for organizations that support IPv6 infrastructure. The director includes a set of environment files to help with creating IPv6-based Overclouds. For more information about configuring IPv6 in the Overcloud, see the dedicated IPv6 Networking for the Overcloud guide for full instructions.

Commands:
ExtraKernelModules: <MODULE_NAME>: {}
ExtraKernelPackages: <PACKAGE_NAME>: {}
ExtraSysctlSettings: <KERNEL_PARAMETER>: value: <VALUE>
parameter_defaults: ExtraKernelModules: iscsi_target_mod: {} ExtraKernelPackages: iscsi-initiator-utils: {} ExtraSysctlSettings: dev.scsi.logging_level: value: 1
Chapter 1. About networking Red Hat OpenShift Networking is an ecosystem of features, plugins, and advanced networking capabilities that enhance Kubernetes networking with advanced networking-related features that your cluster needs to manage network traffic for one or multiple hybrid clusters. This ecosystem of networking capabilities integrates ingress, egress, load balancing, high-performance throughput, security, and inter- and intra-cluster traffic management. The Red Hat OpenShift Networking ecosystem also provides role-based observability tooling to reduce its natural complexities. The following are some of the most commonly used Red Hat OpenShift Networking features available on your cluster: Cluster Network Operator for network plugin management Primary cluster network provided by either of the following Container Network Interface (CNI) plugins: OVN-Kubernetes network plugin , which is the default CNI plugin. OpenShift SDN network plugin, which was deprecated in OpenShift 4.16 and removed in OpenShift 4.17. Important Before upgrading OpenShift Dedicated clusters that are configured with the OpenShift SDN network plugin to version 4.17, you must migrate to the OVN-Kubernetes network plugin. For more information, see Migrating from the OpenShift SDN network plugin to the OVN-Kubernetes network plugin in the Additional resources section. Additional resources OpenShift SDN CNI removal in OCP 4.17 Migrating from the OpenShift SDN network plugin to the OVN-Kubernetes network plugin

Commands: