mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 18. System and Subscription Management New payload_gpgcheck option added to yum With this update, the new configuration option payload_gpgcheck has been added to the yum utility. This option enables a GNU Privacy Guard (GPG) signature check on the payload sections of packages, thus enhancing the security and integrity when installing packages. Previously, when gpgcheck option was enabled, yum only performed a GPG signature check on headers. Consequently, if the payload data were tampered with or corrupted, RPM unpacking error occurred, and the package was left in a partly installed state. This might have put the operating system into an inconsistent and vulnerable state. You can use the new payload_gpgcheck option in conjunction with the gpgcheck or localpkg_gpgcheck options to prevent this problem. As a result, when payload_gpgcheck is enabled, yum performs a GPG signature check on the payload and aborts the transaction if it is not verified. Using payload_gpgcheck is equivalent to manually running rpm -K on downloaded packages. (BZ# 1343690 ) A no-proxy configuration is available for virt-who With this update, the virt-who service can be set to ignore proxy network settings. This enables virt-who to work properly on environments that use a proxy connection with one-way communication. To set up this functionality, add the NO_PROXY environment variable to the /etc/sysconfig/virt-who file. Alternatively, you can add the no_proxy variable to the [server] section of the /etc/rhsm/rhsm.conf file. Note that the NO_PROXY setting does not work when synchronizing the hypervisor using Red Hat Satellite 5. (BZ#1299643) virt-who respects independent interval settings With this update, the virt-who command reports each interval on all sources that have updates. In addition, if virt-who is configured to send updates to more than one destination, for example to an Red Hat Satellite instance and the Red Hat Subscription Management (RHSM), the interval for each is maintained separately. This means that all updates can be sent to each configured destination, regardless of the state of communication with other destinations. (BZ# 1436811 ) Password options added to virt-who-password With this update, the -p and --password options have been added to the virt-who-password utility. This enables the utility to be used in scripts. (BZ# 1426058 ) Regular expressions and wildcards can be used in some virt-who configuration parameters With this update, regular expressions and wildcards can be used in the filter_hosts and exclude_hosts configuration parameters. This enables users of virt-who to maintain a list of hosts to report on with much more ease. By using regular expressions and wildcards to specify which hosts to report on or exclude, the hosts list can be much more concise. (BZ# 1405967 ) virt-who configuration files are easier to manage The virt-who service now only uses configuration files in the /etc/virt-who.d/ directory that end with the .conf extension. This enables easier management of virt-who configuration files, for example for testing or backup purposes. (BZ# 1369107 )

Commands:
Chapter 2. Hardware recommendations RAM is the most important hardware feature to size properly. Make sure your system has enough RAM available. Typical RAM requirements are: For 10,000 users and 100 groups: at least 4 GB of RAM and 4 GB swap space For 100,000 users and 50,000 groups: at least 16 GB of RAM and 4 GB of swap space For larger deployments, increasing RAM is more effective than increasing disk space because much of the data is stored in cache. In general, adding more RAM leads to better performance for larger deployments due to caching. In virtualized environments, memory ballooning must be disabled or the complete RAM must be reserved for the guest IdM servers. Note A basic user entry or a simple host entry with a certificate is approximately 5- 10 kB in size.

Commands:
B.2. Teiid Designer Preferences General Teiid Designer preferences include: Enable auto-creating of a source model's data source on Teiid Instance - indicates if data sources that match the default name should be auto-created if they do not exist on Teiid server. Default Teiid Server Version - determines what version of server modelling will be targeted at, if no server has been defined in the Servers View. Thus, it is possible to still design models without the need to define and connect to a server. However, possible values are confined to the teiid runtime clients installed. Always open editor without prompting - To change/edit a model, it must be opened for editing. Selecting this box will automatically open the model in an editor if the user attempts to perform a change in a model. If unchecked, the user will be informed that an editor will be opened before the operation is completed. Open Designer perspective when model is opened - If a model is opened via importing projects, the New > Teiid Metadata Model menu and the Teiid Designer perspective is not open, you may want to automatically open the perspective and begin working on your model. This preference has 3 settings. Always open, which means always open the perspective without prompting; never open, which means do not open the Teiid Designer perspective, or prompt, which will always ask you if you wish to open the Teiid Designer perspective. Check and update imports during save - Occasionally editing a model may add or remove objects in one model that reference objects in another model. Model Imports keep track of these dependencies within each model. A validation error or warning may appear during a build. Checking this box will automatically check and update imports during the save process. This will result in any unneeded imports being removed from the model or any required imports added to the model. If unchecked, no updating of imports will be performed.

Commands:
15.2.2. Using a Private libvirt Network Procedure 15.3. Using a private libvirt network Configure PXE booting on libvirt as shown in Section 15.1.1, "Setting up a PXE Boot Server on a Private libvirt Network" . Boot a guest virtual machine using libvirt with PXE booting enabled. You can use the virt-install command to create/install a new virtual machine using PXE: Alternatively, ensure that the guest network is configured to use your bridged network, and that the XML guest configuration file has a <boot dev='network'/> element inside the <os> element, as shown in the following example: Also ensure that the guest virtual machine is connected to the private network:

Commands:
virt-install --pxe --network network=default --prompt
<os> <type arch='x86_64' machine='rhel6.2.0'>hvm</type> <boot dev='network'/> <boot dev='hd'/> </os>
<interface type='network'> <mac address='52:54:00:66:79:14'/> <source network='default'/> <target dev='vnet0'/> <alias name='net0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface>
3.2.2. Cloning Guests with virt-manager This procedure describes cloning a guest virtual machine using the virt-manager utility. Procedure 3.2. Cloning a Virtual Machine with virt-manager Open virt-manager Start virt-manager . Launch the Virtual Machine Manager application from the Applications menu and System Tools submenu. Alternatively, run the virt-manager command as root. Select the guest virtual machine you want to clone from the list of guest virtual machines in Virtual Machine Manager . Right-click the guest virtual machine you want to clone and select Clone . The Clone Virtual Machine window opens. Figure 3.1. Clone Virtual Machine window Configure the clone To change the name of the clone, enter a new name for the clone. To change the networking configuration, click Details . Enter a new MAC address for the clone. Click OK . Figure 3.2. Change MAC Address window For each disk in the cloned guest virtual machine, select one of the following options: Clone this disk - The disk will be cloned for the cloned guest virtual machine Share disk with guest virtual machine name - The disk will be shared by the guest virtual machine that will be cloned and its clone Details - Opens the Change storage path window, which enables selecting a new path for the disk Figure 3.3. Change storage path window Clone the guest virtual machine Click Clone .

Commands:
Chapter 13. Finding applications By the end of this guide, you will be able to quickly locate an application in the Admin Portal based on either its name, an API key, or an application identifier. During API operations, you may need to be able to find information on an application that is accessing your API quickly - either for support purposes, to change configuration, or potentially because the application is misbehaving and needs to be disabled. 13.1. Get the information you need To find an application, you need the name of the account it belongs to or the application's name. If you do not have this information, you can verify the access logs. To perform the search, navigate to Applications: Audience > Applications > Listing . If you search by identifier for an authentication type, you need the following information: For API key-only authentication patterns: the API key For app ID and app key authentication patterns: the app identifier (search by app key is not supported) For OpenID Connect authentication patterns: the client_id (search on the secret is not supported) 13.2. Search for the application To search a given application, navigate to Applications page via Audience > Applications > Listing , and use the search box as shown in the image below. 13.3. Access application information Once the results are returned, click on the application you would like to access and you will be taken to that application's homepage, which includes information such as that shown in the image below.

Commands:
4.16. bash 4.16.1. RHBA-2012:0561 - bash bug fix update Updated bash packages that fix one bug are now available for Red Hat Enterprise Linux 6. The GNU Bourne Again shell (Bash) is a shell and command language interpreter compatible with the Bourne shell (sh). Bash is the default shell for Red Hat Enterprise Linux. Bug Fix BZ# 814271 When a SIGCHLD signal was received in job control mode and a handler for the signal was installed, Bash called the trap handler within the signal handler itself. This was unsafe and could cause Bash to enter a deadlock or to terminate unexpectedly with a segmentation fault due to memory corruption. With this update, the trap handler is now called outside of the signal handler, and Bash no longer enters a deadlock, neither crashes in this scenario. All users of bash are advised to upgrade to these updated packages, which fix this bug.

Commands:
Chapter 7. KafkaListenerAuthenticationTls schema reference Used in: GenericKafkaListener The type property is a discriminator that distinguishes use of the KafkaListenerAuthenticationTls type from KafkaListenerAuthenticationScramSha512 , KafkaListenerAuthenticationOAuth , KafkaListenerAuthenticationCustom . It must have the value tls for the type KafkaListenerAuthenticationTls . Property Property type Description type string Must be tls .

Commands:
14.3. Multi-Source Binding Support Teiid Designer allows you to define relational source models and binding them to multiple data sources. Use Multi-source models to quickly access data in multiple sources with homogeneous metadata. When you have multiple instances using identical schema, Red Hat JBoss Data Virtualization can help you gather data across all the instances, using "multi-source" models. In this scenario, instead of creating/importing a model for every data source, one source model is defined to represents the schema and is configured with multiple data "sources" underneath it. During runtime when a query issued against this model, the query engine analyzes the information and gathers the required data from all sources configured and gathers the results and provides in a single result. Since all sources utilize the same physical metadata, this feature is most appropriate for accessing the same source type with multiple instances. The VDB Editor's Models tab contains a simplified model table on the left and a new tabbed panel on the right containing Model Details and Source Binding Definition tabs. Click the Multi-source check box if you wish to add additional source bindings. Note Note that each binding must be defined with a unique source name as well as unique JNDI name representing a deployed data source you your server.

Commands:
Chapter 7. Modifying firewall rules 7.1. Modifying firewall rules for disk encryption On Network-Bound Disk Encryption (NBDE) key servers, you need to open ports so that encryption keys can be served. Procedure On each NBDE key server: Open ports required to serve encryption keys. Note The default port is 80/tcp . To use a custom port, see Deploying a tang server with SELinux in enforcing mode in the Red Hat Enterprise Linux 8 documentation. Verify that the port appears in the output of the following command.

Commands:
firewall-cmd --add-port=80/tcp firewall-cmd --add-port=80/tcp --permanent
firewall-cmd --list-ports | grep '80/tcp'
4.3. sVirt Configuration SELinux Booleans are variables that can be toggled on or off, quickly enabling or disabling features or other special conditions. Booleans can be toggled by running either setsebool boolean_name {on|off} for a temporary change, or setsebool -P boolean_name {on|off} to make the change persistent across reboots. The following table shows the SELinux Boolean values that affect KVM when launched by libvirt. The current state of these booleans (on or off) can be found by running the command getsebool -a|grep virt . Table 4.1. KVM SELinux Booleans SELinux Boolean Description staff_use_svirt Allow staff user to create and transition to sVirt domains. unprivuser_use_svirt Allow unprivileged user to create and transition to sVirt domains. virt_sandbox_use_audit Allow sandbox containers to send audit messages. virt_sandbox_use_netlink Allow sandbox containers to use netlink system calls. virt_sandbox_use_sys_admin Allow sandbox containers to use sys_admin system calls, such as mount. virt_transition_userdomain Allow virtual processes to run as user domains. virt_use_comm Allow virt to use serial/parallel communication ports. virt_use_execmem Allow confined virtual guests to use executable memory and executable stack. virt_use_fusefs Allow virt to read FUSE mounted files. virt_use_nfs Allow virt to manage NFS mounted files. virt_use_rawip Allow virt to interact with rawip sockets. virt_use_samba Allow virt to manage CIFS mounted files. virt_use_sanlock Allow confined virtual guests to interact with the sanlock. virt_use_usb Allow virt to use USB devices. virt_use_xserver Allow virtual machine to interact with the X Window System. Note For more information on SELinux Booleans, refer to Red Hat Enterprise Linux Security Enhanced Linux .

Commands:
36.6. Verifying the Boot Loader The kernel RPM package configures the boot loader to boot the newly installed kernel (except for IBM eServer iSeries systems). However, it does not configure the boot loader to boot the new kernel by default. It is always a good idea to confirm that the boot loader has been configured correctly. This is a crucial step. If the boot loader is configured incorrectly, the system does not boot into Red Hat Enterprise Linux properly. If this happens, boot the system with the boot media created earlier and try configuring the boot loader again. 36.6.1. x86 Systems All x86 systems use GRUB as the boot loader, which includes all AMD64 systems. 36.6.1.1. GRUB Confirm that the file /boot/grub/grub.conf contains a title section with the same version as the kernel package just installed (if the kernel-smp or kernel-hugemem package was installed, a section exists for it as well): If a separate /boot/ partition was created, the paths to the kernel and initrd image are relative to /boot/ . Notice that the default is not set to the new kernel. To configure GRUB to boot the new kernel by default, change the value of the default variable to the title section number for the title section that contains the new kernel. The count starts with 0. For example, if the new kernel is the first title section, set default to 0 . Begin testing the new kernel by rebooting the computer and watching the messages to ensure that the hardware is detected properly.

Commands:
Note that you do not have to rerun grub after making changes to this file NOTICE: You have a /boot partition. This means that all kernel and initrd paths are relative to /boot/, eg. root (hd0,0) kernel /vmlinuz-version ro root=/dev/hda2 initrd /initrd-version.img #boot=/dev/hda default=1 timeout=10 splashimage=(hd0,0)/grub/splash.xpm.gz title Red Hat Enterprise Linux (2.6.9-5.EL) root (hd0,0) kernel /vmlinuz-2.6.9-5.EL ro root=LABEL=/ initrd /initrd-2.6.9-5.EL.img title Red Hat Enterprise Linux (2.6.9-1.906_EL) root (hd0,0) kernel /vmlinuz-2.6.9-1.906_EL ro root=LABEL=/ initrd /initrd-2.6.9-1.906_EL.img
Chapter 4. Introduction to non-containerized product certification The Red Hat Software certification program for traditional, non-containerized products helps Independent Software Vendors (ISV) to build, certify and distribute their application software on systems and server environments running Red Hat Enterprise Linux (RHEL) in a jointly supported customer environment. A strong working knowledge of RHEL is required. Partner Validation - Select this type of certification, if you want to validate your product using your own criteria and test suite on Red Hat platforms. This partner validation allows you to publish your software offerings on the Red Hat Ecosystem Catalog more quickly. However, validated workloads may not incorporate all of Red Hat integration requirements and best practices. We encourage you to continue your efforts toward Red Hat certification. Certified - Select this type of certification, if you want your product to undergo thorough testing by using Red Hat's test suite, and benefit from collaborative support. Your products will meet your standards and Red Hat's criteria, including interoperability, lifecycle management, security, and support requirements. Products that meet the requirements and complete the certification workflow get listed on the Red Hat Ecosystem Catalog. Partners will receive a logo to promote their product certification.

Commands:
Chapter 7. Integrating Red Hat JBoss Data Virtualization with Red Hat JBoss Data Grid 7.1. Configure Red Hat JBoss Data Grid Connectors The infinispan-cache, infinispan-hotrod and infinispan-cache-dsl translators are not pre-configured to work when the server starts. You must manually configure them if you wish to use Red Hat JBoss Data Grid as a data source. Download the required Java web client and apply overlay to the modules directory. Navigate to the docs/teiid/datasources/infinispan/ directory (and to the docs/teiid/datasources/infinispan-hotrod-7.1/ directoryfor Hotrod). Execute the appropriate script: add-infinispan-cache-translator.cli , add-infinispan-cache-dsl-translator.cli and infinispan-hotrod-translator.cli .

Commands:
18.4. ACI Evaluation To evaluate the access rights to a particular entry, the server creates a list of the ACIs present on the entry itself and on the parent entries back up to the top level entry stored in Directory Server. ACIs are evaluated across all databases for a particular instance but not across different instances. Directory Server evaluates this list of ACIs based on the semantics of the ACIs, not on their placement in the directory tree. This means that ACIs that are close to the root of the directory tree do not take precedence over ACIs that are closer to the leaves of the directory tree. In Directory Server, the deny permission in ACIs take precedence over the allow permission. For example, if you deny write permission at the directory's root level, none of the users can write to the directory, regardless if an other ACI grants this permission. To grant a specific user write permissions to the directory, you have to add an exception to the original denying rule to allow the user to write in that directory. Note For improved ACIs, use fine-grained allow rules instead of deny rules.

Commands:
function::user_string_n Name function::user_string_n - Retrieves string of given length from user space. Synopsis Arguments addr The user space address to retrieve the string from. n The maximum length of the string (if not null terminated). General Syntax user_string_n:string(addr:long, n:long) Description Returns the C string of a maximum given length from a given user space address. Returns " <unknown> " on the rare cases when userspace data is not accessible at the given address.

Commands:
function user_string_n:string(addr:long,n:long)
25.6. Storing a Common Secret for Multiple Users This section shows how an administrator can create a shared vault and allow other users to access the secret in the vault. The administrator archives a common password into the vault, and the other users are able to retrieve the password on any machine in the domain. This section includes these procedures: Section 25.6.2, "Retrieving a Secret from a Shared Vault as a Member User" Section 25.6.1, "Creating the Shared Vault with the Common Secret" In the procedures: shared_vault is the vault used to store the common password admin is the administrator who creates the shared vault the vault type is standard , so that accessing the archived password does not require the user to provide a vault password secret.txt is the file containing the common secret user1 and user2 are the users allowed to access the vault 25.6.1. Creating the Shared Vault with the Common Secret Create a shared vault and use it to store the common secret. Add the users who will be accessing the secret as vault members. The vault type is standard, which ensures any user accessing the secret will not be required to authenticate. Log in as the administrator: Create the shared vault: Archive the secret into the vault. Add the --shared option to specify that the vault is in the shared container: Note One vault can only store one secret. Add user1 and user2 as vault members: 25.6.2. Retrieving a Secret from a Shared Vault as a Member User Log in as a member user of the vault, and export the file with the secret from the vault. Log in as the user1 member user: Retrieve the secret from the shared vault:

Commands:
kinit admin
ipa vault-add shared_vault --shared --type standard --------------------------- Added vault "shared_vault" --------------------------- Vault name: shared_vault Type: standard Owner users: admin Shared vault: True
ipa vault-archive shared_vault --shared --in secret.txt ----------------------------------- Archived data into vault "shared_vault" -----------------------------------
ipa vault-add-member shared_vault --shared --users={user1,user2} Vault name: shared_vault Type: standard Owner users: admin Shared vault: True Member users: user1, user2 ------------------------- Number of members added 2 -------------------------
kinit user1
ipa vault-retrieve shared_vault --shared --out secret_exported.txt ----------------------------------------- Retrieved data from vault "shared_vault" -----------------------------------------