mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 3. Reports by CVEs You can create PDF reports showing a filtered list of CVEs your systems are exposed to. Give each report a relevant name, apply filters, and add user notes to present focused data to specific stakeholders. You can apply the following filters when setting up the PDF report: Security rules. Show only CVEs with the security rules label. Known exploit. Show only CVEs with the Known exploit label. Severity. Select one or more values: Critical, Important, Moderate, Low, or Unknown. CVSS base score. Select one or more ranges: All, 0.0-3.9, 4.0-7.9, 8.0-10.0, N/A (not applicable) Business risk. Select one or more values: High, Medium, Low, Not defined. Status. Select one or more values: Not reviewed, In review, On-hold, Scheduled for patch, Resolved, No action - risk accepted, Resolved via mitigation. Publish date. Select from All, Last 7 days, Last 30 days, Last 90 days, Last year, or More than 1 year ago. Applies to OS. Select the RHEL minor version(s) of systems to filter and view. Tags. Select groups of tagged systems. For more information about tags and system groups, see System tags and groups Advisory. Select whether to display only CVEs that have associated advisories (errata), only CVEs without advisories, or all CVEs. The CVE report lists the CVEs, linking each to the respective CVE page in the Red Hat CVE database so you can learn more about it. The list is ordered primarily by the publish date of the CVE, with the most recently published CVEs at the top of the list. Example of an Insights Vulnerability CVE report 3.1. Creating a PDF report of CVEs Use the following procedure to create a point-in-time snapshot of CVEs potentially affecting your systems. Prerequisites You must be logged in to Red Hat Hybrid Cloud Console . Procedure Navigate to the Security > Vulnerability > Reports page in the Insights for Red Hat Enterprise Linux application. On the Report by CVEs card, click Create report . Make selections as needed in the pop-up card: Optionally, customize the report title. Under Filter CVEs by , click each filter dropdown and select a value. Select Tags to only include systems in a tagged group of systems. Under CVE data to include, Choose columns is activated by default, allowing you to deselect columns you do not want to include. Leave all boxes checked, or click All columns to show everything. Optionally add notes to give the report context for the intended audience. Click Export report and allow the application a minute to generate the report. Select to open or save the PDF file, if your OS asks, and click OK .

Commands:
Chapter 88. Plugin schema reference Used in: Build Property Description name The unique name of the connector plugin. Will be used to generate the path where the connector artifacts will be stored. The name has to be unique within the KafkaConnect resource. The name has to follow the following pattern: ^[a-z][-_a-z0-9]*[a-z]USD . Required. string artifacts List of artifacts which belong to this connector plugin. Required. JarArtifact , TgzArtifact , ZipArtifact , MavenArtifact , OtherArtifact array

Commands:
Chapter 5. Using Insights tasks to help you convert from CentOS Linux 7 to RHEL 7 You can use Red Hat Insights to help you convert from CentOS Linux 7 to RHEL 7. For more information about using Insights tasks to help convert your systems, see Converting using Insights in the Converting from a Linux distribution to RHEL using the Convert2RHEL utility documentation . Additional resources Video: Pre-conversion analysis for converting to Red Hat Enterprise Linux Video: Convert to Red Hat Enterprise Linux from CentOS7 Linux using Red Hat Insights Troubleshooting conversion-related Insights tasks Tasks help you update, manage, or secure your Red Hat Enterprise Linux infrastructure using Insights. Each task is a predefined playbook that executes a task from start to finish. If you have trouble completing some Insights conversion-related tasks, see: Troubleshooting issues with Red Hat Insights conversions

Commands:
Chapter 17. Virtual Networking This chapter introduces the concepts needed to create, start, stop, remove, and modify virtual networks with libvirt. Additional information can be found in the libvirt reference chapter 17.1. Virtual Network Switches Libvirt virtual networking uses the concept of a virtual network switch . A virtual network switch is a software construct that operates on a host physical machine server, to which virtual machines (guests) connect. The network traffic for a guest is directed through this switch: Figure 17.1. Virtual network switch with two guests Linux host physical machine servers represent a virtual network switch as a network interface. When the libvirtd daemon ( libvirtd ) is first installed and started, the default network interface representing the virtual network switch is virbr0 . This virbr0 interface can be viewed with the ip command like any other interface:

Commands:
ip addr show virbr0 3: virbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN link/ether 1b:c4:94:cf:fd:17 brd ff:ff:ff:ff:ff:ff inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
1.5. Package Selection Use the %packages command to begin a kickstart file section that lists the packages you would like to install (this is for installations only, as package selection during upgrades is not supported). Packages can be specified by group or by individual package name. The installation program defines several groups that contain related packages. Refer to the RedHat/base/comps.xml file on the first Red Hat Enterprise Linux CD-ROM for a list of groups. Each group has an id, user visibility value, name, description, and package list. In the package list, the packages marked as mandatory are always installed if the group is selected, the packages marked default are selected by default if the group is selected, and the packages marked optional must be specifically selected even if the group is selected to be installed. In most cases, it is only necessary to list the desired groups and not individual packages. Note that the Core and Base groups are always selected by default, so it is not necessary to specify them in the %packages section. Here is an example %packages selection: As you can see, groups are specified, one to a line, starting with an @ symbol, a space, and then the full group name as given in the comps.xml file. Groups can also be specified using the id for the group, such as gnome-desktop . Specify individual packages with no additional characters (the dhcp line in the example above is an individual package). You can also specify which packages not to install from the default package list: The following options are available for the %packages option: --resolvedeps Install the listed packages and automatically resolve package dependencies. If this option is not specified and there are package dependencies, the automated installation pauses and prompts the user. For example: --ignoredeps Ignore the unresolved dependencies and install the listed packages without the dependencies. For example: --ignoremissing Ignore the missing packages and groups instead of halting the installation to ask if the installation should be aborted or continued. For example:

Commands:
%packages @ X Window System @ GNOME Desktop Environment @ Graphical Internet @ Sound and Video dhcp
-autofs
%packages --resolvedeps
%packages --ignoredeps
%packages --ignoremissing
Chapter 5. Deploying the all-in-one Red Hat OpenStack Platform environment Procedure Log in to registry.redhat.io with your Red Hat credentials: Export the environment variables that the deployment command uses. In this example, deploy the all-in-one environment with the eth1 interface that has the IP address 192.168.25.2 on the management network: Set the hostname. If the node is using localhost.localdomain, the deployment will fail. Enter the deployment command. Ensure that you include all .yaml files relevant to your environment: After a successful deployment, you can use the clouds.yaml configuration file in the /home/USDUSER/.config/openstack directory to query and verify the OpenStack services: To access the dashboard, go to to http://192.168.25.2/dashboard and use the default username admin and the undercloud_admin_password from the ~/standalone-passwords.conf file:

Commands:
[stack@all-in-one]USD sudo podman login registry.redhat.io
[stack@all-in-one]USD export IP=192.168.25.2 [stack@all-in-one]USD export NETMASK=24 [stack@all-in-one]USD export INTERFACE=eth1
[stack@all-in-one]USD hostnamectl set-hostname all-in-one.example.net [stack@all-in-one]USD hostnamectl set-hostname all-in-one.example.net --transient
[stack@all-in-one]USD sudo openstack tripleo deploy --templates --local-ip=USDIP/USDNETMASK -e /usr/share/openstack-tripleo-heat-templates/environments/standalone/standalone-tripleo.yaml -r /usr/share/openstack-tripleo-heat-templates/roles/Standalone.yaml -e USDHOME/containers-prepare-parameters.yaml -e USDHOME/standalone_parameters.yaml --output-dir USDHOME --standalone
[stack@all-in-one]USD export OS_CLOUD=standalone [stack@all-in-one]USD openstack endpoint list
[stack@all-in-one]USD cat standalone-passwords.conf | grep undercloud_admin_password:
7.13. RHEA-2014:1501 - new package: libestr New libestr packages are now available for Red Hat Enterprise Linux 6. The libestr packages contain the string handling essentials library used by the Rsyslog daemon, and is required by the rsyslog7 package. This enhancement update adds the libestr packages to Red Hat Enterprise Linux 6. (BZ# 966966 ) All users who require libestr are advised to install these new packages.

Commands:
34.2. Removing Red Hat Enterprise Linux from IBM Z If you want to delete the existing operating system data, first, if any Linux disks contain sensitive data, ensure that you destroy the data according to your security policy. To proceed you can consider these options: Overwrite the disks with a new installation. Make the DASD or SCSI disk where Linux was installed visible from another system, then delete the data. However, this might require special privileges. Ask your system administrator for advice. You can use Linux commands such as dasdfmt (DASD only), parted , mke2fs or dd . For more details about the commands, see the respective man pages. 34.2.1. Running a Different Operating System on Your z/VM Guest or LPAR If you want to boot from a DASD or SCSI disk different from where the currently installed system resides under a z/VM guest virtual machine or an LPAR, shut down the Red Hat Enterprise Linux installed and use the desired disk, where another Linux instance is installed, to boot from. This leaves the contents of the installed system unchanged.

Commands:
7.224. seabios 7.224.1. RHBA-2013:0307 - seabios bug fix and enhancement update Updated seabios packages that fix several bugs and add two enhancements are now available for Red Hat Enterprise Linux 6. The seabios packages contain an open-source legacy BIOS implementation which can be used as a coreboot payload. It implements the standard BIOS calling interfaces that a typical x86 proprietary BIOS implements. Bug Fixes BZ# 771616 In the QXL-VGA drive, the ram_size and vram_size variables were set to a default value that was too high. Consequently, the guest was not able to boot, and the "VM status: paused (internal-error)" message was returned. This update uses extended addressing for PCI address space and the guest can now boot successfully. BZ# 839674 Previously, the advertisement of S3 and S4 states in the default BIOS was disabled for which a separate BIOS binary file had been created. This update enables users to configurate S3 and S4 states per virtual machine in seabios and thus, the extra BIOS binary file is no longer necessary. Now, a single binary is used to enable these states. BZ# 851245 Prior to this update, the SeaBIOS component did not support the non-contiguous APIC IDs. This resulted in incorrect topology generation on SMP and NUMA systems; moreover, QEMU-KVM was unable to run on some of the host systems. A patch has been provided to fix this bug and Seabios now supports the non-contiguous APIC IDs. BZ# 854448 The seabios packages used the time-stamp counter (TSC) for timekeeping with a simple calibration loop. As a consequence, on a busy host, the magnitude calibration could be set incorrectly and could lead to boot failures. This update provides the power management timer (PMT) with a fixed frequency, which does not suffer from calibration errors due to a loaded host machine. As a result, timeouts work correctly under all circumstances. Enhancements BZ#827500 With this update, it is possible to configurate S3 and S4 states per virtual machine. BZ#831273 The seabios packages are now able to reboot a VM even if no bootable device can be found. Users of seabios are advised to upgrade to these updated packages, which fix these bugs and add these enhancements.

Commands:
Chapter 1. Overview Red Hat build of Apache Qpid Proton DotNet is a lightweight AMQP 1.0 library for the .NET platform. It enables you to write .NET applications that send and receive AMQP messages. Red Hat build of Apache Qpid Proton DotNet is part of AMQ Clients, a suite of messaging libraries supporting multiple languages and platforms. For information on available clients, see AMQ Clients . 1.1. Key features SSL/TLS for secure communication Flexible SASL authentication Seamless conversion between AMQP and native data types Access to all the features and capabilities of AMQP 1.0 An integrated development environment with full IntelliSense API documentation 1.2. Supported standards and protocols Red Hat build of Apache Qpid Proton DotNet supports the following industry-recognized standards and network protocols: Version 1.0 of the Advanced Message Queueing Protocol (AMQP) Versions 1.0, 1.1, 1.2, and 1.3 of the Transport Layer Security (TLS) protocol, the successor to SSL Simple Authentication and Security Layer (SASL) mechanisms ANONYMOUS, PLAIN, and EXTERNAL Modern TCP with IPv6 1.3. Supported configurations Refer to Red Hat AMQ Supported Configurations on the Red Hat Customer Portal for current information regarding Red Hat build of Apache Qpid Proton DotNet supported configurations. 1.4. Terms and concepts This section introduces the core API entities and describes how they operate together. Table 1.1. API terms Entity Description Client A context for creating Connections to Brokers Connection A channel for communication between two peers on a network Session A context for sending and receiving messages Sender A channel for sending messages to a target Receiver A channel for receiving messages from a source Delivery A Delivery received from a IReceiver that can be acted upon and contains a message Message A mutable holder of application data Red Hat build of Apache Qpid Proton DotNet sends and receives Messages . Messages are transferred to Brokers via Senders and from Brokers using Receivers . Received Messages are wrapped in a Delivery which can be Accepted, Rejected or Released. Senders and Receivers are created using Connections which are in turn created using Clients . Sessions are established over Connections . 1.5. Document conventions The sudo command In this document, sudo is used for any command that requires root privileges. Exercise caution when using sudo because any changes can affect the entire system. For more information about sudo , see Using the sudo command . File paths In this document, all file paths are valid for Linux, UNIX, and similar operating systems (for example, /home/andrea ). On Microsoft Windows, you must use the equivalent Windows paths (for example, C:\Users\andrea ). Variable text This document contains code blocks with variables that you must replace with values specific to your environment. Variable text is enclosed in arrow braces and styled as italic monospace. For example, in the following command, replace <project-dir> with the value for your environment: USD cd <project-dir>

Commands:
cd <project-dir>
Chapter 41. Online Storage Configuration Troubleshooting This section provides solution to common problems users experience during online storage reconfiguration. Logical unit removal status is not reflected on the host. When a logical unit is deleted on a configured filer, the change is not reflected on the host. In such cases, lvm commands will hang indefinitely when dm-multipath is used, as the logical unit has now become stale . To work around this, perform the following procedure: Procedure 41.1. Working Around Stale Logical Units Determine which mpath link entries in /etc/lvm/cache/.cache are specific to the stale logical unit. To do this, run the following command: Example 41.1. Determine specific mpath link entries For example, if stale-logical-unit is 3600d0230003414f30000203a7bc41a00, the following results may appear: This means that 3600d0230003414f30000203a7bc41a00 is mapped to two mpath links: dm-4 and dm-5 . , open /etc/lvm/cache/.cache . Delete all lines containing stale-logical-unit and the mpath links that stale-logical-unit maps to. Example 41.2. Delete relevant lines Using the same example in the step, the lines you need to delete are:

Commands:
ls -l /dev/mpath | grep stale-logical-unit
lrwxrwxrwx 1 root root 7 Aug 2 10:33 /3600d0230003414f30000203a7bc41a00 -> ../dm-4 lrwxrwxrwx 1 root root 7 Aug 2 10:33 /3600d0230003414f30000203a7bc41a00p1 -> ../dm-5
/dev/dm-4 /dev/dm-5 /dev/mapper/3600d0230003414f30000203a7bc41a00 /dev/mapper/3600d0230003414f30000203a7bc41a00p1 /dev/mpath/3600d0230003414f30000203a7bc41a00 /dev/mpath/3600d0230003414f30000203a7bc41a00p1
Chapter 90. OpenTelemetryTracing schema reference Used in: KafkaBridgeSpec , KafkaConnectSpec , KafkaMirrorMaker2Spec , KafkaMirrorMakerSpec The type property is a discriminator that distinguishes use of the OpenTelemetryTracing type from JaegerTracing . It must have the value opentelemetry for the type OpenTelemetryTracing . Property Property type Description type string Must be opentelemetry .

Commands:
Appendix D. Overview of the host columns Below is the complete overview of columns that can be displayed in the host table divided into content categories. Some columns fall under more than one category. For more information on how to customize columns in the host table, see Section 2.17, "Selecting host columns" . General Power - Whether the host is turned on or off, if available Name - name of the host Operating system - operating system of the host Model - host hardware model (or compute resource in case of virtual hosts) Owner - user or group owning the host Host group - host group of the host Last report - time of the last host report Comment - comment given to host Content Name - name of the host Operating system - operating system of the host Subscription status - does the host have a valid subscription attached Installable updates - numbers of installable updates divided into four categories: security, bugfix, enhancement, total Lifecycle environment - lifecycle environment of the host Content view - content view of the host Registered - time when the host was registered to Satellite Last checkin - last time of the communication between the host and the Satellite Server Network IPv4 - IPv4 address of the host IPv6 - IPv6 address of the host MAC - MAC address of the host Reported data Sockets - number of host sockets Cores - number of host processor cores RAM - amount of memory Boot time - last boot time of the host Virtual - whether or not the host is recognized as a virtual machine Disks total space - total host storage space Kernel Version - Kernel version of the host operating system BIOS vendor - vendor of the host BIOS BIOS release date - release date of the host BIOS BIOS version - version of the host BIOS Puppet (only if the Puppet plugin is installed) Environment name - name of the Puppet environment of the host RH Cloud Recommendations - number of available recommendations for the host

Commands:
Chapter 14. Asset overview Business rules, process definition files, and other assets and resources created in Business Central are stored in the Artifact repository (Knowledge Store) that KIE Server accesses. The Artifact repository is a centralized repository for your business knowledge. It connects multiple GIT repositories so that you can access them from a single environment while storing different kinds of knowledge and artifacts in different locations. GIT is a distributed version control system and it implements revisions as commit objects. Every time you save your changes to a repository this creates a new commit object in the GIT repository. Similarly, the user can also copy an existing repository. This copying process is typically called cloning and the resulting repository can be referred to as clone. Every clone contains the full history of the collection of files and a cloned repository has the same content as the original repository. Business Central provides a web front-end that enables you to view and update the stored content. To access Artifact repository assets, go to Menu Design Projects in Business Central and click the project name.

Commands:
13.3. Example Query The following example has a query that retrieves all engineering employees born since 1970. Example 13.1. Example query SELECT e.title, e.lastname FROM Employees AS e JOIN Departments AS d ON e.dept_id = d.dept_id WHERE year(e.birthday) >= 1970 AND d.dept_name = 'Engineering' Logically, the data from the Employees and Departments tables are retrieved, then joined, then filtered as specified, and finally the output columns are projected. The canonical query plan thus looks like this: Figure 13.1. Canonical Query Plan Data flows from the tables at the bottom upwards through the join, through the select, and finally through the project to produce the final results. The data passed between each node is logically a result set with columns and rows. This is what happens logically , not how the plan is actually executed. Starting from this initial plan, the query planner performs transformations on the query plan tree to produce an equivalent plan that retrieves the same results faster. Both a federated query planner and a relational database planner deal with the same concepts and many of the same plan transformations. In this example, the criteria on the Departments and Employees tables will be pushed down the tree to filter the results as early as possible. In both cases, the goal is to retrieve the query results in the fastest possible time. However, the relational database planner does this primarily by optimizing the access paths in pulling data from storage. In contrast, a federated query planner is less concerned about storage access because it is typically pushing that burden to the data source. The most important consideration for a federated query planner is minimizing data transfer.

Commands:
SELECT e.title, e.lastname FROM Employees AS e JOIN Departments AS d ON e.dept_id = d.dept_id WHERE year(e.birthday) >= 1970 AND d.dept_name = 'Engineering'
23.8. Serving NTP Time With PTP NTP to PTP synchronization in the opposite direction is also possible. When ntpd is used to synchronize the system clock, ptp4l can be configured with the priority1 option (or other clock options included in the best master clock algorithm) to be the grandmaster clock and distribute the time from the system clock via PTP : With hardware time stamping, phc2sys needs to be used to synchronize the PTP hardware clock to the system clock: To prevent quick changes in the PTP clock's frequency, the synchronization to the system clock can be loosened by using smaller P (proportional) and I (integral) constants of the PI servo:

Commands:
~]# cat /etc/ptp4l.conf [global] priority1 127 ptp4l -f /etc/ptp4l.conf
~]# phc2sys -c eth3 -s CLOCK_REALTIME -w
~]# phc2sys -c eth3 -s CLOCK_REALTIME -w -P 0.01 -I 0.0001