mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 16. Creating a dummy interface As a Red Hat Enterprise Linux user, you can create and use dummy network interfaces for debugging and testing purposes. A dummy interface provides a device to route packets without actually transmitting them. It enables you to create additional loopback-like devices managed by NetworkManager and makes an inactive SLIP (Serial Line Internet Protocol) address look like a real address for local programs. 16.1. Creating a dummy interface with both an IPv4 and IPv6 address by using nmcli You can create a dummy interface with various settings, such as IPv4 and IPv6 addresses. After creating the interface, NetworkManager automatically assigns it to the default public firewalld zone. Procedure Create a dummy interface named dummy0 with static IPv4 and IPv6 addresses: Note To configure a dummy interface without IPv4 and IPv6 addresses, set both the ipv4.method and ipv6.method parameters to disabled . Otherwise, IP auto-configuration fails, and NetworkManager deactivates the connection and removes the device. Verification List the connection profiles: Additional resources nm-settings(5) man page on your system

Commands:
nmcli connection add type dummy ifname dummy0 ipv4.method manual ipv4.addresses 192.0.2.1/24 ipv6.method manual ipv6.addresses 2001:db8:2::1/64
nmcli connection show NAME UUID TYPE DEVICE dummy-dummy0 aaf6eb56-73e5-4746-9037-eed42caa8a65 dummy dummy0
Chapter 1. OpenShift Container Platform CLI tools overview A user performs a range of operations while working on OpenShift Container Platform such as the following: Managing clusters Building, deploying, and managing applications Managing deployment processes Developing Operators Creating and maintaining Operator catalogs OpenShift Container Platform offers a set of command-line interface (CLI) tools that simplify these tasks by enabling users to perform various administration and development operations from the terminal. These tools expose simple commands to manage the applications, as well as interact with each component of the system. 1.1. List of CLI tools The following set of CLI tools are available in OpenShift Container Platform: OpenShift CLI ( oc ) : This is the most commonly used CLI tool by OpenShift Container Platform users. It helps both cluster administrators and developers to perform end-to-end operations across OpenShift Container Platform using the terminal. Unlike the web console, it allows the user to work directly with the project source code using command scripts. Knative CLI (kn) : The Knative ( kn ) CLI tool provides simple and intuitive terminal commands that can be used to interact with OpenShift Serverless components, such as Knative Serving and Eventing. Pipelines CLI (tkn) : OpenShift Pipelines is a continuous integration and continuous delivery (CI/CD) solution in OpenShift Container Platform, which internally uses Tekton. The tkn CLI tool provides simple and intuitive commands to interact with OpenShift Pipelines using the terminal. opm CLI : The opm CLI tool helps the Operator developers and cluster administrators to create and maintain the catalogs of Operators from the terminal. Operator SDK : The Operator SDK, a component of the Operator Framework, provides a CLI tool that Operator developers can use to build, test, and deploy an Operator from the terminal. It simplifies the process of building Kubernetes-native applications, which can require deep, application-specific operational knowledge.

Commands:
Chapter 11. General Updates A new module helping to upgrade the Tomcat server from Red Hat Enterprise Linux 6 to Red Hat Enterprise Linux 7 This update adds a new module to the preupgrade-assistant-el6toel7 package as a Technology Preview. The module helps to upgrade from Tomcat version 6.0.24 in Red Hat Enterprise Linux 6 to Tomcat version 7.0.x in Red Hat Enterprise Linux 7 and provides information about incompatibilities found in the system configuration. When using the module, which is recommended only on non-production machines, several automatic changes are made to the Tomcat configuration files during the postupgrade phase to prevent certain known issues. Note that in the supported scenario, users should remove the tomcat6 packages before upgrading. A new module helping to upgrade Java OpenJDK 7 and Java OpenJDK 8 from Red Hat Enterprise Linux 6 to Red Hat Enterprise Linux 7 The preupgrade-assistant-el6toel7 package provides a new module that handles upgrades of Java OpenJDK 7 and Java OpenJDK 8 from Red Hat Enterprise Linux 6 to Red Hat Enterprise Linux 7. The module, available as a Technology Preview, informs users about possible requested actions and installs the expected equivalents of the original Java OpenJDK packages on the target system. Note that Java OpenJDK 6 and earlier versions are not handled by the in-place upgrade, but the module informs users about expected risks and required manual actions.

Commands:
Chapter 37. Avoiding Anti-Patterns Reuse connections, sessions, consumers, and producers where possible. The most common messaging anti-pattern is the creation of a new connection, session, and producer for every message sent or consumed. These objects take time to create and may involve several network round trips, so it is a poor use of resources. Always reuse them. Note Some popular libraries such as the Spring Messaging Template use these anti-patterns. If you are using the Spring Messaging Template, you may see poor performance. The Spring Messaging Template can only safely be used in an application server which caches Jakarta Messaging sessions, for example, using Jakarta Connectors, and only then for sending messages. It cannot safely be used for synchronously consuming messages, even in an application server. Avoid fat messages. Verbose formats such as XML take up a lot of space on the wire and performance suffers as result. Avoid XML in message bodies if you can. Do not create temporary queues for each request. This common anti-pattern involves the temporary queue request-response pattern. With the temporary queue request-response pattern, a message is sent to a target, and a reply-to header is set with the address of a local temporary queue. When the recipient receives the message, they process it, and then send back a response to the address specified in the reply-to header. A common mistake made with this pattern is to create a new temporary queue on each message sent, which drastically reduces performance. Instead, the temporary queue should be reused for many requests. Do not use message driven beans unless it is necessary. Using MDBs to consume messages is slower than consuming messages using a simple Jakarta Messaging message consumer.

Commands:
5.2. Run Time Errors and Warnings Runtime errors and warnings occur when the SystemTap instrumentation has been installed and is collecting data on the system. WARNING: Number of errors: N , skipped probes: M Errors, skipped probes, or both occurred during this run. N and M are the numbers of errors encountered and probes skipped due to conditions, such as too much time required to execute event handlers over an interval of time. division by 0 The script code performed an invalid division. aggregate element not found A statistics extractor function other than @count was invoked on an aggregate that has not had any values accumulated yet. This is similar to a division by zero. aggregation overflow An array containing aggregate values contains too many distinct key pairs at this time. MAXNESTING exceeded Too many levels of function call nesting were attempted. The default nesting of function calls allowed is 10. MAXACTION exceeded The probe handler attempted to execute too many statements in the probe handler. The default number of actions allowed in a probe handler is 1000. kernel/user string copy fault at ADDR The probe handler attempted to copy a string from kernel or user-space at an invalid address ( ADDR ). pointer dereference fault There was a fault encountered during a pointer dereference operation such as a target variable evaluation.

Commands:
Assessing and Reporting Malware Signatures on RHEL Systems with FedRAMP Red Hat Insights 1-latest Know when systems in your RHEL infrastructure are exposed to malware risks Red Hat Customer Content Services

Commands:
sudo dnf install yara
sudo yum install insights-client
sudo insights-client --test-connection
sudo insights-client --register
sudo insights-client --collector malware-detection
test_scan: false
sudo insights-client --collector malware-detection
scan_processes: true
sudo insights-client --collector malware-detection
FILESYSTEM_SCAN_ONLY=/etc,/tmp,/var/lib
sudo FILESYSTEM_SCAN_ONLY=/etc,/tmp,/var/lib TEST_SCAN=false insights-client --collector malware-detection
4.5. Creating a system image with Image Builder in the web console interface The following steps below describe creating a system image. Prerequisites You have opened the Image Builder interface of the RHEL 7 web console in a browser. A blueprint exists. Procedure 1. Locate the blueprint that you want to build an image by entering its name or a part of it into the search box at top left, and press Enter . The search is added to the list of filters under the text entry field, and the list of blueprints below is reduced to these that match the search. If the list of blueprints is too long, add further search terms in the same way. 2. On the right side of the blueprint, press the Create Image button that belongs to the blueprint. A pop-up window appears. 3. Select the image type and architecture and press Create. A small pop-up in the top right informs you that the image creation has been added to the queue. 4. Click the name of the blueprint. A screen with details of the blueprint opens. 5. Click the Images tab to switch to it. The image that is being created is listed with the status In Progress. Important Image creation takes a longer time, measured in minutes. There is no indication of progress while the image is created. To abort image creation, press its Stop button on the right. 6. Once the image is successfully created, the Stop button is replaced by a Download button. Click this button to download the image to your system.

Commands:
2.2. Making Minimal Boot Media A piece of minimal boot media is a CD, DVD, or USB flash drive that contains the software to boot the system and launch the installation program, but which does not contain the software that must be transferred to the system to create a Red Hat Enterprise Linux installation. Use minimal boot media: to boot the system to install Red Hat Enterprise Linux over a network to boot the system to install Red Hat Enterprise Linux from a hard drive to use a kickstart file during installation (refer to Section 32.9.1, "Creating Kickstart Boot Media" to commence a network or hard-drive installation or to use an anaconda update or a kickstart file with a DVD installation. You can use minimal boot media to start the installation process on 32-bit x86 systems, AMD64 or Intel 64 systems, and Power Systems servers. The process by which you create minimal boot media for systems of these various types is identical except in the case of AMD64 and Intel 64 systems with UEFI firmware interfaces - refer to Section 2.2.2, "Minimal USB Boot Media for UEFI-based Systems" . To make minimal boot media for 32-bit x86 systems, BIOS-based AMD64 or Intel 64 systems, and Power Systems servers: Download the ISO image file named rhel- variant - version - architecture -boot.iso that is available at the same location as the images of the Red Hat Enterprise Linux 6.9 installation DVD - refer to Chapter 1, Obtaining Red Hat Enterprise Linux . Burn the .iso file to a blank CD or DVD using the same procedure detailed in Section 2.1, "Making an Installation DVD" for the installation disc. Alternatively, transfer the .iso file to a USB device with the dd command. As the .iso file is only around 200 MB in size, you do not need an especially large USB flash drive. 2.2.1. Minimal USB Boot Media for BIOS-based Systems Warning When you perform this procedure any data on the USB flash drive is destroyed with no warning. Make sure that you specify the correct USB flash drive, and make sure that this flash drive does not contain any data that you want to keep. Plug in your USB flash drive. Find the flash drive's device name. If the media has a volume name, use it to look up the device name in /dev/disk/by-label , or use the findfs command: If the media does not have a volume name or you do not know it, you can also use the dmesg command shortly after connecting the media to your computer. After running the command, the device name (such as sdb or sdc ) should appear in several lines towards the end of the output. Become root: Use the dd command to transfer the boot ISO image to the USB device: where path/image_name .iso is the boot ISO image file that you downloaded and device is the device name for the USB flash drive. Ensure you specify the device name (such as sdc ), not the partition name (such as sdc1 ). For example:

Commands:
findfs LABEL= MyLabel
su -
dd if= path/image_name .iso of=/dev/ device
dd if=~/Downloads/RHEL6.9-Server-x86_64-boot.iso of=/dev/sdc
12.4.2. Deleting a Storage Pool Using virt-manager This procedure demonstrates how to delete a storage pool. To avoid any issues with other guest virtual machines using the same pool, it is best to stop the storage pool and release any resources in use by it. To do this, select the storage pool you want to stop and click the red X icon at the bottom of the Storage window. Figure 12.18. Stop Icon Delete the storage pool by clicking the Trash can icon. This icon is only enabled if you stop the storage pool first.

Commands:
Chapter 4. Getting started with Apicurio Registry Apicurio Registry is a powerful tool for managing and storing data schemas, API designs, or any structured content in a centralized repository. It supports a wide variety of artifact types, including Avro, Protobuf, JSON Schema, and OpenAPI definitions. Additional information Apicurio Registry documentation 4.1. Exploring artifacts Artifacts are the building blocks of Apicurio Registry. They represent data structures, API designs, or schema definitions stored in the registry for reuse and collaboration. You can upload, update, and retrieve artifacts, view their version history, and manage their lifecycle. 4.2. Managing groups Groups allow you to organize artifacts logically, making it easier to manage and retrieve them. Each artifact belongs to a group, and groups can represent domains, projects, or teams. Grouping provides isolation while enabling fine-grained control over access and usage policies. 4.3. Managing rules Rules in Apicurio Registry help enforce consistency and quality by validating artifacts against defined standards. You can apply global rules for the entire registry or configure specific rules for individual groups and artifacts. 4.4. Configuring settings The configuration options in Apicurio Registry allow you to tailor the registry to your specific needs. Adjust operational parameters, integrate with external systems, or configure advanced settings to enhance performance and security. 4.5. Using the API Apicurio Registry provides a robust REST API to interact with the registry programmatically. Developers can automate artifact management, integrate registry features into CI/CD pipelines, or build custom tools to enhance schema governance.

Commands:
4.3.3. Displaying Volume Groups There are two commands you can use to display properties of LVM volume groups: vgs and vgdisplay . The vgscan command, which scans all the disks for volume groups and rebuilds the LVM cache file, also displays the volume groups. For information on the vgscan command, see Section 4.3.4, "Scanning Disks for Volume Groups to Build the Cache File" . The vgs command provides volume group information in a configurable form, displaying one line per volume group. The vgs command provides a great deal of format control, and is useful for scripting. For information on using the vgs command to customize your output, see Section 4.9, "Customized Reporting for LVM" . The vgdisplay command displays volume group properties (such as size, extents, number of physical volumes, etc.) in a fixed form. The following example shows the output of a vgdisplay command for the volume group new_vg . If you do not specify a volume group, all existing volume groups are displayed.

Commands:
vgdisplay new_vg --- Volume group --- VG Name new_vg System ID Format lvm2 Metadata Areas 3 Metadata Sequence No 11 VG Access read/write VG Status resizable MAX LV 0 Cur LV 1 Open LV 0 Max PV 0 Cur PV 3 Act PV 3 VG Size 51.42 GB PE Size 4.00 MB Total PE 13164 Alloc PE / Size 13 / 52.00 MB Free PE / Size 13151 / 51.37 GB VG UUID jxQJ0a-ZKk0-OpMO-0118-nlwO-wwqd-fD5D32
Providing feedback on Red Hat documentation We appreciate your feedback on our documentation. Provide as much detail as possible so that your request can be addressed. Prerequisites You have a Red Hat account. You are logged in to your Red Hat account. Procedure To provide your feedback, click the following link: Create Issue Describe the issue or enhancement in the Summary text box. Provide more details about the issue or enhancement in the Description text box. If your Red Hat user name does not automatically appear in the Reporter text box, enter it. Scroll to the bottom of the page and then click the Create button. A documentation issue is created and routed to the appropriate documentation team. Thank you for taking the time to provide feedback.

Commands:
4.170. mailman 4.170.1. RHBA-2011:1275 - mailman bug fix update An updated mailman package that fixes various bugs is now available for Red Hat Enterprise Linux 6. Mailman is a program used to help manage email discussion lists. Bug Fixes BZ# 704699 , BZ# 703389 Previously, a number of Python scripts and subdirectories in the /usr/lib/mailman/ directory were group writable. As a result, the respective files and subdirectories could have been changed not only by the owner, but also by other users in the same user group. This undesired behavior has been resolved in this update so that only the owner can now change the files and subdirectories. BZ# 684622 Because of a bug in the brp-python-compile script file, unnecessary /etc/mailman/mm_cfg.pyc and /etc/mailman/mm_cfg.pyo files were generated under certain circumstances. As a result, the Mailman build process could have failed. This update fixes the aforementioned bug by compiling Python script files manually so that the build process no longer fails. BZ# 636825 In accordance with current guidelines, all Python executable files have been updated to use the Python executable file directly, that is the "#!/usr/bin/python" string instead of "#!/usr/bin/env python". All users of mailman are advised to upgrade to this updated package, which fixes these bugs.

Commands:
Chapter 3. Deprecated Features 3.1. Map/Reduce The native Map/Reduce API in JDG 6 has been deprecated in version 6.6.0 and is expected to be removed in version 7.0.0. JDG 7.0.0 will support the Map/Reduce use case via a new Distributed Streams feature, which is based on the Java 8 Stream API. Report a bug

Commands:
4.2. Which Log File is Used In Red Hat Enterprise Linux, the dbus and audit packages are installed by default, unless they are removed from the default package selection. The setroubleshoot-server must be installed using Yum (use the yum install setroubleshoot-server command). If the auditd daemon is running, an SELinux denial message, such as the following, is written to /var/log/audit/audit.log by default: In addition, a message similar to the one below is written to the /var/log/message file: In Red Hat Enterprise Linux 7, setroubleshootd no longer constantly runs as a service. However, it is still used to analyze the AVC messages. Two new programs act as a method to start setroubleshoot when needed: The sedispatch utility runs as a part of the audit subsystem. When an AVC denial message is returned, sedispatch sends a message using dbus . These messages go straight to setroubleshootd if it is already running. If it is not running, sedispatch starts it automatically. The seapplet utility runs in the system toolbar, waiting for dbus messages in setroubleshootd . It launches the notification bubble, allowing the user to review AVC messages. Procedure 4.1. Starting Daemons Automatically To configure the auditd and rsyslog daemons to automatically start at boot, enter the following commands as the root user: To ensure that the daemons are enabled, type the following commands at the shell prompt: Alternatively, use the systemctl status service-name .service command and search for the keyword enabled in the command output, for example: To learn more on how the systemd daemon manages system services, see the Managing System Services chapter in the System Administrator's Guide.

Commands:
type=AVC msg=audit(1223024155.684:49): avc: denied { getattr } for pid=2000 comm="httpd" path="/var/www/html/file1" dev=dm-0 ino=399185 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:samba_share_t:s0 tclass=file
May 7 18:55:56 localhost setroubleshoot: SELinux is preventing httpd (httpd_t) "getattr" to /var/www/html/file1 (samba_share_t). For complete SELinux messages. run sealert -l de7e30d6-5488-466d-a606-92c9f40d316d
~]# systemctl enable auditd.service
~]# systemctl enable rsyslog.service
~]USD systemctl is-enabled auditd enabled
~]USD systemctl is-enabled rsyslog enabled
~]USD systemctl status auditd.service | grep enabled auditd.service - Security Auditing Service Loaded: loaded (/usr/lib/systemd/system/auditd.service; enabled )
Chapter 8. Viewing the status of the QuayRegistry object Lifecycle observability for a given Red Hat Quay deployment is reported in the status section of the corresponding QuayRegistry object. The Red Hat Quay Operator constantly updates this section, and this should be the first place to look for any problems or state changes in Red Hat Quay or its managed dependencies. 8.1. Viewing the registry endpoint Once Red Hat Quay is ready to be used, the status.registryEndpoint field will be populated with the publicly available hostname of the registry. 8.2. Viewing the version of Red Hat Quay in use The current version of Red Hat Quay that is running will be reported in status.currentVersion . 8.3. Viewing the conditions of your Red Hat Quay deployment Certain conditions will be reported in status.conditions .

Commands: