mtpti5iD/redhat-docs_dataset huggingface dataset:
3. File Systems Note The Storage Administration Guide provides further instructions on how to effectively manage file systems on Red Hat Enterprise Linux 6. Additionally, the Global File System 2 document details specific information on configuring and maintaining Red Hat Global File System 2 for Red Hat Enterprise Linux 6. 3.1. Fourth Extended Filesystem (ext4) Support The fourth extended filesystem (ext4) is based on the third extended filesystem (ext3) and features a number of improvements. These include support for larger file systems and larger files, faster and more efficient allocation of disk space, no limit on the number of subdirectories within a directory, faster file system checking, and more robust journaling. The ext4 file system is selected by default and is highly recommended. 3.2. XFS XFS is a highly scalable, high-performance file system which was originally designed at Silicon Graphics, Inc. It was created to support filesystems up to 16 exabytes (approximately 16 million terabytes), files up to 8 exabytes (approximately 8 million terabytes) and directory structures containing tens of millions of entries. XFS supports metadata journaling, which facilitates quicker crash recovery. The XFS file systems can also be defragmented and expanded while mounted and active. 3.3. Block Discard - enhanced support for thinly provisioned LUNs and SSD devices Filesystems in Red Hat Enterprise Linux 6 use the new block discard feature to allows a storage device to be informed when the filesystem detects that portions of a device (also known as blocks) are no longer in active use. While few storage devices feature block discard capabilities, newer solid state drives (SSDs) utilize this feature to optimize internal data layout and invoke proactive wear levelling. Additionally, some high end SCSI devices use block discard information to help implement thinly provisioned LUNs. 3.4. Network File System (NFS) A Network File System (NFS) allows remote hosts to mount file systems over a network and interact with those file systems as though they were mounted locally. This enables system administrators to consolidate resources onto centralized servers on the network. Red Hat Enterprise Linux 6 supports NFSv2, NFSv3, and NFSv4 clients. Mounting a file system via NFS now defaults to NFSv4. Additional improvements have been made to the NFS in Red Hat Enterprise Linux 6, providing enhanced support over Internet Protocol version 6 (IPv6)

Commands:
7.7. RHEA-2014:1439 - new package: hyperv-daemons New hyperv-daemons packages are now available for Red Hat Enterprise Linux 6. The hyperv-daemons packages provide a suite of daemons that are needed when a Linux guest is running on a Windows Host with HyperV. The following daemons are included: - hypervkvpd, the guest Hyper-V Key-Value Pair (KVP) daemon. - hypervvssd, the implementation of HyperV VSS functionality for Linux guest. - hypervfcopyd, the implementation of file copy service functionality for Linux Guest running on HyperV. This enhancement update adds the hyperv-daemons packages to Red Hat Enterprise Linux 6. (BZ# 977631 , BZ# 1107559 ) All users who require hyperv-daemons are advised to install these new packages. After installing the packages, rebooting all guest machines is recommended, otherwise the Microsoft Windows server with Hyper-V will not be able to get information from these guest machines. For more information about inclusion of, and guest installation support for, Microsoft Hyper-V drivers, refer to the Red Hat Enterprise Linux 6.6 Release Notes.

Commands:
15.2. Importing a Root Certificate First, change directories into the NSS DB: cd /path/to/nssdb Ensure that your web service is taken offline (stopped, disabled, etc.) while performing these steps and ensure no concurrent access to the NSS DB by other processes (such as a browser). Doing so may corrupt the NSS DB or result in improper usage of these certificates. When needing to import a new root certificate, ensure you acquire this certificate in a secure manner as it will be able to sign a number of certificates. We assume you already have it in a file named ca_root.crt . Please substitute the correct name and path to this file as appropriate for your scenario. For more information about the certutil and PKICertImport options used below, see Section 15.1, "About certutil and PKICertImport " . To import the root certificate: Execute PKICertImport -d . -n "CA Root" -t "CT,C,C" -a -i ca_root.crt -u L command. This command validates and imports the root certificate into your NSS DB. The validation succeeds when no error message is printed and the return code is 0. To check the return code, execute echo USD? immediately after executing the command above. In most cases, a visual error message is printed. The certificate usually fails to validate because it is expired or because it is not a CA certificate. Therefore, make sure your certificate file is correct and up-to-date. Contact the issuer and ensure that all intermediate and root certificates are present on your system.

Commands:
Updating Red Hat OpenShift Service Mesh 3.0.0tp1 Updating OpenShift Service Mesh Red Hat OpenShift Documentation Team

Commands:
kind: Istio spec: updateStrategy: type: InPlace
oc label namespace <namespace-name> istio.io/rev=<revision-name>
apiVersion: apps/v1 kind: Deployment spec: template: metadata: labels: istio.io/rev: <revision-name> spec:
label namespace <namespace-name> istio-injection=enabled
kind: Istio spec: version: 1.20.2 updateStrategy: type: InPlace
oc get istio <control-plane-name>
oc rollout restart <deployment-name>
kind: Istio spec: version: 1.20.0 updateStrategy: RevisionBased
kind: Istio spec: version: 1.20.2 updateStrategy: type: RevisionBased
oc get istiorevisions
oc rollout restart <deployment>
Chapter 11. Internationalization 11.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 11.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:
Chapter 6. Run Red Hat JBoss Data Grid JAR Files with Maven 6.1. Run JBoss Data Grid (Remote Client-Server Mode) Use the following instructions to run Red Hat JBoss Data Grid JAR files with Maven in Remote Client-Server mode. Hot Rod Client with Querying Add the following dependencies to the pom.xml file: Add infinispan-remote dependency: For instances where a Remote Cache Store is in use also add the infinispan-embedded dependency as shown below: For instances where JSR-107 is in use, ensure that the cache-api packages are available at runtime. Having these packages available can be accomplished by any of the following methods: Option 1: If JBoss EAP is in use, then add the JBoss Data Grid modules to this instance as described in Section 4.2, "Deploy JBoss Data Grid in JBoss EAP (Remote Client-Server Mode)" . Add the javax.cache.api module to the application's jboss-deployment-structure.xml . An example is shown below: Option 2: Download the jboss-datagrid-USD{jdg.version}-library file from the customer portal. Extract the downloaded archive. Embed the jboss-datagrid-USD{jdg.version}-library/lib/cache-api-USD{jcache.version}.jar file into the desired application. Option 3: If the JBoss Data Grid Maven repository is available then add an explicit dependency to the pom.xml of the project as seen below: Warning The Infinispan query API directly exposes the Hibernate Search and the Lucene APIs and cannot be embedded within the infinispan-embedded-query.jar file. Do not include other versions of Hibernate Search and Lucene in the same deployment as infinispan-embedded-query . This action will cause classpath conflicts and result in unexpected behavior. Report a bug

Commands:
<dependency> <groupId>org.infinispan</groupId> <artifactId>infinispan-remote</artifactId> <version>USD{infinispan.version}</version> </dependency>
<dependency> <groupId>org.infinispan</groupId> <artifactId>infinispan-embedded</artifactId> <version>USD{infinispan.version}</version> </dependency>
<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2"> <deployment> <dependencies> <module name="javax.cache.api" slot="jdg-6.6" services="export"/> </dependencies> </deployment> </jboss-deployment-structure>
<dependency> <groupId>javax.cache</groupId> <artifactId>cache-api</artifactId> <version>USD{jcache.version}</version> </dependency>
15.2.7. Verifying Verifying a package compares information about files installed from a package with the same information from the original package. Among other things, verifying compares the size, MD5 sum, permissions, type, owner, and group of each file. The command rpm -V verifies a package. You can use any of the Package Verify Options listed for querying to specify the packages you wish to verify. A simple use of verifying is rpm -V foo , which verifies that all the files in the foo package are as they were when they were originally installed. For example: To verify a package containing a particular file: To verify ALL installed packages: To verify an installed package against an RPM package file: This command can be useful if you suspect that your RPM databases are corrupt. If everything verified properly, there is no output. If there are any discrepancies, they are displayed. The format of the output is a string of eight characters (a c denotes a configuration file) and then the file name. Each of the eight characters denotes the result of a comparison of one attribute of the file to the value of that attribute recorded in the RPM database. A single period ( . ) means the test passed. The following characters denote failure of certain tests: 5 - MD5 checksum S - file size L - symbolic link T - file modification time D - device U - user G - group M - mode (includes permissions and file type) ? - unreadable file If you see any output, use your best judgment to determine if you should remove or reinstall the package, or fix the problem in another way.

Commands:
-Vf /usr/bin/vim
-Va
-Vp foo-1.0-1.i386.rpm
17.2.2.2. Access Control Option fields also allow administrators to explicitly allow or deny hosts in a single rule by adding the allow or deny directive as the final option. For instance, the following two rules allow SSH connections from client-1.example.com , but deny connections from client-2.example.com : By allowing access control on a per-rule basis, the option field allows administrators to consolidate all access rules into a single file: either hosts.allow or hosts.deny . Some consider this an easier way of organizing access rules.

Commands:
sshd : client-1.example.com : allow sshd : client-2.example.com : deny
Chapter 1. Installation methods You can install OpenShift Container Platform on installer-provisioned or user-provisioned infrastructure. The default installation type uses installer-provisioned infrastructure, where the installation program provisions the underlying infrastructure for the cluster. You can also install OpenShift Container Platform on infrastructure that you provision. If you do not use infrastructure that the installation program provisions, you must manage and maintain the cluster resources yourself. See Installation process for more information about installer-provisioned and user-provisioned installation processes. 1.1. Installing a cluster on installer-provisioned infrastructure You can install a cluster on Azure Stack Hub infrastructure that is provisioned by the OpenShift Container Platform installation program, by using the following method: Installing a cluster : You can install OpenShift Container Platform on Azure Stack Hub infrastructure that is provisioned by the OpenShift Container Platform installation program. 1.2. Installing a cluster on user-provisioned infrastructure You can install a cluster on Azure Stack Hub infrastructure that you provision, by using the following method: Installing a cluster on Azure Stack Hub using ARM templates : You can install OpenShift Container Platform on Azure Stack Hub by using infrastructure that you provide. You can use the provided Azure Resource Manager (ARM) templates to assist with an installation. 1.3. Additional resources Configuring an Azure Stack Hub account

Commands:
Chapter 4. In-place Upgrades An in-place upgrade provides a way of upgrading a system to a new major release of Red Hat Enterprise Linux by replacing the existing operating system. For a list of currently supported upgrade paths, see Supported in-place upgrade paths for Red Hat Enterprise Linux . In-place upgrade from RHEL 6 to RHEL 7 To perform an in-place upgrade from RHEL 6 to RHEL 7, use the Preupgrade Assistant , a utility that checks the system for upgrade issues before running the actual upgrade, and that also provides additional scripts for the Red Hat Upgrade Tool . When you have solved all the problems reported by the Preupgrade Assistant , use the Red Hat Upgrade Tool to upgrade the system. For details regarding procedures and supported scenarios, see the Upgrading from RHEL 6 to RHEL 7 guide. Note that the Preupgrade Assistant and the Red Hat Upgrade Tool are available in the RHEL 6 Extras repository . If you are using CentOS Linux 6 or Oracle Linux 6, you can convert your operating system to RHEL 6 using the convert2rhel utility prior to upgrading to RHEL 7. For instructions, see How to convert from CentOS Linux or Oracle Linux to RHEL . In-place upgrade from RHEL 7 to RHEL 8 To perform an in-place upgrade from RHEL 7 to RHEL 8, use the Leapp utility. For instructions, see the Upgrading from RHEL 7 to RHEL 8 document. Major differences between RHEL 7 and RHEL 8 are listed in Considerations in adopting RHEL 8 . Note that the Leapp utility is available in the RHEL 7 Extras repository . If you are using CentOS Linux 7 or Oracle Linux 7, you can convert your operating system to RHEL 7 using the convert2rhel utility prior to upgrading to RHEL 8. For instructions, see How to convert from CentOS Linux or Oracle Linux to RHEL .

Commands:
Chapter 4. Upgrading Red Hat JBoss Web Server using this Service Pack To install this service pack: Go to the Software Downloads page for Red Hat JBoss Web Server 6.0 . Note You require a Red Hat subscription to access the Software Downloads page. Download the Red Hat JBoss Web Server 6.0 Service Pack 3 archive file that is appropriate to your platform. Extract the archive file to the Red Hat JBoss Web Server installation directory. If you have installed Red Hat JBoss Web Server from RPM packages on Red Hat Enterprise Linux, you can use the following yum command to upgrade to the latest service pack:

Commands:
yum upgrade
Support Red Hat Advanced Cluster Security for Kubernetes 4.6 Getting support for Red Hat Advanced Cluster Security for Kubernetes Red Hat OpenShift Documentation Team

Commands:
export ROX_PASSWORD= <rox_password> && export ROX_CENTRAL_ADDRESS= <address>:<port_number> 1
roxctl -e "USDROX_CENTRAL_ADDRESS" -p "USDROX_PASSWORD" central debug download-diagnostics
export ROX_API_TOKEN= <api_token>
roxctl -e "USDROX_CENTRAL_ADDRESS" central debug download-diagnostics
Chapter 2. Installing .NET image streams To install .NET image streams, use image stream definitions from s2i-dotnetcore with the OpenShift Client ( oc ) binary. Image streams can be installed from Linux, Mac, and Windows. You can define .NET image streams in the global openshift namespace or locally in a project namespace. Sufficient permissions are required to update the openshift namespace definitions. Procedure Install (or update) the image streams:

Commands:
oc apply [-n namespace ] -f https://raw.githubusercontent.com/redhat-developer/s2i-dotnetcore/main/dotnet_imagestreams.json
Chapter 23. Configuring screen rotation 23.1. Configuring screen rotation for a single user This procedure sets screen rotation for the current user. Procedure Go to the system menu , which is accessible from the top-right screen corner, and click the Settings icon. In the Settings Devices section, choose Displays . Configure the rotation using the Orientation field. Confirm your choice by clicking Apply . If you are satisfied with the new setup preview, click on Keep changes . The setting persists to your login. Additional resources For information about rotating the screen for all users on a system, see Configuring screen rotation for all users . 23.2. Configuring screen rotation for all users This procedure sets a default screen rotation for all users on a system and is suitable for mass deployment of homogenized display configuration. Procedure Prepare the preferable setup for a single user as in Configuring the screen rotation for a single user . Copy the transform section of the ~/.config/monitors.xml configuration file, which configures the screen rotation. An example portrait orientation: <?xml version="1.0" encoding="UTF-8"?> <transform> <rotation>left</rotation> <flipped>no</flipped> </transform> Paste the content in the /etc/xdg/monitors.xml file that stores system-wide configuration. Save the changes. The new setup takes effect for all the users the time they log in in the system. Additional resources Configuring screen rotation for a single user 23.3. Configuring screen rotation for multiple monitors In a multi-monitor setup, you can configure individual monitors with different screen rotation so that you can adjust monitor layout to your display needs. Procedure In the Settings application, go to Displays . Identify the monitor that you want to rotate from the visual representation of your connected monitors. Select the monitor whose orientation you want to configure. Select orientation: Landscape: Default orientation. Portrait Right: Rotates the screen by 90 degrees to the right. Portrait Left: Rotates the screen by 90 degrees to the left. Landscape (flipped): Rotates the screen by 180 degrees upside down. Click Apply to display preview. If you are satisfied with the preview, click Keep Changes . Alternatively, go back to the original orientation by clicking Revert Changes .

Commands:
<?xml version="1.0" encoding="UTF-8"?> <transform> <rotation>left</rotation> <flipped>no</flipped> </transform>
20.16.9.5. Generic Ethernet connection Provides a means for the administrator to execute an arbitrary script to connect the guest virtual machine's network to the LAN. The guest virtual machine will have a tun device created with a name of vnetN , which can also be overridden with the target element. After creating the tun device a shell script will be run which is expected to do whatever host physical machine network integration is required. By default this script is called /etc/qemu-ifup but can be overridden (refer to Section 20.16.9.11, "Overriding the target element" ). The generic Ethernet connection parameters are defined in the following part of the domain XML: ... <devices> <interface type='ethernet'/> ... <interface type='ethernet'> <target dev='vnet7'/> <script path='/etc/qemu-ifup-mynet'/> </interface> </devices> ... Figure 20.40. Devices - network interfaces- generic Ethernet connection

Commands:
<devices> <interface type='ethernet'/> <interface type='ethernet'> <target dev='vnet7'/> <script path='/etc/qemu-ifup-mynet'/> </interface> </devices>
Chapter 13. PodMetrics [metrics.k8s.io/v1beta1] Description PodMetrics sets resource usage metrics of a pod. Type object Required timestamp window containers 13.1. Specification Property Type Description apiVersion string APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources containers array Metrics for all containers are collected within the same time window. containers[] object ContainerMetrics sets resource usage metrics of a container. kind string Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds metadata ObjectMeta Standard object's metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata timestamp Time The following fields define time interval from which metrics were collected from the interval [Timestamp-Window, Timestamp]. window Duration 13.1.1. .containers Description Metrics for all containers are collected within the same time window. Type array 13.1.2. .containers[] Description ContainerMetrics sets resource usage metrics of a container. Type object Required name usage Property Type Description name string Container name corresponding to the one from pod.spec.containers. usage object (Quantity) The memory usage is the memory working set. 13.2. API endpoints The following API endpoints are available: /apis/metrics.k8s.io/v1beta1/pods GET : list objects of kind PodMetrics /apis/metrics.k8s.io/v1beta1/namespaces/{namespace}/pods GET : list objects of kind PodMetrics /apis/metrics.k8s.io/v1beta1/namespaces/{namespace}/pods/{name} GET : read the specified PodMetrics 13.2.1. /apis/metrics.k8s.io/v1beta1/pods HTTP method GET Description list objects of kind PodMetrics Table 13.1. HTTP responses HTTP code Reponse body 200 - OK PodMetricsList schema 13.2.2. /apis/metrics.k8s.io/v1beta1/namespaces/{namespace}/pods HTTP method GET Description list objects of kind PodMetrics Table 13.2. HTTP responses HTTP code Reponse body 200 - OK PodMetricsList schema 13.2.3. /apis/metrics.k8s.io/v1beta1/namespaces/{namespace}/pods/{name} Table 13.3. Global path parameters Parameter Type Description name string name of the PodMetrics HTTP method GET Description read the specified PodMetrics Table 13.4. HTTP responses HTTP code Reponse body 200 - OK PodMetrics schema

Commands: