mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 7. Adding additional storage to your instance Some cloud instances do not have enough storage for the RHEL AI end-to-end workflow in the default disk. You can add a directory that holds additional data. 7.1. Adding a data storage directory to your instance By default RHEL AI holds configuration data in the USDHOME directory. You can change this default to a different directory for holding InstructLab data. Prerequisites You have a Red Hat Enterprise Linux AI instance You added an extra storage disk to your instance Procedure You can configure the ILAB_HOME environment variable by writing it to the USDHOME/.bash_profile file by running the following commands: USD echo 'export ILAB_HOME=/mnt' >> USDHOME/.bash_profile You can make that change effective by reloading the USDHOME/.bash_profile file with the following command: USD source USDHOME/.bash_profile You then need to create a containers directory with the following command: USD mkdir /mnt/.config/containers Copy over the storage.conf file to the containers directory with the following command: USD cp /etc/skel/.config/containers/storage.conf /mnt/.config/containers/

Commands:
echo 'export ILAB_HOME=/mnt' >> USDHOME/.bash_profile
source USDHOME/.bash_profile
mkdir /mnt/.config/containers
cp /etc/skel/.config/containers/storage.conf /mnt/.config/containers/
4.80. gpm 4.80.1. RHBA-2011:1092 - gpm bug fix update Updated gpm packages that fix one bug are now available for Red Hat Enterprise Linux 6. The gpm packages contain a program handling mouse services on a system console device. Bug Fix BZ# 684920 Prior to this update, it was not possible to build the gpm packages on the supported platforms if the emacs package was installed. This problem has been resolved with this update and no longer occurs. All users of gpm are advised to upgrade to these updated packages, which fix this bug.

Commands:
Chapter 5. Troubleshooting notification failures The notifications service event log enables Notifications administrators to see when notifications are not working properly. The event log provides a list of all triggered events on the Red Hat Hybrid Cloud Console account, and actions taken (as configured in the associated behavior group) for the past 14 days. In the Action taken column, each event shows the notification method highlighted in green or red to indicate the status of the message transmission. The filterable event log is a useful troubleshooting tool to see a failed notification event and identify potential issues with endpoints. The event log can answer questions related to receipt of emails. By showing the email action for an event as green, the event log enables a Notifications administrator to confirm that emails were sent successfully. Even when notifications are configured properly, individual users on the Hybrid Cloud Console account must configure their user preferences to receive emails. Prerequisites You are logged in to the Hybrid Cloud Console as a user with Notifications administrator or Organization Administrator permissions. Procedure In the Hybrid Cloud Console, navigate to Settings > Notifications > Event Log . Filter the events list by event, application, application bundle, action type, or action status. Select the time frame to show events from today, yesterday, the last seven days, the last 14 days (default), or set a custom range within the last 14 days. Sort the Date and time column in ascending or descending order. Navigate to Settings > Notifications > Configure Events , and verify or change settings by event. Ask users to check their user preferences for receiving email notifications. Even when notifications are configured properly, individual users on the Hybrid Cloud Console account must configure their user preferences to receive emails. Additional resources For more information about network and firewall configuration, see Firewall Configuration for accessing Red Hat Insights / Hybrid Cloud Console Integrations & Notifications . To configure your personal preferences for receiving notifications, see Configuring user preferences for email notifications .

Commands:
Chapter 24. Managing routing endpoints The JMX Navigator view lets you add or delete routing endpoints. Important These changes are not persistent across routing context restarts. 24.1. Adding a routing endpoint Overview When testing a new scenario, you might want to add a new endpoint to a routing context. Procedure To add an endpoint to a routing context: In the JMX Navigator view, under the routing context node, select the Endpoints child to which you want to add an endpoint. Right-click the selected node to open the context menu, and then select Create Endpoint . In the Create Endpoint dialog, enter a URL that defines the new endpoint, for example, file://target/messages/validOrders . Click OK . Right-click the routing context node, and select Refresh . The new destination appears in the JMX Navigator view under the Endpoints node, in a folder that corresponds to the type of endpoint it is, for example, file . Related topics Section 24.2, "Deleting a routing endpoint" 24.2. Deleting a routing endpoint Overview When testing failover scenarios or other scenarios that involve handling failures, it is helpful to be able to remove an endpoint from a routing context. Procedure To delete a routing endpoint: In the JMX Navigator view, select the endpoint you want delete. Right-click the selected endpoint to open the context menu, and then select Delete Endpoint . The tooling deletes the endpoint. To remove the deleted endpoint from the view, right-click the Endpoints node, and select Refresh . The endpoint disappears from the JMX Navigator view. Note To remove the endpoint's node from the Project Explorer view without rerunning the project, you need to explicitly delete it by right-clicking the node and selecting Delete . To remove it from view, refresh the project display. Related topics Section 24.1, "Adding a routing endpoint"

Commands:
20.16.9.7. PCI passthrough A PCI network device (specified by the source element) is directly assigned to the guest virtual machine using generic device passthrough, after first optionally setting the device's MAC address to the configured value, and associating the device with an 802.1Qbh capable switch using an optionally specified virtualport element (see the examples of virtualport given above for type='direct' network devices). Note that - due to limitations in standard single-port PCI ethernet card driver design - only SR-IOV (Single Root I/O Virtualization) virtual function (VF) devices can be assigned in this manner; to assign a standard single-port PCI or PCIe ethernet card to a guest virtual machine, use the traditional hostdev device definition Note that this "intelligent passthrough" of network devices is very similar to the functionality of a standard hostdev device, the difference being that this method allows specifying a MAC address and virtualport for the passed-through device. If these capabilities are not required, if you have a standard single-port PCI, PCIe, or USB network card that does not support SR-IOV (and hence would anyway lose the configured MAC address during reset after being assigned to the guest virtual machine domain), or if you are using a version of libvirt older than 0.9.11, you should use standard hostdev to assign the device to the guest virtual machine instead of interface type='hostdev'/ . ... <devices> <interface type='hostdev'> <driver name='vfio'/> <source> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/> </source> <mac address='52:54:00:6d:90:02'> <virtualport type='802.1Qbh'> <parameters profileid='finance'/> </virtualport> </interface> </devices> ... Figure 20.44. Devices - network interfaces- PCI passthrough

Commands:
<devices> <interface type='hostdev'> <driver name='vfio'/> <source> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/> </source> <mac address='52:54:00:6d:90:02'> <virtualport type='802.1Qbh'> <parameters profileid='finance'/> </virtualport> </interface> </devices>
Chapter 1. Introduction to Automation execution environments Using Ansible content that depends on non-default dependencies can be complicated because the packages must be installed on each node, interact with other software installed on the host system, and be kept in sync. Automation execution environments help simplify this process and can easily be created with Ansible Builder. 1.1. About automation execution environments All automation in Red Hat Ansible Automation Platform runs on container images called automation execution environments. Automation execution environments create a common language for communicating automation dependencies, and offer a standard way to build and distribute the automation environment. An automation execution environment should contain the following: Ansible Core 2.15 or later Python 3.8-3.11 Ansible Runner Ansible content collections and their dependencies System dependencies 1.1.1. Why use automation execution environments? With automation execution environments, Red Hat Ansible Automation Platform has transitioned to a distributed architecture by separating the control plane from the execution plane. Keeping automation execution independent of the control plane results in faster development cycles and improves scalability, reliability, and portability across environments. Red Hat Ansible Automation Platform also includes access to Ansible content tools, making it easy to build and manage automation execution environments. In addition to speed, portability, and flexibility, automation execution environments provide the following benefits: They ensure that automation runs consistently across multiple platforms and make it possible to incorporate system-level dependencies and collection-based content. They give Red Hat Ansible Automation Platform administrators the ability to provide and manage automation environments to meet the needs of different teams. They allow automation to be easily scaled and shared between teams by providing a standard way of building and distributing the automation environment. They enable automation teams to define, build, and update their automation environments themselves. Automation execution environments provide a common language to communicate automation dependencies.

Commands:
5.6. Configure CXF for a Web Service Data Source: SSL Support (HTTPS) For using HTTPS, you can configure the CXF configuration file as below: For more information about http-conduit based configuration see http://cxf.apache.org/docs/client-http-transport-including-ssl-support.html . You can also configure for services such as HTTPBasic and Kerberos.

Commands:
<beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:sec="http://cxf.apache.org/configuration/security" xmlns:http-conf="http://cxf.apache.org/transports/http/configuration" xmlns:jaxws="http://java.sun.com/xml/ns/jaxws" xsi:schemaLocation="http://cxf.apache.org/transports/http/configuration http://cxf.apache.org/schemas/configuration/http-conf.xsd http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd http://cxf.apache.org/configuration/security http://cxf.apache.org/schemas/configuration/security.xsd"> <http-conf:conduit name="*.http-conduit"> <http-conf:client ConnectionTimeout="120000" ReceiveTimeout="240000"/> <http-conf:tlsClientParameters secureSocketProtocol="SSL"> <sec:trustManagers> <sec:keyStore type="JKS" password="changeit" file="/path/to/truststore.jks"/> </sec:trustManagers> </http-conf:tlsClientParameters> </http-conf:conduit> </beans>
4.78. gnome-terminal 4.78.1. RHBA-2011:1172 - gnome-terminal bug fix update An updated gnome-terminal package that fixes one bug is now available for Red Hat Enterprise Linux 6. The gnome-terminal package contains a terminal emulator for GNOME. It supports translucent backgrounds, opening multiple terminals in a single window (tabs) and clickable URLs. Bug Fix BZ# 655132 Previously, the regular expression used to find URLs in the text was missing a colon character. As a consequence, the URL containing a colon was not interpreted correctly. With this update, a colon character has been added to the regular expression so that the URL is now properly interpreted. All gnome-terminal users are advised to upgrade to this updated package, which fixes this bug.

Commands:
Getting started with automation hub Red Hat Ansible Automation Platform 2.4 Configure Red Hat automation hub as your default server for Ansible collections content Red Hat Customer Content Services saas-docs@redhat.com

Commands:
curl https://sso.redhat.com/auth/realms/redhat-external/protocol/openid-connect/token -d grant_type=refresh_token -d client_id="cloud-services" -d refresh_token="{{ user_token }}" --fail --silent --show-error --output /dev/null
[galaxy_server._<server_name>_]
https:// <server_fully_qualified_domain_name> /api/galaxy/
[galaxy] server_list = automation_hub, my_org_hub [galaxy_server.automation_hub] url=https://console.redhat.com/api/automation-hub/content/published/ 1 auth_url=https://sso.redhat.com/auth/realms/redhat-external/protocol/openid-connect/token token=my_ah_token [galaxy_server.my_org_hub] url=https://automation.my_org/api/galaxy/content/rh-certified/ 2 username=my_user password=my_pass
cd ansible-automation-platform-setup-bundle-<latest-version>
cd ansible-automation-platform-setup-<latest-version>
[all:vars] automationhub_enable_unauthenticated_collection_access = True 1 automationhub_enable_unauthenticated_collection_download = True 2
ansible-galaxy collection publish path/to/my_namespace-my_collection-1.0.0.tar.gz --api-key=SECRET
3.4. Setting up an IdM Client Through Kickstart A Kickstart enrollment automatically adds a new system to the IdM domain at the time Red Hat Enterprise Linux is installed. For details on Kickstart, see Kickstart Installations in the Installation Guide . Preparing for a Kickstart client installation includes these steps: Section 3.4.1, "Pre-creating a Client Host Entry on the IdM Server" Section 3.4.2, "Creating a Kickstart File for the Client" 3.4.1. Pre-creating a Client Host Entry on the IdM Server Log in as admin: Create the host entry on the IdM server, and set a temporary password for the entry: The password is used by Kickstart to authenticate during the client installation and expires after the first authentication attempt. After the client is successfully installed, it authenticates using its keytab. 3.4.2. Creating a Kickstart File for the Client A Kickstart file used to set up an IdM client must include the following: The ipa-client package in the list of packages to be installed: See Package Selection in the Installation Guide for details. Post-installation instructions that: ensure SSH keys are generated before enrollment runs the ipa-client-install utility, specifying: all required information to access and configure the IdM domain services the password which you set when pre-creating the client host on the IdM server, in Section 3.4.1, "Pre-creating a Client Host Entry on the IdM Server" For example: For a non-interactive installation, add also the --unattended option. To let the client installation script request a certificate for the machine: Add the --request-cert option to ipa-client-install . Set the system bus address to /dev/null for both the getcert and ipa-client-install utility in the kickstart chroot environment. To do this, add these lines to the post-installation instruction file before the ipa-client-install instruction: Note Red Hat recommends not to start the sshd service prior to the kickstart enrollment. While starting sshd before enrolling the client generates the SSH keys automatically, using the above script is the preferred solution. See Post-installation Script in the Installation Guide for details. For details on using Kickstart, see How Do You Perform a Kickstart Installation? in the Installation Guide . For examples of Kickstart files, see Sample Kickstart Configurations .

Commands:
kinit admin
ipa host-add client.example.com --password= secret
%packages @ X Window System @ Desktop @ Sound and Video ipa-client
%post --log=/root/ks-post.log Generate SSH keys to ensure that ipa-client-install uploads them to the IdM server /usr/sbin/sshd-keygen Run the client install script /usr/sbin/ipa-client-install --hostname= client.example.com --domain= EXAMPLE.COM --enable-dns-updates --mkhomedir -w secret --realm= EXAMPLE.COM --server= server.example.com
env DBUS_SYSTEM_BUS_ADDRESS=unix:path=/dev/null getcert list env DBUS_SYSTEM_BUS_ADDRESS=unix:path=/dev/null ipa-client-install
13.2.30. Using NSCD with SSSD SSSD is not designed to be used with the NSCD daemon. Even though SSSD does not directly conflict with NSCD, using both services can result in unexpected behavior, especially with how long entries are cached. The most common evidence of a problem is conflicts with NFS. When using Network Manager to manage network connections, it may take several minutes for the network interface to come up. During this time, various services attempt to start. If these services start before the network is up and the DNS servers are available, these services fail to identify the forward or reverse DNS entries they need. These services will read an incorrect or possibly empty resolv.conf file. This file is typically only read once, and so any changes made to this file are not automatically applied. This can cause NFS locking to fail on the machine where the NSCD service is running, unless that service is manually restarted. To avoid this problem, enable caching for hosts and services in the /etc/nscd.conf file and rely on the SSSD cache for the passwd , group , and netgroup entries. Change the /etc/nscd.conf file: With NSCD answering hosts requests, these entries will be cached by NSCD and returned by NSCD during the boot process. All other entries are handled by SSSD.

Commands:
enable-cache hosts yes enable-cache passwd no enable-cache group no enable-cache netgroup no
Chapter 2. Nagios Core installation and configuration As a storage administrator, you can install Nagios Core by downloading the Nagios Core source code; then, configuring, making, and installing it on the node that will run the Nagios Core instance. 2.1. Installing and configuring the Nagios Core server from source There is not a Red Hat Enterprise Linux package for the Nagios Core software, so the Nagios Core software must be compiled from source. Prerequisites Internet access. Root-level access to the Nagios Core host. Procedure Install the prerequisites: Example If you are using a firewall, open port 80 for httpd : Example Create a user and group for Nagios Core: Example Download the latest version of Nagios Core and Plug-ins: Example Run ./configure : Example Compile the Nagios Core source code: Example Install Nagios source code: Example Copy the event handlers and change their ownership: Example Run the pre-flight check: Example Make and install the Nagios Core plug-ins: Example Create a user for the Nagios Core user interface: Example Important If adding a user other than nagiosadmin , ensure the /usr/local/nagios/etc/cgi.cfg file gets updated with the user name too. Modify the /usr/local/nagios/etc/objects/contacts.cfg file with the user name, full name, and email address as needed. 2.2. Starting the Nagios Core service Start the Nagios Core service to monitor the Red Hat Ceph Storage cluster health. Prerequisites Root-level access to the Nagios Core host. Procedure Add Nagios Core and Apache as a service: Example Start the Nagios Core daemon and Apache: Example 2.3. Logging into the Nagios Core server Log in to the Nagios Core server to view the health status of the Red Hat Ceph Storage cluster. Prerequisites User name and password for the Nagios dashboard. Procedure With Nagios up and running, log in to the dashboard using the credentials of the default Nagios Core user: Syntax Replace IP_ADDRESS with the IP address of your Nagios Core server.

Commands:
dnf install -y httpd php php-cli gcc glibc glibc-common gd gd-devel net-snmp openssl openssl-devel wget unzip make
firewall-cmd --zone=public --add-port=80/tcp firewall-cmd --zone=public --add-port=80/tcp --permanent
useradd nagios passwd nagios groupadd nagcmd usermod -a -G nagcmd nagios usermod -a -G nagcmd apache
wget --inet4-only https://assets.nagios.com/downloads/nagioscore/releases/nagios-4.4.5.tar.gz wget --inet4-only http://www.nagios-plugins.org/download/nagios-plugins-2.3.3.tar.gz tar zxf nagios-4.4.5.tar.gz tar zxf nagios-plugins-2.3.3.tar.gz cd nagios-4.4.5
./configure --with-command-group=nagcmd
make all
make install make install-init make install-config make install-commandmode make install-webconf
cp -R contrib/eventhandlers/ /usr/local/nagios/libexec/ chown -R nagios:nagios /usr/local/nagios/libexec/eventhandlers
/usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
cd ../nagios-plugins-2.3.3 ./configure --with-nagios-user=nagios --with-nagios-group=nagios make make install
htpasswd -c /usr/local/nagios/etc/htpasswd.users nagiosadmin
systemctl enable nagios systemctl enable httpd
systemctl start nagios systemctl start httpd
http:// IP_ADDRESS /nagios
Chapter 52. Boon DataFormat Available as of Camel version 2.16 Boon is a Data Format which uses the Boon JSON marshalling library to unmarshal an JSON payload into Java objects or to marshal Java objects into an JSON payload. Boon aims to be a simple and fast parser than other common parsers currently used. 52.1. Options The Boon dataformat supports 3 options, which are listed below. Name Default Java Type Description unmarshalTypeName String Class name of the java type to use when unarmshalling useList false Boolean To unarmshal to a List of Map or a List of Pojo. contentTypeHeader false Boolean Whether the data format should set the Content-Type header with the type from the data format if the data format is capable of doing so. For example application/xml for data formats marshalling to XML, or application/json for data formats marshalling to JSon etc. 52.2. Spring Boot Auto-Configuration The component supports 4 options, which are listed below. Name Description Default Type camel.dataformat.boon.content-type-header Whether the data format should set the Content-Type header with the type from the data format if the data format is capable of doing so. For example application/xml for data formats marshalling to XML, or application/json for data formats marshalling to JSon etc. false Boolean camel.dataformat.boon.enabled Enable boon dataformat true Boolean camel.dataformat.boon.unmarshal-type-name Class name of the java type to use when unarmshalling String camel.dataformat.boon.use-list To unarmshal to a List of Map or a List of Pojo. false Boolean ND 52.3. Using the Java DSL DataFormat boonDataFormat = new BoonDataFormat("com.acme.model.Person"); from("activemq:My.Queue") .unmarshal(boonDataFormat) .to("mqseries:Another.Queue"); 52.4. Using Blueprint XML <bean id="boonDataFormat" class="org.apache.camel.component.boon.BoonDataFormat"> <argument value="com.acme.model.Person"/> </bean> <camelContext id="camel" xmlns="http://camel.apache.org/schema/blueprint"> <route> <from uri="activemq:My.Queue"/> <unmarshal ref="boonDataFormat"/> <to uri="mqseries:Another.Queue"/> </route> </camelContext> 52.5. Dependencies <dependency> <groupId>org.apache.camel</groupId> <artifactId>camel-boon</artifactId> <version>x.x.x</version> </dependency>

Commands:
DataFormat boonDataFormat = new BoonDataFormat("com.acme.model.Person"); from("activemq:My.Queue") .unmarshal(boonDataFormat) .to("mqseries:Another.Queue");
<bean id="boonDataFormat" class="org.apache.camel.component.boon.BoonDataFormat"> <argument value="com.acme.model.Person"/> </bean> <camelContext id="camel" xmlns="http://camel.apache.org/schema/blueprint"> <route> <from uri="activemq:My.Queue"/> <unmarshal ref="boonDataFormat"/> <to uri="mqseries:Another.Queue"/> </route> </camelContext>
<dependency> <groupId>org.apache.camel</groupId> <artifactId>camel-boon</artifactId> <version>x.x.x</version> </dependency>