mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 27. System and Subscription Management Some Italian text is missing from subscription-manager Due to some missing translations in the subscription-manager tool, when using subscription-manager in Italian, some messages will appear in English. (BZ# 1318404 ) ReaR supports only grub during system recovery ReaR supports only the grub boot loader. Consequently, ReaR cannot automatically recover a system with a different boot loader. Notably, yaboot is not yet supported by ReaR on PowerPC machines. To work around this problem, edit the boot loader manually. (BZ# 1313874 ) ReaR works only on the eth0 interface ReaR produces a rescue system that does not support mounting an NFS server using an interface other than eth0. Consequently, the backup files cannot be downloaded and the system cannot be restored. To work around this problem, ensure that the used interface is eth0 by restarting dhclient. (BZ# 1313417 ) ReaR fails to create an ISO on IBM System z ReaR is unable to create an ISO image on IBM System z systems. To work around this problem, use a different type of rescue system than ISO. (BZ# 1309597 ) ReaR creates two ISO images instead of one In ReaR, the OUTPUT_URL directive enables specifying location for the ISO image containing the rescue system. Currently, with this directive set, ReaR creates two copies of the ISO image: one in the specified directory and one in the /var/lib/rear/output/ default directory. This requires additional space for the image. This is especially important if a full-system backup is included into the ISO image (using the BACKUP=NETFS and BACKUP_URL=iso:///backup/ configuration). To work around this behavior, delete the extra ISO image once ReaR has finished working or, to avoid having a period of time with double storage consumption, create the image in the default directory and then move it to the desired location manually. There is a request for enhancement to change this behavior and make ReaR create only one copy of the ISO image. (BZ#1320551)

Commands:
Preface Red Hat Quay container image registries serve as centralized hubs for storing container images. Users of Red Hat Quay can create repositories to effectively manage images and grant specific read (pull) and write (push) permissions to the repositories as deemed necessary. Administrative privileges expand these capabilities, allowing users to perform a broader set of tasks, like the ability to add users and control default settings. This guide offers an overview of Red Hat Quay's users and organizations, its tenancy model, and basic operations like creating and deleting users, organizations, and repositories, handling access, and interacting with tags. It includes both UI and API operations. Note The following API endpoints are linked to their associated entry in the Red Hat Quay API guide . The Red Hat Quay API guide provides more information about each endpoint, such as response codes and optional query parameters.

Commands:
5.4. Importing and running converted virtual machines on target hypervisors Now that you have converted your physical machine to a virtual machine, it can be run on a hypervisor. For information on running the converted physical machine as a virtual machine on Red Hat Enterprise Linux using virt-manager, see: Section 3.4, "Running converted virtual machines" For information on importing and running the converted physical machine as a virtual machine in Red Hat Enterprise Virtualization using the Red Hat Enterprise Virtualization Manager, see: Section 4.3.3, "Importing and running the converted virtual machine"

Commands:
4.371. rsync 4.371.1. RHBA-2013:1485 - rsync bug fix update An updated rsync package that fixes a bug is now available for Red Hat Enterprise Linux 6. The rsync tool is used to copy and synchronize files locally or across a network. The rsync works very fast because it uses delta encoding and sends just differences in files instead of whole files. The rsync is also used as powerful mirroring tool. Bug Fix BZ# 1022355 Previously, the rsync tool did not check whether the inbuf variable is non-empty. As a consequence, rsync terminated unexpectedly while trying to do the required encoding in a loop. With this update, rsync checks whether inbuf is non-empty and no longer crashes in the described scenario. Users of rsync are advised to upgrade to these updated packages, which fix this bug.

Commands:
Chapter 5. Testing Clair Use the following procedure to test Clair on either a standalone Red Hat Quay deployment, or on an OpenShift Container Platform Operator-based deployment. Prerequisites You have deployed the Clair container image. Procedure Pull a sample image by entering the following command: USD podman pull ubuntu:20.04 Tag the image to your registry by entering the following command: USD sudo podman tag docker.io/library/ubuntu:20.04 <quay-server.example.com>/<user-name>/ubuntu:20.04 Push the image to your Red Hat Quay registry by entering the following command: USD sudo podman push --tls-verify=false quay-server.example.com/quayadmin/ubuntu:20.04 Log in to your Red Hat Quay deployment through the UI. Click the repository name, for example, quayadmin/ubuntu . In the navigation pane, click Tags . Report summary Click the image report, for example, 45 medium , to show a more detailed report: Report details Note In some cases, Clair shows duplicate reports on images, for example, ubi8/nodejs-12 or ubi8/nodejs-16 . This occurs because vulnerabilities with same name are for different packages. This behavior is expected with Clair vulnerability reporting and will not be addressed as a bug.

Commands:
podman pull ubuntu:20.04
sudo podman tag docker.io/library/ubuntu:20.04 <quay-server.example.com>/<user-name>/ubuntu:20.04
sudo podman push --tls-verify=false quay-server.example.com/quayadmin/ubuntu:20.04
Chapter 2. Parameters \u00ad\u00ad\u00ad\u00adThese parameters of an existing two-node cluster are used to setup the third site: Parameter Example Description SID RH2 System ID of the HANA Database First SITE DC1 Name of the first datacenter /site Second SITE DC2 Name of the second datacenter / site Third SITE DC3 Name of the third datacenter / site InstanceNr 02 HANA Instance Number <sid>adm uid 1000 User-ID of SAP HANA admin user (rh2adm) sapsys gid 980 Group ID of sapsys It is required that all three HANA instances use the same values for the following: SID InstanceNr <sid>adm uid sapsys gid

Commands:
Customizing Red Hat Trusted Application Pipeline Red Hat Trusted Application Pipeline 1.4 Learn how to customize default software templates and build pipeline configurations. Red Hat Trusted Application Pipeline Documentation Team

Commands:
./generate.sh
REKOR_HOST=http://rekor-server.rhtap-tas.svc TUF_MIRROR=http://tuf.rhtap-tas.svc
oc get routes -n rhtap-tas
./scripts/update-tekton-definition {fork_url} {branch_name} For example, .scripts/update-tekton-definition https://github.com/<username>/tssc-sample-pipelines main
mkdir rebuild-image
more ../tssc-sample-templates/skeleton/ci/source-repo/gitlabci/.gitlab-ci.yml Example: image: quay.io/redhat-appstudio/rhtap-task-runner:latest
run -v USD(pwd):/pwd:z <The_url_you_copied_in_step_2> cp -r /work/rhtap /pwd 1
FROM quay.io/redhat-appstudio/rhtap-task-runner:latest 1 #Copy the updated pipeline tasks COPY ./rhtap /work/rhtap 2 Example: Install additional software (for example, git) RUN microdnf -y install make 3
build -f Dockerfile -t quay.io/<namespace>/<new_image_name> 1
login quay.io Enter username and password push quay.io/<namespace>/<new_image_name> 1
image: quay.io/<namespace>/<new_image_name>
image: quay.io/<namespace>/<new_image_name>
metadata: annotations: 'quay.io/repository-slug': `<ORGANIZATION>/<REPOSITORY>'
metadata: annotations: 'jfrog-artifactory/image-name': '<IMAGE-NAME>'
{%- if "quay" in values.image %} quay.io/repository-slug: USD{{ values.repoSlug }} {%- elif "jfrog" in values.image or "artifactory" in values.image %} jfrog-artifactory/image-name: USD{{ values.imageName }}
4.7. Kernel Kernel Media support The following features are presented as Technology Previews: The latest upstream video4linux Digital video broadcasting Primarily infrared remote control device support Various webcam support fixes and improvements Package: kernel-2.6.32-554 Linux (NameSpace) Container [LXC] Linux containers provide a flexible approach to application runtime containment on bare-metal systems without the need to fully virtualize the workload. Red Hat Enterprise Linux 6 provides application level containers to separate and control the application resource usage policies via cgroups and namespaces. This release includes basic management of container life-cycle by allowing creation, editing and deletion of containers via the libvirt API and the virt-manager GUI. Linux Containers are a Technology Preview. Packages: libvirt-0.10.2-53 , virt-manager-0.9.0-29 Diagnostic pulse for the fence_ipmilan agent, BZ# 655764 A diagnostic pulse can now be issued on the IPMI interface using the fence_ipmilan agent. This new Technology Preview is used to force a kernel dump of a host if the host is configured to do so. Note that this feature is not a substitute for the off operation in a production cluster. Package: fence-agents-4.0.15-8

Commands:
18.4. Common IPTables Filtering Preventing remote attackers from accessing a LAN is one of the most important aspects of network security. The integrity of a LAN should be protected from malicious remote users through the use of stringent firewall rules. However, with a default policy set to block all incoming, outgoing, and forwarded packets, it is impossible for the firewall/gateway and internal LAN users to communicate with each other or with external resources. To allow users to perform network-related functions and to use networking applications, administrators must open certain ports for communication. For example, to allow access to port 80 on the firewall , append the following rule: This allows users to browse websites that communicate using the standard port 80. To allow access to secure websites (for example, https://www.example.com/), you also need to provide access to port 443, as follows: Important When creating an iptables ruleset, order is important. If a rule specifies that any packets from the 192.168.100.0/24 subnet be dropped, and this is followed by a rule that allows packets from 192.168.100.13 (which is within the dropped subnet), then the second rule is ignored. The rule to allow packets from 192.168.100.13 must precede the rule that drops the remainder of the subnet. To insert a rule in a specific location in an existing chain, use the -I option. For example: This rule is inserted as the first rule in the INPUT chain to allow local loopback device traffic. There may be times when you require remote access to the LAN. Secure services, for example SSH, can be used for encrypted remote connection to LAN services. Administrators with PPP-based resources (such as modem banks or bulk ISP accounts), dial-up access can be used to securely circumvent firewall barriers. Because they are direct connections, modem connections are typically behind a firewall/gateway. For remote users with broadband connections, however, special cases can be made. You can configure iptables to accept connections from remote SSH clients. For example, the following rules allow remote SSH access: These rules allow incoming and outbound access for an individual system, such as a single PC directly connected to the Internet or a firewall/gateway. However, they do not allow nodes behind the firewall/gateway to access these services. To allow LAN access to these services, you can use Network Address Translation ( NAT ) with iptables filtering rules.

Commands:
iptables -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
iptables -I INPUT 1 -i lo -p all -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j ACCEPT iptables -A OUTPUT -p tcp --sport 22 -j ACCEPT
Appendix B. Changes in Version 12.1 The following sections document features and bug fixes introduced in Red Hat Developer Toolset 12.1. B.1. Changes in GCC GCC in Red Hat Developer Toolset 12.1 has been updated to GCC 12.2.1 , which provides many bug fixes and enhancements that are available in upstream GCC . B.2. Changes in Annobin Annobin in Red Hat Developer Toolset 12.1 has been updated to Annobin 11.08 . B.3. Changes in binutils With the release of Red Hat Developer Toolset 12.1, a security update is available for binutils 2.36.1 .

Commands:
4.3. Checking Permissions from Scripts The pkcheck utility, which checks whether a process is authorized for action, now supports a new format for parameters specified by the --process option. This makes running pkcheck safer by avoiding a race condition. The new format looks as follows: USD pkcheck --process pid , start-time , uid Important Do not use the bare pid or pid,start-time formats for the --process option. All scripts that invoke pkcheck need to use the new format pid , start-time , uid to avoid a race condition. For more information, see the pkcheck (1) man page.

Commands:
Chapter 2. Configuring the Knative CLI You can customize your Knative ( kn ) CLI setup by creating a config.yaml configuration file. You can provide this configuration by using the --config flag, otherwise the configuration is picked up from a default location. The default configuration location conforms to the XDG Base Directory Specification , and is different for UNIX systems and Windows systems. For UNIX systems: If the XDG_CONFIG_HOME environment variable is set, the default configuration location that the Knative ( kn ) CLI looks for is USDXDG_CONFIG_HOME/kn . If the XDG_CONFIG_HOME environment variable is not set, the Knative ( kn ) CLI looks for the configuration in the home directory of the user at USDHOME/.config/kn/config.yaml . For Windows systems, the default Knative ( kn ) CLI configuration location is %APPDATA%\kn . Example configuration file plugins: path-lookup: true 1 directory: ~/.config/kn/plugins 2 eventing: sink-mappings: 3 - prefix: svc 4 group: core 5 version: v1 6 resource: services 7 1 Specifies whether the Knative ( kn ) CLI should look for plugins in the PATH environment variable. This is a boolean configuration option. The default value is false . 2 Specifies the directory where the Knative ( kn ) CLI looks for plugins. The default path depends on the operating system, as described previously. This can be any directory that is visible to the user. 3 The sink-mappings spec defines the Kubernetes addressable resource that is used when you use the --sink flag with a Knative ( kn ) CLI command. 4 The prefix you want to use to describe your sink. svc for a service, channel , and broker are predefined prefixes for the Knative ( kn ) CLI. 5 The API group of the Kubernetes resource. 6 The version of the Kubernetes resource. 7 The plural name of the Kubernetes resource type. For example, services or brokers .

Commands:
plugins: path-lookup: true 1 directory: ~/.config/kn/plugins 2 eventing: sink-mappings: 3 - prefix: svc 4 group: core 5 version: v1 6 resource: services 7
Chapter 1. Overview of Networking Topics 1.1. Comparing IP to non-IP Networks Network is a system of interconnected devices that can communicate sharing information and resources, such as files, printers, applications, and Internet connection. Each of these devices has a unique Internet Protocol (IP) address to send and receive messages between two or more devices using a set of rules called protocol. Categories of Network Communication IP Networks Networks that communicate through Internet Protocol addresses. An IP network is implemented in the Internet and most internal networks. Ethernet, Cable Modems, DSL Modems, dial up modems, wireless networks, and VPN connections are typical examples. non-IP Networks Networks that are used to communicate through a lower layer rather than the transport layer. Note that these networks are rarely used. InfiniBand is a non-IP network, described in Chapter 13, Configure InfiniBand and RDMA Networks .

Commands:
B.3. Glocks To understand GFS2, the most important concept to understand, and the one which sets it aside from other file systems, is the concept of glocks. In terms of the source code, a glock is a data structure that brings together the DLM and caching into a single state machine. Each glock has a 1:1 relationship with a single DLM lock, and provides caching for that lock state so that repetitive operations carried out from a single node of the file system do not have to repeatedly call the DLM, and thus they help avoid unnecessary network traffic. There are two broad categories of glocks, those which cache metadata and those which do not. The inode glocks and the resource group glocks both cache metadata, other types of glocks do not cache metadata. The inode glock is also involved in the caching of data in addition to metadata and has the most complex logic of all glocks. Table B.1. Glock Modes and DLM Lock Modes Glock mode DLM lock mode Notes UN IV/NL Unlocked (no DLM lock associated with glock or NL lock depending on I flag) SH PR Shared (protected read) lock EX EX Exclusive lock DF CW Deferred (concurrent write) used for Direct I/O and file system freeze Glocks remain in memory until either they are unlocked (at the request of another node or at the request of the VM) and there are no local users. At that point they are removed from the glock hash table and freed. When a glock is created, the DLM lock is not associated with the glock immediately. The DLM lock becomes associated with the glock upon the first request to the DLM, and if this request is successful then the 'I' (initial) flag will be set on the glock. Table B.4, "Glock flags" shows the meanings of the different glock flags. Once the DLM has been associated with the glock, the DLM lock will always remain at least at NL (Null) lock mode until the glock is to be freed. A demotion of the DLM lock from NL to unlocked is always the last operation in the life of a glock. Each glock can have a number of "holders" associated with it, each of which represents one lock request from the higher layers. System calls relating to GFS2 queue and dequeue holders from the glock to protect the critical section of code. The glock state machine is based on a work queue. For performance reasons, tasklets would be preferable; however, in the current implementation we need to submit I/O from that context which prohibits their use. Note Workqueues have their own tracepoints which can be used in combination with the GFS2 tracepoints. Table B.2, "Glock Modes and Data Types" shows what state may be cached under each of the glock modes and whether that cached state may be dirty. This applies to both inode and resource group locks, although there is no data component for the resource group locks, only metadata. Table B.2. Glock Modes and Data Types Glock mode Cache Data Cache Metadata Dirty Data Dirty Metadata UN No No No No SH Yes Yes No No DF No Yes No No EX Yes Yes Yes Yes

Commands:
3.4. Increasing the Size of an XFS File System An XFS file system may be grown while mounted using the xfs_growfs command: The -D size option grows the file system to the specified size (expressed in file system blocks). Without the -D size option, xfs_growfs will grow the file system to the maximum size supported by the device. Before growing an XFS file system with -D size , ensure that the underlying block device is of an appropriate size to hold the file system later. Use the appropriate resizing methods for the affected block device. Note While XFS file systems can be grown while mounted, their size cannot be reduced at all. For more information about growing a file system, see man xfs_growfs .

Commands:
xfs_growfs /mount/point -D size
10.8. Multi-Source Models: Stored Procedures A physical stored procedure requires the addition of a string in parameter matching the multi-source column name to specify which source the procedure is executed on. If the parameter is not present and defaults to a null value, then the procedure will be executed on each source. It is not possible to execute procedures that are required to return IN/OUT, OUT, or RETURN parameters values on more than 1 source. Example 10.1. Example DDL Example 10.2. Example Calls Against A Single Source Example 10.3. Example Calls Against All Sources

Commands:
CREATE FOREIGN PROCEDURE PROC (arg1 IN STRING NOT NULL, arg2 IN STRING, SOURCE_NAME IN STRING)
CALL PROC(arg1=>'x', SOURCE_NAME=>'sourceA') EXEC PROC('x', 'y', 'sourceB')
CALL PROC(arg1=>'x') EXEC PROC('x', 'y')
Chapter 4. Deploying an existing JWS image You can use the JWS Operator to facilitate the deployment of an existing image for a web server application that you want to deploy in an OpenShift cluster. In this situation, you must create a custom resource WebServer file for the web server application that you want to deploy. The JWS Operator uses the custom resource WebServer file to handle the application deployment. Prerequisites You have installed the JWS Operator from OperatorHub . To ensure that the JWS Operator is installed, enter the following command: The preceding command displays the name and status details of the Operator. For example: Note If you want to view more detailed output, you can use the following command: oc describe deployment.apps/jws-operator-controller-manager Procedure Prepare your image and push it to the location where you want to display the image (for example, quay.io/ <USERNAME> /tomcat-demo:latest ). To create a custom resource file for your web server application, perform the following steps: Create a YAML file named, for example, webservers_cr.yaml . Enter details in the following format: For example: To deploy your web application, perform the following steps: Go to the directory where you have created the web application. Enter the following command: The preceding command displays a message to confirm that the web application is deployed. For example: When you run the preceding command, the Operator also creates a route automatically. Verify the route that the Operator has automatically created: Optional: Delete the webserver that you created in Step 3 : Note Alternatively, you can delete the webserver by deleting the YAML file. For example: oc delete -f webservers_cr.yaml Additional resources Route configuration: Creating an HTTP-based route

Commands:
oc get deployment.apps/jws-operator-controller-manager
NAME READY UP-TO-DATE AVAILABLE AGE jws-operator 1/1 1 1 15h
apiVersion: web.servers.org/v1alpha1 kind: WebServer metadata: name: <image name> spec: # Add fields here applicationName: <application name> replicas: 2 webImage: applicationImage: <URL of the image>
apiVersion: web.servers.org/v1alpha1 kind: WebServer metadata: name: example-image-webserver spec: # Add fields here applicationName: jws-app replicas: 2 webImage: applicationImage: quay.io/<USERNAME>/tomcat-demo:latest
oc apply -f webservers_cr.yaml
webserver/example-image-webserver created
oc get routes
oc delete webserver example-image-webserver