mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 1. Machine APIs 1.1. ContainerRuntimeConfig [machineconfiguration.openshift.io/v1] Description ContainerRuntimeConfig describes a customized Container Runtime configuration. Type object 1.2. ControllerConfig [machineconfiguration.openshift.io/v1] Description ControllerConfig describes configuration for MachineConfigController. This is currently only used to drive the MachineConfig objects generated by the TemplateController. Type object 1.3. ControlPlaneMachineSet [machine.openshift.io/v1] Description ControlPlaneMachineSet ensures that a specified number of control plane machine replicas are running at any given time. Compatibility level 1: Stable within a major release for a minimum of 12 months or 3 minor releases (whichever is longer). Type object 1.4. KubeletConfig [machineconfiguration.openshift.io/v1] Description KubeletConfig describes a customized Kubelet configuration. Type object 1.5. MachineConfigPool [machineconfiguration.openshift.io/v1] Description MachineConfigPool describes a pool of MachineConfigs. Type object 1.6. MachineConfig [machineconfiguration.openshift.io/v1] Description MachineConfig defines the configuration for a machine Type object 1.7. MachineHealthCheck [machine.openshift.io/v1beta1] Description MachineHealthCheck is the Schema for the machinehealthchecks API Compatibility level 2: Stable within a major release for a minimum of 9 months or 3 minor releases (whichever is longer). Type object 1.8. Machine [machine.openshift.io/v1beta1] Description Machine is the Schema for the machines API Compatibility level 2: Stable within a major release for a minimum of 9 months or 3 minor releases (whichever is longer). Type object 1.9. MachineSet [machine.openshift.io/v1beta1] Description MachineSet ensures that a specified number of machines replicas are running at any given time. Compatibility level 2: Stable within a major release for a minimum of 9 months or 3 minor releases (whichever is longer). Type object

Commands:
Chapter 14. Changing resources for the OpenShift Data Foundation components When you install OpenShift Data Foundation, it comes with pre-defined resources that the OpenShift Data Foundation pods can consume. In some situations with higher I/O load, it might be required to increase these limits. To change the CPU and memory resources on the rook-ceph pods, see Section 14.1, "Changing the CPU and memory resources on the rook-ceph pods" . To tune the resources for the Multicloud Object Gateway (MCG), see Section 14.2, "Tuning the resources for the MCG" . 14.1. Changing the CPU and memory resources on the rook-ceph pods When you install OpenShift Data Foundation, it comes with pre-defined CPU and memory resources for the rook-ceph pods. You can manually increase these values according to the requirements. You can change the CPU and memory resources on the following pods: mgr mds rgw The following example illustrates how to change the CPU and memory resources on the rook-ceph pods. In this example, the existing MDS pod values of cpu and memory are increased from 1 and 4Gi to 2 and 8Gi respectively. Edit the storage cluster: <storagecluster_name> Specify the name of the storage cluster. For example: Add the following lines to the storage cluster Custom Resource (CR): Save the changes and exit the editor. Alternatively, run the oc patch command to change the CPU and memory value of the mds pod: <storagecluster_name> Specify the name of the storage cluster. For example: 14.2. Tuning the resources for the MCG The default configuration for the Multicloud Object Gateway (MCG) is optimized for low resource consumption and not performance. For more information on how to tune the resources for the MCG, see the Red Hat Knowledgebase solution Performance tuning guide for Multicloud Object Gateway (NooBaa) .

Commands:
oc edit storagecluster -n openshift-storage <storagecluster_name>
oc edit storagecluster -n openshift-storage ocs-storagecluster
spec: resources: mds: limits: cpu: 2 memory: 8Gi requests: cpu: 2 memory: 8Gi
oc patch -n openshift-storage storagecluster <storagecluster_name> --type merge --patch '{"spec": {"resources": {"mds": {"limits": {"cpu": "2","memory": "8Gi"},"requests": {"cpu": "2","memory": "8Gi"}}}}}'
oc patch -n openshift-storage storagecluster ocs-storagecluster --type merge --patch ' {"spec": {"resources": {"mds": {"limits": {"cpu": "2","memory": "8Gi"},"requests": {"cpu": "2","memory": "8Gi"}}}}} '
Chapter 1. Introduction to IdM API You can access the services of the Red Hat Identity Management with command-line and web-based interfaces. With the Identity Management API, you can interact with Identity Management services through the third-party applications and scripts that are written in Python. The Identity Management API has the JavaScript Object Notation Remote Procedure Call (JSON-RPC) interface. To use the automation for various important parts, access the Identity Management API through Python. For example, you can retrieve metadata from the server with all available commands.

Commands:
3.8. Obtaining Information about Control Groups The libcgroup-tools package contains several utilities for obtaining information about controllers, control groups, and their parameters. Listing Controllers To find the controllers that are available in your kernel and information on how they are mounted together to hierarchies, execute: Alternatively, to find the mount points of particular subsystems, execute the following command: Here controllers stands for a list of the subsystems in which you are interested. Note that the lssubsys -m command returns only the top-level mount point per each hierarchy. Finding Control Groups To list the cgroups on a system, execute as root : To restrict the output to a specific hierarchy, specify a controller and a path in the format controller : path . For example: The above command lists only subgroups of the adminusers cgroup in the hierarchy to which the cpuset controller is attached. Displaying Parameters of Control Groups To display the parameters of specific cgroups, run: where parameter is a pseudo-file that contains values for a controller, and list_of_cgroups is a list of cgroups separated with spaces. If you do not know the names of the actual parameters, use a command similar to:

Commands:
~]USD cat /proc/cgroups
~]USD lssubsys -m controllers
~]# lscgroup
~]USD lscgroup cpuset:adminusers
~]USD cgget -r parameter list_of_cgroups
~]USD cgget -g cpuset /
Chapter 25. Extending a Stratis volume with additional block devices You can attach additional block devices to a Stratis pool to provide more storage capacity for Stratis file systems. You can do it manually or by using the web console. Important Stratis is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process. For more information about the support scope of Red Hat Technology Preview features, see https://access.redhat.com/support/offerings/techpreview . 25.1. Adding block devices to a Stratis pool You can add one or more block devices to a Stratis pool. Prerequisites Stratis is installed. See Installing Stratis . The stratisd service is running. The block devices that you are adding to the Stratis pool are not in use and not mounted. The block devices that you are adding to the Stratis pool are at least 1 GiB in size each. Procedure To add one or more block devices to the pool, use: Additional resources stratis(8) man page on your system 25.2. Adding a block device to a Stratis pool by using the web console You can use the web console to add a block device to an existing Stratis pool. You can also add caches as a block device. Prerequisites You have installed the RHEL 8 web console. You have enabled the cockpit service. Your user account is allowed to log in to the web console. For instructions, see Installing and enabling the web console . The stratisd service is running. A Stratis pool is created. The block devices on which you are creating a Stratis pool are not in use and are not mounted. Each block device on which you are creating a Stratis pool is at least 1 GB. Procedure Log in to the RHEL 8 web console. For details, see Logging in to the web console . Click Storage . In the Storage table, click the Stratis pool to which you want to add a block device. On the Stratis pool page, click Add block devices and select the Tier where you want to add a block device as data or cache. If you are adding the block device to a Stratis pool that is encrypted with a passphrase, enter the passphrase. Under Block devices , select the devices you want to add to the pool. Click Add .

Commands:
stratis pool add-data my-pool device-1 device-2 device-n
1.6. Data Centers A data center is the highest level of abstraction in Red Hat Virtualization. A data center contains three types of information: Storage This includes storage types, storage domains, and connectivity information for storage domains. Storage is defined for a data center, and available to all clusters in the data center. All host clusters within a data center have access to the same storage domains. Logical networks This includes details such as network addresses, VLAN tags and STP support. Logical networks are defined for a data center, and are optionally implemented at the cluster level. Clusters Clusters are groups of hosts with compatible processor cores, either AMD or Intel processors. Clusters are migration domains; virtual machines can be live-migrated to any host within a cluster, and not to other clusters. One data center can hold multiple clusters, and each cluster can contain multiple hosts.

Commands:
Providing feedback on Red Hat documentation We appreciate your input on our documentation. Please let us know how we could make it better. To do so: Submitting feedback through Jira (account required) Log in to the Jira website. Click Create in the top navigation bar. Enter a descriptive title in the Summary field. Enter your suggestion for improvement in the Description field. Include links to the relevant parts of the documentation. Click Create at the bottom of the dialogue.

Commands:
probe::scheduler.wakeup_new Name probe::scheduler.wakeup_new - Newly created task is woken up for the first time Synopsis scheduler.wakeup_new Values name name of the probe point task_state state of the task woken up task_pid PID of the new task woken up task_tid TID of the new task woken up task_priority priority of the new task task_cpu cpu of the task woken up

Commands:
13.2.2. Preparing a Driver Disc You can create a driver update disc on CD or DVD. 13.2.2.1. Creating a driver update disc on CD or DVD Important CD/DVD Creator is part of the GNOME desktop. If you use a different Linux desktop, or a different operating system altogether, you will need to use another piece of software to create the CD or DVD. The steps will be generally similar. Make sure that the software that you choose can create CDs or DVDs from image files. While this is true of most CD and DVD burning software, exceptions exist. Look for a button or menu entry labeled burn from image or similar. If your software lacks this feature, or you do not select it, the resulting disc will hold only the image file itself, instead of the contents of the image file. Use the desktop file manager to locate the ISO image file of the driver disc, supplied to you by Red Hat or your hardware vendor. Figure 13.2. A typical .iso file displayed in a file manager window Right-click on this file and choose Write to disc . You will see a window similar to the following: Figure 13.3. CD/DVD Creator's Write to Disc dialog Click the Write button. If a blank disc is not already in the drive, CD/DVD Creator will prompt you to insert one. After you burn a driver update disc CD or DVD, verify that the disc was created successfully by inserting it into your system and browsing to it using the file manager. You should see a single file named rhdd3 and a directory named rpms : Figure 13.4. Contents of a typical driver update disc on CD or DVD If you see only a single file ending in .iso , then you have not created the disc correctly and should try again. Ensure that you choose an option similar to burn from image if you use a Linux desktop other than GNOME or if you use a different operating system. Refer to Section 13.3.2, "Let the Installer Prompt You for a Driver Update" and Section 13.3.3, "Use a Boot Option to Specify a Driver Update Disk" to learn how to use the driver update disc during installation.

Commands:
Installing Red Hat Developer Hub on OpenShift Container Platform Red Hat Developer Hub 1.3 Red Hat Customer Content Services

Commands:
global: auth: backend: enabled: true clusterRouterBase: apps.<clusterName>.com # other Red Hat Developer Hub Helm Chart configurations
Loaded config from app-config-from-configmap.yaml, env 2023-07-24T19:44:46.223Z auth info Configuring "database" as KeyStore provider type=plugin Backend failed to start up Error: Missing required config value at 'backend.database.client'
NAMESPACE=<emphasis><rhdh></emphasis> new-project USD{NAMESPACE} || oc project USD{NAMESPACE}
helm upgrade redhat-developer-hub -i https://github.com/openshift-helm-charts/charts/releases/download/redhat-redhat-developer-hub-1.3.5/redhat-developer-hub-1.3.5.tgz
PASSWORD=USD(oc get secret redhat-developer-hub-postgresql -o jsonpath="{.data.password}" | base64 -d) CLUSTER_ROUTER_BASE=USD(oc get route console -n openshift-console -o=jsonpath='{.spec.host}' | sed 's/^[^.]*\.//') helm upgrade redhat-developer-hub -i "https://github.com/openshift-helm-charts/charts/releases/download/redhat-redhat-developer-hub-1.3.5/redhat-developer-hub-1.3.5.tgz" --set global.clusterRouterBase="USDCLUSTER_ROUTER_BASE" --set global.postgresql.auth.password="USDPASSWORD"
echo "https://redhat-developer-hub-USDNAMESPACE.USDCLUSTER_ROUTER_BASE"
Chapter 3. Upgrading to the Red Hat JBoss Core Services Apache HTTP Server 2.4.57 The steps to upgrade to the latest Red Hat JBoss Core Services (JBCS) release differ depending on whether you previously installed JBCS from RPM packages or from an archive file. Upgrading JBCS when installed from RPM packages If you installed an earlier release of the JBCS Apache HTTP Server from RPM packages on RHEL 7 or RHEL 8 by using the yum groupinstall command, you can upgrade to the latest release. You can use the yum groupupdate command to upgrade to the 2.4.57 release on RHEL 7 or RHEL 8. Note JBCS does not provide an RPM distribution of the Apache HTTP Server on RHEL 9. Upgrading JBCS when installed from an archive file If you installed an earlier release of the JBCS Apache HTTP Server from an archive file, you must perform the following steps to upgrade to the Apache HTTP Server 2.4.57: Install the Apache HTTP Server 2.4.57. Set up the Apache HTTP Server 2.4.57. Remove the earlier version of Apache HTTP Server. The following procedure describes the recommended steps for upgrading a JBCS Apache HTTP Server 2.4.51 release that you installed from archive files to the latest 2.4.57 release. Prerequisites If you are using Red Hat Enterprise Linux, you have root user access. If you are using Windows Server, you have administrative access. The Red Hat JBoss Core Services Apache HTTP Server 2.4.51 or earlier was previously installed in your system from an archive file. Procedure Shut down any running instances of Red Hat JBoss Core Services Apache HTTP Server 2.4.51. Back up the Red Hat JBoss Core Services Apache HTTP Server 2.4.51 installation and configuration files. Install the Red Hat JBoss Core Services Apache HTTP Server 2.4.57 using the .zip installation method for the current system (see Additional Resources below). Migrate your configuration from the Red Hat JBoss Core Services Apache HTTP Server version 2.4.51 to version 2.4.57. Note The Apache HTTP Server configuration files might have changed since the Apache HTTP Server 2.4.51 release. Consider updating the 2.4.57 version configuration files rather than overwrite them with the configuration files from a different version, such as the Apache HTTP Server 2.4.51. Remove the Red Hat JBoss Core Services Apache HTTP Server 2.4.51 root directory. Additional Resources Installing the JBCS Apache HTTP Server on RHEL from archive files Installing the JBCS Apache HTTP Server on RHEL from RPM packages Installing the JBCS Apache HTTP Server on Windows Server

Commands:
3.6. Saving Network Packet Filter Settings After configuring the appropriate network packet filters for your situation, save the settings so they can be restored after a reboot. For iptables , enter the following command: To ensure the iptables service is started at system start, enter the following command: You can verify whether the changes persist on a reboot by running the following command and checking whether the changes remain: See the Red Hat Enterprise Linux 7 Security Guide for more information on working with iptables in Red Hat Enterprise Linux 7

Commands:
iptables-save > /etc/sysconfig/iptables
systemctl enable iptables
systemctl restart iptables
Chapter 1. About Tooling guide This guide introduces VS Code extensions for Red Hat build of Apache Camel and how to install and use Camel CLI. Important The VS Code extensions for Apache Camel are listed as development support. For more information about scope of development support, see Development Support Scope of Coverage for Red Hat Build of Apache Camel . VS Code extensions for Red Hat build of Apache Camel. Following VS Code extensions are explained in this guide. Language Support for Apache Camel The Language Support for Apache Camel extension adds the language support for Apache Camel for Java, Yaml, or XML DSL code. Debug Adapter for Apache Camel The Debug Adapter for Apache Camel adds Camel Debugger power by attaching to a running Camel route written in Java, Yaml, or XML DSL. Camel CLI This is a JBang based Camel application that you can use for running your Camel routes.

Commands:
Chapter 1. Checking which version you have installed To begin troubleshooting, determine which version of Red Hat build of MicroShift you have installed. 1.1. Checking the version using the command-line interface To begin troubleshooting, you must know your MicroShift version. One way to get this information is by using the CLI. Procedure Run the following command to check the version information: USD microshift version Example output Red Hat build of MicroShift Version: 4.18-0.microshift-e6980e25 Base OCP Version: 4.18 1.2. Checking the MicroShift version using the API To begin troubleshooting, you must know your MicroShift version. One way to get this information is by using the API. Procedure To get the version number using the OpenShift CLI ( oc ), view the kube-public/microshift-version config map by running the following command: USD oc get configmap -n kube-public microshift-version -o yaml Example output apiVersion: v1 data: major: "4" minor: "13" version: 4.13.8-0.microshift-fa441af87431 kind: ConfigMap metadata: creationTimestamp: "2023-08-03T21:06:11Z" name: microshift-version namespace: kube-public 1.3. Checking the etcd version You can get the version information for the etcd database included with your MicroShift by using one or both of the following methods, depending on the level of information that you need. Procedure To display the base database version information, run the following command: USD microshift-etcd version Example output microshift-etcd Version: 4.17.1 Base etcd Version: 3.5.13 To display the full database version information, run the following command: USD microshift-etcd version -o json Example output { "major": "4", "minor": "16", "gitVersion": "4.17.1~rc.1", "gitCommit": "140777711962eb4e0b765c39dfd325fb0abb3622", "gitTreeState": "clean", "buildDate": "2024-05-10T16:37:53Z", "goVersion": "go1.21.9" "compiler": "gc", "platform": "linux/amd64", "patch": "", "etcdVersion": "3.5.13" }

Commands:
microshift version
Red Hat build of MicroShift Version: 4.18-0.microshift-e6980e25 Base OCP Version: 4.18
oc get configmap -n kube-public microshift-version -o yaml
apiVersion: v1 data: major: "4" minor: "13" version: 4.13.8-0.microshift-fa441af87431 kind: ConfigMap metadata: creationTimestamp: "2023-08-03T21:06:11Z" name: microshift-version namespace: kube-public
microshift-etcd version
microshift-etcd Version: 4.17.1 Base etcd Version: 3.5.13
microshift-etcd version -o json
{ "major": "4", "minor": "16", "gitVersion": "4.17.1~rc.1", "gitCommit": "140777711962eb4e0b765c39dfd325fb0abb3622", "gitTreeState": "clean", "buildDate": "2024-05-10T16:37:53Z", "goVersion": "go1.21.9" "compiler": "gc", "platform": "linux/amd64", "patch": "", "etcdVersion": "3.5.13" }
5.31. control-center 5.31.1. RHBA-2012:0950 - control-center bug fix and enhancement update Updated control-center packages that fix one bug and add various enhancements are now available for Red Hat Enterprise Linux 6. The control-center packages contain various configuration utilities for the GNOME desktop. These utilities allow the user to configure accessibility options, desktop fonts, keyboard and mouse properties, sound setup, desktop theme and background, user interface properties, screen resolution, and other settings. Bug Fix BZ# 771600 versions of the control-center package contained gnome-at-mobility, a script that requires a software component that is not distributed with Red Hat Enterprise Linux 6 nor is present in any of the available channels. With this update, the non-functional gnome-at-mobility script has been removed and is no longer distributed as part of the control-center package. Enhancements BZ# 524942 The background configuration tool now uses the XDG Base Directory Specification to determine where to store its data file. By default, this file is located at ~/.config/gnome-control-center/backgrounds.xml. Users can change the ~/.config/ prefix by setting the XDG_DATA_HOME environment variable, or set the GNOMECC_USE_OLD_BG_PATH environment variable to 1 to restore the old behavior and use the ~/.gnome2/backgrounds.xml file. BZ# 632680 The control-center-extra package now includes a GNOME Control Center shell. This shell provides a user interface for launching the various Control Center utilities. BZ# 769465 , BZ# 801363 The GNOME Control Center now provides a configuration utility for Wacom graphics tablets, which replaces the wacompl utility. All users of control-center are advised to upgrade to these updated packages, which fix this bug and add these enhancements.

Commands:
6.3. Resource-Specific Parameters For any individual resource, you can use the following command to display the parameters you can set for that resource. For example, the following command displays the parameters you can set for a resource of type LVM .

Commands:
pcs resource describe standard:provider:type | type
pcs resource describe LVM Resource options for: LVM volgrpname (required): The name of volume group. exclusive: If set, the volume group will be activated exclusively. partial_activation: If set, the volume group will be activated even only partial of the physical volumes available. It helps to set to true, when you are using mirroring logical volumes.
function::user_string_n_warn Name function::user_string_n_warn - Retrieves string from user space Synopsis Arguments addr the user space address to retrieve the string from n the maximum length of the string (if not null terminated) Description Returns up to n characters of a C string from a given user space memory address. Reports " <unknown> " on the rare cases when userspace data is not accessible and warns (but does not abort) about the failure.

Commands:
user_string_n_warn:string(addr:long,n:long)