mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 1. Release Schedule The following table lists the dates of each Red Hat Virtualization 4.3 release: Table 1.1. Red Hat Virtualization release schedule Release Date Red Hat Virtualization 4.3 General Availability (ovirt-4.3.3) 2019-05-08 Red Hat Virtualization 4.3 Batch Update 1 (ovirt-4.3.4) 2019-06-20 Red Hat Virtualization 4.3 Batch Update 2 (ovirt-4.3.5) 2019-08-12 Red Hat Virtualization 4.3 Batch Update 3 (ovirt-4.3.6) 2019-10-10 Red Hat Virtualization 4.3 Batch Update 4 (ovirt-4.3.7) 2019-12-12 Red Hat Virtualization 4.3 Batch Update 5 (ovirt-4.3.8) 2020-02-13 Red Hat Virtualization 4.3 Batch Update 6 (ovirt-4.3.9) 2020-04-02 Red Hat Virtualization 4.3 Batch Update 7 (ovirt-4.3.10) 2020-06-04 Red Hat Virtualization 4.3 Batch Update 8 (ovirt-4.3.11) 2020-09-30 Red Hat Virtualization 4.3 Batch Update 9 (ovirt-4.3.12) 2020-11-17

Commands:
Chapter 7. File Systems gfs2-utils rebase to version 3.1.8 The gfs2-utils package has been rebased to version 3.1.8, which provides important fixes and a number of enhancements: * The performance of the fsck.gfs2 , mkfs.gfs2 , and gfs2_edit utilities has been improved. * The fsck.gfs2 utility now performs better checking of journals, the jindex, system inodes, and the inode 'goal' values. * The gfs2_jadd and gfs2_grow utilities are now separate programs instead of symlinks to mkfs.gfs2 . * The test suite and related documentation have been improved. * The package no longer depends on Perl. GFS2 now prevents users from exceeding their quotas Previously, GFS2 only checked quota violations after the completion of operations, which could result in users or groups exceeding their allotted quotas. This behavior has been fixed, and GFS2 now predicts how many blocks an operation would allocate and checks if allocating them would violate quotas. Operations that would result in quota violations are disallowed, and users thus never exceed their allotted quotas. XFS rebase to version 4.1 XFS has been upgraded to upstream version 4.1 including minor bug fixes, refactorings, reworks of certain internal mechanisms, such as logging, pcpu accounting, and new mmap locking. On top of the upstream changes, this update extends the rename() function to add cross-rename (a symmetric variant of rename()) and whiteout handling. cifs rebase to version 3.17 The CIFS module has been upgraded to upstream version 3.17, which provides various minor fixes and new features for Server Message Block (SMB) 2 and 3: SMB version 2.0, 2.1, 3.0, and 3.0.2. Note that using the Linux kernel CIFS module with SMB protocol 3.1.1 is currently experimental and the functionality is unavailable in kernels provided by Red Hat. In addition, features introduced in SMB version 3.0.2 are defined as optional and are not currently supported by Red Hat Enterprise Linux. Changes in NFS in Red Hat Enterprise Linux 7.2 Fallocate support allows preallocation of files on the server. The SEEK_HOLE and SEEK_DATA extensions to the fseek() function make it possible to locate holes or data quickly and efficiently. Red Hat Enterprise Linux 7.2 also adds support for flexible file layout on NFSv4 clients described in the Technology Previews section.

Commands:
Part II. Configuring Business Central settings and properties As an administrator, you can customize the following on the admin Settings page: Roles : Set the home page, priority, and permissions of a role. Groups : Set the home page, priority, and permissions of a group as well as create and delete groups. Users : Create and delete users, add or remove groups and roles from users, and view user permissions. Artifacts : View M2 repository artifacts, upload artifacts, view, and download JAR files. Data Sources : Add, update, or delete data sources and database drivers. Data Sets : Create, modify, or delete data sets. Projects : View and edit project preferences such as file export properties, space properties, default values, and advanced GAV properties. Artifact Repository : Manage artifact repository properties. Languages : Set the Business Central language. Process Administration : Set the default pagination option in Business Central. Process Designer : Set diagram editor properties. SSH Keys : Add or delete SSH keys. Custom Tasks Administration : Enable or disable default service tasks and upload custom service tasks. Dashbuilder Data Transfer : Import and export Dashbuilder data as ZIP files in Business Central. Profiles : Set the workbench profile as Planner and Rules or Full . Archetypes : View, add, validate, set as default, and delete the archetypes. Used as a template when creating a new project in Business Central. Prerequisites Red Hat JBoss Enterprise Application Platform 7.4.14 is installed. For more information, see Red Hat JBoss Enterprise Application Platform 7.4 Installation Guide . Red Hat Decision Manager is installed and running. For more information, see Installing and configuring Red Hat Decision Manager on Red Hat JBoss EAP 7.4 . You are logged in to Business Central with the admin user role.

Commands:
Chapter 7. Building Dockerfiles Red Hat Quay supports the ability to build Dockerfiles on our build fleet and push the resulting image to the repository. 7.1. Viewing and managing builds Repository Builds can be viewed and managed by clicking the Builds tab in the Repository View . 7.2. Manually starting a build To manually start a repository build, click the + icon in the top right of the header on any repository page and choose New Dockerfile Build . An uploaded Dockerfile , .tar.gz , or an HTTP URL to either can be used for the build. Note You will not be able to specify the Docker build context when manually starting a build. 7.3. Build Triggers Repository builds can also be automatically triggered by events such as a push to an SCM (GitHub, BitBucket or GitLab) or via a call to a webhook . 7.3.1. Creating a new build trigger To setup a build trigger, click the Create Build Trigger button on the Builds view page and follow the instructions of the dialog. You will need to grant Red Hat Quay access to your repositories in order to setup the trigger and your account requires admin access on the SCM repository . 7.3.2. Manually triggering a build trigger To trigger a build trigger manually, click the icon to the build trigger and choose Run Now . 7.3.3. Build Contexts When building an image with Docker, a directory is specified to become the build context. This holds true for both manual builds and build triggers because the builds conducted by Red Hat Quay are no different from running docker build on your own machine. Red Hat Quay build contexts are always the specified subdirectory from the build setup and fallback to the root of the build source if none is specified. When a build is triggered, Red Hat Quay build workers clone the git repository to the worker machine and enter the build context before conducting a build. For builds based on tar archives, build workers extract the archive and enter the build context. For example: Imagine the example above is the directory structure for a GitHub repository called "example". If no subdirectory is specified in the build trigger setup or while manually starting a build, the build will operate in the example directory. If subdir is specified to be the subdirectory in the build trigger setup, only the Dockerfile within it is visible to the build. This means that you cannot use the ADD command in the Dockerfile to add file , because it is outside of the build context. Unlike the Docker Hub, the Dockerfile is part of the build context on Red Hat Quay. Thus, it must not appear in the .dockerignore file.

Commands:
example ├── .git ├── Dockerfile ├── file └── subdir └── Dockerfile
7.50. ethtool 7.50.1. RHBA-2013:0366 - ethtool bug fix and enhancement update Updated ethtool packages that fix multiple bugs and add various enhancements are now available for Red Hat Enterprise Linux 6. The ethtool utility allows the querying and changing of Ethernet adapter settings, such as port speed, auto-negotiation, and device-specific performance options. Note The ethtool packages have been upgraded to upstream version 3.5, which provides a number of bug fixes and enhancements over the version. (BZ#819846) All users of ethtool are advised to upgrade to these updated packages, which fix these bugs and add these enhancements.

Commands:
Chapter 1. Installing the CLI The Skupper CLI provides a method to create both Kubernetes and Podman sites. There are two methods to install the CLI: Section 1.1, "Downloading binaries" Section 1.2, "Using Red Hat packages" 1.1. Downloading binaries Downloading the Skupper CLI binaries is a quick way to get started with Red Hat Service Interconnect. However, consider using Red Hat packages on Linux to receive the latest updates. Procedure Download binary files for Linux, macOS or Windows, choose the latest Version for 1.8 at Software Downloads . For a Mac with Apple silicon, use Rosetta 2 and the Skupper CLI for Mac on x86-64 download. Unzip the downloaded file and place the Skupper executable on your PATH. Verify installation: USD skupper version client version 1.8.2-rh-1 1.2. Using Red Hat packages Installing Red Hat packages on Linux makes sure you receive the latest updates to the Skupper CLI. Prerequisites Make sure your subscription is activated and your system is registered. For more information about using the Customer Portal to activate your Red Hat subscription and register your system for packages, see Chapter 6, Using your subscription . Procedure Use the subscription-manager command to subscribe to the required package repositories. Replace <version> with 1 for the main release stream or 1.4 for the long term support release stream. Note Replacing <version> with 1 installs 1.8 , while 1.8 is the main release stream and changes after further releases. Red Hat Enterprise Linux 8 Red Hat Enterprise Linux 9 Use the yum or dnf command to install the skupper command: Additional information See Examples for the 'Hello world' tutorial. Use man containers.conf to view more information about podman configuration.

Commands:
skupper version client version 1.8.2-rh-1
sudo subscription-manager repos --enable=service-interconnect-_<version>_-for-rhel-8-x86_64-rpms
sudo subscription-manager repos --enable=service-interconnect-_<version>_-for-rhel-9-x86_64-rpms
sudo dnf install skupper-cli
Chapter 44. KIE Server KIE Server is the server where the rules and other artifacts for Red Hat Process Automation Manager are stored and run. KIE Server is a standalone built-in component that can be used to instantiate and execute rules through interfaces available for REST, Java Message Service (JMS), or Java client-side applications, as well as to manage processes, jobs, and Red Hat build of OptaPlanner functionality through solvers. Created as a web deployable WAR file, KIE Server can be deployed on any web container. The current version of KIE Server is included with default extensions for both Red Hat Decision Manager and Red Hat Process Automation Manager. KIE Server has a low footprint with minimal memory consumption and therefore can be deployed easily on a cloud instance. Each instance of this server can open and instantiate multiple containers, which enables you to execute multiple rule services in parallel. KIE Server can be integrated with other application servers, such as Oracle WebLogic Server or IBM WebSphere Application Server, to streamline Red Hat Process Automation Manager application management.

Commands:
27.5. Enabling Console Access for Other Applications To make other applications accessible to console users, a bit more work is required. First of all, console access only works for applications which reside in /sbin/ or /usr/sbin/ , so the application that you wish to run must be there. After verifying that, do the following steps: Create a link from the name of your application, such as our sample foo program, to the /usr/bin/consolehelper application: Create the file /etc/security/console.apps/ foo : Create a PAM configuration file for the foo service in /etc/pam.d/ . An easy way to do this is to start with a copy of the halt service's PAM configuration file, and then modify the file if you want to change the behavior: Now, when /usr/bin/ foo is executed, consolehelper is called, which authenticates the user with the help of /usr/sbin/userhelper . To authenticate the user, consolehelper asks for the user's password if /etc/pam.d/ foo is a copy of /etc/pam.d/halt (otherwise, it does precisely what is specified in /etc/pam.d/ foo ) and then runs /usr/sbin/ foo with root permissions. In the PAM configuration file, an application can be configured to use the pam_timestamp module to remember (or cache) a successful authentication attempt. When an application is started and proper authentication is provided (the root password), a timestamp file is created. By default, a successful authentication is cached for five minutes. During this time, any other application that is configured to use pam_timestamp and run from the same session is automatically authenticated for the user - the user does not have to enter the root password again. This module is included in the pam package. To enable this feature, the PAM configuration file in etc/pam.d/ must include the following lines: The first line that begins with auth should be after any other auth sufficient lines, and the line that begins with session should be after any other session optional lines. If an application configured to use pam_timestamp is successfully authenticated from the Main Menu Button (on the Panel), the icon is displayed in the notification area of the panel if you are running the GNOME or KDE desktop environment. After the authentication expires (the default is five minutes), the icon disappears. The user can select to forget the cached authentication by clicking on the icon and selecting the option to forget authentication.

Commands:
cd /usr/bin ln -s consolehelper foo
touch /etc/security/console.apps/ foo
cp /etc/pam.d/halt /etc/pam.d/foo
auth sufficient /lib/security/pam_timestamp.so session optional /lib/security/pam_timestamp.so
Chapter 2. Red Hat Ansible Automation Platform Architecture As a modular platform, Ansible Automation Platform provides the flexibility to easily integrate components and customize your deployment to best meet your automation requirements. The following section provides a comprehensive architectural example of an Ansible Automation Platform deployment. 2.1. Example Ansible Automation Platform architecture The Red Hat Ansible Automation Platform 2.4 reference architecture provides an example setup of a standard deployment of Ansible Automation Platform using automation mesh on Red Hat Enterprise Linux. The deployment shown takes advantage of the following components to provide a simple, secure and flexible method of handling your automation workloads, a central location for content collections, and automated resolution of IT requests. Automation controller Provides the control plane for automation through its UI, Restful API, RBAC workflows and CI/CD integrations. Automation mesh Is an overlay network that provides the ability to ease the distribution of work across a large and dispersed collection of workers through nodes that establish peer-to-peer connections with each other using existing networks. Private automation hub Provides automation developers the ability to collaborate and publish their own automation content and streamline delivery of Ansible code within their organization. Event-Driven Ansible Provides the event-handling capability needed to automate time-consuming tasks and respond to changing conditions in any IT domain. The architecture for this example consists of the following: A two node automation controller cluster An optional hop node to connect automation controller to execution nodes A two node automation hub cluster A single node Event-Driven Ansible controller cluster A single PostgreSQL database connected to the automation controller, automation hub, and Event-Driven Ansible controller clusters Two execution nodes per automation controller cluster Figure 2.1. Example Ansible Automation Platform 2.4 architecture

Commands:
Chapter 10. Container Images Based on Red Hat Software Collections 3.1 Component Description Supported architectures Application Images rhscl/php-70-rhel7 PHP 7.0 platform for building and running applications (EOL) x86_64 rhscl/perl-526-rhel7 Perl 5.26 platform for building and running applications (EOL) x86_64 Daemon Images rhscl/varnish-5-rhel7 Varnish Cache 5.0 HTTP reverse proxy (EOL) x86_64, s390x, ppc64le Database Images rhscl/mongodb-36-rhel7 MongoDB 3.6 NoSQL database server (EOL) x86_64 rhscl/postgresql-10-rhel7 PostgreSQL 10 SQL database server x86_64, s390x, ppc64le Red Hat Developer Toolset Images rhscl/devtoolset-7-toolchain-rhel7 Red Hat Developer Toolset toolchain (EOL) x86_64, s390x, ppc64le rhscl/devtoolset-7-perftools-rhel7 Red Hat Developer Toolset perftools (EOL) x86_64, s390x, ppc64le Legend: x86_64 - AMD64 and Intel 64 architectures s390x - 64-bit IBM Z ppc64le - IBM POWER, little endian All images are based on components from Red Hat Software Collections. The images are available for Red Hat Enterprise Linux 7 through the Red Hat Container Registry. For detailed information about components provided by Red Hat Software Collections 3.1, see the Red Hat Software Collections 3.1 Release Notes . For more information about the Red Hat Developer Toolset 7.1 components, see the Red Hat Developer Toolset 7 User Guide . For information regarding container images based on Red Hat Software Collections 2, see Using Red Hat Software Collections 2 Container Images . EOL images are no longer supported.

Commands:
Chapter 2. Check your Connectivity Link installation and permissions This guide expects that you have successfully installed Connectivity Link on at least one OpenShift cluster, and that you have the correct user permissions. Prerequisites You completed the Connectivity Link installation steps on one or more clusters, as described in Installing Connectivity Link on OpenShift . You have the kubectl or oc command installed. You have write access to the OpenShift namespaces used in this guide. You have an AWS account with Amazon Route 53 and a DNS zone for the examples in this guide. Google Cloud DNS and Microsoft Azure DNS are also supported. Optional: For rate limiting in a multicluster environment, you have installed Connectivity Link on more than one cluster and have a shared accessible Redis-based datastore. For more details, see Installing Connectivity Link on OpenShift . For Observability, OpenShift user workload monitoring is configured to remote write to a central storage system such as Thanos, as described in Connectivity Link Observability Guide .

Commands:
2.6. Business Metadata Business metadata represents additional information about a piece of data, not necessarily related to its physical storage in the enterprise information system or data access requirements. It can also represent descriptions, business rules, and other additional information about a piece of data. Continuing with our example of the ZIP Code column in the address book database, the following represents business metadata we may know about the ZIP code: The first five characters represent the five ZIP code numbers, the final four represent the ZIP Plus Four digits if available, or 0000 if not The application used to populate this field in the database strictly enforces the integrity of the data format Although the first might seem technical, it does not directly relate to the physical storage of the data. It represents a business rule applied to the contents of the column, not the contents themselves. The second, of course, represents some business information about the way the column was populated. This information, although useful to associate with our definition of the column, does not reflect the physical storage of the data.

Commands:
2.5. Testing the Resource Configuration In the cluster status display shown in Section 2.4, "Creating the Resources and Resource Groups with the pcs Command" , all of the resources are running on node z1.example.com . You can test whether the resource group fails over to node z2.example.com by using the following procedure to put the first node in standby mode, after which the node will no longer be able to host resources. The following command puts node z1.example.com in standby mode. After putting node z1 in standby mode, check the cluster status. Note that the resources should now all be running on z2 . The web site at the defined IP address should still display, without interruption. To remove z1 from standby mode, enter the following command. Note Removing a node from standby mode does not in itself cause the resources to fail back over to that node. This will depend on the resource-stickiness value for the resources. For information on the resource-stickiness meta attribute, see Configuring a Resource to Prefer its Current Node in the Red Hat High Availability Add-On Reference .

Commands:
root@z1 ~]# pcs node standby z1.example.com
pcs status Cluster name: my_cluster Last updated: Wed Jul 31 17:16:17 2013 Last change: Wed Jul 31 17:18:34 2013 via crm_attribute on z1.example.com Stack: corosync Current DC: z2.example.com (2) - partition with quorum Version: 1.1.10-5.el7-9abe687 2 Nodes configured 6 Resources configured Node z1.example.com (1): standby Online: [ z2.example.com ] Full list of resources: myapc (stonith:fence_apc_snmp): Started z1.example.com Resource Group: apachegroup my_lvm (ocf::heartbeat:LVM): Started z2.example.com my_fs (ocf::heartbeat:Filesystem): Started z2.example.com VirtualIP (ocf::heartbeat:IPaddr2): Started z2.example.com Website (ocf::heartbeat:apache): Started z2.example.com
root@z1 ~]# pcs node unstandby z1.example.com
Chapter 2. Enable the RHEL for SAP Applications or RHEL for SAP Solutions subscriptions For running SAP NetWeaver application servers the RHEL for SAP Applications subscription can be used if the RHEL systems don't need to be locked to a specific RHEL 9 minor release. For running SAP HANA or SAP NetWeaver or S/4HANA application servers that should be tied to the same RHEL 9 minor release as SAP HANA, one of the following subscriptions is required to access Update Services for SAP Solutions (E4S) : for the x86_64 platform: Red Hat Enterprise Linux for SAP Solutions for the PowerPC Little Endian ( ppc64le ) platform: Red Hat Enterprise Linux for SAP Solutions for Power, LE 2.1. Detach existing subscriptions (already registered systems only) Perform the following steps if the SAP System was previously registered using another RHEL subscription. Find the serial number of the subscription that the system is currently subscribed to: # subscription-manager list --consumed | \ awk '/Subscription Name:/|| /Serial:/|| /Pool ID:/|| /Service Type:/{print} /Service Level:/{printf ("%s\n\n", USD0)}' Remove the subscription from the system, using the following command. Replace the string <SERIAL> by the serial number shown in the output of the command. # subscription-manager remove --serial=<SERIAL> 2.2. Attach the RHEL for SAP Applications or RHEL for SAP Solutions subscription To attach the RHEL for SAP Applications or RHEL for SAP Solutions subscriptions, perform the following steps: Find the pool id of the subscription: # subscription-manager list --available --matches='RHEL for SAP*' | \ awk '/Subscription Name:/|| /Pool ID:/|| /Service Type:/{print} /Service Level:/{printf ("%s\n\n", USD0)}' Attach the subscription to the system, using the following command. Replace the string <POOL_ID> with the actual pool ID (or one of the pool IDs) shown in the output of the command. # subscription-manager attach --pool=<POOL_ID>

Commands:
subscription-manager list --consumed | awk '/Subscription Name:/|| /Serial:/|| /Pool ID:/|| /Service Type:/{print} /Service Level:/{printf ("%s\n\n", USD0)}'
subscription-manager remove --serial=<SERIAL>
subscription-manager list --available --matches='RHEL for SAP*' | awk '/Subscription Name:/|| /Pool ID:/|| /Service Type:/{print} /Service Level:/{printf ("%s\n\n", USD0)}'
subscription-manager attach --pool=<POOL_ID>