mtpti5iD/redhat-docs_dataset huggingface dataset:
3.5. Configuring Fence Devices Configuring fence devices consists of creating, modifying, and deleting fence devices. 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). Modifying 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 If you are creating a new cluster, you can create fence devices when you configure cluster nodes. Refer to Section 3.6, "Configuring Cluster Members" . With Conga you can create shared and non-shared fence devices. The following shared fence devices are available: APC Power Switch Brocade Fabric Switch Bull PAP Egenera SAN Controller GNBD IBM Blade Center McData SAN Switch QLogic SANbox2 SCSI Fencing Virtual Machine Fencing Vixel SAN Switch WTI Power Switch The following non-shared fence devices are available: Dell DRAC HP iLO IBM RSA II IPMI LAN RPS10 Serial Switch This section provides procedures for the following tasks: Creating shared fence devices - Refer to Section 3.5.1, "Creating a Shared Fence Device" . The procedures apply only to creating shared fence devices. You can create non-shared (and shared) fence devices while configuring nodes (refer to Section 3.6, "Configuring Cluster Members" ). Modifying or deleting fence devices - Refer to Section 3.5.2, "Modifying or Deleting a Fence Device" . The procedures apply to both shared and non-shared fence devices. The starting point of each procedure is at the cluster-specific page that you navigate to from Choose a cluster to administer displayed on the cluster tab. 3.5.1. Creating a Shared Fence Device To create a shared fence device, follow these steps: At the detailed menu for the cluster (below the clusters menu), click Shared Fence Devices . Clicking Shared Fence Devices causes the display of the fence devices for a cluster and causes the display of menu items for fence device configuration: Add a Fence Device and Configure a Fence Device . Note If this is an initial cluster configuration, no fence devices have been created, and therefore none are displayed. Click Add a Fence Device . Clicking Add a Fence Device causes the Add a Sharable Fence Device page to be displayed (refer to Figure 3.1, "Fence Device Configuration" ). Figure 3.1. Fence Device Configuration At the Add a Sharable Fence Device page, click the drop-down box under Fencing Type and select the type of fence device to configure. Specify the information in the Fencing Type dialog box according to the type of fence device. Refer to Appendix B, Fence Device Parameters for more information about fence device parameters. Click Add this shared fence device . Clicking Add this shared fence device causes a progress page to be displayed temporarily. After the fence device has been added, the detailed cluster properties menu is updated with the fence device under Configure a Fence Device .

Commands:
Preface Red Hat build of OpenJDK (Open Java Development Kit) is a free and open source implementation of the Java Platform, Standard Edition (Java SE). The Red Hat build of OpenJDK is available in four versions: 8u, 11u, 17u, and 21u. Packages for the Red Hat build of OpenJDK are made available on Red Hat Enterprise Linux and Microsoft Windows and shipped as a JDK and JRE in the Red Hat Ecosystem Catalog.

Commands:
Chapter 1. Red Hat Decision Manager project packaging Red Hat Decision Manager projects contain the business assets that you develop in Red Hat Decision Manager. Each project in Red Hat Decision Manager is packaged as a Knowledge JAR (KJAR) file with configuration files such as a Maven project object model file ( pom.xml ), which contains build, environment, and other information about the project, and a KIE module descriptor file ( kmodule.xml ), which contains the KIE base and KIE session configurations for the assets in the project. You deploy the packaged KJAR file to a KIE Server that runs the decision services and other deployable assets (collectively referred to as services ) from that KJAR file. These services are consumed at run time through an instantiated KIE container, or deployment unit . Project KJAR files are stored in a Maven repository and identified by three values: GroupId , ArtifactId , and Version (GAV). The Version value must be unique for every new version that might need to be deployed. To identify an artifact (including a KJAR file), you need all three GAV values. Projects in Business Central are packaged automatically when you build and deploy the projects. For projects outside of Business Central, such as independent Maven projects or projects within a Java application, you must configure the KIE module descriptor settings in an appended kmodule.xml file or directly in your Java application in order to build and deploy the projects.

Commands:
10.5. Multi-Source Models: Planning and Execution The planner logically treats a multi-source table as if it were a view containing the union all of the respective source tables. More complex partitioning scenarios, such as heterogeneous sources or list partitioning will require the use of a Partitioned Union. Most of the federated optimizations available over unions are still applicable in multi-source mode. This includes aggregation pushdown/decomposition, limit pushdown, join partitioning, etc.

Commands:
3.9. Creating a Virtual Machine This Ruby example creates a virtual machine. This example uses a hash with symbols and nested hashes as their values. Another method, more verbose, is to use the constructors of the corresponding objects directly. See Creating a Virtual Machine Instance with Attributes for more information. # Get the reference to the "vms" service: vms_service = connection.system_service.vms_service # Use the "add" method to create a new virtual machine: vms_service.add( OvirtSDK4::Vm.new( name: 'myvm', cluster: { name: 'mycluster' }, template: { name: 'Blank' } ) ) After creating a virtual machine, it is recommended to poll the virtual machine's status , to ensure that all the disks have been created. For more information, see VmsService:add .

Commands:
Get the reference to the "vms" service: vms_service = connection.system_service.vms_service Use the "add" method to create a new virtual machine: vms_service.add( OvirtSDK4::Vm.new( name: 'myvm', cluster: { name: 'mycluster' }, template: { name: 'Blank' } ) )
Chapter 4. Supported configurations for running JBoss EAP in Microsoft Azure This section describes the supported configurations for running JBoss EAP in Microsoft Azure. 4.1. Supported virtual machine operating systems for using JBoss EAP The only virtual machine operating systems supported for using JBoss EAP in Microsoft Azure are: Red Hat Enterprise Linux 8 Red Hat Enterprise Linux 9 Microsoft Windows Server 2019 Microsoft Windows Server 2022 The Red Hat Cloud Access program allows you to use a JBoss EAP subscription to install JBoss EAP on your own Azure virtual machine or one of the above On-Demand operating systems from the Microsoft Azure Marketplace. Note that virtual machine operating system subscriptions are separate from a JBoss EAP subscription. Other than the above operating system restrictions, see the Customer Portal for further information on supported configurations for JBoss EAP , such as supported Java Development Kit (JDK) vendors and versions.

Commands:
8.247. yum-rhn-plugin 8.247.1. RHBA-2013:1086 - yum-rhn-plugin bug fix update Updated yum-rhn-plugin packages that fix one bug are now available. The yum-rhn-plugin package provides support for connecting to Red Hat Network (RHN). Systems registered with RHN are able to update and install packages from Red Hat Network. Bug Fix BZ#949649 The RHN Proxy did not work properly if separated from a parent by a slow enough network. Consequently, users who attempted to download larger repodata files and RPMs experienced timeouts. This update changes both RHN Proxy and Red Hat Enterprise Linux RHN Client to allow all communications to obey a configured timeout value for connections. Users of yum-rhn-plugin are advised to upgrade to these updated packages, which fix this bug. 8.247.2. RHBA-2013:1703 - yum-rhn-plugin bug fix update Updated yum-rhn-plugin packages that fix one bug are now available for Red Hat Enterprise Linux 6. The yum-rhn-plugin packages allow the Yum package manager to access content from Red Hat Network. Bug Fix BZ# 960524 , BZ# 988895 Prior to this update, an attempt to install an already-installed package led to an empty transaction that was incorrectly identified as an error. Consequently, the yum-rhn-plugin reported a failed installation action. With this update, yum-rhn-plugin has been modified to return a success code for empty transactions. As a result, a successful installation action is now reported when the package is already installed. Users of yum-rhn-plugin are advised to upgrade to these updated packages, which fix this bug.

Commands:
Chapter 2. Red Hat Enterprise Linux AI product architecture Red Hat Enterprise Linux AI contains various distinct features and consists of the following components. 2.1. Bootable Red Hat Enterprise Linux with InstructLab You can install RHEL AI and deploy the InstructLab tooling using a bootable RHEL container image provided by Red Hat. The current supported installation methods for this image are on Amazon Web Services (AWS), IBM Cloud, and bare-metal machines with NVIDIA GPUs. This RHEL AI image includes InstructLab, RHEL 9.4, and various inference and training software, including vLLM and DeepSpeed. After you boot this image, you can download various Red Hat and IBM developed Granite models to serve or train. The image and all the tools are compiled to specific Independent Software Vendor (ISV) hardware. For more information about the architecture of the image, see Installation overview Important RHEL AI currently only includes bootable images for NVIDIA accelerators. 2.1.1. InstructLab model alignment The Red Hat Enterprise Linux AI bootable image contains InstructLab and its tooling. InstructLab uses a novel approach to LLM fine-tuning called LAB (Large-Scale Alignment for ChatBots). The LAB method uses a taxonomy-based system that implements high-quality synthetic data generation (SDG) and multi-phase training. Using the RHEL AI command line interface (CLI), which is built from the InstructLab CLI, you can create your own custom LLM by tuning a Granite base model on synthetic data generated from your own domain-specific knowledge. For general availability, the RHEL AI LLMs customization workflow consists of the following steps: Installing and initializing RHEL AI on your preferred platform. Using a CLI and Git workflow for adding skills and knowledge to your taxonomy tree. Running synthetic data generation (SDG) using the mixtral-8x7B-Instruct teacher model. SDG can generate hundreds or thousands of synthetic question-and-answer pairs for model tuning based on user-provided specific samples. Using the InstructLab to train the base model with the new synthetically generated data. The prometheus-8x7B-V2.0 judge model evaluates the performance of the newly trained model. Using InstructLab with vLLM to serve the new custom model for inferencing. 2.1.2. Open source licensed Granite models With RHEL AI, you can download the open source licensed IBM Granite family of LLMs. Using the granite-7b-starter model as a base, you can create your model using knowledge data. You can keep these custom LLMs private or you can share them with the AI community. Red Hat Enterprise Linux AI also allows you to serve and chat with Granite models created and fine-tuned by Red Hat and IBM.

Commands:
Appendix C. Journaler configuration reference Reference of the list commands that can be used for journaler configuration. journaler_write_head_interval Description How frequently to update the journal head object. Type Integer Required No Default 15 journaler_prefetch_periods Description How many stripe periods to read ahead on journal replay. Type Integer Required No Default 10 journal_prezero_periods Description How many stripe periods to zero ahead of write position. Type Integer Required No Default 10 journaler_batch_interval Description Maximum additional latency in seconds to incur artificially. Type Double Required No Default .001 journaler_batch_max Description Maximum bytes that will be delayed flushing. Type 64-bit Unsigned Integer Required No Default 0

Commands:
Deploying and managing OpenShift Data Foundation using Google Cloud Red Hat OpenShift Data Foundation 4.13 Instructions on deploying and managing OpenShift Data Foundation on existing Red Hat OpenShift Container Platform Google Cloud clusters Red Hat Storage Documentation Team Abstract Read this document for instructions about how to install and manage Red Hat OpenShift Data Foundation using Red Hat OpenShift Container Platform on Google Cloud. Important Deploying and managing OpenShift Data Foundation on Google Cloud is a Technology Preview feature. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.

Commands:
Chapter 2. Trusted Artifact Signer's implementation of The Update Framework Starting with Red Hat Trusted Artifact Signer (RHTAS) version 1.1, we implemented The Update Framework (TUF) as a trust root to store public keys, and certificates used by RHTAS services. The Update Framework is a sophisticated framework for securing software update systems, and this makes it ideal for securing shipped artifacts. The Update Framework refers to the RHTAS services as trusted root targets. There are four trusted targets, one for each RHTAS service: Fulcio, Certificate Transparency (CT) log, Rekor, and Timestamp Authority (TSA). Client software, such as cosign , use the RHTAS trust root targets to sign and verify artifact signatures. A simple HTTP server distributes the public keys and certificates to the client software. This simple HTTP server has the TUF repository of the individual targets. When deploying the RHTAS operator in OpenShift, by default, we create a TUF repository, and prepopulate the individual targets. By default, the expiration date of all metadata files is 52 weeks from the time you deploy a Securesign instance. Red Hat recommends choosing shorter expiration periods, and rotating your public keys and certificates often. Doing these maintenance tasks regularly can help prevent attacks on your code base.

Commands:
Chapter 2. Using the Argo CD plugin You can use the Argo CD plugin to visualize the Continuous Delivery (CD) workflows in OpenShift GitOps. This plugin provides a visual overview of the application's status, deployment details, commit message, author of the commit, container image promoted to environment and deployment history. Prerequisites You have enabled the Argo CD plugin in Red Hat Developer Hub RHDH. Procedures Select the Catalog tab and choose the component that you want to use. Select the CD tab to view insights into deployments managed by Argo CD. Select an appropriate card to view the deployment details (for example, commit message, author name, and deployment history). Click the link icon ( ) to open the deployment details in Argo CD. Select the Overview tab and navigate to the Deployment summary section to review the summary of your application's deployment across namespaces. Additionally, select an appropriate Argo CD app to open the deployment details in Argo CD, or select a commit ID from the Revision column to review the changes in GitLab or GitHub. Additional resources For more information on installing dynamic plugins, see Installing and viewing dynamic plugins .

Commands:
Chapter 1. Observability and Service Mesh Red Hat OpenShift Observability provides real-time visibility, monitoring, and analysis of various system metrics, logs, and events to help you quickly diagnose and troubleshoot issues before they impact systems or applications. Red Hat OpenShift Observability connects open-source observability tools and technologies to create a unified Observability solution. The components of Red Hat OpenShift Observability work together to help you collect, store, deliver, analyze, and visualize data. Red Hat OpenShift Service Mesh integrates with the following Red Hat OpenShift Observability components: OpenShift Monitoring Red Hat OpenShift distributed tracing platform OpenShift Service Mesh also integrates with: Kiali provided by Red Hat, a powerful console for visualizing and managing your service mesh. OpenShift Service Mesh Console (OSSMC) plugin, an OpenShift Container Platform console plugin that seamlessly integrates Kiali console features into your OpenShift console.

Commands:
5.9.2.3. ISO 9660 In 1987, the International Organization for Standardization (known as ISO) released standard 9660. ISO 9660 defines how files are represented on CD-ROMs. Red Hat Enterprise Linux system administrators will likely see ISO 9660-formatted data in two places: CD-ROMs Files (usually referred to as ISO images ) containing complete ISO 9660 file systems, meant to be written to CD-R or CD-RW media The basic ISO 9660 standard is rather limited in functionality, especially when compared with more modern file systems. File names may be a maximum of eight characters long and an extension of no more than three characters is permitted. However, various extensions to the standard have become popular over the years, among them: Rock Ridge -- Uses some fields undefined in ISO 9660 to provide support for features such as long mixed-case file names, symbolic links, and nested directories (in other words, directories that can themselves contain other directories) Joliet -- An extension of the ISO 9660 standard, developed by Microsoft to allow CD-ROMs to contain long file names, using the Unicode character set Red Hat Enterprise Linux is able to correctly interpret ISO 9660 file systems using both the Rock Ridge and Joliet extensions.

Commands:
Chapter 1. Architecture 1.1. Terminology VM or Process - a JBoss EAP instance running JBoss Data Virtualization. Host - a machine that is "hosting" one or more VMs. Service - a subsystem running in a VM (often in many VMs) and providing a related set of functionality In addition to these main components, the service platform provides a core set of services available to applications built on top of the service platform. These services are: Session - the Session service manages active session information. Buffer Manager - the Buffer Manager service provides access to data management for intermediate results. See Section 1.2.2, "Buffer Management" . Transaction - the Transaction service manages global, local, and request scoped transactions. See Section 5.1, "Transaction Support" for more information.

Commands:
Chapter 3. PXE Network Installations Red Hat Enterprise Linux allows for installation over a network using the NFS, FTP, or HTTP protocols. A network installation can be started from a boot CD-ROM, a bootable flash memory drive, or by using the askmethod boot option with the Red Hat Enterprise Linux CD #1. Alternatively, if the system to be installed contains a network interface card (NIC) with Pre-Execution Environment (PXE) support, it can be configured to boot from files on another networked system rather than local media such as a CD-ROM. For a PXE network installation, the client's NIC with PXE support sends out a broadcast request for DHCP information. The DHCP server provides the client with an IP address, other network information such as name server, the IP address or hostname of the tftp server (which provides the files necessary to start the installation program), and the location of the files on the tftp server. This is possible because of PXELINUX, which is part of the syslinux package. The following steps must be performed to prepare for a PXE installation: Configure the network (NFS, FTP, HTTP) server to export the installation tree. Configure the files on the tftp server necessary for PXE booting. Configure which hosts are allowed to boot from the PXE configuration. Start the tftp service. Configure DHCP. Boot the client, and start the installation. 3.1. Setting up the Network Server First, configure an NFS, FTP, or HTTP server to export the entire installation tree for the version and variant of Red Hat Enterprise Linux to be installed. Refer to the section Preparing for a Network Installation in the Installation Guide for detailed instructions.

Commands:
Chapter 12. Integrating with the Red Hat build of Debezium for change data capture The Red Hat build of Debezium is a distributed change data capture platform. It captures row-level changes in databases, creates change event records, and streams the records to Kafka topics. Debezium is built on Apache Kafka. You can deploy and integrate the Red Hat build of Debezium with AMQ Streams. Following a deployment of AMQ Streams, you deploy Debezium as a connector configuration through Kafka Connect. Debezium passes change event records to AMQ Streams on OpenShift. Applications can read these change event streams and access the change events in the order in which they occurred. Debezium has multiple uses, including: Data replication Updating caches and search indexes Simplifying monolithic applications Data integration Enabling streaming queries To capture database changes, deploy Kafka Connect with a Debezium database connector. You configure a KafkaConnector resource to define the connector instance. For more information on deploying the Red Hat build of Debezium with AMQ Streams, refer to the product documentation . The documentation includes a Getting Started with Debezium guide that guides you through the process of setting up the services and connector required to view change event records for database updates.

Commands:
3.8. Changing Default User Configuration The realmd system supports modifying the default user home directory and shell POSIX attributes. For example, this might be required when some POSIX attributes are not set in the Windows user accounts or when these attributes are different from POSIX attributes of other users on the local system. Important Changing the configuration as described in this section only works if the realm join command has not been run yet. If a system is already joined, change the default home directory and shell in the /etc/sssd/sssd.conf file, as described in the section called "Optional: Configure User Home Directories and Shells" . To override the default home directory and shell POSIX attributes, specify the following options in the [users] section in the /etc/realmd.conf file: default-home The default-home option sets a template for creating a home directory for accounts that have no home directory explicitly set. A common format is /home/%d/%u , where %d is the domain name and %u is the user name. default-shell The default-shell option defines the default user shell. It accepts any supported system shell. For example: For more information about the options, see the realmd.conf (5) man page.

Commands:
[users] default-home = /home/%u default-shell = /bin/bash
1.2.7. Updating a Working Copy To update a working copy and get the latest changes from a Subversion repository, change to the directory with the working copy and run the following command: svn update Example 1.13. Updating a working copy Imagine that the directory with your working copy of a Subversion repository has the following contents: Also imagine that somebody recently added ChangeLog to the repository, removed the TODO file from it, changed the name of LICENSE to COPYING , and made some changes to Makefile . To update this working copy, type:

Commands:
project]USD ls AUTHORS doc INSTALL LICENSE Makefile README src TODO
myproject]USD svn update D LICENSE D TODO A COPYING A Changelog M Makefile Updated to revision 2.