mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 1. Installation FCoE Support in the Kickstart File When using a kickstart file to install Red Hat Enterprise Linux 6.4, with the new fcoe kickstart option you can specify which Fibre Channel over Ethernet (FCoE) devices should be activated automatically in addition to those discovered by Enhanced Disk Drive (EDD) services. For more information, refer to the Kickstart Options section in the Red Hat Enterprise Linux 6 Installation Guide . Installation over VLAN In Red Hat Enterprise Linux 6.4, the vlanid= boot option and the --vlanid= kickstart option allow you to set a virtual LAN ID (802.1q tag) for a specified network device. By specifying either one of these options, installation of the system can be done over a VLAN. Configuring Bonding The bond boot option and the --bondslaves and --bondopts kickstart options can now be used to configure bonding as a part of the installation process. For more information on how to configure bonding, refer to the following parts of the Red Hat Enterprise Linux 6 Installation Guide : section Kickstart Options and chapter Boot Options .

Commands:
5.2. Removing a Cluster from the luci Interface You can remove a cluster from the luci management GUI without affecting the cluster services or cluster membership. If you remove a cluster, you can later add the cluster back, or you can add it to another luci instance, as described in Section 5.1, "Adding an Existing Cluster to the luci Interface" . To remove a cluster from the luci management GUI without affecting the cluster services or cluster membership, follow these steps: Click Manage Clusters from the menu on the left side of the luci Homebase page. The Clusters screen appears. Select the cluster or clusters you wish to remove. Click Remove . The system will ask you to confirm whether to remove the cluster from the luci management GUI. For information on deleting a cluster entirely, stopping all cluster services removing the cluster configuration information from the nodes themselves, see Section 5.4, "Starting, Stopping, Restarting, and Deleting Clusters" .

Commands:
7.5. Set an IP Address to Run Red Hat JBoss Data Grid For production use, the Red Hat JBoss Data Grid server must be bound to a specified IP address rather than to 127.0.0.1/localhost . Use the -b parameter with the script to specify an IP address. For standalone mode, set the IP address as follows: For clustered mode, set the IP address as follows: Report a bug

Commands:
USDJDG_HOME/bin/standalone.sh -b USD{IP_ADDRESS}
USDJDG_HOME/bin/clustered.sh -b USD{IP_ADDRESS}
5.168. libxml2 5.168.1. RHSA-2012:1512 - Important: libxml2 security update Updated libxml2 packages that fix one security issue are now available for Red Hat Enterprise Linux 5 and 6. The Red Hat Security Response Team has rated this update as having important security impact. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available from the CVE link(s) associated with each description below. The libxml2 library is a development toolbox providing the implementation of various XML standards. Security Fix CVE-2012-5134 A heap-based buffer underflow flaw was found in the way libxml2 decoded certain entities. A remote attacker could provide a specially-crafted XML file that, when opened in an application linked against libxml2, would cause the application to crash or, potentially, execute arbitrary code with the privileges of the user running the application. All users of libxml2 are advised to upgrade to these updated packages, which contain a backported patch to correct this issue. The desktop must be restarted (log out, then log back in) for this update to take effect. 5.168.2. RHSA-2012:1288 - Moderate: libxml2 security update Updated libxml2 packages that fix multiple security issues are now available for Red Hat Enterprise Linux 5 and 6. The Red Hat Security Response Team has rated this update as having moderate security impact. Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) associated with each description below. The libxml2 library is a development toolbox providing the implementation of various XML standards. Security Fixes CVE-2012-2807 Multiple integer overflow flaws, leading to heap-based buffer overflows, were found in the way libxml2 handled documents that enable entity expansion. A remote attacker could provide a large, specially-crafted XML file that, when opened in an application linked against libxml2, would cause the application to crash or, potentially, execute arbitrary code with the privileges of the user running the application. CVE-2011-3102 A one byte buffer overflow was found in the way libxml2 evaluated certain parts of XML Pointer Language (XPointer) expressions. A remote attacker could provide a specially-crafted XML file that, when opened in an application linked against libxml2, would cause the application to crash or, potentially, execute arbitrary code with the privileges of the user running the application. All users of libxml2 are advised to upgrade to these updated packages, which contain backported patches to correct these issues. The desktop must be restarted (log out, then log back in) for this update to take effect.

Commands:
2.2. Fencing Overview In a cluster system, there can be many nodes working on several pieces of vital production data. Nodes in a busy, multi-node cluster could begin to act erratically or become unavailable, prompting action by administrators. The problems caused by errant cluster nodes can be mitigated by establishing a fencing policy. Fencing is the disconnection of a node from the cluster's shared storage. Fencing cuts off I/O from shared storage, thus ensuring data integrity. The cluster infrastructure performs fencing through the STONITH facility. When Pacemaker determines that a node has failed, it communicates to other cluster-infrastructure components that the node has failed. STONITH fences the failed node when notified of the failure. Other cluster-infrastructure components determine what actions to take, which includes performing any recovery that needs to done. For example, DLM and GFS2, when notified of a node failure, suspend activity until they detect that STONITH has completed fencing the failed node. Upon confirmation that the failed node is fenced, DLM and GFS2 perform recovery. DLM releases locks of the failed node; GFS2 recovers the journal of the failed node. Node-level fencing through STONITH can be configured with a variety of supported fence devices, including: Uninterruptible Power Supply (UPS) - a device containing a battery that can be used to fence devices in event of a power failure Power Distribution Unit (PDU) - a device with multiple power outlets used in data centers for clean power distribution as well as fencing and power isolation services Blade power control devices - dedicated systems installed in a data center configured to fence cluster nodes in the event of failure Lights-out devices - Network-connected devices that manage cluster node availability and can perform fencing, power on/off, and other services by administrators locally or remotely

Commands:
Chapter 5. Networking Operators overview OpenShift Container Platform supports multiple types of networking Operators. You can manage the cluster networking using these networking Operators. 5.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) network plugin selected for the cluster during installation. For more information, see Cluster Network Operator in OpenShift Container Platform . 5.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 . 5.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 . 5.4. External DNS Operator The External DNS Operator deploys and manages ExternalDNS to provide the name resolution for services and routes from the external DNS provider to OpenShift Container Platform. For more information, see Understanding the External DNS Operator . 5.5. Ingress Node Firewall Operator The Ingress Node Firewall Operator uses an extended Berkley Packet Filter (eBPF) and eXpress Data Path (XDP) plugin to process node firewall rules, update statistics and generate events for dropped traffic. The operator manages ingress node firewall resources, verifies firewall configuration, does not allow incorrectly configured rules that can prevent cluster access, and loads ingress node firewall XDP programs to the selected interfaces in the rule's object(s). For more information, see Understanding the Ingress Node Firewall Operator 5.6. Network Observability Operator The Network Observability Operator is an optional Operator that allows cluster administrators to observe the network traffic for OpenShift Container Platform clusters. The Network Observability Operator uses the eBPF technology to create network flows. The network flows are then enriched with OpenShift Container Platform information and stored in Loki. You can view and analyze the stored network flows information in the OpenShift Container Platform console for further insight and troubleshooting. For more information, see About Network Observability Operator .

Commands:
10.9. Change the Default JDBC Port Using Management Console Login to the Management Console. Navigate to the Socket Binding panel in the Management Console Standalone Mode Select the Profile tab from the top-right of the console. Domain Mode Select the Profiles tab from the top-right of the console. Select the appropriate profile from the drop-down box in the top left. Expand the Subsystems menu on the left of the console. Select General Configuration Socket Binding from the menu on the left of the console. Modify the port number Select the teiid-jdbc configuration. Select the Edit button. Set the Port to the new port number. Select Save .

Commands:
Chapter 16. Impersonating the system:admin user 16.1. API impersonation You can configure a request to the OpenShift Container Platform API to act as though it originated from another user. For more information, see User impersonation in the Kubernetes documentation. 16.2. Impersonating the system:admin user You can grant a user permission to impersonate system:admin , which grants them cluster administrator permissions. Procedure To grant a user permission to impersonate system:admin , run the following command: USD oc create clusterrolebinding <any_valid_name> --clusterrole=sudoer --user=<username> Tip You can alternatively apply the following YAML to grant permission to impersonate system:admin : apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: <any_valid_name> roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: sudoer subjects: - apiGroup: rbac.authorization.k8s.io kind: User name: <username> 16.3. Impersonating the system:admin group When a system:admin user is granted cluster administration permissions through a group, you must include the --as=<user> --as-group=<group1> --as-group=<group2> parameters in the command to impersonate the associated groups. Procedure To grant a user permission to impersonate a system:admin by impersonating the associated cluster administration groups, run the following command: USD oc create clusterrolebinding <any_valid_name> --clusterrole=sudoer --as=<user> \ --as-group=<group1> --as-group=<group2>

Commands:
oc create clusterrolebinding <any_valid_name> --clusterrole=sudoer --user=<username>
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: <any_valid_name> roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: sudoer subjects: - apiGroup: rbac.authorization.k8s.io kind: User name: <username>
oc create clusterrolebinding <any_valid_name> --clusterrole=sudoer --as=<user> --as-group=<group1> --as-group=<group2>
9.2. Keepalived and HAProxy Replace Piranha as Load Balancer Red Hat Enterprise Linux 7 replaces the Piranha Load Balancer technology with Keepalived and HAProxy . Keepalived provides simple and robust facilities for load balancing and high availability. The load-balancing framework relies on the well-known and widely used Linux Virtual Server kernel module providing Layer-4 (transport layer) load balancing. Keepalived implements a set of checkers to dynamically and adaptively maintain and manage a load balanced server pool according to their health. Keepalived also implements the Virtual Router Redundancy Protocol (VRRPv2) to achieve high availability with director failover. HAProxy is a TCP/HTTP reverse proxy which is particularly suited for high availability environments. HAProxy can: route HTTP requests depending on statically assigned cookies; spread the load among several servers while assuring server persistence through the use of HTTP cookies; switch to backup servers in the event a main server fails; accept connections to special ports dedicated to service monitoring; stop accepting connections without breaking existing ones; add, modify, and delete HTTP headers in both directions; block requests matching particular patterns; persist client connections to the correct application server depending on application cookies; report detailed status as HTML pages to authenticated users from a URI intercepted from the application. With Red Hat Enterprise Linux 7, the Load Balancer technology is now included in the base operating system and is no longer a Red Hat Enterprise Linux Add-On.

Commands:
Chapter 6. Back-end compression Compress an edge cluster of a smaller capacity with the compression options. BlueStore allows two types of compression: BlueStore level of compression for general workload. Ceph Object Gateway level of compression for S3 workload. For more information on compression algorithms, see Pool values . You need to enable compression and ensure that no crashes occur on the cluster upon enabling compression on pools. You can enable compression on the pools of the edge cluster in the following ways: Enable supported compression algorithms such as snappy, zlib, and zstd and enable supported compression modes such as None , passive , aggressive , and force with the following commands: Syntax Enable various compression ratios with the following commands: Syntax Create three pools and enable different compressions on those pools to ensure that no IO stoppage occurs on the pools. Create a fourth pool without any compression created on the pools. Write the same amount of data as pools with compression. The pool with compression uses less RAW space that the pool without compression. To verify these algorithms are set, use ceph osd pool get POOL_NAME OPTION_NAME command. To unset these algorithms, use ceph osd pool unset POOL_NAME OPTION_NAME command with the appropriate options.

Commands:
ceph osd pool set POOL_NAME compression_algorithm ALGORITHM ceph osd pool set POOL_NAME compression_mode MODE
ceph osd pool set POOL_NAME compression_required_ratio RATIO ceph osd pool set POOL_NAME compression_min_blob_size SIZE ceph osd pool set POOL_NAME compression_max_blob_size SIZE
2.2.4. Securing NFS Important The version of NFS included in Red Hat Enterprise Linux 6, NFSv4, no longer requires the portmap service as outlined in Section 2.2.2, "Securing Portmap" . NFS traffic now utilizes TCP in all versions, rather than UDP, and requires it when using NFSv4. NFSv4 now includes Kerberos user and group authentication, as part of the RPCSEC_GSS kernel module. Information on portmap is still included, since Red Hat Enterprise Linux 6 supports NFSv2 and NFSv3, both of which utilize portmap . 2.2.4.1. Carefully Plan the Network NFSv2 and NFSv3 traditionally passed data insecurely. All versions of NFS now have the ability to authenticate (and optionally encrypt) ordinary file system operations using Kerberos. Under NFSv4 all operations can use Kerberos; under v2 or v3, file locking and mounting still do not use it. When using NFSv4.0, delegations may be turned off if the clients are behind NAT or a firewall. Refer to the section on pNFS in the Storage Administration Guide for information on the use of NFSv4.1 to allow delegations to operate through NAT and firewalls.

Commands:
Chapter 8. Removing Service Telemetry Framework from the Red Hat OpenShift Container Platform environment Remove Service Telemetry Framework (STF) from an Red Hat OpenShift Container Platform environment if you no longer require the STF functionality. To remove STF from the Red Hat OpenShift Container Platform environment, you must perform the following tasks: Delete the namespace. Remove the cert-manager Operator. Remove the Cluster Observability Operator. 8.1. Deleting the namespace To remove the operational resources for STF from Red Hat OpenShift Container Platform, delete the namespace. Procedure Run the oc delete command: USD oc delete project service-telemetry Verify that the resources have been deleted from the namespace: USD oc get all No resources found. 8.2. Removing the cert-manager Operator for Red Hat OpenShift If you are not using the cert-manager Operator for Red Hat OpenShift for any other applications, delete the Subscription, ClusterServiceVersion, and CustomResourceDefinitions. For more information about removing the cert-manager for Red Hat OpenShift Operator, see Removing cert-manager Operator for Red Hat OpenShift in the OpenShift Container Platform Documentation . Additional resources Deleting Operators from a cluster . 8.3. Removing the Cluster Observability Operator If you are not using the Cluster Observability Operator for any other applications, delete the Subscription, ClusterServiceVersion, and CustomResourceDefinitions. For more information about removing the Cluster Observability Operator, see Deleting Operators from a cluster using the web console in the OpenShift Container Platform Documentation . Additional resources Deleting Operators from a cluster .

Commands:
oc delete project service-telemetry
oc get all No resources found.
5.2.10. /proc/filesystems This file displays a list of the file system types currently supported by the kernel. Sample output from a generic /proc/filesystems file looks similar to the following: The first column signifies whether the file system is mounted on a block device. Those beginning with nodev are not mounted on a device. The second column lists the names of the file systems supported. The mount command cycles through the file systems listed here when one is not specified as an argument.

Commands:
nodev sysfs nodev rootfs nodev bdev nodev proc nodev sockfs nodev binfmt_misc nodev usbfs nodev usbdevfs nodev futexfs nodev tmpfs nodev pipefs nodev eventpollfs nodev devpts ext2 nodev ramfs nodev hugetlbfs iso9660 nodev mqueue ext3 nodev rpc_pipefs nodev autofs
15.4. RemoteCacheStore Parameters for Rolling Upgrades 15.4.1. rawValues and RemoteCacheStore By default, the RemoteCacheStore store's values are wrapped in InternalCacheEntry. Enabling the rawValues parameter causes the raw values to be stored instead for interoperability with direct access by RemoteCacheManagers. rawValues must be enabled in order to interact with a Hot Rod cache via both RemoteCacheStore and RemoteCacheManager. Report a bug 15.4.2. hotRodWrapping The hotRodWrapping parameter is a shortcut that enables rawValues and sets an appropriate marshaller and entry wrapper for performing Rolling Upgrades. Report a bug

Commands:
5.6.3. User Accounts Because FTP passes unencrypted usernames and passwords over insecure networks for authentication, it is a good idea to deny system users access to the server from their user accounts. To disable user accounts in vsftpd , add the following directive to /etc/vsftpd/vsftpd.conf : 5.6.3.1. Restricting User Accounts The easiest way to disable a specific group of accounts, such as the root user and those with sudo privileges, from accessing an FTP server is to use a PAM list file as described in Section 4.4.1, "Allowing Root Access" . The PAM configuration file for vsftpd is /etc/pam.d/vsftpd . It is also possible to disable user accounts within each service directly. To disable specific user accounts in vsftpd , add the username to /etc/vsftpd.ftpusers .

Commands:
local_enable=NO
Chapter 4. Integrated applications Cryostat integrates with specific applications that can enhance how you analyze data from your JFR recording. 4.1. Viewing a JFR recording on Grafana Cryostat 3.0 integrates with the Grafana application, so you can plot JFR recording data in Grafana. You can view plot data in time interval sections to precisely analyze the performance of your target JVM application. Prerequisites Entered your authentication details for your Cryostat instance. Created a JFR recording. See Creating a JFR recording in the Cryostat web console . Procedure Go to the Recordings menu or the Archives menu on your Cryostat instance. Depending on your needs, click either the Active Recordings tab or the Archived Recordings tab. Locate your JFR recording and then select the overflow menu. Figure 4.1. Overflow menu items available for an example JFR recording From the overflow menu, click the View in Grafana option. The Grafana application opens in a new web browser window. Enter your Red Hat OpenShift credentials in the Grafana web console login page, if prompted. A dashboard window opens and shows your JFR recording's data in various time-series plots. Optional: Interact with any plot by selecting a time-series segment on the plot. Grafana expands the on-screen data to show only the data for that time interval. Figure 4.2. Example of a Grafana dashboard with plotted graphs Revised on 2024-07-02 13:35:46 UTC

Commands:
3.3. Creating Control Groups Use the cgcreate command to create transient cgroups in hierarchies you created yourself. The syntax for cgcreate is: where: -t (optional) - specifies a user (by user ID, uid) and a group (by group ID, gid) to own the tasks pseudo-file for this cgroup. This user can add tasks to the cgroup. Note Note that the only way to remove a process from a cgroup is to move it to a different cgroup. To be able to move a process, the user has to have write access to the destination cgroup; write access to the source cgroup is not necessary. -a (optional) - specifies a user (by user ID, uid) and a group (by group ID, gid) to own all pseudo-files other than tasks for this cgroup. This user can modify the access to system resources for tasks in this cgroup. -g - specifies the hierarchy in which the cgroup should be created, as a comma-separated list of the controllers associated with hierarchies. The list of controllers is followed by a colon and the path to the child group relative to the hierarchy. Do not include the hierarchy mount point in the path. Because all cgroups in the same hierarchy have the same controllers, the child group has the same controllers as its parent. As an alternative, you can create a child of the cgroup directly. To do so, use the mkdir command: For example:

Commands:
cgcreate -t uid : gid -a uid : gid -g controllers : path
~]# mkdir /sys/fs/cgroup/ controller / name / child_name
~]# mkdir /sys/fs/cgroup/net_prio/lab1/group1