mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 1. Migrating Camel Quarkus projects 1.1. Updating projects to the latest Quarkus version We recommend that you use Maven to update and upgrade your projects to the latest Quarkus version. Important For projects that use Hibernate ORM or Hibernate Reactive, review the Hibernate ORM 5 to 6 migration quick reference. The following update command covers only a subset of this guide. 1.1.1. Prerequisites Roughly 30 minutes JDK installed with JAVA_HOME configured appropriately Apache Maven 3.8.6 Optionally, the Quarkus CLI if you want to use it A project based on Camel Quarkus version 2.13 or later. 1.2. Updating with Maven Configure your extension registry client as described in the Configuring Quarkus extension registry client section of the Quarkus Getting Started guide. Update with Maven: Go to the project directory and update the project to the latest stream: Ensure that the Quarkus Maven plugin version aligns with the latest supported Red Hat build of Quarkus version. Run the update with the following command: mvn io.quarkus.platform:quarkus-maven-plugin:3.15.3.SP1-redhat-00002:update -N For multi-module projects , always first try the following command: mvn io.quarkus.platform:quarkus-maven-plugin:3.15.3.SP1-redhat-00002:update If this command fails, you can instead try this longer command: find . -type f -name "pom.xml" -execdir sh -c 'mvn io.quarkus.platform:quarkus-maven-plugin:3.15.3.SP1-redhat-00002:update -N' \; Note Due to an issue with OpenRewrite , warnings are preset in the migration log. Optional By default, this command updates to the latest current version. To update to a specific stream instead of latest current version, add the stream option to this command followed by the version; for example: -Dstream=3.2 Analyze the update command output for potential instructions and perform the suggested tasks if needed. Use a diff tool to inspect all changes. Review the migration guide for items that were not updated by the update command. If your project has such items, implement the additional steps advised in these topics. Note In some cases versions might not upgrade correctly, and may not match the migration to Quarkus. If so, you must change the version manually. See Migrating Apache Camel for instructions. Ensure the project builds without errors, all tests pass, and the application functions as required before deploying to production. Before deploying your updated Quarkus application to production, ensure the following: The project builds without errors. All tests pass. The application functions as required.

Commands:
mvn io.quarkus.platform:quarkus-maven-plugin:3.15.3.SP1-redhat-00002:update -N
mvn io.quarkus.platform:quarkus-maven-plugin:3.15.3.SP1-redhat-00002:update
find . -type f -name "pom.xml" -execdir sh -c 'mvn io.quarkus.platform:quarkus-maven-plugin:3.15.3.SP1-redhat-00002:update -N' \;
Chapter 2. Upgrading a host operating system from RHEL 8 to RHEL 9 You can perform a Red Hat Ceph Storage host operating system upgrade from Red Hat Enterprise Linux 8 to Red Hat Enterprise Linux 9 using the Leapp utility. Prerequisites A running Red Hat Ceph Storage 5 cluster. The following are the supported combinations of containerized Ceph daemons. For more information, see the How colocation works and its advantages section in the Red Hat Ceph Storage Installation Guide . Ceph Metadata Server ( ceph-mds ), Ceph OSD ( ceph-osd ), and Ceph Object Gateway ( radosgw ) Ceph Monitor ( ceph-mon ) or Ceph Manager ( ceph-mgr ), Ceph OSD ( ceph-osd ), and Ceph Object Gateway ( radosgw ) Ceph Monitor ( ceph-mon ), Ceph Manager ( ceph-mgr ), Ceph OSD ( ceph-osd ), and Ceph Object Gateway ( radosgw ) Procedure Deploy Red Hat Ceph Storage 5 on Red Hat Enterprise Linux 8 with service. Note Verify that the cluster contains two admin nodes, so that while performing host upgrade in one admin node (with _admin label), the second admin can be used for managing clusters. For full instructions, see Red Hat Ceph Storage installation in the Red Hat Ceph Storage Installation Guide and Deploying the Ceph daemons using the service specifications in the Operations guide . Set the noout flag on the Ceph OSD. Example Perform host upgrade one node at a time using the Leapp utility. Put respective node maintenance mode before performing host upgrade using Leapp. Syntax Example Enable the ceph tools repo manually when executing the Leapp command with the --enablerepo parameter. Example Refer to Upgrading RHEL 8 to RHEL 9 within the Red Hat Enterprise Linux product documentation on the Red Hat Customer Portal. Important After performing in-place upgrade from Red Hat Enterprise Linux 8 to Red Hat Enterprise Linux 9, you need to manually enable and start the logrotate.timer service. Verify the new IMAGE_ID and VERSION of the Ceph cluster: Example Continue with the Red Hat Ceph Storage 5 to Red Hat Ceph Storage 6 upgrade by following the Upgrading the Red Hat Ceph Storage cluster steps in the Red Hat Ceph Storage Upgrade Guide .

Commands:
ceph osd set noout
ceph orch host maintenance enter HOST
ceph orch host maintenance enter host01
leapp upgrade --enablerepo rhceph-5-tools-for-rhel-9-x86_64-rpms
systemctl start logrotate.timer systemctl enable logrotate.timer
ceph version ceph orch ps
24.6. Saving Your Settings If you do not want to save your Apache HTTP Server configuration settings, click the Cancel button in the bottom right corner of the HTTP Configuration Tool window. You are prompted to confirm this decision. If you click Yes to confirm this choice, your settings are not saved. If you want to save your Apache HTTP Server configuration settings, click the OK button in the bottom right corner of the HTTP Configuration Tool window. A dialog window appears. If you answer Yes , your settings are saved in /etc/httpd/conf/httpd.conf . Remember that your original configuration file is overwritten with your new settings. If this is the first time that you have used the HTTP Configuration Tool , a dialog window appears, warning you that the configuration file has been manually modified. If the HTTP Configuration Tool detects that the httpd.conf configuration file has been manually modified, it saves the manually modified file as /etc/httpd/conf/httpd.conf.bak . Important After saving your settings, you must restart the httpd daemon with the command service httpd restart . You must be logged in as root to execute this command.

Commands:
2.2. Special Red Hat Enterprise Linux File Locations Red Hat Enterprise Linux extends the FHS structure slightly to accommodate special files. Most files pertaining to RPM are kept in the /var/lib/rpm/ directory. For more information on RPM, see man rpm . The /var/cache/yum/ directory contains files used by the Package Updater , including RPM header information for the system. This location may also be used to temporarily store RPMs downloaded while updating the system. For more information about the Red Hat Network, see https://rhn.redhat.com/ . Another location specific to Red Hat Enterprise Linux is the /etc/sysconfig/ directory. This directory stores a variety of configuration information. Many scripts that run at boot time use the files in this directory.

Commands:
Chapter 1. About Red Hat OpenShift Pipelines Red Hat OpenShift Pipelines is a cloud-native, continuous integration and continuous delivery (CI/CD) solution based on Kubernetes resources. It uses Tekton building blocks to automate deployments across multiple platforms by abstracting away the underlying implementation details. Tekton introduces a number of standard custom resource definitions (CRDs) for defining CI/CD pipelines that are portable across Kubernetes distributions. Note Because Red Hat OpenShift Pipelines releases on a different cadence from OpenShift Container Platform, the Red Hat OpenShift Pipelines documentation is now available as separate documentation sets for each minor version of the product. The Red Hat OpenShift Pipelines documentation is available at https://docs.openshift.com/pipelines/ . Documentation for specific versions is available using the version selector drop-down list, or directly by adding the version to the URL, for example, https://docs.openshift.com/pipelines/1.18 . In addition, the Red Hat OpenShift Pipelines documentation is also available on the Red Hat Customer Portal at https://access.redhat.com/documentation/en-us/red_hat_openshift_pipelines/ . For additional information about the Red Hat OpenShift Pipelines life cycle and supported platforms, refer to the Platform Life Cycle Policy .

Commands:
21.7. Multiple JMX Domains Multiple JMX domains are used when multiple CacheManager instances exist on a single virtual machine, or if the names of cache instances in different CacheManagers clash. To resolve this issue, name each CacheManager in manner that allows it to be easily identified and used by monitoring tools such as JMX and JBoss Operations Network. Set a CacheManager Name Declaratively Add the following snippet to the relevant CacheManager configuration: Set a CacheManager Name Programmatically Add the following code to set the CacheManager name programmatically: Report a bug

Commands:
<globalJmxStatistics enabled="true" cacheManagerName="Hibernate2LC"/>
GlobalConfiguration globalConfiguration = new GlobalConfigurationBuilder().globalJmxStatistics().enable(). cacheManagerName("Hibernate2LC").build();
Chapter 1. Role-Based Access Control (RBAC) in Red Hat Developer Hub Role-Based Access Control is a security paradigm that restricts access to authorized users. This feature includes defining roles with specific permissions and then assigning those roles to the users. The Red Hat Developer Hub uses RBAC to improve the permission system within the platform. The RBAC feature in Developer Hub introduces an administrator role and leverages the organizational structure including teams, groups, and users by facilitating efficient access control.

Commands:
Chapter 10. IO subsystem tuning The io subsystem defines XNIO workers and buffer pools that are used by other JBoss EAP subsystems, such as Undertow and Remoting. 10.1. Configuring workers You can create multiple separate workers that each have their own performance configuration and which handle different I/O tasks. For example, you could create one worker to handle HTTP I/O, and another worker to handle Jakarta Enterprise Beans I/O, and then separately configure the attributes of each worker for specific load requirements. Worker attributes that significantly affect performance include io-threads which sets the total number of I/O threads that a worker can use, and task-max-threads which sets the maximum number of threads that can be used for a particular task. The defaults for these two attributes are calculated based on the server's CPU count. 10.1.1. Monitoring worker statistics You can view a worker's runtime statistics using the management CLI. This exposes worker statistics such as connection count, thread count, and queue size. The following command displays runtime statistics for the default worker: Note The number of core threads, which is tracked by the core-pool-size statistic, is currently always set to the same value as the maximum number of threads, which is tracked by the max-pool-size statistic. 10.2. Configuring buffer pools Note IO buffer pools are deprecated, but they are still set as the default in the current release. A buffer pool in the io subsystem is a pooled NIO buffer instance that is used specifically for I/O operations. Like workers, you can create separate buffer pools which can be dedicated to handle specific I/O tasks. The main buffer pool attribute that significantly affects performance is buffer-size . The default is calculated based on the RAM resources of your system, and is sufficient in most cases. If you are configuring this attribute manually, an ideal size for most servers is 16KB.

Commands:
/subsystem=io/worker=default:read-resource(include-runtime=true,recursive=true)
5.5.4. Adding a GULM Client-only Member The procedure for adding a member to a running GULM cluster depends on the type of GULM node: either a node that functions only as a GULM client (a cluster member capable of running applications, but not eligible to function as a GULM lock server) or a node that functions as a GULM lock server. This procedure describes how to add a member that functions only as a GULM client. To add a member that functions as a GULM lock server, refer to Section 5.5.6, "Adding or Deleting a GULM Lock Server Member" . To add a member that functions only as a GULM client to an existing cluster that is currently in operation, follow these steps: At one of the running members, start system-config-cluster (refer to Section 5.2, "Starting the Cluster Configuration Tool " ). At the Cluster Configuration Tool tab, add the node and configure fencing for it as in Section 5.5.1, "Adding a Member to a New Cluster" . Click Send to Cluster to propagate the updated configuration to other running nodes in the cluster. Use the scp command to send the updated /etc/cluster/cluster.conf file from one of the existing cluster nodes to the new node. Start cluster services on the new node by running the following commands in this order: service ccsd start service lock_gulmd start service clvmd start , if CLVM has been used to create clustered volumes service gfs start , if you are using Red Hat GFS service rgmanager start , if the cluster is running high-availability services ( rgmanager ) At system-config-cluster , in the Cluster Configuration Tool tab, verify that the configuration is correct. At the Cluster Status Tool tab verify that the nodes and services are running as expected. Note Make sure to configure other parameters that may be affected by changes in this section. Refer to Section 5.1, "Configuration Tasks" .

Commands:
Chapter 1. Compatibility Matrix for Red Hat Ceph Storage 6.0 The following tables list products and their versions compatible with Red Hat Ceph Storage 6.0. Host Operating System Version Notes Red Hat Enterprise Linux 8.7, 8.8, 9.0, 9.1, 9.2 Standard lifecycle 9.0, 9.1, and 9.2 Note Red Hat Ceph Storage 6.0 supports Red Hat Enterprise Linux 8.7 and 8.8 with bootstrap node in supported Red Hat Enterprise Linux 9.x versions. Important All nodes in the cluster and their clients must use the supported OS version(s) to ensure that the version of the ceph package is the same on all nodes. Using different versions of the ceph package is not supported. Important Red Hat no longer supports using Ubuntu as a host operating system to deploy Red Hat Ceph Storage. Product Version Notes Ansible Supported in a limited capacity. Supported for upgrade and conversion to Cephadm and for other minimal playbooks. Red Hat OpenShift 3.x RBD, Cinder and CephFS drivers are supported. Red Hat OpenShift Data Foundation See the Red Hat OpenShift Data Foundation Supportability and Interoperability Checker for detailed external mode version compatibility. Red Hat Satellite 6.x Only registering with the Content Delivery Network (CDN) is supported. Registering with Red Hat Network (RHN) is deprecated and not supported. Client Connector Version Notes S3A 2.8.x, 3.2.x, and trunk Red Hat Ceph Storage as a backup target Version Notes CommVault Cloud Data Management v11 IBM Spectrum Protect Plus 10.1.5 IBM Spectrum Protect server 8.1.8 NetApp AltaVault 4.3.2 and 4.4 Rubrik Cloud Data Management (CDM) 3.2 onwards Trilio, TrilioVault 3.0 S3 target Veeam (object storage) Veeam Availability Suite 9.5 Update 4 Supported on Red Hat Ceph Storage object storage with the S3 protocol Veritas NetBackup for Symantec OpenStorage (OST) cloud backup 7.7 and 8.0 Independent Software vendors Version Notes IBM Spectrum Discover 2.0.3 WekaIO 3.12.2

Commands:
23.3. The Graphical Installation Program User Interface If you have used a graphical user interface (GUI) before, you are already familiar with this process; use your mouse to navigate the screens, click buttons, or enter text fields. You can also navigate through the installation using the keyboard. The Tab key allows you to move around the screen, the Up and Down arrow keys to scroll through lists, + and - keys expand and collapse lists, while Space and Enter selects or removes from selection a highlighted item. You can also use the Alt + X key command combination as a way of clicking on buttons or making other screen selections, where X is replaced with any underlined letter appearing within that screen.

Commands:
Chapter 9. Satellite host management and monitoring in the web console After enabling RHEL web console integration on a Red Hat Satellite Server, you manage many hosts at scale in the web console. Red Hat Satellite is a system management solution for deploying, configuring, and maintaining your systems across physical, virtual, and cloud environments. Satellite provides provisioning, remote management and monitoring of multiple Red Hat Enterprise Linux deployments with a centralized tool. By default, RHEL web console integration is disabled in Red Hat Satellite. To access RHEL web console features for your hosts from within Red Hat Satellite, you must first enable RHEL web console integration on a Red Hat Satellite Server. To enable the RHEL web console on your Satellite Server, enter the following command as root : Additional resources Host management and monitoring by using the RHEL web console in the Managing hosts in Red Hat Satellite guide

Commands:
satellite-installer --enable-foreman-plugin-remote-execution-cockpit --reset-foreman-plugin-remote-execution-cockpit-ensure
2.2. Web Server Configuration The following procedure configures an Apache HTTP server. Ensure that the Apache HTTP server is installed on each node in the cluster. You also need the wget tool installed on the cluster to be able to check the status of the Apache HTTP server. On each node, execute the following command. In order for the Apache resource agent to get the status of the Apache HTTP server, ensure that the following text is present in the /etc/httpd/conf/httpd.conf file on each node in the cluster, and ensure that it has not been commented out. If this text is not already present, add the text to the end of the file. When you use the apache resource agent to manage Apache, it does not use systemd . Because of this, you must edit the logrotate script supplied with Apache so that it does not use systemctl to reload Apache. Remove the following line in the /etc/logrotate.d/httpd file on each node in the cluster. Replace the line you removed with the following three lines. Create a web page for Apache to serve up. On one node in the cluster, mount the file system you created in Section 2.1, "Configuring an LVM Volume with an ext4 File System" , create the file index.html on that file system, then unmount the file system.

Commands:
yum install -y httpd wget
<Location /server-status> SetHandler server-status Require local </Location>
/bin/systemctl reload httpd.service > /dev/null 2>/dev/null || true
/usr/bin/test -f /run/httpd.pid >/dev/null 2>/dev/null && /usr/bin/ps -q USD(/usr/bin/cat /run/httpd.pid) >/dev/null 2>/dev/null && /usr/sbin/httpd -f /etc/httpd/conf/httpd.conf -c "PidFile /run/httpd.pid" -k graceful > /dev/null 2>/dev/null || true
mount /dev/my_vg/my_lv /var/www/ mkdir /var/www/html mkdir /var/www/cgi-bin mkdir /var/www/error restorecon -R /var/www cat <<-END >/var/www/html/index.html <html> <body>Hello</body> </html> END umount /var/www
A.9. Enabling Intel VT-x and AMD-V Virtualization Hardware Extensions in BIOS Note To expand your expertise, you might also be interested in the Red Hat Virtualization (RH318) training course. This section describes how to identify hardware virtualization extensions and enable them in your BIOS if they are disabled. The Intel VT-x extensions can be disabled in the BIOS. Certain laptop vendors have disabled the Intel VT-x extensions by default in their CPUs. The virtualization extensions cannot be disabled in the BIOS for AMD-V. See the following section for instructions on enabling disabled virtualization extensions. Verify the virtualization extensions are enabled in BIOS. The BIOS settings for Intel VT or AMD-V are usually in the Chipset or Processor menus. The menu names may vary from this guide, the virtualization extension settings may be found in Security Settings or other non standard menu names. Procedure A.3. Enabling virtualization extensions in BIOS Reboot the computer and open the system's BIOS menu. This can usually be done by pressing the delete key, the F1 key or Alt and F4 keys depending on the system. Enabling the virtualization extensions in BIOS Note Many of the steps below may vary depending on your motherboard, processor type, chipset and OEM. See your system's accompanying documentation for the correct information on configuring your system. Open the Processor submenu The processor settings menu may be hidden in the Chipset , Advanced CPU Configuration or Northbridge . Enable Intel Virtualization Technology (also known as Intel VT-x). AMD-V extensions cannot be disabled in the BIOS and should already be enabled. The virtualization extensions may be labeled Virtualization Extensions , Vanderpool or various other names depending on the OEM and system BIOS. Enable Intel VT-d or AMD IOMMU, if the options are available. Intel VT-d and AMD IOMMU are used for PCI device assignment. Select Save & Exit . Reboot the machine. When the machine has booted, run grep -E "vmx|svm" /proc/cpuinfo . Specifying --color is optional, but useful if you want the search term highlighted. If the command outputs, the virtualization extensions are now enabled. If there is no output your system may not have the virtualization extensions or the correct BIOS setting enabled.

Commands:
5.11.3. Creating a User With a Specific MLS Range Follow these steps to create a new Linux user with a specific MLS range: Add a new Linux user via the useradd command and map the new Linux user to an existing SELinux user (in this case, user_u ): Assign the newly-created Linux user a password: Run the semanage login -l command to view the mapping between SELinux and Linux users. The output should be as follows: Define a specific range for user john : Run the semanage login -l command to view the mapping between SELinux and Linux users. Note that the user john now has a specific MLS range defined: To correct the label on john's home directory (if needed), run the following command:

Commands:
~]# useradd -Z user_u john
~]# passwd john
Login Name SELinux User MLS/MCS Range __default__ user_u s0 john user_u s0 root root s0-s15:c0.c1023 system_u system_u s0-s15:c0.c1023
~]# semanage login --modify --seuser user_u --range s2:c100 john
Login Name SELinux User MLS/MCS Range __default__ user_u s0 john user_u s2:c100 root root s0-s15:c0.c1023 system_u system_u s0-s15:c0.c1023
~]# chcon -R -l s2:c100 /home/john
Chapter 5. Managing Ceph daemons As a storage administrator, you can manage Ceph daemons on the Red Hat Ceph Storage dashboard. 5.1. Daemon actions The Red Hat Ceph Storage dashboard allows you to start, stop, restart, and redeploy daemons. Note These actions are supported on all daemons except monitor and manager daemons. Prerequisites Before you begin, make sure that you have the following prerequisites in place: A running Red Hat Ceph Storage cluster. Dashboard is installed. At least one daemon is configured in the storage cluster. Procedure You can manage daemons two ways. From the Services page: From the dashboard navigation, go to Administration->Services . Expand the service with the daemon that will have the action run on. Note The row can be collapsed at any time. On the Daemons tab, select the row with the daemon. Note The Daemons table can be searched and filtered. Select the action that needs to be run on the daemon. The options are Start , Stop , Restart , and Redeploy . Figure 5.1. Managing daemons from Services From the Hosts page: From the dashboard navigation, go to Cluster->Hosts . On the Hosts List tab, expand the host row and select the host with the daemon to perform the action on. On the Daemons tab of the host, select the row with the daemon. Note The Daemons table can be searched and filtered. Select the action that needs to be run on the daemon. The options are Start , Stop , Restart , and Redeploy . Figure 5.2. Managing daemons from Hosts

Commands: