mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 11. Configuring alert notifications In OpenShift Container Platform, an alert is fired when the conditions defined in an alerting rule are true. An alert provides a notification that a set of circumstances are apparent within a cluster. Firing alerts can be viewed in the Alerting UI in the OpenShift Container Platform web console by default. After an installation, you can configure OpenShift Container Platform to send alert notifications to external systems. 11.1. Sending notifications to external systems In OpenShift Container Platform 4.17, firing alerts can be viewed in the Alerting UI. Alerts are not configured by default to be sent to any notification systems. You can configure OpenShift Container Platform to send alerts to the following receiver types: PagerDuty Webhook Email Slack Microsoft Teams Routing alerts to receivers enables you to send timely notifications to the appropriate teams when failures occur. For example, critical alerts require immediate attention and are typically paged to an individual or a critical response team. Alerts that provide non-critical warning notifications might instead be routed to a ticketing system for non-immediate review. Checking that alerting is operational by using the watchdog alert OpenShift Container Platform monitoring includes a watchdog alert that fires continuously. Alertmanager repeatedly sends watchdog alert notifications to configured notification providers. The provider is usually configured to notify an administrator when it stops receiving the watchdog alert. This mechanism helps you quickly identify any communication issues between Alertmanager and the notification provider. 11.2. Additional resources About OpenShift Container Platform monitoring Configuring alert notifications

Commands:
B.3. autofs B.3.1. RHBA-2011:0403 - autofs bug fix update An updated autofs package that fixes one bug is now available for Red Hat Enterprise Linux 6. The autofs utility controls the operation of the automount daemon. The automount daemon automatically mounts file systems when you use them, and unmounts them when they are not busy. Bug Fix BZ# 689754 Prior to this update, an attempt to restart the autofs service while a mounted file system was in use caused the service to stop responding upon its startup. This was due to inappropriate locking during the recursive reconstruction of mount trees of pre-existing mounted multi-mount map entries. With this update, the underlying source code has been adapted to avoid the deadlock during the mount tree reconstruction, so that autofs now starts as expected. Additionally, this update prevents autofs from occasionally terminating with a segmentation fault upon a map entry lookup. All users of autofs are advised to upgrade to this updated package, which fixes this bug.

Commands:
Chapter 5. Configuring Network Connection Settings This chapter describes various configurations of the network connection settings and shows how to configure them by using NetworkManager . 5.1. Configuring 802.3 Link Settings You can configure the 802.3 link settings of an Ethernet connection by modifying the following configuration parameters: 802-3-ethernet.auto-negotiate 802-3-ethernet.speed 802-3-ethernet.duplex You can configure the 802.3 link settings to three main modes: Ignore link negotiation Enforce auto-negotiation activation Manually set the speed and duplex link settings Ignoring link negotiation In this case, NetworkManager ignores link configuration for an ethernet connection, keeping the already configuration on the device. To ignore link negotiation, set the following parameters: Important If the auto-negotiate parameter is set to no , but the speed and duplex values are not set, that does not mean that auto-negotiation is disabled. Enforcing auto-negotiation activation In this case, NetworkManager enforces auto-negotiation on a device. To enforce auto-negotiation activation, set the following options: Manually setting the link speed and duplex In this case, you can manually configure the speed and duplex settings on the link. To manually set the speed and duplex link settings, set the aforementioned parameters as follows: Important Make sure to set both the speed and the duplex values, otherwise NetworkManager does not update the link configuration. As a system administrator, you can configure 802.3 link settings using one of the following options: the nmcli tool the nm-connection-editor utility Configuring 802.3 Link Settings with the nmcli Tool Procedure Create a new ethernet connection for the enp1s0 device. Set the 802.3 link setting to a configuration of your choice. For details, see Section 5.1, "Configuring 802.3 Link Settings" For example, to manually set the speed option 100 Mbit/s and duplex to full : Configuring 802.3 Link Settings with nm-connection-editor Procedure Enter nm-connection-editor in a terminal. Select the ethernet connection you want to edit and click the gear wheel icon to move to the editing dialog. See Section 3.4.3, "Common Configuration Options Using nm-connection-editor" for more information. Select the link negotiation of your choice. Ignore : link configuration is skipped (default). Automatic : link auto-negotiation is enforced on the device. Manual : the Speed and Duplex options can be specified to enforce the link negotiation. Figure 5.1. Configure 802.3 link settings using nm-connection-editor

Commands:
802-3-ethernet.auto-negotiate = no 802-3-ethernet.speed = 0 802-3-ethernet.duplex = NULL
802-3-ethernet.auto-negotiate = yes 802-3-ethernet.speed = 0 802-3-ethernet.duplex = NULL
802-3-ethernet.auto-negotiate = no 802-3-ethernet.speed = [speed in Mbit/s] 802-3-ethernet.duplex = [half |full]
nmcli connection add con-name MyEthernet type ethernet ifname enp1s0 802-3-ethernet.auto-negotiate no 802-3-ethernet.speed 100 802-3-ethernet.duplex full
18.5. Limitations of ACIs When you set ACIs, the following restrictions apply: If your directory database is distributed over multiple servers, the following restrictions apply to the keywords you can use in ACIs: ACIs depending on group entries using the groupdn keyword must be located on the same server as the group entry. If the group is dynamic, all members of the group must have an entry on the server. Member entries of static groups can be located on the remote server. ACIs depending on role definitions using the roledn keyword, must be located on the same server as the role definition entry. Every entry that is intended to have the role must also be located on the same server. However, you can match values stored in the target entry with values stored in the entry of the bind user by, for example, using the userattr keyword. In this case, access is evaluated normally even if the bind user does not have an entry on the server that stores the ACI. For further details, see Section 2.3.3, "Database Links and Access Control Evaluation" . You cannot use virtual attributes, such as Class of Service (CoS) attributes, in the following ACI keywords: targetfilter targattrfilters userattr For details, see Chapter 8, Organizing and Grouping Entries . Access control rules are evaluated only on the local server. For example, if you specify the host name of a server in LDAP URLs in ACI keywords, the URL will be ignored.

Commands:
14.2.7. Editing a Logical Volume The LVM utility allows you to select a logical volume in the volume group and modify its name, size and specify file system options. In this example, the logical volume named 'Backups" was extended onto the remaining space for the volume group. Clicking on the Edit Properties button will display the 'Edit Logical Volume' pop-up window from which you can edit the properties of the logical volume. On this window, you can also mount the volume after making the changes and mount it when the system is rebooted. You should indicate the mount point. If the mount point you specify does not exist, a pop-up window will be displayed prompting you to create it. The 'Edit Logical Volume' window is illustrated below. Figure 14.17. Edit logical volume If you wish to mount the volume, select the 'Mount' checkbox indicating the preferred mount point. To mount the volume when the system is rebooted, select the 'Mount when rebooted' checkbox. In this example, the new volume will be mounted in /mnt/backups . This is illustrated in the figure below. Figure 14.18. Edit logical volume - specifying mount options The figure below illustrates the logical and physical view of the volume group after the logical volume was extended to the unused space. In this example that the logical volume named 'Backups' spans across two hard disks. A volume can be stripped across two or more physical devices using LVM. Figure 14.19. Edit logical volume

Commands:
Chapter 1. Provisioning APIs 1.1. BMCEventSubscription [metal3.io/v1alpha1] Description BMCEventSubscription is the Schema for the fast eventing API Type object 1.2. BareMetalHost [metal3.io/v1alpha1] Description BareMetalHost is the Schema for the baremetalhosts API Type object 1.3. DataImage [metal3.io/v1alpha1] Description DataImage is the Schema for the dataimages API. Type object 1.4. FirmwareSchema [metal3.io/v1alpha1] Description FirmwareSchema is the Schema for the firmwareschemas API. Type object 1.5. HardwareData [metal3.io/v1alpha1] Description HardwareData is the Schema for the hardwaredata API. Type object 1.6. HostFirmwareComponents [metal3.io/v1alpha1] Description HostFirmwareComponents is the Schema for the hostfirmwarecomponents API. Type object 1.7. HostFirmwareSettings [metal3.io/v1alpha1] Description HostFirmwareSettings is the Schema for the hostfirmwaresettings API. Type object 1.8. Metal3Remediation [infrastructure.cluster.x-k8s.io/v1beta1] Description Metal3Remediation is the Schema for the metal3remediations API. Type object 1.9. Metal3RemediationTemplate [infrastructure.cluster.x-k8s.io/v1beta1] Description Metal3RemediationTemplate is the Schema for the metal3remediationtemplates API. Type object 1.10. PreprovisioningImage [metal3.io/v1alpha1] Description PreprovisioningImage is the Schema for the preprovisioningimages API. Type object 1.11. Provisioning [metal3.io/v1alpha1] Description Provisioning contains configuration used by the Provisioning service (Ironic) to provision baremetal hosts. Provisioning is created by the OpenShift installer using admin or user provided information about the provisioning network and the NIC on the server that can be used to PXE boot it. This CR is a singleton, created by the installer and currently only consumed by the cluster-baremetal-operator to bring up and update containers in a metal3 cluster. Type object

Commands:
18.13. Creating Tunnels This section will demonstrate how to implement different tunneling scenarios. 18.13.1. Creating Multicast Tunnels A multicast group is set up to represent a virtual network. Any guest virtual machines whose network devices are in the same multicast group can talk to each other even across host physical machines. This mode is also available to unprivileged users. There is no default DNS or DHCP support and no outgoing network access. To provide outgoing network access, one of the guest virtual machines should have a second NIC which is connected to one of the first four network types, thus providing appropriate routing. The multicast protocol is compatible with the guest virtual machine user mode. Note that the source address that you provide must be from the address used for the multicast address block. To create a multicast tunnel, specify the following XML details into the <devices> element: ... <devices> <interface type='mcast'> <mac address='52:54:00:6d:90:01'> <source address='230.0.0.1' port='5558'/> </interface> </devices> ... Figure 18.28. Multicast tunnel XML example

Commands:
<devices> <interface type='mcast'> <mac address='52:54:00:6d:90:01'> <source address='230.0.0.1' port='5558'/> </interface> </devices>
Chapter 16. Enabling Red Hat build of Keycloak Metrics Red Hat build of Keycloak has built in support for metrics. This chapter describes how to enable and configure server metrics. 16.1. Enabling Metrics It is possible to enable metrics using the build time option metrics-enabled : bin/kc.[sh|bat] start --metrics-enabled=true 16.2. Querying Metrics Red Hat build of Keycloak exposes metrics at the following endpoint: /metrics The response from the endpoint uses a application/openmetrics-text content type and it is based on the Prometheus (OpenMetrics) text format. The snippet bellow is an example of a response: 16.3. Available Metrics The table below summarizes the available metrics groups: Metric Description System A set of system-level metrics related to CPU and memory usage. JVM A set of metrics from the Java Virtual Machine (JVM) related to GC, and heap. Database A set of metrics from the database connection pool, if using a database. Cache A set of metrics from Infinispan caches. See Configuring distributed caches for more details. 16.4. Relevant options Value metrics-enabled 🛠 If the server should expose metrics. If enabled, metrics are available at the /metrics endpoint. CLI: --metrics-enabled Env: KC_METRICS_ENABLED true , false (default)

Commands:
bin/kc.[sh|bat] start --metrics-enabled=true
HELP base_gc_total Displays the total number of collections that have occurred. This attribute lists -1 if the collection count is undefined for this collector. TYPE base_gc_total counter base_gc_total{name="G1 Young Generation",} 14.0 HELP jvm_memory_usage_after_gc_percent The percentage of long-lived heap pool used after the last GC event, in the range [0..1] TYPE jvm_memory_usage_after_gc_percent gauge jvm_memory_usage_after_gc_percent{area="heap",pool="long-lived",} 0.0 HELP jvm_threads_peak_threads The peak live thread count since the Java virtual machine started or peak was reset TYPE jvm_threads_peak_threads gauge jvm_threads_peak_threads 113.0 HELP agroal_active_count Number of active connections. These connections are in use and not available to be acquired. TYPE agroal_active_count gauge agroal_active_count{datasource="default",} 0.0 HELP base_memory_maxHeap_bytes Displays the maximum amount of memory, in bytes, that can be used for memory management. TYPE base_memory_maxHeap_bytes gauge base_memory_maxHeap_bytes 1.6781410304E10 HELP process_start_time_seconds Start time of the process since unix epoch. TYPE process_start_time_seconds gauge process_start_time_seconds 1.675188449054E9 HELP system_load_average_1m The sum of the number of runnable entities queued to available processors and the number of runnable entities running on the available processors averaged over a period of time TYPE system_load_average_1m gauge system_load_average_1m 4.005859375
Chapter 3. Using the OpenShift Container Platform dashboard to get cluster information The OpenShift Container Platform web console captures high-level information about the cluster. 3.1. About the OpenShift Container Platform dashboards page Access the OpenShift Container Platform dashboard, which captures high-level information about the cluster, by navigating to Home Overview from the OpenShift Container Platform web console. The OpenShift Container Platform dashboard provides various cluster information, captured in individual dashboard cards. The OpenShift Container Platform dashboard consists of the following cards: Details provides a brief overview of informational cluster details. Status include ok , error , warning , in progress , and unknown . Resources can add custom status names. Cluster ID Provider Version Cluster Inventory details number of resources and associated statuses. It is helpful when intervention is required to resolve problems, including information about: Number of nodes Number of pods Persistent storage volume claims Bare metal hosts in the cluster, listed according to their state (only available in metal3 environment). Bare metal hosts in the cluster, listed according to their state (only available in metal3 environment) Status helps administrators understand how cluster resources are consumed. Click on a resource to jump to a detailed page listing pods and nodes that consume the largest amount of the specified cluster resource (CPU, memory, or storage). Cluster Utilization shows the capacity of various resources over a specified period of time, to help administrators understand the scale and frequency of high resource consumption, including information about: CPU time Memory allocation Storage consumed Network resources consumed Pod count Activity lists messages related to recent activity in the cluster, such as pod creation or virtual machine migration to another host. 3.2. Recognizing resource and project limits and quotas You can view a graphical representation of available resources in the Topology view of the web console Developer perspective. If a resource has a message about resource limitations or quotas being reached, a yellow border appears around the resource name. Click the resource to open a side panel to see the message. If the Topology view has been zoomed out, a yellow dot indicates that a message is available. If you are using List View from the View Shortcuts menu, resources appear as a list. The Alerts column indicates if a message is available.

Commands:
7.6. Setting up Additional Subsystems After you have installed the root Certificate Authority (CA) as described in Section 7.4, "Setting Up a Root Certificate Authority" , you can install additional Certificate System subsystems. Prerequisites All additional subsystems require a root Certificate Authority (CA). If you have not installed a root Certificate System CA, see Section 7.4, "Setting Up a Root Certificate Authority" . Installing the Subsystem To set up an additional subsystem, you have the following options: Configuration file-based installation: Use this method for high-level customization. This installation method uses a configuration file that overrides the default installation parameters. You can install Certificate System using a configuration file in a single step or in two steps. For details and examples, see: The pkispawn (8) man page for the single-step installation. Section 7.7, "Two-step Installation" for the two-step installation. Interactive installation: Use the interactive installer if you only want to set the minimum of required configuration options. For example: Replace subsystem with one of the following subsystems: KRA , OCSP , TKS , or TPS . The interactive installer does not support installing a subordinate CA. To install a subordinate CA, use the two-step installation. See Section 7.7, "Two-step Installation" .

Commands:
pkispawn -s subsystem
1.4. SysV Init Runlevels The SysV init runlevel system provides a standard process for controlling which programs init launches or halts when initializing a runlevel. SysV init was chosen because it is easier to use and more flexible than the traditional BSD-style init process. The configuration files for SysV init are located in the /etc/rc.d/ directory. Within this directory, are the rc , rc.local , rc.sysinit , and, optionally, the rc.serial scripts as well as the following directories: The init.d/ directory contains the scripts used by the /sbin/init command when controlling services. Each of the numbered directories represent the six runlevels configured by default under Red Hat Enterprise Linux. 1.4.1. Runlevels The idea behind SysV init runlevels revolves around the idea that different systems can be used in different ways. For example, a server runs more efficiently without the drag on system resources created by the X Window System. Or there may be times when a system administrator may need to operate the system at a lower runlevel to perform diagnostic tasks, like fixing disk corruption in runlevel 1. The characteristics of a given runlevel determine which services are halted and started by init . For instance, runlevel 1 (single user mode) halts any network services, while runlevel 3 starts these services. By assigning specific services to be halted or started on a given runlevel, init can quickly change the mode of the machine without the user manually stopping and starting services. The following runlevels are defined by default under Red Hat Enterprise Linux: 0 - Halt 1 - Single-user text mode 2 - Not used (user-definable) 3 - Full multi-user text mode 4 - Not used (user-definable) 5 - Full multi-user graphical mode (with an X-based login screen) 6 - Reboot In general, users operate Red Hat Enterprise Linux at runlevel 3 or runlevel 5 - both full multi-user modes. Users sometimes customize runlevels 2 and 4 to meet specific needs, since they are not used. The default runlevel for the system is listed in /etc/inittab . To find out the default runlevel for a system, look for the line similar to the following near the top of /etc/inittab : The default runlevel listed in this example is five, as the number after the first colon indicates. To change it, edit /etc/inittab as root. Warning Be very careful when editing /etc/inittab . Simple typos can cause the system to become unbootable. If this happens, either use a boot diskette, enter single-user mode, or enter rescue mode to boot the computer and repair the file. For more information on single-user and rescue mode, refer to the chapter titled Basic System Recovery in the System Administrators Guide . It is possible to change the default runlevel at boot time by modifying the arguments passed by the boot loader to the kernel. For information on changing the runlevel at boot time, refer to Section 2.8, "Changing Runlevels at Boot Time" .

Commands:
init.d/ rc0.d/ rc1.d/ rc2.d/ rc3.d/ rc4.d/ rc5.d/ rc6.d/
id:5:initdefault:
Chapter 34. Using Automount Automount is a way to manage, organize, and access directories across multiple systems. Automount automatically mounts a directory whenever access to it is requested. This works exceptionally well within an IdM domain since it allows directories on clients within the domain to be shared easily. This is especially important with user home directories, see Section 11.1, "Setting up User Home Directories" . In IdM, automount works with the internal LDAP directory and also with DNS services if configured. 34.1. About Automount and IdM Automount provides a coherent structure to the way that directories are organized. Every directory is called a mount point or a key . Multiple keys that are grouped together create a map , and maps are associated according to their physical or conceptual location . The base configuration file for automount is the auto.master file in the /etc directory. If necessary, there can be multiple auto.master configuration files in separate server locations. When the autofs utility is configured on a server and the server is a client in an IdM domain, then all configuration information for automount is stored in the IdM directory. Rather than in separate text files, the autofs configuration containing maps, locations, and keys are stored as LDAP entries. For example, the default map file, auto.master , is stored as: Important Identity Management works with an existing autofs deployment but does not set up or configure autofs itself. Each new location is added as a container entry under cn=automount,dc=example,dc=com , and each map and each key are stored beneath that location. As with other IdM domain services, automount works with IdM natively. The automount configuration can be managed by IdM tools: The ipa automountlocation* commands for Locations , The ipa automountmap* commands for direct and indirect maps , The ipa automountkey* commands for keys . For automount to work within the IdM domain, the NFS server must be configured as an IdM client. Configuring NFS itself is covered in the Red Hat Enterprise Linux Storage Administration Guide .

Commands:
dn: automountmapname=auto.master,cn=default,cn=automount,dc=example,dc=com objectClass: automountMap objectClass: top automountMapName: auto.master