mtpti5iD/redhat-docs_dataset huggingface dataset:
5.3.2. Causing a Node to Leave or Join a Cluster You can use the luci server component of Conga to cause a node to leave an active cluster by stopping all cluster services on the node. You can also use the luci server component of Conga to cause a node that has left a cluster to rejoin the cluster. Causing a node to leave a cluster does not remove the cluster configuration information from that node, and the node still appears in the cluster node display with a status of Not a cluster member . For information on deleting the node entirely from the cluster configuration, see Section 5.3.4, "Deleting a Member from a Cluster" . To cause a node to leave a cluster, perform the following steps. This shuts down the cluster software in the node. Making a node leave a cluster prevents the node from automatically joining the cluster when it is rebooted. From the cluster-specific page, click on Nodes along the top of the cluster display. This displays the nodes that constitute the cluster. This is also the default page that appears when you click on the cluster name beneath Manage Clusters from the menu on the left side of the luci Homebase page. Select the node you want to leave the cluster by clicking the check box for that node. Select the Leave Cluster function from the menu at the top of the page. This causes a message to appear at the top of the page indicating that the node is being stopped. Refresh the page to see the updated status of the node. It is also possible to cause more than one node at a time to leave the cluster by selecting all of the nodes to leave the cluster before clicking on Leave Cluster . To cause a node to rejoin a cluster, select any nodes you want to have rejoin the cluster by clicking the check box for those nodes and selecting Join Cluster . This makes the selected nodes join the cluster, and allows the selected nodes to join the cluster when they are rebooted.

Commands:
Chapter 11. 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. 11.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. 11.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"] 11.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 21. Compiler and Tools LVM2 detection on FCoE storage and mounting of file systems specified in /etc/fstab on FCoE storage can fail The fcoe init scripts cannot determine what devices can be assigned through the FCoE storage fabric, and therefore whether the startup process needs to wait for device discovery. Consequently, logical volume (LVM2) detection on FCoE attached storage and mounting of file systems specified in /etc/fstab on FCoE storage can fail during system startup due to an incomplete FCoE device discovery. To work around this problem, use /dev/disk/by-path/fc-* symbolic links as the specified block special device in /etc/fstab along with the _netdev mount option. The fcoe init script waits longer for the specified devices to attach. Sometimes, Fibre Channel by-path symbolic links are not a suitable option, such as when using LVM2 or mounting by labels. You can, starting with version 1.0.28 of the fcoe-utils packages, use the MINIMUM_WAIT option in the /etc/fcoe/config file in such cases. The default value of MINIMUM_WAIT is 0. Set the value to the number of seconds you want the fcoe init script to delay allowing device discovery to complete. Using MINIMUM_WAIT adds time to the system boot process, but could be necessary to allow block devices to be present before LVM2 and file system mounting scripts are run. (BZ#980961)

Commands:
Chapter 4. Distribution selection Eclipse Temurin produces several distributions of Red Hat build of OpenJDK. Red Hat provides support for a subset of these distributions. All Eclipse Temurin distributions of Red Hat build of OpenJDK contain the JDK Flight Recorder (JFR) feature. This feature produces diagnostics and profiling data that can be consumed by other applications, such as JDK Mission Control (JMC). To help select a distribution that is right for your needs, see Platform Coverage for Red Hat Support of Eclipse Temurin (Red Hat Customer Portal) . Additional resources Temurin TM Supported Platforms (Adoptium) Eclipse Mission Control (Adoptium) Introduction to JDK Flight Recorder Red Hat build of OpenJDK Revised on 2024-10-29 14:17:38 UTC

Commands:
2.7. Hardware Considerations You should take the following hardware considerations into account when deploying a GFS2 file system. Use Higher-Quality Storage Options GFS2 can operate on cheaper shared-storage options, such as iSCSI or Fibre Channel over Ethernet (FCoE), but you will get better performance if you buy higher-quality storage with larger caching capacity. Red Hat performs most quality, sanity, and performance tests on SAN storage with Fibre Channel interconnect. As a general rule, it is always better to deploy something that has been tested first. Test Network Equipment Before Deploying Higher-quality, faster-network equipment makes cluster communications and GFS2 run faster with better reliability. However, you do not have to purchase the most expensive hardware. Some of the most expensive network switches have problems passing multicast packets, which are used for passing fcntl locks (flocks), whereas cheaper commodity network switches are sometimes faster and more reliable. It is a general best practice to try equipment before deploying it into full production.

Commands:
Chapter 2. Upgrading the Red Hat Developer Hub Helm Chart You can upgrade to a later version of Red Hat Developer Hub in OpenShift Container Platform by using either the web console or the CLI. OpenShift Container Platform web console In the Developer perspective, click Helm to open the Helm Releases tab. Click the overflow menu on the Helm release that you want to use and select Upgrade . On the Upgrade Helm Release page, select the version of Developer Hub that you want to upgrade to from the chart version drop-down list. Click Upgrade . Note It might take a few minutes to delete the resources in the older versions and to start the newer versions of the Developer Hub pods. Close all open Developer Hub web pages, and log in again to verify that the upgrade was successful. OpenShift Container Platform CLI Log in to the OpenShift Container Platform cluster as the cluster administrator and switch to the project or namespace in which Developer Hub was installed. oc login -u <user> -p <password> https://api.<HOSTNAME>:6443 oc project <your_namespace> For a new version of the Developer Hub Helm chart, run the following upgrade command: helm upgrade -i rhdh -f new-values.yml \ openshift-helm-charts/redhat-developer-hub --version 1.3.5 Note You can also provide extra values to the chart by creating a new-values.yml file on your workstation with values that override the attributes in the installed chart or by adding new attributes.

Commands:
login -u <user> -p <password> https://api.<HOSTNAME>:6443 project <your_namespace>
helm upgrade -i rhdh -f new-values.yml openshift-helm-charts/redhat-developer-hub --version 1.3.5
Chapter 10. Enabling authentication with enterprise credentials in GNOME If your workplace uses a system called Active Directory or IPA, and you have an account there, you can use that account to log into the GNOME desktop environment. Logging in using enterprise credentials provides centralized account management, streamlines access to work-related resources, and gives the convenience of Single Sign-On (SSO). 10.1. Configuring enterprise credentials in GNOME You can configure your system to use enterprise credentials using Settings. Procedure Open Settings . Click Online Accounts . Select Enterprise Login (Kerberos) . In the Principal field, enter your domain username in the username@domain.com format. Click Connect . Enter your enterprise password and click Continue . Depending on the configuration of your domain, you might be asked for the domain administrator credentials. 10.2. Adding enterprise users in GNOME You can add an enterprise user to GNOME using Settings. Prerequisites Administrative access. You have configured Enterprise credentials . Procedure Open Settings . Click Users . Select the Unlock button and enter your password. Click Add User . Choose Enterprise Login Enter the domain, username, and password for your Enterprise account. Click Add . Depending on the domain configuration, you might need to enter administrator credentials. 10.3. Logging in to GNOME with enterprise credentials If your network has an Active Directory or IPA domain available, and you have a domain account, you can log in to GNOME using your enterprise credentials. Procedure At the GNOME login prompt, type your domain username followed by an @ sign and then your domain name. 10.4. Additional resources For troubleshooting, see the realm man page on your system

Commands:
username@domain.com
Chapter 3. Filtering systems based on severity You can filter all your systems in a report based on the severity of the rules that failed. This enables you to triage your systems and remediate the most critical issues first. Prerequisites Login access to the Red Hat Hybrid Cloud Console. Procedure Navigate to Security > Compliance > Reports . Choose the Policy rule you want to view. Click the Name filter above your list of systems. Choose Failed rule severity . Click on Filter by failed rule to the right of Failed rule severity , and place a checkmark in the box to the left of High . The systems that remain are those deemed to be critical issues, and should be the first ones remediated.

Commands:
Chapter 4. HA Solution for NetWeaver or S/4 Based on ABAP Platform 1709 or older 4.1. Standalone Enqueue Server 1 (ENSA1) When using the old Standalone Enqueue Server (ENSA1), the ASCS instance has to fail over the cluster node where the active ERS instance is running and it must be ensured that the ERS instance is shut down and moved to the node where the ASCS instance was running when it was online. This is because the ASCS instance has to access the shared memory where the ERS instance maintains a copy of the enqueue lock table to continue to keep track of the enqueue locks of active transactions. ENSA1 is supported in pacemaker as a two-node cluster configuration, mainly because of the restriction that the ASCS instance must "follow" the ERS instance. 4.2. Supported Scenarios Supported Scenario Description Two node cluster For ENSA1 the ASCS instance must always move to the node where the ERS instance is running ABAP/Java Dual-Stack Supported by Master/Slave Resources in all RHEL 7.x releases 4.2.1. ABAP/Java Dual-Stack ABAP/JAVA Dual-Stack is supported using the Master/Slave methodology, that's supported in all RHEL 7.x minor releases. Please follow the configuration guide: Configure (A)SCS/ERS SAPInstance cluster resource . However, since SAP no longer recommends dual-stack setups where both ABAP and JAVA instances share the same SID, it would be better to consider doing a Dual-Stack Split , so that the ABAP and JAVA stack will use separate SIDs. With such a setup you then could use the Standalone approach for managing the ASCS/ERS instances for the ABAP stack and the SCS/ERS instances for the JAVA stack. You need to configure separate resource groups for each instance and set up appropriate constraints based on the separate SIDs for each part of the environment. Please follow configuration guide: Configuring SAP NetWeaver ASCS/ERS ENSA1 with Standalone Resources in RHEL 7.5+ and RHEL 8 . 4.3. Support Policies Please refer to Support Policies for RHEL High Availability Clusters - Management of SAP NetWeaver in a Cluster . 4.4. Configuration Guides On-Premise: Configuring HA clusters to manage SAP NetWeaver or SAP S/4HANA Application server instances using the RHEL HA Add-On AWS: Configure SAP NetWeaver ASCS/ERS ENSA1 on Amazon Web Services (AWS) Azure: Azure Virtual Machines high availability for SAP NetWeaver on Red Hat Enterprise Linux with GlusterFS Azure: Azure Virtual Machines high availability for SAP NetWeaver on Red Hat Enterprise Linux with Azure NetApp Files for SAP applications Azure: High availability for SAP NetWeaver on Azure VMs on Red Hat Enterprise Linux with NFS on Azure Files GCP: HA cluster configuration guide for SAP NetWeaver on RHEL

Commands:
Appendix C. Ceph Firewall Ports These are the general firewall ports used by various components in Red Hat Ceph Storage. Port Port type Components 6800-7300 TCP Ceph OSDs. 3300 TCP Ceph clients and Ceph daemons connecting to the Ceph Monitor daemon. This port is preferred over 6789. 6789 TCP Ceph clients and Ceph daemons connecting to the Ceph Monitor daemon. This port is considered if port 3300 fails.

Commands:
6.3.2. Let the Installer Prompt You for a Driver Update Begin the installation normally for whatever method you have chosen. If the installer cannot load drivers for a piece of hardware that is essential for the installation process (for example, if it cannot detect any network or storage controllers), it prompts you to insert a driver update disk: Figure 6.5. The no driver found dialog Select Use a driver disk and refer to Section 6.4, "Specifying the Location of a Driver Update Image File or a Driver Update Disk" .

Commands:
Reference Guide Red Hat Trusted Profile Analyzer 1 Additional reference information for Red Hat Trusted Profile Analyzer Red Hat Trusted Documentation Team

Commands:
syft IMAGE_PATH -o cyclonedx-json@1.5
syft registry:example.io/hello-world:latest -o cyclonedx-json@1.5
syft IMAGE_PATH -o spdx-json@2.3
syft registry:example.io/hello-world:latest -o spdx-json@2.3
syft dir: DIRECTORY_PATH -o cyclonedx-json@1.5 syft file: FILE_PATH -o cyclonedx-json@1.5
syft dir:. -o cyclonedx-json@1.5 syft file:/example-binary -o cyclonedx-json@1.5
syft dir: DIRECTORY_PATH -o spdx-json@2.3 syft file: FILE_PATH -o spdx-json@2.3
syft dir:. -o spdx-json@2.3 syft file:/example-binary -o spdx-json@2.3
5.5.2. Adding a Member to a Running DLM Cluster The procedure for adding a member to a running DLM cluster depends on whether the cluster contains only two nodes or more than two nodes. To add a member to a running DLM cluster, follow the steps in one of the following sections according to the number of nodes in the cluster: For clusters with only two nodes - Section 5.5.2.1, "Adding a Member to a Running DLM Cluster That Contains Only Two Nodes" For clusters with more than two nodes - Section 5.5.2.2, "Adding a Member to a Running DLM Cluster That Contains More Than Two Nodes" 5.5.2.1. Adding a Member to a Running DLM Cluster That Contains Only Two Nodes To add a member to an existing DLM cluster that is currently in operation, and contains only two nodes, follow these steps: 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. At system-config-cluster , in the Cluster Status Tool tab, disable each service listed under Services . Stop the cluster software on the two running nodes by running the following commands at each node in this order: service rgmanager stop , if the cluster is running high-availability services ( rgmanager ) service gfs stop , if you are using Red Hat GFS service clvmd stop , if CLVM has been used to create clustered volumes service fenced stop service cman stop service ccsd stop Start cluster software on all cluster nodes (including the added one) by running the following commands in this order: service ccsd start service cman start service fenced 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 ) Start system-config-cluster (refer to Section 5.2, "Starting the Cluster Configuration Tool " ). At 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:
5.2. Securing Portmap The portmap service is a dynamic port assignment daemon for RPC services such as NIS and NFS. It has weak authentication mechanisms and has the ability to assign a wide range of ports for the services it controls. For these reasons, it is difficult to secure. Note Securing portmap only affects NFSv2 and NFSv3 implementations, since NFSv4 no longer requires it. If you plan to implement a NFSv2 or NFSv3 server, then portmap is required, and the following section applies. If running RPC services, follow these basic rules. 5.2.1. Protect portmap With TCP Wrappers It is important to use TCP wrappers to limit which networks or hosts have access to the portmap service since it has no built-in form of authentication. Further, use only IP addresses when limiting access to the service. Avoid using hostnames, as they can be forged via DNS poisoning and other methods.

Commands:
5.4.10. Changing the Parameters of a Logical Volume Group To change the parameters of a logical volume, use the lvchange command. For a listing of the parameters you can change, see the lvchange (8) man page. You can use the lvchange command to activate and deactivate logical volumes. To activate and deactivate all the logical volumes in a volume group at the same time, use the vgchange command, as described in Section 5.3.8, "Changing the Parameters of a Volume Group" . The following command changes the permission on volume lvol1 in volume group vg00 to be read-only.

Commands:
lvchange -pr vg00/lvol1
5.3. Using KVM virtio Drivers for Network Interface Devices When network interfaces use KVM virtio drivers, KVM does not emulate networking hardware which removes processing overhead and can increase the guest performance. In Red Hat Enterprise Linux 7, virtio is used as the default network interface type. However, if this is configured differently on your system, you can use the following procedures: To attach a virtio network device to a guest, use the virsh attach-interface command with the model --virtio option. Alternatively, in the virt-manager interface, navigate to the guest's Virtual hardware details screen and click Add Hardware . In the Add New Virtual Hardware screen, select Network , and change Device model to virtio : To change the type of an existing interface to virtio , use the virsh edit command to edit the XML configuration of the intended guest, and change the model type attribute to virtio , for example as follows: <devices> <interface type='network'> <source network='default'/> <target dev='vnet1'/> <model type='virtio'/> <driver name='vhost' txmode='iothread' ioeventfd='on' event_idx='off'/> </interface> </devices> ... Alternatively, in the virt-manager interface, navigate to the guest's Virtual hardware details screen, select the NIC item, and change Device model to virtio : Note If the naming of network interfaces inside the guest is not consistent across reboots, ensure all interfaces presented to the guest are of the same device model, preferably virtio-net . For details, see the Red Hat Knowledgebase .

Commands:
<devices> <interface type='network'> <source network='default'/> <target dev='vnet1'/> <model type='virtio'/> <driver name='vhost' txmode='iothread' ioeventfd='on' event_idx='off'/> </interface> </devices>
Chapter 5. Overview of security practices The Security Practices tests also known as cloud/security confirm that the image follows a minimum set of standard security practices. They also confirm (but do not require at this time) that the latest Red Hat security updates are installed. The cloud/security test includes the following subtests: 5.1. Password configuration test The password configuration test checks that login authentication services are enabled on the HUT, and that the services are using the SHA512 encryption algorithm. The test ensures that the image uses the standard SHA512 encryption and decryption algorithm for optimal security. For RHEL 8 and 9, it uses the authselect utility. Success criteria The SHA-512 encryption algorithm is enabled for system authentication. The test fails for RHEL 8 and RHEL 9 if the NIS, SSSD, or winbind services are not configured because these services support the SHA-512 algorithm. 5.2. RPM freshness Confirms that all important and critical security errata released against Red Hat packages that are included in the image are installed. Red Hat encourages you to update and recertify their images whenever an errata is released. This test displays status (REVIEW) at runtime as it requires review at Red Hat to confirm success or failure. Success criteria All important and critical security errata released for installed Red Hat packages are current. Additional resources For more information on Red Hat security ratings, refer to Understanding Red Hat security ratings . 5.3. SELinux enforcing subtest Security-Enhanced Linux (SELinux) Enforcing subtest confirms that SELinux is enabled and running in enforcing mode on the image. SELinux adds Mandatory Access Control (MAC) to the Linux kernel, and is enabled by default in Red Hat Enterprise Linux. SELinux policy is administratively-defined, enforced system-wide, and is not set at user discretion. It reduces vulnerability to privilege escalation attacks and limits the damage made during the configuration. If a process becomes compromised, the attacker only has access to the normal functions of that process, and to files the process has been configured to have access to. Success criteria SELinux is configured and running in enforcing mode on the image. Additional resources For more information about SELinux, see: RHEL 9 : Using SElinux . RHEL 8 : Using SElinux .

Commands: