mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 13. Managing Ansible content You can import Ansible collections from several sources to Satellite Server. For more information about Ansible integration in Satellite, see Managing configurations by using Ansible integration . 13.1. Synchronizing Ansible Collections On Satellite, you can synchronize your Ansible Collections from Private Automation Hub, console.redhat.com , and other Satellite instances. Ansible Collections will appear on Satellite as a new repository type in the Satellite web UI menu under Content after the sync. Procedure In the Satellite web UI, navigate to Content > Products . Select the required product name. In the Products window, select the name of a product that you want to create a repository for. Click the Repositories tab, and then click New Repository . In the Name field, enter a name for the repository. The Label field is populated automatically based on the name. From the Type list, select ansible collection . In the Upstream URL field, enter the URL for the upstream collections repository. The URL can be any Ansible Galaxy endpoint. For example, https://console.redhat.com/api/automation-hub/ . Optional: In the Requirements.yml field, you can specify the list of collections you want to sync from the endpoint, as well as their versions. If you do not specify the list of collections, everything from the endpoint will be synced. --- collections: - name: my_namespace.my_collection version: 1.2.3 For more information, see Installing roles and collections from the same requirements.yml file in the Galaxy User Guide . Authenticate. To sync Satellite from Private Automation Hub , enter your token in the Auth Token field. For more information, see Connect Private Automation Hub in Connect to Hub . To sync Satellite from console.redhat.com , enter your token in the Auth Token field and enter your SSO URL in the the Auth URL field. For more information, see Getting started with automation hub . To sync Satellite from Satellite, leave both authentication fields blank. Click Save . Navigate to the Ansible Collections repository. From the Select Action menu, select Sync Now .

Commands:
--- collections: - name: my_namespace.my_collection version: 1.2.3
Chapter 9. Red Hat build of Kogito on Red Hat OpenShift Container Platform You can deploy Red Hat build of Kogito microservices on Red Hat OpenShift Container Platform for cloud implementation. In this architecture, Red Hat build of Kogito microservices are deployed as OpenShift pods that you can scale up and down individually to provide as few or as many containers as required for a particular service. To help you deploy your Red Hat build of Kogito microservices on OpenShift, Red Hat Process Automation Manager provides Red Hat Process Automation Manager Kogito Operator . This operator guides you through the deployment process. The operator is based on the Operator SDK and automates many of the deployment steps for you. For example, when you provide the operator with a link to the Git repository that contains your application, the operator automatically configures the components required to build your project from source and deploys the resulting services. To install the Red Hat Process Automation Manager Kogito Operator in OpenShift web console, go to Operators OperatorHub in the left menu, search for and select RHPAM Kogito Operator , and follow the on-screen instructions to install the latest operator version.

Commands:
Chapter 2. Installation This chapter guides you through the steps to install AMQ Spring Boot Starter in your environment. 2.1. Prerequisites You must have a subscription to access AMQ release files and repositories. To build programs with AMQ Spring Boot Starter, you must install Apache Maven . To use AMQ Spring Boot Starter, you must install Java. 2.2. Using the Red Hat Maven repository Configure your Maven environment to download the client library from the Red Hat Maven repository. Procedure Add the Red Hat repository to your Maven settings or POM file. For example configuration files, see Section B.1, "Using the online repository" . <repository> <id>red-hat-ga</id> <url>https://maven.repository.redhat.com/ga</url> </repository> Add the library dependency to your POM file. <dependency> <groupId>org.amqphub.spring</groupId> <artifactId>amqp-10-jms-spring-boot-starter</artifactId> <version>3.1.2.redhat-00001</version> </dependency> The client is now available in your Maven project. 2.3. Installing a local Maven repository As an alternative to the online repository, AMQ Spring Boot Starter can be installed to your local filesystem as a file-based Maven repository. Procedure Use your subscription to download the AMQ Spring Boot Starter 3.1.2 Maven repository .zip file. Extract the file contents into a directory of your choosing. On Linux or UNIX, use the unzip command to extract the file contents. USD unzip amq-spring-boot-starter-3.1.2-maven-repository-maven-repository.zip On Windows, right-click the .zip file and select Extract All . Configure Maven to use the repository in the maven-repository directory inside the extracted install directory. For more information, see Section B.2, "Using a local repository" .

Commands:
<repository> <id>red-hat-ga</id> <url>https://maven.repository.redhat.com/ga</url> </repository>
<dependency> <groupId>org.amqphub.spring</groupId> <artifactId>amqp-10-jms-spring-boot-starter</artifactId> <version>3.1.2.redhat-00001</version> </dependency>
unzip amq-spring-boot-starter-3.1.2-maven-repository-maven-repository.zip
5.22. cdrkit 5.22.1. RHBA-2012:1451 - cdrkit bug fix update Updated cdrkit packages that fix one bug are now available for Red Hat Enterprise Linux 6. The cdrkit packages contain a collection of CD/DVD utilities for generating the ISO9660 file-system and burning media. Bug Fix BZ# 797990 Prior to this update, overlapping memory was handled incorrectly. As a consequence, newly created paths could be garbled when calling "genisoimage" with the "-graft-points" option to graft the paths at points other than the root directory. This update modifies the underlying code to generate graft paths as expected. All users of cdrkit are advised to upgrade to these updated packages, which fix this bug.

Commands:
4.102. isdn4k-utils 4.102.1. RHBA-2011:1169 - isdn4k-utils bug fix update Updated isdn4k-utils packages that fix one bug are now available for Red Hat Enterprise Linux 6. The isdn4k-utils package contains a collection of utilities needed for configuring an ISDN subsystem. Bug Fixes BZ# 618653 Prior to this update, the isdn and capi init scripts were not LSB compatible. Due to this problem, the isdn and capi init scripts exited with incorrect or invalid exit statuses. This update modifies the init scripts so that they are LSB compatible. Now the init scripts exit with the correct exit status. (BZ# 618549 ) All users of isdn4k-utils are advised to upgrade to these updated packages, which fix this bug.

Commands:
Chapter 9. Installing a three-node cluster on VMC In OpenShift Container Platform version 4.13, you can install a three-node cluster on your VMware vSphere instance by deploying it to VMware Cloud (VMC) on AWS . A three-node cluster consists of three control plane machines, which also act as compute machines. This type of cluster provides a smaller, more resource efficient cluster, for cluster administrators and developers to use for testing, development, and production. You can install a three-node cluster using either installer-provisioned or user-provisioned infrastructure. 9.1. Configuring a three-node cluster You configure a three-node cluster by setting the number of worker nodes to 0 in the install-config.yaml file before deploying the cluster. Setting the number of worker nodes to 0 ensures that the control plane machines are schedulable. This allows application workloads to be scheduled to run from the control plane nodes. Note Because application workloads run from control plane nodes, additional subscriptions are required, as the control plane nodes are considered to be compute nodes. Prerequisites You have an existing install-config.yaml file. Procedure Set the number of compute replicas to 0 in your install-config.yaml file, as shown in the following compute stanza: compute: - name: worker platform: {} replicas: 0 If you are deploying a cluster with user-provisioned infrastructure: Configure your application ingress load balancer to route HTTP and HTTPS traffic to the control plane nodes. In a three-node cluster, the Ingress Controller pods run on the control plane nodes. For more information, see the "Load balancing requirements for user-provisioned infrastructure". After you create the Kubernetes manifest files, make sure that the spec.mastersSchedulable parameter is set to true in cluster-scheduler-02-config.yml file. You can locate this file in <installation_directory>/manifests . For more information, see "Creating the Kubernetes manifest and Ignition config files" in "Installing a cluster on VMC with user-provisioned infrastructure". Do not create additional worker nodes. Example cluster-scheduler-02-config.yml file for a three-node cluster apiVersion: config.openshift.io/v1 kind: Scheduler metadata: creationTimestamp: null name: cluster spec: mastersSchedulable: true policy: name: "" status: {} 9.2. steps Installing a cluster on VMC with customizations Installing a cluster on VMC with user-provisioned infrastructure

Commands:
compute: - name: worker platform: {} replicas: 0
apiVersion: config.openshift.io/v1 kind: Scheduler metadata: creationTimestamp: null name: cluster spec: mastersSchedulable: true policy: name: "" status: {}
API overview OpenShift Container Platform 4.12 Overview content for the OpenShift Container Platform API Red Hat OpenShift Documentation Team

Commands:
oc debug node/<node>
chroot /host
systemctl cat kubelet
/etc/systemd/system/kubelet.service.d/20-logging.conf [Service] Environment="KUBELET_LOG_LEVEL=2"
echo -e "[Service]\nEnvironment=\"KUBELET_LOG_LEVEL=8\"" > /etc/systemd/system/kubelet.service.d/30-logging.conf
systemctl daemon-reload
systemctl restart kubelet
rm -f /etc/systemd/system/kubelet.service.d/30-logging.conf
systemctl daemon-reload
systemctl restart kubelet
apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: labels: machineconfiguration.openshift.io/role: master name: 99-master-kubelet-loglevel spec: config: ignition: version: 3.2.0 systemd: units: - name: kubelet.service enabled: true dropins: - name: 30-logging.conf contents: | [Service] Environment="KUBELET_LOG_LEVEL=2"
oc adm node-logs --role master -u kubelet
oc adm node-logs --role worker -u kubelet
journalctl -b -f -u kubelet.service
sudo tail -f /var/log/containers/*
- for n in USD(oc get node --no-headers | awk '{print USD1}'); do oc adm node-logs USDn | gzip > USDn.log.gz; done
Chapter 10. FS-Cache FS-Cache is a persistent local cache that can be used by file systems to take data retrieved from over the network and cache it on local disk. This helps minimize network traffic for users accessing data from a file system mounted over the network (for example, NFS). The following diagram is a high-level illustration of how FS-Cache works: Figure 10.1. FS-Cache Overview FS-Cache is designed to be as transparent as possible to the users and administrators of a system. Unlike cachefs on Solaris, FS-Cache allows a file system on a server to interact directly with a client's local cache without creating an overmounted file system. With NFS, a mount option instructs the client to mount the NFS share with FS-cache enabled. FS-Cache does not alter the basic operation of a file system that works over the network - it merely provides that file system with a persistent place in which it can cache data. For instance, a client can still mount an NFS share whether or not FS-Cache is enabled. In addition, cached NFS can handle files that won't fit into the cache (whether individually or collectively) as files can be partially cached and do not have to be read completely up front. FS-Cache also hides all I/O errors that occur in the cache from the client file system driver. To provide caching services, FS-Cache needs a cache back-end . A cache back-end is a storage driver configured to provide caching services (i.e. cachefiles ). In this case, FS-Cache requires a mounted block-based file system that supports bmap and extended attributes (e.g. ext3) as its cache back-end. FS-Cache cannot arbitrarily cache any file system, whether through the network or otherwise: the shared file system's driver must be altered to allow interaction with FS-Cache, data storage/retrieval, and metadata set up and validation. FS-Cache needs indexing keys and coherency data from the cached file system to support persistence: indexing keys to match file system objects to cache objects, and coherency data to determine whether the cache objects are still valid. Note Starting with Red Hat Enterprise Linux 6.2, cachefilesd is not installed by default and needs to be installed manually. 10.1. Performance Guarantee FS-Cache does not guarantee increased performance, however it ensures consistent performance by avoiding network congestion. Using a cache back-end incurs a performance penalty: for example, cached NFS shares add disk accesses to cross-network lookups. While FS-Cache tries to be as asynchronous as possible, there are synchronous paths (e.g. reads) where this isn't possible. For example, using FS-Cache to cache an NFS share between two computers over an otherwise unladen GigE network will not demonstrate any performance improvements on file access. Rather, NFS requests would be satisfied faster from server memory rather than from local disk. The use of FS-Cache, therefore, is a compromise between various factors. If FS-Cache is being used to cache NFS traffic, for instance, it may slow the client down a little, but massively reduce the network and server loading by satisfying read requests locally without consuming network bandwidth.

Commands:
5.9.4.2. SMB SMB stands for Server Message Block and is the name for the communications protocol used by various operating systems produced by Microsoft over the years. SMB makes it possible to share storage across a network. Present-day implementations often use TCP/IP as the underlying transports; previously NetBEUI was the transport. Red Hat Enterprise Linux supports SMB via the Samba server program. The System Administrators Guide includes information on configuring Samba.

Commands:
5.2.4. Create the bootable media P2V uses bootable media to create a bootable image of the hard drive of a physical machine and send it to the conversion server for import into a hypervisor. You will need a Red Hat subscription to download the rhel-6.x-p2v.iso ISO. Follow the instructions on preparing bootable media from the Red Hat Enterprise Linux Installation Guide . Note that there is only one ISO image for both i386 and x86_64 architectures. The latest release of rhel-6.x-p2v.iso can be found at https://rhn.redhat.com/rhn/channels/PackageList.do?filter_string=virt-p2v&cid=10508 . The ISO file will be installed in /usr/share/virt-p2v/ . Create the appropriate bootable media: The rhel-6.x-p2v.iso file can be used three ways: as a bootable disk, a PXE boot image, and as a bootable USB device. Burn the ISO to a blank CD-ROM or DVD-ROM, and insert it into the disk drive of the physical machine that is to be converted. To boot properly from this boot media, some changes to BIOS settings may be required to ensure that the optical disk drive is first in the boot order. Use the ISO to create a bootable USB media. To boot properly from this boot media, some changes to BIOS settings may be required to ensure that the USB device is first in the boot order. In addition, some BIOSes do not support booting from USB media. The P2V client disk image is approximately 100 MB, so the USB device must be large enough to hold the disk image. Prepare a PXE Boot image for your existing PXE server. To boot from PXE, some changes to BIOS settings may be required to ensure that the PXE boot is first in the boot order. More information about creating boot media can be found in Appendix A, Additional procedures . You have finished preparing and are now ready to move on to converting a physical machine to a virtual machine.

Commands:
7.2. Upgrading an in-service integrated environment Follow the instructions below to upgrade an integrated Red Hat Virtualization and Red Hat Gluster Storage environment that is online and in-service. Upgrade the Red Hat Gluster Storage nodes Perform the following steps for each Red Hat Gluster Storage node, one node at a time. If you have multiple replica sets, upgrade each node in a replica set before moving on to another replica set. Stop all gluster services on the storage node that you want to upgrade by running the following commands as the root user on that node. In the Administration Portal, click Storage Hosts and select the storage node to upgrade. Click Management Maintenance and click OK . Upgrade the storage node using the procedure at Section 5.2, "In-Service Software Upgrade from Red Hat Gluster Storage 3.4 to Red Hat Gluster Storage 3.5" . Reboot the storage node. In the Administration Portal, click Storage Hosts and select the storage node. Click Management Activate . Click the name of the storage node Bricks , and verify that the Self-Heal Info column of all bricks is listed as OK before upgrading the storage node. Upgrade Gluster client software on virtualization hosts After upgrading all storage nodes, update the client software on all virtualization hosts. For Red Hat Virtualization hosts In the Administration Portal, click Compute Hosts and select the node to update. On Red Hat Virtualization versions earlier than 4.2, click Management Maintenance and click OK . Click Installation Upgrade and click OK . The node is automatically updated with the latest packages and reactivated when the update is complete. For Red Hat Enterprise Linux hosts In the Administration Portal, click Compute Hosts and select the node to update. Click Management Maintenance and click OK . Subscribe the host to the correct repositories to receive updates. Update the host. In the Administration Portal, click Management Activate .

Commands:
systemctl stop glusterd pkill glusterfs pkill glusterfsd pgrep gluster
yum update
Chapter 4. JDBC Transactions 4.1. JDBC Transaction Types The JBoss Data Virtualization JDBC API supports three types of transactions from a client perspective: global transactions, local transactions, and request level transactions. All are implemented by JBoss Data Virtualization as XA transactions. Refer to the JTA specification at http://www.oracle.com/technetwork/java/javaee/tech/jta-138684.html for more information on XA Transactions. Warning The use of global, local, and request level transactions are all mutually exclusive. Request level transactions only apply when not in a global or local transaction. Any attempt to mix global and local transactions concurrently will result in an exception.

Commands:
5.358. xfig 5.358.1. RHBA-2012:0985 - xfig bug fix update Updated xfig packages that fix one bug are now available for Red Hat Enterprise Linux 6. The xfig packages contain the Xfig editor. Xfig is an open-source vector graphics editor, which allows you to create simple diagrams and figures. Bug Fix BZ# 806689 Security errata RHSA-2012:0095 changed the way ghostscript handles relative paths. Consequently, as Xfig relied on the original ghostscript behavior, it failed to open encapsulated postscript files and returned the execution stack ending with the following error: Xfig was changed to use absolute paths when executing the ghostscript binary. With this update, Xfig opens encapsulated postscript files and includes them in other figures as expected. Users are advised to upgrade to these updated xfig packages, which fix this bug.

Commands:
Current allocation mode is local Last OS error: 2 GPL Ghostscript 8.70: Unrecoverable error, exit code 1 EPS object read OK, but no preview bitmap found/generated
15.5.4. Local User Options The following lists directives which characterize the way local users access the server. To use these options, the local_enable directive must be set to YES . chmod_enable - When enabled, the FTP command SITE CHMOD is allowed for local users. This command allows the users to change the permissions on files. The default value is YES . chroot_list_enable - When enabled, the local users listed in the file specified in the chroot_list_file directive are placed in a chroot jail upon log in. If enabled in conjunction with the chroot_local_user directive, the local users listed in the file specified in the chroot_list_file directive are not placed in a chroot jail upon log in. The default value is NO . chroot_list_file - Specifies the file containing a list of local users referenced when the chroot_list_enable directive is set to YES . The default value is /etc/vsftpd.chroot_list . chroot_local_user - When enabled, local users are change-rooted to their home directories after logging in. The default value is NO . Warning Enabling chroot_local_user opens up a number of security issues, especially for users with upload privileges. For this reason, it is not recommended. guest_enable - When enabled, all non-anonymous users are logged in as the user guest , which is the local user specified in the guest_username directive. The default value is NO . guest_username - Specifies the username the guest user is mapped to. The default value is ftp . local_root - Specifies the directory vsftpd changes to after a local user logs in. There is no default value for this directive. local_umask - Specifies the umask value for file creation. Note that the default value is in octal form (a numerical system with a base of eight), which includes a "0" prefix. Otherwise the value is treated as a base-10 integer. The default value is 022 . passwd_chroot_enable - When enabled in conjunction with the chroot_local_user directive, vsftpd change-roots local users based on the occurrence of the /./ in the home directory field within /etc/passwd . The default value is NO . user_config_dir - Specifies the path to a directory containing configuration files bearing the name of local system users that contain specific setting for that user. Any directive in the user's configuration file overrides those found in /etc/vsftpd/vsftpd.conf . There is no default value for this directive.

Commands:
Chapter 1. Introduction Red Hat's Trusted Profile Analyzer (RHTPA) is a proactive service that assists in risk management of Open Source Software (OSS) packages and dependencies. The Trusted Profile Analyzer service brings awareness to and remediation of OSS vulnerabilities discovered within the software supply chain. The Red Hat Trusted Profile Analyzer documentation is available here . Items added to the RHTPA 1.2.2 Release Notes: The spog-ui-pod-service pod restarts when launching the Trusted Profile Analyzer console in a web browser

Commands:
Chapter 26. Upgrading MySQL Red Hat is committed to fully supporting the upstream version of MySQL, which is currently included in Red Hat Enterprise Linux, until the end of Maintenance Support 2 Phase, as long as upstream security and bug fixes are available. For overview of Red Hat Enterprise Linux Life Cycle, see https://access.redhat.com/support/policy/updates/errata#Maintenance_Support_2_Phase . More recent versions of MySQL, MySQL 5.6 and MySQL 5.7, are provided as the rh-mysql56 and rh-mysql57 Software Collections. These components are part of Red Hat Software Collections, available for all supported releases of Red Hat Enterprise Linux 6 on AMD64 and Intel 64 architectures. For information on how to get access to Red Hat Software Collections, see the Red Hat Software Collections Release Notes . See the Red Hat Software Collections Product Life Cycle document for information regarding length of support for individual components. Note that you cannot directly migrate from MySQL 5.1 to the currently supported versions. Refer to detailed procedures how to migrate from MySQL 5.1 to MySQL 5.5 , from MySQL 5.5 to MySQL 5.6 , and from MySQL 5.6 to MySQL 5.7 .

Commands: