mtpti5iD/redhat-docs_dataset huggingface dataset:
2.9.2. Useful Websites http://www.gnu.org/software/grub/ - The home page of the GNU GRUB project. This site contains information concerning the state of GRUB development and an FAQ. http://www.redhat.com/mirrors/LDP/HOWTO/mini/Multiboot-with-GRUB.html - Investigates various uses for GRUB, including booting operating systems other than Linux. http://www.linuxgazette.com/issue64/kohli.html - An introductory article discussing the configuration of GRUB on a system from scratch, including an overview of GRUB command line options.

Commands:
7.189. ppc64-diag 7.189.1. RHBA-2013:0382 - ppc64-diag bug fix and enhancement update Updated ppc64-diag packages that fix several bugs and add various enhancements are now available for Red Hat Enterprise Linux 6. The ppc64-diag packages provide diagnostic tools for Linux on the 64-bit PowerPC platforms. The platform diagnostics write events reported by the firmware to the service log, provide automated responses to urgent events, and notify system administrators or connected service frameworks about the reported events. Note The ppc64-diag packages have been upgraded to upstream version 2.5.0, which provides a number of bug fixes and enhancements over the version. (BZ#822653) Bug Fixes BZ#833619 Previously, the GARD functionality could fail to "gard out" a CPU that was being deconfigured on a logical partition (LPAR) if a predictive CPU failure was received. Consequently, the CPU could not be deconfigured. This was caused by incorrect behavior of the SIGCHLD signal handler, which under certain circumstances performed cleanup on a pipe child process that had already exited. This update modifies the underlying source code so that the SIGCHLD signal handler is reset to the default action before a pipe is open and set up again after the pipe is closed. The CPU is now correctly "garded out" and deconfigured as expected in this scenario. Also, vital product data (VPD) extraction from the lsvpd command did not work correctly. This has been fixed by correcting the lsvpd_init() function, and VPD is now obtained as expected. BZ#878314 The diag_encl command was previously enhanced with a comparison feature. The feature requires the /etc/ppc64-diag/ses_pages directory to be created on ppc64-diag installation. However, the ppc64-diag spec file was not modified accordingly so that the required directory was not created when installing the ppc64-diag packages. Consequently, the comparison feature of the diag_encl command did not work. This update corrects the ppc64-diag spec file so that the /etc/ppc64-diag/ses_pages directory is now created as expected, and the comparison feature works properly. All users of ppc64-diag are advised to upgrade to these updated packages, which fix these bugs and add these enhancements.

Commands:
Chapter 2. Instance boot source The boot source for an instance can be an image or a bootable volume. The instance disk of an instance that you boot from an image is controlled by the Compute service and deleted when the instance is deleted. The instance disk of an instance that you boot from a volume is controlled by the Block Storage service and is stored remotely. An image contains a bootable operating system. The Image Service (glance) controls image storage and management. You can launch any number of instances from the same base image. Each instance runs from a copy of the base image. Any changes that you make to the instance do not affect the base image. A bootable volume is a block storage volume created from an image that contains a bootable operating system. The instance can use the bootable volume to persist instance data when the instance is deleted. You can use an existing persistent root volume when you launch an instance. You can also create persistent storage when you launch an instance from an image, so that you can save the instance data when the instance is deleted. A new persistent storage volume is created automatically when you create an instance from a volume snapshot. The following diagram shows the instance disks and storage that you can create when you launch an instance. The actual instance disks and storage created depend on the boot source and flavor used.

Commands:
Appendix A. Component Versions This appendix provides a list of key components and their versions in the Red Hat Enterprise Linux 7 release. Table A.1. Component Versions Component Version kernel 3.10.0-1127 kernel-alt 4.14.0-115 QLogic qla2xxx driver 10.01.00.20.07.8-k QLogic qla4xxx driver 5.04.00.00.07.02-k0 Emulex lpfc driver 0:12.0.0.13 iSCSI initiator utils ( iscsi-initiator-utils ) 6.2.0.874-17 DM-Multipath ( device-mapper-multipath ) 0.4.9-131 LVM ( lvm2 ) 2.02.186-7 qemu-kvm [a] 1.5.3-173 qemu-kvm-ma [b] 2.12.0-33 [a] The qemu-kvm packages provide KVM virtualization on AMD64 and Intel 64 systems. [b] The qemu-kvm-ma packages provide KVM virtualization on IBM POWER8, IBM POWER9, and IBM Z. Note that KVM virtualization on IBM POWER9 and IBM Z also requires using the kernel-alt packages.

Commands:
6.3. Colocation of Resources A colocation constraint determines that the location of one resource depends on the location of another resource. There is an important side effect of creating a colocation constraint between two resources: it affects the order in which resources are assigned to a node. This is because you cannot place resource A relative to resource B unless you know where resource B is. So when you are creating colocation constraints, it is important to consider whether you should colocate resource A with resource B or resource B with resource A. Another thing to keep in mind when creating colocation constraints is that, assuming resource A is collocated with resource B, the cluster will also take into account resource A's preferences when deciding which node to choose for resource B. The following command creates a colocation constraint. For information on master and slave resources, see Section 8.2, "Multi-State Resources: Resources That Have Multiple Modes" . Table 6.3, "Properties of a Colocation Constraint" . summarizes the properties and options for configuring colocation constraints. Table 6.3. Properties of a Colocation Constraint Field Description source_resource The colocation source. If the constraint cannot be satisfied, the cluster may decide not to allow the resource to run at all. target_resource The colocation target. The cluster will decide where to put this resource first and then decide where to put the source resource. score Positive values indicate the resource should run on the same node. Negative values indicate the resources should not run on the same node. A value of + INFINITY , the default value, indicates that the source_resource must run on the same node as the target_resource . A value of - INFINITY indicates that the source_resource must not run on the same node as the target_resource . 6.3.1. Mandatory Placement Mandatory placement occurs any time the constraint's score is +INFINITY or -INFINITY . In such cases, if the constraint cannot be satisfied, then the source_resource is not permitted to run. For score=INFINITY , this includes cases where the target_resource is not active. If you need myresource1 to always run on the same machine as myresource2 , you would add the following constraint: Because INFINITY was used, if myresource2 cannot run on any of the cluster nodes (for whatever reason) then myresource1 will not be allowed to run. Alternatively, you may want to configure the opposite, a cluster in which myresource1 cannot run on the same machine as myresource2 . In this case use score=-INFINITY Again, by specifying -INFINITY , the constraint is binding. So if the only place left to run is where myresource2 already is, then myresource1 may not run anywhere.

Commands:
pcs constraint colocation add [master|slave] source_resource with [master|slave] target_resource [ score ] [ options ]
pcs constraint colocation add myresource1 with myresource2 score=INFINITY
pcs constraint colocation add myresource1 with myresource2 score=-INFINITY
Chapter 10. Cloning Subsystems When a new subsystem instance is first configured, the Red Hat Certificate System allows subsystems to be cloned, or duplicated, for high availability of the Certificate System. The cloned instances run on different machines to avoid a single point of failure and their databases are synchronized through replication. The master CA and its clones are functionally identical, they only differ in serial number assignments and CRL generation. Therefore, this chapter refers to master or any of its clones as replicated CAs . 10.1. Backing up Subsystem Keys from a Software Database Ideally, the keys for the master instance are backed up when the instance is first created. If the keys were not backed up then or if the backup file is lost, then it is possible to extract the keys from the internal software database for the subsystem instance using the PKCS12Export utility. For example: Then copy the PKCS #12 file to the clone machine to be used in the clone instance configuration. For more details, see Section 2.7.6, "Cloning and Key Stores" . Note Keys cannot be exported from an HSM. However, in a typical deployment, HSMs support networked access, as long as the clone instance is installed using the same HSM as the master. If both instances use the same key store, then the keys are naturally available to the clone. If backing up keys from the HSM is required, contact the HSM manufacturer for assistance.

Commands:
PKCS12Export -debug -d /var/lib/pki/ instance_name /alias -w p12pwd.txt -p internal.txt -o master.p12
2.2.6.2. Anonymous Access The presence of the /var/ftp/ directory activates the anonymous account. The easiest way to create this directory is to install the vsftpd package. This package establishes a directory tree for anonymous users and configures the permissions on directories to read-only for anonymous users. By default the anonymous user cannot write to any directories. Warning If enabling anonymous access to an FTP server, be aware of where sensitive data is stored. Procedure 2.1. Anonymous Upload To allow anonymous users to upload files, it is recommended to create a write-only directory within the /var/ftp/pub/ directory. Run the following command as root to create such directory named /upload/ : , change the permissions so that anonymous users cannot view the contents of the directory: A long format listing of the directory should look like this: Note Administrators who allow anonymous users to read and write in directories often find that their servers become a repository of stolen software. Under vsftpd , add the following line to the /etc/vsftpd/vsftpd.conf file: In Red Hat Enterprise Linux, the SELinux is running in Enforcing mode by default. Therefore, the allow_ftpd_anon_write Boolean must be enabled in order to allow vsftpd to upload files: Label the /upload/ directory and its files with the public_content_rw_t SELinux context: Note The semanage utility is provided by the policycoreutils-python package, which is not installed by default. To install it, use the following command as root: Use the restorecon utility to change the type of /upload/ and its files: The directory is now properly labeled with public_content_rw_t so that SELinux in Enforcing mode allows anonymous users to upload files to it: For further information about using SELinux, see the Security-Enhanced Linux User Guide and Managing Confined Services guides.

Commands:
~]# mkdir /var/ftp/pub/upload
~]# chmod 730 /var/ftp/pub/upload
~]# ls -ld /var/ftp/pub/upload drwx-wx---. 2 root ftp 4096 Nov 14 22:57 /var/ftp/pub/upload
anon_upload_enable=YES
~]# setsebool -P allow_ftpd_anon_write=1
~]# semanage fcontext -a -t public_content_rw_t '/var/ftp/pub/upload(/.*)'
~]# yum install policycoreutils-python
~]# restorecon -R -v /var/ftp/pub/upload
~]USD ls -dZ /var/ftp/pub/upload drwx-wx---. root root unconfined_u:object_r:public_content_t:s0 /var/ftp/pub/upload/
8.4. Increasing the Size of an XFS File System An XFS file system may be grown while mounted using the xfs_growfs command: The -D size option grows the file system to the specified size (expressed in file system blocks). Without the -D size option, xfs_growfs will grow the file system to the maximum size supported by the device. Before growing an XFS file system with -D size , ensure that the underlying block device is of an appropriate size to hold the file system later. Use the appropriate resizing methods for the affected block device. Note While XFS file systems can be grown while mounted, their size cannot be reduced at all. For more information about growing a file system, refer to man xfs_growfs .

Commands:
xfs_growfs /mount/point -D size
6.3.2.3. /etc/group The /etc/group file is world-readable and contains a list of groups, each on a separate line. Each line is a four field, colon delimited list including the following information: Group name - The name of the group. Used by various utility programs as a human-readable identifier for the group. Group password - If set, this allows users that are not part of the group to join the group by using the newgrp command and typing the password stored here. If a lower case x is in this field, then shadow group passwords are being used. Group ID ( GID ) - The numerical equivalent of the group name. It is used by the operating system and applications when determining access privileges. Member list - A comma delimited list of the users belonging to the group. Here is an example line from /etc/group : This line shows that the general group is using shadow passwords, has a GID of 502, and that juan , shelley , and bob are members. For more information on /etc/group , see the group(5) man page.

Commands:
general:x:502:juan,shelley,bob
5.4.2.3. Moving the Data Use the pvmove command to move the data from /dev/sdb1 to /dev/sdd1 .

Commands:
pvmove /dev/sdb1 /dev/sdd1 /dev/sdb1: Moved: 10.0% /dev/sdb1: Moved: 79.7% /dev/sdb1: Moved: 100.0% pvs -o+pv_used PV VG Fmt Attr PSize PFree Used /dev/sda1 myvg lvm2 a- 17.15G 7.15G 10.00G /dev/sdb1 myvg lvm2 a- 17.15G 17.15G 0 /dev/sdc1 myvg lvm2 a- 17.15G 15.15G 2.00G /dev/sdd1 myvg lvm2 a- 17.15G 15.15G 2.00G
Chapter 1. About Telemetry Red Hat Advanced Cluster Security for Kubernetes (RHACS) collects anonymized aggregated information about product usage and product configuration. It helps Red Hat understand how everyone uses the product and identify areas to prioritize for improvements. In addition, Red Hat uses this information to improve the user experience. 1.1. Information collected by Telemetry Telemetry does not collect identifying information such as user names, passwords, or the names or addresses of user resources. Note Telemetry data collection is enabled by default, except for the installations with the offline mode enabled. Telemetry collects the following information: API, roxctl CLI, and user interface (UI) features and settings to know how you use Red Hat Advanced Cluster Security for Kubernetes (RHACS), which helps prioritize efforts. The time you spend on UI screens to help us improve user experience. The integrations are used to know if there are integrations that you have never used. The number of connected secured clusters and their configurations. Errors you encounter to identify the most common problems.

Commands:
Appendix B. Revision History Revision History Revision 4-10 Mon Aug 10 2020 Marek Suchanek An asynchronous update Revision 4-09 Mon Jan 7 2019 Marek Suchanek An asynchronous update Revision 4-08 Mon Oct 23 2018 Marek Suchanek Preparing document for 7.6 GA publication Revision 4-07 Thu Sep 13 2018 Marek Suchanek An asynchronous update Revision 4-00 Fri Apr 6 2018 Marek Suchanek Document version for 7.5 GA publication. Revision 3-95 Thu Apr 5 2018 Marek Suchanek An asynchronous update Revision 3-93 Mon Mar 5 2018 Marek Suchanek New chapter: VDO Integration Revision 3-92 Fri Feb 9 2018 Marek Suchanek An asynchronous update Revision 3-90 Wed Dec 6 2017 Marek Suchanek Version for 7.5 Alpha publication. Revision 3-86 Mon Nov 6 2017 Marek Suchanek An asynchronous update. Revision 3-80 Thu Jul 27 2017 Milan Navratil Document version for 7.4 GA publication. Revision 3-77 Wed May 24 2017 Milan Navratil An asynchronous update. Revision 3-68 Fri Oct 21 2016 Milan Navratil Version for 7.3 GA publication. Revision 3-67 Fri Jun 17 2016 Milan Navratil An asynchronous update. Revision 3-64 Wed Nov 11 2015 Jana Heves Version for 7.2 GA release. Revision 3-33 Wed Feb 18 2015 Jacquelynn East Version for 7.1 GA Revision 3-26 Wed Jan 21 2015 Jacquelynn East Added overview of Ceph Revision 3-22 Thu Dec 4 2014 Jacquelynn East 7.1 Beta Revision 3-4 Thu Jul 17 2014 Jacquelynn East Added new chapter on targetcli Revision 3-1 Tue Jun 3 2014 Jacquelynn East Version for 7.0 GA release

Commands:
5.7. Activating Logical Volumes on Individual Nodes in a Cluster If you have LVM installed in a cluster environment, you may at times need to activate logical volumes exclusively on one node. To activate logical volumes exclusively on one node, use the lvchange -aey command. Alternatively, you can use lvchange -aly command to activate logical volumes only on the local node but not exclusively. You can later activate them on additional nodes concurrently. You can also activate logical volumes on individual nodes by using LVM tags, which are described in Appendix D, LVM Object Tags . You can also specify activation of nodes in the configuration file, which is described in Appendix B, The LVM Configuration Files .

Commands:
Chapter 5. Kernel Module Management Operator release notes 5.1. Kernel Module Management Operator release notes 5.1.1. Release notes for Kernel Module Management Operator 2.2 5.1.1.1. New features KMM is now using the CRI-O container engine to pull container images in the worker pod instead of using HTTP calls directly from the worker container. For more information, see Example Module CR . The Kernel Module Management (KMM) Operator images are now based on rhel-els-minimal container images instead of the rhel-els images. This change results in a greatly reduced image footprint, while still maintaining FIPS compliance. In this release, the firmware search path has been updated to copy the contents of the specified path into the path specified in worker.setFirmwareClassPath (default: /var/lib/firmware). For more information, see Example Module CR . For each node running a kernel matching the regular expression, KMM now checks if you have included a tag or a digest. If you have not specified a tag or digest in the container image, then the validation webhook returns an error and does not apply the module. For more information, see Example Module CR .

Commands:
17.4. Configuration Examples 17.4.1. Dynamic DNS BIND allows hosts to update their records in DNS and zone files dynamically. This is used when a host computer's IP address changes frequently and the DNS record requires real-time modification. Use the /var/named/dynamic/ directory for zone files you want updated by dynamic DNS. Files created in or copied into this directory inherit Linux permissions that allow named to write to them. As such files are labeled with the named_cache_t type, SELinux allows named to write to them. If a zone file in /var/named/dynamic/ is labeled with the named_zone_t type, dynamic DNS updates may not be successful for a certain period of time as the update needs to be written to a journal first before being merged. If the zone file is labeled with the named_zone_t type when the journal attempts to be merged, an error such as the following is logged: Also, the following SELinux denial message is logged: To resolve this labeling issue, use the restorecon utility as root:

Commands:
named[PID]: dumping master file: rename: /var/named/dynamic/zone-name: permission denied
setroubleshoot: SELinux is preventing named (named_t) "unlink" to zone-name (named_zone_t)
~]# restorecon -R -v /var/named/dynamic
22.4. Understanding the Drift File The drift file is used to store the frequency offset between the system clock running at its nominal frequency and the frequency required to remain in synchronization with UTC. If present, the value contained in the drift file is read at system start and used to correct the clock source. Use of the drift file reduces the time required to achieve a stable and accurate time. The value is calculated, and the drift file replaced, once per hour by ntpd . The drift file is replaced, rather than just updated, and for this reason the drift file must be in a directory for which ntpd has write permissions.

Commands:
1.2. Digital Signatures Tamper detection relies on a mathematical function called a one-way hash (also called a message digest ). A one-way hash is a number of fixed length with the following characteristics: The value of the hash is unique for the hashed data. Any change in the data, even deleting or altering a single character, results in a different value. The content of the hashed data cannot be deduced from the hash. As mentioned in Section 1.1.2, "Public-Key Encryption" , it is possible to use a private key for encryption and the corresponding public key for decryption. Although not recommended when encrypting sensitive information, it is a crucial part of digitally signing any data. Instead of encrypting the data itself, the signing software creates a one-way hash of the data, then uses the private key to encrypt the hash. The encrypted hash, along with other information such as the hashing algorithm, is known as a digital signature. Figure 1.3, "Using a Digital Signature to Validate Data Integrity" illustrates the way a digital signature can be used to validate the integrity of signed data. Figure 1.3. Using a Digital Signature to Validate Data Integrity Figure 1.3, "Using a Digital Signature to Validate Data Integrity" shows two items transferred to the recipient of some signed data: the original data and the digital signature, which is a one-way hash of the original data encrypted with the signer's private key. To validate the integrity of the data, the receiving software first uses the public key to decrypt the hash. It then uses the same hashing algorithm that generated the original hash to generate a new one-way hash of the same data. (Information about the hashing algorithm used is sent with the digital signature.) Finally, the receiving software compares the new hash against the original hash. If the two hashes match, the data has not changed since it was signed. If they do not match, the data may have been tampered with since it was signed, or the signature may have been created with a private key that does not correspond to the public key presented by the signer. If the two hashes match, the recipient can be certain that the public key used to decrypt the digital signature corresponds to the private key used to create the digital signature. Confirming the identity of the signer also requires some way of confirming that the public key belongs to a particular entity. For more information on authenticating users, see Section 1.3, "Certificates and Authentication" . A digital signature is similar to a handwritten signature. Once data have been signed, it is difficult to deny doing so later, assuming the private key has not been compromised. This quality of digital signatures provides a high degree of nonrepudiation; digital signatures make it difficult for the signer to deny having signed the data. In some situations, a digital signature is as legally binding as a handwritten signature.

Commands: