mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 2. Supported architectures The first version of Red Hat Enterprise Linux 8 for SAP Solutions to include E4S repositories and packages for SAP was RHEL 8.0 (kernel 4.18.0-80), which provides support for the following architectures: Intel 64-bit architecture (x86_64) IBM Power, Little Endian (ppc64le) For more information, see Red Hat Enterprise Linux Technology Capabilities and Limits . Subsequent RHEL 8 versions that included E4S repositories and packages for SAP were: RHEL 8.1 (kernel 4.18.0-147) RHEL 8.2 (kernel 4.18.0-193) RHEL 8.4 (kernel 4.18.0-305) RHEL 8.6 (kernel 4.18.0-372)

Commands:
Chapter 6. New Packages 6.1. RHEA-2013:0278 - new packages: dev86 and iasl New dev86 and iasl packages are now available for Red Hat Enterprise Linux 6. The dev86 and iasl packages are build dependencies of the qemu-kvm package. This enhancement update adds the dev86 and iasl packages to the 32-bit x862 Optional channels of Red Hat Enterprise Linux 6. (BZ# 901677 , BZ# 901678 ) All users who require dev86 and iasl are advised to install these new packages.

Commands:
13.4. Save Copy of Model The Save As... action performs a similar function as the Refactor > Rename action except the renamed model is a structural copy of the original model. Note Each model object maintains its own unique ID, so copying a model will result in a exact structural copy of your original model but with regenerated unique object IDs. Be aware that locating and copying your models via your local file system may result in runtime errors within Teiid Designer . Each model is expected to be unique and duplicate models are not permitted. To create a duplicate model using Save As...: Open the model you wish to copy in a Model Editor by double-clicking the model in Model Explorer view or right-click and click Open action. Select the editor tab for the model you opened. Figure 13.4. Select Editor Tab Click File > Save As... action to open the Save Model As dialog. Figure 13.5. Save Model As Dialog Enter a unique model name in the new model name text field and click OK . If dependent models are detected, the Save Model As - Import References dialog is presented to give you the opportunity to change any of the dependent models imports to reference the new model or not. Figure 13.6. Save Model As Dialog

Commands:
1.3. DM-Multipath Components Table 1.1, "DM-Multipath Components" . describes the components of DM-Multipath. Table 1.1. DM-Multipath Components Component Description dm-multipath kernel module Reroutes I/O and supports failover for paths and path groups. multipath command Lists and configures multipath devices. Normally started up with /etc/rc.sysinit , it can also be started up by a udev program whenever a block device is added or it can be run by the initramfs file system. multipathd daemon Monitors paths; as paths fail and come back, it may initiate path group switches. Provides for interactive changes to multipath devices. This must be restarted for any changes to the /etc/multipath.conf file. kpartx command Creates device mapper devices for the partitions on a device It is necessary to use this command for DOS-based partitions with DM-MP. The kpartx is provided in its own package, but the device-mapper-multipath package depends on it.

Commands:
Chapter 16. structured Original log entry as a structured object. This field may be present if the forwarder was configured to parse structured JSON logs. If the original log entry was a valid structured log, this field will contain an equivalent JSON structure. Otherwise this field will be empty or absent, and the message field will contain the original log message. The structured field can have any subfields that are included in the log message, there are no restrictions defined here. Data type group Example value map[message:starting fluentd worker pid=21631 ppid=21618 worker=0 pid:21631 ppid:21618 worker:0]

Commands:
8.56. gnome-screensaver 8.56.1. RHBA-2013:1706 - gnome-screensaver bug fix update Updated gnome-screensaver packages that fix two bugs are now available for Red Hat Enterprise Linux 6. The gnome-screensaver packages contain the GNOME project's official screen saver program. The screen saver is designed for improved integration with the GNOME desktop, including themeability, language support, and Human Interface Guidelines (HIG) compliance. It also provides screen-locking and fast user-switching from a locked screen. Bug Fixes BZ# 905935 Previously, when using the virt-manager, virt-viewer, and spice-xpi applications, users were unable to enter the gnome-screensaver password after the screen saver had started. This occurred only when the virtual machine system used the Compiz composting window manager. After users had released the mouse cursor, then pressed a key to enter the password, the dialog window did not accept any input. This happened due to incorrect assignment of window focus to applications that did not drop their keyboard grab. With this update, window focus is now properly assigned to the correct place, and attempts to enter the gnome-screensaver password no longer fail in the described scenario. BZ# 947671 Prior to this update, the gnome-screensaver utility worked incorrectly when using an X server that does not support the fade-out function. Consequently, gnome-screensaver terminated unexpectedly when trying to fade out the monitor. This bug has been fixed and gnome-screensaver now detects a potential fade-out failure and recovers instead of crashing. Users of gnome-screensaver are advised to upgrade to these updated packages, which fix these bugs.

Commands:
Chapter 5. Networking This chapter covers network optimization topics for virtualized environments. 5.1. Networking Tuning Tips Use multiple networks to avoid congestion on a single network. For example, have dedicated networks for management, backups, or live migration. Red Hat recommends not using multiple interfaces in the same network segment. However, if this is unavoidable, you can use arp_filter to prevent ARP Flux, an undesirable condition that can occur in both hosts and guests and is caused by the machine responding to ARP requests from more than one network interface: echo 1 > /proc/sys/net/ipv4/conf/all/arp_filter or edit /etc/sysctl.conf to make this setting persistent. Note For more information on ARP Flux, see http://linux-ip.net/html/ether-arp.html#ether-arp-flux

Commands:
11.4. Preparing and Adding POSIX-compliant File System Storage 11.4.1. Preparing POSIX-compliant File System Storage POSIX file system support allows you to mount file systems using the same mount options that you would normally use when mounting them manually from the command line. This functionality is intended to allow access to storage not exposed using NFS, iSCSI, or FCP. Any POSIX-compliant file system used as a storage domain in Red Hat Virtualization must be a clustered file system, such as Global File System 2 (GFS2), and must support sparse files and direct I/O. The Common Internet File System (CIFS), for example, does not support direct I/O, making it incompatible with Red Hat Virtualization. For information on setting up and configuring POSIX-compliant file system storage, see Red Hat Enterprise Linux Global File System 2 . Important Do not mount NFS storage by creating a POSIX-compliant file system storage domain. Always create an NFS storage domain instead. 11.4.2. Adding POSIX-compliant File System Storage This procedure shows you how to attach existing POSIX-compliant file system storage to your Red Hat Virtualization environment as a data domain. Procedure Click Storage Domains . Click New Domain . Enter the Name for the storage domain. Select the Data Center to be associated with the storage domain. The data center selected must be of type POSIX (POSIX compliant FS) . Alternatively, select (none) . Select Data from the Domain Function drop-down list, and POSIX compliant FS from the Storage Type drop-down list. If applicable, select the Format from the drop-down menu. Select a host from the Host drop-down list. Enter the Path to the POSIX file system, as you would normally provide it to the mount command. Enter the VFS Type , as you would normally provide it to the mount command using the -t argument. See man mount for a list of valid VFS types. Enter additional Mount Options , as you would normally provide them to the mount command using the -o argument. The mount options should be provided in a comma-separated list. See man mount for a list of valid mount options. Optionally, you can configure the advanced parameters. Click Advanced Parameters . Enter a percentage value in the Warning Low Space Indicator field. If the free space available on the storage domain is below this percentage, warning messages are displayed to the user and logged. Enter a GB value in the Critical Space Action Blocker field. If the free space available on the storage domain is below this value, error messages are displayed to the user and logged, and any new action that consumes space, even temporarily, will be blocked. Select the Wipe After Delete check box to enable the wipe after delete option. This option can be edited after the domain is created, but doing so will not change the wipe after delete property of disks that already exist. Click OK .

Commands:
Chapter 2. Supported Configurations For information on supported configurations, see Red Hat AMQ Broker 7 Supported Configurations . Minimum Java version At a minimum, AMQ Broker 7.12 requires Java version 11 to run. Openwire support AMQ 7 Broker has provided support for the Openwire protocol since its release in 2017 as a means to migrate client applications to AMQ 7. With the release of AMQ Broker 7.9.0 in 2021, the Openwire protocol was deprecated and customers were encouraged to migrate their existing Openwire client applications to one of the fully supported protocols of AMQ 7 (CORE, AMQP, MQTT, or STOMP). Starting with the AMQ Broker 8.0 release, the Openwire protocol will be removed from AMQ Broker.

Commands:
15.5.7. Logging Options The following lists directives which affect vsftpd 's logging behavior. dual_log_enable - When enabled in conjunction with xferlog_enable , vsftpd writes two files simultaneously: a wu-ftpd -compatible log to the file specified in the xferlog_file directive ( /var/log/xferlog by default) and a standard vsftpd log file specified in the vsftpd_log_file directive ( /var/log/vsftpd.log by default). The default value is NO . log_ftp_protocol - When enabled in conjunction with xferlog_enable and with xferlog_std_format set to NO , all FTP commands and responses are logged. This directive is useful for debugging. The default value is NO . syslog_enable - When enabled in conjunction with xferlog_enable , all logging normally written to the standard vsftpd log file specified in the vsftpd_log_file directive ( /var/log/vsftpd.log by default) is sent to the system logger instead under the FTPD facility. The default value is NO . vsftpd_log_file - Specifies the vsftpd log file. For this file to be used, xferlog_enable must be enabled and xferlog_std_format must either be set to NO or, if xferlog_std_format is set to YES , dual_log_enable must be enabled. It is important to note that if syslog_enable is set to YES , the system log is used instead of the file specified in this directive. The default value is /var/log/vsftpd.log . xferlog_enable - When enabled, vsftpd logs connections ( vsftpd format only) and file transfer information to the log file specified in the vsftpd_log_file directive ( /var/log/vsftpd.log by default). If xferlog_std_format is set to YES , file transfer information is logged but connections are not, and the log file specified in xferlog_file ( /var/log/xferlog by default) is used instead. It is important to note that both log files and log formats are used if dual_log_enable is set to YES . The default value is NO . Note, in Red Hat Enterprise Linux, the value is set to YES . xferlog_file - Specifies the wu-ftpd -compatible log file. For this file to be used, xferlog_enable must be enabled and xferlog_std_format must be set to YES . It is also used if dual_log_enable is set to YES . The default value is /var/log/xferlog . xferlog_std_format - When enabled in conjunction with xferlog_enable , only a wu-ftpd -compatible file transfer log is written to the file specified in the xferlog_file directive ( /var/log/xferlog by default). It is important to note that this file only logs file transfers and does not log connections to the server. The default value is NO . Note, in Red Hat Enterprise Linux, the value is set to YES . Important To maintain compatibility with log files written by the older wu-ftpd FTP server, the xferlog_std_format directive is set to YES under Red Hat Enterprise Linux. However, this setting means that connections to the server are not logged. To both log connections in vsftpd format and maintain a wu-ftpd -compatible file transfer log, set dual_log_enable to YES . If maintaining a wu-ftpd -compatible file transfer log is not important, either set xferlog_std_format to NO , comment the line with a hash mark ( # ), or delete the line entirely.

Commands:
Chapter 4. Installing a three-node cluster on Nutanix In OpenShift Container Platform version 4.14, you can install a three-node cluster on Nutanix. A three-node cluster consists of three control plane machines, which also act as compute machines. This type of cluster provides a smaller, more resource efficient cluster, for cluster administrators and developers to use for testing, development, and production. 4.1. Configuring a three-node cluster You configure a three-node cluster by setting the number of worker nodes to 0 in the install-config.yaml file before deploying the cluster. Setting the number of worker nodes to 0 ensures that the control plane machines are schedulable. This allows application workloads to be scheduled to run from the control plane nodes. Note Because application workloads run from control plane nodes, additional subscriptions are required, as the control plane nodes are considered to be compute nodes. Prerequisites You have an existing install-config.yaml file. Procedure Set the number of compute replicas to 0 in your install-config.yaml file, as shown in the following compute stanza: Example install-config.yaml file for a three-node cluster apiVersion: v1 baseDomain: example.com compute: - name: worker platform: {} replicas: 0 # ... 4.2. steps Installing a cluster on Nutanix

Commands:
apiVersion: v1 baseDomain: example.com compute: - name: worker platform: {} replicas: 0
Chapter 4. Managing rules The MTA plugin comes with a core set of System rules for analyzing projects and identifying migration and modernization issues. You can create and import custom rulesets. 4.1. Viewing rules You can view system and custom rules, if any, for the MTA plugin. Prerequisites To view system rules, the MTA server must be running. Procedure Click the Rulesets tab. Expand System to view system rulesets or Custom to view custom rulesets. Expand a ruleset. Double-click a rule to open it in a viewer. Click the Source tab to view the XML source of the rule. 4.2. Creating a custom ruleset You can create a custom ruleset in the MTA perspective. See the Rule Development Guide to learn more about creating custom XML rules. Procedure Click the Rulesets tab. Click the Create Ruleset icon ( ). Select a project and a directory for the ruleset. Enter the file name. Note The file must have the extension .windup.xml . Enter a ruleset ID, for example, my-ruleset-id . Optional: Select Generate quickstart template to add basic rule templates to the file. Click Finish . The ruleset file opens in an editor and you can add and edit rules in the file. Click the Source tab to edit the XML source of the ruleset file. You can select the new ruleset when you create a run configuration. 4.3. Importing a custom ruleset You can import a custom ruleset into the MTA plugin to analyze your projects. Prerequisites Custom ruleset file with a .windup.xml extension. See the Rule Development Guide for information about creating rulesets. Procedure Click the Rulesets tab. Click the Import Ruleset icon ( ). Browse to and select the XML rule file to import. The custom ruleset is displayed when you expand Custom on the Rulesets tab. 4.4. Submitting a custom ruleset You can submit your custom ruleset for inclusion in the official MTA rule repository. This allows your custom rules to be reviewed and included in subsequent releases of MTA. Procedure Click the Rulesets tab. Click the Arrow icon ( ) and select Submit Ruleset . Complete the following fields: Summary : Describe the purpose of the rule. This becomes the title of the submission. Code Sample : Enter an example of the source code that the rule should run against. Description : Enter a brief description of the rule. Click Choose Files and select the ruleset file. Click Submit .

Commands:
Chapter 15. Configuring the loopback interface by using nmcli By default, NetworkManager does not manage the loopback ( lo ) interface. After creating a connection profile for the lo interface, you can configure this device by using NetworkManager. Some of the examples are as follows: Assign additional IP addresses to the lo interface Define DNS addresses Change the Maximum Transmission Unit (MTU) size of the lo interface Procedure Create a new connection of type loopback : Configure custom connection settings, for example: To assign an additional IP address to the interface, enter: Note NetworkManager manages the lo interface by always assigning the IP addresses 127.0.0.1 and ::1 that are persistent across the reboots. You can not override 127.0.0.1 and ::1 . However, you can assign additional IP addresses to the interface. To set a custom Maximum Transmission Unit (MTU), enter: To set an IP address to your DNS server, enter: If you set a DNS server in the loopback connection profile, this entry is always available in the /etc/resolv.conf file. The DNS server entry remains independent of whether or not the host roams between different networks. Activate the connection: Verification Display the settings of the lo interface: Verify the DNS address:

Commands:
nmcli connection add con-name example-loopback type loopback
nmcli connection modify example-loopback +ipv4.addresses 192.0.2.1/24
nmcli con mod example-loopback loopback.mtu 16384
nmcli connection modify example-loopback ipv4.dns 192.0.2.0
nmcli connection up example-loopback
ip address show lo 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16384 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet 192.0.2.1/24 brd 192.0.2.255 scope global lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever
cat /etc/resolv.conf nameserver 192.0.2.0
6.4. Setting up Active Directory for Synchronization Synchronizing user accounts is enabled within IdM. It is only necessary to set up a synchronization agreement ( Section 6.5.1, "Creating Synchronization Agreements" ). However, the Active Directory does need to be configured in a way that allows the Identity Management server to connect to it. 6.4.1. Creating an Active Directory User for Synchronization On the Windows server, it is necessary to create the user that the IdM server will use to connect to the Active Directory domain. The process for creating a user in Active Directory is covered in the Windows server documentation at http://technet.microsoft.com/en-us/library/cc732336.aspx . The new user account must have the proper permissions: Grant the synchronization user account Replicating directory changes rights to the synchronized Active Directory subtree. Replicator rights are required for the synchronization user to perform synchronization operations. Replicator rights are described in http://support.microsoft.com/kb/303972 . Add the synchronization user as a member of the Account Operators and Enterprise Read-only Domain Controllers groups. It is not necessary for the user to belong to the Domain Admins group. 6.4.2. Setting up an Active Directory Certificate Authority The Identity Management server connects to the Active Directory server using a secure connection. This requires that the Active Directory server have an available CA certificate or CA certificate chain available, which can be imported into the Identity Management security databases, so that the Windows server is a trusted peer. While this could technically be done with an external (to Active Directory) CA, most deployments should use the Certificate Services available with Active Directory. The procedure for setting up and configuring certificate services on Active Directory is covered in the Microsoft documentation at http://technet.microsoft.com/en-us/library/cc772393(v=WS.10).aspx .

Commands:
C.10. References For more information about tracepoints and the GFS2 glocks file, see the following resources: For information on glock internal locking rules, see http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/filesystems/gfs2-glocks.txt;h=0494f78d87e40c225eb1dc1a1489acd891210761;hb=HEAD . For information on event tracing, see http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/trace/events.txt;h=09bd8e9029892e4e1d48078de4d076e24eff3dd2;hb=HEAD . For information on the trace-cmd utility, see http://lwn.net/Articles/341902/ .

Commands:
Chapter 2. Overview of installing and deploying OpenShift AI Red Hat OpenShift AI is a platform for data scientists and developers of artificial intelligence (AI) applications. It provides a fully supported environment that lets you rapidly develop, train, test, and deploy machine learning models on-premises and/or in the public cloud. OpenShift AI is provided as a managed cloud service add-on for Red Hat OpenShift or as self-managed software that you can install on-premise or in the public cloud on OpenShift. For information about installing OpenShift AI as self-managed software on your OpenShift cluster in a connected or a disconnected environment, see Product Documentation for Red Hat OpenShift AI Self-Managed . There are two deployment options for Red Hat OpenShift AI as a managed cloud service add-on: OpenShift Dedicated with a Customer Cloud Subscription on Amazon Web Services or Google Cloud Platform OpenShift Dedicated is a complete OpenShift Container Platform cluster provided as a cloud service, configured for high availability, and dedicated to a single customer. OpenShift Dedicated is professionally managed by Red Hat and hosted on Amazon Web Services (AWS) or Google Cloud Platform (GCP). The Customer Cloud Subscription (CCS) model allows Red Hat to deploy and manage clusters into a customer's AWS or GCP account. Contact your Red Hat account manager to get OpenShift Dedicated through a CCS. Red Hat OpenShift Service on AWS (ROSA) ROSA is a fully-managed, turnkey application platform that allows you to focus on delivering value to your customers by building and deploying applications. You subscribe to the service directly from your AWS account. Installing OpenShift AI as a managed cloud service involves the following high-level tasks: Confirm that your OpenShift cluster meets all requirements. Configure an identity provider for your OpenShift cluster. Add administrative users for your OpenShift cluster. Subscribe to the Red Hat OpenShift Data Science Add-on. For OpenShift Dedicated with a CCS for AWS or GCP, get a subscription through Red Hat. For ROSA, get a subscription through the AWS Marketplace. Install the OpenShift Data Science Add-on. Access the OpenShift AI dashboard. Optionally, enable graphics processing units (GPUs) in OpenShift AI to ensure that your data scientists can use compute-heavy workloads in their models.

Commands: