mtpti5iD/redhat-docs_dataset huggingface dataset:
E.2.2. GRUB and the Boot Process on UEFI-based x86 Systems This section describes the specific role GRUB plays when booting a UEFI-based x86 system. For a look at the overall boot process, refer to Section F.2, "A Detailed Look at the Boot Process" . GRUB loads itself into memory in the following stages: The UEFI-based platform reads the partition table on the system storage and mounts the EFI System Partition (ESP), a VFAT partition labeled with a particular globally unique identifier (GUID). The ESP contains EFI applications such as bootloaders and utility software, stored in directories specific to software vendors. Viewed from within the Red Hat Enterprise Linux 6.9 file system, the ESP is /boot/efi/ , and EFI software provided by Red Hat is stored in /boot/efi/EFI/redhat/ . The /boot/efi/EFI/redhat/ directory contains grub.efi , a version of GRUB compiled for the EFI firmware architecture as an EFI application. In the simplest case, the EFI boot manager selects grub.efi as the default bootloader and reads it into memory. If the ESP contains other EFI applications, the EFI boot manager might prompt you to select an application to run, rather than load grub.efi automatically. GRUB determines which operating system or kernel to start, loads it into memory, and transfers control of the machine to that operating system. Because each vendor maintains its own directory of applications in the ESP, chain loading is not normally necessary on UEFI-based systems. The EFI boot manager can load any of the operating system bootloaders that are present in the ESP.

Commands:
19.3.2. Saving encryption keys After completing the required preparation (see Section 19.3.1, "Preparation for saving encryption keys" ) it is now possible to save the encryption keys using the following procedure. Note For all examples in this file, /path/to/volume is a LUKS device, not the plaintext device contained within; blkid -s type /path/to/volume should report type ="crypto_LUKS" . Procedure 19.4. Saving encryption keys Run: Save the generated escrow-packet file in the prepared storage, associating it with the system and the volume. These steps can be performed manually, or scripted as part of system installation.

Commands:
volume_key --save /path/to/volume -c /path/to/cert escrow-packet
Chapter 4. Diskless Environments Some networks require multiple systems with the same configuration. They also require that these systems be easy to reboot, upgrade, and manage. One solution is to use a diskless environment in which most of the operating system, which can be read-only, is shared from a central server between the clients. The individual clients have their own directories on the central server for the rest of the operating system, which must be read/write. Each time the client boots, it mounts most of the OS from the NFS server as read-only and another directory as read-write. Each client has its own read-write directory so that one client can not affect the others. The following steps are necessary to configure Red Hat Enterprise Linux to run on a diskless client: Install Red Hat Enterprise Linux on a system so that the files can be copied to the NFS server. (Refer to the Installation Guide for details.) Any software to be used on the clients must be installed on this system and the busybox-anaconda package must be installed. Create a directory on the NFS server to contain the diskless environment such as /diskless/i386/RHEL4-AS/ . For example: This directory is referred to as the diskless directory . Create a subdirectory of this directory named root/ : Copy Red Hat Enterprise Linux from the client system to the server using rsync . For example: The length of this operation depends on the network connection speed as well as the size of the file system on the installed system. Depending on these factors, this operation may take a while. Start the tftp server Configure the DHCP server Finish creating the diskless environment as discussed in Section 4.2, "Finish Configuring the Diskless Environment" . Configure the diskless clients as discussed in Section 4.3, "Adding Hosts" . Configure each diskless client to boot via PXE and boot them. 4.1. Configuring the NFS Server The shared read-only part of the operating system is shared via NFS. Configure NFS to export the root/ and snapshot/ directories by adding them to /etc/exports . For example: Replace * with one of the hostname formats discussed in Section 21.3.2, "Hostname Formats" . Make the hostname declaration as specific as possible, so unwanted systems can not access the NFS mount. If the NFS service is not running, start it: If the NFS service is already running, reload the configuration file:

Commands:
mkdir -p /diskless/i386/RHEL4-AS/
mkdir -p /diskless/i386/RHEL4-AS/root/
rsync -a -e ssh installed-system.example.com:/ /diskless/i386/RHEL4-AS/root/
/diskless/i386/RHEL4-AS/root/ *(ro,sync,no_root_squash) /diskless/i386/RHEL4-AS/snapshot/ *(rw,sync,no_root_squash)
service nfs start
service nfs reload
F.10. Window Menu The Window menu shown below contains no Teiid Designer specific actions. See Eclipse Workbench documentation for details. Figure F.12. Window Menu The Preferences... action launches the Preferences dialog, which can be used to set preferences and default values for many features of Teiid Designer. Note These menu items may vary depending on your set of installed Eclipse features and plugins. To customize a perspective to include one or more Teiid Designer views, click the Show View > Other... action and expand the Teiid Designer category to show the available views. Figure F.13. Show View Dialog

Commands:
10.4. Preparation for IBM Power Systems Servers Important Ensure that the real-base boot parameter is set to c00000 , otherwise you might see errors such as: IBM Power Systems servers offer many options for partitioning, virtual or native devices, and consoles. If you are using a non-partitioned system, you do not need any pre-installation setup. For systems using the HVSI serial console, hook up your console to the T2 serial port. If using a partitioned system the steps to create the partition and start the installation are largely the same. You should create the partition at the HMC and assign some CPU and memory resources, as well as SCSI and Ethernet resources, which can be either virtual or native. The HMC create partition wizard steps you through the creation. For more information on creating the partition, see the Partitioning for Linux with an HMC PDF in the IBM Systems Hardware Information Center. If you are using virtual SCSI resources, rather than native SCSI, you must configure a 'link' to the virtual SCSI serving partition, and then configure the virtual SCSI serving partition itself. You create a 'link' between the virtual SCSI client and server slots using the HMC. You can configure a virtual SCSI server on either Virtual I/O Server (VIOS) or IBM i, depending on which model and options you have. If you are installing using Intel iSCSI Remote Boot, all attached iSCSI storage devices must be disabled. Otherwise, the installation will succeed but the installed system will not boot. For more information on using virtual devices, see the IBM Redbooks publication Virtualizing an Infrastructure with System p and Linux . Once you have your system configured, you need to Activate from the HMC or power it on. Depending on the type of installation, you need to configure SMS to correctly boot the system into the installation program.

Commands:
DEFAULT CATCH!, exception-handler=fff00300
function::log Name function::log - Send a line to the common trace buffer. Synopsis Arguments msg The formatted message string. General Syntax log(msg:string) Description This function logs data. log sends the message immediately to staprun and to the bulk transport (relayfs) if it is being used. If the last character given is not a newline, then one is added. This function is not as effecient as printf and should be used only for urgent messages.

Commands:
function log(msg:string)
Chapter 2. 20 March 2025 This release Red Hat Ansible Lightspeed features the following enhancement: Ability to generate roles and view role explanations Role generation and viewing role explanations are now supported on the Red Hat Ansible Lightspeed cloud service. You can create roles within Ansible collections from the Ansible VS Code extension using a natural language interface in English. You can also view the explanations for new or existing roles. For more information, see Creating roles and viewing role explanations . Availability of REST API on on-premise deployments Platform administrators can now configure and use the Red Hat Ansible Lightspeed REST API to build a custom automation development and tooling workflow outside of VS Code. For more information, see Using the Ansible Lightspeed REST API and Ansible AI Connect. 1.0.0 (v1) in the API catalog. Removal of unnecessary settings from the initial configuration of Ansible VS Code extension The initial configuration of the Ansible VS Code extension now has fewer settings that are enabled by default. For more information, see Configuring the Ansible VS Code extension .

Commands:
1.3. The Cluster and Pacemaker Configuration Files The configuration files for the Red Hat High Availability add-on are cluster.conf and cib.xml . Do not edit the cib.xml file directly; use the pcs interface instead. The cluster.conf file provides the cluster parameters used by corosync , the cluster manager that Pacemaker is built on. The cib.xml file is an XML file that represents both the cluster's configuration and current state of all resources in the cluster. This file is used by Pacemaker's Cluster Information Base (CIB). The contents of the CIB are automatically kept in sync across the entire cluster

Commands:
5.238. perl-Sys-Virt 5.238.1. RHBA-2012:0754 - perl-Sys-Virt bug fix and enhancement update Updated perl-Sys-Virt packages that fix multiple bugs and add various enhancements are now available for Red Hat Enterprise Linux 6. The perl-Sys-Virt packages provide application programming interfaces (APIs) to manage virtual machines from Perl with the libvirt library. The perl-Sys-Virt package has been upgraded to upstream version 0.9.10, which provides a number of bug fixes and enhancements over the version. (BZ# 752436 ) Bug Fixes BZ# 661801 Prior to this update, the perl-Sys-Virt spec file did not contain the "perl(Time::HiRes)" requirement. As a consequence, perl-Sys-Virt could not be rebuild in mock mode. This update adds the missing requirement to the spec file. Now, perl-Sys-Virt can is rebuild in mock mode as expected. BZ# 747483 Prior to this update, the perl-Sys-Virt man page did not document the "USDflags" parameter for the "get_xml_description" executable. This update modifies the man page so that the parameter is correctly documented. BZ# 748689 Prior to this update, the default settings for the remote domain memory statistics used a length of 16 bits only. As a consequence, the get_node_cpu_stats() function could send the libvirt error "code: 1, message: internal error nparams too large". This update modifies libvirt so that the maximum length is now 1024 bits. BZ# 773572 Prior to this update, the bandwidth in the "block_pull and set_block_job_speed" method was incorrectly given in Kilobytes per second (Kb/s). This update changes the bandwidth unit to Megabytes per second (Mb/s). BZ# 800766 Prior to this update, the bandwidth for maximum migration bandwidth was incorrectly given in Kilobytes per second (Kb/s). This update changes the maximum migration bandwidth unit to Megabytes per second (Mb/s). BZ# 809906 Prior to this update, the documentation for "Sys::Virt::StoragePool" incorrectly stated that the object method "get_info()" returns a hash. This update corrects this misprint and correctly states that object method returns a hash reference. Enhancement BZ# 800734 Prior to this update, the Perl API bindings could not handle tunable parameters in string format. As a consequence, the block I/O tunable parameters could not be read or updated. This update adds support for string parameters. Now, the block I/O tunable parameters can be read and updated from the Perl API. All users of perl-Sys-Virt are advised to upgrade to these updated packages, which fix these bugs and add these enhancements.

Commands:
7.187. policycoreutils 7.187.1. RHBA-2013:0396 - policycoreutils bug fix and enhancement update Updated policycoreutils packages that fix several bugs and add two enhancements are now available for Red Hat Enterprise Linux 6. The policycoreutils packages contain the policy core utilities that are required for basic operation of SELinux. These utilities include load_policy to load policies, setfiles to label file systems, newrole to switch roles, and run_init to run /etc/init.d scripts in the proper context. Bug Fixes BZ# 816460 , BZ# 885527 Previously, when the policycoreutils-gui utility was used to add an SELinux policy for a socket file, policycoreutils-gui failed with a traceback. This bug has been fixed, policycoreutils-gui now succeeds, and the SELinux policy is now added in this scenario. BZ#824779 Due to a bug in the code, when the restorecon utility failed, it returned the success exit code. This bug has been fixed and restorecon now returns appropriate exit codes. BZ# 843727 When multiple type accesses from the same role occurred, the audit2allow utility produced policy files that could not be parsed by the checkmodule compiler. With this update, audit2allow produces correct policy files which can be compiled by checkmodule. BZ# 876971 The restorecond init script allows to use the "reload" operation. Previously, the usage message produced by restorecond did not mention the operation. The operation has been added to the usage message, which is now complete. BZ#882862 Prior to this update, the audit2allow utility produced a confusing output when one of the several processed AVCs could be allowed by a boolean, as it was not clear which AVC the message was related to. The layout of the output has been corrected and the audit2allow output no longer causes confusion. BZ# 893065 Due to a regression, the vdsm package failed to be installed on Red Hat Enterprise Linux 6.4 if SELinux was disabled. A patch which enables the vdsm installation has been provided. Enhancements BZ#834160 A new function to the semanage utility has been implemented. Now, the user is able to notice that a specified file context semanage command is wrong and an appropriate error message is returned. BZ#851479 With this update, the restorecon utility now returns a warning message for paths for which a default SELinux security context is not defined in the policy. Users of policycoreutils are advised to upgrade to these updated packages, which fix these bugs and add these enhancements.

Commands:
Chapter 4. Troubleshooting Use this information to diagnose and resolve issues during backup and recovery. 4.1. Automation controller custom resource has the same name as an existing deployment The name specified for the new AutomationController custom resource must not match an existing deployment or the recovery process will fail. If your AutomationController customer resource matches an existing deployment, perform the following steps to resolve the issue. Procedure Delete the existing AutomationController and the associated postgres PVC: oc delete automationcontroller <YOUR_DEPLOYMENT_NAME> -n <YOUR_NAMESPACE> oc delete pvc postgres-13-<YOUR_DEPLOYMENT_NAME>-13-0 -n <YOUR_NAMESPACE> Use AutomationControllerRestore with the same deployment_name in it: oc apply -f restore.yaml

Commands:
delete automationcontroller <YOUR_DEPLOYMENT_NAME> -n <YOUR_NAMESPACE> delete pvc postgres-13-<YOUR_DEPLOYMENT_NAME>-13-0 -n <YOUR_NAMESPACE>
apply -f restore.yaml
Chapter 4. Policy Parameters These parameters allow you to set policies on a per-service basis. Parameter Description BarbicanPolicies A hash of policies to configure for OpenStack Key Manager (barbican). CinderApiPolicies A hash of policies to configure for OpenStack Block Storage (cinder) API. GlanceApiPolicies A hash of policies to configure for OpenStack Image Storage (glance) API. HeatApiPolicies A hash of policies to configure for OpenStack Orchestration (heat) API. IronicApiPolicies A hash of policies to configure for OpenStack Bare Metal (ironic) API. KeystonePolicies A hash of policies to configure for OpenStack Identity (keystone). NeutronApiPolicies A hash of policies to configure for OpenStack Networking (neutron) API. NovaApiPolicies A hash of policies to configure for OpenStack Compute (nova) API. SaharaApiPolicies A hash of policies to configure for OpenStack Clustering (sahara) API.

Commands:
10.4. CMC SharedSecret Authentication Use the Shared Secret feature to enable users to send unsigned CMC requests to the server. For example, this is necessary if a user wants to obtain the first signing certificate. This signing certificate can later be used to sign other certificates of this user. 10.4.1. Creating a Shared Secret Token The The Shared Secret Workflow section in the Red Hat Certificate System Planning, Installation, and Deployment Guide describes the workflow when using a Shared Secret Token. Depending on the situation, either an end entity user or an administrator creates the Shared Secret Token. Note To use the shared secret token, Certificate System must use an RSA issuance protection certificate. For details, see Enabling the CMC Shared Secret Feature section located in RHCS Planning, Installation, and Deployment Guide. To create a Shared Secret Token, enter: If you use an HSM, additionally pass the -h token_name option to the command to set the HSM security token name. For further details about the CMCSharedToken utility, see the CMCSharedToken (8) man page. Note The generated token is encrypted and only the user who generated knows the password. If a CA administrator generates the token for a user, the administrator must provide the password to the user using a secure way. After creating the Shared Token, an administrator must add the token to a user or certificate record. For details, see Section 10.4.2, "Setting a CMC Shared Secret" . 10.4.2. Setting a CMC Shared Secret Depending on the planned action, an administrator must store a Shared Secret Token after generating it in the LDAP entry of the user or certificate. For details about the workflow and when to use a Shared Secret, see the The Shared Secret Workflow section in the Red Hat Certificate System Planning, Installation, and Deployment Guide . 10.4.2.1. Adding a CMC Shared Secret to a User Entry for Certificate Enrollment To use the Shared Secret Token for certificate enrollment, store it as an administrator in the LDAP entry of the user: 10.4.2.2. Adding a CMC Shared Secret to a Certificate for Certificate Revocations To use the Shared Secret Token for certificate revocations, store it as an administrator in the LDAP entry of the certificate to be revoked:

Commands:
CMCSharedToken -d /home/user_name/.dogtag/ -p NSS_password -s " CMC_enrollment_password " -o /home/user_name/CMC_shared_token.b64 -n " issuance_protection_certificate_nickname "
ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: uid= user_name ,ou=People,dc=example,dc=com changetype: modify replace: shrTok shrTok: base64-encoded_token
ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn= certificate_id ,ou=certificateRepository,ou=ca,o= pki-tomcat-CA changetype: modify replace: shrTok shrTok: base64-encoded_token
Chapter 1. Keystone authentication and the Ceph Object Gateway Organizations using OpenStack Keystone to authenticate users can integrate Keystone with the Ceph Object Gateway. The Ceph Object Gateway enables the gateway to accept a Keystone token, authenticate the user and create a corresponding Ceph Object Gateway user. When Keystone validates a token, the gateway considers the user authenticated. Benefits Managing users with Keystone Automatic User Creation in the Ceph Object Gateway The Ceph Object Gateway will query Keystone periodically for a list of revoked tokens.

Commands:
3.3. LVM Logical Volumes In LVM, a volume group is divided up into logical volumes. There are three types of LVM logical volumes: linear volumes, striped volumes, and mirrored volumes. These are described in the following sections. 3.3.1. Linear Volumes A linear volume aggregates space from one or more physical volumes into one logical volume. For example, if you have two 60GB disks, you can create a 120GB logical volume. The physical storage is concatenated. Creating a linear volume assigns a range of physical extents to an area of a logical volume in order. For example, as shown in Figure 3.2, "Extent Mapping" logical extents 1 to 99 could map to one physical volume and logical extents 100 to 198 could map to a second physical volume. From the point of view of the application, there is one device that is 198 extents in size. Figure 3.2. Extent Mapping The physical volumes that make up a logical volume do not have to be the same size. Figure 3.3, "Linear Volume with Unequal Physical Volumes" shows volume group VG1 with a physical extent size of 4MB. This volume group includes 2 physical volumes named PV1 and PV2 . The physical volumes are divided into 4MB units, since that is the extent size. In this example, PV1 is 200 extents in size (800MB) and PV2 is 100 extents in size (400MB). You can create a linear volume any size between 1 and 300 extents (4MB to 1200MB). In this example, the linear volume named LV1 is 300 extents in size. Figure 3.3. Linear Volume with Unequal Physical Volumes You can configure more than one linear logical volume of whatever size you require from the pool of physical extents. Figure 3.4, "Multiple Logical Volumes" shows the same volume group as in Figure 3.3, "Linear Volume with Unequal Physical Volumes" , but in this case two logical volumes have been carved out of the volume group: LV1 , which is 250 extents in size (1000MB) and LV2 which is 50 extents in size (200MB). Figure 3.4. Multiple Logical Volumes

Commands:
5.87. gnome-desktop 5.87.1. RHBA-2012:1352 - gnome-desktop bug fix update Updated gnome-desktop packages that fix a bug are now available. The gnome-desktop package contains an internal library (libgnome-desktop) used to implement some portions of the GNOME desktop, and also some data files and other shared components of the GNOME user environment. Bug Fix BZ# 829891 Previously, when a user hit the system's hot-key (most commonly Fn+F7) to change display configurations, the system could potentially switch to an invalid mode, which would fail to display. With this update, gnome-desktop now selects valid XRandR modes and correctly switching displays with the hot-key works as expected. All users of gnome-desktop are advised to upgrade to these updated packages, which fix this bug. 5.87.2. RHBA-2012:0405 - gnome-desktop bug fix update An updated gnome-desktop package that fixes one bug is now available for Red Hat Enterprise Linux 6. The gnome-desktop package contains an internal library (libgnomedesktop) used to implement some portions of the GNOME desktop, and also some data files and other shared components of the GNOME user environment. Bug Fix BZ# 639732 Previously, due to an object not being destroyed, the Nautilus file manager could consume an excessive amount of memory. Consequently, constantly growing resident memory would slow down the system. The source code has been modified to prevent memory leaks from occurring and Nautilus now consumes a reasonable amount of memory. All users of gnome-desktop are advised to upgrade to this updated package, which fixes this bug.

Commands:
Chapter 2. Introduction 2.1. Features of ModeShape Tools ModeShape Tools possesses following functionalities: the ability to publish or upload resources from Eclipse workspaces to ModeShape repositories, and the ability to create and edit Compact Node Type Definition (CND) files using the included CND form-based editor. Note The CND editor does not require a connection to a ModeShape or any other JCR repository. ModeShape repositories are persisted within the workspace, from session to session. The ModeShape registry is persisted from session to session.

Commands: