mtpti5iD/redhat-docs_dataset huggingface dataset:
1.8.3.2. Direct Routing Direct routing provides increased performance benefits compared to NAT routing. Direct routing allows the real servers to process and route packets directly to a requesting user rather than passing outgoing packets through the LVS router. Direct routing reduces the possibility of network performance issues by relegating the job of the LVS router to processing incoming packets only. Figure 1.24. LVS Implemented with Direct Routing In a typical direct-routing LVS configuration, an LVS router receives incoming server requests through a virtual IP (VIP) and uses a scheduling algorithm to route the request to real servers. Each real server processes requests and sends responses directly to clients, bypassing the LVS routers. Direct routing allows for scalability in that real servers can be added without the added burden on the LVS router to route outgoing packets from the real server to the client, which can become a bottleneck under heavy network load. While there are many advantages to using direct routing in LVS, there are limitations. The most common issue with direct routing and LVS is with Address Resolution Protocol ( ARP ). In typical situations, a client on the Internet sends a request to an IP address. Network routers typically send requests to their destination by relating IP addresses to a machine's MAC address with ARP. ARP requests are broadcast to all connected machines on a network, and the machine with the correct IP/MAC address combination receives the packet. The IP/MAC associations are stored in an ARP cache, which is cleared periodically (usually every 15 minutes) and refilled with IP/MAC associations. The issue with ARP requests in a direct-routing LVS configuration is that because a client request to an IP address must be associated with a MAC address for the request to be handled, the virtual IP address of the LVS router must also be associated to a MAC. However, because both the LVS router and the real servers have the same VIP, the ARP request is broadcast to all the nodes associated with the VIP. This can cause several problems, such as the VIP being associated directly to one of the real servers and processing requests directly, bypassing the LVS router completely and defeating the purpose of the LVS configuration. Using an LVS router with a powerful CPU that can respond quickly to client requests does not necessarily remedy this issue. If the LVS router is under heavy load, it may respond to the ARP request more slowly than an underutilized real server, which responds more quickly and is assigned the VIP in the ARP cache of the requesting client. To solve this issue, the incoming requests should only associate the VIP to the LVS router, which will properly process the requests and send them to the real server pool. This can be done by using the arptables packet-filtering tool.

Commands:
9.4. Synchronous/Asynchronous Invalidation In Red Hat JBoss Data Grid's Library mode, invalidation operates either asynchronously or synchronously. Synchronous invalidation blocks the thread until all caches in the cluster have received invalidation messages and evicted the obsolete data. Asynchronous invalidation operates in a fire-and-forget mode that allows invalidation messages to be broadcast without blocking a thread to wait for responses. Report a bug

Commands:
3.4.5. Deleting Users If you want to remove a user account from the system, use the userdel command on the command line as root . Combining userdel with the -r option removes files in the user's home directory along with the home directory itself and the user's mail spool. Files located in other file systems have to be searched for and deleted manually. Note The -r option is relatively safer, and thus recommended, compared to -f which forces the removal of the user account even if the user is still logged in.

Commands:
userdel username
userdel -r username
Chapter 3. Tasks 3.1. Register Repository on New Server 3.1.1. Register Repository on a New Server You can register a repository on a new server through the ModeShape view. Open ModeShape View To open the ModeShape view navigate to Window -> Show View -> Other. From the Show View dialog, select the ModeShape folder followed by the ModeShape view and click Open . Figure 3.1. Selecting the ModeShape view Add ModeShape Repository To add a ModeShape repository, click the Create a new server icon that appears in the ModeShape view. This view is located in the lower section of your interface, along with other views such as Servers and Console. Figure 3.2. Adding a new server for ModeShape repositories The New Server dialog will appear. Enter the URL of the server to connect and your authentication information in the New Server dialog. You can test your connection to the server by clicking the Test button. Figure 3.3. The New Server dialog Click the Finish button to add the server to the ModeShape view. Note Upon testing the connection, if a connection cannot be established, the ModeShape server can still be created. Use the Reconnect button on the ModeShape View's toolbar to try and connect again at a later time. Result Once the server with the ModeShape repository has been added three new options become available within the ModeShape view. 3.1.2. ModeShape Repository Options After the repository is added to the new server as described in Section 3.1.1, "Register Repository on a New Server" , three new options appear within the ModeShape view. These options allow you to: edit server properties, delete a server from the server registry, and reconnect to the selected server. To perform one of these actions either right-click on a server and select from the presented menu of actions, or use the buttons beside the Create a new server icon. Note It is possible for a ModeShape server instance to have numerous ModeShape repositories stored on it. Once you have registered a connection to the server you will have access to all ModeShape repositories on the server. You do not need to register a new connection for each repository on the same server.

Commands:
Chapter 14. Setting Time and Date in Red Hat Enterprise Linux The section contains how to set time and date in Red Hat Enterprise Linux: The system time is always kept in Coordinated Universal Time (UTC) and converted in applications to local time as needed. Local time is the actual time in your current time zone, taking into account daylight saving time (DST). The timedatectl utility is distributed as part of the systemd system and service manager and allows you to review and change the configuration of the system clock. To change the current time: Replace HH with an hour, MM with a minute, and SS with a second, all typed in two-digit form. To change the current date: Replace YYYY with a four-digit year, MM with a two-digit month, and DD with a two-digit day of the month. To set the time zone: First, display the list of available time zones: Based on the above list, set your desired time zone with this command: The time change is audited by the operating system. For more information see 13.2.1.3 Auditing Time Change Events in the Planning, Installation and Deployment Guide (Common Criteria Edition) .

Commands:
timedatectl set-time HH:MM:SS
timedatectl set-time YYYY-MM-DD
timedatectl list-timezones
timedatectl set-timezone <your_preferred_timezone>
Chapter 5. Using the Tekton plugin You can use the Tekton plugin to visualize the results of CI/CD pipeline runs on your Kubernetes or OpenShift clusters. The plugin allows users to visually see high level status of all associated tasks in the pipeline for their applications. You can use the Tekton front-end plugin to view PipelineRun resources. Prerequisites You have installed the Red Hat Developer Hub (RHDH). You have installed the Tekton plugin. For the installation process, see Installing and configuring the Tekton plugin . Procedure Open your RHDH application and select a component from the Catalog page. Go to the CI tab. The CI tab displays the list of PipelineRun resources associated with a Kubernetes cluster. The list contains pipeline run details, such as NAME , VULNERABILITIES , STATUS , TASK STATUS , STARTED , and DURATION . Click the expand row button besides PipelineRun name in the list to view the PipelineRun visualization. The pipeline run resource includes tasks to complete. When you hover the mouse pointer on a task card, you can view the steps to complete that particular task.

Commands:
A.5. Test Your HAProxy Configuration On your HAProxy nodes, check to ensure the virtual IP address from your keepalived configuration appears. On your calamari node, see if you can reach the gateway nodes by means of the load balancer configuration. For example: This should return the same result as: If it returns an index.html file with the following contents then your configuration is working properly.

Commands:
ip addr show
wget haproxy
wget rgw1
<?xml version="1.0" encoding="UTF-8"?> <ListAllMyBucketsResult xmlns="http://s3.amazonaws.com/doc/2006-03-01/"> <Owner> <ID>anonymous</ID> <DisplayName></DisplayName> </Owner> <Buckets> </Buckets> </ListAllMyBucketsResult>
Chapter 2. Setting up automation mesh Configure the Ansible Automation Platform installer to set up automation mesh for your Ansible environment. Perform additional tasks to customize your installation, such as importing a Certificate Authority (CA) certificate. 2.1. automation mesh Installation You use the Ansible Automation Platform installation program to set up automation mesh or to upgrade to automation mesh. To provide Ansible Automation Platform with details about the nodes, groups, and peer relationships in your mesh network, you define them in an the inventory file in the installer bundle. Additional Resources Red Hat Ansible Automation Platform Installation Guide Automation Mesh Design Patterns 2.2. Importing a Certificate Authority (CA) certificate A Certificate Authority (CA) verifies and signs individual node certificates in an automation mesh environment. You can provide your own CA by specifying the path to the certificate and the private RSA key file in the inventory file of your Red Hat Ansible Automation Platform installer. Note The Ansible Automation Platform installation program generates a CA if you do not provide one. Procedure Open the inventory file for editing. Add the mesh_ca_keyfile variable and specify the full path to the private RSA key ( .key ). Add the mesh_ca_certfile variable and specify the full path to the CA certificate file ( .crt ). Save the changes to the inventory file. Example With the CA files added to the inventory file, run the installation program to apply the CA. This process copies the CA to the to /etc/receptor/tls/ca/ directory on each control and execution node on your mesh network. Additional resources Red Hat Ansible Automation Platform System Requirements

Commands:
[all:vars] mesh_ca_keyfile=/tmp/ <mesh_CA> .key mesh_ca_certfile=/tmp/ <mesh_CA> .crt
3.12. Example: Create Virtual Machine NIC The following example creates a virtual network interface to connect the example virtual machine to the ovirtmgmt network. Example 3.14. Create a virtual machine NIC Request: cURL command:

Commands:
POST /ovirt-engine/api/vms/6efc0cfa-8495-4a96-93e5-ee490328cf48/nics HTTP/1.1 Accept: application/xml Content-type: application/xml <nic> <interface>virtio</interface> <name>nic1</name> <network> <name>ovirtmgmt</name> </network> </nic>
curl -X POST -H "Accept: application/xml" -H "Content-Type: application/xml" -u [USER:PASS] --cacert [CERT] -d "<nic><name>nic1</name><network><name>ovirtmgmt</name></network></nic>" https:// [RHEVM Host] :443/ovirt-engine/api/vms/6efc0cfa-8495-4a96-93e5-ee490328cf48/nics
Chapter 110. Checking DNS records using IdM Healthcheck You can identify issues with DNS records in Identity Management (IdM) using the Healthcheck tool. Prerequisites The DNS records Healthcheck tool is only available on RHEL 8.2 or newer. 110.1. DNS records healthcheck test The Healthcheck tool includes a test for checking that the expected DNS records required for autodiscovery are resolvable. To list all tests, run the ipa-healthcheck with the --list-sources option: You can find the DNS records check test under the ipahealthcheck.ipa.idns source. IPADNSSystemRecordsCheck This test checks the DNS records from the ipa dns-update-system-records --dry-run command using the first resolver specified in the /etc/resolv.conf file. The records are tested on the IPA server. 110.2. Screening DNS records using the healthcheck tool Follow this procedure to run a standalone manual test of DNS records on an Identity Management (IdM) server using the Healthcheck tool. The Healthcheck tool includes many tests. Results can be narrowed down by including only the DNS records tests by adding the --source ipahealthcheck.ipa.idns option. Prerequisites You must perform Healthcheck tests as the root user. Procedure To run the DNS records check, enter: If the record is resolvable, the test returns SUCCESS as a result: The test returns a WARNING when, for example, the number of records does not match the expected number: Additional resources See man ipa-healthcheck .

Commands:
ipa-healthcheck --list-sources
ipa-healthcheck --source ipahealthcheck.ipa.idns
{ "source": "ipahealthcheck.ipa.idns", "check": "IPADNSSystemRecordsCheck", "result": "SUCCESS", "uuid": "eb7a3b68-f6b2-4631-af01-798cac0eb018", "when": "20200415143339Z", "duration": "0.210471", "kw": { "key": "_ldap._tcp.idm.example.com.:server1.idm.example.com." } }
{ "source": "ipahealthcheck.ipa.idns", "check": "IPADNSSystemRecordsCheck", "result": "WARNING", "uuid": "972b7782-1616-48e0-bd5c-49a80c257895", "when": "20200409100614Z", "duration": "0.203049", "kw": { "msg": "Got {count} ipa-ca A records, expected {expected}", "count": 2, "expected": 1 } }
27.2. iSCSI Initiator Creation An iSCSI initiator is the client who wishes to access the storage on a target, or server. The IP address of the target needs to be known for this process. Procedure 27.2. Create an iSCSI Initiator Install iscsi-initiator-utils . Discover the target. Use the target's IP address, the one used below serves only as an example. The above shows the target's IP address and IQN address. It is the IQN address that is needed for future steps. Connect to the target. Find the iSCSI disk name. Create a file system on that disk. Mount the file system. Make it persistent across reboots by editing the /etc/fstab file.

Commands:
~]# yum install iscsi-initiator-utils
~]# iscsiadm -m discovery -t sendtargets -p 192.168.1.1 Starting iscsid: [ OK ] 192.168.1.1:3260,1 iqn.2015-06.com.example.test:target1
~]# iscsiadm -m node -T iqn.2015-06.com.example:target1 --login Logging in to [iface: default, target: iqn.2015-06.com.example:target1, portal: 192.168.1.1,3260] (multiple) Login in to [iface: default, target: iqn.2015-06.com.example:target1, portal: 192.168.1.1,3260] successful.
~]# grep "Attached SCSI" /var/log/messages Jun 19 01:30:26 test kernel: sd 7:0:0:1 [sdb] Attached SCSI disk
~]# mkfs.ext4 /dev/sdb
~]# mkdir /mnt/iscsiTest ~]# mount /dev/sdb /mnt/iscsiTest
~]# blkid /dev/sdb /dev/sdb: UUID="766a3bf4-beeb-4157-8a9a-9007be1b9e78" TYPE="ext4" ~]# vim /etc/fstab UUID=766a3bf4-beeb-4157-8a9a-9007be1b9e78 /mnt/iscsiTest ext4 _netdev 0 0
Chapter 4. Bug fixes This section describes bug fixes available in Red Hat Trusted Application Pipeline 1.4. The KUBECONFIG environment variable is now supported The RHTAP installer now supports reading the kubeconfig files provided in the KUBECONFIG environment variable. This allows you to use KUBECONFIG to specify a kubeconfig file that should be used when you access the OpenShift cluster. To learn more about the KUBECONFIG variable, refer to the Kubernetes docs on kubeconfig files . RHTAP now automatically finds the Rekor and TUF services when running Jenkins pipelines Previously, when you used Jenkins as a CI provider, and your Jenkins instance ran outside the RHTAP cluster, RHTAP couldn't detect the correct Rekor and TUF URLs and reach these services. As a result, cosign was unable to sign container images, and Jenkins pipelines could fail. To work around this issue, you needed to manually hardcode the external routes for Rekor and TUF in the rhtap/env.sh file. With this release, updating the rhtap/env.sh file is no longer required. If you prefer, you can still manually hardcode the Rekor and TUF URLs by following instructions in Customizing sample software templates for Jenkins . However, a second option is now available: you can choose to set the REKOR_HOST and TUF_MIRROR environment variables during Jenkins configuration as described in the Configuring Jenkins guide. This will allow Jenkins to reach external Rekor and TUF services. Note Setting the REKOR_HOST and TUF_MIRROR CI/CD variables is also supported for GitLab CI and GitHub Actions. For instructions, refer to a corresponding guide: Configuring GitLab CI Configuring GitHub Actions The Vulnerabilities tab in RHTPA no longer shows an error Previously, when RHTAP uploaded the SBOM to Red Hat Trusted Profile Analyzer, RHTPA accepted the SBOM but could show Internal server error in the Vulnerabilities tab. The issue is resolved in this release.

Commands:
Chapter 7. Scaling hyperconverged nodes To scale HCI nodes up or down, the same principles and methods for scaling Compute or Ceph Storage nodes apply. 7.1. Scaling Up To scale up hyperconverged nodes in HCI environments follow the same procedure for scaling up non-hyperconverged nodes, as detailed in Adding nodes to the overcloud . Note When you tag new nodes, remember to use the right flavor. For information about how to scale up HCI nodes by adding OSDs to a Ceph Storage cluster, see Adding an OSD to a Ceph Storage node in Deploying an Overcloud with Containerized Red Hat Ceph . 7.2. Scaling Down Procedure Disable and rebalance the Ceph OSD services on the HCI node. This step is necessary because the director does not automatically rebalance the Red Hat Ceph Storage cluster when you remove HCI or Ceph Storage nodes. Migrate the instances from the HCI nodes. See Migrating Virtual Machines Between Compute Nodes in the Instances and Images guide. Disable the Compute services on the nodes to prevent new instances from being launched on the nodes. Remove the node from the overcloud. For steps 3 and 4, see Removing Compute nodes .

Commands:
27.2. Displaying the Current PKINIT Configuration IdM provides multiple commands you can use to query the PKINIT configuration in your domain. To determine the PKINIT status in your domain, use the ipa pkinit-status command: To determine the PKINIT status on the server where you are logged in, use the ipa-pkinit-manage status command: The commands display the PKINIT configuration status as enabled or disabled : enabled : PKINIT is configured using a certificate signed by the integrated IdM CA or an external PKINIT certificate. See also Section 27.1, "Default PKINIT Status in Different IdM Versions" . disabled : IdM only uses PKINIT for internal purposes on IdM servers. To display the IdM servers with active Kerberos key distribution centers (KDCs) that support PKINIT for IdM clients, use the ipa config-show command on any server: Additional Resources For more details on the command-line tools for reporting the PKINIT status, use the ipa help pkinit command.

Commands:
ipa pkinit-status Server name: server1.example.com PKINIT status: enabled [...output truncated...] Server name: server2.example.com PKINIT status: disabled [...output truncated...]
ipa-pkinit-manage status PKINIT is enabled The ipa-pkinit-manage command was successful
ipa config-show Maximum username length: 32 Home directory base: /home Default shell: /bin/sh Default users group: ipausers [...output truncated...] IPA masters capable of PKINIT: server1.example.com [...output truncated...]
5.195. mlocate 5.195.1. RHBA-2012:1355 - mlocate bug fix update Updated mlocate packages that fix two bugs are now available for Red Hat Enterprise 6. The mlocate packages provide a locate/updatedb implementation. Mlocate keeps a database of all existing files and allows you to look up files by name. Bug Fixes BZ# 690800 Prior to this update, the locate(1) manual page contained a misprint. This update corrects the misprint. BZ# 699363 Prior to this update, the mlocate tool aborted the "updatedb" command if an incorrect filesystem implementation returned a zero-length file name. As a consequence, the locate database was not be updated. This update detects invalid zero-length file names, warns about them, and continues to the locate database. All users of mlocate are advised to upgrade to these updated packages, which fix these bugs.

Commands:
Chapter 1. New and changed features Red Hat Service Interconnect is the Red Hat build of Skupper . The following features were designated Technology Preview in version 1.5, but are now fully supported: Windows and macOS You can use the skupper CLI on Windows and macOS. Multiarch You can create sites on 64-bit ARM clusters and Linux hosts (aarch64). The following features are included in this release: Support for Podman version 5. Support for IBM Z and IBM LinuxONE (s390x architecture). Claim type tokens include an expiry date. The skupper token status command allows you validate a token Metrics are now documented. Better support for Podman sites, including console.

Commands:
Chapter 3. Container Images Based on Red Hat Software Collections 3.8 Component Description Supported architectures Daemon Images rhscl/nginx-120-rhel7 nginx 1.20 server and a reverse proxy server x86_64, s390x, ppc64le Database Images rhscl/redis-6-rhel7 Redis 6 key-value store x86_64, s390x, ppc64le Red Hat Developer Toolset Images rhscl/devtoolset-12-toolchain-rhel7 (available since November 2022) Red Hat Developer Toolset toolchain x86_64, s390x, ppc64le rhscl/devtoolset-12-perftools-rhel7 (available since November 2022) Red Hat Developer Toolset perftools x86_64, s390x, ppc64le rhscl/devtoolset-11-toolchain-rhel7 Red Hat Developer Toolset toolchain (EOL) x86_64, s390x, ppc64le rhscl/devtoolset-11-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.8 , see the Red Hat Software Collections 3.8 Release Notes . For more information about the Red Hat Developer Toolset 11 components, see the Red Hat Developer Toolset 11 User Guide . For information about the Red Hat Developer Toolset 12 components, see the Red Hat Developer Toolset 12 User Guide . EOL images are no longer supported.

Commands:
14.15.2.3. Taking a snapshot of the current domain This command is used to query which snapshot is currently in use. To use, run: If snapshotname is not used, snapshot XML for the domain's current snapshot (if there is one) will be displayed as output. If --name is specified, just the current snapshot name instead of the full XML will be sent as output. If --security-info is supplied, security sensitive information will be included in the XML. Using snapshotname , libvirt generates a request to make the existing named snapshot become the current snapshot, without reverting it to the domain.

Commands:
virsh snapshot-current domain {[--name] | [--security-info] | [snapshotname]}