mtpti5iD/redhat-docs_dataset huggingface dataset:
8.194. sblim-wbemcli 8.194.1. RHBA-2013:1047 - sblim-wbemcli bug fix update Updated sblim-wbemcli packages that fix two bugs are now available for Red Hat Enterprise Linux 6. WBEM (Web-Based Enterprise Management) CLI is a standalone, command-line WBEM client. It can be used in scripts for basic system management tasks. Bug Fixes BZ#745264 Previously, the spec file of the sblim-wbemcli package contained a requirement for the tog-pegasus CIM server, which could cause problems. This update amends the spec file and top-pegasus is no longer required when installing sblim-wbemcli. BZ#868905 Due to incorrect usage of the curl API in the code, when the wbemcli utility was called with an HTTPS scheme, wbemcli terminated unexpectedly with a segmentation fault. With this update, the curl API is used properly and wbemcli no longer crashes in the described scenario. Users of sblim-wbemcli are advised to upgrade to these updated packages, which fix these bugs.

Commands:
Chapter 45. Using the standalone content manager perspective By using the standalone content manager perspective in your application, you can create and edit your application's content and its navigation menus. Procedure Log in to Business Central. In a web browser, enter the following web address in the address bar, http://localhost:8080/business-central/kie-wb.jsp?standalone=true&perspective=ContentManagerPerspective The standalone content manager perspective opens in the browser.

Commands:
7.66. geronimo-specs 7.66.1. RHBA-2012:1397 - geronimo-specs bug fix update Updated geronimo-specs packages that fix one bug are now available for Red Hat Enterprise Linux 6. The geronimo-specs packages provide the specifications for Apache's ASF-licenced J2EE server Geronimo. Bug Fix BZ# 818755 Prior to this update, the geronimo-specs-compat package description contained inaccurate references. This update removes these references so that the description is now accurate. All users of geronimo-specs are advised to upgrade to these updated packages, which fix this bug.

Commands:
Chapter 13. Volume cloning A clone is a duplicate of an existing storage volume that is used as any standard volume. You create a clone of a volume to make a point in time copy of the data. A persistent volume claim (PVC) cannot be cloned with a different size. You can create up to 512 clones per PVC for both CephFS and RADOS Block Device (RBD). 13.1. Creating a clone Prerequisites Source PVC must be in Bound state and must not be in use. Note Do not create a clone of a PVC if a Pod is using it. Doing so might cause data corruption because the PVC is not quiesced (paused). Procedure Click Storage Persistent Volume Claims from the OpenShift Web Console. To create a clone, do one of the following: Beside the desired PVC, click Action menu (...) Clone PVC . Click on the PVC that you want to clone and click Actions Clone PVC . Enter a Name for the clone. Select the access mode of your choice. Important The ReadOnlyMany (ROX) access mode is a Developer Preview feature and is subject to Developer Preview support limitations. Developer Preview releases are not intended to be run in production environments and are not supported through the Red Hat Customer Portal case management system. If you need assistance with ReadOnlyMany feature, reach out to the ocs-devpreview@redhat.com mailing list and a member of the Red Hat Development Team will assist you as quickly as possible based on availability and work schedules. See Creating a clone or restoring a snapshot with the new readonly access mode to use the ROX access mode. Enter the required size of the clone. Select the storage class in which you want to create the clone. The storage class can be any RBD storage class and it need not necessarily be the same as the parent PVC. Click Clone . You are redirected to the new PVC details page. Wait for the cloned PVC status to become Bound . The cloned PVC is now available to be consumed by the pods. This cloned PVC is independent of its dataSource PVC.

Commands:
17.2. XML Representation of a Virtual Machine Template Example 17.1. An XML representation of a virtual machine template

Commands:
<template href="/ovirt-engine/api/templates/00000000-0000-0000-0000-000000000000" id="00000000-0000-0000-0000-000000000000"> <actions> <link href="/ovirt-engine/api/templates/00000000-0000-0000-0000-000000000000/export" rel="export"/> </actions> <name>Blank</name> <description>Blank template</description> <comment>Blank template</comment> <link href="/ovirt-engine/api/templates/00000000-0000-0000-0000-000000000000/disks" rel="disks"/> <link href="/ovirt-engine/api/templates/00000000-0000-0000-0000-000000000000/nics" rel="nics"/> <link href="/ovirt-engine/api/templates/00000000-0000-0000-0000-000000000000/cdroms" rel="cdroms"/> <link href="/ovirt-engine/api/templates/00000000-0000-0000-0000-000000000000/permissions" rel="permissions"/> <link href="/ovirt-engine/api/templates/00000000-0000-0000-0000-000000000000/watchdogs" rel="watchdogs"/> <type>server</type> <status> <state>ok</state> </status> <memory>536870912</memory> <cpu> <topology sockets="1" cores="1"/> <architecture>X86_64<architecture/> </cpu> <cpu_shares>0</cpu_shares> <os type="rhel_6x64"> <boot dev="hd"/> <boot dev="cdrom"/>; </os> <cluster id="00000000-0000-0000-0000-000000000000" href="/ovirt-engine/api/clusters/00000000-0000-0000-0000-000000000000"/> <creation_time>2010-08-16T14:24:29</creation_time> <origin>ovirt</origin> <high_availability> <enabled>true</enabled> <priority>100</priority> </high_availability> <display> <type>spice</type> <monitors>1</monitors> <single_qxl_pci>false</single_qxl_pci> <allow_override>true</allow_override> <smartcard_enabled>true</smartcard_enabled> </display> <stateless>false</stateless> <delete_protected>false</delete_protected> <sso> <methods> <method id="GUEST_AGENT">true</enabled> </methods> </sso> <usb> <enabled>true</enabled> </usb> <migration_downtime>-1</migration_downtime> <version> <base_template href="/ovirt-engine/api/templates/00000000-0000-0000-0000-000000000000" id="00000000-0000-0000-0000-000000000000"/> <version_number>2</version_number> <version_name>RHEL65_TMPL_001</version_name> </version> </template>
Chapter 3. Installing and Uninstalling Identity Management Clients This chapter explains how to configure a system to join an Identity Management (IdM) domain as a client machine enrolled with a server. Note See Section 1.2, "The Identity Management Domain" for details on clients and servers in the IdM domain. 3.1. Prerequisites for Installing a Client DNS requirements Employ proper DNS delegation. For details on DNS requirements in IdM, see Section 2.1.5, "Host Name and DNS Configuration" . Do not alter the resolv.conf file on clients. Port requirements IdM clients connect to a number of ports on IdM servers to communicate with their services. These ports must be open on the IdM servers in the incoming direction. For more information on which ports IdM requires, see Section 2.1.6, "Port Requirements" . On a client, open these ports in the outgoing direction. If you are using a firewall that does not filter outgoing packets, such as firewalld , the ports are already available in the outgoing direction. Name Service Cache Daemon (NSCD) requirements Red Hat recommends to disable NSCD on Identity Management machines. Alternatively, if disabling NSCD is not possible, only enable NSCD for maps that SSSD does not cache. Both NSCD and the SSSD service perform caching, and problems can occur when systems use both services simultaneously. See the System-Level Authentication Guide for information on how to avoid conflicts between NSCD and SSSD. 3.1.1. Supported versions of RHEL for installing IdM clients An Identity Management (IdM) deployment in which IdM servers are running on the latest minor version of RHEL 7 supports clients that are running on the latest minor versions of: RHEL 7 RHEL 8 RHEL 9 Note If you are planning to make your IdM deployment FIPS-compliant, {RH} strongly recommends migrating your environment to RHEL 9. RHEL 9 is the first major RHEL version certified for FIPS 140-3. 3.1.2. Prerequisites for Installing a Client in a FIPS Environment In environments set up using Red Hat Enterprise Linux 7.4 and later: You can configure a new client on a system with the Federal Information Processing Standard (FIPS) mode enabled. The installation script automatically detects a system with FIPS enabled and configures IdM without the administrator's intervention. To enable FIPS in the operating system, see Enabling FIPS Mode in the Security Guide . In environments set up using Red Hat Enterprise Linux 7.3 and earlier: IdM does not support the FIPS mode. Disable FIPS on your system before installing an IdM client, and do not enable it after the installation. For further details about FIPS mode, see Federal Information Processing Standard (FIPS) in the Security Guide .

Commands:
Virtualization Tuning and Optimization Guide Red Hat Enterprise Linux 7 Using KVM performance features for host systems and virtualized guests on RHEL Jiri Herrmann Red Hat Customer Content Services jherrman@redhat.com Yehuda Zimmerman Red Hat Customer Content Services yzimmerm@redhat.com Dayle Parker Red Hat Customer Content Services Scott Radvan Red Hat Customer Content Services Red Hat Subject Matter Experts

Commands:
16.3. PAM Configuration File Format Each PAM configuration file contains a group of directives formatted as follows: Each of these elements are explained in the subsequent sections. 16.3.1. Module Interface There are four types of PAM module interfaces which correlate to different aspects of the authorization process: auth - This module interface authenticates use. For example, it asks for and verifies the validity of a password. Modules with this interface can also set credentials, such as group memberships or Kerberos tickets. account - This module interface verifies that access is allowed. For example, it may check if a user account is expired or is allowed to log in at a particular time of day. password - This module interface sets and verifies passwords. session - This module interface configures and manages user sessions. Modules with this interface can also perform additional tasks that are needed to allow access, like mounting a user's home directory and making the user's mailbox available. Note An individual module can provide any or all module interfaces. For instance, pam_unix.so provides all four module interfaces. In a PAM configuration file, the module interface is the first field defined. For example, a typical line in a configuration may look like this: This instructs PAM to use the pam_unix.so module's auth interface. 16.3.1.1. Stacking Module Interfaces Module interface directives can be stacked , or placed upon one another, so that multiple modules are used together for one purpose. For this reason, the order in which the modules are listed is very important to the authentication process. Stacking makes it very easy for an administrator to require specific conditions to exist before allowing the user to authenticate. For example, rlogin normally uses five stacked auth modules, as seen in its PAM configuration file: Before someone is allowed to use rlogin , PAM verifies that the /etc/nologin file does not exist, that they are not trying to log in remotely as a root user over a network connection, and that any environmental variables can be loaded. Then, if a successful rhosts authentication is performed, the connection is allowed. If the rhosts authentication fails, then standard password authentication is performed.

Commands:
<module interface> <control flag> <module name> <module arguments>
auth required pam_unix.so
auth required pam_nologin.so auth required pam_securetty.so auth required pam_env.so auth sufficient pam_rhosts_auth.so auth required pam_stack.so service=system-auth
12.4.2. Configuring /etc/rndc.conf The key is the most important statement in /etc/rndc.conf . The <key-name> and <key-value> should be exactly the same as their settings in /etc/named.conf . To match the keys specified in the target server's /etc/named.conf , add the following lines to /etc/rndc.conf . This directive sets a global default key. However, the rndc configuration file can also specify different keys for different servers, as in the following example: Warning Make sure that only the root user can read or write to the /etc/rndc.conf file. For more information about the /etc/rndc.conf file, refer to the rndc.conf man page.

Commands:
key " <key-name> " { algorithm hmac-md5; secret " <key-value> "; };
options { default-server localhost; default-key " <key-name> "; };
server localhost { key " <key-name> "; };
2.3. Changing the Data Warehouse Sampling Scale Data Warehouse is required in Red Hat Virtualization. It can be installed and configured on the same machine as the Manager, or on a separate machine with access to the Manager. The default data retention settings may not be required for all setups, so engine-setup offers two data sampling scales: Basic and Full . Full uses the default values for the data retention settings listed in Application Settings for the Data Warehouse service (recommended when Data Warehouse is installed on a remote host). Basic reduces the values of DWH_TABLES_KEEP_HOURLY to 720 and DWH_TABLES_KEEP_DAILY to 0 , easing the load on the Manager machine. Use Basic when the Manager and Data Warehouse are installed on the same machine. The sampling scale is configured by engine-setup during installation: --== MISC CONFIGURATION ==-- Please choose Data Warehouse sampling scale: (1) Basic (2) Full (1, 2)[1]: You can change the sampling scale later by running engine-setup again with the --reconfigure-dwh-scale option. Changing the Data Warehouse Sampling Scale You can also adjust individual data retention settings if necessary, as documented in Application Settings for the Data Warehouse service .

Commands:
--== MISC CONFIGURATION ==-- Please choose Data Warehouse sampling scale: (1) Basic (2) Full (1, 2)[1]:
engine-setup --reconfigure-dwh-scale [...] Setup can automatically configure the firewall on this system. Note: automatic configuration of the firewall may overwrite current settings. Do you want Setup to configure the firewall? (Yes, No) [Yes]: [...] Perform full vacuum on the oVirt engine history database ovirt_engine_history@localhost? This operation may take a while depending on this setup health and the configuration of the db vacuum process. See https://www.postgresql.org/docs/12/static/sql-vacuum.html (Yes, No) [No]: [...] Setup can backup the existing database. The time and space required for the database backup depend on its size. This process takes time, and in some cases (for instance, when the size is few GBs) may take several hours to complete. If you choose to not back up the database, and Setup later fails for some reason, it will not be able to restore the database and all DWH data will be lost. Would you like to backup the existing database before upgrading it? (Yes, No) [Yes]: [...] Please choose Data Warehouse sampling scale: (1) Basic (2) Full (1, 2)[1]: 2 [...] During execution engine service will be stopped (OK, Cancel) [OK]: [...] Please confirm installation settings (OK, Cancel) [OK]:
22.16.12. Configuring Symmetric Authentication Using a Key To configure symmetric authentication using a key, add the following option to the end of a server or peer command: key number where number is in the range 1 to 65534 inclusive. This option enables the use of a message authentication code ( MAC ) in packets. This option is for use with the peer , server , broadcast , and manycastclient commands. The option can be used in the /etc/ntp.conf file as follows: See also Section 22.6, "Authentication Options for NTP" .

Commands:
server 192.168.1.1 key 10 broadcast 192.168.1.255 key 20 manycastclient 239.255.254.254 key 30
Chapter 39. Viewing process instance logs You can view all the process events of an instance from its Logs tab. The instance logs list all the current and process states. Business Central has two types of logs for process instances, Business and Technical logs. Procedure In Business Central, go to Menu Manage Process Instances . On the Manage Process Instances page, click the process instance whose log you want to view. Select the Logs tab: Click Business to view the business events log. Click Technical to view the technical events log. Click Asc or Desc to change the order of the log files.

Commands:
16.4. Search Models Via Metadata Properties The Teiid Designer provides a search capability to find model objects that are characterized by one or more metadata property values. To search your models using metadata: Click Search > Teiid Designer > Transformations... action on the main toolbar which opens the Search dialog. Specify desired search options for Criteria, Object Type, Data Type and Scope. Click Search . The search will be performed and the results will be displayed in the Search Results View . If the view is not yet open, it will be opened automatically.

Commands:
14.4. Changing the Media of a CDROM Changing the media of a CDROM to another source or format --path - A string containing a fully-qualified path or target of disk device --source - A string containing the source of the media --eject - Eject the media --insert - Insert the media --update - Update the media --current - can be either or both of --live and --config , depends on implementation of hypervisor driver --live - alter live configuration of running domain --config - alter persistent configuration, effect observed on boot --force - force media changing

Commands:
change-media domain path source --eject --insert --update --current --live --config --force
11.4. About JTA Transaction Manager Lookup Classes In order to execute a cache operation, the cache requires a reference to the environment's Transaction Manager. Configure the cache with the class name that belongs to an implementation of the TransactionManagerLookup interface. When initialized, the cache creates an instance of the specified class and invokes its getTransactionManager() method to locate and return a reference to the Transaction Manager. Table 11.1. Transaction Manager Lookup Classes Class Name Details org.infinispan.transaction.lookup.DummyTransactionManagerLookup Used primarily for testing environments. This testing transaction manager is not for use in a production environment and is severely limited in terms of functionality, specifically for concurrent transactions and recovery. org.infinispan.transaction.lookup.JBossStandaloneJTAManagerLookup It is a fully functional JBoss Transactions based transaction manager that overcomes the functionality limits of the DummyTransactionManager . org.infinispan.transaction.lookup.GenericTransactionManagerLookup GenericTransactionManagerLookup is used by default when no transaction lookup class is specified. This lookup class is recommended when using JBoss Data Grid with Java EE-compatible environment that provides a TransactionManager interface, and is capable of locating the Transaction Manager in most Java EE application servers. If no transaction manager is located, it defaults to DummyTransactionManager . It is important to note that when using Red Hat JBoss Data Grid with Tomcat or an ordinary Java Virtual Machine (JVM), the recommended Transaction Manager Lookup class is JBossStandaloneJTAManagerLookup , which uses JBoss Transactions. Report a bug

Commands:
Chapter 1. Connectivity Link prerequisites and permissions Before you install Connectivity Link, you must ensure that you have access to the required platforms in your environment with the correct user permissions. 1.1. Required platforms and components Red Hat account You have a Red Hat account with subscriptions for Connectivity Link and OpenShift. OpenShift OpenShift Container Platform 4.16 or later is installed, or you have access to a supported OpenShift cloud service. You are logged into an OpenShift cluster with the cluster-admin role. You have the kubectl or oc command installed. OpenShift Service Mesh Red Hat OpenShift Service Mesh 3.0 Technology Preview 2 is installed on OpenShift as your Gateway API provider. For more details, see the OpenShift Service Mesh installation documentation . You have enabled the Gateway API feature in OpenShift Service Mesh 3.0 Technology Preview 2. For more details, see the OpenShift Service Mesh documentation on enabling Gateway API . Important Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process. For more information, see Technology Preview Features - Scope of Support . cert-manager Operator for Red Hat OpenShift cert-manager Operator for Red Hat OpenShift 1.14 is installed to manage the TLS certificates for your Gateways. For more details, see the cert-manager Operator for Red Hat OpenShift documentation . Note Before using a Connectivity Link TLSPolicy, you must set up a certificate issuer for your cloud provider platform. For more details, see the OpenShift documentation on configuring an ACME issuer . 1.2. Optional platforms and components DNSPolicy For DNSPolicy, you have an account for one of the supported cloud DNS providers and have set up a hosted zone for Connectivity Link. For more details, see your cloud DNS provider documentation: Amazon Route 53 documentation . Google Cloud DNS documentation . Microsoft Azure DNS documentation . RateLimitPolicy For rate limiting policies, you have a shared accessible Redis-based datastore for rate limit counters in a multicluster environment. For details on how to install and configure a secure and highly available datastore, see the documentation for your Redis-compatible datastore: Redis documentation AWS ElastiCache (Redis OSS) User Guide Dragonfly documentation AuthPolicy For AuthPolicy, you can install Red Hat build of Keycloak if this is required in your environment. For more details, see the Red Hat build of Keycloak documentation . Observability For Observability, OpenShift user workload monitoring must be configured to remote write to a central storage system such as Thanos. For more details, see the Connectivity Link Observability Guide . Additional resources For more details, see Supported Configurations for Red Hat Connectivity Link .

Commands:
7.105. libica 7.105.1. RHBA-2015:1283 - libica bug fix and enhancement update Updated libica packages that fix several bugs and add various enhancements are now available for Red Hat Enterprise Linux 6. The libica library contains a set of functions and utilities for accessing the IBM eServer Cryptographic Accelerator (ICA) hardware on IBM System z. Note The libica packages have been upgraded to upstream version 2.4.2, which provides a number of bug fixes and enhancements over the version, including improved statistics tracking of cryptographic requests issued by libica, increased security of the cryptography library, and enhanced usability that enables better monitoring and debugging of the cryptography stack on IBM System z. (BZ# 1148124 ) Users of libica are advised to upgrade to these updated packages, which fix these bugs and add these enhancements.

Commands:
10.5.23. Options The Options directive controls which server features are available in a particular directory. For example, under the restrictive parameters specified for the root directory, Options is only set to the FollowSymLinks directive. No features are enabled, except that the server is allowed to follow symbolic links in the root directory. By default, in the DocumentRoot directory, Options is set to include Indexes and FollowSymLinks . Indexes permits the server to generate a directory listing for a directory if no DirectoryIndex (for example, index.html ) is specified. FollowSymLinks allows the server to follow symbolic links in that directory. Note Options statements from the main server configuration section need to be replicated to each VirtualHost container individually. Refer to Section 10.5.65, " VirtualHost " for more information.

Commands: