mtpti5iD/redhat-docs_dataset huggingface dataset:
3.2. Red Hat High Availability Add-On Resource Classes There are several classes of resource agents supported by Red Hat High Availability Add-On: LSB - The Linux Standards Base agent abstracts the compliant services supported by the LSB, namely those services in /etc/init.d and the associated return codes for successful and failed service states (started, stopped, running status). OCF - The Open Cluster Framework is superset of the LSB (Linux Standards Base) that sets standards for the creation and execution of server initialization scripts, input parameters for the scripts using environment variables, and more. systemd - The newest system services manager for Linux based systems, systemd uses sets of unit files rather than initialization scripts as does LSB and OCF. These units can be manually created by administrators or can even be created and managed by services themselves. Pacemaker manages these units in a similar way that it manages OCF or LSB init scripts. Upstart - Much like systemd, Upstart is an alternative system initialization manager for Linux. Upstart uses jobs, as opposed to units in systemd or init scripts. STONITH - A resource agent exclusively for fencing services and fence agents using STONITH. Nagios - Agents that abstract plug-ins for the Nagios system and infrastructure monitoring tool.

Commands:
Chapter 1. Updating Red Hat Enterprise Linux AI Red Hat Enterprise Linux AI allows you to update your instance so you can use the latest version of RHEL AI and InstructLab. 1.1. Updating your RHEL AI instance You can update your instance to use the latest version of RHEL AI and InstructLab Prerequisites You installed and deployed a Red Hat Enterprise Linux AI instance on one of the supported platforms. You created a Red Hat registry account. You have root user access on your machine. Procedure Log into your Red Hat registry account with the podman command: USD sudo podman login registry.redhat.io --username <user-name> --password <user-password> --authfile /etc/ostree/auth.json Or you can log in with the skopeo command: USD sudo skopeo login registry.redhat.io --username <user-name> --password <user-password> --authfile /etc/ostree/auth.json Upgrading to a minor version of Red Hat Enterprise Linux AI You can upgrade your instance to use the latest version of Red Hat Enterprise Linux AI by using the bootc image for your machines hardware. USD sudo bootc switch registry.redhat.io/rhelai1/bootc-<hardware-vendor>-rhel9:<rhel-ai-version> where <hardware-vendor> Specify the hardare vendor for your accelerators. Valid values include: nvidia , amd , and intel . <rhel-ai-version> Specify the RHEL AI version you want to upgrade to. Example command for machines with NVIDIA accelerators USD sudo bootc switch registry.redhat.io/rhelai1/bootc-nvidia-rhel9:1.4 Restart your system by running the following command: USD sudo reboot -n Important When upgrading to RHEL AI version 1.4, the /etc/skel/.config/containers/storage.conf storage configuration needs to be copied to your <user-home>/.config/containers/storage.conf home directory before re-initializing. For example: USD cp /etc/skel/.config/containers/storage.conf <user-home>/.config/containers/storage.con Upgrading to a z-stream version of Red Hat Enterprise Linux AI If a z-stream exists, you can upgrade your system to a z-stream version of RHEL AI by running the folllowing command: USD sudo bootc upgrade --apply It is recommended to re-initialize your environment and configurations after you upgrade to the latest RHEL AI version. Warning The ilab config init command overrides your existing config.yaml file and sets it to the default configurations per your system hardware. If you customized the config.yaml file, ensure you are familiar with your custom configurations before re-initializing. USD ilab config init

Commands:
sudo podman login registry.redhat.io --username <user-name> --password <user-password> --authfile /etc/ostree/auth.json
sudo skopeo login registry.redhat.io --username <user-name> --password <user-password> --authfile /etc/ostree/auth.json
sudo bootc switch registry.redhat.io/rhelai1/bootc-<hardware-vendor>-rhel9:<rhel-ai-version>
sudo bootc switch registry.redhat.io/rhelai1/bootc-nvidia-rhel9:1.4
sudo reboot -n
cp /etc/skel/.config/containers/storage.conf <user-home>/.config/containers/storage.con
sudo bootc upgrade --apply
ilab config init
Chapter 1. Understanding image builds 1.1. Builds A build is the process of transforming input parameters into a resulting object. Most often, the process is used to transform input parameters or source code into a runnable image. A BuildConfig object is the definition of the entire build process. Red Hat OpenShift Service on AWS uses Kubernetes by creating containers from build images and pushing them to a container image registry. Build objects share common characteristics including inputs for a build, the requirement to complete a build process, logging the build process, publishing resources from successful builds, and publishing the final status of the build. Builds take advantage of resource restrictions, specifying limitations on resources such as CPU usage, memory usage, and build or pod execution time. The resulting object of a build depends on the builder used to create it. For docker and S2I builds, the resulting objects are runnable images. For custom builds, the resulting objects are whatever the builder image author has specified. Additionally, the pipeline build strategy can be used to implement sophisticated workflows: Continuous integration Continuous deployment 1.1.1. Docker build Red Hat OpenShift Service on AWS uses Buildah to build a container image from a Dockerfile. For more information on building container images with Dockerfiles, see the Dockerfile reference documentation . Tip If you set Docker build arguments by using the buildArgs array, see Understand how ARG and FROM interact in the Dockerfile reference documentation. 1.1.2. Source-to-image build Source-to-image (S2I) is a tool for building reproducible container images. It produces ready-to-run images by injecting application source into a container image and assembling a new image. The new image incorporates the base image, the builder, and built source and is ready to use with the buildah run command. S2I supports incremental builds, which re-use previously downloaded dependencies, previously built artifacts, and so on. 1.1.3. Pipeline build Important The Pipeline build strategy is deprecated in Red Hat OpenShift Service on AWS 4. Equivalent and improved functionality is present in the Red Hat OpenShift Service on AWS Pipelines based on Tekton. Jenkins images on Red Hat OpenShift Service on AWS are fully supported and users should follow Jenkins user documentation for defining their jenkinsfile in a job or store it in a Source Control Management system. The Pipeline build strategy allows developers to define a Jenkins pipeline for use by the Jenkins pipeline plugin. The build can be started, monitored, and managed by Red Hat OpenShift Service on AWS in the same way as any other build type. Pipeline workflows are defined in a jenkinsfile , either embedded directly in the build configuration, or supplied in a Git repository and referenced by the build configuration.

Commands:
Chapter 1. Supported upgrade paths Currently, it is possible to perform an in-place upgrade from RHEL 7 to the following target RHEL 8 minor versions: System configuration Source OS version Target OS version SAP HANA RHEL 7.9 RHEL 8.8 (default) RHEL 8.10 SAP NetWeaver and other SAP Applications RHEL 7.9 RHEL 8.8 RHEL 8.10 (default) SAP HANA is validated by SAP for RHEL minor versions, which are getting package updates for longer than 6 months. Therefore, for the SAP HANA hosts, the upgrade paths include only EUS/E4S releases plus the last minor release for a given major release. Upgrading SAP HANA System describes restrictions and detailed steps for upgrading a SAP HANA system. SAP NetWeaver is validated by SAP for each major RHEL version. The supported in-place upgrade path for this scenario is from RHEL 7.9 to the RHEL 8.x minor version, which is supported by Leapp for non-HANA systems as per the Upgrading from RHEL 7 to RHEL 8 document. Exceptionally for Cloud Providers, the upgrade of SAP NetWaver systems is supported by two latest EUS/E4S releases. Upgrading SAP NetWeaver System describes certain deviations from the default upgrade procedure. For systems on which both SAP HANA and SAP NetWeaver are installed, the SAP HANA restrictions apply. For more information about supported upgrade paths, see Supported in-place upgrade paths for Red Hat Enterprise Linux .

Commands:
Appendix C. Using AMQ Broker with the examples The AMQ Core Protocol JMS examples require a running message broker with a queue named exampleQueue . Use the procedures below to install and start the broker and define the queue. C.1. Installing the broker Follow the instructions in Getting Started with AMQ Broker to install the broker and create a broker instance . Enable anonymous access. The following procedures refer to the location of the broker instance as <broker-instance-dir> . C.2. Starting the broker Procedure Use the artemis run command to start the broker. USD <broker-instance-dir> /bin/artemis run Check the console output for any critical errors logged during startup. The broker logs Server is now live when it is ready. USD example-broker/bin/artemis run __ __ ____ ____ _ /\ | \/ |/ __ \ | _ \ | | / \ | \ / | | | | | |_) |_ __ ___ | | _____ _ __ / /\ \ | |\/| | | | | | _ <| '__/ _ \| |/ / _ \ '__| / ____ \| | | | |__| | | |_) | | | (_) | < __/ | /_/ \_\_| |_|\___\_\ |____/|_| \___/|_|\_\___|_| Red Hat AMQ <version> 2020-06-03 12:12:11,807 INFO [org.apache.activemq.artemis.integration.bootstrap] AMQ101000: Starting ActiveMQ Artemis Server ... 2020-06-03 12:12:12,336 INFO [org.apache.activemq.artemis.core.server] AMQ221007: Server is now live ... C.3. Creating a queue In a new terminal, use the artemis queue command to create a queue named exampleQueue . USD <broker-instance-dir> /bin/artemis queue create --name exampleQueue --address exampleQueue --auto-create-address --anycast You are prompted to answer a series of yes or no questions. Answer N for no to all of them. Once the queue is created, the broker is ready for use with the example programs. C.4. Stopping the broker When you are done running the examples, use the artemis stop command to stop the broker. USD <broker-instance-dir> /bin/artemis stop Revised on 2024-01-22 11:05:17 UTC

Commands:
<broker-instance-dir> /bin/artemis run
example-broker/bin/artemis run __ __ ____ ____ _ /\ | \/ |/ __ \ | _ \ | | / \ | \ / | | | | | |_) |_ __ ___ | | _____ _ __ / /\ \ | |\/| | | | | | _ <| '__/ _ \| |/ / _ \ '__| / ____ \| | | | |__| | | |_) | | | (_) | < __/ | /_/ \_\_| |_|\___\_\ |____/|_| \___/|_|\_\___|_| Red Hat AMQ <version> 2020-06-03 12:12:11,807 INFO [org.apache.activemq.artemis.integration.bootstrap] AMQ101000: Starting ActiveMQ Artemis Server 2020-06-03 12:12:12,336 INFO [org.apache.activemq.artemis.core.server] AMQ221007: Server is now live
<broker-instance-dir> /bin/artemis queue create --name exampleQueue --address exampleQueue --auto-create-address --anycast
<broker-instance-dir> /bin/artemis stop
20.8. Disabling Network Encryption Follow this section to disable network encryption on clients and servers. Procedure 20.13. Disabling I/O encryption Unmount volumes from all clients Run the following command on each client for any volume that should have encryption disabled. Stop encrypted volumes Run the following command on any server to stop volumes that should have encryption disabled. Disable server and client SSL usage Run the following commands for each volume that should have encryption disabled. Start volumes Mount volumes on clients The process for mounting a volume depends on the protocol your client is using. The following command mounts a volume using the native FUSE protocol. Procedure 20.14. Disabling management encryption Unmount volumes from all clients Run the following command on each client for any volume that should have encryption disabled. Stop glusterd on all nodes For Red Hat Enterprise Linux 7 based installations: For Red Hat Enterprise Linux 6 based installations: Important Red Hat Gluster Storage is not supported on Red Hat Enterprise Linux 6 (RHEL 6) from 3.5 Batch Update 1 onwards. See Version Details table in section Red Hat Gluster Storage Software Components and Versions of the Installation Guide Remove the secure-access file Run the following command on all servers and clients to remove the secure-access file. You can just rename the file if you are only disabling encryption temporarily. Start glusterd on all nodes For Red Hat Enterprise Linux 7 based installations: For Red Hat Enterprise Linux 6 based installations: Important Red Hat Gluster Storage is not supported on Red Hat Enterprise Linux 6 (RHEL 6) from 3.5 Batch Update 1 onwards. See Version Details table in section Red Hat Gluster Storage Software Components and Versions of the Installation Guide Mount volumes on clients The process for mounting a volume depends on the protocol your client is using. The following command mounts a volume using the native FUSE protocol. Important If you are permanently disabling network encryption, you can now delete the SSL certificate files. Do not delete these files if you are only disabling encryption temporarily.

Commands:
umount /mountpoint
gluster volume stop volname
gluster volume set volname server.ssl off gluster volume set volname client.ssl off
gluster volume start volname
mount -t glusterfs server1:/testvolume /mnt/glusterfs
umount /mountpoint
systemctl stop glusterd
service glusterd stop
rm -f /var/lib/glusterd/secure-access
systemctl start glusterd
service glusterd start
mount -t glusterfs server1:/testvolume /mnt/glusterfs
20.16.9.8. Multicast tunnel A multicast group may be used to represent a virtual network. Any guest virtual machine whose network devices are within the same multicast group will talk to each other, even if they reside across multiple physical host physical machines. This mode may be used as an unprivileged user. There is no default DNS or DHCP support and no outgoing network access. To provide outgoing network access, one of the guest virtual machines should have a second NIC which is connected to one of the first 4 network types in order to provide appropriate routing. The multicast protocol is compatible with protocols used by user mode linux guest virtual machines as well. Note that the source address used must be from the multicast address block. A multicast tunnel is created by manipulating the interface type using a management tool and setting/changing it to mcast , and providing a mac and source address. The result is shown in changes made to the domain XML: ... <devices> <interface type='mcast'> <mac address='52:54:00:6d:90:01'> <source address='230.0.0.1' port='5558'/> </interface> </devices> ... Figure 20.45. Devices - network interfaces- multicast tunnel

Commands:
<devices> <interface type='mcast'> <mac address='52:54:00:6d:90:01'> <source address='230.0.0.1' port='5558'/> </interface> </devices>
32.7. Post-installation Script You have the option of adding commands to run on the system once the installation is complete. This section must be placed towards the end of the kickstart file, after the kickstart commands described in Section 32.4, "Kickstart Options" , and must start with the %post command and end with the %end command. If your kickstart file also includes a %pre section, the order of the %pre and %post sections does not matter. See Section 32.8, "Kickstart Examples" for example configuration files. This section is useful for functions such as installing additional software and configuring an additional nameserver. Note If you configured the network with static IP information, including a nameserver, you can access the network and resolve IP addresses in the %post section. If you configured the network for DHCP, the /etc/resolv.conf file has not been completed when the installation executes the %post section. You can access the network, but you can not resolve IP addresses. Thus, if you are using DHCP, you must specify IP addresses in the %post section. Note The post-install script is run in a chroot environment; therefore, performing tasks such as copying scripts or RPMs from the installation media do not work. --nochroot Allows you to specify commands that you would like to run outside of the chroot environment. The following example copies the file /etc/resolv.conf to the file system that was just installed. --interpreter /usr/bin/python Allows you to specify a different scripting language, such as Python. Replace /usr/bin/python with the scripting language of your choice. --log /path/to/logfile Logs the output of the post-install script. Note that the path of the log file must take into account whether or not you use the --nochroot option. For example, without --nochroot : with --nochroot :

Commands:
%post --nochroot cp /etc/resolv.conf /mnt/sysimage/etc/resolv.conf
%post --log=/root/ks-post.log
%post --nochroot --log=/mnt/sysimage/root/ks-post.log
Chapter 58. Securing passwords with a keystore You can use a keystore to encrypt passwords that are used for communication between Business Central and KIE Server. You should encrypt both controller and KIE Server passwords. If Business Central and KIE Server are deployed to different application servers, then both application servers should use the keystore. Use Java Cryptography Extension KeyStore (JCEKS) for your keystore because it supports symmetric keys. Use KeyTool, which is part of the JDK installation, to create a new JCEKS. Note If KIE Server is not configured with JCEKS, KIE Server passwords are stored in system properties in plain text form. Prerequisites KIE Server is installed in Oracle WebLogic Server. A KIE Server user with the kie-server role has been created, as described in Section 54.1, "Configuring the KIE Server group and users" . Java 8 or higher is installed. Procedure To use KeyTool to create a JCEKS, enter the following command in the Java 8 home directory: USD<JAVA_HOME>/bin/keytool -importpassword -keystore <KEYSTORE_PATH> -keypass <ALIAS_KEY_PASSWORD> -alias <PASSWORD_ALIAS> -storepass <KEYSTORE_PASSWORD> -storetype JCEKS In this example, replace the following variables: <KEYSTORE_PATH> : The path where the keystore will be stored <KEYSTORE_PASSWORD> : The keystore password <ALIAS_KEY_PASSWORD> : The password used to access values stored with the alias <PASSWORD_ALIAS> : The alias of the entry to the process When prompted, enter the password for the KIE Server user that you created. Set the system properties listed in the following table: Table 58.1. System properties used to load a KIE Server JCEKS System property Placeholder Description kie.keystore.keyStoreURL <KEYSTORE_URL> URL for the JCEKS that you want to use, for example file:///home/kie/keystores/keystore.jceks kie.keystore.keyStorePwd <KEYSTORE_PWD> Password for the JCEKS kie.keystore.key.server.alias <KEY_SERVER_ALIAS> Alias of the key for REST services where the password is stored kie.keystore.key.server.pwd <KEY_SERVER_PWD> Password of the alias for REST services with the stored password kie.keystore.key.ctrl.alias <KEY_CONTROL_ALIAS> Alias of the key for default REST Process Automation Controller where the password is stored kie.keystore.key.ctrl.pwd <KEY_CONTROL_PWD> Password of the alias for default REST Process Automation Controller with the stored password Start KIE Server to verify the configuration.

Commands:
USD<JAVA_HOME>/bin/keytool -importpassword -keystore <KEYSTORE_PATH> -keypass <ALIAS_KEY_PASSWORD> -alias <PASSWORD_ALIAS> -storepass <KEYSTORE_PASSWORD> -storetype JCEKS
Chapter 74. KafkaClientAuthenticationScramSha512 schema reference Used in: KafkaBridgeSpec , KafkaConnectSpec , KafkaMirrorMaker2ClusterSpec , KafkaMirrorMakerConsumerSpec , KafkaMirrorMakerProducerSpec Full list of KafkaClientAuthenticationScramSha512 schema properties To configure SASL-based SCRAM-SHA-512 authentication, set the type property to scram-sha-512 . The SCRAM-SHA-512 authentication mechanism requires a username and password. 74.1. username Specify the username in the username property. 74.2. passwordSecret In the passwordSecret property, specify a link to a Secret containing the password. You can use the secrets created by the User Operator. If required, you can create a text file that contains the password, in cleartext, to use for authentication: echo -n PASSWORD > MY-PASSWORD .txt You can then create a Secret from the text file, setting your own field name (key) for the password: oc create secret generic MY-CONNECT-SECRET-NAME --from-file= MY-PASSWORD-FIELD-NAME =./ MY-PASSWORD .txt Example Secret for SCRAM-SHA-512 client authentication for Kafka Connect apiVersion: v1 kind: Secret metadata: name: my-connect-secret-name type: Opaque data: my-connect-password-field: LFTIyFRFlMmU2N2Tm The secretName property contains the name of the Secret , and the password property contains the name of the key under which the password is stored inside the Secret . Important Do not specify the actual password in the password property. Example SASL-based SCRAM-SHA-512 client authentication configuration for Kafka Connect authentication: type: scram-sha-512 username: my-connect-username passwordSecret: secretName: my-connect-secret-name password: my-connect-password-field 74.3. KafkaClientAuthenticationScramSha512 schema properties Property Description passwordSecret Reference to the Secret which holds the password. PasswordSecretSource type Must be scram-sha-512 . string username Username used for the authentication. string

Commands:
echo -n PASSWORD > MY-PASSWORD .txt
create secret generic MY-CONNECT-SECRET-NAME --from-file= MY-PASSWORD-FIELD-NAME =./ MY-PASSWORD .txt
apiVersion: v1 kind: Secret metadata: name: my-connect-secret-name type: Opaque data: my-connect-password-field: LFTIyFRFlMmU2N2Tm
authentication: type: scram-sha-512 username: my-connect-username passwordSecret: secretName: my-connect-secret-name password: my-connect-password-field
Chapter 78. OpenTelemetryTracing schema reference Used in: KafkaBridgeSpec , KafkaConnectSpec , KafkaMirrorMaker2Spec , KafkaMirrorMakerSpec The type property is a discriminator that distinguishes use of the OpenTelemetryTracing type from JaegerTracing . It must have the value opentelemetry for the type OpenTelemetryTracing . Property Description type Must be opentelemetry . string

Commands:
9.7. Import From Salesforce You can create relational source models from your Salesforce connection using the steps below. Note Depending the detail provided in the database connection URL information and schema, Steps 5 through 7 may not be required. In Model Explorer, right-click and then click Import... or click the File > Import... action in the toolbar or select a project, folder or model in the tree and click Import... Select the import option Teiid Designer > Salesforce >> Source Model and click > Select existing or connection profile from the drop-down selector or click New... button to launch the New Connection Profile dialog or Edit... to modify or change an existing connection profile prior to selection. Note that the Connection Profile selection list will be populated with only Salesforce connection profiles. Figure 9.24. Select Salesforce Credentials Dialog After selecting a Connection Profile, enter the password (if not provided). Click > to display the Salesforce Objects selection page. Figure 9.25. Select Salesforce Objects Dialog On the Target Model Selection page, specify the target folder location for your generated model, a unique model name and select desired import options. You have to enter the JNDI name. Click > (or Finish if enabled). Figure 9.26. Target Model Selection Dialog If you are updating an existing relational model, the page will be Review Model Updates page. Any differences. Click Finish to create your models and tables. Figure 9.27. Review Model Updates Dialog When finished, the new or changed relational model's package diagram will be displayed showing your new tables. Figure 9.28. New Saleforce Tables Diagram

Commands: