mtpti5iD/redhat-docs_dataset huggingface dataset:
17.4. Run the Application Once built the deployed applications may be accessed using the included classes. Using the AdminClient In this example neither the AdminServer nor the AppOneServer are clustered at the JBoss EAP level; only the JBoss Data Grid instances are clustered as configured by the application. This application will perform the following: Add values to the App1 cache, using AdminApp , and validated they are replicated to the server instance of AppOne . Add a value to the App2 cache, then rollback the transaction and confirm that it is not added to the cache after the rollback. Procedure 17.4. Execute the AdminClient application Open a command line and navigate to the USDQUICKSTART_HOME/client/ directory. Execute the following command: Note By default the application will attempt to access localhost:4447 and localhost:4547 for the AdminHost and AppOneHost . This may be changed by adding the following parameter to the mvn command: Confirm that the following text appears in the console; any unexpected results will raise an Exception: Using the AppOneClient In this example both JBoss EAP and the JBoss Data Grid caches are clustered; however, the purpose of this example is to demonstrate that the clusters are independent of one other. The JBoss Data Grid cluster is able to use a different JGroups implementation compared to the JBoss EAP servers, and this example will: Add values to the App2 cache using the AdminApp and access AppOne to show that the EJB invocation is clustered and both AppTwo instances are used. Procedure 17.5. Execute the AppOneClient Open a command line and navigate to the USDQUICKSTART_HOME/client/ directory. Execute the following command: Confirm that the following text appears in the console; any unexpected results will raise an Exception: Report a bug

Commands:
mvn -Dexec.mainClass=org.jboss.as.quickstarts.datagrid.eap.app.AdminClient exec:java
-Dexec.args="AdminHost AdminPort AppOneHost AppOnePort"
Add a value to App1Cache with the AdminApp and check on the same instance that the value is correct added success Check the previous added value of App1Cache by accessing the AppOne Server success Add a value to App2Cache and check on the same instance that the value is correct added success Check whether changes to a cache are rollbacked if the transaction fail The cache App2 work as expected on rollback
mvn -Dexec.mainClass=org.jboss.as.quickstarts.datagrid.eap.app.AppOneClient exec:java
Add a value to App2Cache with the AdminApp Access the App2Cache from the AppOneServer by using the clustered EJB@AppTwoServer success : received the following node names for EJB invocation : [node3, node4]
Chapter 53. DeploymentTemplate schema reference Used in: CruiseControlTemplate , EntityOperatorTemplate , JmxTransTemplate , KafkaBridgeTemplate , KafkaConnectTemplate , KafkaExporterTemplate , KafkaMirrorMakerTemplate Full list of DeploymentTemplate schema properties Use deploymentStrategy to specify the strategy used to replace old pods with new ones when deployment configuration changes. Use one of the following values: RollingUpdate : Pods are restarted with zero downtime. Recreate : Pods are terminated before new ones are created. Using the Recreate deployment strategy has the advantage of not requiring spare resources, but the disadvantage is the application downtime. Example showing the deployment strategy set to Recreate . # ... template: deployment: deploymentStrategy: Recreate # ... This configuration change does not cause a rolling update. 53.1. DeploymentTemplate schema properties Property Property type Description metadata MetadataTemplate Metadata applied to the resource. deploymentStrategy string (one of [RollingUpdate, Recreate]) Pod replacement strategy for deployment configuration changes. Valid values are RollingUpdate and Recreate . Defaults to RollingUpdate .

Commands:
template: deployment: deploymentStrategy: Recreate
Chapter 15. GenericKafkaListenerConfigurationBootstrap schema reference Used in: GenericKafkaListenerConfiguration Full list of GenericKafkaListenerConfigurationBootstrap schema properties Configures bootstrap service settings for listeners. Example configuration for the host , nodePort , loadBalancerIP , and annotations properties is shown in the GenericKafkaListenerConfiguration schema section. 15.1. Specifying alternative bootstrap addresses To specify alternative names for the bootstrap address, use the alternativeNames property. This property is applicable to all types of listeners. The names are added to the broker certificates and can be used for TLS hostname verification. Example route listener configuration with additional bootstrap addresses listeners: #... - name: external1 port: 9094 type: route tls: true configuration: bootstrap: alternativeNames: - example.hostname1 - example.hostname2 # ... 15.2. GenericKafkaListenerConfigurationBootstrap schema properties Property Property type Description alternativeNames string array Additional alternative names for the bootstrap service. The alternative names will be added to the list of subject alternative names of the TLS certificates. host string Specifies the hostname used for the bootstrap resource. For route (optional) or ingress (required) listeners only. Ensure the hostname resolves to the Ingress endpoints; no validation is performed by Streams for Apache Kafka. nodePort integer Node port for the bootstrap service. For nodeport listeners only. loadBalancerIP string The loadbalancer is requested with the IP address specified in this property. This feature depends on whether the underlying cloud provider supports specifying the loadBalancerIP when a load balancer is created. This property is ignored if the cloud provider does not support the feature. For loadbalancer listeners only. annotations map Annotations added to Ingress , Route , or Service resources. You can use this property to configure DNS providers such as External DNS. For loadbalancer , nodeport , route , or ingress listeners only. labels map Labels added to Ingress , Route , or Service resources. For loadbalancer , nodeport , route , or ingress listeners only. externalIPs string array External IPs associated to the nodeport service. These IPs are used by clients external to the OpenShift cluster to access the Kafka brokers. This property is helpful when nodeport without externalIP is not sufficient. For example on bare-metal OpenShift clusters that do not support Loadbalancer service types. For nodeport listeners only.

Commands:
listeners: # - name: external1 port: 9094 type: route tls: true configuration: bootstrap: alternativeNames: - example.hostname1 - example.hostname2
Chapter 16. Using Cruise Control to modify topic replication factor Make requests to the /topic_configuration endpoint of the Cruise Control REST API to modify topic configurations, including the replication factor. Prerequisites You are logged in to Red Hat Enterprise Linux as the Kafka user. You have configured Cruise Control . You have deployed the Cruise Control Metrics Reporter . Procedure Start the Cruise Control server. The server starts on port 9092 by default; optionally, specify a different port. cd ./cruise-control/ ./kafka-cruise-control-start.sh config/cruisecontrol.properties <port_number> To verify that Cruise Control is running, send a GET request to the /state endpoint of the Cruise Control server: curl -X GET 'http://<cc_host>:<cc_port>/kafkacruisecontrol/state' Run the bin/kafka-topics.sh command with the --describe option to check the current replication factor of the target topic: ./bin/kafka-topics.sh \ --bootstrap-server localhost:9092 \ --topic <topic_name> \ --describe Update the replication factor for the topic: curl -X POST 'http://<cc_host>:<cc_port>/kafkacruisecontrol/topic_configuration?topic=<topic_name>&replication_factor=<new_replication_factor>&dryrun=false' For example, curl -X POST 'localhost:9090/kafkacruisecontrol/topic_configuration?topic=topic1&replication_factor=3&dryrun=false' . Run the bin/kafka-topics.sh command with the --describe option, as before, to see the results of the change to the topic.

Commands:
cd ./cruise-control/ ./kafka-cruise-control-start.sh config/cruisecontrol.properties <port_number>
curl -X GET 'http://<cc_host>:<cc_port>/kafkacruisecontrol/state'
./bin/kafka-topics.sh --bootstrap-server localhost:9092 --topic <topic_name> --describe
curl -X POST 'http://<cc_host>:<cc_port>/kafkacruisecontrol/topic_configuration?topic=<topic_name>&replication_factor=<new_replication_factor>&dryrun=false'
Chapter 7. Submitting the test results file You can submit the test results file to Red Hat using either RHCert CLI or the Red Hat Certification Tool . Using the RHCert CLI Tool: Procedure Log in to authenticate your device. Note Logging in is mandatory to submit the test results file. Open the generated URL in a new browser window or tab. Enter the login and password and click Log in . Click Grant access . Device log in successful message displays. Return to the terminal and enter yes to the Please confirm once you grant access prompt. Submit the result file. When prompted, enter your Certification ID. Using Red Hat Certification Tool Procedure Log in to Red Hat Certification portal . On the homepage, enter the product case number in the search bar. Select the case number from the list that is displayed. On the Summary tab, under the Files section, click Upload . steps Red Hat will review your submitted results file and suggest the steps to grant certification. Visit the Red Hat Certification portal for more information. Once certified, the product is listed on the Red Hat Ecosystem Catalog .

Commands:
rhcert-cli login
rhcert-submit
Chapter 7. Resolved issues The following notable issues are resolved in Red Hat OpenShift AI 2.18. Security updates, bug fixes, and enhancements for Red Hat OpenShift AI 2.18 are released as asynchronous errata. All OpenShift AI errata advisories are published on the Red Hat Customer Portal . 7.1. Issues resolved in Red Hat OpenShift AI 2.18 (March 2025) RHOAIENG-19711 - Kueue-controller-manager uses old metrics port after upgrade from 2.16.0 to 2.17.0 Previously, after upgrading, the Kueue Operator continued to use the old port (8080) instead of the new port (8443) for metrics. As a result, the OpenShift console Observe > Targets page showed that the status of the Kueue Operator was Down . This issue is now resolved. RHOAIENG-19261 - The TrustyAI installation might fail due to missing custom resource definitions (CRDs) Previously, when installing or upgrading OpenShift AI, the TrustyAI installation might have failed due to missing InferenceService and ServingRuntime CRDs. As a result, the Trusty AI controller went into the CrashLoopBackOff state. This issue is now resolved. RHOAIENG-18933 - Increased workbench image size can delay workbench startup Previously, as a result of the presence of the kubeflow-training Python SDK in the 2024.2 workbench images, the workbench image size was increased and may have caused a delay when starting the workbench. This issue is now resolved. RHOAIENG-18884 - Enabling NIM account setup is incomplete Previously, when you tried to enable the NVIDIA NIM model serving platform, the odh-model-controller deployment started before the NIM account setup was complete. As a result, the NIM account setup was incomplete and the platform was not enabled. This issue is now resolved. RHOAIENG-18675 - Workbenches component fails after upgrading Previously, when upgrading to OpenShift AI 2.18, the workbench component did not upgrade correctly. Specifically, BuildConfigs and resources that follow it (for example, RStudio BuildConfigs and ROCm imagestreams ) were not updated, which caused the workbench component reconciliation in the DataScienceCluster to fail. This issue is now resolved. RHOAIENG-15123 (also documented as RHOAIENG-10790 and RHOAIENG-14265 ) - Pipelines schedule might fail after upgrading Previously, when you upgraded to OpenShift AI 2.18, any data science pipeline scheduled runs that existed before the upgrade might fail to execute, resulting in an error message in the task pod. This issue is now resolved.

Commands:
Chapter 7. Tracking the last login time without setting a lockout policy You can use the Account Policy plug-in to track user login times without setting an expiration time or inactivity period. In this case, the plug-in adds the lastLoginTime attribute to user entries. 7.1. Configuring the Account Policy plug-in to record the last login time Follow this procedure to record the last login time of users in the lastLoginTime attribute of user entries. Procedure Enable the Account Policy plug-in: # dsconf -D " cn=Directory Manager " ldap://server.example.com plugin account-policy enable Create the plug-in configuration entry to record login times: # dsconf -D " cn=Directory Manager " ldap://server.example.com plugin account-policy config-entry set " cn=config,cn=Account Policy Plugin,cn=plugins,cn=config " --always-record-login yes --state-attr lastLoginTime This command uses the following options: --always-record-login yes : Enables logging of the log in time. --state-attr lastLoginTime : Configures that the Account Policy plug-in stores the last log in time in the lastLoginTime attribute of users. Restart the instance: # dsctl instance_name restart Verification Log in to Directory Server as a user. For example, run a search: # ldapsearch -H ldap://server.example.com -x -D " uid=example,ou=People,dc=example,dc=com " -W -b " dc=example,dc=com " Display the lastLoginTime attribute of the user you used in the step: # ldapsearch -H ldap://server.example.com -x -D " cn=Directory Manager " -W -b " uid=example,ou=people,dc=example,dc=com " lastLoginTime ... dn: uid=example,ou=People,dc=example,dc=com lastLoginTime: 20210913091435Z If the lastLoginTime attribute exists and Directory Server updated its value, recording of the last login time works.

Commands:
dsconf -D " cn=Directory Manager " ldap://server.example.com plugin account-policy enable
dsconf -D " cn=Directory Manager " ldap://server.example.com plugin account-policy config-entry set " cn=config,cn=Account Policy Plugin,cn=plugins,cn=config " --always-record-login yes --state-attr lastLoginTime
dsctl instance_name restart
ldapsearch -H ldap://server.example.com -x -D " uid=example,ou=People,dc=example,dc=com " -W -b " dc=example,dc=com "
ldapsearch -H ldap://server.example.com -x -D " cn=Directory Manager " -W -b " uid=example,ou=people,dc=example,dc=com " lastLoginTime dn: uid=example,ou=People,dc=example,dc=com lastLoginTime: 20210913091435Z
Chapter 12. Identity: Delegating Access to Hosts and Services As discussed in Section 1.3, "Relationships Between Servers and Clients" , within the IdM domain, manage means being able to retrieve a keytab and certificates for another host or service. Every host and service has a managedby entry which lists what hosts or services can manage it. By default, a host can manage itself and all of its services. It is also possible to allow a host to manage other hosts, or services on other hosts, by updating the appropriate delegations or providing a suitable managedby entry. An IdM service can be managed from any IdM host, as long as that host has been granted, or delegated , permission to access the service. Likewise, hosts can be delegated permissions to other hosts within the domain. Figure 12.1. Host and Service Delegation Note If a host is delegated authority to another host through a managedBy entry, it does not mean that the host has also been delegated management for all services on that host. Each delegation has to be performed independently. 12.1. Delegating Service Management A host is delegated control over a service using the service-add-host command. There are two parts to delegating the service: specifying the principal and identifying the hosts (in a comma-separated list) with control: For example: Once the host is delegated authority, the host principal can be used to manage the service: To create a ticket for this service, create a certificate request on the host with the delegated authority and use the cert-request command to create a service entry and load the certification information:

Commands:
ipa service-add-host principal --hosts= hostnames
ipa service-add-host http/web.example.com --hosts=client1.example.com
kinit -kt /etc/krb5.keytab host/`hostname` ipa-getkeytab -s `hostname` -k /tmp/test.keytab -p http/web.example.com Keytab successfully retrieved and stored in: /tmp/test.keytab
ipa cert-request --add --principal=http/web.example.com web.csr Certificate: MIICETCCAXqgA...[snip] Subject: CN=web.example.com,O=EXAMPLE.COM Issuer: CN=EXAMPLE.COM Certificate Authority Not Before: Tue Feb 08 18:51:51 2011 UTC Not After: Mon Feb 08 18:51:51 2016 UTC Fingerprint (MD5): c1:46:8b:29:51:a6:4c:11:cd:81:cb:9d:7c:5e:84:d5 Fingerprint (SHA1): 01:43:bc:fa:b9:d8:30:35:ee:b6:54:dd:a4:e7:d2:11:b1:9d:bc:38 Serial number: 1005
Chapter 2. Installing the Red Hat Quay Operator from the OperatorHub Use the following procedure to install the Red Hat Quay Operator from the OpenShift Container Platform OperatorHub. Procedure Using the OpenShift Container Platform console, select Operators OperatorHub . In the search box, type Red Hat Quay and select the official Red Hat Quay Operator provided by Red Hat. This directs you to the Installation page, which outlines the features, prerequisites, and deployment information. Select Install . This directs you to the Operator Installation page. The following choices are available for customizing the installation: Update Channel: Choose the update channel, for example, stable-3.13 for the latest release. Installation Mode: Choose All namespaces on the cluster if you want the Red Hat Quay Operator to be available cluster-wide. It is recommended that you install the Red Hat Quay Operator cluster-wide. If you choose a single namespace, the monitoring component will not be available by default. Choose A specific namespace on the cluster if you want it deployed only within a single namespace. Approval Strategy: Choose to approve either automatic or manual updates. Automatic update strategy is recommended. Select Install .

Commands:
Chapter 5. Understand Micrometer integration 5.1. Micrometer in JBoss EAP Micrometer integration in JBoss EAP introduces a vendor-neutral observability layer with a reusable API for registering and tracking performance metrics across applications. This extension integrates with Micrometer, allowing deployed applications to access its API and display application-specific metrics alongside the server metrics provided by the extension. Note JBoss EAP uses the existing metrics subsystem. You must manually add and configure this extension. Additional resources Micrometer Metrics subsystem configuration in WildFly Admin guide Micrometer documentation

Commands:
Chapter 3. Customizing Red Hat Developer Hub backend secret The default Red Hat Developer Hub configuration defines the Developer Hub backend secret for service to service authentication. You can define your custom Developer Hub backend secret. Prerequisites You added a custom Developer Hub application configuration , and have sufficient permissions to modify it. Procedure To define the Developer Hub backend secret, add to your custom my-rhdh-secrets.txt file the BACKEND_SECRET environment variable with a base64 encoded string. Use a unique value for each Developer Hub instance. USD echo > my-rhdh-secrets.txt "BACKEND_SECRET=USD(node -p 'require("crypto").randomBytes(24).toString("base64")')" my-rhdh-secrets.txt example Add your backend secret to your custom app-config.yaml file. app-config.yaml excerpt defining the backend secret backend: auth: externalAccess: - type: legacy options: subject: legacy-default-config secret: "USD{BACKEND_SECRET}"

Commands:
echo > my-rhdh-secrets.txt "BACKEND_SECRET=USD(node -p 'require("crypto").randomBytes(24).toString("base64")')"
BACKEND_SECRET=3E2/rIPuZNFCtYHoxVP8wjriffnN1q/z
backend: auth: externalAccess: - type: legacy options: subject: legacy-default-config secret: "USD{BACKEND_SECRET}"
Chapter 1. Insights client overview The Insights client ( insights-client ) is the client for Red Hat Insights for Red Hat Enterprise Linux. Run insights-client from the command line. 1.1. Red Hat Insights client distribution Insights client is available for the following releases of Red Hat Enterprise Linux (RHEL). RHEL release Comments RHEL 9 Distributed with Insights client pre-installed. RHEL 8 Distributed with Insights client pre-installed, unless RHEL 8 was installed as a minimal installation. RHEL 7 Distributed with the Insights client RPM package loaded but not installed. RHEL 6.10 and later You must download the Insights client RPM package and install it. Additional resources Getting Started with Insights with FedRAMP

Commands:
Chapter 6. Migration from versions of .NET 6.1. Migration from versions of .NET Microsoft provides instructions for migrating from most versions of .NET Core. If you are using a version of .NET that is no longer supported or want to migrate to a newer .NET version to expand functionality, see the following articles: Migrate from ASP.NET Core 8.0 to 9.0 Migrate from ASP.NET Core 7.0 to 8.0 Migrate from ASP.NET Core 6.0 to 7.0 Migrate from ASP.NET Core 5.0 to 6.0 Migrate from ASP.NET Core 3.1 to 5.0 Migrate from ASP.NET Core 3.0 to 3.1 Migrate from ASP.NET Core 2.2 to 3.0 Migrate from ASP.NET Core 2.1 to 2.2 Migrate from .NET Core 2.0 to 2.1 Migrate from ASP.NET to ASP.NET Core Migrating .NET Core projects from project.json Migrate from project.json to .csproj format Note If migrating from .NET Core 1.x to 2.0, see the first few related sections in Migrate from ASP.NET Core 1.x to 2.0 . These sections provide guidance that is appropriate for a .NET Core 1.x to 2.0 migration path. 6.2. Porting from .NET Framework Refer to the following Microsoft articles when migrating from .NET Framework: For general guidelines, see Porting to .NET Core from .NET Framework . For porting libraries, see Porting to .NET Core - Libraries . For migrating to ASP.NET Core, see Migrating to ASP.NET Core . Several technologies and APIs present in the .NET Framework are not available in .NET Core and .NET. If your application or library requires these APIs, consider finding alternatives or continue using the .NET Framework. .NET Core and .NET do not support the following technologies and APIs: Desktop applications, for example, Windows Forms and Windows Presentation Foundation (WPF) Windows Communication Foundation (WCF) servers (WCF clients are supported) .NET remoting Additionally, several .NET APIs can only be used in Microsoft Windows environments. The following list shows examples of these Windows-specific APIs: Microsoft.Win32.Registry System.AppDomains System.Security.Principal.Windows Important Several APIs that are not supported in the default version of .NET may be available from the Microsoft.Windows.Compatibility NuGet package. Be careful when using this NuGet package. Some of the APIs provided (such as Microsoft.Win32.Registry ) only work on Windows, making your application incompatible with Red Hat Enterprise Linux.

Commands: