mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 4. Alerts 4.1. Setting up alerts For internal Mode clusters, various alerts related to the storage metrics services, storage cluster, disk devices, cluster health, cluster capacity, and so on are displayed in the Block and File , and the Object dashboards. These alerts are not available for external Mode. Note It might take a few minutes for alerts to be shown in the alert panel because only firing alerts are visible in this panel. You can also view alerts with additional details and customize the display of Alerts in the OpenShift Container Platform. For more information, see Managing alerts .

Commands:
8.3. Using ID Views to Define AD User Attributes With ID views, you can change the user attribute values defined in AD. For a complete list of the attributes, see Attributes an ID View Can Override . For example: If you are managing a mixed Linux-Windows environment and want to manually define POSIX attributes or SSH login attributes for an AD user, but the AD policy does not allow it, you can use ID views to override the attribute values. When the AD user authenticates to clients running SSSD or authenticates using a compat LDAP tree, the new values are used in the authentication process. Note Only IdM users can manage ID views. AD users cannot. The process for overriding the attribute values follows these steps: Create a new ID view. Add a user ID override in the ID view, and specify the require attribute value. Apply the ID view to a specific host. For details on how to perform these steps, see Defining a Different Attribute Value for a User Account on Different Hosts in the Linux Domain Identity, Authentication, and Policy Guide .

Commands:
2.13. RHEA-2011:0553 - new package: iwl6000g2b-firmware A new iwl6000g2b-firmware package that works with the iwlagn driver in the latest Red Hat Enterprise Linux kernels to enable support for Intel Wireless WiFi Link 6030 Series AGN Adapters is now available. iwlagn is a kernel driver module for the Intel Wireless WiFi Link series of devices. The iwlagn driver requires firmware loaded on the device in order to function. This new iwl6000g2b-firmware package provides the firmware required by iwlagn to enable Intel Wireless WiFi Link 6030 Series AGN Adapters. (BZ# 664520 ) All users of the iwlagn driver, especially those requiring iwl6000g2b support, should install this new package, which provides this enhancement.

Commands:
7.250. systemtap 7.250.1. RHBA-2013:0345 - systemtap bug fix and enhancement update Updated systemtap packages that fix several bugs and add various enhancements are now available for Red Hat Enterprise Linux 6. SystemTap is a tracing and probing tool to analyze and monitor activities of the operating system, including the kernel. It provides a wide range of filtering and analysis options. Note The systemtap packages have been upgraded to upstream version 1.8, which provides a number of bug fixes and enhancements over the version. (BZ#843123) Bug Fixes BZ#746334 Many of the SystemTap examples for memory used tracepoints which did not exist in some versions of kernel. Consequently, if the user tried to run the mmanonpage.stp, mmfilepage.stp, or mmwriteback.stp files, this process failed. The examples have been updated to work with the memory tracepoints available in Red Hat Enterprise Linux 6 and SystemTap now works as expected. BZ# 822503 Previously, support for the IPv6 protocol was missing. Consequently, an attempt to execute a script that evaluates a tapset variable containing an IPv6 address, or call a tapset function returning an IPv6 address was unsuccessful, and the address field was filled with the "Unsupported Address Family" message instead of a valid IPv6 address. This update adds the support for the IPv6 protocol. BZ#824311 Previously, changes in the include/trace/events/sunrpc.h file were referenced, but were not defined by the #include directive. As a consequence, the rpc tracepoint was missing. This tracepoint has been defined using #include and SystemTap works correctly in this situation. BZ#828103 In kernels and versions of SystemTap, the nfsd.open probe-alias in the nfsd tapset referred to the "access" parameter, which was later renamed to "may_flags" in the kernel. Consequently, the semantic errors occurred and then the stap command failed to execute. This update allows the nfsd.open probe-alias check under both names for setting the "access" script-level variable, and stap now works as expected in the described scenario. BZ#884951 Recent kernel updates required updates to some of the NFS tapset definitions to find certain context variables. With this update, the tapset aliases now search both old and new locations. All users of systemtap are advised to upgrade to these updated packages, which fix these bugs and add these enhancements.

Commands:
Chapter 1. Overview JBoss Operations Network (JON) is an enterprise, Java-based administration and management platform that you can use to develop, test, deploy, and monitor JBoss middleware applications. JON is based on RHQ. When using the JON platform to manage AMQ Brokers, the system comprises three components: JON server JON agent Plug-in pack The AMQ Broker plug-in is a connector that enables the JON Agent to collect information about the message brokers running in your JBoss environment. 1.1. Key Features With the AMQ Broker plug-in for JON, you can: Discover and maintain an inventory of AMQ Brokers. Store, manage, and update AMQ Broker configurations. Detect configuration change, correlate them with performance history, and roll back. Automate and schedule execution of operations for managed resources and resource groups. 1.2. Supported Configurations The supported configurations for both AMQ broker and JON server apply when you are using them together. Ensure that your systems align with the configurations documented in the following Knowledgebase articles: AMQ 7 Supported Configurations JON Supported Configurations and Components

Commands:
function::str_replace Name function::str_replace - str_replace Replaces all instances of a substring with another. Synopsis Arguments prnt_str The string to search and replace in. srch_str The substring which is used to search in prnt_str string. rplc_str The substring which is used to replace srch_str. General Syntax str_replace:string(prnt_str:string, srch_str:string, rplc_str:string) Description This function returns the given string with substrings replaced.

Commands:
function str_replace:string(prnt_str:string,srch_str:string,rplc_str:string)
Chapter 10. Uninstalling a cluster on OpenStack You can remove a cluster that you deployed to Red Hat OpenStack Platform (RHOSP). 10.1. Removing a cluster that uses installer-provisioned infrastructure You can remove a cluster that uses installer-provisioned infrastructure from your cloud. Note If you deployed your cluster to the AWS C2S Secret Region, the installation program does not support destroying the cluster; you must manually remove the cluster resources. Note After uninstallation, check your cloud provider for any resources not removed properly, especially with user-provisioned infrastructure clusters. There might be resources that the installation program did not create or that the installation program is unable to access. For example, some Google Cloud resources require IAM permissions in shared VPC host projects, or there might be unused health checks that must be deleted . Prerequisites You have a copy of the installation program that you used to deploy the cluster. You have the files that the installation program generated when you created your cluster. Procedure On the computer that you used to install the cluster, go to the directory that contains the installation program, and run the following command: USD ./openshift-install destroy cluster \ --dir <installation_directory> --log-level info 1 2 1 For <installation_directory> , specify the path to the directory that you stored the installation files in. 2 To view different details, specify warn , debug , or error instead of info . Note You must specify the directory that contains the cluster definition files for your cluster. The installation program requires the metadata.json file in this directory to delete the cluster. Optional: Delete the <installation_directory> directory and the OpenShift Container Platform installation program.

Commands:
./openshift-install destroy cluster --dir <installation_directory> --log-level info 1 2
Chapter 8. Configuring the node port service range As a cluster administrator, you can expand the available node port range. If your cluster uses of a large number of node ports, you might need to increase the number of available ports. The default port range is 30000-32767 . You can never reduce the port range, even if you first expand it beyond the default range. 8.1. Prerequisites Your cluster infrastructure must allow access to the ports that you specify within the expanded range. For example, if you expand the node port range to 30000-32900 , the inclusive port range of 32768-32900 must be allowed by your firewall or packet filtering configuration. 8.2. Expanding the node port range You can expand the node port range for the cluster. Prerequisites Install the OpenShift CLI ( oc ). Log in to the cluster with a user with cluster-admin privileges. Procedure To expand the node port range, enter the following command. Replace <port> with the largest port number in the new range. USD oc patch network.config.openshift.io cluster --type=merge -p \ '{ "spec": { "serviceNodePortRange": "30000-<port>" } }' Tip You can alternatively apply the following YAML to update the node port range: apiVersion: config.openshift.io/v1 kind: Network metadata: name: cluster spec: serviceNodePortRange: "30000-<port>" Example output network.config.openshift.io/cluster patched To confirm that the configuration is active, enter the following command. It can take several minutes for the update to apply. USD oc get configmaps -n openshift-kube-apiserver config \ -o jsonpath="{.data['config\.yaml']}" | \ grep -Eo '"service-node-port-range":["[[:digit:]]+-[[:digit:]]+"]' Example output "service-node-port-range":["30000-33000"] 8.3. Additional resources Configuring ingress cluster traffic using a NodePort Network [config.openshift.io/v1 ] Service [core/v1 ]

Commands:
oc patch network.config.openshift.io cluster --type=merge -p '{ "spec": { "serviceNodePortRange": "30000-<port>" } }'
apiVersion: config.openshift.io/v1 kind: Network metadata: name: cluster spec: serviceNodePortRange: "30000-<port>"
network.config.openshift.io/cluster patched
oc get configmaps -n openshift-kube-apiserver config -o jsonpath="{.data['config\.yaml']}" | grep -Eo '"service-node-port-range":["[[:digit:]]+-[[:digit:]]+"]'
"service-node-port-range":["30000-33000"]
Chapter 5. Transaction Support 5.1. Transaction Support JBoss Data Virtualization uses XA transactions for participating in global transactions and for demarcating its local and command scoped transactions. Refer to the Red Hat JBoss Data Virtualization Development Guide Volume 1: Client Development for more information about the transaction subsystem. Table 5.1. JBoss Data Virtualization Transaction Scopes Scope Description Command Treats the user command as if all source commands are executed within the scope of the same transaction. The AutoCommitTxn execution property controls the behavior of command level transactions. Local The transaction boundary is local defined by a single client session. Global JBoss Data Virtualization participates in a global transaction as an XA Resource. The default transaction isolation level for JBoss Data Virtualization is READ_COMMITTED.

Commands:
Chapter 101. ReplicasChangeStatus schema reference Used in: KafkaTopicStatus Property Property type Description targetReplicas integer The target replicas value requested by the user. This may be different from .spec.replicas when a change is ongoing. state string (one of [ongoing, pending]) Current state of the replicas change operation. This can be pending , when the change has been requested, or ongoing , when the change has been successfully submitted to Cruise Control. message string Message for the user related to the replicas change request. This may contain transient error messages that would disappear on periodic reconciliations. sessionId string The session identifier for replicas change requests pertaining to this KafkaTopic resource. This is used by the Topic Operator to track the status of ongoing replicas change operations.

Commands:
13.2.16. Domain Options: Enabling Offline Authentication User identities are always cached, as well as information about the domain services. However, user credentials are not cached by default. This means that SSSD always checks with the back end identity provider for authentication requests. If the identity provider is offline or unavailable, there is no way to process those authentication requests, so user authentication could fail. It is possible to enable offline credentials caching , which stores credentials (after successful login) as part of the user account in the SSSD cache. Therefore, even if an identity provider is unavailable, users can still authenticate, using their stored credentials. Offline credentials caching is primarily configured in each individual domain entry, but there are some optional settings that can be set in the PAM service section, because credentials caching interacts with the local PAM service as well as the remote domain. There are optional parameters that set when those credentials expire. Expiration is useful because it can prevent a user with a potentially outdated account or credentials from accessing local services indefinitely. The credentials expiration itself is set in the PAM service, which processes authentication requests for the system. offline_credentials_expiration sets the number of days after a successful login that a single credentials entry for a user is preserved in cache. Setting this to zero (0) means that entries are kept forever. While not related to the credentials cache specifically, each domain has configuration options on when individual user and service caches expire: account_cache_expiration sets the number of days after a successful login that the entire user account entry is removed from the SSSD cache. This must be equal to or longer than the individual offline credentials cache expiration period. entry_cache_timeout sets a validity period, in seconds, for all entries stored in the cache before SSSD requests updated information from the identity provider. There are also individual cache timeout parameters for group, service, netgroup, sudo, and autofs entries; these are listed in the sssd.conf man page. The default time is 5400 seconds (90 minutes). For example:

Commands:
[domain/EXAMPLE] cache_credentials = true
[sssd] services = nss,pam [pam] offline_credentials_expiration = 3 [domain/EXAMPLE] cache_credentials = true
[sssd] services = nss,pam [pam] offline_credentials_expiration = 3 [domain/EXAMPLE] cache_credentials = true account_cache_expiration = 7 entry_cache_timeout = 14400
4.3.4. Scanning Disks for Volume Groups to Build the Cache File The vgscan command scans all supported disk devices in the system looking for LVM physical volumes and volume groups. This builds the LVM cache in the /etc/lvm/.cache file, which maintains a listing of current LVM devices. LVM runs the vgscan command automatically at system startup and at other times during LVM operation, such as when you execute a vgcreate command or when LVM detects an inconsistency. You may need to run the vgscan command manually when you change your hardware configuration, causing new devices to be visible to the system that were not present at system bootup. This may be necessary, for example, when you add new disks to the system on a SAN or hotplug a new disk that has been labeled as a physical volume. You can define a filter in the lvm.conf file to restrict the scan to avoid specific devices. For information on using filters to control which devices are scanned, see Section 4.6, "Controlling LVM Device Scans with Filters" . The following example shows the output of a vgscan command.

Commands:
vgscan Reading all physical volumes. This may take a while Found volume group "new_vg" using metadata type lvm2 Found volume group "officevg" using metadata type lvm2
Chapter 25. Device Mapper Multipathing and Virtual Storage Red Hat Enterprise Linux 6 also supports DM-Multipath and virtual storage . Both features are documented in detail in the Red Hat books DM Multipath and Virtualization Administration Guide . 25.1. Virtual Storage Red Hat Enterprise Linux 6 supports the following file systems/online storage methods for virtual storage: Fibre Channel iSCSI NFS GFS2 Virtualization in Red Hat Enterprise Linux 6 uses libvirt to manage virtual instances. The libvirt utility uses the concept of storage pools to manage storage for virtualized guests. A storage pool is storage that can be divided up into smaller volumes or allocated directly to a guest. Volumes of a storage pool can be allocated to virtualized guests. There are two categories of storage pools available: Local storage pools Local storage covers storage devices, files or directories directly attached to a host. Local storage includes local directories, directly attached disks, and LVM Volume Groups. Networked (shared) storage pools Networked storage covers storage devices shared over a network using standard protocols. It includes shared storage devices using Fibre Channel, iSCSI, NFS, GFS2, and SCSI RDMA protocols, and is a requirement for migrating guest virtualized guests between hosts. Important For comprehensive information on the deployment and configuration of virtual storage instances in your environment, refer to the Virtualization Storage section of the Virtualization guide provided by Red Hat.

Commands:
Chapter 1. Federal Information Processing Standard (FIPS) readiness and compliance The Federal Information Processing Standard (FIPS) developed by the National Institute of Standards and Technology (NIST) is regarded as the highly regarded for securing and encrypting sensitive data, notably in highly regulated areas such as banking, healthcare, and the public sector. Red Hat Enterprise Linux (RHEL) and OpenShift Container Platform support FIPS by providing a FIPS mode , in which the system only allows usage of specific FIPS-validated cryptographic modules like openssl . This ensures FIPS compliance. 1.1. Enabling FIPS compliance Use the following procedure to enable FIPS compliance on your Red Hat Quay deployment. Prerequisite If you are running a standalone deployment of Red Hat Quay, your Red Hat Enterprise Linux (RHEL) deployment is version 8 or later and FIPS-enabled. If you are using the Red Hat Quay Operator, OpenShift Container Platform is version 4.10 or later. Your Red Hat Quay version is 3.5.0 or later. You have administrative privileges for your Red Hat Quay deployment. Procedure In your Red Hat Quay config.yaml file, set the FEATURE_FIPS configuration field to true . For example: --- FEATURE_FIPS = true --- With FEATURE_FIPS set to true , Red Hat Quay runs using FIPS-compliant hash functions.

Commands:
--- FEATURE_FIPS = true ---
Chapter 10. NetworkManager NetworkManager is a dynamic network control and configuration system that attempts to keep network devices and connections up and active when they are available. NetworkManager consists of a core daemon, a GNOME Notification Area applet that provides network status information, and graphical configuration tools that can create, edit and remove connections and interfaces. NetworkManager can be used to configure the following types of connections: Ethernet, wireless, mobile broadband (such as cellular 3G), and DSL and PPPoE (Point-to-Point over Ethernet). In addition, NetworkManager allows for the configuration of network aliases, static routes, DNS information and VPN connections, as well as many connection-specific parameters. Finally, NetworkManager provides a rich API via D-Bus which allows applications to query and control network configuration and state. versions of Red Hat Enterprise Linux included the Network Administration Tool , which was commonly known as system-config-network after its command-line invocation. In Red Hat Enterprise Linux 6, NetworkManager replaces the former Network Administration Tool while providing enhanced functionality, such as user-specific and mobile broadband configuration. It is also possible to configure the network in Red Hat Enterprise Linux 6 by editing interface configuration files; see Chapter 11, Network Interfaces for more information. NetworkManager may be installed by default on your version of Red Hat Enterprise Linux. To ensure that it is, run the following command as root : 10.1. The NetworkManager Daemon The NetworkManager daemon runs with root privileges and is usually configured to start up at boot time. You can determine whether the NetworkManager daemon is running by entering this command as root : The service command will report NetworkManager is stopped if the NetworkManager service is not running. To start it for the current session: Run the chkconfig command to ensure that NetworkManager starts up every time the system boots: For more information on starting, stopping and managing services and runlevels, see Chapter 12, Services and Daemons .

Commands:
~]# yum install NetworkManager
~]# service NetworkManager status NetworkManager (pid 1527) is running
~]# service NetworkManager start
~]# chkconfig NetworkManager on
Chapter 8. Using JSON for complex parameters JSON is the preferred way to describe complex parameters. An example of JSON formatted content appears below:

Commands:
hammer compute-profile values create --compute-profile-id 22 --compute-resource-id 1 --compute-attributes= '{ "cpus": 2, "corespersocket": 2, "memory_mb": 4096, "firmware": "efi", "resource_pool": "Resources", "cluster": "Example_Cluster", "guest_id": "rhel8", "path": "/Datacenters/EXAMPLE/vm/", "hardware_version": "Default", "memoryHotAddEnabled": 0, "cpuHotAddEnabled": 0, "add_cdrom": 0, "boot_order": [ "disk", "network" ], "scsi_controllers":[ { "type": "ParaVirtualSCSIController", "key":1000 }, { "type": "ParaVirtualSCSIController", "key":1001 } ] }'