mtpti5iD/redhat-docs_dataset huggingface dataset:
18.7. The Installation Summary Screen The Installation Summary screen is the central location for setting up an installation. Figure 18.4. The Installation Summary Screen Instead of directing you through consecutive screens, the Red Hat Enterprise Linux installation program allows you to configure your installation in the order you choose. Use your mouse to select a menu item to configure a section of the installation. When you have completed configuring a section, or if you would like to complete that section later, click the Done button located in the upper left corner of the screen. Only sections marked with a warning symbol are mandatory. A note at the bottom of the screen warns you that these sections must be completed before the installation can begin. The remaining sections are optional. Beneath each section's title, the current configuration is summarized. Using this you can determine whether you need to visit the section to configure it further. Once all required sections are complete, click the Begin Installation button. Also see Section 18.18, "Begin Installation" . To cancel the installation, click the Quit button. Note When related background tasks are running, certain menu items might be temporarily unavailable.

Commands:
probe::ioblock.request Name probe::ioblock.request - Fires whenever making a generic block I/O request. Synopsis ioblock.request Values sector beginning sector for the entire bio name name of the probe point devname block device name phys_segments number of segments in this bio after physical address coalescing is performed flags see below BIO_UPTODATE 0 ok after I/O completion BIO_RW_BLOCK 1 RW_AHEAD set, and read/write would block BIO_EOF 2 out-out-bounds error BIO_SEG_VALID 3 nr_hw_seg valid BIO_CLONED 4 doesn't own data BIO_BOUNCED 5 bio is a bounce bio BIO_USER_MAPPED 6 contains user pages BIO_EOPNOTSUPP 7 not supported hw_segments number of segments after physical and DMA remapping hardware coalescing is performed bdev_contains points to the device object which contains the partition (when bio structure represents a partition) vcnt bio vector count which represents number of array element (page, offset, length) which make up this I/O request idx offset into the bio vector array bdev target block device p_start_sect points to the start sector of the partition structure of the device size total size in bytes ino i-node number of the mapped file rw binary trace for read/write request Context The process makes block I/O request

Commands:
Chapter 2. Workflow for developing automation content 2.1. Workflow 2.1.1. Create In the create stage, you create a new playbook project locally, using VS Code. The following is a typical workflow: Install and run the Ansible extension in VS Code. Scaffold a playbook project from VS Code. Add playbook files to your project and edit them in VS Code. 2.1.2. Test Debug your playbook with the help of ansible-lint . Select or create an automation execution environment so that your local environment replicates the environment on Ansible Automation Platform. Run your playbooks from VS Code, using ansible-playbook or using ansible-navigator with an execution environment. Test your playbooks by running them on an execution environment that replicates your production environment. 2.1.3. Deploy Push your playbooks project to a source control repository. Set up credentials on Ansible Automation Platform to pull from your source control repository and create a project for your playbook repository. If you have created an execution environment, push it to private automation hub. Create a job template on Ansible Automation Platform that runs a playbook from your project, and specify the execution environment that you want to use.

Commands:
Chapter 3. Certification lifecycle Instance Type certifications are limited to the versions and architecture of RHEL and their subsequent minor releases. Example RHEL 8.4 for x86_64 will carry forward through each minor release such as RHEL 8.5, 8.6, and so on. Certifications do not apply to or future major versions of RHEL versions nor any additional or alternate architectures that RHEL may be or become available for. Certifications for each major release + architecture combination must be obtained separately. Once an Instance has been certified, the Instance will retain its certification until: Recertification is required Red Hat no longer supports that version of RHEL The vendor ceases participation in the CCSP Program or The Instance is no longer offered and is no longer in use by customers with the corresponding RHEL. 3.1. Lifecycle of Instance Type It is required that an already certified Instance Type is not modified in a way that would invalidate the certification. This is in order to avoid inconvenience to customers . Red Hat recognizes that an Instance Type may change over time and the Instance Type Certification program does support the following changes to a certified instance type: Changes to the specification Offering adding additional sizes, smaller or larger Offering the same instance type under additional names To change the specification of an already certified Instance a supplemental certification is to be opened before the specification is modified for customers. The details of the upcoming changes is to be provided along with any relevant tests successfully conducted and credited. For more information, see Supplemental certification . To add an additional Instance Type name to an existing certified Instance Type create a pass-through certification. For more information, see Pass-Through Instance Type certification To add an additional Instance Type size to an existing certified Instance Type extending or contracting the configuration specification of that instance Type, create a pass-through certification providing the additional specifications and submit the relevant results to the supplemental tests. 3.2. Recertification Changes to the Instance Type that would alter the original test plan criteria require recertification. The changes include hardware, BIOS, or firmware. For example, an increase to the number of CPUs supported or the addition of new components such as network or storage controllers requires recertification. See Lifecycle of Instance Type .

Commands:
Chapter 9. Authenticating as an Active Directory user using PKINIT with a smart card Active Directory (AD) users can authenticate with a smart card to a desktop client system joined to IdM and get a Kerberos ticket-granting ticket (TGT). These tickets can be used for single sign-on (SSO) authentication from the client. Prerequisites The IdM server is configured for smart card authentication. For more information, see Configuring the IdM server for smart card authentication or Using Ansible to configure the IdM server for smart card authentication . The client is configured for smart card authentication. For more information, see Configuring the IdM client for smart card authentication or Using Ansible to configure IdM clients for smart card authentication . The krb5-pkinit package is installed. The AD server is configured to trust the certificate authority (CA) that issued the smart card certificate. Import the CA certificates into the NTAuth store (see Microsoft support ) and add the CA as a trusted CA. See Active Directory documentation for details. Procedure Configure the Kerberos client to trust the CA that issued the smart card certificate: On the IdM client, open the /etc/krb5.conf file. Add the following lines to the file: If the user certificates do not contain a certificate revocation list (CRL) distribution point extension, configure AD to ignore revocation errors: Save the following REG-formatted content in a plain text file and import it to the Windows registry: Alternatively, you can set the values manually by using the regedit.exe application. Reboot the Windows system to apply the changes. Authenticate by using the kinit utility on an Identity Management client. Specify the Active Directory user with the user name and domain name: The -X option specifies the opensc-pkcs11.so module as the pre-authentication attribute. Additional resources kinit(1) man page on your system See MIT Kerberos Documentation for /etc/krb5.conf settings.

Commands:
[realms] AD.DOMAIN.COM = { pkinit_eku_checking = kpServerAuth pkinit_kdc_hostname = adserver.ad.domain.com }
Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc] "UseCachedCRLOnlyAndIgnoreRevocationUnknownErrors"=dword:00000001 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA\Kerberos\Parameters] "UseCachedCRLOnlyAndIgnoreRevocationUnknownErrors"=dword:00000001
kinit -X X509_user_identity='PKCS11:opensc-pkcs11.so' ad_user@AD.DOMAIN.COM
Chapter 3. Performing cross-site operations with the CLI Use the Data Grid command line interface (CLI) to connect to Data Grid Server clusters, manage sites, and push state transfer to backup locations. 3.1. Bringing backup locations offline and online Take backup locations offline manually and bring them back online. Prerequisites Create a CLI connection to Data Grid. Procedure Check if backup locations are online or offline with the site status command: Note --site is an optional argument. If not set, the CLI returns all backup locations. Tip Use the --all-caches option to get the backup location status for all caches. Manage backup locations as follows: Bring backup locations online with the bring-online command: Take backup locations offline with the take-offline command: Tip Use the --all-caches option to bring a backup location online, or take a backup location offline, for all caches. For more information and examples, run the help site command. 3.2. Configuring cross-site state transfer modes You can configure cross-site state transfer operations to happen automatically when Data Grid detects that backup locations come online. Alternatively you can use the default mode, which is to manually perform state transfer. Prerequisites Create a CLI connection to Data Grid. Procedure Use the site command to configure state transfer modes, as in the following examples: Retrieve the current state transfer mode. Configure automatic state transfer operations for a cache and backup location. Tip Run the help site command for more information and examples. 3.3. Pushing state to backup locations Transfer cache state to backup locations. Prerequisites Create a CLI connection to Data Grid. Procedure Use the site push-site-state command to push state transfer, as in the following example: Tip Use the --all-caches option to push state transfer for all caches. For more information and examples, run the help site command.

Commands:
site status --cache=cacheName --site=NYC
site bring-online --cache=customers --site=NYC
site take-offline --cache=customers --site=NYC
site state-transfer-mode get --cache=cacheName --site=NYC
site state-transfer-mode set --cache=cacheName --site=NYC --mode=AUTO
site push-site-state --cache=cacheName --site=NYC
2.33. RHEA-2011:0630 - new package: python-pyasn1 A new python-pyasn1 package is now available for Red Hat Enterprise Linux 6. The python-pyasn1 package provides an implementation of ASN.1 types (concrete syntax) and codecs (transfer syntax) for the Python programming language. This enhancement update adds the python-pyasn1 package to Red Hat Enterprise Linux 6. (BZ# 643555 ) All users who require python-pyasn1 should install this new package.

Commands:
7.240. subscription-manager-migration-data 7.240.1. RHBA-2013:0360 - subscription-manager-migration-data bug fix and enhancement update An updated subscription-manager-migration-data package that fixes several bugs and adds various enhancements is now available for Red Hat Enterprise Linux 6. The new Subscription Management tooling allows users to understand the specific products, which have been installed on their machines, and the specific subscriptions, which their machines consume. Note The subscription-manager-migration-data package has been upgraded to upstream version 1.12.2.5, which provides a number of bug fixes and new product certificates over the version. (BZ# 860304 , BZ# 825603 , BZ# 872959 , BZ# 875760 ) All users of subscription-manager-migration-data are advised to upgrade to this updated package, which fixes these bugs adds these enhancements.

Commands:
11.6. Table Constraints Constraints can be defined on table/view to define indexes and relationships to other tables/views. See "create table body" in Section A.7, "Productions" . This information is used by the JBoss Data Virtualization optimizer to plan queries or use the indexes in materialization tables to optimize the access to the data. CONSTRAINTS are same as one can define on RDBMS. Example 11.3. Example of CONSTRAINTs

Commands:
CREATE VIEW CustomerOrders (name varchar(50), saledate date, amount decimal, CONSTRAINT EXAMPLE_INDEX INDEX (name, amount) ACCESSPATTERN (name) PRIMARY KEY
Chapter 6. Fixed CVEs JBoss EAP 8.0 includes fixes for the following security-related issues: JBEAP-25077:(8.0.z) Upgrade netty from 4.1.92.Final to 4.1.94.Final (resolves CVE-2023-34462) JBEAP-25748:(8.0.z) JBWS-4389 - Wrong assumption about the Identity's password are all clearpassword JBEAP-25356:(8.0.0) Upgrade Guava from 31.1.0.jre-redhat-00001 to 32.1.1.jre-redhat-00001 JBEAP-25646:(8.0.z) Upgrade FasterXML Jackson from 2.14.2.redhat-00001 to 2.15.2 JBEAP-25943: Upgrade santuario to 3.0.3 JBEAP-24435: MP OpenAPI - Loading static files bigger than 3MB fails since SmallRye OpenAPI 3.0.1 uses new SnakeYaml that sets a constraint

Commands:
8.9. Keyboard Configuration To add multiple keyboard layouts to your system, select Keyboard from the Installation Summary screen. Upon saving, the keyboard layouts are immediately available in the installation program and you can switch between them by using the keyboard icon located at all times in the upper right corner of the screen. Initially, only the language you selected in the welcome screen is listed as the keyboard layout in the left pane. You can either replace the initial layout or add more layouts. However, if your language does not use ASCII characters, you might need to add a keyboard layout that does, to be able to properly set a password for an encrypted disk partition or the root user, among other things. Figure 8.7. Keyboard Configuration To add an additional layout, click the + button, select it from the list, and click Add . To delete a layout, select it and click the - button. Use the arrow buttons to arrange the layouts in order of preference. For a visual preview of the keyboard layout, select it and click the keyboard button. To test a layout, use the mouse to click inside the text box on the right. Type some text to confirm that your selection functions correctly. To test additional layouts, you can click the language selector at the top on the screen to switch them. However, it is recommended to set up a keyboard combination for switching layout. Click the Options button at the right to open the Layout Switching Options dialog and choose a combination from the list by selecting its check box. The combination will then be displayed above the Options button. This combination applies both during the installation and on the installed system, so you must configure a combination here in order to use one after installation. You can also select more than one combination to switch between layouts. Important If you use a layout that cannot accept Latin characters, such as Russian , Red Hat recommends additionally adding the English (United States) layout and configuring a keyboard combination to switch between the two layouts. If you only select a layout without Latin characters, you might be unable to enter a valid root password and user credentials later in the installation process. This can prevent you from completing the installation. Once you have made your selection, click Done to return to the Installation Summary screen. Note To change your keyboard configuration after you have completed the installation, visit the Keyboard section of the Settings dialogue window.

Commands:
13.2. Start Two Application Server Instances Before deploying the Hello World quickstart, start two instances of your application server (JBoss Enterprise Application Platform 6.x). Procedure 13.1. Start the First Application Server Instance Navigate to the Root Directory In the command line terminal, navigate to the root for your JBoss server directory. Start the First Application Server Depending on your operating system, use the appropriate command from the following to start the first instance of your selected application server: For Linux: For Windows: Procedure 13.2. Start the Second Application Server Instance Clone the Application Server Create a copy of the selected JBoss Server to create a second instance. Navigate to the Root Directory In the command line terminal, navigate to the root for your JBoss server directory. Start the Second Application Server Use the appropriate command for your operating system from the following commands. This command starts the server with the provided port offset to ensure that both the server instances run on the same host. For Linux: For Windows: 23154%2C+Getting+Started+Guide-6.608-09-2016+09%3A22%3A31JBoss+Data+Grid+6Documentation6.6.1 Report a bug

Commands:
USDJBOSS_HOME/bin/standalone.sh
USDJBOSS_HOME\bin\standalone.bat
USDJBOSS_HOME2/bin/standalone.sh -Djboss.socket.binding.port-offset=100
USDJBOSS_HOME2\bin\standalone.bat -Djboss.socket.binding.port-offset=100
Chapter 14. Managing Your Virtual Databases 14.1. Create a Virtual Database Procedure 14.1. Create a Virtual Database Launch Red Hat JBoss Developer Studio's New wizard. Open the Teiid Designer category directory and select Teiid VDB . Note You can also select one or more models in a model project. To do so right-click and select New - Teiid VDB action . Launching this wizard will open the New VDB dialog. If you launched with one or more models selected the dialog will contain the pre-selected models for inclusion in the new VDB. Note A VDB is scoped to be aware of models and files within the same model project as the VDB. You will not be allowed to add models to a VDB that exist in a different project. Fill in VDB Name and then click Finish .

Commands:
Chapter 2. Non-interactively selecting a system-wide Red Hat build of OpenJDK version on RHEL If you have multiple versions of Red Hat build of OpenJDK installed on RHEL, you can select the default Red Hat build of OpenJDK version to use system-wide in a non-interactive way. This is useful for administrators who have root privileges on a Red Hat Enterprise Linux system and need to switch the default Red Hat build of OpenJDK on many systems in an automated way. Note If you do not have root privileges, you can select a Red Hat build of OpenJDK version by configuring the JAVA_HOME environment variable . Prerequisites You must have root privileges on the system. Multiple versions of Red Hat build of OpenJDK were installed using the yum package manager. Procedure Select the major Red Hat build of OpenJDK version to switch to. For example, for Red Hat build of OpenJDK 11, use java-11-openjdk . Verify that the active Red Hat build of OpenJDK version is the one you specified.

Commands:
PKG_NAME=java-11-openjdk JAVA_TO_SELECT=USD(alternatives --display java | grep "family USDPKG_NAME" | cut -d' ' -f1) alternatives --set java USDJAVA_TO_SELECT
java -version openjdk version "11.0.9" 2020-10-15 LTS OpenJDK Runtime Environment 18.9 (build 11.0.9+10-LTS) OpenJDK 64-Bit Server VM 18.9 (build 11.0.9+10-LTS, mixed mode, sharing)
8.232. watchdog 8.232.1. RHBA-2013:1656 - watchdog bug fix update Updated watchdog package that fixes one bug is now available for Red Hat Enterprise Linux 6. The watchdog package provides a user-space application which can be configured to provide updates to a hardware or software watchdog timer via the Linux kernel's watchdog interface. Note The watchdog package has been upgraded to upstream version 5.6, which provides one bug fix over the version. The version failed to reset the Ipmi Linux watchdog timer on a Sun Fire X4100 server. Consequently, the system started to reboot continuously if the watchdog daemon was started. A patch has been applied to address this bug, and resetting the watchdog timer now works as expected on Sun Fire X4100. (BZ# 870217 ) Users of watchdog are advised to upgrade to this updated package, which fixes this bug.

Commands:
2.7. Creating User Private Groups Automatically Using SSSD An SSSD client directly integrated into AD can automatically create a user private group for every AD user retrieved, ensuring that its GID matches the user's UID unless the GID number is already taken. To avoid conflicts, make sure that no groups with the same GIDs as user UIDs exist on the server. The GID is not stored in AD. This ensures that AD users benefit from group functionality, while the LDAP database does not contain unnecessary empty groups. 2.7.1. Activating the Automatic Creation of User Private Groups for AD users To activate the automatic creation of user private groups for AD users: Edit the /etc/sssd/sssd.conf file, adding in the [domain/LDAP] section: Restart the sssd service, removing the sssd database: After performing this procedure, every AD user has a GID which is identical to the UID: 2.7.2. Deactivating the Automatic Creation of User Private Groups for AD users To deactivate the automatic creation of user private groups for AD users: Edit the /etc/sssd/sssd.conf file, adding in the [domain/LDAP] section: Restart the sssd service, removing the sssd database: After performing this procedure, all AD users have an identical, generic GID:

Commands:
auto_private_groups = true
service sssd stop ; rm -rf /var/lib/sss/db/* ; service sssd start
id ad_user1 uid=121298(ad_user1) gid=121298(ad_user1) groups=121298(ad_user1),10000(Group1) id ad_user2 uid=121299(ad_user2) gid=121299(ad_user2) groups=121299(ad_user2),10000(Group1)
auto_private_groups = false
service sssd stop ; rm -rf /var/lib/sss/db/* ; service sssd start
id ad_user1 uid=121298(ad_user1) gid=10000(group1) groups=10000(Group1) id ad_user2 uid=121299(ad_user2) gid=10000(group1) groups=10000(Group1)
14.5.14. Displaying Virtual Interfaces Associated with a Domain Running the domiflist command results in a table that displays information of all the virtual interfaces that are associated with a specified domain. The domiflist requires a domain name and optionally can take the --inactive option. If --inactive is specified, the result will show the devices that are to be used at the boot and will not show those that are currently running in use by the running domain. Commands that require a MAC address of a virtual interface (such as detach-interface or domif-setlink ) will accept the output displayed by this command.

Commands:
31.6.2. Loading a Customized Module - Persistent Changes If you want to ensure that a kernel module is always loaded with specific settings, modify an existing or newly-created file in the /etc/modprobe.d/ directory with a line in the following format. ~]# options <module_name> [ parameter = value \ufeff ] where [ parameter = value \ufeff ] represents a list of customized parameters available to that module. The following procedure illustrates the recommended steps for loading a kernel module with custom parameters on the b43 module for Open Firmware for wireless networks, ensuring that changes persist between module reloads. Procedure 31.2. Loading a Kernel Module with Custom Parameters - Persistent Changes Add the following line to the /etc/modprobe.d/openfwwf.conf file, which ensures that the b43 module is always loaded with QoS and hardware-accelerated cryptography disabled: Verify whether the module is not already loaded into the kernel by running the following command: Note that the output of the command in this example indicates that the module is currently not loaded into the kernel. If the module is already loaded into the kernel, you must unload the module and all its dependencies before proceeding with the step. See Section 31.4, "Unloading a Module" for instructions on how to safely unload it. Load the b43 module by running the following command:

Commands:
options b43 nohwcrypt=1 qos=0
~]# lsmod|grep ^b43 ~]#
~]# modprobe b43