mtpti5iD/redhat-docs_dataset huggingface dataset:
4.6. Configuring Fence Devices Configuring fence devices consists of creating, updating, and deleting fence devices for the cluster. You must configure the fence devices in a cluster before you can configure fencing for the nodes in the cluster. Creating a fence device consists of selecting a fence device type and entering parameters for that fence device (for example, name, IP address, login, and password). Updating a fence device consists of selecting an existing fence device and changing parameters for that fence device. Deleting a fence device consists of selecting an existing fence device and deleting it. Note It is recommended that you configure multiple fencing mechanisms for each node. A fencing device can fail due to network split, a power outage, or a problem in the fencing device itself. Configuring multiple fencing mechanisms can reduce the likelihood that the failure of a fencing device will have fatal results. This section provides procedures for the following tasks: Creating fence devices - Refer to Section 4.6.1, "Creating a Fence Device" . Once you have created and named a fence device, you can configure the fence devices for each node in the cluster, as described in Section 4.7, "Configuring Fencing for Cluster Members" . Updating fence devices - Refer to Section 4.6.2, "Modifying a Fence Device" . Deleting fence devices - Refer to Section 4.6.3, "Deleting a Fence Device" . From the cluster-specific page, you can configure fence devices for that cluster by clicking on Fence Devices along the top of the cluster display. This displays the fence devices for the cluster and displays the menu items for fence device configuration: Add and Delete . This is the starting point of each procedure described in the following sections. Note If this is an initial cluster configuration, no fence devices have been created, and therefore none are displayed. Figure 4.6, "luci fence devices configuration page" shows the fence devices configuration screen before any fence devices have been created. Figure 4.6. luci fence devices configuration page 4.6.1. Creating a Fence Device To create a fence device, follow these steps: From the Fence Devices configuration page, click Add . Clicking Add displays the Add Fence Device (Instance) dialog box. From this dialog box, select the type of fence device to configure. Specify the information in the Add Fence Device (Instance) dialog box according to the type of fence device. Refer to Appendix A, Fence Device Parameters for more information about fence device parameters. In some cases you will need to specify additional node-specific parameters for the fence device when you configure fencing for the individual nodes, as described in Section 4.7, "Configuring Fencing for Cluster Members" . Click Submit . After the fence device has been added, it appears on the Fence Devices configuration page.

Commands:
10.4. Using KVM virtio Drivers for Existing Devices You can modify an existing hard disk device attached to the guest to use the virtio driver instead of the virtualized IDE driver. The example shown in this section edits libvirt configuration files. Note that the guest virtual machine does not need to be shut down to perform these steps, however the change will not be applied until the guest is completely shut down and rebooted. Procedure 10.4. Using KVM virtio drivers for existing devices Ensure that you have installed the appropriate driver ( viostor ), as described in Section 10.1, "Installing the KVM Windows virtio Drivers" , before continuing with this procedure. Run the virsh edit <guestname> command as root to edit the XML configuration file for your device. For example, virsh edit guest1 . The configuration files are located in /etc/libvirt/qemu . Below is a file-based block device using the virtualized IDE driver. This is a typical entry for a virtual machine not using the virtio drivers. Change the entry to use the virtio device by modifying the bus= entry to virtio . Note that if the disk was previously IDE it will have a target similar to hda, hdb, or hdc and so on. When changing to bus=virtio the target needs to be changed to vda, vdb, or vdc accordingly. Remove the address tag inside the disk tags. This must be done for this procedure to work. Libvirt will regenerate the address tag appropriately the time the virtual machine is started. Alternatively, virt-manager , virsh attach-disk or virsh attach-interface can add a new device using the virtio drivers. Refer to the libvirt website for more details on using Virtio: http://www.linux-kvm.org/page/Virtio

Commands:
<disk type='file' device='disk'> <source file='/var/lib/libvirt/images/disk1.img'/> <target dev='hda' bus='ide'/> </disk>
<disk type='file' device='disk'> <source file='/var/lib/libvirt/images/disk1.img'/> <target dev='vda' bus='virtio'/> </disk>
Getting Started with Streams for Apache Kafka on OpenShift Red Hat Streams for Apache Kafka 2.7 Get started using Streams for Apache Kafka 2.7 on OpenShift Container Platform

Commands:
apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka metadata: name: my-cluster namespace: amq-streams-kafka spec: kafka: # listeners: # - name: listener1 port: 9094 type: route tls: true
get routes my-cluster-kafka-listener1-bootstrap -o=jsonpath='{.status.ingress[0].host}{"\n"}'
extract secret/my-cluster-cluster-ca-cert --keys=ca.crt --to=- > ca.crt
keytool -keystore client.truststore.jks -alias CARoot -import -file ca.crt
run kafka-producer -ti --image=registry.redhat.io/amq-streams/kafka-37-rhel9:2.7.0 --rm=true --restart=Never -- bin/kafka-console-producer.sh --bootstrap-server my-cluster-kafka-bootstrap:9092 --topic my-topic
run kafka-consumer -ti --image=registry.redhat.io/amq-streams/kafka-37-rhel9:2.7.0 --rm=true --restart=Never -- bin/kafka-console-consumer.sh --bootstrap-server my-cluster-kafka-bootstrap:9092 --topic my-topic --from-beginning
kafka-console-producer.sh --bootstrap-server my-cluster-kafka-listener1-bootstrap-amq-streams-kafka.apps.ci-ln-50kcyvt-72292.origin-ci-int-gce.dev.rhcloud.com:443 --producer-property security.protocol=SSL --producer-property ssl.truststore.password=password --producer-property ssl.truststore.location=client.truststore.jks --topic my-topic
kafka-console-consumer.sh --bootstrap-server my-cluster-kafka-listener1-bootstrap-amq-streams-kafka.apps.ci-ln-50kcyvt-72292.origin-ci-int-gce.dev.rhcloud.com:443 --consumer-property security.protocol=SSL --consumer-property ssl.truststore.password=password --consumer-property ssl.truststore.location=client.truststore.jks --topic my-topic --from-beginning
dnf install <package_name>
dnf install <path_to_download_package>
Chapter 4. Selecting a system-wide archive Red Hat build of OpenJDK version If you have multiple versions of Red Hat build of OpenJDK installed with the archive on RHEL, you can select a specific Red Hat build of OpenJDK version to use system-wide. Prerequisites Know the locations of the Red Hat build of OpenJDK versions installed using the archive. Procedure To specify the Red Hat build of OpenJDK version to use for a single session: Configure JAVA_HOME with the path to the Red Hat build of OpenJDK version you want used system-wide. USD export JAVA_HOME=/opt/jdk/openjdk-17.0.0.0.35 Add USDJAVA_HOME/bin to the PATH environment variable. USD export PATH="USDJAVA_HOME/bin:USDPATH" To specify the Red Hat build of OpenJDK version to use permanently for a single user, add these commands into ~/.bashrc : To specify the Red Hat build of OpenJDK version to use permanently for all users, add these commands into /etc/bashrc : Note If you do not want to redefine JAVA_HOME , add only the PATH command to bashrc , specifying the path to the Java binary. For example, export PATH="/opt/jdk/openjdk-17.0.0.0.35/bin:USDPATH" . Additional resources Be aware of the exact meaning of JAVA_HOME . For more information, see Changes/Decouple system java setting from java command setting .

Commands:
export JAVA_HOME=/opt/jdk/openjdk-17.0.0.0.35 export PATH="USDJAVA_HOME/bin:USDPATH"
export JAVA_HOME=/opt/jdk/openjdk-17.0.0.0.35 export PATH="USDJAVA_HOME/bin:USDPATH"
8.120. libselinux 8.120.1. RHBA-2014:1469 - libselinux bug fix update Updated libselinux packages that fix several bugs are now available for Red Hat Enterprise Linux 6. The libselinux packages contain the core library of an SELinux system. The libselinux library provides an API for SELinux applications to get and set process and file security contexts, and to obtain security policy decisions. It is required for any applications that use the SELinux API, and used by all applications that are SELinux-aware. Bug Fixes BZ# 753675 When attempting to run the virt-manager utility over SSH X11 forwarding, SELinux prevented the D-Bus system from performing actions even if SELinux was in permissive mode. As a consequence, such attempts failed and an AVC denial message was logged. With this update, a patch has been provided to fix this bug, and SELinux in permissive mode no longer blocks D-Bus in the described scenario. BZ# 1011109 Prior to this update, the selinux(8) manual page contained outdated information. This manual page has been updated, and SELinux is now documented correctly. BZ# 1025507 The Name Server Caching Daemon (nscd) uses SELinux permissions to check if a connecting user is allowed to query the cache. However, two permissions, NSCD__GETNETGRP and NSCD__SHMEMNETGRP, were missing from the SELinux list of permissions. Consequently, the netgroup caching worked only when SELinux was running in permissive mode. The missing permissions have been added to the list, and the netgroup caching now works as expected. BZ# 1091857 Previously, the matchpathcon utility did not handle non-existent files or directories properly; the "matchpathcon -V" command verified the files of directories instead of specifying that they did not exist. The underlying source code has been modified to fix this bug, and matchpathcon now correctly recognizes non-existent files or directories. As a result, an error message is returned when a file or directory do not exist. BZ# 1096816 It was not possible to add a new user inside a Docker container because SELinux in enforcing or permissive mode incorrectly blocked an attempt to modify the /etc/passwd file. With this update, when the /selinux/ or /sys/fs/selinux/ directories are mounted as read-only, the libselinux library acts as if SELinux is disabled. This behavior stops SELinux-aware applications from attempting to perform SELinux actions inside a container, and /etc/passwd can now be modified as expected. Users of libselinux are advised to upgrade to these updated packages, which fix these bugs.

Commands:
14.12.4. Listing Volume Information The vol-info --pool pool-or-uuid vol-name-or-key-or-path command lists basic information about the given storage volume --pool , where pool-or-uuid is the name or UUID of the storage pool the volume is in. vol-name-or-key-or-path is the name or key or path of the volume to return information for. The vol-list --pool pool-or-uuid --details lists all of volumes in the specified storage pool. This command requires --pool pool-or-uuid which is the name or UUID of the storage pool. The --details option instructs virsh to additionally display volume type and capacity related information where available.

Commands:
2.2. GRUB The GNU GRand Unified Boot loader (GRUB) is a program which enables the selection of the installed operating system or kernel to be loaded at system boot time. It also allows the user to pass arguments to the kernel. 2.2.1. GRUB and the x86 Boot Process This section discusses the specific role GRUB plays when booting an x86 system. For a look at the overall boot process, refer to Section 1.2, "A Detailed Look at the Boot Process" . GRUB loads itself into memory in the following stages: The Stage 1 or primary boot loader is read into memory by the BIOS from the MBR [4] . The primary boot loader exists on less than 512 bytes of disk space within the MBR and is capable of loading either the Stage 1.5 or Stage 2 boot loader. The Stage 1.5 boot loader is read into memory by the Stage 1 boot loader, if necessary. Some hardware requires an intermediate step to get to the Stage 2 boot loader. This is sometimes true when the /boot/ partition is above the 1024 cylinder head of the hard drive or when using LBA mode. The Stage 1.5 boot loader is found either on the /boot/ partition or on a small part of the MBR and the /boot/ partition. The Stage 2 or secondary boot loader is read into memory. The secondary boot loader displays the GRUB menu and command environment. This interface allows the user to select which kernel or operating system to boot, pass arguments to the kernel, or look at system parameters. The secondary boot loader reads the operating system or kernel as well as the contents of /boot/sysroot/ into memory. Once GRUB determines which operating system or kernel to start, it loads it into memory and transfers control of the machine to that operating system. The method used to boot Red Hat Enterprise Linux is called direct loading because the boot loader loads the operating system directly. There is no intermediary between the boot loader and the kernel. The boot process used by other operating systems may differ. For example, the Microsoft (R) Windows (R) operating system, as well as other operating systems, are loaded using chain loading . Under this method, the MBR points to the first sector of the partition holding the operating system, where it finds the files necessary to actually boot that operating system. GRUB supports both direct and chain loading boot methods, allowing it to boot almost any operating system. Warning During installation, Microsoft's DOS and Windows installation programs completely overwrite the MBR, destroying any existing boot loaders. If creating a dual-boot system, it is best to install the Microsoft operating system first. [4] For more on the system BIOS and the MBR, refer to Section 1.2.1, "The BIOS" .

Commands:
Chapter 1. Upgrading the Red Hat Developer Hub Operator If you use the Operator to deploy your Red Hat Developer Hub instance, then an administrator can use the OpenShift Container Platform web console to upgrade the Operator to a later version. OpenShift Container Platform is currently supported from version 4.14 to 4.17. See also the Red Hat Developer Hub Life Cycle . Prerequisites You are logged in as an administrator on the OpenShift Container Platform web console. You have installed the Red Hat Developer Hub Operator. You have configured the appropriate roles and permissions within your project to create or access an application. For more information, see the Red Hat OpenShift Container Platform documentation on Building applications . Procedure In the Administrator perspective of the OpenShift Container Platform web console, click Operators > Installed Operators . On the Installed Operators page, click Red Hat Developer Hub Operator . On the Red Hat Developer Hub Operator page, click the Subscription tab. From the Upgrade status field on the Subscription details page, click Upgrade available . Note If there is no upgrade available, the Upgrade status field value is Up to date . On the InstallPlan details page, click Preview InstallPlan > Approve . Verification The Upgrade status field value on the Subscription details page is Up to date . Additional resources Installing Red Hat Developer Hub on OpenShift Container Platform with the Operator . Installing from OperatorHub using the web console

Commands:
Chapter 26. Adding the IdM CA service to an IdM server in a deployment without a CA If you previously installed an Identity Management (IdM) domain without the certificate authority (CA) component, you can add the IdM CA service to the domain by using the ipa-ca-install command. Depending on your requirements, you can select one of the following options: Note For details on the supported CA configurations, see Planning your CA services . 26.1. Installing the first IdM CA as the root CA into an existing IdM domain If you previously installed Identity Management (IdM) without the certificate authority (CA) component, you can install the CA on an IdM server subsequently. Follow this procedure to install, on the idmserver server, an IdM CA that is not subordinate to any external root CA. Prerequisites You have root permissions on idmserver . The IdM server is installed on idmserver . Your IdM deployment has no CA installed. You know the IdM Directory Manager password. Procedure On idmserver , install the IdM Certificate Server CA: On each IdM host in the topology, run the ipa-certupdate utility to update the host with the information about the new certificate from the IdM LDAP. Important If you do not run ipa-certupdate after generating the IdM CA certificate, the certificate will not be distributed to the other IdM machines. 26.2. Installing the first IdM CA with an external CA as the root CA into an existing IdM domain If you previously installed Identity Management (IdM) without the certificate authority (CA) component, you can install the CA on an IdM server subsequently. Follow this procedure to install, on the idmserver server, an IdM CA that is subordinate to an external root CA, with zero or several intermediate CAs in between. Prerequisites You have root permissions on idmserver . The IdM server is installed on idmserver . Your IdM deployment has no CA installed. You know the IdM Directory Manager password. Procedure Start the installation: Wait till the command line informs you that a certificate signing request (CSR) has been saved. Submit the CSR to the external CA. Copy the issued certificate to the IdM server. Continue the installation by adding the certificates and full path to the external CA files to ipa-ca-install : On each IdM host in the topology, run the ipa-certupdate utility to update the host with the information about the new certificate from the IdM LDAP. Important Failing to run ipa-certupdate after generating the IdM CA certificate means that the certificate will not be distributed to the other IdM machines.

Commands:
[root@idmserver ~] ipa-ca-install
[root@idmserver ~] ipa-ca-install --external-ca
ipa-ca-install --external-cert-file=/root/master.crt --external-cert-file=/root/ca.crt
Chapter 12. Services and Daemons Maintaining security on your system is extremely important, and one approach for this task is to manage access to system services carefully. Your system may need to provide open access to particular services (for example, httpd if you are running a web server). However, if you do not need to provide a service, you should turn it off to minimize your exposure to possible bug exploits. This chapter explains the concept of runlevels, and describes how to set the default one. It also covers the setup of the services to be run in each of these runlevels, and provides information on how to start, stop, and restart the services on the command line using the service command. Important When you allow access for new services, always remember that both the firewall and SELinux need to be configured as well. One of the most common mistakes committed when configuring a new service is neglecting to implement the necessary firewall configuration and SELinux policies to allow access for it. For more information, see the Red Hat Enterprise Linux 6 Security Guide . 12.1. Configuring the Default Runlevel A runlevel is a state, or mode , defined by services that are meant to be run when this runlevel is selected. Seven numbered runlevels exist (indexed from 0 ): Table 12.1. Runlevels in Red Hat Enterprise Linux Runlevel Description 0 Used to halt the system. This runlevel is reserved and cannot be changed. 1 Used to run in a single-user mode. This runlevel is reserved and cannot be changed. 2 Not used by default. You are free to define it yourself. 3 Used to run in a full multi-user mode with a command-line user interface. 4 Not used by default. You are free to define it yourself. 5 Used to run in a full multi-user mode with a graphical user interface. 6 Used to reboot the system. This runlevel is reserved and cannot be changed. To check in which runlevel you are operating, type the following: The runlevel command displays and current runlevel. In this case it is number 5 , which means the system is running in a full multi-user mode with a graphical user interface. The default runlevel can be changed by modifying the /etc/inittab file, which contains a line near the end of the file similar to the following: To do so, edit this file as root and change the number on this line to the desired value. The change will take effect the time you reboot the system.

Commands:
~]USD runlevel N 5
id:5:initdefault:
4.7. Installing Extensions Once you have developed an extension to the JDBC translator, you must install it into the Red hat JBoss Data Virtualization server. The process of packaging or deploying the extended JDBC translators is exactly as any other translator. Since the RDBMS is accessible already through its JDBC driver, there is no need to develop a resource adapter for this source as JBoss EAP provides a wrapper JCA connector (DataSource) for any JDBC driver.

Commands:
14.3. DHCP Relay Agent The DHCP Relay Agent ( dhcrelay ) enables the relay of DHCP and BOOTP requests from a subnet with no DHCP server on it to one or more DHCP servers on other subnets. When a DHCP client requests information, the DHCP Relay Agent forwards the request to the list of DHCP servers specified when the DHCP Relay Agent is started. When a DHCP server returns a reply, the reply is broadcast or unicast on the network that sent the original request. The DHCP Relay Agent for IPv4 , dhcrelay , listens for DHCPv4 and BOOTP requests on all interfaces unless the interfaces are specified in /etc/sysconfig/dhcrelay with the INTERFACES directive. See Section 14.3.1, "Configure dhcrelay as a DHCPv4 and BOOTP relay agent" . The DHCP Relay Agent for IPv6 , dhcrelay6 , does not have this default behavior and interfaces to listen for DHCPv6 requests must be specified. See Section 14.3.2, "Configure dhcrelay as a DHCPv6 relay agent" . dhcrelay can either be run as a DHCPv4 and BOOTP relay agent (by default) or as a DHCPv6 relay agent (with -6 argument). To see the usage message, issue the command dhcrelay -h . 14.3.1. Configure dhcrelay as a DHCPv4 and BOOTP relay agent To run dhcrelay in DHCPv4 and BOOTP mode specify the servers to which the requests should be forwarded to. Copy and then edit the dhcrelay.service file as the root user: Edit the ExecStart option under section [Service] and add one or more server IPv4 addresses to the end of the line, for example: ExecStart=/usr/sbin/dhcrelay -d --no-pid 192.168.1.1 If you also want to specify interfaces where the DHCP Relay Agent listens for DHCP requests, add them to the ExecStart option with -i argument (otherwise it will listen on all interfaces), for example: ExecStart=/usr/sbin/dhcrelay -d --no-pid 192.168.1.1 -i em1 For other options see the dhcrelay(8) man page. To activate the changes made, as the root user, restart the service: 14.3.2. Configure dhcrelay as a DHCPv6 relay agent To run dhcrelay in DHCPv6 mode add the -6 argument and specify the " lower interface " (on which queries will be received from clients or from other relay agents) and the " upper interface " (to which queries from clients and other relay agents should be forwarded). Copy dhcrelay.service to dhcrelay6.service and edit it as the root user: Edit the ExecStart option under section [Service] add -6 argument and add the " lower interface " and " upper interface " interface, for example: ExecStart=/usr/sbin/dhcrelay -d --no-pid -6 -l em1 -u em2 For other options see the dhcrelay(8) man page. To activate the changes made, as the root user, restart the service:

Commands:
~]# cp /lib/systemd/system/dhcrelay.service /etc/systemd/system/ ~]# vi /etc/systemd/system/dhcrelay.service
~]# systemctl --system daemon-reload ~]# systemctl restart dhcrelay
~]# cp /lib/systemd/system/dhcrelay.service /etc/systemd/system/dhcrelay6.service ~]# vi /etc/systemd/system/dhcrelay6.service
~]# systemctl --system daemon-reload ~]# systemctl restart dhcrelay6