mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 1. Preparing to install on IBM Cloud The installation workflows documented in this section are for IBM Cloud(R) infrastructure environments. IBM Cloud(R) classic is not supported at this time. For more information about the difference between classic and VPC infrastructures, see the IBM(R) documentation . 1.1. Prerequisites You reviewed details about the OpenShift Container Platform installation and update processes. You read the documentation on selecting a cluster installation method and preparing it for users . 1.2. Requirements for installing OpenShift Container Platform on IBM Cloud Before installing OpenShift Container Platform on IBM Cloud(R), you must create a service account and configure an IBM Cloud(R) account. See Configuring an IBM Cloud(R) account for details about creating an account, enabling API services, configuring DNS, IBM Cloud(R) account limits, and supported IBM Cloud(R) regions. You must manually manage your cloud credentials when installing a cluster to IBM Cloud(R). Do this by configuring the Cloud Credential Operator (CCO) for manual mode before you install the cluster. For more information, see Configuring IAM for IBM Cloud(R) . 1.3. Choosing a method to install OpenShift Container Platform on IBM Cloud You can install OpenShift Container Platform on IBM Cloud(R) using installer-provisioned infrastructure. This process involves using an installation program to provision the underlying infrastructure for your cluster. Installing OpenShift Container Platform on IBM Cloud(R) using user-provisioned infrastructure is not supported at this time. See Installation process for more information about installer-provisioned installation processes. 1.3.1. Installing a cluster on installer-provisioned infrastructure You can install a cluster on IBM Cloud(R) infrastructure that is provisioned by the OpenShift Container Platform installation program by using one of the following methods: Installing a customized cluster on IBM Cloud(R) : You can install a customized cluster on IBM Cloud(R) infrastructure that the installation program provisions. The installation program allows for some customization to be applied at the installation stage. Many other customization options are available post-installation . Installing a cluster on IBM Cloud(R) with network customizations : You can customize your OpenShift Container Platform network configuration during installation, so that your cluster can coexist with your existing IP address allocations and adhere to your network requirements. Installing a cluster on IBM Cloud(R) into an existing VPC : You can install OpenShift Container Platform on an existing IBM Cloud(R). You can use this installation method if you have constraints set by the guidelines of your company, such as limits when creating new accounts or infrastructure. Installing a private cluster on an existing VPC : You can install a private cluster on an existing Virtual Private Cloud (VPC). You can use this method to deploy OpenShift Container Platform on an internal network that is not visible to the internet. 1.4. steps Configuring an IBM Cloud(R) account

Commands:
Chapter 10. Publishing on the catalog After submitting your test results through the Red Hat certification portal, your application is scanned for vulnerabilities. When the scanning is completed, you can publish your product on the Red Hat Ecosystem Catalog . A RHOSP infrastructure certification is generated if you have performed the following: You ran the required tests successfully. Red Hat reviewed the testing configuration report, and found it was valid and appropriate for the certification. Perform the following steps to publish your product on the catalog: Procedure Navigate to your Product listing page. Click Publish . Your certified application is now published on the Red Hat Ecosystem Catalog.

Commands:
Chapter 19. Changing a hostname The hostname of a system is the name on the system itself. You can set the name when you install RHEL, and you can change it afterwards. 19.1. Changing a hostname by using nmcli You can use the nmcli utility to update the system hostname. Note that other utilities might use a different term, such as static or persistent hostname. Procedure Optional: Display the current hostname setting: Set the new hostname: NetworkManager automatically restarts the systemd-hostnamed to activate the new name. For the changes to take effect, reboot the host: Alternatively, if you know which services use the hostname: Restart all services that only read the hostname when the service starts: Active shell users must re-login for the changes to take effect. Verification Display the hostname: 19.2. Changing a hostname by using hostnamectl You can use the hostnamectl utility to update the hostname. By default, this utility sets the following hostname types: Static hostname: Stored in the /etc/hostname file. Typically, services use this name as the hostname. Pretty hostname: A descriptive name, such as Proxy server in data center A . Transient hostname: A fall-back value that is typically received from the network configuration. Procedure Optional: Display the current hostname setting: Set the new hostname: This command sets the static, pretty, and transient hostname to the new value. To set only a specific type, pass the --static , --pretty , or --transient option to the command. The hostnamectl utility automatically restarts the systemd-hostnamed to activate the new name. For the changes to take effect, reboot the host: Alternatively, if you know which services use the hostname: Restart all services that only read the hostname when the service starts: Active shell users must re-login for the changes to take effect. Verification Display the hostname:

Commands:
nmcli general hostname old-hostname.example.com
nmcli general hostname new-hostname.example.com
reboot
systemctl restart <service_name>
nmcli general hostname new-hostname.example.com
hostnamectl status --static old-hostname.example.com
hostnamectl set-hostname new-hostname.example.com
reboot
systemctl restart <service_name>
hostnamectl status --static new-hostname.example.com
16.7.2. Running virt-df To display file system usage for all file systems found in a disk image, enter the following: (Where /dev/vg_guests/RHEL6 is a Red Hat Enterprise Linux 6 guest virtual machine disk image. The path in this case is the host physical machine logical volume where this disk image is located.) You can also use virt-df on its own to list information about all of your guest virtual machines (ie. those known to libvirt). The virt-df command recognizes some of the same options as the standard df such as -h (human-readable) and -i (show inodes instead of blocks). virt-df also works on Windows guest virtual machines: Note You can use virt-df safely on live guest virtual machines, since it only needs read-only access. However, you should not expect the numbers to be precisely the same as those from a df command running inside the guest virtual machine. This is because what is on disk will be slightly out of synch with the state of the live guest virtual machine. Nevertheless it should be a good enough approximation for analysis and monitoring purposes. virt-df is designed to allow you to integrate the statistics into monitoring tools, databases and so on. This allows system administrators to generate reports on trends in disk usage, and alerts if a guest virtual machine is about to run out of disk space. To do this you should use the --csv option to generate machine-readable Comma-Separated-Values (CSV) output. CSV output is readable by most databases, spreadsheet software and a variety of other tools and programming languages. The raw CSV looks like the following: For resources and ideas on how to process this output to produce trends and alerts, refer to the following URL: http://libguestfs.org/virt-df.1.html .

Commands:
virt-df /dev/vg_guests/RHEL6 Filesystem 1K-blocks Used Available Use% RHEL6:/dev/sda1 101086 10233 85634 11% RHEL6:/dev/VolGroup00/LogVol00 7127864 2272744 4493036 32%
virt-df -h Filesystem Size Used Available Use% F14x64:/dev/sda1 484.2M 66.3M 392.9M 14% F14x64:/dev/vg_f14x64/lv_root 7.4G 3.0G 4.4G 41% RHEL6brewx64:/dev/sda1 484.2M 52.6M 406.6M 11% RHEL6brewx64:/dev/vg_rhel6brewx64/lv_root 13.3G 3.4G 9.2G 26% Win7x32:/dev/sda1 100.0M 24.1M 75.9M 25% Win7x32:/dev/sda2 19.9G 7.4G 12.5G 38%
virt-df --csv WindowsGuest Virtual Machine,Filesystem,1K-blocks,Used,Available,Use% Win7x32,/dev/sda1,102396,24712,77684,24.1% Win7x32,/dev/sda2,20866940,7786652,13080288,37.3%
Chapter 2. Fuse on OpenShift Fuse on OpenShift enables you to deploy Fuse applications on OpenShift Container Platform. 2.1. Supported version of OpenShift For details of the supported version (or versions) of OpenShift Container Platform to use with Fuse on OpenShift, see the Supported Configurations page. 2.2. Supported images Fuse on OpenShift provides the following Docker-formatted images: Image Platform Supported architectures fuse7/fuse-java-openshift-rhel8 Spring Boot AMD64 and Intel 64 (x86_64) fuse7/fuse-java-openshift-jdk11-rhel8 Spring Boot AMD64 and Intel 64 (x86_64) fuse7/fuse-java-openshift-jdk17-rhel8 Spring Boot AMD64 and Intel 64 (x86_64) fuse7/fuse-java-openshift-openj9-11-rhel8 Spring Boot IBM Z and LinuxONE (s390x) IBM Power Systems (ppc64le) fuse7/fuse-karaf-openshift-rhel8 Apache Karaf AMD64 and Intel 64 (x86_64) fuse7/fuse-karaf-openshift-jdk11-rhel8 Apache Karaf AMD64 and Intel 64 (x86_64) fuse7/fuse-karaf-openshift-jdk17-rhel8 Apache Karaf AMD64 and Intel 64 (x86_64) fuse7/fuse-eap-openshift-jdk11-rhel8 Red Hat JBoss Enterprise Application Platform AMD64 and Intel 64 (x86_64) fuse7/fuse-eap-openshift-jdk17-rhel8 Red Hat JBoss Enterprise Application Platform AMD64 and Intel 64 (x86_64) fuse7/fuse-console-rhel8 Fuse console AMD64 and Intel 64 (x86_64) IBM Z and LinuxONE (s390x) IBM Power Systems (ppc64le) fuse7/fuse-console- rhel8-operator Fuse console operator AMD64 and Intel 64 (x86_64) IBM Z and LinuxONE (s390x) IBM Power Systems (ppc64le) fuse7/fuse-apicurito-generator-rhel8 Apicurito REST application generator AMD64 and Intel 64 (x86_64) fuse7/fuse-apicurito-rhel8 Apicurito REST API editor AMD64 and Intel 64 (x86_64) fuse7/fuse-apicurito-rhel8-operator API Designer Operator AMD64 and Intel 64 (x86_64)

Commands:
probe::ipmib.OutRequests Name probe::ipmib.OutRequests - Count a request to send a packet Synopsis ipmib.OutRequests Values skb pointer to the struct sk_buff being acted on op value to be added to the counter (default value of 1) Description The packet pointed to by skb is filtered by the function ipmib_filter_key . If the packet passes the filter is is counted in the global OutRequests (equivalent to SNMP's MIB IPSTATS_MIB_OUTREQUESTS)

Commands:
Chapter 53. KIE Server KIE Server is the server where the rules and other artifacts for Red Hat Process Automation Manager are stored and run. KIE Server is a standalone built-in component that can be used to instantiate and execute rules through interfaces available for REST, Java Message Service (JMS), or Java client-side applications, as well as to manage processes, jobs, and Red Hat build of OptaPlanner functionality through solvers. Created as a web deployable WAR file, KIE Server can be deployed on any web container. The current version of KIE Server is included with default extensions for both Red Hat Decision Manager and Red Hat Process Automation Manager. KIE Server has a low footprint with minimal memory consumption and therefore can be deployed easily on a cloud instance. Each instance of this server can open and instantiate multiple containers, which enables you to execute multiple rule services in parallel. KIE Server can be integrated with other application servers, such as Oracle WebLogic Server or IBM WebSphere Application Server, to streamline Red Hat Process Automation Manager application management.

Commands:
3.3. Adding Devices to the Multipathing Database By default, DM-Multipath includes support for the most common storage arrays that support DM-Multipath. The default configuration values, including supported devices, can be found in the multipath.conf.defaults file. If you need to add a storage device that is not supported by default as a known multipath device, edit the /etc/multipath.conf file and insert the appropriate device information. For example, to add information about the HP Open-V series the entry looks like this: For more information on the devices section of the configuration file, see Section 4.5, "Configuration File Devices" .

Commands:
devices { device { vendor "HP" product "OPEN-V." getuid_callout "/sbin/scsi_id -g -u -p0x80 -s /block/%n" } }
5.359. xfsprogs 5.359.1. RHBA-2012:0883 - xfsprogs bug fix update Updated xfsprogs packages that fix four bugs are now available for Red Hat Enterprise Linux 6. The xfsprogs packages contain a set of commands to use the XFS file system, including mkfs.xfs. Bug Fixes BZ# 730886 Prior to this update, certain file names could cause the xfs_metadump utility to become suspended when generating obfuscated names. This update modifies the underlying code so that xfs_metadump now works as expected. BZ# 738279 Prior to this update, the allocation group size (agsize) was computed incorrectly during mkfs for some filesystem sizes. As a consequence, creating file systems could fail if file system blocks within an allocation group (agblocks) were increased past the maximum. This update modifies the computing method so that agblocks are no longer increased past the maximum. BZ# 749434 Prior to this update, the xfs_quota utility failed with the error message "xfs_quota: cannot initialise path table: No such file or directory" if an invalid xfs entry was encountered in the mtab. This update modifies the xfs_quota utility so that the xfs_quota utility now runs as expected. BZ# 749435 Prior to this update, the xfs_quota utility reported that the project quota values were twice as high as expected. This update modifies the xfs_quota utility so that it now reports the correct values. All users who use the XFS file system are advised to upgrade to these updated packages, which fix these bugs.

Commands:
Chapter 4. Technology Previews This section provides a list of all Technology Previews available in OpenShift sandboxed containers 1.8. See Technology Preview Features Support Scope for more information. Peer pod support for IBM Z and IBM LinuxONE You can deploy OpenShift sandboxed containers workloads, without nested virtualization, by using peer pods on IBM Z(R) and IBM(R) LinuxONE (s390x architecture). Jira:KATA-2030 Confidential Containers on Microsoft Azure Cloud Computing Services, IBM Z, and IBM LinuxONE Confidential Containers provides enhanced security for cloud-native applications, allowing them to run in secure and isolated environments known as Trusted Execution Environments (TEEs), which protect the containers and their data even when in use. Note the following limitations: No encryption and integrity protection of the confidential virtual machine (CVM) root filesystem (rootfs): The CVM executes inside the TEE and runs the container workload. Lack of encryption and integrity protection of the rootfs could allow a malicious admin to exfiltrate sensitive data written to the rootfs or to tamper with the rootfs data. Integrity protection and encryption for the rootfs is currently work in progress. You must ensure that all your application writes are in memory. No encrypted container image support: Only signed container image support is currently available. Encrypted container image support is work in progress. Communication between the Kata shim and the agent components inside the CVM is subject to tampering: The agent components inside the CVM are responsible for executing Kubernetes API commands from the Kata shim running on the OpenShift worker node. We use an agent policy in the CVM that turns off Kubernetes exec and log APIs for the containers to avoid exfiltration of sensitive data via the Kubernetes API. However, this is incomplete; further work is ongoing to harden the communication channel between the shim and the agent components. The agent policy can be overridden at runtime by using pod annotations. Currently, runtime policy annotations in the pod are not verified by the attestation process. No native support for encrypted pod-to-pod communication: Pod-to-pod communication is unencrypted. You must use TLS at the application level for all pod-to-pod communication. Image double-pull on the worker node and inside the CVM: The container image is downloaded and executed in the CVM that executes inside the TEE. However, currently the image is also downloaded on the worker node. Building the CVM image for Confidential Containers requires the OpenShift sandboxed containers Operator to be available in the cluster. Jira:KATA-2416

Commands:
1.2. About glusterFS glusterFS aggregates various storage servers over network interconnects into one large parallel network file system. Based on a stackable user space design, it delivers exceptional performance for diverse workloads and is a key building block of Red Hat Gluster Storage. The POSIX compatible glusterFS servers, which use XFS file system format to store data on disks, can be accessed using industry-standard access protocols including Network File System (NFS) and Server Message Block (SMB) (also known as CIFS).

Commands:
Chapter 1. Requirements for scaling storage nodes Before you proceed to scale the storage nodes, refer to the following sections to understand the node requirements for your specific Red Hat OpenShift Data Foundation instance: Platform requirements Storage device requirements Dynamic storage devices Local storage devices Capacity planning Important Always ensure that you have plenty of storage capacity. If storage ever fills completely, it is not possible to add capacity or delete or migrate content away from the storage to free up space completely. Full storage is very difficult to recover. Capacity alerts are issued when cluster storage capacity reaches 75% (near-full) and 85% (full) of total capacity. Always address capacity warnings promptly, and review your storage regularly to ensure that you do not run out of storage space. If you do run out of storage space completely, contact Red Hat Customer Support . 1.1. Supported Deployments for Red Hat OpenShift Data Foundation User-provisioned infrastructure: Amazon Web Services (AWS) VMware Bare metal IBM Power IBM Z or LinuxONE Installer-provisioned infrastructure: Amazon Web Services (AWS) Microsoft Azure Red Hat Virtualization VMware

Commands:
1.13. Connecting to a VDB as a Data Source JBoss Data Virtualization virtual databases (VDBs) can be configured as an JBoss Enterprise Application Platform (EAP) data source. The data source can then be accessed from JNDI or injected into your Java EE applications. A JBoss Data Virtualization data source is deployed in the same way as any other database resource. Note The recommended approach for configuring data sources is to use JBoss CLI or Management Console, not directly editing the standalone.xml configuration file. See the Red Hat JBoss Enterprise Application Platform Administration and Configuration Guide for more information on how to configure data sources in JBoss EAP.

Commands:
Chapter 11. Storage Concepts This chapter introduces the concepts used for describing and managing storage devices. Terms such as Storage pools and Volumes are explained in the sections that follow. 11.1. Storage Pools A storage pool is a file, directory, or storage device managed by libvirt for the purpose of providing storage to guest virtual machines. The storage pool can be local or it can be shared over a network. A storage pool is a quantity of storage set aside by an administrator, often a dedicated storage administrator, for use by guest virtual machines. Storage pools are divided into storage volumes either by the storage administrator or the system administrator, and the volumes are assigned to guest virtual machines as block devices. In short storage volumes are to partitions what storage pools are to disks. Although the storage pool is a virtual container it is limited by two factors: maximum size allowed to it by qemu-kvm and the size of the disk on the host physical machine. Storage pools may not exceed the size of the disk on the host physical machine. The maximum sizes are as follows: virtio-blk = 2^63 bytes or 8 Exabytes(using raw files or disk) Ext4 = ~ 16 TB (using 4 KB block size) XFS = ~8 Exabytes qcow2 and host file systems keep their own metadata and scalability should be evaluated/tuned when trying very large image sizes. Using raw disks means fewer layers that could affect scalability or max size. libvirt uses a directory-based storage pool, the /var/lib/libvirt/images/ directory, as the default storage pool. The default storage pool can be changed to another storage pool. Local storage pools - Local storage pools are directly attached to the host physical machine server. Local storage pools include: local directories, directly attached disks, physical partitions, and LVM volume groups. These storage volumes store guest virtual machine images or are attached to guest virtual machines as additional storage. As local storage pools are directly attached to the host physical machine server, they are useful for development, testing and small deployments that do not require migration or large numbers of guest virtual machines. Local storage pools are not suitable for many production environments as local storage pools do not support live migration. Networked (shared) storage pools - Networked storage pools include storage devices shared over a network using standard protocols. Networked storage is required when migrating virtual machines between host physical machines with virt-manager, but is optional when migrating with virsh. Networked storage pools are managed by libvirt. Supported protocols for networked storage pools include: Fibre Channel-based LUNs iSCSI NFS GFS2 SCSI RDMA protocols (SCSI RCP), the block export protocol used in InfiniBand and 10GbE iWARP adapters. Note Multi-path storage pools should not be created or used as they are not fully supported.

Commands:
23.2. Red Hat Data Grid Server CLI Red Hat JBoss Data Grid includes a new Remote Client-Server mode CLI. This CLI can only be used for specific use cases, such as manipulating the server subsystem for the following: configuration management obtaining metrics Report a bug 23.2.1. Start the Server Mode CLI Use the following commands to run the JBoss Data Grid Server CLI from the command line: For Linux: For Windows: Report a bug

Commands:
JDG_HOME/bin/cli.sh
C:\>JDG_HOME\bin\cli.bat
Chapter 4. Publishing applications with .NET 9.0 .NET 9.0 applications can be published to use a shared system-wide version of .NET or to include .NET. The following methods exist for publishing .NET 9.0 applications: Self-contained deployment (SCD) - The application includes .NET. This method uses a runtime built by Microsoft. Framework-dependent deployment (FDD) - The application uses a shared system-wide version of .NET. Note When publishing an application for RHEL, Red Hat recommends using FDD, because it ensures that the application is using an up-to-date version of .NET, built by Red Hat, that uses a set of native dependencies. Prerequisites Existing .NET application. For more information about how to create a .NET application, see Creating an application using .NET . 4.1. Publishing .NET applications The following procedure outlines how to publish a framework-dependent application. Procedure Publish the framework-dependent application: Replace my-app with the name of the application you want to publish. Optional: If the application is for RHEL only, trim out the dependencies needed for other platforms: Replace architecture based on the platform you are using: For Intel: x64 For IBM Z and LinuxONE: s390x For 64-bit Arm: arm64 For IBM Power: ppc64le

Commands:
dotnet publish my-app -f net9.0
dotnet publish my-app -f net9.0 -r rhel.8- architecture --self-contained false