mtpti5iD/redhat-docs_dataset huggingface dataset:
7.275. xfsdump 7.275.1. RHBA-2013:0482 - xfsdump bug fix update Updated xfsdump packages that fix one bug are now available for Red Hat Enterprise Linux 6. The xfsdump packages provide several utilities for managing XFS file systems, including xfsrestore and xfsdump. Bug Fix BZ#860454 With Red Hat Enterprise Linux 6.4, XFS has been enhanced to allow the use of the 32-bit project quota ID feature. However, the top 16 bits of a 32-bit project quota ID were not properly saved and restored using the xfsdump and xfsrestore utilities. This caused the data to be saved and restored with an incorrect 16-bit project quota ID. With this update, the underlying source code has been fixed so that all 32 bits of the project quota ID are properly saved and restored by xsfdump and xfsrestore. All users of xfsdump are advised to upgrade to these updated packages, which fix this bug.

Commands:
14.3.3.3. Backup Domain Controller (BDC) using LDAP A BDC is an integral part of any enterprise Samba/LDAP solution. The smb.conf files between the PDC and BDC are virtually identical except for the domain master directive. Make sure the PDC has a value of Yes and the BDC has a value of No . If you have multiple BDCs for a PDC, the os level directive is useful in setting the BDC election priority. The higher the value, the higher the server priority for connecting clients. Note A BDC can either use the LDAP database of the PDC or have its own LDAP database. This example uses the LDAP database of the PDC as seen in the passdb backend directive.

Commands:
[global] workgroup = DOCS netbios name = DOCS_SRV2 passdb backend = ldapsam:ldap://ldap.example.com username map = /etc/samba/smbusers security = user add user script = /usr/sbin/useradd -m %u delete user script = /usr/sbin/userdel -r %u add group script = /usr/sbin/groupadd %g delete group script = /usr/sbin/groupdel %g add user to group script = /usr/sbin/usermod -G %g %u add machine script = /usr/sbin/useradd -s /bin/false -d /dev/null -g machines %u The following specifies the default logon script Per user logon scripts can be specified in the user account using pdbedit logon script = scripts\logon.bat This sets the default profile path. Set per user paths with pdbedit logon path = \\%L\Profiles\%U logon drive = H: logon home = \\%L\%U domain logons = Yes os level = 35 preferred master = Yes domain master = No ldap suffix = dc=example,dc=com ldap machine suffix = ou=People ldap user suffix = ou=People ldap group suffix = ou=Group ldap idmap suffix = ou=People ldap admin dn = cn=Manager ldap ssl = no ldap passwd sync = yes idmap uid = 15000-20000 idmap gid = 15000-20000 Other resource shares
F.9. The Externalizer F.9.1. About Externalizer An Externalizer is a class that can: Marshall a given object type to a byte array. Unmarshall the contents of a byte array into an instance of the object type. Externalizers are used by Red Hat JBoss Data Grid and allow users to specify how their object types are serialized. The marshalling infrastructure used in JBoss Data Grid builds upon JBoss Marshalling and provides efficient payload delivery and allows the stream to be cached. The stream caching allows data to be accessed multiple times, whereas normally a stream can only be read once. Report a bug F.9.2. Internal Externalizer Implementation Access Externalizable objects should not access Red Hat JBoss Data Grids Externalizer implementations. The following is an example of incorrect usage: End user externalizers do not need to interact with internal externalizer classes. The following is an example of correct usage: Report a bug

Commands:
public static class ABCMarshallingExternalizer implements AdvancedExternalizer<ABCMarshalling> { @Override public void writeObject(ObjectOutput output, ABCMarshalling object) throws IOException { MapExternalizer ma = new MapExternalizer(); ma.writeObject(output, object.getMap()); } @Override public ABCMarshalling readObject(ObjectInput input) throws IOException, ClassNotFoundException { ABCMarshalling hi = new ABCMarshalling(); MapExternalizer ma = new MapExternalizer(); hi.setMap((ConcurrentHashMap<Long, Long>) ma.readObject(input)); return hi; } <!-- Additional configuration information here -->
public static class ABCMarshallingExternalizer implements AdvancedExternalizer<ABCMarshalling> { @Override public void writeObject(ObjectOutput output, ABCMarshalling object) throws IOException { output.writeObject(object.getMap()); } @Override public ABCMarshalling readObject(ObjectInput input) throws IOException, ClassNotFoundException { ABCMarshalling hi = new ABCMarshalling(); hi.setMap((ConcurrentHashMap<Long, Long>) input.readObject()); return hi; } <!-- Additional configuration information here --> }
A.2. Output Reference An output is the response to the end user of a successful enrollment. A.2.1. Certificate Output This output displays the certificate in pretty-print format. This output cannot be configured or changed. It does not display anything other than the certificate in pretty-print format. This output needs to be specified for any automated enrollment. Once a user successfully authenticates using the automated enrollment method, the certificate is automatically generated, and this output page is returned to the user. In an agent-approved enrollment, the user can get the certificate, once it is issued, by providing the request ID in the end-entities page. Example A.14. A.2.2. PKCS #7 Output This output returns the certificate and the certificate chain in PKCS #7 format. PKCS #7 format is the Cryptographic Message Syntax Standard, which is used for signing. This output cannot be configured or changed. Example A.15. A.2.3. nsNSKeyOutput This class implements the output plug-in that returns the DER encoded certificates for token keys. A.2.4. CMMF Output This output returns the certificate in Certificate Management Messages Formats (CMMF). CMMF govern communication between different parts of a PKI and is used for requesting certificates and requesting certificate revocation.

Commands:
caAdminCert.cfg:output.o1.class_id=certOutputImpl
caAgentFileSigning.cfg:output.o1.class_id=pkcs7OutputImpl
Chapter 4. Creating system images with Image Builder web console interface Image Builder is a tool for creating custom system images. To use Image Builder and create your custom system images, you can use the web console interface. Note that the command-line interface is the currently preferred alternative, because it offers more features. Note The command-line interface is the currently preferred alternative, because it offers more features. 4.1. Accessing Image Builder GUI in the RHEL 7 web console The cockpit-composer plug-in for the RHEL 7 web console enables users to manage Image Builder blueprints and composes with a graphical interface. Note that the preferred method for controlling Image Builder is at the moment using the command-line interface. Prerequisites You must have root access to the system. Procedure 1. Open https://localhost:9090/ in a web browser on the system where Image Builder is installed. Figure 4.1. Log into the web console For more information on how to remotely access Image Builder, see managing systems using the RHEL 7 web console . 2. Log into the web console with your root username and password. 3. To display the Image Builder controls, click the Image Builder icon, which is in the upper-left corner of the window. The Image Builder view opens, listing existing blueprints. Figure 4.2. Image Builder on Web Console Related information Chapter 3, Creating system images with Image Builder command-line interface You will be able to create customized RHEL OS images using Image Builder scenario

Commands:
Chapter 1. Advanced Red Hat Quay configuration You can configure your Red Hat Quay after initial deployment using one of the following methods: Editing the config.yaml file . The config.yaml file contains most configuration information for the Red Hat Quay cluster. Editing the config.yaml file directly is the primary method for advanced tuning and enabling specific features. Using the Red Hat Quay API . Some Red Hat Quay features can be configured through the API. This content in this section describes how to use each of the aforementioned interfaces and how to configure your deployment with advanced features. 1.1. Using the API to modify Red Hat Quay See the Red Hat Quay API Guide for information on how to access Red Hat Quay API. 1.2. Editing the config.yaml file to modify Red Hat Quay Advanced features can be implemented by editing the config.yaml file directly. All configuration fields for Red Hat Quay features and settings are available in the Red Hat Quay configuration guide . The following example is one setting that you can change directly in the config.yaml file. Use this example as a reference when editing your config.yaml file for other features and settings. 1.2.1. Adding name and company to Red Hat Quay sign-in By setting the FEATURE_USER_METADATA field to true , users are prompted for their name and company when they first sign in. This is an optional field, but can provide your with extra data about your Red Hat Quay users. Use the following procedure to add a name and a company to the Red Hat Quay sign-in page. Procedure Add, or set, the FEATURE_USER_METADATA configuration field to true in your config.yaml file. For example: # ... FEATURE_USER_METADATA: true # ... Redeploy Red Hat Quay. Now, when prompted to log in, users are requested to enter the following information:

Commands:
FEATURE_USER_METADATA: true
10.3.3. Discontinued Packages The following table lists discontinued (removed) packages in Red Hat Enterprise Linux 6 and their replacements or alternatives. Table 10.2. Discontinued Packages Discontinued Package Replaced By aspell hunspell. aspell is only provided as a build dependency. Applications that want to use spell-checking must use hunspell. beecrypt NSS/OpenSSL crash-spu-commands None. Cell-specific packages no longer included. dhcpv6/dhcpv6-client dhcp/dhclient binaries now have IPv6 capability built in. elfspe2 None. Cell-specific packages no longer included. exim Postfix gnbd iSCSI recommended for use instead. gnome-vfs gvfs ipsec-tools Openswan kmod-gnbd iSCSI recommended for use instead. lam openmpi libatomic gcc-libraries, in Red Hat Enterprise Linux 6.5 and onward. libspe2 None. Cell-specific packages no longer included. libspe2-devel None. Cell-specific packages no longer included. linuxwacom xorg-x11-drv-wacom mod_python mod_wsgi, which uses the WSGI interface, can be used as an alternative for Python scripting. mkinitrd dracut nss_ldap nss-pam-ldapd, pam_ldap openmotif-2.2 openmotif-2.3 spu-tools None. Cell-specific packages no longer included. switchdesk The session management performed by both supported session managers: GDM and KDM. sysklogd rsyslog as of Red Hat Enterprise Linux 6.0; rsyslog7 as of Red Hat Enterprise Linux 6.6 SysVinit upstart vixie-cron cronie

Commands:
Chapter 2. Hardware requirements The hardware requirements are based on tests run with the following prerequisites: The server uses default indexes. Each LDAP entry has a size of 1.5 KB and 30 or more attributes. Disk space The following table provides guidelines for the recommended disk space for Directory Server based on the number of entries. Table 2.1. Required disk space Number of entries Database size Database cache Server and logs Total disk space 10,000 - 500,000 2 GB 2 GB 4 GB 8 GB 500,000 - 1,000,000 5 GB 2 GB 4 GB 11 GB 1,000,000 - 5,000,000 21 GB 2 GB 4 GB 27 GB 5,000,000 - 10,000,000 42 GB 2 GB 4 GB 48 GB The total disk space does not include space for backups and replication metadata. With enabled replication, its metadata can require up to 10% more of the total disk space. A replication changelog with 1 million changes can add at least 315 MB to the total disk space requirement. The temporary file system (tmpfs) mounted in /dev/shm/ should have at least 4 GB of available space to store RHDS temporary files. Required RAM Make sure your system has enough RAM available to keep the entire database in cache. The required RAM size can be higher than the recommended one depending on server configuration and usage patterns. Table 2.2. Required RAM size Number of entries Entry cache Entry cache with replication [a] Database cache DN cache NDN cache Total RAM size [b] 10,000 - 500,000 4 GB 5 GB 1.5 GB 45 MB 160 MB 7 GB 500,000 - 1,000,000 8 GB 10 GB 1.5 GB 90 MB 320 MB 12 GB 1,000,000 - 5,000,000 40 GB 50 GB 1.5 GB 450 MB 1.6 GB 54 GB 5,000,000 - 10,000,000 80 GB 100 GB 1.5 GB 900 MB 3.2 GB 106 GB [a] Entry cache with replication includes the entry's replication state and metadata. [b] Total RAM size assumes you enabled replication.

Commands:
Chapter 7. Configuring the systems and running tests using RHCert CLI Tool To complete the certification process using CLI, you must prepare the host under test (HUT) and test server, run the tests, and retrieve the test results. 7.1. Using the test plan to prepare the host under test for testing Running the provision command performs a number of operations, such as setting up passwordless SSH communication with the test server, installing the required packages on your system based on the certification type, and creating a final test plan to run, which is a list of common tests taken from both the test plan provided by Red Hat and tests generated on discovering the system requirements. For instance, required hardware or software packages will be installed if the test plan is designed for certifying a hardware or a software product. Prerequisites You have the hostname or the IP address of the test server. Procedure Run the provision command in either way. The test plan will automatically get downloaded to your system. If you have already downloaded the test plan: Replace <path_to_test_plan_document> with the test plan file saved on your system. Follow the on-screen instructions. If you have not downloaded the test plan: Follow the on-screen instructions and enter your Certification ID when prompted. When prompted, provide the hostname or the IP address of the test server to set up passwordless SSH. You are prompted only the first time you add a new system. 7.2. Using the test plan to prepare the test server for testing Running the Provision command enables and starts the rhcertd service, which configures services specified in the test suite on the test server, such as iperf for network testing, and an nfs mount point used in kdump testing. Prerequisites You have the hostname or IP address of the host under test. Procedure Run the provision command by defining the role, "test server", to the system you are adding. This is required only for provisioning the test server. Replace <path_to_test_plan_document> with the test plan file saved on your system. 7.3. Running the certification tests using CLI Procedure Run the following command: When prompted, choose whether to run each test by typing yes or no . You can also run particular tests from the list by typing select . Note After a test reboot, rhcert is running in the background to verify the image. Use tail -f / var /log/rhcert/RedHatCertDaemon.log to see the current progress and status of the verification. 7.4. Submitting the test results file Procedure Log in to authenticate your device. Note Logging in is mandatory to submit the test results file. Open the generated URL in a new browser window or tab. Enter the login and password and click Log in . Click Grant access . Device log in successful message displays. Return to the terminal and enter yes to the Please confirm once you grant access prompt. Submit the result file. When prompted, enter your Certification ID.

Commands:
rhcert-provision <path_to_test_plan_document>
rhcert-provision
rhcert-provision --role test-server <path_to_test_plan_document>
rhcert-run
rhcert-cli login
rhcert-submit
Chapter 1. About Lightspeed 1.1. OpenShift Lightspeed overview Red Hat OpenShift Lightspeed provides intelligent, natural language processing capabilities designed to make Red Hat cloud-native application platforms easier to use for beginners and more efficient for experienced professionals. Note Because OpenShift Lightspeed releases on a different cadence from OpenShift Container Platform, the OpenShift Lightspeed documentation is available as a separate documentation set at About Red Hat OpenShift Lightspeed .

Commands:
6.4. Reverting to an ext2 File System Because ext3 is relatively new, some disk utilities do not yet support it. For example, you may need to shrink a partition with resize2fs , which does not yet support ext3. In this situation, it may be necessary to temporarily revert a file system to ext2. To revert a partition, you must first unmount the partition by logging in as root and typing, , change the file system type to ext2 by typing the following command as root: Check the partition for errors by typing the following command as root: Then mount the partition again as ext2 file system by typing: In the above command, replace /mount/point with the mount point of the partition. , remove the .journal file at the root level of the partition by changing to the directory where it is mounted and typing: You now have an ext2 partition. If you want to permanently change the partition to ext2, remember to update the /etc/fstab file. Note You can increase the size of an ext3 file system using ext2online . ext2online allows you to increase the size of an ext3 file system once it is mounted (online) and on a resizable logical volume. The root file system is set up by default on LVM2 logical volumes during installation. Note that ext2online will only work on ext3 file systems. For more information, refer to man ext2online .

Commands:
umount /dev/mapper/VolGroup00-LogVol02
/sbin/tune2fs -O ^has_journal /dev/mapper/VolGroup00-LogVol02
/sbin/e2fsck -y /dev/mapper/VolGroup00-LogVol02
mount -t ext2 /dev/mapper/VolGroup00-LogVol02 /mount/point
rm -f .journal
Chapter 1. OpenShift Container Platform CLI tools overview A user performs a range of operations while working on OpenShift Container Platform such as the following: Managing clusters Building, deploying, and managing applications Managing deployment processes Developing Operators Creating and maintaining Operator catalogs OpenShift Container Platform offers a set of command-line interface (CLI) tools that simplify these tasks by enabling users to perform various administration and development operations from the terminal. These tools expose simple commands to manage the applications, as well as interact with each component of the system. 1.1. List of CLI tools The following set of CLI tools are available in OpenShift Container Platform: OpenShift CLI (oc) : This is the most commonly used CLI tool by OpenShift Container Platform users. It helps both cluster administrators and developers to perform end-to-end operations across OpenShift Container Platform using the terminal. Unlike the web console, it allows the user to work directly with the project source code using command scripts. Knative CLI (kn) : The Knative ( kn ) CLI tool provides simple and intuitive terminal commands that can be used to interact with OpenShift Serverless components, such as Knative Serving and Eventing. Pipelines CLI (tkn) : OpenShift Pipelines is a continuous integration and continuous delivery (CI/CD) solution in OpenShift Container Platform, which internally uses Tekton. The tkn CLI tool provides simple and intuitive commands to interact with OpenShift Pipelines using the terminal. opm CLI : The opm CLI tool helps the Operator developers and cluster administrators to create and maintain the catalogs of Operators from the terminal. Operator SDK : The Operator SDK, a component of the Operator Framework, provides a CLI tool that Operator developers can use to build, test, and deploy an Operator from the terminal. It simplifies the process of building Kubernetes-native applications, which can require deep, application-specific operational knowledge.

Commands:
31.6. Conclusion Going through this or any other well-structured evaluation plan is an important step in integrating VDO into any storage system. The evaluation process is important to understanding performance and catching any potential compatibility issues. The collection of results from this evaluation not only demonstrates deduplication and compression, but also provides a performance profile of your system implementing VDO. The results help determine whether the results achieved in real applications are as expected and plausible or whether they fall short of expectations. Finally, we can also use these results to help predict the kinds of applications that will operate favorably with VDO.

Commands:
6.2. Confining New Linux Users: useradd Linux users mapped to the SELinux unconfined_u user run in the unconfined_t domain. This is seen by running the id -Z command while logged-in as a Linux user mapped to unconfined_u : When Linux users run in the unconfined_t domain, SELinux policy rules are applied, but policy rules exist that allow Linux users running in the unconfined_t domain almost all access. If unconfined Linux users execute an application that SELinux policy defines can transition from the unconfined_t domain to its own confined domain, unconfined Linux users are still subject to the restrictions of that confined domain. The security benefit of this is that, even though a Linux user is running unconfined, the application remains confined, and therefore, the exploitation of a flaw in the application can be limited by policy. Note This does not protect the system from the user. Instead, the user and the system are being protected from possible damage caused by a flaw in the application. When creating Linux users with the useradd command, use the -Z option to specify which SELinux user they are mapped to. The following example creates a new Linux user, useruuser , and maps that user to the SELinux user_u user. Linux users mapped to the SELinux user_u user run in the user_t domain. In this domain, Linux users are unable to run setuid applications unless SELinux policy permits it (such as passwd ), and cannot run the su or sudo command, preventing them from becoming the root user with these commands. Procedure 6.1. Confining a New Linux User to user_u SELinux User As root, create a new Linux user ( useruuser ) that is mapped to the SELinux user_u user. To view the mapping between useruuser and user_u , enter the following command as root: As root, assign a password to the Linux useruuser user: Log out of your current session, and log in as the Linux useruuser user. When you log in, the pam_selinux module maps the Linux user to an SELinux user (in this case, user_u ), and sets up the resulting SELinux context. The Linux user's shell is then launched with this context. Enter the following command to view the context of a Linux user: Log out of the Linux useruuser 's session, and log back in with your account. If you do not want the Linux useruuser user, enter the following command as root to remove it, along with its home directory:

Commands:
~]USD id -Z unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
~]# useradd -Z user_u useruuser
~]# semanage login -l Login Name SELinux User MLS/MCS Range Service __default__ unconfined_u s0-s0:c0.c1023 * root unconfined_u s0-s0:c0.c1023 * system_u system_u s0-s0:c0.c1023 * useruuser user_u s0 *
~]# passwd useruuser Changing password for user useruuser. New password: Enter a password Retype new password: Enter the same password again passwd: all authentication tokens updated successfully.
~]USD id -Z user_u:user_r:user_t:s0
~]# userdel -Z -r useruuser