mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 5. Requesting, Enrolling, and Managing Certificates Certificates are requested and used by end users. Although certificate enrollment and renewal are operations that are not limited to administrators, understanding the enrollment and renewal processes can make it easier for administrators to manage and create appropriate certificate profiles, as described in Section 3.2, "Setting up Certificate Profiles" , and to use fitting authentication methods (described in Chapter 10, Authentication for Enrolling Certificates ) for each certificate type. This chapter discusses requesting, receiving, and renewing certificates for use outside Certificate System. For information on requesting and renewing Certificate System subsystem certificates, see Chapter 17, Managing Subsystem Certificates . 5.1. About Enrolling and Renewing Certificates Enrollment is the process for requesting and receiving a certificate. The mechanics for the enrollment process are slightly different depending on the type of certificate, the method for generating its key pair, and the method for generating and approving the certificate itself. Whatever the specific method, certificate enrollment, at a high level, has the same basic steps: A certificate request (CSR) is generated. The certificate request is submitted to the CA. The request is verified by authenticating the entity which requested it and by confirming that the request meets the certificate profile rules which were used to submit it. The request is approved. The requesting party retrieves the new certificate. When the certificate reaches the end of its validity period, it can be renewed.

Commands:
14.12.7. Re-sizing Storage Volumes This command command re-sizes the capacity of the given volume, in bytes. The command requires --pool pool-or-uuid which is the name or UUID of the storage pool the volume is in. This command also requires vol-name-or-key-or-path is the name or key or path of the volume to re-size. The new capacity may create a sparse file unless the --allocate option is specified. Normally, capacity is the new size, but if --delta is present, then it is added to the existing size. Attempts to shrink the volume will fail unless the --shrink option is present. Note that capacity cannot be negative unless the --shrink option is provided and a negative sign is not necessary. capacity is a scaled integer which defaults to bytes if there is no suffix. Note too that this command is only safe for storage volumes not in use by an active guest. Refer to Section 14.5.17, "Using blockresize to Change the Size of a Domain Path" for live re-sizing.

Commands:
vol-resize --pool pool-or-uuid vol-name-or-path pool-or-uuid capacity --allocate --delta --shrink
Chapter 8. Updating and Migrating Identity Management 8.1. Updating Identity Management You can use the yum utility to update the Identity Management packages on the system. Warning Before installing an update, make sure you have applied all previously released errata relevant to the RHEL system. For more information, see the How do I apply package updates to my RHEL system? KCS article. Additionally, if a new minor Red Hat Enterprise Linux version is available, such as 7.3, yum upgrades the Identity Management server or client to this version. Note This section does not describe migrating Identity Management from Red Hat Enterprise Linux 6 to Red Hat Enterprise Linux 7. If you want to migrate, see Section 8.2, "Migrating Identity Management from Red Hat Enterprise Linux 6 to Version 7" . 8.1.1. Considerations for Updating Identity Management After you update the Identity Management packages on at least one server, all other servers in the topology receive the updated schema, even if you do not update their packages. This ensures that any new entries which use the new schema can be replicated among the other servers. Downgrading Identity Management packages is not supported. Important Do not run the yum downgrade command on any of the ipa-* packages. Red Hat recommends upgrading to the version only. For example, if you want to upgrade to Identity Management for Red Hat Enterprise Linux 7.4, we recommend upgrading from Identity Management for Red Hat Enterprise Linux 7.3. Upgrading from earlier versions can cause problems. 8.1.2. Using yum to Update the Identity Management Packages To update all Identity Management packages on a server or client: Warning When upgrading multiple Identity Management servers, wait at least 10 minutes between each upgrade. When two or more servers are upgraded simultaneously or with only short intervals between the upgrades, there is not enough time to replicate the post-upgrade data changes throughout the topology, which can result in conflicting replication events. Related Information For details on using the yum utility, see Yum in the System Administrator's Guide . Important Due to CVE-2014-3566 , the Secure Socket Layer version 3 (SSLv3) protocol needs to be disabled in the mod_nss module. You can ensure that by following these steps: Edit the /etc/httpd/conf.d/nss.conf file and set the NSSProtocol parameter to TLSv1.0 (for backward compatibility), TLSv1.1 , and TLSv1.2 . Restart the httpd service. Note that Identity Management in Red Hat Enterprise Linux 7 automatically performs the above steps when the yum update ipa-* command is launched to upgrade the main packages.

Commands:
yum update ipa-*
NSSProtocol TLSv1.0,TLSv1.1,TLSv1.2
systemctl restart httpd.service
Chapter 1. Backing up storage data from Amazon EBS Red Hat recommends that you back up the data on your persistent volume claims (PVCs) regularly. Backing up your data is particularly important before deleting a user and before uninstalling OpenShift AI, as all PVCs are deleted when OpenShift AI is uninstalled. Prerequisites You have credentials for OpenShift Cluster Manager ( https://console.redhat.com/openshift/ ). You have administrator access to the OpenShift Dedicated cluster. You have credentials for the Amazon Web Services (AWS) account that the OpenShift Dedicated cluster is deployed under. Procedure Determine the IDs of the persistent volumes (PVs) that you want to back up. In the OpenShift Dedicated web console, change into the Administrator perspective. Click Home Projects . Click the rhods-notebooks project. The Details page for the project opens. Click the PersistentVolumeClaims in the Inventory section. The PersistentVolumeClaims page opens. Note the ID of the persistent volume (PV) that you want to back up. Note The persistent volumes (PV) that you make a note of are required to identify the correct EBS volume to back up in your AWS instance. Locate the EBS volume containing the PVs that you want to back up. See Amazon Web Services documentation: Create Amazon EBS snapshots for more information. Log in to AWS ( https://aws.amazon.com ) and ensure that you are viewing the region that your OpenShift Dedicated cluster is deployed in. Click Services . Click Compute EC2 . Click Elastic Block Storage Volumes in the side navigation. The Volumes page opens. In the search bar, enter the ID of the persistent volume (PV) that you made a note of earlier. The Volumes page reloads to display the search results. Click on the volume shown and verify that any kubernetes.io/created-for/pvc/namespace tags contain the value rhods-notebooks , and any kubernetes.io/created-for/pvc/name tags match the name of the persistent volume that the EC2 volume is being used for, for example, jupyter-nb-user1-pvc . Back up the EBS volume that contains your persistent volume (PV). Right-click on the volume that you want to back up and select Create Snapshot from the list. The Create Snapshot page opens. Enter a Description for the volume. Click Create Snapshot . The snapshot of the volume is created. Click Close . Verification The snapshot that you created is visible on the Snapshots page in AWS. Additional resources Amazon Web Services documentation: Create Amazon EBS snapshots

Commands:
10.5. Programming Languages Ruby 2.0.0 Red Hat Enterprise Linux 7 provides the latest Ruby version, 2.0.0. The most notable of the changes between version 2.0.0 and 1.8.7 included in Red Hat Enterprise Linux 6 are the following: New interpreter, YARV (yet another Ruby VM), which significantly reduces loading times, especially for applications with large trees or files; New and faster "Lazy Sweep" garbage collector; Ruby now supports string encoding; Ruby now supports native threads instead of green threads. For more information about Ruby 2.0.0, consult the upstream pages of the project: https://www.ruby-lang.org/en/ . Python 2.7.5 Red Hat Enterprise Linux 7 includes Python 2.7.5, which is the latest Python 2.7 series release. This version contains many improvements in performance and provides forward compatibility with Python 3. The most notable of the changes in Python 2.7.5 are the following: An ordered dictionary type; A faster I/O module; Dictionary comprehensions and set comprehensions; The sysconfig module. For the full list of changes, see http://docs.python.org/dev/whatsnew/2.7.html Java 7 and Multiple JDKs Red Hat Enterprise Linux 7 features OpenJDK7 as the default Java Development Kit (JDK) and Java 7 as the default Java version. All Java 7 packages ( java-1.7.0-openjdk , java-1.7.0-oracle , java-1.7.1-ibm ) allow installation of multiple versions in parallel, similarly to the kernel. The ability of parallel installation allows users to try out multiple versions of the same JDK simultaneously, to tune performance and debug problems if needed. The precise JDK is selectable through /etc/alternatives/ as before. Important The Optional channel must be enabled in order to successfully install the java-1.7.1-ibm-jdbc or java-1.7.1-ibm-plugin packages from the Supplementary channel. The Optional channel contains packages that satisfy dependencies of the desired Java packages. Before installing packages from the Optional and Supplementary channels, see Scope of Coverage Details . Information on subscribing to the Optional and Supplementary channels can be found in the Red Hat Knowledgebase solution How to access Optional and Supplementary channels .

Commands:
Chapter 5. Asset execution options with Red Hat Process Automation Manager After you build and deploy your Red Hat Process Automation Manager project to KIE Server or other environment, you can execute the deployed assets for testing or for runtime consumption. You can also execute assets locally in addition to or instead of executing them after deployment. The following options are the main methods for Red Hat Process Automation Manager asset execution: Table 5.1. Asset execution options Execution option Description Documentation Execution in KIE Server If you deployed Red Hat Process Automation Manager project assets to KIE Server, you can use the KIE Server REST API or Java client API to execute and interact with the deployed assets. You can also use Business Central or the headless Process Automation Manager controller outside of Business Central to manage the configurations and KIE containers in the KIE Server instances associated with your deployed assets. For process definitions, you can use Business Central directly to execute process instances. Interacting with Red Hat Process Automation Manager using KIE APIs Execution in an embedded Java application If you deployed Red Hat Process Automation Manager project assets in your own Java virtual machine (JVM) environment, microservice, or application server, you can use custom APIs or application interactions with core KIE APIs (not KIE Server APIs) to execute assets in the embedded engine. KIE Public API Execution in a local environment for extended testing As part of your development cycle, you can execute assets locally to ensure that the assets you have created in Red Hat Process Automation Manager function as intended. You can use local execution in addition to or instead of executing assets after deployment. "Executing rules" in Designing a decision service using DRL rules Smart Router (KIE Server router) Depending on your deployment and execution environment, you can use a Smart Router to aggregate multiple independent KIE Server instances as though they are a single server. Smart Router is a single endpoint that can receive calls from client applications to any of your services and route each call automatically to the KIE Server that runs the service. For more information about Smart Router, see Installing and configuring Red Hat Process Automation Manager in a Red Hat JBoss EAP clustered environment .

Commands:
7.6. Overview of Bonding Modes and the Required Settings on the Switch The following table describes the required configuration that you must apply to the upstream switch depending on the bonding mode: Table 7.1. Switch Configuration Settings Depending on the Bonding Modes Bonding Mode Configuration on the Switch 0 - balance-rr Requires static Etherchannel enabled (not LACP-negotiated) 1 - active-backup Requires autonomous ports 2 - balance-xor Requires static Etherchannel enabled (not LACP-negotiated) 3 - broadcast Requires static Etherchannel enabled (not LACP-negotiated) 4 - 802.3ad Requires LACP-negotiated Etherchannel enabled 5 - balance-tlb Requires autonomous ports 6 - balance-alb Requires autonomous ports For configuring these settings on your switch, see the switch documentation.

Commands:
20.21. Creating a Guest Virtual Machine from a Configuration File Guest virtual machines can be created from XML configuration files. You can copy existing XML from previously created guest virtual machines or use the virsh dumpxml command. Example 20.49. How to create a guest virtual machine from an XML file The following example creates a new virtual machine from the existing guest1.xml configuration file. You need to have this file before beginning. You can retrieve the file using the virsh dumpxml command. See Example 20.48, "How to retrieve the XML file for a guest virtual machine" for instructions. # virsh create guest1.xml

Commands:
8.9. pNFS Support for Parallel NFS (pNFS) as part of the NFS v4.1 standard is available as of Red Hat Enterprise Linux 6.4. The pNFS architecture improves the scalability of NFS, with possible improvements to performance. That is, when a server implements pNFS as well, a client is able to access data through multiple servers concurrently. It supports three storage protocols or layouts: files, objects, and blocks. Note The protocol allows for three possible pNFS layout types: files, objects, and blocks. While the Red Hat Enterprise Linux 6.4 client only supported the files layout type, Red Hat Enterprise Linux 7 supports the files layout type, with objects and blocks layout types being included as a technology preview. pNFS Flex Files Flexible Files is a new layout for pNFS that enables the aggregation of standalone NFSv3 and NFSv4 servers into a scale out name space. The Flex Files feature is part of the NFSv4.2 standard as described in the RFC 7862 specification. Red Hat Enterprise Linux can mount NFS shares from Flex Files servers since Red Hat Enterprise Linux 7.4. Mounting pNFS Shares To enable pNFS functionality, mount shares from a pNFS-enabled server with NFS version 4.1 or later: After the server is pNFS-enabled, the nfs_layout_nfsv41_files kernel is automatically loaded on the first mount. The mount entry in the output should contain minorversion=1 . Use the following command to verify the module was loaded: To mount an NFS share with the Flex Files feature from a server that supports Flex Files, use NFS version 4.2 or later: Verify that the nfs_layout_flexfiles module has been loaded: Additional Resources For more information on pNFS, refer to: http://www.pnfs.com .

Commands:
mount -t nfs -o v4.1 server:/remote-export /local-directory
lsmod | grep nfs_layout_nfsv41_files
mount -t nfs -o v4.2 server:/remote-export /local-directory
lsmod | grep nfs_layout_flexfiles
Chapter 1. Workflow for deploying a single hyperconverged host Check requirements. Verify that your planned deployment meets support requirements: Requirements , and fill in the installation checklist so that you can refer to it during the deployment process. Install operating systems. Install an operating system on each physical machine that will act as a hyperconverged host: Installing hyperconverged hosts . (Optional) Install an operating system on each physical or virtual machine that will act as an Network-Bound Disk Encryption (NBDE) key server: Installing NBDE key servers . Modify firewall rules for additional software. (Optional) Modify firewall rules for disk encryption: Section 5.1, "Modifying firewall rules for disk encryption" . Configure authentication between hyperconverged hosts. Configure key-based SSH authentication without a password to enable automated configuration of the hosts: Configure key-based SSH without a password . (Optional) Configure disk encryption. Configure NBDE key servers . Configure hyperconverged hosts as NBDE clients . Configure the hyperconverged node. Browse to the Web Console and deploy a single hyperconverged node .

Commands:
3.9. Relatime Drive Access Optimization The POSIX standard requires that operating systems maintain file system metadata that record when each file was last accessed. This timestamp is called atime , and maintaining it requires a constant series of write operations to storage. These writes keep storage devices and their links busy and powered up. Since few applications make use of the atime data, this storage device activity wastes power. Significantly, the write to storage would occur even if the file was not read from storage, but from cache. For some time, the Linux kernel has supported a noatime option for mount and would not write atime data to file systems mounted with this option. However, simply turning off this feature is problematic because some applications rely on atime data and will fail if it is not available. The kernel used in Red Hat Enterprise Linux 6 supports another alternative - relatime . relatime maintains atime data, but not for each time that a file is accessed. With this option enabled, atime data is written to the disk only if the file has been modified since the atime data was last updated ( mtime ), or if the file was last accessed more than a certain amount of time ago (by default, one day). By default, all file systems are now mounted with relatime enabled. You can suppress it for any particular file system by mounting that file system with the norelatime option.

Commands:
4.7.4. Testing the Fence Configuration As of Red Hat Enterprise Linux Release 6.4, you can test the fence configuration for each node in a cluster with the fence_check utility. The following example shows the output of a successful execution of this command. For information on this utility, see the fence_check (8) man page.

Commands:
fence_check fence_check run at Wed Jul 23 09:13:57 CDT 2014 pid: 4769 Testing host-098 method 1: success Testing host-099 method 1: success Testing host-100 method 1: success
8.4.3. Remote Node Resource Options You configure a remote node as a cluster resource with the pcs resource create command, specifying ocf:pacemaker:remote as the resource type. Table 8.5, "Resource Options for Remote Nodes" describes the resource options you can configure for a remote resource. Table 8.5. Resource Options for Remote Nodes Field Default Description reconnect_interval 0 Time in seconds to wait before attempting to reconnect to a remote node after an active connection to the remote node has been severed. This wait is recurring. If reconnect fails after the wait period, a new reconnect attempt will be made after observing the wait time. When this option is in use, Pacemaker will keep attempting to reach out and connect to the remote node indefinitely after each wait interval. server Server location to connect to. This can be an IP address or host name. port TCP port to connect to.

Commands:
3.3.8. Cache Volumes As of the Red Hat Enterprise Linux 6.7 release, LVM supports the use of fast block devices (such as SSD drives) as write-back or write-though caches for larger slower block devices. Users can create cache logical volumes to improve the performance of their existing logical volumes or create new cache logical volumes composed of a small and fast device coupled with a large and slow device. For information on creating LVM cache volumes, see Section 5.4.7, "Creating LVM Cache Logical Volumes" .

Commands:
3.5. Tracking Tag History The ETL Service collects tag information as displayed in the Administration Portal every minute and stores this data in the tags historical tables. The ETL Service tracks five types of changes: A tag is created in the Administration Portal - the ETL Service copies the tag details, position in the tag tree and relation to other objects in the tag tree. A entity is attached to the tag tree in the Administration Portal - the ETL Service replicates the addition to the ovirt_engine_history database as a new entry. A tag is updated - the ETL Service replicates the change of tag details to the ovirt_engine_history database as a new entry. An entity or tag branch is removed from the Administration Portal - the ovirt_engine_history database flags the corresponding tag and relations as removed in new entries. Removed tags and relations are only flagged as removed or detached. A tag branch is moved - the corresponding tag and relations are updated as new entries. Moved tags and relations are only flagged as updated.

Commands:
Chapter 22. Write Barriers A write barrier is a kernel mechanism used to ensure that file system metadata is correctly written and ordered on persistent storage, even when storage devices with volatile write caches lose power. File systems with write barriers enabled also ensure that data transmitted via fsync() is persistent throughout a power loss. Enabling write barriers incurs a substantial performance penalty for some applications. Specifically, applications that use fsync() heavily or create and delete many small files will likely run much slower. 22.1. Importance of Write Barriers File systems take great care to safely update metadata, ensuring consistency. Journalled file systems bundle metadata updates into transactions and send them to persistent storage in the following manner: First, the file system sends the body of the transaction to the storage device. Then, the file system sends a commit block. If the transaction and its corresponding commit block are written to disk, the file system assumes that the transaction will survive any power failure. However, file system integrity during power failure becomes more complex for storage devices with extra caches. Storage target devices like local S-ATA or SAS drives may have write caches ranging from 32MB to 64MB in size (with modern drives). Hardware RAID controllers often contain internal write caches. Further, high end arrays, like those from NetApp, IBM, Hitachi and EMC (among others), also have large caches. Storage devices with write caches report I/O as "complete" when the data is in cache; if the cache loses power, it loses its data as well. Worse, as the cache de-stages to persistent storage, it may change the original metadata ordering. When this occurs, the commit block may be present on disk without having the complete, associated transaction in place. As a result, the journal may replay these uninitialized transaction blocks into the file system during post-power-loss recovery; this will cause data inconsistency and corruption. How Write Barriers Work Write barriers are implemented in the Linux kernel via storage write cache flushes before and after the I/O, which is order-critical . After the transaction is written, the storage cache is flushed, the commit block is written, and the cache is flushed again. This ensures that: The disk contains all the data. No re-ordering has occurred. With barriers enabled, an fsync() call will also issue a storage cache flush. This guarantees that file data is persistent on disk even if power loss occurs shortly after fsync() returns.

Commands: