mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 2. Installing the native Data Grid CLI as a client plugin Data Grid provides a command line interface (CLI) compiled to a native executable that you can install as a plugin for oc clients. You can then use your oc client to: Create Data Grid Operator subscriptions and remove Data Grid Operator installations. Set up Data Grid clusters and configure services. Work with Data Grid resources via remote shells. 2.1. Installing the native Data Grid CLI plugin Install the native Data Grid Command Line Interface (CLI) as a plugin for oc clients. Prerequisites Have an oc client. Download the native Data Grid CLI distribution from the Data Grid software downloads . Procedure Extract the .zip archive for the native Data Grid CLI distribution. Copy the native executable, or create a hard link, to a file named "kubectl-infinispan", for example: Add kubectl-infinispan to your PATH . Verify that the CLI is installed. Use the infinispan --help command to view available commands. Additional resources Extending the OpenShift CLI with plug-ins 2.2. kubectl-infinispan command reference This topic provides some details about the kubectl-infinispan plugin for clients. Tip Use the --help argument to view the complete list of available options and descriptions for each command. For example, oc infinispan create cluster --help prints all command options for creating Data Grid clusters. Command Description oc infinispan install Creates Data Grid Operator subscriptions and installs into the global namespace by default. oc infinispan create cluster Creates Data Grid clusters. oc infinispan get clusters Displays running Data Grid clusters. oc infinispan shell Starts an interactive remote shell session on a Data Grid cluster. oc infinispan delete cluster Removes Data Grid clusters. oc infinispan uninstall Removes Data Grid Operator installations and all managed resources.

Commands:
cp redhat-datagrid-cli kubectl-infinispan
plugin list The following compatible plugins are available: /path/to/kubectl-infinispan
infinispan --help
Providing feedback on Red Hat documentation We appreciate your feedback on our documentation. Let us know how we can improve it. Submitting feedback through Jira (account required) Make sure you are logged in to the Jira website. Provide feedback by clicking on this link . Enter a descriptive title in the Summary field. Enter your suggestion for improvement in the Description field. Include links to the relevant parts of the documentation. If you want to be notified about future updates, please make sure you are assigned as Reporter . Click Create at the bottom of the dialogue.

Commands:
Authentication builds for Red Hat OpenShift 1.3 Understanding authentication at runtime Red Hat OpenShift Documentation Team

Commands:
apiVersion: v1 data: .dockerconfigjson: <pull_secret> 1 kind: Secret metadata: annotations: build.shipwright.io/referenced.secret: "true" 2 name: secret-docker type: kubernetes.io/dockerconfigjson
apiVersion: v1 kind: Secret metadata: name: secret-git-basic-auth annotations: build.shipwright.io/referenced.secret: "true" type: kubernetes.io/basic-auth 1 stringData: 2 username: <cleartext_username> password: <cleartext_password>
apiVersion: v1 kind: Secret metadata: name: secret-git-ssh-auth annotations: build.shipwright.io/referenced.secret: "true" type: kubernetes.io/ssh-auth 1 data: ssh-privatekey: | 2 # Insert ssh private key, base64 encoded
apiVersion: shipwright.io/v1beta1 kind: Build metadata: name: buildah-golang-build spec: source: git: url: git@gitlab.com:userjohn/newtaxi.git cloneSecret: secret-git-ssh-auth
apiVersion: shipwright.io/v1beta1 kind: Build metadata: name: buildah-golang-build spec: source: git: url: https://gitlab.com/userjohn/newtaxi.git cloneSecret: secret-git-basic-auth
oc --namespace <namespace> create secret docker-registry <container_registry_secret_name> --docker-server=<registry_host> \ 1 --docker-username=<username> \ 2 --docker-password=<password> \ 3 --docker-email=<email_address>
oc --namespace <namespace> annotate secrets <container_registry_secret_name> build.shipwright.io/referenced.secret='true'
apiVersion: shipwright.io/v1beta1 kind: Build metadata: name: buildah-golang-build # output: image: <path_to_image> pushSecret: <container_registry_secret_name>
probe::socket.write_iter.return Name probe::socket.write_iter.return - Conclusion of message send via sock_write_iter Synopsis socket.write_iter.return Values type Socket type value size Size of message received (in bytes) or error code if success = 0 flags Socket flags value state Socket state value success Was receive successful? (1 = yes, 0 = no) family Protocol family value protocol Protocol value name Name of this probe Context The message receiver. Description Fires at the conclusion of sending a message on a socket via the sock_write_iter function

Commands:
5.2. Mounting an ext4 File System An ext4 file system can be mounted with no extra options. For example: The ext4 file system also supports several mount options to influence behavior. For example, the acl parameter enables access control lists, while the user_xattr parameter enables user extended attributes. To enable both options, use their respective parameters with -o , as in: As with ext3, the option data_err=abort can be used to abort the journal if an error occurs in file data. The tune2fs utility also allows administrators to set default mount options in the file system superblock. For more information on this, refer to man tune2fs . Write Barriers By default, ext4 uses write barriers to ensure file system integrity even when power is lost to a device with write caches enabled. For devices without write caches, or with battery-backed write caches, disable barriers using the nobarrier option, as in: For more information about write barriers, refer to Chapter 22, Write Barriers . Direct Access Technology Preview Starting with Red Hat Enterprise Linux 7.3, Direct Access (DAX) provides, as a Technology Preview on the ext4 and XFS file systems, a means for an application to directly map persistent memory into its address space. To use DAX, a system must have some form of persistent memory available, usually in the form of one or more Non-Volatile Dual In-line Memory Modules (NVDIMMs), and a file system that supports DAX must be created on the NVDIMM(s). Also, the file system must be mounted with the dax mount option. Then, an mmap of a file on the dax-mounted file system results in a direct mapping of storage into the application's address space.

Commands:
mount /dev/ device /mount/point
mount -o acl,user_xattr /dev/ device /mount/point
mount -o data_err=abort / dev / device / mount / point
mount -o nobarrier /dev/ device /mount/point
10.5.66. Configuration Directives for SSL The directives in /etc/httpd/conf.d/ssl.conf file can be configured to enable secure Web communications using SSL and TLS. 10.5.66.1. SetEnvIf SetEnvIf sets environment variables based on the headers of incoming connections. It is not solely an SSL directive, though it is present in the supplied /etc/httpd/conf.d/ssl.conf file. It's purpose in this context is to disable HTTP keepalive and to allow SSL to close the connection without a closing notification from the client browser. This setting is necessary for certain browsers that do not reliably shut down the SSL connection. For more information on other directives within the SSL configuration file, refer to the following URLs: http://localhost/manual/mod/mod_ssl.html http://httpd.apache.org/docs-2.0/mod/mod_ssl.html For information about setting up an Apache HTTP Secure Server, Refer to the chapter titled Apache HTTP Secure Server Configuration in the System Administrators Guide . Note In most cases, SSL directives are configured appropriately during the installation of Red Hat Enterprise Linux. Be careful when altering Apache HTTP Secure Server directives, misconfiguration can lead to security vulnerabilities.

Commands:
Chapter 3. Deprecated features The following features are being deprecated in this release. 3.1. Red Hat Enterprise Linux 7 support This release removes support for the Red Hat Enterprise Linux 7 operating system. From JBoss Web Server 6.0 onward, Red Hat does not support the installation of JBoss Web Server from an archive file or RPM packages on Red Hat Enterprise Linux 7 hosts. For more information about supported operating system versions, see OS/JVM certifications . 3.2. Window 2016 Server support This release removes support for the Windows 2016 Server operating system. From JBoss Web Server 6.0 onward, Red Hat does not support the installation of JBoss Web Server from an archive file on Windows 2016 Server hosts. For more information about supported operating system versions, see OS/JVM certifications . 3.3. JDK 8 support This release removes support for using JBoss Web Server with any of the following JDK versions: OpenJDK 1.8.x Oracle JDK 1.8.x IBM JDK 1.8.x For more information about supported JDK versions, see OS/JVM certifications . 3.4. APR connector support With the introduction of Apache Tomcat 10.1 support, JBoss Web Server no longer supports use of the Apache Portable Portable (APR) native connector. From JBoss Web Server 6.0 onward, JBoss Web Server only supports use of the NIO connector or the NIO2 connector. 3.5. JWS_HTTPS_SECRET environment variable From JBoss Web Server 6.0 onward, JWS for OpenShift no longer supports the JWS_HTTPS_SECRET environment variable. In releases, this environment variable specified the name of the secret that contained the certificate files for secure HTTPS connections (for example, jws-app-secret ). For more information, see JWS for OpenShift environment variable enhancements . 3.6. Apache CXF and Hibernate ORM artifacts removed from the JBoss Web Server Maven repository From JBoss Web Server 6.0 onward, Red Hat no longer provides Apache CXF and Hibernate JAR files in the jboss-web-server-6.0. x -maven-repository.zip file that you can download from the Red Hat Customer Portal.

Commands:
Chapter 2. Power Management Auditing And Analysis 2.1. Audit And Analysis Overview The detailed manual audit, analysis, and tuning of a single system is usually the exception because the time and cost spent to do so typically outweighs the benefits gained from these last pieces of system tuning. However, performing these tasks once for a large number of nearly identical systems where you can reuse the same settings for all systems can be very useful. For example, consider the deployment of thousands of desktop systems, or a HPC cluster where the machines are nearly identical. Another reason to do auditing and analysis is to provide a basis for comparison against which you can identify regressions or changes in system behavior in the future. The results of this analysis can be very helpful in cases where hardware, BIOS, or software updates happen regularly and you want to avoid any surprises with regard to power consumption. Generally, a thorough audit and analysis gives you a much better idea of what is really happening on a particular system. Auditing and analyzing a system with regard to power consumption is relatively hard, even with the most modern systems available. Most systems do not provide the necessary means to measure power use via software. Exceptions exist though: the ILO management console of Hewlett Packard server systems has a power management module that you can access through the web. IBM provides a similar solution in their BladeCenter power management module. On some Dell systems, the IT Assistant offers power monitoring capabilities as well. Other vendors are likely to offer similar capabilities for their server platforms, but as can be seen there is no single solution available that is supported by all vendors. Direct measurements of power consumption is often only necessary to maximize savings as far as possible. Fortunately, other means are available to measure if changes are in effect or how the system is behaving. This chapter describes the necessary tools.

Commands:
8.150. nfs-utils-lib 8.150.1. RHBA-2014:1451 - nfs-utils-lib bug fix and enhancement update Updated nfs-utils-lib packages that fix one bug and add one enhancement are now available for Red Hat Enterprise Linux 6. The nfs-utils-lib packages contain support libraries required by the programs in the nfs-utils packages. Enhancement BZ# 1066153 Previously, when the chown utility was used on an NFSv4 mount, chown did not adhere to the no_root_squash option, and thus was not able to change the user and group ownership of each given file. With this update, libnfsidmap, a library to help mapping IDs mainly for NFSv4, has been patched, and chown now handles the user and group ownership as expected. * The rpc.idmapd daemon has been enhanced to be able to parse fully-qualified user names, such as "user@subdomain". Without this enhancement, the UID or GID mappings were failing and clients were incorrectly listed as owned by "nobody". Users of nfs-utils-lib are advised to upgrade to these updated packages, which fix this bug and add this enhancement.

Commands:
Chapter 3. Updating Red Hat build of OpenJDK 17 for Microsoft Windows using the archive Red Hat build of OpenJDK 17 for Microsoft Windows can be manually update using the archive. Procedure Download the archive of Red Hat build of OpenJDK 17. Extract the contents of an archive to a directory of your choice. Note Extracting the contents of an archive to a directory path that does not contain spaces is recommended. On Command Prompt, update JAVA_HOME environment variable as follows: Open Command Prompt as an administrator. Set the value of the environment variable to your Red Hat build of OpenJDK 17 for Microsoft Windows installation path: If the path contains spaces, use the shortened path name. Restart Command Prompt to reload the environment variables. Set the value of PATH variable if it is not set already: Restart Command Prompt to reload the environment variables. Verify that java -version works without supplying the full path.

Commands:
C:\> setx /m JAVA_HOME "C:\Progra~1\RedHat\java-17-openjdk-17.0.0.0.35-1"
C:\> setx -m PATH "%PATH%;%JAVA_HOME%\bin";
C:\> java -version openjdk version "17" 2021-09-14 LTS OpenJDK Runtime Environment 21.9 (build 17+35-LTS) OpenJDK 64-Bit Server VM 21.9 (build 17+35-LTS, mixed mode, sharing)
Chapter 6. Minimum hardware recommendations for containerized Ceph Ceph can run on non-proprietary commodity hardware. Small production clusters and development clusters can run without performance optimization with modest hardware. Process Criteria Minimum Recommended ceph-osd-container Processor 1x AMD64 or Intel 64 CPU CORE per OSD container RAM Minimum of 5 GB of RAM per OSD container OS Disk 1x OS disk per host OSD Storage 1x storage drive per OSD container. Cannot be shared with OS Disk. block.db Optional, but Red Hat recommended, 1x SSD or NVMe or Optane partition or lvm per daemon. Sizing is 4% of block.data for BlueStore for object, file and mixed workloads and 1% of block.data for the BlueStore for Block Device, Openstack cinder, and Openstack cinder workloads. block.wal Optionally, 1x SSD or NVMe or Optane partition or logical volume per daemon. Use a small size, for example 10 GB, and only if it's faster than the block.db device. Network 2x 1 GB Ethernet NICs, 10 GB Recommended ceph-mon-container Processor 1x AMD64 or Intel 64 CPU CORE per mon-container RAM 3 GB per mon-container Disk Space 10 GB per mon-container , 50 GB Recommended Monitor Disk Optionally, 1x SSD disk for Monitor rocksdb data Network 2x 1GB Ethernet NICs, 10 GB Recommended ceph-mgr-container Processor 1x AMD64 or Intel 64 CPU CORE per mgr-container RAM 3 GB per mgr-container Network 2x 1GB Ethernet NICs, 10 GB Recommended ceph-radosgw-container Processor 1x AMD64 or Intel 64 CPU CORE per radosgw-container RAM 1 GB per daemon Disk Space 5 GB per daemon Network 1x 1GB Ethernet NICs ceph-mds-container Processor 1x AMD64 or Intel 64 CPU CORE per mds-container RAM 3 GB per mds-container This number is highly dependent on the configurable MDS cache size. The RAM requirement is typically twice as much as the amount set in the mds_cache_memory_limit configuration setting. Note also that this is the memory for your daemon, not the overall system memory. Disk Space 2 GB per mds-container , plus taking into consideration any additional space required for possible debug logging, 20GB is a good start. Network 2x 1GB Ethernet NICs, 10 GB Recommended Note that this is the same network as the OSD containers. If you have a 10 GB network on your OSDs you should use the same on your MDS so that the MDS is not disadvantaged when it comes to latency.

Commands:
Chapter 4. Finding more information The following table includes deployment references for components mentioned in this guide. For additional manuals for Red Hat OpenStack Platform, see Product Documentation for Red Hat OpenStack Platform 16.0 . Component Reference Red Hat Enterprise Linux Red Hat OpenStack Platform 16.0 is supported on Red Hat Enterprise Linux 8.1. For information on installing Red Hat Enterprise Linux, see Product Documentation for Red Hat Enterprise Linux 8 . Red Hat OpenStack Platform To install OpenStack components and their dependencies, use the Red Hat OpenStack Platform director. Director uses a basic OpenStack undercloud, which is used to provision and manage the OpenStack nodes in the final overcloud. Be aware that you need one extra host machine for the installation of the undercloud, in addition to the environment necessary for the deployed overcloud. For more information, see the Director Installation and Usage guide. High Availability For the configuration of additional high availability components (for example, HAProxy), see the High Availability Deployment and Usage guide. For information about configuring live migration, see Migrating virtual machine instances between Compute nodes in the Instances and Images Guide . Octavia The OpenStack Load-balancing service (Octavia) provides a Load Balancing-as-a-Service (LBaaS) version 2 implementation for Red Hat OpenStack Platform director installations. To use Load Balancing-as-a-Service, see Load Balancing-as-a-Service (LBaaS) with Octavia in the Networking Guide . Pacemaker Pacemaker is integrated into Red Hat Enterprise Linux as an add-on. To set up Red Hat Enterprise Linux for high availability, see the Configuring and managing high availability clusters guide.

Commands:
probe::tcpmib.EstabResets Name probe::tcpmib.EstabResets - Count the reset of a socket Synopsis tcpmib.EstabResets Values sk pointer to the struct sock 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 tcpmib_filter_key . If the packet passes the filter is is counted in the global EstabResets (equivalent to SNMP's MIB TCP_MIB_ESTABRESETS)

Commands:
Chapter 5. VNF certification level Most certification do not have levels; instead a Partner solution is either certified or not. VNF however includes an additional certification level to address that these applications often include a VM that is not otherwise supportable by Red Hat. If a Partners performs a VNF certification following VNF certification levels will get generated: Certified: The Red Hat team generates a Certified level when the certificate is completed. The VNF test level will be Certified if the VNF image is based on the RHEL operating system during the VNF certification process. The following screenshot illustrates the Certified level: Figure 5.1. VNF Certified Level Vendor Validated: The Red Hat team generates a Vendor Validated level when the certificate is completed. The VNF test level will be Vendor Validated if the VNF image is based on a non-RHEL operating system during the VNF certification process. The following screenshot illustrates the Vendor Validated level: Figure 5.2. VNF Vendor Validated Level

Commands:
Chapter 9. Secure Linux Containers Linux Containers ( LXC ) is a low-level virtualization feature that allows you to run multiple copies of the same service at the same time on a system. Compared to full virtualization, containers do not require an entire new system to boot, can use less memory, and can use the base operating system in a read-only manner. For example, LXC allow you to run multiple web servers simultaneously, each with their own data while sharing the system data, and even running as the root user. However, running a privileged process within a container could affect other processes running outside of the container or processes running in other containers. Secure Linux containers use the SELinux context, therefore preventing the processes running within them from interacting with each other or with the host. The Docker application is the main utility for managing Linux Containers in Red Hat Enterprise Linux. As an alternative, you can also use the virsh command-line utility provided by the libvirt package. For further details about Linux Containers, see Getting Started with Containers .

Commands:
Chapter 5. Deploying Red Hat Quay on public cloud Red Hat Quay can run on public clouds, either in standalone mode or where OpenShift Container Platform itself has been deployed on public cloud. A full list of tested and supported configurations can be found in the Red Hat Quay Tested Integrations Matrix at https://access.redhat.com/articles/4067991 . Recommendation: If Red Hat Quay is running on public cloud, then you should use the public cloud services for Red Hat Quay backend services to ensure proper high availability and scalability. 5.1. Running Red Hat Quay on Amazon Web Services If Red Hat Quay is running on Amazon Web Services (AWS), you can use the following features: AWS Elastic Load Balancer AWS S3 (hot) blob storage AWS RDS database AWS ElastiCache Redis EC2 virtual machine recommendation: M3.Large or M4.XLarge The following image provides a high level overview of Red Hat Quay running on AWS: Red Hat Quay on AWS 5.2. Running Red Hat Quay on Microsoft Azure If Red Hat Quay is running on Microsoft Azure, you can use the following features: Azure managed services such as highly available PostgreSQL Azure Blob Storage must be hot storage Azure cool storage is not available for Red Hat Quay Azure Cache for Redis The following image provides a high level overview of Red Hat Quay running on Microsoft Azure: Red Hat Quay on Microsoft Azure

Commands:
probe::ioblock_trace.bounce Name probe::ioblock_trace.bounce - Fires whenever a buffer bounce is needed for at least one page of a block IO request. Synopsis ioblock_trace.bounce Values q request queue on which this bio was queued. size total size in bytes vcnt bio vector count which represents number of array element (page, offset, length) which makes up this I/O request idx offset into the bio vector array phys_segments - number of segments in this bio after physical address coalescing is performed. bdev target block device p_start_sect points to the start sector of the partition structure of the device ino i-node number of the mapped file rw binary trace for read/write request name name of the probe point sector beginning sector for the entire bio bdev_contains points to the device object which contains the partition (when bio structure represents a partition) devname device for which a buffer bounce was needed. flags see below BIO_UPTODATE 0 ok after I/O completion BIO_RW_BLOCK 1 RW_AHEAD set, and read/write would block BIO_EOF 2 out-out-bounds error BIO_SEG_VALID 3 nr_hw_seg valid BIO_CLONED 4 doesn't own data BIO_BOUNCED 5 bio is a bounce bio BIO_USER_MAPPED 6 contains user pages BIO_EOPNOTSUPP 7 not supported bytes_done number of bytes transferred Context The process creating a block IO request.

Commands: