mtpti5iD/redhat-docs_dataset huggingface dataset:
2.3. The /proc Virtual File System Unlike most file systems, /proc contains neither text nor binary files. Instead, it houses virtual files ; as such, /proc is normally referred to as a virtual file system. These virtual files are typically zero bytes in size, even if they contain a large amount of information. The /proc file system is not used for storage. Its main purpose is to provide a file-based interface to hardware, memory, running processes, and other system components. Real-time information can be retrieved on many system components by viewing the corresponding /proc file. Some of the files within /proc can also be manipulated (by both users and applications) to configure the kernel. The following /proc files are relevant in managing and monitoring system storage: /proc/devices Displays various character and block devices that are currently configured. /proc/filesystems Lists all file system types currently supported by the kernel. /proc/mdstat Contains current information on multiple-disk or RAID configurations on the system, if they exist. /proc/mounts Lists all mounts currently used by the system. /proc/partitions Contains partition block allocation information. For more information about the /proc file system, refer to the Red Hat Enterprise Linux 6 Deployment Guide .

Commands:
Chapter 60. Servers and Services ReaR creates two ISO images instead of one In ReaR, the OUTPUT_URL directive enables specifying location for the ISO image containing the rescue system. Currently, with this directive set, ReaR creates two copies of the ISO image: one in the specified directory and one in the /var/lib/rear/output/ default directory. This requires additional space for the image. This is especially important if a full-system backup is included into the ISO image (using the BACKUP=NETFS and BACKUP_URL=iso:///backup/ configuration). To work around this behavior, delete the extra ISO image once ReaR has finished working or, to avoid having a period of time with double storage consumption, create the image in the default directory and then move it to the desired location manually. There is a request for enhancement to change this behavior and make ReaR create only one copy of the ISO image. (BZ#1320552) The default value of first_valid_uid in dovecot has changed In Red Hat Enterprise Linux 7, the default configuration of first_valid_uid in dovecot was changed to 1000 to match the system wide configuration specified as UID_MIN in the /etc/login.defs file. If a system has UID_MIN manually changed to 500 and is relying on dovecot default value, dovecot will not serve users with IDs lower than first_valid_uid . As a consequence, if you have regular users with id less than 1000 , you have to update first_valid_uid . After you do this, dovecot will work as expected. (BZ# 1280433 )

Commands:
B.89.2. RHBA-2010:0852 - sssd bug fix update An updated sssd package that addresses group assignment and multilib issues is now available for Red Hat Enterprise Linux 6. The System Security Services Daemon (SSSD) provides a set of daemons to manage access to remote directories and authentication mechanisms. It provides an NSS and PAM interface toward the system and a pluggable backend system to connect to multiple different account sources. It is also the basis to provide client auditing and policy services for projects like FreeIPA. Bug Fixes BZ# 637070 Previously, Kerberos applications running on the secondary architecture of a multilib platform (e.g. i686 on x86_64) would not be able to identify the Kerberos server for authentication. With this update, the Kerberos locator plugin is located in the sssd-client package to allow installation of both the 32-bit and 64-bit versions on 64-bit systems. BZ# 642412 Previously, users would not always be assigned to all initgroups for which they were a member in LDAP. This could cause several issues related to group-based permissions. With this update, the initgroups() call always returns all groups for the specified user. BZ# 649312 Previously, SSSD could remove legitimate groups that were only identified as a user's primary group when the cache cleanup routine ran. This could cause issues with group-based access control permissions such as access.conf and sudoers. With this update, SSSD checks also whether there are users who have this group as their primary group ID. All SSSD users are advised to upgrade to these updated packages, which fix these bugs.

Commands:
8.24. crash-gcore-command 8.24.1. RHBA-2013:1720 - crash-gcore-command bug fix Updated crash-gcore-command packages that fix one bug are now available for Red Hat Enterprise Linux 6. The crash-gcore-command packages contain an extension module for the crash utility that adds a "gcore" command which can create a core dump file of a user-space task that was running in a kernel dumpfile. Bug Fix BZ# 890232 Due to a backported madvise/MADV_DONTDUMP change in the Red Hat Enterprise Linux 6 kernel, VDSO (Virtual Dynamically linked Shared Objects) and vsyscall pages were missing in the generated process core dump. With this update, VDSO and vsyscall pages are always contained in the generated process core dump. Users of crash-gcore-command are advised to upgrade to these updated packages, which fix this bug.

Commands:
Chapter 1. Overview of alt-java Red Hat packages contain a mitigation for the SSB vulnerability in the form of a patch for the java binary. This patch disables an optimization present in x86-64 (Intel and AMD) processors. Disabling that optimization reduces the risk of kernel side-channel attacks, but also reduces CPU performance. Since the patch reduces performance, it has been removed from the java launcher. A new binary alt-java is now available. From the January 2021 Critical Patch Update release (1.8.0 282.b08, 11.0.10.9) onwards, the alt-java binary is included in Red Hat build of OpenJDK 11 and Red Hat build of OpenJDK 11 GA RPM packages. Additional resources For more information about the performance impact of SSB mitigation, see Kernel Side-Channel Attack using Speculative Store Bypass - CVE-2018-3639 on the Red Hat Customer Portal For more information about the java binary patch, see RH1566890 in the Red Hat Bugzilla documentation.

Commands:
8.181. rhnlib 8.181.1. RHBA-2013:1085 - rhnlib bug fix and enhancement update Updated rhnlib packages that fix one bug are now available. The rhnlib packages contain Python libraries developed specifically for interfacing with the Red Hat Network. Bug Fix BZ#949650 The RHN Proxy did not work properly if separated from a parent by a slow enough network. Consequently, users who attempted to download larger repodata files and RPMs experienced timeouts. This update changes both RHN Proxy and Red Hat Enterprise Linux RHN Client to allow all communications to obey a configured timeout value for connections. Users of rhnlib are advised to upgrade to these updated packages, which fix this bug.

Commands:
Part IV. Activating and opening the subscriptions service After you complete the steps to set up the environment for the subscriptions service, you can go to console.redhat.com to request the subscriptions service activation. After activation and the initial data collection cycle, you can open the subscriptions service and begin viewing usage data. Do these steps To find out if the subscriptions service activation is needed, see the following information: Determining whether manual activation of the subscriptions service is necessary To log in to console.redhat.com and activate the subscriptions service, see the following information: Activating the subscriptions service To log in to console.redhat.com and open the subscriptions service after activation, see the following information: Logging in to the subscriptions service If you cannot activate or log in to the subscriptions service, see the following information: Verifying access to the subscriptions service

Commands:
Chapter 2. Image Registry Operator in Red Hat OpenShift Service on AWS 2.1. Image Registry on Red Hat OpenShift Service on AWS The Image Registry Operator installs a single instance of the OpenShift image registry, and manages all registry configuration, including setting up registry storage. After the control plane deploys in the management cluster, the Operator creates a default configs.imageregistry.operator.openshift.io resource instance based on configuration detected in the cluster. If insufficient information is available to define a complete configs.imageregistry.operator.openshift.io resource, the incomplete resource is defined and the Operator updates the resource status with information about what is missing. The Image Registry Operator runs in the openshift-image-registry namespace, and manages the registry instance in that location as well. All configuration and workload resources for the registry reside in that namespace.

Commands:
Chapter 4. Tuning Satellite Server with predefined profiles If your Satellite deployment includes more than 5000 hosts, you can use predefined tuning profiles to improve performance of Satellite. Note that you cannot use tuning profiles on Capsules. You can choose one of the profiles depending on the number of hosts your Satellite manages and available hardware resources. The tuning profiles are available in the /usr/share/foreman-installer/config/foreman.hiera/tuning/sizes directory. When you run the satellite-installer command with the --tuning option, deployment configuration settings are applied to Satellite in the following order: The default tuning profile defined in the /usr/share/foreman-installer/config/foreman.hiera/tuning/common.yaml file The tuning profile that you want to apply to your deployment and is defined in the /usr/share/foreman-installer/config/foreman.hiera/tuning/sizes/ directory Optional: If you have configured a /etc/foreman-installer/custom-hiera.yaml file, Satellite applies these configuration settings. Note that the configuration settings that are defined in the /etc/foreman-installer/custom-hiera.yaml file override the configuration settings that are defined in the tuning profiles. Therefore, before applying a tuning profile, you must compare the configuration settings that are defined in the default tuning profile in /usr/share/foreman-installer/config/foreman.hiera/tuning/common.yaml , the tuning profile that you want to apply and your /etc/foreman-installer/custom-hiera.yaml file, and remove any duplicated configuration from the /etc/foreman-installer/custom-hiera.yaml file. default Number of hosts: 0 - 5000 RAM: 20G Number of CPU cores: 4 medium Number of hosts: 5001 - 10000 RAM: 32G Number of CPU cores: 8 large Number of hosts: 10001 - 20000 RAM: 64G Number of CPU cores: 16 extra-large Number of hosts: 20001 - 60000 RAM: 128G Number of CPU cores: 32 extra-extra-large Number of hosts: 60000+ RAM: 256G Number of CPU cores: 48+ Procedure Optional: If you have configured the custom-hiera.yaml file on Satellite Server, back up the /etc/foreman-installer/custom-hiera.yaml file to custom-hiera.original . You can use the backup file to restore the /etc/foreman-installer/custom-hiera.yaml file to its original state if it becomes corrupted: Optional: If you have configured the custom-hiera.yaml file on Satellite Server, review the definitions of the default tuning profile in /usr/share/foreman-installer/config/foreman.hiera/tuning/common.yaml and the tuning profile that you want to apply in /usr/share/foreman-installer/config/foreman.hiera/tuning/sizes/ . Compare the configuration entries against the entries in your /etc/foreman-installer/custom-hiera.yaml file and remove any duplicated configuration settings in your /etc/foreman-installer/custom-hiera.yaml file. Enter the satellite-installer command with the --tuning option for the profile that you want to apply. For example, to apply the medium tuning profile settings, enter the following command:

Commands:
cp /etc/foreman-installer/custom-hiera.yaml /etc/foreman-installer/custom-hiera.original
satellite-installer --tuning medium
2.6.4.2. The /etc/xinetd.d/ Directory The /etc/xinetd.d/ directory contains the configuration files for each service managed by xinetd and the names of the files are correlated to the service. As with xinetd.conf , this directory is read only when the xinetd service is started. For any changes to take effect, the administrator must restart the xinetd service. The format of files in the /etc/xinetd.d/ directory use the same conventions as /etc/xinetd.conf . The primary reason the configuration for each service is stored in a separate file is to make customization easier and less likely to affect other services. To gain an understanding of how these files are structured, consider the /etc/xinetd.d/krb5-telnet file: These lines control various aspects of the telnet service: service - Specifies the service name, usually one of those listed in the /etc/services file. flags - Sets any of a number of attributes for the connection. REUSE instructs xinetd to reuse the socket for a Telnet connection. Note The REUSE flag is deprecated. All services now implicitly use the REUSE flag. socket_type - Sets the network socket type to stream . wait - Specifies whether the service is single-threaded ( yes ) or multi-threaded ( no ). user - Specifies which user ID the process runs under. server - Specifies which binary executable to launch. log_on_failure - Specifies logging parameters for log_on_failure in addition to those already defined in xinetd.conf . disable - Specifies whether the service is disabled ( yes ) or enabled ( no ). Refer to the xinetd.conf man page for more information about these options and their usage.

Commands:
service telnet { flags = REUSE socket_type = stream wait = no user = root server = /usr/kerberos/sbin/telnetd log_on_failure += USERID disable = yes }
Chapter 1. Preparing to deploy OpenShift Data Foundation Deploying OpenShift Data Foundation on OpenShift Container Platform using local storage devices provided by IBM Power enables you to create internal cluster resources. This approach internally provisions base services. Then, all applications can access additional storage classes. Note Only internal OpenShift Data Foundation clusters are supported on IBM Power. See Planning your deployment for more information about deployment requirements. Before you begin the deployment of Red Hat OpenShift Data Foundation using local storage, ensure that your resource requirements are met. See requirements for installing OpenShift Data Foundation using local storage devices . On the external key management system (KMS), Ensure that a policy with a token exists and the key value backend path in Vault is enabled. See enabling key value backend path and policy in vault . Ensure that you are using signed certificates on your Vault servers. After you have addressed the above, follow the below steps in the order given: Install Local Storage Operator . Install the Red Hat OpenShift Data Foundation Operator . Find available storage devices . Create OpenShift Data Foundation cluster on IBM Power . 1.1. Requirements for installing OpenShift Data Foundation using local storage devices Node requirements The cluster must consist of at least three OpenShift Container Platform worker nodes in the cluster with locally attached storage devices on each of them. Each of the three selected nodes must have at least one raw block device available to be used by OpenShift Data Foundation. The devices to be used must be empty, that is, there should be no persistent volumes (PVs), volume groups (VGs), or local volumes (LVs) remaining on the disks. You must have a minimum of three labeled nodes. Each node that has local storage devices to be used by OpenShift Data Foundation must have a specific label to deploy OpenShift Data Foundation pods. To label the nodes, use the following command: For more information, see the Resource requirements section in the Planning guide. 1.2. Enabling key value backend path and policy in Vault Prerequisites Administrator access to Vault. Carefully, choose a unique path name as the backend path that follows the naming convention since it cannot be changed later. Procedure Enable the Key/Value (KV) backend path in Vault. For Vault KV secret engine API, version 1: For Vault KV secret engine API, version 2: Create a policy to restrict users to perform a write or delete operation on the secret using the following commands. Create a token matching the above policy.

Commands:
oc label nodes <NodeNames> cluster.ocs.openshift.io/openshift-storage=''
vault secrets enable -path=odf kv
vault secrets enable -path=odf kv-v2
echo ' path "odf/*" { capabilities = ["create", "read", "update", "delete", "list"] } path "sys/mounts" { capabilities = ["read"] }'| vault policy write odf -
vault token create -policy=odf -format json
Chapter 4. Deleting a subscription manifest You can remove unused manifests for maintenance purposes. However, deleting an active manifest on a connected Satellite Server is intended for debugging purposes only. Before deleting an active manifest, it is important to note the consequences: All subscriptions attached to running hosts will be deleted. All subscriptions attached to activation keys will be deleted. Red Hat Insights will be disabled due to a lost connection to Red Hat Satellite. Prerequisites You are logged in to the Red Hat Hybrid Cloud Console. You are connected to a Red Hat Satellite Server. You have Red Hat Satellite 6 or later. You have the Subscriptions administrator role in the role-based access control (RBAC) system for the Red Hat Hybrid Cloud Console. Procedure To delete an unused manifest, complete the following steps: From the Hybrid Cloud Console home page, click Services > Subscriptions and Spend > Manifests . From the Manifests page, click the name of the manifest that you want to delete. Important Deleting a manifest will remove all the subscriptions attached to running hosts and activation keys. Red Hat Insights will be disabled. This operation is permanent and cannot be undone. From the Details panel, click Delete manifest . If you are sure that you want to delete the selected manifest, select the confirmation check box and then click Delete .

Commands:
7.212. tar 7.212.1. RHBA-2015:1285 - tar bug fix update Updated tar packages that fix several bugs are now available for Red Hat Enterprise Linux 6. The GNU tar program can save multiple files in one archive and restore the files from that archive. Bug Fixes BZ# 923359 Previously, when the "--verify" or "-W" option was used, the tar utility always exited with a status of 2, and false warning messagess per each archived file were printed. This behavior was a regression introduced in tar-1.23-11.el6. With this update, tar exits with a status of 2 only if there is a real problem with the archived files. BZ# 1034360 Prior to this update, tar interpreted an argument containing an unescaped "[" character and no corresponding "]" character as a pattern-matching string instead of an archive member name, unless the "--no-wildcard" option was used. Consequently, if a user wanted to extract an existing archive member with a path name containing the argument, tar failed to match the argument with the corresponding member, printed an error message, and eventually exited with a non-zero exit status. This problem has been fixed, and tar is now able to extract such a file. BZ# 1056672 Previously, tar did not automatically detect archives compressed by the xz program if the user did not specify the "-J" or "--xz" option on the command line. As a consequence, if the processed archive had the ".xz" extension, tar extracted or listed the contents of the archive but printed an error message and eventually exited with a non-zero exit status. If the archive did not have this extension, tar failed. With this update, the automatic recognition mechanism has been improved. As a result, tar no longer prints an error message in this scenario, and it extracts or lists the contents of such archives correctly regardless of the extension. BZ# 1119312 The tar(1) man page does not list all the available options; however, it now mentions the fact that complete information on using tar is available in the tar Info page, which can be displayed by running the "info tar" command. Users of tar are advised to upgrade to these updated packages, which fix these bugs.

Commands:
Appendix A. Additional procedures A.1. Creating bootable media The P2V Client can be booted from PXE boot, a bootable USB device, or optical media. Scripts for preparing boot options are included with the rhel-6.x-p2v.iso ISO in the LiveOS directory. A.1.1. Create a P2V client boot CD The exact series of steps that produces a CD from an image file varies greatly from computer to computer, depending on the operating system and disc burning software installed. This procedure describes burning an ISO image to disk using Brasero which is included in Red Hat Enterprise Linux 6. Make sure that your disc burning software is capable of burning discs from image files. Although this is true of most disc burning software, exceptions exist. Insert a blank, writable CD into your computer's CD or DVD burner. Open the Applications menu, choose the Sound and Video sub-menu, and click Brasero Disk Burner . Click the Burn Image button. Click the Click here to select a disc image button. Browse to the rhel-6.x-p2v.iso and select it for burning. Click Burn . Your BIOS may need to be changed to allow booting from your DVD/CD-ROM drive. A.1.2. Create a bootable P2V USB media As root, mount the rhel-6.x-p2v.iso : Attach your USB device to the computer. For the livecd-iso-to-disk script to function, the USB filesystem must be formatted vfat, ext[234] or btrfs. From a terminal as root run the livecd-iso-to-disk script: When the script finishes successfully, eject the USB device. A.1.3. Create a PXE boot image As root, mount the rhel-6.x-p2v.iso From a terminal as root run the livecd-iso-to-pxeboot script: When the command successfully completes, there is a tftpboot directory in the directory from which the command was run. Rename the newly created tftpboot directory to a more descriptive name: Copy the p2vboot/ sub-directory to the /tftpboot directory: Set up your DHCP, TFTP and PXE server to serve /tftpboot/p2vboot/pxeboot.0 . Note The initrd image contains the whole CD ISO. You will notice when pxebooting that initrd can take a long time to download. This is normal behavior.

Commands:
mkdir /mnt/p2vmount
mount -o loop rhel-6.x-p2v.iso /mnt/p2vmount
bash /mnt/p2vmount/LiveOS/livecd-iso-to-disk /PATH/TO/rhel-6.x-p2v.iso /dev/YOURUSBDEVICE
mkdir /mnt/p2vmount
mount -o loop rhel-6.x-p2v.iso /mnt/p2vmount
bash /mnt/p2vboot/LiveOS/livecd-iso-to-pxeboot /PATH/TO/rhel-6.x-p2v.iso
mv tftpboot/ p2vboot/
cp -R p2vboot/ /tftpboot/