mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 10. Patch Installation 10.1. Subscribe to Patch Mailing Lists Summary The JBoss team at Red Hat maintains a mailing list for security announcements for Red Hat JBoss Enterprise Middleware products. This topic covers what you need to do to subscribe to this list. Prerequisites None Procedure 10.1. Subscribe to the JBoss Watch List Click the following link to go to the JBoss Watch mailing list page: JBoss Watch Mailing List . Enter your email address in the Subscribing to Jboss-watch-list section. [ You may also wish to enter your name and select a password. Doing so is optional but recommended. ] Press the Subscribe button to start the subscription process. You can browse the archives of the mailing list by going to: JBoss Watch Mailing List Archives . Result After confirmation of your email address, you will be subscribed to receive security related announcements from the JBoss patch mailing list.

Commands:
5.142. libburn 5.142.1. RHBA-2012:1273 - libburn bug fix update Updated libburn packages that fix one bug are now available for Red Hat Enterprise Linux 6. problem description Libburn is an open-source library for reading, mastering and writing optical discs. For now this means only CD-R and CD-RW. Bug Fix BZ# 822906 Prior to this update, libburn library contained the "burn_write_close_track" command, which was redundant and not fully supported by all burning drives. As a consequence, the burning process CD-R or CD-RW could log errors while closing a track after the burning process, even if the data was written correctly. This update removes this redundant call. All users of gfs-kmod are advised to upgrade to these updated packages, which fix this bug.

Commands:
7.41. docbook-utils 7.41.1. RHBA-2012:1321 - docbook-utils bug fix update Updated docbook-utils packages that fix one bug are now available for Red Hat Enterprise Linux 6. The docbook-utils packages provide a set of utility scripts to convert and analyze SGML documents in general, and DocBook files in particular. The scripts are used to convert from DocBook or other SGML formats into file formats like HTML, man, info, RTF and many more. Bug Fix BZ# 639866 Prior to this update, the Perl script used for generating manpages contained a misprint in the header. As a consequence, the header syntax of all manual pages that docbook-utils built was wrong. This update corrects the script. Now the manual page headers have the right syntax. All users of docbook-utils are advised to upgrade to these updated packages, which fix this bug.

Commands:
22.3. Methods 22.3.1. Adding a User The API adds an existing directory service user to the Red Hat Virtualization Manager database with a POST request to the users collection. The client-provided new user representation includes an embedded roles list with at least one initial role to assign to the user. For example, the following request assigns two initial roles to the user joe@domain.example.com : Example 22.2. Adding a user from directory service and assigning two roles The new user is identified either by Red Hat Virtualization Manager user ID or via the directory service user principal name (UPN). The user ID format reported from the directory service domain might be different to the expected Red Hat Virtualization Manager format, such as in LDIF [5] , the ID has the opposite byte order and is base-64 encoded. Hence it is usually more convenient to refer to the new user by UPN. Note The user exists in the directory service domain before it is added to the Red Hat Virtualization Manager database. An API user has the option to query this domain through the domains collection prior to creation of the user. Roles are identified either by name or ID. The example above shows both approaches. 22.3.2. Adding Roles to a User Further roles are attached or detached with POST or DELETE requests to the roles sub-collection of an individual user. The example below illustrates how the API adds the RHEVMVDIUser role to the role assignments for a particular user. Note The embedded user roles list of the user element is only used for the initial creation. All interactions post-creation with the user's role assignments go through the roles sub-collection. Example 22.3. Adding roles to a user [5] The LDAP Data Interchange Format is described in RFC 2849 .

Commands:
POST /ovirt-engine/api/users HTTP/1.1 Content-Type: application/xml Accept: application/xml <user> <user_name>joe@domain.example.com</user_name> <roles> <role> <name>RHEVMPowerUser</name> </role> <role id="00000000-0000-0000-0001-000000000003"/> </roles> </user>
POST /ovirt-engine/api/users/225f15cd-e891-434d-8262-a66808fcb9b1/roles HTTP/1.1 Content-Type: application/xml Accept: application/xml <role> <name>RHEVMVDIUser</name> </role>
1.6. Feature Compatibility Support Red Hat Gluster Storage supports a number of features. Most features are supported with other features, but there are some exceptions. This section clearly identifies which features are supported and compatible with other features to help you in planning your Red Hat Gluster Storage deployment. Important Virtual Data Optimizer (VDO) volumes, which are supported in Red Hat Enterprise Linux 7.5, are not currently supported in Red Hat Gluster Storage. VDO is supported only when used as part of Red Hat Hyperconverged Infrastructure for Virtualization 2.0. See Understanding VDO for more information. Features in the following table are supported from the specified version and later. Table 1.4. Features supported by Red Hat Gluster Storage version Feature Version Arbiter bricks 3.2 Bitrot detection 3.1 Erasure coding 3.1 Google Compute Engine 3.1.3 Metadata caching 3.2 Microsoft Azure 3.1.3 NFS version 4 3.1 SELinux 3.1 Sharding 3.2.0 Snapshots 3.0 Snapshots, cloning 3.1.3 Snapshots, user-serviceable 3.0.3 Tiering (Deprecated) 3.1.2 Volume Shadow Copy (VSS) 3.1.3 Table 1.5. Features supported by volume type Volume Type Sharding Tiering (Deprecated) Quota Snapshots Geo-Rep Bitrot Arbitrated-Replicated Yes No Yes Yes Yes Yes Distributed No Yes Yes Yes Yes Yes Distributed-Dispersed No Yes Yes Yes Yes Yes Distributed-Replicated Yes Yes Yes Yes Yes Yes Replicated Yes Yes Yes Yes Yes Yes Sharded N/A No No No Yes No Tiered (Deprecated) No N/A Limited [a] Limited [a] Limited [a] Limited [a] [a] See Tiering Limitations in the Red Hat Gluster Storage 3.5 Administration Guide for details. Note Red Hat Gluster Storage is not supported on Red Hat Enterprise Linux 6 (RHEL 6) from 3.5 Batch Update 1 onwards. Table 1.6. Features supported by client protocol Feature FUSE Gluster-NFS NFS-Ganesha SMB Arbiter Yes Yes Yes Yes Bitrot detection Yes Yes No Yes dm-cache Yes Yes Yes Yes Encryption (TLS-SSL) Yes Yes Yes Yes Erasure coding Yes Yes Yes Yes Export subdirectory Yes Yes Yes N/A Geo-replication Yes Yes Yes Yes Quota (Deprecated) Warning Using QUOTA feature is considered to be deprecated in Red Hat Gluster Storage 3.5.3. Red Hat no longer recommends to use this feature and does not support it on new deployments and existing deployments that upgrade to Red Hat Gluster Storage 3.5.3. Yes Yes Yes Yes RDMA (Deprecated) Warning Using RDMA as a transport protocol is considered deprecated in Red Hat Gluster Storage 3.5. Red Hat no longer recommends the use of this feature, and does not support it on new deployments and existing deployments that upgrade to Red Hat Gluster Storage 3.5.3. Yes No No No Snapshots Yes Yes Yes Yes Snapshot cloning Yes Yes Yes Yes Snapshot mount Yes No No No Tiering (Deprecated) Warning Using tiering feature is considered deprecated in Red Hat Gluster Storage 3.5. Red Hat no longer recommends the use of this feature, and does not support it on new deployments and existing deployments that upgrade to Red Hat Gluster Storage 3.5.3. Yes Yes N/A N/A

Commands:
Chapter 11. Updating and downgrading IdM 11.1. Updating IdM packages You can use the dnf utility to update the Identity Management (IdM) packages on the system. Prerequisites Ensure you have applied all previously released errata relevant to the RHEL system. For more information, see the How do I apply package updates to my RHEL system? KCS article. Procedure Select one of the following options: To update all IdM packages that are relevant for your profile and that have updates available: To install or update packages to match the latest version available for your profile from any enabled repository: After you update the IdM packages on at least one server, all other servers in the topology receive the updated schema, even if you do not update their packages. This ensures that any new entries which use the new schema can be replicated among the other servers. Warning When updating multiple IdM servers, wait at least 10 minutes after updating one server before updating another server. However, the actual time required for a server's successful update depends on the topology deployed, the latency of the connections, and the number of changes generated by the update. When two or more servers are updated simultaneously or with only short intervals between the upgrades, there is not enough time to replicate the post-upgrade data changes throughout the topology, which can result in conflicting replication events. Important Upgrade to the version only. For example, if you want to upgrade to IdM for RHEL 9.4, upgrade from IdM for RHEL 9.3. Upgrading from earlier versions can cause problems. Additional resources dnf(8) man page on your system 11.2. Downgrading IdM packages Red Hat does not support downgrading Identity Management.

Commands:
dnf upgrade ipa- *
dnf distro-sync ipa- *
Appendix C. JMX MBeans in RedHat JBoss Data Grid C.1. Activation org.infinispan.eviction.ActivationManagerImpl Activates entries that have been passivated to the CacheStore by loading the entries into memory. Table C.1. Attributes Name Description Type Writable activations Number of activation events. String No statisticsEnabled Enables or disables the gathering of statistics by this component. boolean Yes Table C.2. Operations Name Description Signature resetStatistics Resets statistics gathered by this component. void resetStatistics() 23149%2C+Administration+and+Configuration+Guide-6.628-06-2017+13%3A51%3A02JBoss+Data+Grid+6Documentation6.6.1 Report a bug

Commands:
Chapter 2. Configuring Authentication and Authorization for JBoss Data Virtualization 2.1. Client Authentication Client authentication concerns authenticating users of a JBoss Data Virtualization instance. JDBC/ODBC/Web Service clients may use simple passwords to authenticate a user. Typically a user name is required, however user names may be considered optional if the identity of the user can be discerned by the password credential alone. In any case it is up to the configured security domain to determine whether a user can be authenticated. If you need authentication, the administrator must configure an authentication module. Auto-generated web services, such as OData, typically support HTTPBasic authentication. This should use Pass-through Authentication. Note Kerberos authentication is also supported.

Commands:
Appendix A. Component Versions This appendix is a list of components and their versions in the Red Hat Enterprise Linux 6.6 release. Table A.1. Component Versions Component Version Kernel 2.6.32-494 QLogic qla2xxx driver 8.07.00.08.06.6-k QLogic ql2xxx firmware ql23xx-firmware-3.03.27-3.1 ql2100-firmware-1.19.38-3.1 ql2200-firmware-2.02.08-3.1 ql2400-firmware-7.03.00-1 ql2500-firmware-7.03.00-1 Emulex lpfc driver 10.2.8020.1 iSCSI initiator utils iscsi-initiator-utils-6.2.0.873-11 DM-Multipath device-mapper-multipath-libs-0.4.9-80 LVM lvm2-2.02.108-1

Commands:
Chapter 52. Installing and logging in to the Showcase application The Showcase application is included with the Red Hat Process Automation Manager 7.13 distribution in the add-ons Zip file. The purpose of this application is to demonstrate the functionality of case management in Red Hat Process Automation Manager and enable you to interact with cases created in Business Central. You can install the Showcase application in a Red Hat JBoss Enterprise Application Platform instance or on OpenShift. This procedure describes how to install the Showcase application in Red Hat JBoss EAP. Prerequisites Business Central and KIE Server are installed in a Red Hat JBoss EAP instance. You have created a user with kie-server and user roles. Only users with the user role are able to log in to the Showcase application. Users also require the kie-server role to perform remote operations on the running KIE Server. Business Central is not running. Procedure Navigate to the Software Downloads page in the Red Hat Customer Portal (login required), and select the product and version from the drop-down options: Product: Process Automation Manager Version: 7.13.5 Download Red Hat Process Automation Manager 7.13 Add Ons ( rhpam-7.13.5-add-ons.zip ). Extract the rhpam-7.13.5-add-ons.zip file. The rhpam-7.13-case-mgmt-showcase-eap7-deployable.zip file is in the unzipped directory. Extract the rhpam-7.13-case-mgmt-showcase-eap7-deployable.zip archive to a temporary directory. In the following examples this directory is called TEMP_DIR . Copy the contents of the _TEMP_DIR/rhpam-7.13-case-mgmt-showcase-eap7-deployable/jboss-eap-7.4 directory to EAP_HOME . When asked to overwrite files or merge directories, select Yes . Warning Ensure the names of the Red Hat Process Automation Manager deployments you copy do not conflict with your existing deployments in the Red Hat JBoss EAP instance. Add the following system property to your deployment's jboss-eap-7.4/standalone/configuration/standalone-full.xml file: <property name="org.jbpm.casemgmt.showcase.url" value="/rhpam-case-mgmt-showcase"/> In a terminal application, navigate to EAP_HOME /bin and run the standalone configuration to start Business Central: ./standalone.sh -c standalone-full.xml In a web browser, enter localhost:8080/business-central . If Red Hat Process Automation Manager has been configured to run from a domain name, replace localhost with the domain name, for example: http://www.example.com:8080/business-central In the upper-right corner in Business Central, click the Apps launcher button to launch Case Management Showcase in a new browser window. Log in to the Showcase application using your Business Central user credentials.

Commands:
4.4.9. Extending a Striped Volume In order to increase the size of a striped logical volume, there must be enough free space on the underlying physical volumes that make up the volume group to support the stripe. For example, if you have a two-way stripe that that uses up an entire volume group, adding a single physical volume to the volume group will not enable you to extend the stripe. Instead, you must add at least two physical volumes to the volume group. For example, consider a volume group vg that consists of two underlying physical volumes, as displayed with the following vgs command. You can create a stripe using the entire amount of space in the volume group. Note that the volume group now has no more free space. The following command adds another physical volume to the volume group, which then has 135G of additional space. At this point you cannot extend the striped logical volume to the full size of the volume group, because two underlying devices are needed in order to stripe the data. To extend the striped logical volume, add another physical volume and then extend the logical volume. In this example, having added two physical volumes to the volume group we can extend the logical volume to the full size of the volume group. If you do not have enough underlying physical devices to extend the striped logical volume, it is possible to extend the volume anyway if it does not matter that the extension is not striped, which may result in uneven performance. When adding space to the logical volume, the default operation is to use the same striping parameters of the last segment of the existing logical volume, but you can override those parameters. The following example extends the existing striped logical volume to use the remaining free space after the initial lvextend command fails.

Commands:
vgs VG #PV #LV #SN Attr VSize VFree vg 2 0 0 wz--n- 271.31G 271.31G
lvcreate -n stripe1 -L 271.31G -i 2 vg Using default stripesize 64.00 KB Rounding up size to full physical extent 271.31 GB Logical volume "stripe1" created lvs -a -o +devices LV VG Attr LSize Origin Snap% Move Log Copy% Devices stripe1 vg -wi-a- 271.31G /dev/sda1(0),/dev/sdb1(0)
vgs VG #PV #LV #SN Attr VSize VFree vg 2 1 0 wz--n- 271.31G 0
vgextend vg /dev/sdc1 Volume group "vg" successfully extended vgs VG #PV #LV #SN Attr VSize VFree vg 3 1 0 wz--n- 406.97G 135.66G
lvextend vg/stripe1 -L 406G Using stripesize of last segment 64.00 KB Extending logical volume stripe1 to 406.00 GB Insufficient suitable allocatable extents for logical volume stripe1: 34480 more required
vgextend vg /dev/sdd1 Volume group "vg" successfully extended vgs VG #PV #LV #SN Attr VSize VFree vg 4 1 0 wz--n- 542.62G 271.31G lvextend vg/stripe1 -L 542G Using stripesize of last segment 64.00 KB Extending logical volume stripe1 to 542.00 GB Logical volume stripe1 successfully resized
lvextend vg/stripe1 -L 406G Using stripesize of last segment 64.00 KB Extending logical volume stripe1 to 406.00 GB Insufficient suitable allocatable extents for logical volume stripe1: 34480 more required lvextend -i1 -l+100%FREE vg/stripe1
5.4. Creating Distributed Volumes This type of volume spreads files across the bricks in the volume. Figure 5.1. Illustration of a Distributed Volume Warning Distributed volumes can suffer significant data loss during a disk or server failure because directory contents are spread randomly across the bricks in the volume and hence require an architecture review before using them in production. Please reach out to your Red Hat account team to arrange an architecture review should you intend to use distributed only volumes. Use distributed volumes only where redundancy is either not important, or is provided by other hardware or software layers. In other cases, use one of the volume types that provide redundancy, for example distributed-replicated volumes. Limitations of distributed only volumes include: No in-service upgrades - distributed only volumes need to be taken offline during upgrades. Temporary inconsistencies of directory entries and inodes during eventual node failures. I/O operations will block or fail due to node unavailability or eventual node failures. Permanent loss of data. Create a Distributed Volume Use gluster volume create command to create different types of volumes, and gluster volume info command to verify successful volume creation. Prerequisites A trusted storage pool has been created, as described in Section 4.1, "Adding Servers to the Trusted Storage Pool" . Understand how to start and stop volumes, as described in Section 5.10, "Starting Volumes" . Run the gluster volume create command to create the distributed volume. The syntax is gluster volume create NEW-VOLNAME [transport tcp | rdma (Deprecated) | tcp,rdma] NEW-BRICK... The default value for transport is tcp . Other options can be passed such as auth.allow or auth.reject . See Section 11.1, "Configuring Volume Options" for a full list of parameters. Red Hat recommends disabling the performance.client-io-threads option on distributed volumes, as this option tends to worsen performance. Run the following command to disable performance.client-io-threads : Example 5.1. Distributed Volume with Two Storage Servers Example 5.2. Distributed Volume over InfiniBand with Four Servers Run # gluster volume start VOLNAME to start the volume. Run gluster volume info command to optionally display the volume information. The following output is the result of Example 5.1, "Distributed Volume with Two Storage Servers" .

Commands:
gluster volume set VOLNAME performance.client-io-threads off
gluster v create glustervol server1:/rhgs/brick1 server2:/rhgs/brick1 volume create: glutervol: success: please start the volume to access data
gluster v create glustervol transport rdma server1:/rhgs/brick1 server2:/rhgs/brick1 server3:/rhgs/brick1 server4:/rhgs/brick1 volume create: glutervol: success: please start the volume to access data
gluster v start glustervol volume start: glustervol: success
gluster volume info Volume Name: test-volume Type: Distribute Status: Created Number of Bricks: 2 Transport-type: tcp Bricks: Brick1: server1:/rhgs/brick Brick2: server2:/rhgs/brick
function::print_ubacktrace_brief Name function::print_ubacktrace_brief - Print stack back trace for current task. EXPERIMENTAL! Synopsis Arguments None Description Equivalent to print_ubacktrace , but output for each symbol is shorter (just name and offset, or just the hex address of no symbol could be found). Note To get (full) backtraces for user space applications and shared shared libraries not mentioned in the current script run stap with -d /path/to/exe-or-so and/or add --ldd to load all needed unwind data.

Commands:
function print_ubacktrace_brief()
4.8 Release Notes Red Hat Enterprise Linux 4 Release Notes for all Architectures Ryan Lerch Red Hat Engineering Content Services rlerch@redhat.com

Commands:
mtrr: v2.0 (20020519) ACPI: Subsystem revision 20040816 ACPI: Found ECDT
up2date compat-dapl up2date -fu
selinux --permissive
setenforce 1
%pre
setenforce 1
Chapter 1. Overview Installer-provisioned installation on bare metal nodes deploys and configures the infrastructure that an OpenShift Container Platform cluster runs on. This guide provides a methodology to achieving a successful installer-provisioned bare-metal installation. The following diagram illustrates the installation environment in phase 1 of deployment: For the installation, the key elements in the diagram are: Provisioner : A physical machine that runs the installation program and hosts the bootstrap VM that deploys the control plane of a new OpenShift Container Platform cluster. Bootstrap VM : A virtual machine used in the process of deploying an OpenShift Container Platform cluster. Network bridges : The bootstrap VM connects to the bare metal network and to the provisioning network, if present, via network bridges, eno1 and eno2 . API VIP : An API virtual IP address (VIP) is used to provide failover of the API server across the control plane nodes. The API VIP first resides on the bootstrap VM. A script generates the keepalived.conf configuration file before launching the service. The VIP moves to one of the control plane nodes after the bootstrap process has completed and the bootstrap VM stops. In phase 2 of the deployment, the provisioner destroys the bootstrap VM automatically and moves the virtual IP addresses (VIPs) to the appropriate nodes. The keepalived.conf file sets the control plane machines with a lower Virtual Router Redundancy Protocol (VRRP) priority than the bootstrap VM, which ensures that the API on the control plane machines is fully functional before the API VIP moves from the bootstrap VM to the control plane. Once the API VIP moves to one of the control plane nodes, traffic sent from external clients to the API VIP routes to an haproxy load balancer running on that control plane node. This instance of haproxy load balances the API VIP traffic across the control plane nodes. The Ingress VIP moves to the worker nodes. The keepalived instance also manages the Ingress VIP. The following diagram illustrates phase 2 of deployment: After this point, the node used by the provisioner can be removed or repurposed. From here, all additional provisioning tasks are carried out by the control plane. Important The provisioning network is optional, but it is required for PXE booting. If you deploy without a provisioning network, you must use a virtual media baseboard management controller (BMC) addressing option such as redfish-virtualmedia or idrac-virtualmedia .

Commands: