mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 4. Managing model registry permissions You can manage access to a model registry for individual users and user groups in your organization, and for service accounts in a project. OpenShift AI creates the <model-registry-name>-users group automatically for use with model registries. You can add users to this group in OpenShift, or ask the cluster admin to do so. Prerequisites You have logged in to OpenShift AI as a user with OpenShift AI administrator privileges. An available model registry exists in your deployment. The users and groups that you want to provide access to already exist in OpenShift. For more information, see Managing users and groups . Procedure From the OpenShift AI dashboard, click Settings Model registry settings . Click Manage permissions beside the model registry that you want to manage access for. The permissions page for the model registry opens. Provide one or more OpenShift groups with access to the project. On the Users tab, in the Groups section, click Add group . From the Select a group drop-down list, select a group. Note To enable access for all cluster users, add system:authenticated to the group list. To confirm your entry, click Confirm ( ). Optional: To add an additional group, click Add group and repeat the process. Provide one or more users with access to the model registry. On the Users tab, in the Users section, click Add user . In the Type username field, enter the username of the user to whom you want to provide access. To confirm your entry, click Confirm ( ). Optional: To add an additional user, click Add user and repeat the process. Provide all service accounts in a project with access to the model registry. On the Projects tab, in the Projects section, click Add project . In the Select or enter a project field, select or enter the name of the project to which you want to provide access. To confirm your entry, click Confirm ( ). Optional: To add an additional project, click Add project and repeat the process. Verification Users, groups, and accounts that were granted access to a model registry can register, view, edit, version, deploy, delete, archive, and restore models in that registry. The Users and Groups sections on the Permissions tab show the respective users and groups that you granted access to the model registry. The Projects sections on the Projects tab show the projects that you granted access to the model registry. After you provide access to a model registry, users with access can store, share, version, deploy, and track models using the model registry feature. For more information, see Working with model registries .

Commands:
Chapter 11. Kafka clients The kafka-clients JAR file contains the Kafka Producer and Consumer APIs together with the Kafka AdminClient API. The Producer API allows applications to send data to a Kafka broker. The Consumer API allows applications to consume data from a Kafka broker. The AdminClient API provides functionality for managing Kafka clusters, including topics, brokers, and other components. 11.1. Adding Kafka clients as a dependency to your Maven project This procedure shows you how to add the AMQ Streams Java clients as a dependency to your Maven project. Prerequisites A Maven project with an existing pom.xml . Procedure Add the Red Hat Maven repository to the <repositories> section of your pom.xml file. Add the clients to the <dependencies> section of your pom.xml file. Build your Maven project.

Commands:
<?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <!-- ... --> <repositories> <repository> <id>redhat-maven</id> <url>https://maven.repository.redhat.com/ga/</url> </repository> </repositories> <!-- ... --> </project>
<?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <!-- ... --> <dependencies> <dependency> <groupId>org.apache.kafka</groupId> <artifactId>kafka-clients</artifactId> <version>2.6.0.redhat-00004</version> </dependency> </dependencies> <!-- ... --> </project>
Chapter 2. Configuring Bitbucket webhooks to enable automated pipeline triggers Set up webhooks in Bitbucket to automatically trigger pipeline runs in RHDH upon code updates. Prerequisites You must have integrated Bitbucket during the RHTAP install process. You have a source repository. To locate your application's source code: On the RHDH platform, navigate to the Catalog , select an appropriate application where Bitbucket is configured as the repository host. Go to the Overview tab and select View Source to open the repository where your application's source code is housed. You must have a Webhook URL. You can find these credentials in your private.env file. Procedure Navigate to your Bitbucket source repository. Go to Repository settings > Webhooks , and select Add webhook . In the Title field, enter an appropriate title. In the URL field, enter the webhook URL. . In the Trigger section: Select Push . Select Merged . Select Save . Verification Make a code change in your Bitbucket repository and push the changes. Navigate to the CI tab in RHDH. Verify that a pipeline run is triggered after your code update. Revised on 2025-02-06 18:00:01 UTC

Commands:
Chapter 17. Configuring Delayed Redelivery Delayed redelivery to an address is defined by the redelivery-delay attribute of an address-setting configuration element. If a redelivery delay is specified, JBoss EAP waits for the duration of this delay before redelivering messages. If redelivery-delay is set to 0 , there is no redelivery delay. To get the current value of redelivery-delay for a given address-setting , use the following management CLI command as an example. The table below lists the configuration attributes of an address-setting that can be used to configure the redelivery of messages. Set the value for a given attribute using the following management CLI command as an example. Table 17.1. Delivery Related Attributes of Address Settings Attribute Description max-delivery-attempts Defines how many time a canceled message can be redelivered before sending to the dead-letter-address . The default is 10 . max-redelivery-delay Maximum value for the redelivery-delay in milliseconds. You can set the max-redelivery-delay parameter to prevent the delay from becoming too large. The default is redelivery-delay * 10 . redelivery-delay Defines how long to wait in milliseconds before attempting redelivery of a canceled message. The default is 0 . redelivery-multiplier Multiplier to apply to the redelivery-delay parameter. Each time a message is redelivered, the delay period becomes equal to the redelivery-delay * redelivery-multiplier . The default is 1.0 . See Address Settings for details on configuring an address-setting .

Commands:
/subsystem=messaging-activemq/server=default/address-setting= YOUR_ADDRESS_SETTING :read-attribute(name=redelivery-delay)
/subsystem=messaging-activemq/server=default/address-setting= YOUR_ADDRESS_SETTING :write-attribute(name= ATTRIBUTE ,value= NEW_VALUE )
Chapter 103. KafkaUserScramSha512ClientAuthentication schema reference Used in: KafkaUserSpec The type property is a discriminator that distinguishes use of the KafkaUserScramSha512ClientAuthentication type from KafkaUserTlsClientAuthentication , KafkaUserTlsExternalClientAuthentication . It must have the value scram-sha-512 for the type KafkaUserScramSha512ClientAuthentication . Property Description password Specify the password for the user. If not set, a new password is generated by the User Operator. Password type Must be scram-sha-512 . string

Commands:
Chapter 2. Test suite versions You must install the latest version of the certification tooling and use the latest workflow for the certification process. After a new version of the certification tooling is released, Red Hat supports the tooling and workflow for a period of 90 days post the release. At the end of the 90 days period, test logs/results generated using the versions are automatically rejected and you are expected to regenerate the test logs/results using the latest tooling and workflow. The latest version of the certification tooling and workflow is available (by default) via Red Hat Subscription Management and documented in the CCSP Workflow Guide . The certifications are supported on the following RHEL version and architecture. Table 2.1. Supported RHEL version and architecture RHEL version Architecture RHEL 9 64-bit AMD and Intel 64-bit IBM Z 64-bit ARM Little endian IBM Power systems RHEL 8 64-bit AMD and Intel 64-bit IBM Z 64-bit ARM Little endian IBM Power systems

Commands:
probe::socket.readv.return Name probe::socket.readv.return - Conclusion of receiving a message via sock_readv Synopsis Values success Was receive successful? (1 = yes, 0 = no) protocol Protocol value flags Socket flags value name Name of this probe state Socket state value size Size of message received (in bytes) or error code if success = 0 type Socket type value family Protocol family value Context The message receiver. Description Fires at the conclusion of receiving a message on a socket via the sock_readv function

Commands:
socket.readv.return
5.198. mod_nss 5.198.1. RHBA-2012:0919 - mod_nss bug fix update An updated mod_nss package that fixes several bugs is now available for Red Hat Enterprise Linux 6. The mod_nss module provides strong cryptography for the Apache HTTP Server via the Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols, using the Network Security Services (NSS) security library. Bug Fixes BZ# 749408 PK11_ListCerts was called for every server instead of only once. If there were more than a few hundred certificates in the database, the PK11_ListCerts call could take several seconds or even minutes. BZ# 749409 ECC is now enabled by default for mod_nss. BZ# 797326 and BZ# 797358 The fix for BZ# 691502 , related to clearing the SSL cache when mod_nss started, introduced a file descriptor leak in the httpd Apache daemon. This has been fixed. Users of mod_nss are advised to upgrade to this updated package, which fixes these bugs.

Commands:
Chapter 3. Authentication Modules 3.1. Configuring Transports The security-domain attribute within the transport element is used to set a comma separated list of desired security domains (and their associated authentication modules). Usernames can be fully qualified to authenticate only against a particular domain: If a username is not fully qualified, the installed domains will be consulted in order until a domain successfully authenticates the user. If no domain can authenticate the user, the login attempt will fail. Details of the failed attempt (including information such as invalid users and which domains were consulted) will be in the server log with appropriate levels of severity. The security domain defined for each transport type can be different. Users can configure a unique transport for JDBC and ODBC (and for multiple JDBC ports), each with a different security domain.

Commands:
<transport name="jdbc" protocol="teiid" socket-binding="teiid-jdbc"> <authentication security-domain="teiid-security"/> </transport>
username@domainname
3.8. Bonding Modes Red Hat Virtualization uses Mode 4 by default, but supports the following common bonding modes: Mode 0 (round-robin policy) Transmits packets through network interface cards in sequential order. Packets are transmitted in a loop that begins with the first available network interface card in the bond and ends with the last available network interface card in the bond. All subsequent loops then start with the first available network interface card. Mode 0 offers fault tolerance and balances the load across all network interface cards in the bond. However, Mode 0 cannot be used in conjunction with bridges, and is therefore not compatible with virtual machine logical networks. Mode 1 (active-backup policy) Sets all network interface cards to a backup state while one network interface card remains active. In the event of failure in the active network interface card, one of the backup network interface cards replaces that network interface card as the only active network interface card in the bond. The MAC address of the bond in Mode 1 is visible on only one port to prevent any confusion that might otherwise be caused if the MAC address of the bond changed to reflect that of the active network interface card. Mode 1 provides fault tolerance and is supported in Red Hat Virtualization. Mode 2 (XOR policy) Selects the network interface card through which to transmit packets based on the result of an XOR operation on the source and destination MAC addresses modulo network interface card slave count. This calculation ensures that the same network interface card is selected for each destination MAC address used. Mode 2 provides fault tolerance and load balancing and is supported in Red Hat Virtualization. Mode 3 (broadcast policy) Transmits all packets to all network interface cards. Mode 3 provides fault tolerance and is supported in Red Hat Virtualization. Mode 4 (IEEE 802.3ad policy) Creates aggregation groups in which the interfaces share the same speed and duplex settings. Mode 4 uses all network interface cards in the active aggregation group in accordance with the IEEE 802.3ad specification and is supported in Red Hat Virtualization. Mode 5 (adaptive transmit load balancing policy) Ensures the distribution of outgoing traffic accounts for the load on each network interface card in the bond and that the current network interface card receives all incoming traffic. If the network interface card assigned to receive traffic fails, another network interface card is assigned to the role of receiving incoming traffic. Mode 5 cannot be used in conjunction with bridges, therefore it is not compatible with virtual machine logical networks. Mode 6 (adaptive load balancing policy) Combines Mode 5 (adaptive transmit load balancing policy) with receive load balancing for IPv4 traffic without any special switch requirements. ARP negotiation is used for balancing the receive load. Mode 6 cannot be used in conjunction with bridges, therefore it is not compatible with virtual machine logical networks.

Commands:
5.4.2.2. Multiple Readers/Writers A hard drive that processes I/O requests from multiple sources experiences a different load than a hard drive that services I/O requests from only one source. The main reason for this is due to the fact that multiple I/O requesters have the potential to bring higher I/O loads to bear on a hard drive than a single I/O requester. This is because the I/O requester must perform some amount of processing before an I/O can take place. After all, the requester must determine the nature of the I/O request before it can be performed. Because the processing necessary to make this determination takes time, there is an upper limit on the I/O load that any one requester can generate -- only a faster CPU can raise it. This limitation becomes more pronounced if the requester requires human input before performing an I/O. However, with multiple requesters, higher I/O loads may be sustained. As long as sufficient CPU power is available to support the processing necessary to generate the I/O requests, adding more I/O requesters increases the resulting I/O load. However, there is another aspect to this that also has a bearing on the resulting I/O load. This is discussed in the following section.

Commands:
Chapter 3. Upgrade to Spring Boot 2 This chapter explains how to upgrade your applications to Spring Boot 2.0 from Spring Boot 1. 3.1. Before you begin Before you start the migration to Spring Boot 2, you must review the system requirements and dependencies. Upgrade to the latest 1.5.x version Before you start, upgrade to the latest 1.5.x available version. This is to ensure that you are building against the most recent dependencies of that line. Review dependencies The migration to Spring Boot 2 will result in upgrading a number of dependencies. Review the dependency management for 1.5.x with the dependency management for 2.0.x to assess how your project is affected. Identify the compatible versions for the dependencies that are not managed by Spring Boot and then define the explicit versions for these. Review custom configuration Any custom configuration that your project defines might need to be reviewed on upgrade. If this can be replaced by the use of standard auto-configuration, do it so before upgrading. Review system requirements Spring Boot 2.0 requires Java 8 or later. It also requires Spring Framework 5.0. Java 6 and 7 are no longer supported. 3.2. Upgrade from Spring Boot 1 to Spring Boot 2 Once you have reviewed the state of your project and its dependencies, upgrade to the latest maintenance release of Spring Boot 2.x. It is recommended to upgrade in the phases. For example, first upgrade from Spring Boot 1.5 to Spring Boot 2.0 and then upgrade to 2.1 and then to the latest maintenance release of Spring Boot 2. Migrating configuration properties With Spring Boot 2.0, many configuration properties were renamed or removed. Hence you need to update the application.properties/application.yml accordingly. You can achieve that with the help of a new spring-boot-properties-migrator module. Once added as a dependency to your project, this will not only analyze your application's environment and print diagnostics at startup, but also temporarily migrate properties at runtime for you. Procedure Add spring-boot-properties-migrator module to dependency section of your project's pom.xml . Note Once you're done with the migration, please make sure to remove this module from your project's dependencies.

Commands:
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-properties-migrator</artifactId> <scope>runtime</scope> </dependency> runtime("org.springframework.boot:spring-boot-properties-migrator")
Chapter 31. X Window System Configuration During installation, the system's monitor, video card, and display settings are configured. To change any of these settings after installation, use the X Configuration Tool . To start the X Configuration Tool , go to Applications (the main menu on the panel) => Administration => Display , or type the command system-config-display at a shell prompt (for example, in an XTerm or GNOME terminal). If the X Window System is not running, a small version of X is started to run the program. After changing any of the settings, log out of the graphical desktop and log back in to enable the changes. 31.1. Display Settings The Settings tab allows users to change the resolution and color depth . The display of a monitor consists of tiny dots called pixels . The number of pixels displayed at one time is called the resolution. For example, the resolution 1024x768 means that 1024 horizontal pixels and 768 vertical pixels are used. The higher the resolution values, the more images the monitor can display at one time. The color depth of the display determines how many possible colors are displayed. A higher color depth means more contrast between colors. Figure 31.1. Display Settings

Commands:
Chapter 5. Configuring JBoss EAP Subsystems to Work on Cloud Platforms Some JBoss EAP subsystems must be configured to work properly on cloud platforms, such as Amazon EC2 and Microsoft Azure. This is required because a JBoss EAP server is usually bound to a cloud virtual machine's private IP address, for example: 10.x.x.x , which is only visible from within the cloud platform. For certain subsystems, this address must also be mapped to a server's public IP address, which is visible from outside the cloud. 5.1. Web Services When a client makes a web service request using Service.create(wsdlURL, serviceName); , the user connects to the server public IP address, but is subsequently redirected to an address defined in the server configuration files in the webservices subsystem. By default, this address is USD{jboss.bind.address:127.0.0.1} , which means that on a cloud platform, the caller will be redirected to the server's private IP address and will be unable to resolve the request. The server's public IP address has to be configured in the wsdl-host element, using the following command: 5.2. Messaging When using messaging on a cloud platform, the connection factory that the client uses must have a connector pointing to the server's public IP address. For this reason a new connector and socket binding must be created for JBoss EAP servers running a full profile. The referenced http-public socket binding must be created within the socket-binding-group : Create the new http-connector element in the messaging subsystem: Set the connectors in the connection-factory , which will be used by clients. For example, configuration of RemoteConnectionFactory as the default connection will be: 5.3. Remoting Configuration for High Availability If you are using JBoss EAP HA features with clustered Jakarta Enterprise Beans on a cloud platform, some extra configuration for the remoting subsystem is required to ensure Jakarta Enterprise Beans clients can receive cluster view updates. This is done by configuring client-mappings for the remoting subsystem socket binding:

Commands:
/subsystem=webservices:write-attribute(name=wsdl-host,value=PUBLIC_IP_ADDRESS)
/socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=http-public:add(host=PUBLIC_IP_ADDRESS,port=USD{jboss.http.port:8080})
/subsystem=messaging-activemq/server=default/http-connector=http-public-connector:add(endpoint=http-acceptor, socket-binding=http-public)
/subsystem=messaging-activemq/server=default/connection-factory=RemoteConnectionFactory:write-attribute(name=connectors, value=["http-public-connector"]
/socket-binding-group=standard-sockets/socket-binding=http:write-attribute(name=client-mappings,value=[{ "destination-address" => "PUBLIC_IP_ADDRESS", "destination-port" => "8080" }])
8.50. efibootmgr 8.50.1. RHBA-2014:1616 - efibootmgr bug fix update Updated efibootmgr packages that fix one bug are now available for Red Hat Enterprise Linux 6. The efibootmgr utility is responsible for the boot loader installation on Unified Extensible Firmware Interface (UEFI) systems. Bug Fix BZ# 1121782 Previously, during their boot process, some newer machines created variables larger than 1024 bytes, which the kernel API for Unified Extensible Firmware Interface (UEFI) does not support. Consequently, the efibootmgr utility received an error trying to read such variables, and skipped them, which caused anaconda to fail to create boot variables. This update changes efibootmgr to show the variables but not to display their contents. As a result, anaconda is able to read the large variables, and creates boot variables successfully. Users of efibootmgr are advised to upgrade to these updated packages, which fix this bug.

Commands: