mtpti5iD/redhat-docs_dataset huggingface dataset:
4.9. Configuring Headless Virtual Machines You can configure a headless virtual machine when it is not necessary to access the machine via a graphical console. This headless machine will run without graphical and video devices. This can be useful in situations where the host has limited resources, or to comply with virtual machine usage requirements such as real-time virtual machines. Headless virtual machines can be administered via a Serial Console, SSH, or any other service for command line access. Headless mode is applied via the Console tab when creating or editing virtual machines and machine pools, and when editing templates. It is also available when creating or editing instance types. If you are creating a new headless virtual machine, you can use the Run Once window to access the virtual machine via a graphical console for the first run only. See Section A.2, "Explanation of Settings in the Run Once Window" for more details. Prerequisites If you are editing an existing virtual machine, and the Red Hat Virtualization guest agent has not been installed, note the machine's IP prior to selecting Headless Mode . Before running a virtual machine in headless mode, the GRUB configuration for this machine must be set to console mode otherwise the guest operating system's boot process will hang. To set console mode, comment out the spashimage flag in the GRUB menu configuration file: Note Restart the virtual machine if it is running when selecting the Headless Mode option. Configuring a Headless Virtual Machine Click Compute Virtual Machines and select a virtual machine. Click Edit . Click the Console tab. Select Headless Mode . All other fields in the Graphical Console section are disabled. Optionally, select Enable VirtIO serial console to enable communicating with the virtual machine via serial console. This is highly recommended. Reboot the virtual machine if it is running. See Section 6.3, "Rebooting a Virtual Machine" .

Commands:
#splashimage=(hd0,0)/grub/splash.xpm.gz serial --unit=0 --speed=9600 --parity=no --stop=1 terminal --timeout=2 serial
Chapter 12. Installing a three-node cluster on Azure In OpenShift Container Platform version 4.13, you can install a three-node cluster on Microsoft Azure. A three-node cluster consists of three control plane machines, which also act as compute machines. This type of cluster provides a smaller, more resource efficient cluster, for cluster administrators and developers to use for testing, development, and production. You can install a three-node cluster using either installer-provisioned or user-provisioned infrastructure. Note Deploying a three-node cluster using an Azure Marketplace image is not supported. 12.1. Configuring a three-node cluster You configure a three-node cluster by setting the number of worker nodes to 0 in the install-config.yaml file before deploying the cluster. Setting the number of worker nodes to 0 ensures that the control plane machines are schedulable. This allows application workloads to be scheduled to run from the control plane nodes. Note Because application workloads run from control plane nodes, additional subscriptions are required, as the control plane nodes are considered to be compute nodes. Prerequisites You have an existing install-config.yaml file. Procedure Set the number of compute replicas to 0 in your install-config.yaml file, as shown in the following compute stanza: compute: - name: worker platform: {} replicas: 0 If you are deploying a cluster with user-provisioned infrastructure: After you create the Kubernetes manifest files, make sure that the spec.mastersSchedulable parameter is set to true in cluster-scheduler-02-config.yml file. You can locate this file in <installation_directory>/manifests . For more information, see "Creating the Kubernetes manifest and Ignition config files" in "Installing a cluster on Azure using ARM templates". Do not create additional worker nodes. Example cluster-scheduler-02-config.yml file for a three-node cluster apiVersion: config.openshift.io/v1 kind: Scheduler metadata: creationTimestamp: null name: cluster spec: mastersSchedulable: true policy: name: "" status: {} 12.2. steps Installing a cluster on Azure with customizations Installing a cluster on Azure using ARM templates

Commands:
compute: - name: worker platform: {} replicas: 0
apiVersion: config.openshift.io/v1 kind: Scheduler metadata: creationTimestamp: null name: cluster spec: mastersSchedulable: true policy: name: "" status: {}
Chapter 10. Supported integration with Red Hat products Streams for Apache Kafka 2.7 supports integration with the following Red Hat products: Red Hat build of Keycloak Provides OAuth 2.0 authentication and OAuth 2.0 authorization. For information on the functionality these products can introduce to your Streams for Apache Kafka deployment, refer to the product documentation. 10.1. Red Hat build of Keycloak (formerly Red Hat Single Sign-On) Streams for Apache Kafka supports OAuth 2.0 token-based authorization through Red Hat build of Keycloak Authorization Services , providing centralized management of security policies and permissions. Note Red Hat build of Keycloak replaces Red Hat Single Sign-On, which is now in maintenance support. We are working on updating our documentation, resources, and media to reflect this transition. In the interim, content that describes using Single Sign-On in the Streams for Apache Kafka documentation also applies to using the Red Hat build of Keycloak. Additional resources Red Hat build of Keycloak Supported Configurations Red Hat Single Sign-On Supported Configurations (maintenance) Revised on 2024-07-08 11:23:30 UTC

Commands:
Chapter 1. Event-Driven Ansible controller overview Event-Driven Ansible is a highly scalable, flexible automation capability that works with event sources such as other software vendors' monitoring tools. These tools monitor IT solutions and identify events and automatically implement the documented changes or response in a rulebook to handle that event. The following procedures form the user configuration: Setting up credentials Setting up a new project Setting up a new decision environment Setting up a token to authenticate to Ansible Automation Platform Controller Setting up a rulebook activation Note API documentation for Event-Driven Ansible controller is available at https://<eda-server-host>/api/eda/v1/docs

Commands:
Chapter 4. LVM Administration Overview This chapter provides an overview of the administrative procedures you use to configure LVM logical volumes. This chapter is intended to provide a general understanding of the steps involved. For specific step-by-step examples of common LVM configuration procedures, see Chapter 6, LVM Configuration Examples . For descriptions of the CLI commands you can use to perform LVM administration, see Chapter 5, LVM Administration with CLI Commands . Alternately, you can use the LVM GUI, which is described in Chapter 8, LVM Administration with the LVM GUI . 4.1. Creating LVM Volumes in a Cluster To create logical volumes in a cluster environment, you use the Clustered Logical Volume Manager (CLVM), which is a set of clustering extensions to LVM. These extensions allow a cluster of computers to manage shared storage (for example, on a SAN) using LVM. In order to use CLVM, the High Availability Add-On and Resilient Storage Add-On software, including the clvmd daemon, must be started at boot time, as described in Section 2.4, "The Clustered Logical Volume Manager (CLVM)" . Creating LVM logical volumes in a cluster environment is identical to creating LVM logical volumes on a single node. There is no difference in the LVM commands themselves, or in the LVM GUI interface. In order to enable the LVM volumes you are creating in a cluster, the cluster infrastructure must be running and the cluster must be quorate. CLVM requires changes to the lvm.conf file for cluster-wide locking. Information on configuring the lvm.conf file to support clustered locking is provided within the lvm.conf file itself. For information about the lvm.conf file, see Appendix B, The LVM Configuration Files . By default, logical volumes created with CLVM on shared storage are visible to all systems that have access to the shared storage. It is possible to create volume groups in which all of the storage devices are visible to only one node in the cluster. It is also possible to change the status of a volume group from a local volume group to a clustered volume group. For information, see Section 5.3.3, "Creating Volume Groups in a Cluster" and Section 5.3.8, "Changing the Parameters of a Volume Group" Warning When you create volume groups with CLVM on shared storage, you must ensure that all nodes in the cluster have access to the physical volumes that constitute the volume group. Asymmetric cluster configurations in which some nodes have access to the storage and others do not are not supported. For information on how to install the High Availability Add-On and set up the cluster infrastructure, see Cluster Administration . For an example of creating a mirrored logical volume in a cluster, see Section 6.5, "Creating a Mirrored LVM Logical Volume in a Cluster" .

Commands:
2.2. Data Source Authentication Data source authentication is generally determined by the capabilities of JCA resource adapters used to connect to external resources. Consult the JBoss EAP JCA documentation for the capabilities of data source pooling and supplied resource adapters for more information. Typically a single username/password credential is supported, such as when creating JDBC Data Sources. In more advanced usage scenarios the source and/or translator may be configured or customized to use an execution payload, the JBoss Data Virtualization subject, or even the calling application subject via Pass-through Authentication. See more about Developing JEE Connectors and Translator Development in Red Hat JBoss Data Virtualization Development Guide: Server Development .

Commands:
10.4. FILE Example 10.3. Sample vdb.xml file <vdb name="{vdb-name}" version="1"> <model name="{model-name}" type="PHYSICAL"> <source name="AccountsDB" translator-name="oracle" connection-jndi-name="java:/oracleDS"/> <metadata type="DDL-FILE">/accounts.ddl</metadata> </model> </vdb> This is applicable to both source and view models in zip VDB deployments. See the section about DDL Metadata in Red Hat JBoss Data Virtualization Development Guide: Reference Material .

Commands:
<vdb name="{vdb-name}" version="1"> <model name="{model-name}" type="PHYSICAL"> <source name="AccountsDB" translator-name="oracle" connection-jndi-name="java:/oracleDS"/> <metadata type="DDL-FILE">/accounts.ddl</metadata> </model> </vdb>
Chapter 4. Enabling automatic suspension Enabling automatic suspension provides benefits in terms of energy conservation by ensuring that your system goes into a lower power state after a period of inactivity. This feature helps reduce power consumption when your computer is not in use, potentially prolonging the battery life of your device. Procedure Open Settings . Click Power . Choose Automatic Suspend . Toggle the switch to enable automatic logout. Set the desired time interval for automatic logout after inactivity. This interval defines how long your system remains idle before automatically logging you out.

Commands:
28.3. Configuring Persistent Memory for File System Direct Access File system direct access requires the namespace to be configured to the fsdax mode. This mode allows for the direct access programming model. When a device is configured in the fsdax mode, a file system can be created on top of it, and then mounted with the -o fsdax mount option. Then, any application that performs an mmap() operation on a file on this file system gets direct access to its storage. See the following example: In the example, namespace0.0 is converted to namespace fsdax mode. With the --map=mem argument, ndctl puts operating system data structures used for Direct Memory Access (DMA) in system DRAM. To perform DMA, the kernel requires a data structure for each page in the memory region. The overhead of this data structure is 64 bytes per 4-KiB page. For small devices, the amount of overhead is small enough to fit in DRAM with no problems. For example, the 16-GiB namespace only requires 256MiB for page structures. Because NVDIMM devices are usually small and expensive, storing the kernel's page tracking data structures in DRAM is preferable, as indicated by the --map=mem parameter. In the future, NVDIMM devices might be terabytes in size. For such devices, the amount of memory required to store the page tracking data structures might exceed the amount of DRAM in the system. One TiB of persistent memory requires 16 GiB just for page structures. As a result, specifying the --map=dev parameter to store the data structures in the persistent memory itself is preferable in such cases. After configuring the namespace in the fsdax mode, the namespace is ready for a file system. Starting with Red Hat Enterprise Linux 7.3, both the Ext4 and XFS file system enable using persistent memory as a Technology Preview. File system creation requires no special arguments. To get the DAX functionality, mount the file system with the dax mount option. For example: Then, applications can use persistent memory and create files in the /mnt/ pmem / directory, open the files, and use the mmap operation to map the files for direct access. When creating partitions on a pmem device to be used for direct access, partitions must be aligned on page boundaries. On the Intel 64 and AMD64 architecture, at least 4KiB alignment for the start and end of the partition, but 2MiB is the preferred alignment. By default, the parted tool aligns partitions on 1MiB boundaries. For the first partition, specify 2MiB as the start of the partition. If the size of the partition is a multiple of 2MiB, all other partitions are also aligned.

Commands:
ndctl create-namespace --force --reconfig= namespace0.0 --mode=fsdax --map=mem { "dev":" namespace0.0 ", "mode":"fsdax", "size": 17177772032 , "uuid":" e6944638-46aa-4e06-a722-0b3f16a5acbf ", "blockdev":" pmem0 " }
mkfs -t xfs /dev/ pmem0 # mount -o dax /dev/ pmem0 /mnt/ pmem /
Part II. Part II: Installing Red Hat Certificate System This part describes the prerequisites and procedures for installing Red Hat Certificate System and setting up the individual subsystems. To make it easier to follow, through Chapter 6, Prerequisites for installation and Chapter 7, Installing and configuring Red Hat Certificate System , we are providing an example that demonstrates setting up a RHCS Common Criteria RSA environment on a Red Hat Enterprise Linux (RHEL) 8.6 operating system, complete with a root CA, a subordinate CA, an OCSP server, a KRA, and optionally, if TMS is of interest, a TKS and a TPS. This example setup requires two 64-bit x86_64 machines containing 64-bit versions of the RHEL 8.6 Server release operating system: rhcs10.example.com for Red Hat Certificate System (RHCS) server installation. rhds11.example.com for Red Hat Directory Server (RHDS) server installation.

Commands:
Appendix A. Using your subscription Streams for Apache Kafka is provided through a software subscription. To manage your subscriptions, access your account at the Red Hat Customer Portal. Accessing Your Account Go to access.redhat.com . If you do not already have an account, create one. Log in to your account. Activating a Subscription Go to access.redhat.com . Navigate to My Subscriptions . Navigate to Activate a subscription and enter your 16-digit activation number. Downloading Zip and Tar Files To access zip or tar files, use the customer portal to find the relevant files for download. If you are using RPM packages, this step is not required. Open a browser and log in to the Red Hat Customer Portal Product Downloads page at access.redhat.com/downloads . Locate the Streams for Apache Kafka for Apache Kafka entries in the INTEGRATION AND AUTOMATION category. Select the desired Streams for Apache Kafka product. The Software Downloads page opens. Click the Download link for your component. Installing packages with DNF To install a package and all the package dependencies, use: dnf install <package_name> To install a previously-downloaded package from a local directory, use: dnf install <path_to_download_package> Revised on 2025-03-05 17:09:48 UTC

Commands:
dnf install <package_name>
dnf install <path_to_download_package>
Chapter 3. Downloading Eclipse Temurin distributions You can download Eclipse Temurin distribution from numerous sources, such as the Eclipse Adoptium website. Both the Eclipse Adoptium main web page and the Eclipse Temurin web page include several download buttons for downloading different Eclipse Temurin distribution. Procedure Choose one of the following options to download an Eclipse Temurin distribution: From the Adoptium home web page or from the Eclipse Temurin project page , click one of the following buttons from the web page: Latest LTS Release button that preselects Red Hat build of OpenJDK 17 for the platform that it detects you are using and immediately begins downloading that selection. Other platforms and versions button that directs to a selection of all platform and version options, where you can choose the distribution that best suits your needs from the various formats such as archives, JRE archives and installers. Release archive button that directs to a selection of latest releases, older releases, and nightly beta releases. Eclipse Adoptium provides older releases and beta releases for development purposes only. Beta releases contain the most recent changes delivered into Red Hat build of OpenJDK, which you'll find useful for verifying fixes in development mode. Beta releases are not considered production ready and are not directly supported by Red Hat. Use the Eclipse Adoptium API, see the Swagger UI v3 documentation Eclipse Temurin . From the Eclipse Temurin Docker Hub Official Images, see the eclipse-temurin documentation (docker hub ) . Use the Eclipse Temurin Marketplace and Marketplace API, by going to the Adoptium TM Marketplace web page. This web page lists various distributions, such as the Red Hat build of Red Hat build of OpenJDK and Eclipse Temurin distributions. Additionally, you can make a request to the Eclipse Adoptium Marketplace API v1 to serve up these distributions. For Packages.adoptium.net , see the relevant steps outlined in Eclipse Temurin Linux (RPM/DEB) Installer Packages (Eclipse Adoptium) . Additional resources Adoptium home web page (Adoptium) Eclipse Temurin (Adoptium)

Commands:
5.3.3. Adding a Member to a Running Cluster To add a member to a running cluster, follow the steps in this section. From the cluster-specific page, click 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. Click Add . Clicking Add causes the display of the Add Nodes To Cluster dialog box. Enter the node name in the Node Hostname text box. After you have entered the node name, the node name is reused as the ricci host name; you can override this if you are communicating with ricci on an address that is different from the address to which the cluster node name resolves. As of Red Hat Enterprise Linux 6.9, after you have entered the node name and, if necessary, adjusted the ricci host name, the fingerprint of the certificate of the ricci host is displayed for confirmation. You can verify whether this matches the expected fingerprint. If it is legitimate, enter the ricci password. Important It is strongly advised that you verify the certificate fingerprint of the ricci server you are going to authenticate against. Providing an unverified entity on the network with the ricci password may constitute a confidentiality breach, and communication with an unverified entity may cause an integrity breach. If you are using a different port for the ricci agent than the default of 11111, change this parameter to the port you are using. Check the Enable Shared Storage Support check box if clustered storage is required to download the packages that support clustered storage and enable clustered LVM; you should select this only when you have access to the Resilient Storage Add-On or the Scalable File System Add-On. If you want to add more nodes, click Add Another Node and enter the node name and password for the each additional node. Click Add Nodes . Clicking Add Nodes causes the following actions: If you have selected Download Packages , the cluster software packages are downloaded onto the nodes. Cluster software is installed onto the nodes (or it is verified that the appropriate software packages are installed). The cluster configuration file is updated and propagated to each node in the cluster - including the added node. The added node joins the cluster. The Nodes page appears with a message indicating that the node is being added to the cluster. Refresh the page to update the status. When the process of adding a node is complete, click on the node name for the newly-added node to configure fencing for this node, as described in Section 4.6, "Configuring Fence Devices" . Note When you add a node to a cluster that uses UDPU transport, you must restart all nodes in the cluster for the change to take effect.

Commands:
Chapter 6. Internationalization 6.1. Red Hat Enterprise Linux 8 international languages Red Hat Enterprise Linux 8 supports the installation of multiple languages and the changing of languages based on your requirements. East Asian Languages - Japanese, Korean, Simplified Chinese, and Traditional Chinese. European Languages - English, German, Spanish, French, Italian, Portuguese, and Russian. The following table lists the fonts and input methods provided for various major languages. Language Default Font (Font Package) Input Methods English dejavu-sans-fonts French dejavu-sans-fonts German dejavu-sans-fonts Italian dejavu-sans-fonts Russian dejavu-sans-fonts Spanish dejavu-sans-fonts Portuguese dejavu-sans-fonts Simplified Chinese google-noto-sans-cjk-ttc-fonts, google-noto-serif-cjk-ttc-fonts ibus-libpinyin, libpinyin Traditional Chinese google-noto-sans-cjk-ttc-fonts, google-noto-serif-cjk-ttc-fonts ibus-libzhuyin, libzhuyin Japanese google-noto-sans-cjk-ttc-fonts, google-noto-serif-cjk-ttc-fonts ibus-kkc, libkkc Korean google-noto-sans-cjk-ttc-fonts, google-noto-serif-cjk-ttc-fonts ibus-hangul, libhangul 6.2. Notable changes to internationalization in RHEL 8 RHEL 8 introduces the following changes to internationalization compared to RHEL 7: Support for the Unicode 11 computing industry standard has been added. Internationalization is distributed in multiple packages, which allows for smaller footprint installations. For more information, see Using langpacks . A number of glibc locales have been synchronized with Unicode Common Locale Data Repository (CLDR).

Commands: