mtpti5iD/redhat-docs_dataset huggingface dataset:
4.30. clustermon 4.30.1. RHEA-2011:1550 - clustermon bug fix update Updated clustermon packages that fix a bug and add an enhancement are now available for Red Hat Enterprise Linux 6. The clustermon packages are used for remote cluster management. Bug Fix BZ# 634373 Previously, the clustermon tool failed to shut down nodes if the user had mounted a GFS2 file system that was not listed in the /etc/fstab file. This was caused by clustermon relying on the rgmanager tool and the GFS2 init scripts to unmount all file systems, but the cluster stack would not stop properly if the user mounted the file system manually. This has been fixed: clustermon now ensures that there are no cluster file systems mounted and then attempts to stop the cluster stack. Enhancement BZ# 724978 The "get_cluster_schema" function call has been added to allow users to easily get the XML cluster schema content. All users of clustermon are advised to upgrade to this updated packages, which resolves this bug.

Commands:
Chapter 11. DeploymentLog [apps.openshift.io/v1] Description DeploymentLog represents the logs for a deployment Compatibility level 1: Stable within a major release for a minimum of 12 months or 3 minor releases (whichever is longer). Type object 11.1. Specification Property Type Description apiVersion string APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources kind string Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds 11.2. API endpoints The following API endpoints are available: /apis/apps.openshift.io/v1/namespaces/{namespace}/deploymentconfigs/{name}/log GET : read log of the specified DeploymentConfig 11.2.1. /apis/apps.openshift.io/v1/namespaces/{namespace}/deploymentconfigs/{name}/log Table 11.1. Global path parameters Parameter Type Description name string name of the DeploymentLog namespace string object name and auth scope, such as for teams and projects Table 11.2. Global query parameters Parameter Type Description container string The container for which to stream logs. Defaults to only container if there is one container in the pod. follow boolean Follow if true indicates that the build log should be streamed until the build terminates. limitBytes integer If set, the number of bytes to read from the server before terminating the log output. This may not display a complete final line of logging, and may return slightly more or slightly less than the specified limit. nowait boolean NoWait if true causes the call to return immediately even if the deployment is not available yet. Otherwise the server will wait until the deployment has started. pretty string If 'true', then the output is pretty printed. boolean Return deployment logs. Defaults to false. sinceSeconds integer A relative time in seconds before the current time from which to show logs. If this value precedes the time a pod was started, only logs since the pod start will be returned. If this value is in the future, no logs will be returned. Only one of sinceSeconds or sinceTime may be specified. tailLines integer If set, the number of lines from the end of the logs to show. If not specified, logs are shown from the creation of the container or sinceSeconds or sinceTime timestamps boolean If true, add an RFC3339 or RFC3339Nano timestamp at the beginning of every line of log output. Defaults to false. version integer Version of the deployment for which to view logs. HTTP method GET Description read log of the specified DeploymentConfig Table 11.3. HTTP responses HTTP code Reponse body 200 - OK DeploymentLog schema 401 - Unauthorized Empty

Commands:
9.11. Viewing Certificates and CRLs Published to File Certificates and CRLs can be published to two types of files: base-64 encoded or DER-encoded. The content of these files can be viewed by converting the files to pretty-print format using the dumpasn1 tool or the PrettyPrintCert or PrettyPrintCrl tool. To view the content in a base-64 encoded file: Convert the base-64 file to binary. For example: Use the PrettyPrintCert or PrettyPrintCrl tool to convert the binary file to pretty-print format. For example: To view the content of a DER-encoded file, simply run the dumpasn1 , PrettyPrintCert , or PrettyPrintCrl tool with the DER-encoded file. For example:

Commands:
AtoB /tmp/example.b64 /tmp/example.bin
PrettyPrintCert example.bin example.cert
PrettyPrintCrl example.der example.crl
1.2. Red Hat Cluster Suite Introduction Red Hat Cluster Suite (RHCS) is an integrated set of software components that can be deployed in a variety of configurations to suit your needs for performance, high-availability, load balancing, scalability, file sharing, and economy. RHCS consists of the following major components (refer to Figure 1.1, "Red Hat Cluster Suite Introduction" ): Cluster infrastructure - Provides fundamental functions for nodes to work together as a cluster: configuration-file management, membership management, lock management, and fencing. High-availability Service Management - Provides failover of services from one cluster node to another in case a node becomes inoperative. Cluster administration tools - Configuration and management tools for setting up, configuring, and managing a Red Hat cluster. The tools are for use with the Cluster Infrastructure components, the High-availability and Service Management components, and storage. Linux Virtual Server (LVS) - Routing software that provides IP-Load-balancing. LVS runs in a pair of redundant servers that distributes client requests evenly to real servers that are behind the LVS servers. You can supplement Red Hat Cluster Suite with the following components, which are part of an optional package (and not part of Red Hat Cluster Suite): Red Hat GFS (Global File System) - Provides a cluster file system for use with Red Hat Cluster Suite. GFS allows multiple nodes to share storage at a block level as if the storage were connected locally to each cluster node. Cluster Logical Volume Manager (CLVM) - Provides volume management of cluster storage. Note When you create or modify a CLVM volume for a clustered environment, you must ensure that you are running the clvmd daemon. For further information, refer to Section 1.6, "Cluster Logical Volume Manager" . Global Network Block Device (GNBD) - An ancillary component of GFS that exports block-level storage to Ethernet. This is an economical way to make block-level storage available to Red Hat GFS. For a lower level summary of Red Hat Cluster Suite components and optional software, refer to Chapter 2, Red Hat Cluster Suite Component Summary . Figure 1.1. Red Hat Cluster Suite Introduction Note Figure 1.1, "Red Hat Cluster Suite Introduction" includes GFS, CLVM, and GNBD, which are components that are part of an optional package and not part of Red Hat Cluster Suite.

Commands:
4.7. Configuring Virtual NUMA In the Administration Portal, you can configure virtual NUMA nodes on a virtual machine and pin them to physical NUMA nodes on one or more hosts. The host's default policy is to schedule and run virtual machines on any available resources on the host. As a result, the resources backing a large virtual machine that cannot fit within a single host socket could be spread out across multiple NUMA nodes. Over time these resources may be moved around, leading to poor and unpredictable performance. Configure and pin virtual NUMA nodes to avoid this outcome and improve performance. Configuring virtual NUMA requires a NUMA-enabled host. To confirm whether NUMA is enabled on a host, log in to the host and run numactl --hardware . The output of this command should show at least two NUMA nodes. You can also view the host's NUMA topology in the Administration Portal by selecting the host from the Hosts tab and clicking NUMA Support . This button is only available when the selected host has at least two NUMA nodes. Note If you define NUMA Pinning , the default migration mode is Allow manual migration only by default. Configuring Virtual NUMA Click Compute Virtual Machines and select a virtual machine. Click Edit . Click the Host tab. Select the Specific Host(s) radio button and select the host(s) from the list. The selected host(s) must have at least two NUMA nodes. Enter a number into the NUMA Node Count field to assign virtual NUMA nodes to the virtual machine. Select Strict , Preferred , or Interleave from the Tune Mode drop-down list. If the selected mode is Preferred , the NUMA Node Count must be set to 1 . Click NUMA Pinning . In the NUMA Topology window, click and drag virtual NUMA nodes from the box on the right to host NUMA nodes on the left as required, and click OK . Click OK . Note If you do not pin the virtual NUMA node to a host NUMA node, the system defaults to the NUMA node that contains the host device's memory-mapped I/O (MMIO), provided that there are one or more host devices and all of those devices are from a single NUMA node.

Commands:
Chapter 1. Overview of automated rules You can use automated rules to enable JFR to continuously monitor a running target application. You do not need to restart or redeploy the application. Continuous monitoring event templates exist in Cryostat that you can use to create automated rules and templates. By using continuous monitoring event templates, you can reduce any downtime for specifying a JFR to continuously monitoring an application. You can define automated rules regardless of whether you configure your target applications to use a Java Management Extensions (JMX) connection or an agent HTTP API connection. For more information about configuring your target applications, see Configuring Java applications . Consider the following guidelines: If your target JVMs use an agent HTTP API connection, ensure that you set the cryostat.agent.api.writes-enabled property to true in your target application's configuration. Otherwise, the Cryostat agent cannot accept on-demand requests to start, stop, and delete JFR recordings based on automated rules. If your target JVMs use a JMX connection, before you create an automated rule that applies to multiple target JVMs that each require JMX credentials, consider storing credentials for each JVM on the Cryostat web console. Storing credentials ensures that your automated rule starts, because Cryostat maintains a connection with each target JVM. For more information, see Storing and managing JMX credentials (Using Cryostat to manage a JFR recording) . Cryostat can also store JMX credentials in a keyring database. In this database, JMX credentials are encrypted by a user-provided passphrase that Cryostat supplies with the CRYOSTAT_JMX_CREDENTIALS_DB_PASSWORD environment variable.

Commands:
function::bytes_to_string Name function::bytes_to_string - Human readable string for given bytes Synopsis Arguments bytes Number of bytes to translate. Description Returns a string representing the number of bytes (up to 1024 bytes), the number of kilobytes (when less than 1024K) postfixed by 'K', the number of megabytes (when less than 1024M) postfixed by 'M' or the number of gigabytes postfixed by 'G'. If representing K, M or G, and the number is amount is less than 100, it includes a '.' plus the remainer. The returned string will be 5 characters wide (padding with whitespace at the front) unless negative or representing more than 9999G bytes.

Commands:
function bytes_to_string:string(bytes:long)
14.8.5. Undefining a Domain This command will undefine a domain. Although it can work on a running domain, it will convert the running domain into a transient domain without stopping it. If the domain is inactive, the domain configuration is removed. The command can take the following options: --managed-save - this option guarantees that any managed save image is also cleaned up. Without using this option, attempts to undefine a domain with a managed save image will fail. --snapshots-metadata - this option guarantees that any snapshots (as shown with snapshot-list ) are also cleaned up when undefining an inactive domain. Note that any attempts to undefine an inactive domain whose configuration file contains snapshot metadata will fail. If this option is used and the domain is active, it is ignored. --storage - using this option requires a comma separated list of volume target names or source paths of storage volumes to be removed along with the undefined domain. This action will undefine the storage volume before it is removed. Note that this can only be done with inactive domains. Note too that this will only work with storage volumes that are managed by libvirt . --remove-all-storage - in addition to undefining the domain, all associated storage volumes are deleted. --wipe-storage - in addition to deleting the storage volume, the contents are wiped.

Commands:
virsh undefine domain --managed-save --snapshots-metadata --storage --remove-all-storage --wipe-storage
Chapter 24. Removing Certificate System Subsystem Packages A number of subsystem-related packages and dependencies are installed with Red Hat Certificate System; these are listed in Section 7.2, "Certificate System Packages" . Removing a subsystem removes only the files and directories associated with that specific subsystem. It does not remove the actual installed packages that are used by that instance. Completely uninstalling Red Hat Certificate System or one of its subsystems requires using package management tools, like yum , to remove each package individually. To uninstall an individual Certificate System subsystem packages: Remove all the associated subsystems. For example: Run the uninstall utility. For example: The subsystem type can be ca , kra , ocsp , tks , or tps . To remove other packages and dependencies, remove the packages specifically, using yum . The complete list of installed packages is at Section 7.2, "Certificate System Packages" .

Commands:
pkidestroy -s CA -i pki-tomcat
remove pki- subsystem_type
Chapter 3. Networking Operators overview OpenShift Container Platform supports multiple types of networking Operators. You can manage the cluster networking using these networking Operators. 3.1. Cluster Network Operator The Cluster Network Operator (CNO) deploys and manages the cluster network components in an OpenShift Container Platform cluster. This includes deployment of the Container Network Interface (CNI) default network provider plugin selected for the cluster during installation. For more information, see Cluster Network Operator in OpenShift Container Platform . 3.2. DNS Operator The DNS Operator deploys and manages CoreDNS to provide a name resolution service to pods. This enables DNS-based Kubernetes Service discovery in OpenShift Container Platform. For more information, see DNS Operator in OpenShift Container Platform . 3.3. Ingress Operator When you create your OpenShift Container Platform cluster, pods and services running on the cluster are each allocated IP addresses. The IP addresses are accessible to other pods and services running nearby but are not accessible to external clients. The Ingress Operator implements the Ingress Controller API and is responsible for enabling external access to OpenShift Container Platform cluster services. For more information, see Ingress Operator in OpenShift Container Platform .

Commands:
Support Red Hat Advanced Cluster Security for Kubernetes 4.5 Getting support for Red Hat Advanced Cluster Security for Kubernetes Red Hat OpenShift Documentation Team

Commands:
export ROX_PASSWORD= <rox_password> && export ROX_CENTRAL_ADDRESS= <address>:<port_number> 1
roxctl -e "USDROX_CENTRAL_ADDRESS" -p "USDROX_PASSWORD" central debug download-diagnostics
export ROX_API_TOKEN= <api_token>
roxctl -e "USDROX_CENTRAL_ADDRESS" central debug download-diagnostics
Chapter 14. Basic Subsystem Management This chapter discusses the Certificate System administrative console, the configuration files, and other basic administrative tasks such as starting and stopping the server, managing logs, changing port assignments, and changing the internal database. 14.1. PKI Instances This version of the Certificate System continues to support separate PKI instances for all subsystems. Separate PKI instances run as a single Java-based Apache Tomcat instance, contain a single PKI subsystem (CA, KRA, OCSP, TKS, or TPS), and must utilize unique ports if co-located on the same physical machine or virtual machine (VM). Additionally, this version of the Certificate System introduces the notion of a shared PKI instance . Shared PKI instances run as a single Java-based Apache Tomcat instance, can contain a single PKI subsystem that is identical to a separate PKI instance, can contain any combination of up to one of each type of PKI subsystem: CA TKS CA, KRA CA, OCSP TKS, TPS CA, KRA, TKS, TPS CA, KRA, OCSP, TKS, TPS and so on. allow all of their subsystems contained within that instance to share the same ports, and must utilize unique ports if more than one is co-located on the same physical machine or VM.

Commands:
6.12. Virtual Machine Resources Virtual machine resources are configured differently than other cluster resources. In particular, they are not grouped into service definitions. As of the Red Hat Enterprise Linux 6.2 release, when you configure a virtual machine in a cluster with the ccs command you can use the --addvm (rather than the addservice option). This ensures that the vm resource is defined directly under the rm configuration node in the cluster configuration file. A virtual machine resource requires at least a name and a path attribute. The name attribute should match the name of the libvirt domain and the path attribute should specify the directory where the shared virtual machine definitions are stored. Note The path attribute in the cluster configuration file is a path specification or a directory name, not a path to an individual file. If virtual machine definitions are stored on a shared directory named /mnt/vm_defs , the following command will define a virtual machine named guest1 : Running this command adds the following line to the rm configuration node in the cluster.conf file:

Commands:
ccs -h node1.example.com --addvm guest1 path=/mnt/vm_defs
<vm name="guest1" path="/mnt/vm_defs"/>
Chapter 4. Custom user attributes You can add custom user attributes to the registration page with a custom theme. 4.1. Registration page Use this procedure to enter custom attributes in the registration page. Procedure Copy the template themes/base/login/register.ftl to the login type of your custom theme. Open the copy in an editor. For example, to add a mobile number to the registration page, add the following snippet to the form: <div class="form-group"> <div class="USD{properties.kcLabelWrapperClass!}"> <label for="user.attributes.mobile" class="USD{properties.kcLabelClass!}">Mobile number</label> </div> <div class="USD{properties.kcInputWrapperClass!}"> <input type="text" class="USD{properties.kcInputClass!}" id="user.attributes.mobile" name="user.attributes.mobile" value="USD{(register.formData['user.attributes.mobile']!'')}"/> </div> </div> Ensure the name of the input html element starts with user.attributes . In the example above, the attribute will be stored by Red Hat build of Keycloak with the name mobile . To see the changes, make sure your realm is using your custom theme for the login theme and open the registration page. 4.2. Additional resources See Themes for how to create a custom theme.

Commands:
<div class="form-group"> <div class="USD{properties.kcLabelWrapperClass!}"> <label for="user.attributes.mobile" class="USD{properties.kcLabelClass!}">Mobile number</label> </div> <div class="USD{properties.kcInputWrapperClass!}"> <input type="text" class="USD{properties.kcInputClass!}" id="user.attributes.mobile" name="user.attributes.mobile" value="USD{(register.formData['user.attributes.mobile']!'')}"/> </div> </div>
Configuring OpenShift Data Foundation Disaster Recovery for OpenShift Workloads Red Hat OpenShift Data Foundation 4.16 The OpenShift Data Foundation Disaster Recovery capabilities for Metropolitan and Regional regions is now General Available which also includes Disaster Recovery with stretch cluster. Red Hat Storage Documentation Team Abstract The intent of this solution guide is to detail the steps necessary to deploy OpenShift Data Foundation for disaster recovery with Advanced Cluster Management and stretch cluster to achieve a highly available storage infrastructure.

Commands:
7.252. tboot 7.252.1. RHBA-2013:0524 - tboot bug fix update Updated tboot packages that fix two bugs are now available for Red Hat Enterprise Linux 6. The tboot packages provide the Trusted Boot (tboot) open source pre-kernel/VMM module. This module uses Intel Trusted Execution Technology (Intel TXT) to initialize the launch of operating system kernels and virtual machines. Bug Fixes BZ#885684 Due to an error in the underlying source code, a buffer overflow could occur and an attempt to boot the kernel with tboot enabled could fail with the following error: Kernel panic - not syncing: Too many boot init vars at `numbers,' This update applies an upstream patch that corrects this error, and the kernel now boots as expected. BZ#834323 Prior to this update, the installed README file incorrectly identified the supported kernels. This update corrects this file and ensures that it no longer contains incorrect information. All users of tboot are advised to upgrade to these updated packages, which fix these bugs.

Commands:
Chapter 7. Disabling the web console in OpenShift Container Platform You can disable the OpenShift Container Platform web console. 7.1. Prerequisites Deploy an OpenShift Container Platform cluster. 7.2. Disabling the web console You can disable the web console by editing the consoles.operator.openshift.io resource. Edit the consoles.operator.openshift.io resource: USD oc edit consoles.operator.openshift.io cluster The following example displays the parameters from this resource that you can modify: apiVersion: operator.openshift.io/v1 kind: Console metadata: name: cluster spec: managementState: Removed 1 1 Set the managementState parameter value to Removed to disable the web console. The other valid values for this parameter are Managed , which enables the console under the cluster's control, and Unmanaged , which means that you are taking control of web console management.

Commands:
oc edit consoles.operator.openshift.io cluster
apiVersion: operator.openshift.io/v1 kind: Console metadata: name: cluster spec: managementState: Removed 1