mtpti5iD/redhat-docs_dataset huggingface dataset:
9.4. NFS Client Configuration Files NFS shares are mounted on the client side using the mount command. The format of the command is as follows: Replace <nfs-type> with either nfs for NFSv2 or NFSv3 servers, or nfs4 for NFSv4 servers. Replace <options> with a comma separated list of options for the NFS file system (refer to Section 9.4.3, "Common NFS Mount Options" for details). Replace <host> with the remote host, </remote/export> with the remote directory being mounted, and </local/directory> with the local directory where the remote file system is to be mounted. Refer to the mount man page for more details. If accessing an NFS share by manually issuing the mount command, the file system must be remounted manually after the system is rebooted. Red Hat Enterprise Linux offers two methods for mounting remote file systems automatically at boot time: the /etc/fstab file or the autofs service. 9.4.1. /etc/fstab The /etc/fstab file is referenced by the netfs service at boot time, so lines referencing NFS shares have the same effect as manually typing the mount command during the boot process. A sample /etc/fstab line to mount an NFS export looks like the following example: Replace <server> with the hostname, IP address, or fully qualified domain name of the server exporting the file system. Replace </remote/export> with the path to the exported directory. Replace </local/directory> with the local file system on which the exported directory is mounted. This mount point must exist before /etc/fstab is read or the mount fails. Replace <nfs-type> with either nfs for NFSv2 or NFSv3 servers, or nfs4 for NFSv4 servers. Replace <options> with a comma separated list of options for the NFS file system (refer to Section 9.4.3, "Common NFS Mount Options" for details). Refer to the fstab man page for additional information.

Commands:
mount -t <nfs-type> -o <options> <host> : </remote/export> </local/directory>
<server> : </remote/export> </local/directory> <nfs-type> <options> 0 0
3.2. Guest Security Recommended Practices All of the recommended practices for securing a Red Hat Enterprise Linux system documented in the Red Hat Enterprise Linux Security Guide apply to conventional, non-virtualized systems as well as systems installed as a virtualized guest. However, there are a few security practices which are of critical importance when running guests in a virtualized environment: With all management of the guest likely taking place remotely, ensure that the management of the system takes place only over secured network channels. Tools such as SSH and network protocols such as TLS or SSL provide both authentication and data encryption to ensure that only approved administrators can manage the system remotely. Some virtualization technologies use special guest agents or drivers to enable some virtualization specific features. Ensure that these agents and applications are secured using the standard Red Hat Enterprise Linux security features, such as SELinux. In virtualized environments there is a greater risk of sensitive data being accessed outside the protection boundaries of the guest system. Protect stored sensitive data using encryption tools such as dm-crypt and GnuPG ; although special care needs to be taken to ensure the confidentiality of the encryption keys.

Commands:
3.2.2. Consumers of Processing Power There are two main consumers of processing power: Applications The operating system itself 3.2.2.1. Applications The most obvious consumers of processing power are the applications and programs you want the computer to run for you. From a spreadsheet to a database, applications are the reason you have a computer. A single-CPU system can only do one thing at any given time. Therefore, if your application is running, everything else on the system is not. And the opposite is, of course, true -- if something other than your application is running, then your application is doing nothing. But how is it that many different applications can seemingly run at once under a modern operating system? The answer is that these are multitasking operating systems. In other words, they create the illusion that many different things are going on simultaneously when in fact that is not possible. The trick is to give each process a fraction of a second's worth of time running on the CPU before giving the CPU to another process for the fraction of a second. If these context switches happen frequently enough, the illusion of multiple applications running simultaneously is achieved. Of course, applications do other things than manipulate data using the CPU. They may wait for user input as well as performing I/O to devices such as disk drives and graphics displays. When these events take place, the application no longer needs the CPU. At these times, the CPU can be used for other processes running other applications without slowing the waiting application at all. In addition, the CPU can be used by another consumer of processing power: the operating system itself.

Commands:
Chapter 10. Red Hat Enterprise Linux Atomic Host 7.7.1 10.1. Atomic Host OStree update : New Tree Version: 7.7.1 (hash: 90573ae0c7b166a0e84a2d2cc836fb7b7a5ba6e9a6a3ad29a651b023aadd85c1) Changes since Tree Version 7.7.0 (hash: 9aee8a02a3ff1cc680fdc3243f537cbc285629f6744e2ea08b4c4f05b7d02127) 10.2. Extras Updated packages : atomic-1.22.1-29.gitb507039.el7 10.2.1. Container Images Updated : Red Hat Enterprise Linux 7 Init Container Image (rhel7/rhel7-init) Red Hat Enterprise Linux 7.7 Container Image (rhel7.7, rhel7, rhel7/rhel, rhel) Red Hat Enterprise Linux Atomic Identity Management Server Container Image (rhel7/ipa-server) Red Hat Enterprise Linux Atomic Image (rhel-atomic, rhel7-atomic, rhel7/rhel-atomic) Red Hat Enterprise Linux Atomic Net-SNMP Container Image (rhel7/net-snmp) Red Hat Enterprise Linux Atomic OpenSCAP Container Image (rhel7/openscap) Red Hat Enterprise Linux Atomic SSSD Container Image (rhel7/sssd) Red Hat Enterprise Linux Atomic Support Tools Container Image (rhel7/support-tools) Red Hat Enterprise Linux Atomic Tools Container Image (rhel7/rhel-tools) Red Hat Enterprise Linux Atomic cockpit-ws Container Image (rhel7/cockpit-ws) Red Hat Enterprise Linux Atomic etcd Container Image (rhel7/etcd) Red Hat Enterprise Linux Atomic flannel Container Image (rhel7/flannel) Red Hat Enterprise Linux Atomic open-vm-tools Container Image (rhel7/open-vm-tools) Red Hat Enterprise Linux Atomic rsyslog Container Image (rhel7/rsyslog) Red Hat Enterprise Linux Atomic sadc Container Image (rhel7/sadc) Red Hat Universal Base Image 7 Container Image (rhel7/ubi7) Red Hat Universal Base Image 7 Init Container Image (rhel7/ubi7-init) Red Hat Universal Base Image 7 Minimal Container Image (rhel7/ubi7-minimal)

Commands:
Chapter 2. Important Changes to External Kernel Parameters This chapter provides system administrators with a summary of significant changes in the kernel shipped with Red Hat Enterprise Linux 6.6. These changes include added or updated procfs entries, sysfs default values, boot parameters, kernel configuration options, or any noticeable behavior changes. MemAvailable Using this parameter provides an estimate of how much memory is available for starting new applications without swapping. However, unlike the data provided by the Cache or Free fields, MemAvailable takes into account page cache and also that not all reclaimable slab will be reclaimable due to items being in use. overcommit_kbytes This parameter allows the user to determine the specific number of kilobytes of physicial RAM that a committed address space is not permitted to exceed when the overcommit_memory parameter is set to "2". Therefore, overcommit_bytes works as the counterpart to the overcommit_ratio, and setting one automatically disables the other. meminfo_legacy_layout Setting this parameter to a non-zero value will disable the reporting of new entries introduced to /proc/meminfo and the kernel will keep the legacy (2.6.32) layout when reporting data through that interface. Note that the default value is "1". This parameter is available to Red Hat Enterprise Linux 6 only, for reasons of retroactive compatibility. disable_cpu_apicid This parameter allows the kdump kernel to disable BSP during boot and then to successfully boot up with multiple processors. This resolves the problem of lack of available interrupt vectors for systems with a high number of devices and ensures that kdump can now successfully capture a core dump on these systems. earlyprintk Previously usable only for VGA hardware, this parameter now supports the "efi" value, which allows users to debug early booting issues on EFI hardware. edac_report By setting the value of this parameter to "on" or "off", the user can enable or disable the Error Detection and Correction (EDAC) module to report hardware events. It is also possible to make EDAC impossible to be overridden by a higher-priority module by using the "force" value. The default value of this parameter is "on". intel_iommu This parameter enables the user to turn off the support of large pages, using the "sp_off" value. By default, however, large pages are supported as long as the Intel input/output management unit (IOMMU) meets the requirements. nfs.recover_lost_locks Previously, NFSv4 clients could resume expired or lost file locks. Nevertheless, this sometimes resulted in file corruption if the file was modified in the meantime. Therefore, recovering these locks has been disabled, but can be enabled by changing the value of the above parameter from "0" to "1". Note, however, that doing so still carries a risk of data corruption.

Commands:
Chapter 4. The Migration Toolkit for Applications tools You can use the following Migration Toolkit for Applications (MTA) tools for assistance in the various stages of your migration and modernization efforts: User interface Migration Toolkit for Applications Operator CLI IDE add-ons for the following applications: Eclipse Visual Studio Code, Visual Studio Codespaces, and Eclipse Che IntelliJ IDEA Maven plugin Review the details of each tool to determine which tool is suitable for your project. 4.1. The MTA Operator By using the Migration Toolkit for Applications Operator, you can install the user interface on OpenShift Container Platform versions 4.17, 4.16, 4.15. For more information about the prerequisites for the MTA Operator installation, see OpenShift Operator Life Cycles . 4.2. The MTA user interface By using the user interface for the Migration Toolkit for Applications, you can perform the following tasks: Assess the risks involved in containerizing an application for hybrid cloud environments on Red Hat OpenShift. Analyze the changes that must be made in the code of an application to containerize the application. 4.3. The MTA CLI The CLI is a command-line tool in the Migration Toolkit for Applications that you can use to assess and prioritize migration and modernization efforts for applications. It provides numerous reports that highlight the analysis without using the other tools. The CLI includes a wide array of customization options. By using the CLI, you can tune MTA analysis options or integrate with external automation tools. For more information about using the CLI, see CLI Guide . 4.4. The MTA IDE add-ons You can migrate and modernize applications by using the Migration Toolkit for Applications (MTA) add-ons for the following applications: Eclipse Visual Studio Code, Visual Studio Codespaces, and Eclipse Che IntelliJ IDEA, both the Community and Ultimate versions You can use these add-on to perform the following tasks: Analyze your projects by using customizable sets of rules. Mark issues in the source code. Fix the issues by using the provided guidance. Use the automatic code replacement, if possible.

Commands:
5.228. pam_pkcs11 5.228.1. RHBA-2012:0972 - pam_pkcs11 bug fix update Updated pam_pkcs11 packages which fix a bug are now available for Red Hat Enterprise Linux 6. The pam_pkcs11 package allows X.509 certificate-based user authentication. It provides access to the certificate and its dedicated private key with an appropriate Public Key Cryptographic Standards #11 (PKCS#11) module. Bug Fix BZ# 756917 When remotely logged into a system with smart card log-in turned on, users saw the following unnecessary error message when trying to use su: The user was still able to use su despite this message. With this update the message is logged but no longer displayed. All users of pam_pkcs11 are advised to upgrade to these updated packages, which fix this bug.

Commands:
ERROR:pam_pkcs11.c:224: Remote login (from localhost:13.0) is not (yet) supported
31.4. Unloading a Module You can unload a kernel module by running modprobe -r <module_name> as root. For example, assuming that the wacom module is already loaded into the kernel, you can unload it by running: However, this command will fail if a process is using: the wacom module, a module that wacom directly depends on, or, any module that wacom -through the dependency tree-depends on indirectly. See Section 31.1, "Listing Currently-Loaded Modules" for more information about using lsmod to obtain the names of the modules which are preventing you from unloading a certain module. For example, if you want to unload the firewire_ohci module (because you believe there is a bug in it that is affecting system stability, for example), your terminal session might look similar to this: You have figured out the dependency tree (which does not branch in this example) for the loaded Firewire modules: firewire_ohci depends on firewire_core , which itself depends on crc-itu-t . You can unload firewire_ohci using the modprobe -v -r <module_name> command, where -r is short for --remove and -v for --verbose : The output shows that modules are unloaded in the reverse order that they are loaded, given that no processes depend on any of the modules being unloaded. Important Although the rmmod command can be used to unload kernel modules, it is recommended to use modprobe -r instead.

Commands:
~]# modprobe -r wacom
~]# modinfo -F depends firewire_ohci depends: firewire-core ~]# modinfo -F depends firewire_core depends: crc-itu-t ~]# modinfo -F depends crc-itu-t depends:
~]# modprobe -r -v firewire_ohci rmmod /lib/modules/2.6.32-71.el6.x86_64/kernel/drivers/firewire/firewire-ohci.ko rmmod /lib/modules/2.6.32-71.el6.x86_64/kernel/drivers/firewire/firewire-core.ko rmmod /lib/modules/2.6.32-71.el6.x86_64/kernel/lib/crc-itu-t.ko
Chapter 2. An overview of OpenShift Data Foundation architecture Red Hat OpenShift Data Foundation provides services for, and can run internally from Red Hat OpenShift Container Platform. Red Hat OpenShift Data Foundation architecture Red Hat OpenShift Data Foundation supports deployment into Red Hat OpenShift Container Platform clusters deployed on Installer Provisioned Infrastructure or User Provisioned Infrastructure. For details about these two approaches, see OpenShift Container Platform - Installation process . To know more about interoperability of components for the Red Hat OpenShift Data Foundation and Red Hat OpenShift Container Platform, see the interoperability matrix . For information about the architecture and lifecycle of OpenShift Container Platform, see OpenShift Container Platform architecture .

Commands:
29.8. OProfile Support for Java OProfile allows you to profile dynamically compiled code (also known as "just-in-time" or JIT code) of the Java Virtual Machine (JVM). OProfile in Red Hat Enterprise Linux 6 includes built-in support for the JVM Tools Interface (JVMTI) agent library, which supports Java 1.5 and higher. 29.8.1. Profiling Java Code To profile JIT code from the Java Virtual Machine with the JVMTI agent, add the following to the JVM startup parameters: Note The oprofile-jit package must be installed on the system in order to profile JIT code with OProfile. To learn more about Java support in OProfile, see the OProfile Manual, which is linked from Section 29.11, "Additional Resources" .

Commands:
-agentlib:jvmti_oprofile
Chapter 31. Set Up Cross-Datacenter Replication In Red Hat JBoss Data Grid, Cross-Datacenter Replication allows the administrator to create data backups in multiple clusters. These clusters can be at the same physical location or different ones. JBoss Data Grid's Cross-Site Replication implementation is based on JGroups' RELAY2 protocol. Cross-Datacenter Replication ensures data redundancy across clusters. Ideally, each of these clusters must be in a different physical location than the others. Report a bug 31.1. Cross-Datacenter Replication Operations Red Hat JBoss Data Grid's Cross-Datacenter Replication operation is explained through the use of an example, as follows: Example 31.1. Cross-Datacenter Replication Example Figure 31.1. Cross-Datacenter Replication Example Three sites are configured in this example: LON , NYC and SFO . Each site hosts a running JBoss Data Grid cluster made up of three to four physical nodes. The Users cache is active in all three sites - LON , NYC and SFO . Changes to the Users cache at the any one of these sites will be replicated to the other two as long as the cache defines the other two sites as its backups through configuration. The Orders cache, however, is only available locally at the LON site because it is not replicated to the other sites. The Users cache can use different replication mechanisms each site. For example, it can back up data synchronously to SFO and asynchronously to NYC and LON . The Users cache can also have a different configuration from one site to another. For example, it can be configured as a distributed cache with numOwners set to 2 in the LON site, as a replicated cache in the NYC site and as a distributed cache with numOwners set to 1 in the SFO site. JGroups is used for communication within each site as well as inter-site communication. Specifically, a JGroups protocol called RELAY2 facilitates communication between sites. For more information, see Section F.4, "About RELAY2" Report a bug

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

Commands:
dnf install <package_name>
dnf install <path_to_download_package>
Chapter 7. Viewing the status of the QuayRegistry object Lifecycle observability for a given Red Hat Quay deployment is reported in the status section of the corresponding QuayRegistry object. The Red Hat Quay Operator constantly updates this section, and this should be the first place to look for any problems or state changes in Red Hat Quay or its managed dependencies. 7.1. Viewing the registry endpoint Once Red Hat Quay is ready to be used, the status.registryEndpoint field will be populated with the publicly available hostname of the registry. 7.2. Viewing the version of Red Hat Quay in use The current version of Red Hat Quay that is running will be reported in status.currentVersion . 7.3. Viewing the conditions of your Red Hat Quay deployment Certain conditions will be reported in status.conditions .

Commands:
Chapter 9. What to do ? This is only the beginning of what Red Hat Ceph Storage can do to help you meet the challenging storage demands of the modern data center. Here are links to more information on a variety of topics: Benchmarking performance and accessing performance counters, see the Benchmarking Performance chapter in the Administration Guide for Red Hat Ceph Storage 4. Creating and managing snapshots, see the Snapshots chapter in the Block Device Guide for Red Hat Ceph Storage 4. Expanding the Red Hat Ceph Storage cluster, see the Managing the storage cluster size chapter in the Operations Guide for Red Hat Ceph Storage 4. Mirroring Ceph Block Devices, see the Block Device Mirroring chapter in the Block Device Guide for Red Hat Ceph Storage 4. Process management, see the Process Management chapter in the Administration Guide for Red Hat Ceph Storage 4. Tunable parameters, see the Configuration Guide for Red Hat Ceph Storage 4. Using Ceph as the back end storage for OpenStack, see the Back-ends section in the Storage Guide for Red Hat OpenStack Platform. Monitor the health and capacity of the Red Hat Ceph Storage cluster with the Ceph Dashboard. See the Dashboard Guide for additional details.

Commands:
13.3.2. PHP4, LDAP, and the Apache HTTP Server Red Hat Enterprise Linux includes a package containing an LDAP module for the PHP server-side scripting language. The php-ldap package adds LDAP support to the PHP4 HTML-embedded scripting language via the /usr/lib/php4/ldap.so module. This module allows PHP4 scripts to access information stored in an LDAP directory. Red Hat Enterprise Linux ships with the mod_authz_ldap module for the Apache HTTP Server. This module uses the short form of the distinguished name for a subject and the issuer of the client SSL certificate to determine the distinguished name of the user within an LDAP directory. It is also capable of authorizing users based on attributes of that user's LDAP directory entry, determining access to assets based on the user and group privileges of the asset, and denying access for users with expired passwords. The mod_ssl module is required when using the mod_authz_ldap module. Important The mod_authz_ldap module does not authenticate a user to an LDAP directory using an encrypted password hash. This functionality is provided by the experimental mod_auth_ldap module, which is not included with Red Hat Enterprise Linux. Refer to the Apache Software Foundation website online at http://www.apache.org/ for details on the status of this module.

Commands: