mtpti5iD/redhat-docs_dataset huggingface dataset:
19.3. Sub-Collections 19.3.1. Domain Users Sub-Collection The users sub-collection contains all users in the directory service. This information is used to add new users to the Red Hat Virtualization environment. Table 19.2. Domain user elements Element Type Description name string The name of the user. last_name string The surname of the user. user_name string The user name from directory service. domain id GUID The containing directory service domain. groups complex A list of directory service groups for this user. Example 19.2. An XML representation of a user in the users sub-collection 19.3.2. Domain Groups Sub-Collection The groups sub-collection contains all groups in the directory service. A domain group resource contains a set of elements. Table 19.3. Domain group elements Element Type Description name string The name of the group. domain id GUID The containing directory service domain. Example 19.3. An XML representation of a group in the groups sub-collection

Commands:
<user id="225f15cd-e891-434d-8262-a66808fcb9b1" href="/ovirt-engine/api/domains/77696e32-6b38-7268-6576-2e656e676c61/users/ d3b4e7be-5f57-4dac-b937-21e1771a501f"> <name>RHEV-M Admin</name> <user_name>rhevmadmin@domain.example.com</user_name> <domain id="77696e32-6b38-7268-6576-2e656e676c61" href="/ovirt-engine/api/domains/77696e32-6b38-7268-6576-2e656e676c61"/> <groups> <group> <name>domain.example.com/Users/Enterprise Admins</name> </group> <group> <name>domain.example.com/Users/Domain Admins</name> </group> </groups> </user>
<group id="85bf8d97-273c-4a5c-b801-b17d58330dab" href="/ovirt-engine/api/domains/77696e32-6b38-7268-6576-2e656e676c61/groups/ 85bf8d97-273c-4a5c-b801-b17d58330dab"> <name>example.com/Users/Enterprise Admins</name> <domain id="77696e32-6b38-7268-6576-2e656e676c61" href="/ovirt-engine/api/domains/77696e32-6b38-7268-6576-2e656e676c61"/> </group>
3.6. Domain-to-Realm Mapping When a client attempts to access a service running on a particular server, it knows the name of the service ( host ) and the name of the server ( foo.example.com ), but because more than one realm can be deployed on your network, it must guess at the name of the realm in which the service resides. By default, the name of the realm is taken to be the DNS domain name of the server in all capital letters. In some configurations, this will be sufficient, but in others, the realm name which is derived will be the name of a non-existent realm. In these cases, the mapping from the server's DNS domain name to the name of its realm must be specified in the domain_realm section of the client system's krb5.conf . For example: The configuration specifies two mappings. The first mapping specifies that any system in the example.com DNS domain belongs to the EXAMPLE.COM realm. The second specifies that a system with the exact name example.com is also in the realm. The distinction between a domain and a specific host is marked by the presence or lack of an initial period character. The mapping can also be stored directly in DNS.

Commands:
foo.example.org EXAMPLE.ORG foo.example.com EXAMPLE.COM foo.hq.example.com HQ.EXAMPLE.COM
[domain_realm] .example.com = EXAMPLE.COM example.com = EXAMPLE.COM
4.264. RDMA 4.264.1. RHEA-2011:1639 - RDMA stack bug fix and enhancement update Updated RDMA packages that fix various bugs and add various enhancements are now available for Red Hat Enterprise Linux 6. Red Hat Enterprise Linux includes a collection of InfiniBand and iWARP utilities, libraries and development packages for writing applications that use Remote Direct Memory Access (RDMA) technology. The InfiniBand/iWARP/RDMA stack components have been upgraded to more recent upstream versions. Bug Fixes BZ# 724896 , BZ# 724899 , BZ# 724900 The perftest, qperf, and srptool packages spec files erroneously limited the 32 bit Intel build to just the i386 architecture while Red Hat Enterprise Linux 6 now defaults 32 bit Intel builds to the i686 architecture. As a consequence these packages failed to build on the i686 architecture. With this update the error has been corrected and the packages build as expected. BZ# 721101 In Red Hat Enterprise Linux 6.1 changes to network functions to support multiple IP addresses on an interface were made. This caused the ifup-ib script to fail to start IPoIB interfaces depending on how the ifcfg-ib[n] (where [n] is 0 or greater) file was written. Erroneous error messages, "Error: an inet prefix is expected rather than" or "Error, some other host already uses address" were logged. With this update, the ifup-ib script has been changed to handle an array of multiple IP addresses and the error no longer occurs in the scenario described. Enhancements BZ# 633392 This update provides support in OpenSM for Single Root I/O Virtualization (SRIOV) using SRIOV ports exposed on Mellanox SRIOV capable devices. BZ# 725106 An OpenSM update was required in order to provide SRIOV support and the update changed the names of the libraries exported by OpenSM and the rest of the InfiniBand management stack. Therefore a new package, "compat-opensm-libs", that provides a copy of the original libraries, was added to the stack to prevent this upgrade from breaking installed applications. All RDMA users should upgrade to these updated packages which fix these bugs and add these enhancements.

Commands:
6.3. Confining Existing Linux Users: semanage login If a Linux user is mapped to the SELinux unconfined_u user (the default behavior), and you would like to change which SELinux user they are mapped to, use the semanage login command. The following example creates a new Linux user named newuser , then maps that Linux user to the SELinux user_u user: Procedure 6.2. Mapping Linux Users to the SELinux Users As root, create a new Linux user ( newuser ). Since this user uses the default mapping, it does not appear in the semanage login -l output: To map the Linux newuser user to the SELinux user_u user, enter the following command as root: The -a option adds a new record, and the -s option specifies the SELinux user to map a Linux user to. The last argument, newuser , is the Linux user you want mapped to the specified SELinux user. To view the mapping between the Linux newuser user and user_u , use the semanage utility again: As root, assign a password to the Linux newuser user: Log out of your current session, and log in as the Linux newuser user. Enter the following command to view the newuser 's SELinux context: Log out of the Linux newuser 's session, and log back in with your account. If you do not want the Linux newuser user, enter the following command as root to remove it, along with its home directory: As root, remove the mapping between the Linux newuser user and user_u :

Commands:
~]# useradd newuser
~]# 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 *
~]# semanage login -a -s user_u newuser
~]# semanage login -l Login Name SELinux User MLS/MCS Range Service __default__ unconfined_u s0-s0:c0.c1023 * newuser user_u s0 * root unconfined_u s0-s0:c0.c1023 * system_u system_u s0-s0:c0.c1023 *
~]# passwd newuser Changing password for user newuser. 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 -r newuser
~]# semanage login -d newuser
~]# 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 *
Chapter 5. Using patch templates for remediations The Red Hat Insights patch application supports scheduled patching cycles. Patch templates do not affect yum/dnf operations on the host, but they allow you to refine your patch status reporting in Red Hat Insights. You can use the templates to create remediation playbooks for simple patch cycles. 5.1. Using patch templates with remediations Patch templates can include one or more remediations that you want to apply to multiple systems. You can create a patch template to update a group of systems in a test environment, and use the same patch template to update systems in a production environment on a different day. For more information about creating and using patch templates with remediations, refer to System Patching Using Remediation Playbooks . Note After you apply a patch template to the systems you assign, you will not see more recently published advisories that apply to those systems. Use Red Hat Hybrid Cloud Console notifications to ensure that you remain aware of newly published advisories that might affect your infrastructure. For more information about notifications in the Red Hat Hybrid Cloud Console, see Configuring notifications on the Red Hat Hybrid Cloud Console .

Commands:
Chapter 20. Isolation functionality and variables Automation controller uses container technology to isolate jobs from each other. By default, only the current project is exposed to the container running a job template. You might find that you need to customize your playbook runs to expose additional directories. To fine tune your use of job isolation, there are certain variables that can be set. By default, automation controller uses the system's /tmp directory as its staging area. You can change this in the Job Execution Path field on the Jobs settings page, or in the REST API at /api/v2/settings/jobs , using: AWX_ISOLATION_BASE_PATH = "/opt/tmp" If there are any additional directories to be exposed from the host to the container that playbooks run in, you can specify those in the Paths to Expose to Isolated Jobs field of the Jobs settings page, or in the REST API at /api/v2/settings/jobs , using: AWX_ISOLATION_SHOW_PATHS = ['/list/of/', '/paths'] Note If your playbooks use keys or settings defined in /var/lib/awx/.ssh you must add it to AWX_ISOLATION_SHOW_PATHS . These fields can be found on the Jobs Settings page.

Commands:
AWX_ISOLATION_BASE_PATH = "/opt/tmp"
AWX_ISOLATION_SHOW_PATHS = ['/list/of/', '/paths']
1.3.4. Adding and Deleting Files Adding a File To add an existing file to a CVS repository and put it under revision control, change to the directory with its working copy and run the following command: cvs add file ... This schedules the file for addition to the CVS repository. To proceed and actually add the file to the repository, run the cvs commit command as described in Section 1.3.6, "Committing Changes" . Example 1.18. Adding a file to a CVS repository Imagine that the directory with your working copy of a CVS repository has the following contents: With the exception of ChangeLog , all files and directories within this directory are already under revision control. To schedule this file for addition to the CVS repository, type: Deleting a File To remove a file from a CVS repository, change to the directory with its working copy and delete it locally: rm file ... Then schedule this file for removal by using the following command: cvs remove file ... To proceed and actually remove the file from the repository, run the cvs commit command as described in Section 1.3.6, "Committing Changes" . Example 1.19. Removing a file from a CVS repository Imagine that the directory with your working copy of a CVS repository has the following contents: All files in this directory are under revision control. To schedule the TODO file for removal from the CVS repository, type:

Commands:
project]USD ls AUTHORS ChangeLog CVS doc INSTALL LICENSE Makefile README src TODO
project]USD cvs add ChangeLog cvs add: scheduling file `ChangeLog' for addition cvs add: use 'cvs commit' to add this file permanently
project]USD ls AUTHORS ChangeLog CVS doc INSTALL LICENSE Makefile README src TODO
project]USD rm TODO project]USD cvs remove TODO cvs remove: scheduling `TODO' for removal cvs remove: use 'cvs commit' to remove this file permanently
Chapter 42. Data objects Data objects are the building blocks for the rule assets that you create. Data objects are custom data types implemented as Java objects in specified packages of your project. For example, you might create a Person object with data fields Name , Address , and DateOfBirth to specify personal details for loan application rules. These custom data types determine what data your assets and your decision services are based on. 42.1. Creating data objects The following procedure is a generic overview of creating data objects. It is not specific to a particular business asset. Procedure In Business Central, go to Menu Design Projects and click the project name. Click Add Asset Data Object . Enter a unique Data Object name and select the Package where you want the data object to be available for other rule assets. Data objects with the same name cannot exist in the same package. In the specified DRL file, you can import a data object from any package. Importing data objects from other packages You can import an existing data object from another package directly into the asset designers like guided rules or guided decision table designers. Select the relevant rule asset within the project and in the asset designer, go to Data Objects New item to select the object to be imported. To make your data object persistable, select the Persistable checkbox. Persistable data objects are able to be stored in a database according to the JPA specification. The default JPA is Hibernate. Click Ok . In the data object designer, click add field to add a field to the object with the attributes Id , Label , and Type . Required attributes are marked with an asterisk (*). Id: Enter the unique ID of the field. Label: (Optional) Enter a label for the field. Type: Enter the data type of the field. List: (Optional) Select this check box to enable the field to hold multiple items for the specified type. Figure 42.1. Add data fields to a data object Click Create to add the new field, or click Create and continue to add the new field and continue adding other fields. Note To edit a field, select the field row and use the general properties on the right side of the screen.

Commands:
3.20. RHEA-2011:1633 - new package: tboot A new tboot package is now available for Red Hat Enterprise Linux 6. The tboot package provides Trusted Boot (tboot), an open source pre- kernel/VMM module, that uses Intel Trusted Execution Technology (Intel TXT) to initialize the launch of a operating system kernels and virtual machines. This enhancement update adds tboot to Red Hat Enterprise Linux 6. (BZ# 691617 ) All users wishing to evaluate trusted boot capabilities are advised to install this new package.

Commands:
Chapter 3. Upgrading Red Hat build of Keycloak adapters It is important that you upgrade Red Hat build of Keycloak server first, and then upgrade the adapters. Earlier versions of the adapter might work with later versions of Red Hat build of Keycloak server, but earlier versions of Red Hat build of Keycloak server might not work with later versions of the adapter. 3.1. Compatibility with older adapters As mentioned above, we try to support newer release versions of Red Hat build of Keycloak server working with older release versions of the adapters. However, in some cases we need to include fixes on the Red Hat build of Keycloak server side which may break compatibility with older versions of the adapters. For example, when we implement new aspects of the OpenID Connect specification, which older client adapter versions were not aware of. In those cases, we added Compatibility modes. For OpenId Connect clients, there is a section named OpenID Connect Compatibility Modes in the Red Hat build of Keycloak admin console, on the page with client details. Here, you can disable some new aspects of the Red Hat build of Keycloak server to preserve compatibility with older client adapters. More details are available in the tool tips of individual switches. 3.2. Upgrading the EAP adapter To upgrade an EAP adapter that has been copied to your web application, perform the following procedure. Procedure Download the new adapter archive. Remove the adapter modules by deleting the EAP_HOME/modules/system/add-ons/keycloak/ directory. Unzip the downloaded archive into EAP_HOME . 3.3. Upgrading the JavaScript adapter To upgrade a JavaScript adapter that has been copied to your web application, perform the following procedure. Procedure Download the new adapter archive. Overwrite the keycloak.js file in your application with the keycloak.js file from the downloaded archive. 3.4. Upgrading the Node.js adapter To upgrade a Node.js adapter that has been copied to your web application, perform the following procedure. Procedure Download the new adapter archive. Remove the existing Node.js adapter directory Unzip the updated file into its place Change the dependency for keycloak-connect in the package.json of your application

Commands:
Appendix A. Managing certificates A.1. Installing certificate authority certificates SSL/TLS authentication relies on digital certificates issued by trusted Certificate Authorities (CAs). When an SSL/TLS connection is established by a client, the AMQP peer sends a server certificate to the client. This server certificate must be signed by one of the CAs in the client's Trusted Root Certification Authorities certificate store. If the user is creating self-signed certificates for use by AMQ Broker, then the user must create a CA to sign the certificates. Then the user can enable the client SSL/TLS handshake by installing the self-signed CA file ca.crt . From an administrator command prompt, run the MMC Certificate Manager plugin, certmgr.msc . Expand the Trusted Root Certification Authorities folder on the left to expose Certificates . Right-click Certificates and select All Tasks and then Import . Click . Browse to select file ca.crt . Click . Select Place all certificates in the following store . Select certificate store Trusted Root Certification Authorities . Click . Click Finish . For more information about installing certificates, see Managing Microsoft Certificate Services and SSL . A.2. Installing client certificates In order to use SSL/TLS and client certificates, the certificates with the client's private keys must be imported into the proper certificate store on the client system. From an administrator command prompt, run the MMC Certificate Manager plugin, certmgr.msc . Expand the Personal folder on the left to expose Certificates . Right-click Certificates and select All Tasks and then Import . Click . Click Browse . In the file type pulldown, select Personal Information Exchange (\.pfx;*.p12) . Select file client.p12 and click Open . Click . Enter the password for the private key password field. Accept the default import options. Click . Select Place all certificates in the following store . Select certificate store Personal . Click . Click Finish . A.3. Using client certificates Before a client will return a certificate to the broker, the Red Hat build of Apache Qpid Proton DotNet library must be told which certificates to use. The client certificate file client.crt is added to the list of certificates to be used during connection. In this example, certfile is the full path to the client.p12 certificate installed in the Personal certificate store.

Commands:
ConnectionOptions connectionOptions = new(); connectionOptions.SslOptions.ClientCertificateCollection.Add( X509Certificate.CreateFromCertFile(certfile) );
Chapter 1. OAuth APIs 1.1. OAuthAccessToken [oauth.openshift.io/v1] Description OAuthAccessToken describes an OAuth access token. The name of a token must be prefixed with a sha256~ string, must not contain "/" or "%" characters and must be at least 32 characters long. The name of the token is constructed from the actual token by sha256-hashing it and using URL-safe unpadded base64-encoding (as described in RFC4648) on the hashed result. Compatibility level 1: Stable within a major release for a minimum of 12 months or 3 minor releases (whichever is longer). Type object 1.2. OAuthAuthorizeToken [oauth.openshift.io/v1] Description OAuthAuthorizeToken describes an OAuth authorization token Compatibility level 1: Stable within a major release for a minimum of 12 months or 3 minor releases (whichever is longer). Type object 1.3. OAuthClientAuthorization [oauth.openshift.io/v1] Description OAuthClientAuthorization describes an authorization created by an OAuth client Compatibility level 1: Stable within a major release for a minimum of 12 months or 3 minor releases (whichever is longer). Type object 1.4. OAuthClient [oauth.openshift.io/v1] Description OAuthClient describes an OAuth client Compatibility level 1: Stable within a major release for a minimum of 12 months or 3 minor releases (whichever is longer). Type object 1.5. UserOAuthAccessToken [oauth.openshift.io/v1] Description UserOAuthAccessToken is a virtual resource to mirror OAuthAccessTokens to the user the access token was issued for Type object

Commands:
Chapter 1. Overview In the event of a hardware issue or some other serious problem, you may need to replace a failed host. Minimize restore time by backing up disk configuration: Chapter 2, Backing up important files . This is not required to restore brick contents, but it does make the process faster. The process differs depending on the following factors: Is data on the disks intact? Have you backed up or can you safely back up host configuration details? Is the failed host a primary volfile server (the server whose FQDN is used to mount gluster volumes, usually the first host in the cluster)? Follow the process that best fits your situation: If your disks are intact, you can reinstall the same host and use the same FQDN regardless of whether the server is the primary volfile server. If you can back up configuration details, follow Chapter 3, Reusing bricks and restoring configuration from backups . If you cannot back up configuration details, follow Chapter 4, Reusing bricks and reconstructing existing brick configuration . If your disks are not intact or you want the replacement host to use a different FQDN: If the host that failed was the primary volfile server, use Chapter 6, Replacing a primary host using new bricks . Important This process requires that virtual machines are taken offline. If the host that failed was not the primary volfile server, use Chapter 7, Replacing a non-primary host using new bricks .

Commands: