mtpti5iD/redhat-docs_dataset huggingface dataset:
8.3. Comparison of Network Teaming to Bonding Table 8.1. A Comparison of Features in Bonding and Team Feature Bonding Team broadcast Tx policy Yes Yes round-robin Tx policy Yes Yes active-backup Tx policy Yes Yes LACP (802.3ad) support Yes (active only) Yes Hash-based Tx policy Yes Yes User can set hash function No Yes Tx load-balancing support (TLB) Yes Yes LACP hash port select Yes Yes load-balancing for LACP support No Yes Ethtool link monitoring Yes Yes ARP link monitoring Yes Yes NS/NA (IPv6) link monitoring No Yes ports up/down delays Yes Yes port priorities and stickiness ( " primary " option enhancement) No Yes separate per-port link monitoring setup No Yes multiple link monitoring setup Limited Yes lockless Tx/Rx path No (rwlock) Yes (RCU) VLAN support Yes Yes user-space runtime control Limited Full Logic in user-space No Yes Extensibility Hard Easy Modular design No Yes Performance overhead Low Very Low D-Bus interface No Yes multiple device stacking Yes Yes zero config using LLDP No (in planning) NetworkManager support Yes Yes

Commands:
21.3.3. Adding a Local Printer Follow this procedure to add a local printer connected with other than a serial port: Open the New Printer dialog (see Section 21.3.2, "Starting Printer Setup" ). If the device does not appear automatically, select the port to which the printer is connected in the list on the left (such as Serial Port #1 or LPT #1 ). On the right, enter the connection properties: for Other URI (for example file:/dev/lp0) for Serial Port Baud Rate Parity Data Bits Flow Control Figure 21.4. Adding a local printer Click Forward . Select the printer model. See Section 21.3.8, "Selecting the Printer Model and Finishing" for details.

Commands:
Part II. File Systems File system refers to the files and directories stored on a computer. A file system can have different formats called file system types . These formats determine how the information is stored as files and directories. Some file system types store redundant copies of the data, while some file system types make hard drive access faster. This part discusses the ext3, swap, RAID, and LVM file system types. It also discusses the parted utility to manage partitions and access control lists (ACLs) to customize file permissions.

Commands:
Chapter 2. Configuring the model registry component To configure the model registry feature for your data scientists to use in OpenShift AI, you must install the following Operators in OpenShift, install Red Hat OpenShift AI as an add-on to your OpenShift cluster, and then enable the modelregistry component in OpenShift AI. Red Hat Authorino Operator (Technical Preview) Red Hat OpenShift Serverless Operator Red Hat OpenShift Service Mesh Operator Important You should install the Red Hat OpenShift AI Add-on only after the listed Operators are installed and in a running state. For more information about installing Operators in OpenShift, see Adding Operators to a cluster . For more information about installing the Red Hat OpenShift AI Add-on, see Installing OpenShift AI on your OpenShift cluster . After you install the Operators and the Red Hat OpenShift AI Add-on, you can use the following steps to enable the modelregistry component. Prerequisites You have cluster administrator privileges for your OpenShift cluster. You have access to the data science cluster. You have installed Red Hat OpenShift AI as an add-on to your OpenShift cluster. You have installed the Red Hat Authorino, Red Hat OpenShift Serverless, Red Hat OpenShift Service Mesh, and Red Hat OpenShift AI Operators. You have sufficient resources. For more information about the minimum resources required to use OpenShift AI, see Installing and deploying OpenShift AI . Procedure In the OpenShift console, click Operators Installed Operators . Search for the Red Hat OpenShift AI Operator version 2.14+, and then click the Operator name to open the Operator details page. Click the Data Science Cluster tab. Click the default instance name (for example, default-dsc ) to open the instance details page. Click the YAML tab to show the instance specifications. Find the spec.components section, and then add or update it to include the following modelregistry component entry, with the managementState field set to Managed , and the registriesNamespace field set to rhoai-model-registries : Click Save . Verification Confirm that the model registry namespace was created successfully: In the OpenShift console, click Home Projects . Confirm that the rhoai-model-registries namespace appears in the Projects drop-down list. Check the status of the model-registry-operator-controller-manager pod: In the OpenShift console, from the Project list, select redhat-ods-applications . Click Workloads Deployments . Search for the model-registry-operator-controller-manager deployment. Check the status: Click the deployment name to open the deployment details page. Click the Pods tab. View the pod status. When the status of the model-registry-operator-controller-manager- <pod-id> pod is Running , the pod is ready to use. step OpenShift AI administrators can create, delete, and manage permissions for model registries. For more information, see Managing model registries .

Commands:
modelregistry: managementState: Managed registriesNamespace: rhoai-model-registries
Chapter 1. Preface This document provides an overview of differences between two major versions of Red Hat Enterprise Linux: RHEL 7 and RHEL 8. It provides a list of changes relevant for evaluating an upgrade to RHEL 8 rather than an exhaustive list of all alterations. Capabilities and limits of RHEL 8 as compared to other versions of the system are available in the Knowledgebase article Red Hat Enterprise Linux technology capabilities and limits . Information regarding the RHEL life cycle is provided in the Red Hat Enterprise Linux Life Cycle document. The Package manifest document provides a package listing for RHEL 8. For details regarding RHEL 8 usage, see the RHEL 8 product documentation . For guidance regarding an in-place upgrade from RHEL 7 to RHEL 8, see Upgrading from RHEL 7 to RHEL 8 . For information about major differences between RHEL 6 and RHEL 7, see the RHEL 7 Migration Planning Guide .

Commands:
18.2.3. Trusted Services Enabling options in the Trusted services list allows the specified service to pass through the firewall. WWW (HTTP) The HTTP protocol is used by Apache (and by other Web servers) to serve web pages. If you plan on making your Web server publicly available, select this check box. This option is not required for viewing pages locally or for developing web pages. This service requires that the httpd package be installed. Enabling WWW (HTTP) will not open a port for HTTPS, the SSL version of HTTP. If this service is required, select the Secure WWW (HTTPS) check box. FTP The FTP protocol is used to transfer files between machines on a network. If you plan on making your FTP server publicly available, select this check box. This service requires that the vsftpd package be installed. SSH Secure Shell (SSH) is a suite of tools for logging into and executing commands on a remote machine. To allow remote access to the machine via ssh, select this check box. This service requires that the openssh-server package be installed. Telnet Telnet is a protocol for logging into remote machines. Telnet communications are unencrypted and provide no security from network snooping. Allowing incoming Telnet access is not recommended. To allow remote access to the machine via telnet, select this check box. This service requires that the telnet-server package be installed. Mail (SMTP) SMTP is a protocol that allows remote hosts to connect directly to your machine to deliver mail. You do not need to enable this service if you collect your mail from your ISP's server using POP3 or IMAP, or if you use a tool such as fetchmail . To allow delivery of mail to your machine, select this check box. Note that an improperly configured SMTP server can allow remote machines to use your server to send spam. NFS4 The Network File System (NFS) is a file sharing protocol commonly used on *NIX systems. Version 4 of this protocol is more secure than its predecessors. If you want to share files or directories on your system with other network users, select this check box. Samba Samba is an implementation of Microsoft's proprietary SMB networking protocol. If you need to share files, directories, or locally-connected printers with Microsoft Windows machines, select this check box.

Commands:
Appendix F. Boot Process, Init, and Shutdown An important and powerful aspect of Red Hat Enterprise Linux is the open, user-configurable method it uses for starting the operating system. Users are free to configure many aspects of the boot process, including specifying the programs launched at boot-time. Similarly, system shutdown gracefully terminates processes in an organized and configurable way, although customization of this process is rarely required. Understanding how the boot and shutdown processes work not only allows customization, but also makes it easier to troubleshoot problems related to starting or shutting down the system. F.1. The Boot Process Below are the basic stages of the boot process: The system loads and runs a boot loader. The specifics of this process depend on the system architecture. For example: BIOS-based x86 systems run a first-stage boot loader from the MBR of the primary hard disk that, in turn, loads an additional boot loader, GRUB . UEFI-based x86 systems mount an EFI System Partition that contains a version of the GRUB boot loader. The EFI boot manager loads and runs GRUB as an EFI application. Power Systems servers mount a PPC PReP partition that contains the Yaboot boot loader. The System Management Services (SMS) boot manager loads and runs yaboot . IBM System z runs the z/IPL boot loader from a DASD or FCP-connected device that you specify when you IPL the partition that contains Red Hat Enterprise Linux. The boot loader loads the kernel into memory, which in turn loads any necessary modules and mounts the root partition read-only. The kernel transfers control of the boot process to the /sbin/init program. The /sbin/init program loads all services and user-space tools, and mounts all partitions listed in /etc/fstab . The user is presented with a login screen for the freshly booted Linux system. Because configuration of the boot process is more common than the customization of the shutdown process, the remainder of this chapter discusses in detail how the boot process works and how it can be customized to suite specific needs.

Commands:
4.6. Personal Firewalls Once the necessary network services are configured, it is important to implement a firewall. Firewalls prevent network packets from accessing the system's network interface. If a request is made to a port that is blocked by a firewall, the request is ignored. If a service is listening on one of these blocked ports, it does not receive the packets and is effectively disabled. For this reason, care should be taken when configuring a firewall to block access to ports not in use, while not blocking access to ports used by configured services. For most users, the best tool for configuring a simple firewall is the straight-forward, graphical firewall configuration tool which ships with Red Hat Enterprise Linux: the Security Level Configuration Tool ( system-config-securitylevel ). This tool creates broad iptables rules for a general-purpose firewall using a control panel interface. For more information about using this application and the options it offers, refer to the chapter titled Basic Firewall Configuration in the System Administrators Guide . For advanced users and server administrators, manually configuring a firewall with iptables is likely the best option. Refer to Chapter 7, Firewalls for more information. For a comprehensive guide to the iptables command, consult the chapter titled iptables in the Reference Guide .

Commands:
25.7.4. Using RELP Reliable Event Logging Protocol (RELP) is a networking protocol for data logging in computer networks. It is designed to provide reliable delivery of event messages, which makes it useful in environments where message loss is not acceptable. To configure RELP, first install the rsyslog-relp package both on the server and the client: Then, configure both the server and the client. To configure the client, configure: loading the required modules the TCP input port the transport settings by adding the following configuration to the /etc/rsyslog.conf file: Replace port to start a listener at the required port. Replace target_IP and target_port with the IP address and port that identify the target server. To configure the server: configure loading the modules configure the TCP input similarly to the client configuration configure the rules and choose an action to be performed by adding the following configuration to the /etc/rsyslog.conf file: Replace target_port with the same value as on the clients. In the example, log_path specifies the path for storing messages.

Commands:
~]# yum install rsyslog-relp
USDModLoad omrelp USDModLoad imuxsock USDModLoad imtcp USDInputTCPServerRun " port " *.* :omrelp:" target_IP ":" target_port "
USDModLoad imuxsock USDModLoad imrelp USDRuleSet relp *.* " log_path " USDInputRELPServerBindRuleset relp USDInputRELPServerRun " target_port "
14.10.4. Displaying Guest Virtual Machine Information Using virsh with the guest virtual machine's domain ID, domain name or UUID you can display information on the specified guest virtual machine: This is an example of virsh dominfo output:

Commands:
virsh dominfo {domain-id, domain-name or domain-uuid}
virsh dominfo vr-rhel6u1-x86_64-kvm Id: 9 Name: vr-rhel6u1-x86_64-kvm UUID: a03093a1-5da6-a2a2-3baf-a845db2f10b9 OS Type: hvm State: running CPU(s): 1 CPU time: 21.6s Max memory: 2097152 kB Used memory: 1025000 kB Persistent: yes Autostart: disable Security model: selinux Security DOI: 0 Security label: system_u:system_r:svirt_t:s0:c612,c921 (permissive)
Chapter 1. About Red Hat OpenShift Dev Spaces Red Hat OpenShift Dev Spaces provides web-based development environments on Red Hat OpenShift with an enterprise-level setup: Cloud Development Environments (CDE) server IDEs such as Microsoft Visual Studio Code - Open Source, JetBrains IntelliJ IDEA Community and desktop IntelliJ IDEA Ultimate, PyCharm, WebStorm, RubyMine, and CLion editors as a Technology Preview . Containerized environments with popular programming languages, frameworks, and Red Hat technologies Red Hat OpenShift Dev Spaces is well-suited for container-based development. Red Hat OpenShift Dev Spaces 3.19 is based on Eclipse Che 7.98. 1.1. Supported platforms OpenShift Dev Spaces runs on OpenShift 4.14-4.18 on the following CPU architectures: AMD64 and Intel 64 ( x86_64 ) IBM Z ( s390x ) IBM Power ( ppc64le ) Additional resources OpenShift Documentation Red Hat OpenShift Dev Spaces administration guide 1.2. Support policy For Red Hat OpenShift Dev Spaces 3.19, Red Hat will provide support for deployment, configuration, and use of the product. Additional resources OpenShift Dev Spaces life-cycle and support policy . 1.3. Differences between Red Hat OpenShift Dev Spaces and Eclipse Che There are some differences between Red Hat OpenShift Dev Spaces and the upstream project on which it is based, Eclipse Che: OpenShift Dev Spaces is supported only on Red Hat OpenShift. OpenShift Dev Spaces is based on Red Hat Enterprise Linux and is regularly updated to include the latest security fixes. OpenShift Dev Spaces provides getting-started samples supported in the air-gap mode with languages and technologies such as Quarkus, Lombok, NodeJS, Python, DotNet, Golang, and C/C++. Community samples are available at the Devfile registry page . OpenShift Dev Spaces uses OpenShift OAuth for user login and management. Red Hat provides licensing and packaging to ensure enterprise-level support for OpenShift Dev Spaces.

Commands:
Chapter 9. Uninstalling metering Important Metering is a deprecated feature. Deprecated functionality is still included in OpenShift Container Platform and continues to be supported; however, it will be removed in a future release of this product and is not recommended for new deployments. For the most recent list of major functionality that has been deprecated or removed within OpenShift Container Platform, refer to the Deprecated and removed features section of the OpenShift Container Platform release notes. You can remove metering from your OpenShift Container Platform cluster. Note Metering does not manage or delete Amazon S3 bucket data. After uninstalling metering, you must manually clean up S3 buckets that were used to store metering data. 9.1. Removing the Metering Operator from your cluster Remove the Metering Operator from your cluster by following the documentation on deleting Operators from a cluster . Note Removing the Metering Operator from your cluster does not remove its custom resource definitions or managed resources. See the following sections on Uninstalling a metering namespace and Uninstalling metering custom resource definitions for steps to remove any remaining metering components. 9.2. Uninstalling a metering namespace Uninstall your metering namespace, for example the openshift-metering namespace, by removing the MeteringConfig resource and deleting the openshift-metering namespace. Prerequisites The Metering Operator is removed from your cluster. Procedure Remove all resources created by the Metering Operator: USD oc --namespace openshift-metering delete meteringconfig --all After the step is complete, verify that all pods in the openshift-metering namespace are deleted or are reporting a terminating state: USD oc --namespace openshift-metering get pods Delete the openshift-metering namespace: USD oc delete namespace openshift-metering 9.3. Uninstalling metering custom resource definitions The metering custom resource definitions (CRDs) remain in the cluster after the Metering Operator is uninstalled and the openshift-metering namespace is deleted. Important Deleting the metering CRDs disrupts any additional metering installations in other namespaces in your cluster. Ensure that there are no other metering installations before proceeding. Prerequisites The MeteringConfig custom resource in the openshift-metering namespace is deleted. The openshift-metering namespace is deleted. Procedure Delete the remaining metering CRDs: USD oc get crd -o name | grep "metering.openshift.io" | xargs oc delete

Commands:
oc --namespace openshift-metering delete meteringconfig --all
oc --namespace openshift-metering get pods
oc delete namespace openshift-metering
oc get crd -o name | grep "metering.openshift.io" | xargs oc delete
7.236. xorg-x11-drv-qxl 7.236.1. RHBA-2015:1399 - xorg-x11-drv-qxl bug fix update Updated xorg-x11-drv-qxl packages that fix several bugs are now available for Red Hat Enterprise Linux 6. The xorg-x11-drv-qxl package provides an X11 video driver for QEMU QXL video accelerator. This driver makes it possible to use Red Hat Enterprise Linux 6 as a guest operating system under the KVM kernel module and the QEMU multiplatform emulator, using the Simple Protocol for Computing Environments (SPICE). Bug Fixes BZ# 1098647 Previously, the X.org process could become unresponsive after switching to a virtual terminal (VT) and back to a GNOME session with multi-monitor session, meaning 4 monitors opened, or two monitors with a higher resolution, over 1920x1080. A patch has been applied to fix this bug, and X.org no longer hangs in the described scenario. BZ# 1192154 Due to a memory leak in the QXL driver, an X.Org guest could become unresponsive. This update fixes the memory leak, and X.Org no longer crashes. BZ# 1199355 Due to a memory leak in the cursor handling code of the QXL guest driver, the video memory would get saturated and caused a corrupted display when the Anaconda installer was formatting a very large disk (over 2TB). A patch has been applied to prevent cursor data from leaking. As a result, display corruption no longer occurs. BZ# 1151559 Previously, the QXL driver did not correctly handle unexpected drawing commands. As a consequence, the display became unresponsive after entering a space character in the Xfig application. This update fixes the bug in the QXL driver, and Xfig no longer becomes unresponsive in the described situation. Users of xorg-x11-drv-qxl are advised to upgrade to these updated packages, which fix these bugs.

Commands:
23.19. Installation Complete Congratulations! Your Red Hat Enterprise Linux installation is now complete! The installation program prompts you to prepare your system for reboot. The installation program automatically reboots into the installed system. Should the installation program not reboot, the installation program shows information from which device to do an IPL (boot). Accept the shutdown option and after shutdown, IPL from the DASD or SCSI LUN where the /boot partition for Red Hat Enterprise Linux has been installed. 23.19.1. IPL Under z/VM To IPL from a DASD, for example using the DASD device 200 on the 3270 console, issue the command: In DASD only environments where automatic partitioning (clearing data from all partitions) was used, the first activated DASD is where the /boot partition is typically located. Using /boot on an FCP LUN, you must provide the WWPN and LUN for the FCP-attached device from which to IPL. To IPL from an FCP-attached device: Provide FCP routing information to an FCP-attached device, for example, where 0x50050763050B073D is the WWPN, and 0x4020400100000000 is the FCP LUN: IPL the FCP adapter, for example FC00 : Note To disconnect from the 3270 terminal without stopping the Linux running in your virtual machine, use #cp disconnect instead of #cp logoff . When your virtual machine is re-connected using the usual logon procedure, it might be placed in CP console function mode ( CP READ ). If so, to resume execution on your virtual machine, enter the BEGIN command.

Commands:
#cp i 200
#cp set loaddev portname50050763 050B073D lun 40204001 00000000
#cp ipl FC00