mtpti5iD/redhat-docs_dataset huggingface dataset:
4.9. Global Transactions Global or client XA transactions allow the JBoss Data Virtualization JDBC API to participate in transactions that are beyond the scope of a single client resource. For this, use the org.teiid.jdbc.TeiidDataSource class for establishing connections. When the data source class is used in the context of a user transaction in an application server, such as JBoss, WebSphere, or Weblogic, the resulting connection will already be associated with the current XA transaction. No additional client JDBC code is necessary to interact with the XA transaction. The following code demonstrates usage of UserTransactions. The following code demonstrates manual usage of XA transactions. With the use of global transactions, multiple XAConnections may participate in the same transaction. It is important to note that the JDBC XAResource isSameRM() method only returns true if connections are made to the same server instance in a cluster. If the JBoss Data Virtualization connections are to different server instances then transactional behavior may not be the same as if they were to the same cluster member. For example, if the client transaction manager uses the same XID for each connection, duplicate XID exceptions may arise from the same physical source accessed through different cluster members. If the client transaction manager uses a different branch identifier for each connection, issues may arise with sources that lock or isolate changes based upon branch identifiers.

Commands:
UserTransaction ut = context.getUserTransaction(); try { ut.begin(); Datasource oracle = lookup(...) Datasource teiid = lookup(...) Connection c1 = oracle.getConnection(); Connection c2 = teiid.getConnection(); // do something with Oracle connection // do something with Teiid connection c1.close(); c2.close(); ut.commit(); } catch (Exception ex) { ut.rollback(); }
XAConnection xaConn = null; XAResource xaRes = null; Connection conn = null; Statement stmt = null; try { xaConn = <XADataSource instance>.getXAConnection(); xaRes = xaConn.getXAResource(); Xid xid = <new Xid instance>; conn = xaConn.getConnection(); stmt = conn.createStatement(); xaRes.start(xid, XAResource.TMNOFLAGS); stmt.executeUpdate("insert into a\u0080¦"); // other statements on this connection or other resources enlisted in this transaction // xaRes.end(xid, XAResource.TMSUCCESS); if (xaRes.prepare(xid) == XAResource.XA_OK) { xaRes.commit(xid, false); } } catch (XAException e) { xaRes.rollback(xid); } finally { // clean up code // }
Chapter 19. Using the mount Command On Linux, UNIX, and similar operating systems, file systems on different partitions and removable devices (CDs, DVDs, or USB flash drives for example) can be attached to a certain point (the mount point ) in the directory tree, and then detached again. To attach or detach a file system, use the mount or umount command respectively. This chapter describes the basic use of these commands, as well as some advanced topics, such as moving a mount point or creating shared subtrees. 19.1. Listing Currently Mounted File Systems To display all currently attached file systems, use the following command with no additional arguments: This command displays the list of known mount points. Each line provides important information about the device name, the file system type, the directory in which it is mounted, and relevant mount options in the following form: device on directory type type ( options ) The findmnt utility, which allows users to list mounted file systems in a tree-like form, is also available from Red Hat Enterprise Linux 6.1. To display all currently attached file systems, run the findmnt command with no additional arguments: 19.1.1. Specifying the File System Type By default, the output of the mount command includes various virtual file systems such as sysfs and tmpfs . To display only the devices with a certain file system type, provide the -t option: Similarly, to display only the devices with a certain file system using the findmnt command: For a list of common file system types, see Table 19.1, "Common File System Types" . For an example usage, see Example 19.1, "Listing Currently Mounted ext4 File Systems" . Example 19.1. Listing Currently Mounted ext4 File Systems Usually, both / and /boot partitions are formatted to use ext4 . To display only the mount points that use this file system, use the following command: To list such mount points using the findmnt command, type:

Commands:
mount
findmnt
mount -t type
findmnt -t type
mount -t ext4 /dev/sda2 on / type ext4 (rw) /dev/sda1 on /boot type ext4 (rw)
findmnt -t ext4 TARGET SOURCE FSTYPE OPTIONS / /dev/sda2 ext4 rw,realtime,seclabel,barrier=1,data=ordered /boot /dev/sda1 ext4 rw,realtime,seclabel,barrier=1,data=ordered
4.7. Displaying LVM Information with the lvm Command The lvm command provides several built-in options that you can use to display information about LVM support and configuration. lvm devtypes Displays the recognized built-in block device types (Red Hat Enterprise Linux release 6.6 and later). lvm formats Displays recognizes metadata formats. lvm help Displays LVM help text. lvm segtypes Displays recognized logical volume segment types. lvm tags Displays any tags defined on this host. For information on LVM object tags, see Appendix D, LVM Object Tags . lvm version Displays the current version information.

Commands:
Chapter 18. Disabling Breakpoints in a Running Context Overview You can disable and re-enable breakpoints in a running routing context in the Breakpoints view. When a breakpoint is disabled, the button causes the debugger to skip over it during the debugging session. Disabling and enabling breakpoints in Breakpoints view The Breakpoints view opens with all set breakpoints enabled. To disable a breakpoint, clear its check box. For each breakpoint you disable, the Console view displays an INFO level log entry noting that it has been disabled (for example, Removing breakpoint log2 ). Likewise, for each breakpoint you re-enable, the Console view displays an INFO level log entry noting that it has been enabled (for example, Adding breakpoint log2 ). Note To re-enable a disabled breakpoint, click its check box. The Console view displays an INFO level log entry noting that the breakpoint has been added to the selected node.

Commands:
Chapter 5. Installing a three-node cluster on AWS In OpenShift Container Platform version 4.18, you can install a three-node cluster on Amazon Web Services (AWS). 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. You can install a three-node cluster using either installer-provisioned or user-provisioned infrastructure. Note Deploying a three-node cluster using an AWS Marketplace image is not supported. 5.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 # ... If you are deploying a cluster with user-provisioned infrastructure: After you create the Kubernetes manifest files, make sure that the spec.mastersSchedulable parameter is set to true in cluster-scheduler-02-config.yml file. You can locate this file in <installation_directory>/manifests . For more information, see "Creating the Kubernetes manifest and Ignition config files" in "Installing a cluster on user-provisioned infrastructure in AWS by using CloudFormation templates". Do not create additional worker nodes. Example cluster-scheduler-02-config.yml file for a three-node cluster apiVersion: config.openshift.io/v1 kind: Scheduler metadata: creationTimestamp: null name: cluster spec: mastersSchedulable: true policy: name: "" status: {} 5.2. steps Installing a cluster on AWS with customizations Installing a cluster on user-provisioned infrastructure in AWS by using CloudFormation templates

Commands:
apiVersion: v1 baseDomain: example.com compute: - name: worker platform: {} replicas: 0
apiVersion: config.openshift.io/v1 kind: Scheduler metadata: creationTimestamp: null name: cluster spec: mastersSchedulable: true policy: name: "" status: {}
Chapter 2. Launching applications in GNOME You can launch installed applications using several different methods in the GNOME desktop environment. 2.1. Launching an application in the standard GNOME session This procedure launches a graphical application in the GNOME desktop environment. Prerequisites You are using the standard GNOME session. Procedure Open the Activities Overview screen using either of the following ways: Click Activities in the top panel. Press the Super key, which is usually labeled with the Windows logo, ⌘ , or 🔍 . Find the application using either of the following ways: Click the Show Applications icon in the bottom horizontal bar. Type the name of the required application in the search entry. Click the application in the displayed list. 2.2. Launching an application in GNOME Classic This procedure launches a graphical application in the GNOME Classic desktop environment. Prerequisites You are using the GNOME Classic session. Procedure Open the Applications menu in the top panel. Choose the required application from the available categories, which can include: Favorites Accessories Graphics Internet Office Sound & Video System Tools Utilities 2.3. Launching an application in GNOME using a command This procedure launches a graphical application in GNOME by entering a command. Prerequisites You know the command that starts the application. Procedure Open a command prompt using either of the following ways: Open a terminal. Press the Alt + F2 shortcut to open the Enter a Command screen. Type the application command in the command prompt. Confirm the command by pressing Enter . 2.4. Launching an application automatically on login You can set applications to launch automatically on login using the Tweaks tool. Tweaks is a tool to customize the GNOME Shell environment for a particular user. Prerequisites You have installed gnome-tweaks on your system. For more details, see Installing software in GNOME You have installed the application that you want to launch at login. Procedure Open Tweaks . For more details see Launching applications in GNOME . Select Startup Applications in the left side bar. Click the plus sign button ( + ). Select an application from the list of available applications and click Add . Verification Open Tweaks . Select Startup Applications in the left side bar. List of applications launched at start will be present in the center section. Additional resources For more information about lauching applications, see Launching applications in GNOME

Commands:
Chapter 6. Managing DNS by using Capsule Satellite can manage DNS records by using your Capsule. DNS management contains updating and removing DNS records from existing DNS zones. A Capsule has multiple DNS providers that you can use to integrate Satellite with your existing DNS infrastructure or deploy a new one. After you have enabled DNS, your Capsule can manipulate any DNS server that complies with RFC 2136 by using the dns_nsupdate provider. Other providers provide more direct integration, such as dns_infoblox for Infoblox . Available DNS providers dhcp_infoblox - For more information, see Chapter 7, Using Infoblox as DHCP and DNS providers . dns_nsupdate - Dynamic DNS update using nsupdate. For more information, see Section 6.1, "Configuring dns_nsupdate" . dns_nsupdate_gss - Dynamic DNS update with GSS-TSIG. For more information, see Section 4.4.1, "Configuring dynamic DNS update with GSS-TSIG authentication" . 6.1. Configuring dns_nsupdate The dns_nsupdate DNS provider manages DNS records using the nsupdate utility. You can use dns_nsupdate with any DNS server compatible with RFC2136 . By default, dns_nsupdate installs the ISC BIND server. For installation without ISC BIND, see Section 4.1, "Configuring Capsule Server with external DNS" . Procedure Configure dns_nsupdate :

Commands:
satellite-installer --foreman-proxy-dns true --foreman-proxy-dns-provider nsupdate --foreman-proxy-dns-managed true --foreman-proxy-dns-zone example.com --foreman-proxy-dns-reverse 2.0.192.in-addr.arpa
5.10. Migration The Red Hat Virtualization Manager uses migration to enforce load balancing policies for a cluster. Virtual machine migration takes place according to the load balancing policy for a cluster and current demands on hosts within a cluster. Migration can also be configured to automatically occur when a host is fenced or moved to maintenance mode. The Red Hat Virtualization Manager first migrates virtual machines with the lowest CPU utilization. This is calculated as a percentage, and does not take into account RAM usage or I/O operations, except as I/O operations affect CPU utilization. If there are more than one virtual machines with the same CPU usage, the one that will be migrated first is the first virtual machine returned by the database query run by the Red Hat Virtualization Manager to determine virtual machine CPU usage. Virtual machine migration has the following limitations by default: A bandwidth limit of 52 MiBps is imposed on each virtual machine migration. A migration will time out after 64 seconds per GB of virtual machine memory. A migration will abort if progress is stalled for 240 seconds. Concurrent outgoing migrations are limited to one per CPU core per host, or 2, whichever is smaller. See Understanding live migration "migration_max_bandwidth" and "max_outgoing_migrations" parameters in vdsm.conf for details about tuning migration settings.

Commands:
5.6. Restricting Identity Management or SSSD to Selected Active Directory Servers or Sites in a Trusted Active Directory Domain As an administrator, you can disable autodiscovery of Active Directory servers and sites in the trusted Active Directory domain and instead list servers, sites, or both manually, so that you can limit the list of Active Directory servers that SSSD communicates with. For example, this enables you to avoid contacting sites that are not accessible. 5.6.1. Configuring SSSD to Contact a Specific Active Directory Server This procedure describes manually setting Active Directory servers that SSSD connects to by editing the /etc/sssd/sssd.conf file. Considerations If your SSSD clients are directly joined to an Active Directory domain, perform this procedure on all the clients. In this setup, restricting the Active Directory domain controllers (DCs) or sites also configures the SSSD clients to connect to a particular server or site for authentication. If your SSSD clients are in an Identity Management domain that is in a trust with Active Directory, perform this procedure only on the Identity Management server. In this setup, restricting the Active Directory DCs or sites does not configure the Identity Management clients to connect to a particular server or site for authentication. Although trusted Active Directory users and groups are resolved through Identity Management servers, authentication is performed directly against the Active Directory DCs. Starting with Red Hat Enterprise Linux 7.6 and sssd-1.16.2-5.el7 , you can configure SSSD on IdM clients to use a specific AD server or site using the ad_server and ad_site options. In prior versions of Red Hat Enterprise Linux 7, restrict authentication by defining the required Active Directory DCs in the /etc/krb5.conf file on the clients. Procedure Make sure the trusted domain has a separate [domain] section in sssd.conf . The headings of trusted domain sections follow this template: For example: Edit the sssd.conf file to list the host names of the Active Directory servers or sites to which you want SSSD to connect. Use the ad_server and, optionally, ad_backup_server options for Active Directory servers. Use the ad_site option for Active Directory sites. For more details on these options, see the sssd-ad (5) man page. For example: Restart SSSD. To verify, on the SSSD client, resolve or authenticate as an Active Directory user from the configured server or site. For example: If you are unable to resolve the user or authenticate, use these steps to troubleshoot the problem: In the general [domain] section of sssd.conf , set the debug_level option to 9 . Inspect the SSSD logs at /var/log/sssd/ to see which servers SSSD contacted. Additional Resources For a list of options you can use in trusted domain sections of sssd.conf , see TRUSTED DOMAIN SECTION in the sssd.conf (5) man page.

Commands:
[domain/ main_domain / trusted_domain ]
[domain/ idm.example.com / ad.example.com ]
[domain/ idm.example.com / ad.example.com ] ad_server = dc1.ad.example.com
systemctl restart sssd.service
id ad_user @ ad.example.com
Chapter 54. File Systems Mounting a non-existent NFS export outputs a different error than in RHEL 6 The mount utility prints the operation not permitted error message when an NFS client is trying to mount a server export that does not exist. In Red Hat Enterprise Linux 6, the access denied message was printed in the same situation. (BZ#1428549) XFS disables per-inode DAX functionality Per-inode direct access (DAX) options are now disabled in the XFS file system due to unresolved issues with this feature. XFS now ignores existing per-inode DAX flags on the disk. You can still set file system DAX behavior using the dax mount option: (BZ#1623150)

Commands:
mount -o dax device mount-point
H.2. Red Hat Virtualization Manager Groups A number of system user groups are created to support Red Hat Virtualization when the rhevm package is installed. Each system user group has a default group identifier (GID). The system user groups created are: The kvm group (GID 36 ). Group members include: The vdsm user. The ovirt group (GID 108 ). Group members include: The ovirt user. The ovirt-vmconsole group (GID 498 ). Group members include: The ovirt-vmconsole user.

Commands:
5.3.5. /proc/ide/ This directory contains information about IDE devices on the system. Each IDE channel is represented as a separate directory, such as /proc/ide/ide0 and /proc/ide/ide1 . In addition, a drivers file is available, providing the version number of the various drivers used on the IDE channels: Many chipsets also provide a file in this directory with additional data concerning the drives connected through the channels. For example, a generic Intel PIIX4 Ultra 33 chipset produces the /proc/ide/piix file which reveals whether DMA or UDMA is enabled for the devices on the IDE channels: Navigating into the directory for an IDE channel, such as ide0 , provides additional information. The channel file provides the channel number, while the model identifies the bus type for the channel (such as pci ). 5.3.5.1. Device Directories Within each IDE channel directory is a device directory. The name of the device directory corresponds to the drive letter in the /dev/ directory. For instance, the first IDE drive on ide0 would be hda . Note There is a symbolic link to each of these device directories in the /proc/ide/ directory. Each device directory contains a collection of information and statistics. The contents of these directories vary according to the type of device connected. Some of the more useful files common to many devices include: cache - The device cache. capacity - The capacity of the device, in 512 byte blocks. driver - The driver and version used to control the device. geometry - The physical and logical geometry of the device. media - The type of device, such as a disk . model - The model name or number of the device. settings - A collection of current device parameters. This file usually contains quite a bit of useful, technical information. A sample settings file for a standard IDE hard disk looks similar to the following:

Commands:
ide-floppy version 0.99.newide ide-cdrom version 4.61 ide-disk version 1.18
Intel PIIX4 Ultra 33 Chipset. ------------- Primary Channel ---------------- Secondary Channel ------------- enabled enabled ------------- drive0 --------- drive1 -------- drive0 ---------- drive1 ------ DMA enabled: yes no yes no UDMA enabled: yes no no no UDMA enabled: 2 X X X UDMA DMA PIO
name value min max mode ---- ----- --- --- ---- acoustic 0 0 254 rw address 0 0 2 rw bios_cyl 38752 0 65535 rw bios_head 16 0 255 rw bios_sect 63 0 63 rw bswap 0 0 1 r current_speed 68 0 70 rw failures 0 0 65535 rw init_speed 68 0 70 rw io_32bit 0 0 3 rw keepsettings 0 0 1 rw lun 0 0 7 rw max_failures 1 0 65535 rw multcount 16 0 16 rw nice1 1 0 1 rw nowerr 0 0 1 rw number 0 0 3 rw pio_mode write-only 0 255 w unmaskirq 0 0 1 rw using_dma 1 0 1 rw wcache 1 0 1 rw
Chapter 2. Multiple Hosts 2.1. Using Multiple Hosts JBoss Data Virtualization may be clustered over several servers utilizing failover and load balancing . The easiest way to enable these features is for the client to specify multiple hostname and port number combinations in the URL connection string as a comma separated list of host:port combinations: If you are connecting with the data source class, the setAlternateServers method can be used to specify the failover servers. The format is also a comma separated list of host:port combinations. The client randomly selects one of the JBoss Data Virtualization servers from the list and establishes a session with that server. If a connection cannot be established, then each of the remaining servers will be tried in random order. This allows for both connection time failover and random server selection load balancing.

Commands:
jdbc:teiid:<vdb-name>@mm://host1:31000,host1:31001,host2:31000;version=2
2.2. Consistent Multipath Device Names in a Cluster When the user_friendly_names configuration option is set to yes , the name of the multipath device is unique to a node, but it is not guaranteed to be the same on all nodes using the multipath device. This should not cause any difficulties if you use LVM to create logical devices from the multipath device, but if you require that your multipath device names be consistent in every node in the cluster you perform one of the following procedures: Use the alias option in the multipaths section of the multipath configuration file to set the name of the multipath device. The alias for the multipath device is consistent across all the nodes in a cluster. For information on the multipaths section of the multipath configuration file, see see Section 4.4, "Multipaths Device Configuration Attributes" . If you want the system-defined user-friendly names to be consistent across all nodes in the cluster, set up all of the multipath devices on one machine. Then copy the bindings file from that machine to all the other machines in the cluster. The bindings file is located at /var/lib/multipath/bindings by default, but as of RHEL 4.6 and later you can set this value to a different location with the bindings_file parameter of the defaults section of the configuration file.

Commands: