mtpti5iD/redhat-docs_dataset huggingface dataset:
7.64. gdm 7.64.1. RHBA-2013:0381 - gdm bug fix and enhancement update Updated gdm packages that fix four bugs and add two enhancements are now available for Red Hat Enterprise Linux 6. The gdm packages provide the GNOME Display Manager (GDM), which implements the graphical login screen, shown shortly after boot up, log out, and when user-switching. Bug Fixes BZ#616755 Previously, the gdm_smartcard_extension_is_visible() function returned "TRUE" instead of the "ret" variable. Consequently, the smartcard login could not be disabled in the system-config-authentication window if the pcsd package was installed. With this update, gdm_smartcard_extension_is_visible() has been modified to return the correct value. As a result, the described error no longer occurs. BZ#704245 When GDM was used to connect to a host via XDMCP (X Display Manager Control Protocol), another connection to a remote system using the "ssh -X" command resulted in failed authentication with the X server. Consequently, applications such as xterm could not be displayed on a remote system. This update provides a compatible MIT-MAGIC-COOKIE-1 key in the described scenario, thus fixing this incompatibility. BZ#738462 Previously, X server audit messages were not included by default in the X server log. Now, those messages are unconditionally included in the log. Also, with this update, verbose messages are added to the X server log if debugging is enabled in the /etc/gdm/custom.conf file by setting "Enable=true" in the "debug" section. BZ# 820058 Previously, after booting the system, the following message occurred in the /var/log/gdm/:0-greeter.log file: With this update, this warning is no longer displayed. Enhancements BZ#719647 With this update, GDM has been modified to allow smartcard authentication when the visible user list is disabled. BZ#834303 Previously, the GDM debugging logs were stored in the /var/log/messages file. With this update, a separate /var/log/gdm/daemon.log file has been established for these debugging logs. All users of gdm are advised to upgrade to these updated packages, which fix these bugs and add these enhancements.

Commands:
gdm-simple-greeter[PID]: Gtk-WARNING: gtkwidget.c:5460: widget not within a GtkWindow
Chapter 30. Profiling memory allocation with numastat With the numastat tool, you can display statistics over memory allocations in a system. The numastat tool displays data for each NUMA node separately. You can use this information to investigate memory performance of your system or the effectiveness of different memory policies on your system. 30.1. Default numastat statistics By default, the numastat tool displays statistics over these categories of data for each NUMA node: numa_hit The number of pages that were successfully allocated to this node. numa_miss The number of pages that were allocated on this node because of low memory on the intended node. Each numa_miss event has a corresponding numa_foreign event on another node. numa_foreign The number of pages initially intended for this node that were allocated to another node instead. Each numa_foreign event has a corresponding numa_miss event on another node. interleave_hit The number of interleave policy pages successfully allocated to this node. local_node The number of pages successfully allocated on this node by a process on this node. other_node The number of pages allocated on this node by a process on another node. Note High numa_hit values and low numa_miss values (relative to each other) indicate optimal performance. 30.2. Viewing memory allocation with numastat You can view the memory allocation of the system by using the numastat tool. Prerequisites Install the numactl package: Procedure View the memory allocation of your system: Additional resources numastat(8) man page on your system

Commands:
yum install numactl
numastat node0 node1 numa_hit 76557759 92126519 numa_miss 30772308 30827638 numa_foreign 30827638 30772308 interleave_hit 106507 103832 local_node 76502227 92086995 other_node 30827840 30867162
Chapter 11. Transactions 11.1. About Java Transaction API Red Hat JBoss Data Grid supports configuring, use of, and participation in Java Transaction API (JTA) compliant transactions. JBoss Data Grid does the following for each cache operation: First, it retrieves the transactions currently associated with the thread. If not already done, it registers an XAResource with the transaction manager to receive notifications when a transaction is committed or rolled back. Report a bug

Commands:
3.4. Logical Volume Backup Metadata backups and archives are automatically created on every volume group and logical volume configuration change unless disabled in the lvm.conf file. By default, the metadata backup is stored in the /etc/lvm/backup file and the metadata archives are stored in the /etc/lvm/archive file. How long the the metadata archives stored in the /etc/lvm/archive file are kept and how many archive files are kept is determined by parameters you can set in the lvm.conf file. A daily system backup should include the contents of the /etc/lvm directory in the backup. Note that a metadata backup does not back up the user and system data contained in the logical volumes. You can manually back up the metadata to the /etc/lvm/backup file with the vgcfgbackup command. You can restore metadata with the vgcfgrestore command. The vgcfgbackup and vgcfgrestore commands are described in Section 4.3.11, "Backing Up Volume Group Metadata" .

Commands:
B.15. No Guest Virtual Machines are Present when libvirtd is Started Symptom The libvirt daemon is successfully started, but no guest virtual machines appear to be present. Investigation There are various possible causes of this problem. Performing these tests will help to determine the cause of this situation: Verify KVM kernel modules Verify that KVM kernel modules are inserted in the kernel: If you are using an AMD machine, verify the kvm_amd kernel modules are inserted in the kernel instead, using the similar command lsmod | grep kvm_amd in the root shell. If the modules are not present, insert them using the modprobe <modulename> command. Note Although it is uncommon, KVM virtualization support may be compiled into the kernel. In this case, modules are not needed. Verify virtualization extensions Verify that virtualization extensions are supported and enabled on the host: Enable virtualization extensions in your hardware's firmware configuration within the BIOS setup. Refer to your hardware documentation for further details on this. Verify client URI configuration Verify that the URI of the client is configured as desired: For example, this message shows the URI is connected to the VirtualBox hypervisor, not QEMU , and reveals a configuration error for a URI that is otherwise set to connect to a QEMU hypervisor. If the URI was correctly connecting to QEMU , the same message would appear instead as: This situation occurs when there are other hypervisors present, which libvirt may speak to by default. Solution After performing these tests, use the following command to view a list of guest virtual machines:

Commands:
virsh list --all Id Name State ---------------------------------------------------- #
lsmod | grep kvm kvm_intel 121346 0 kvm 328927 1 kvm_intel
egrep "(vmx|svm)" /proc/cpuinfo flags : fpu vme de pse tsc ... svm ... skinit wdt npt lbrv svm_lock nrip_save flags : fpu vme de pse tsc ... svm ... skinit wdt npt lbrv svm_lock nrip_save
virsh uri vbox:///system
virsh uri qemu:///system
virsh list --all
Chapter 1. Block Storage backup service overview The Block Storage service (cinder) of the Red Hat OpenStack Platform (RHOSP) provides an optional backup service that you can deploy on Controller nodes. You can use the Block Storage backup service to create and restore full or incremental backups of your Block Storage volumes. A volume backup is a persistent copy of the contents of a Block Storage volume that is saved to a backup repository. Some features of the Block Storage backup service can impact the performance of the backups. For more information, see Backup performance considerations . 1.1. Backup repository back ends By default, your backup repository uses the Red Hat OpenStack Platform Object Storage service (swift) back end and the volume backups are created as object stores. However, you can choose to use Red Hat Ceph Storage, NFS, or S3 as your backup repository back end. The Block Storage backup service can back up volumes on any back end that the Block Storage service (cinder) supports, regardless of which back end you choose to use for your backup repository. 1.2. Block Storage volume backup metadata When you create a backup of a Block Storage volume, the metadata for this backup is stored in the Block Storage service database. The Block Storage backup service uses this metadata when it restores the volume from the backup. Important To ensure that a backup survives a catastrophic loss of the Block Storage service database, you can manually export and store the metadata of this backup. After a catastrophic database loss, you need to create a new Block Storage database and then manually re-import this backup metadata into it. For more information, see Protecting your backups .

Commands:
Chapter 28. Configuring Core Bridges The function of a bridge is to consume messages from one destination and forward them to another one, typically on a different JBoss EAP messaging server. The source and target servers do not have to be in the same cluster which makes bridging suitable for reliably sending messages from one cluster to another, for instance across a WAN, or internet and where the connection may be unreliable. The bridge has built-in resilience to failure so if the target server connection is lost, for example, due to network failure, the bridge will retry connecting to the target until it comes back online. When it comes back online it will resume operation as normal. Bridges are a way to reliably connect two separate JBoss EAP messaging servers together. With a core bridge both source and target servers must be JBoss EAP 7 messaging servers. Note Do not confuse a core bridge with a Jakarta Messaging bridge. A core bridge is used to bridge any two JBoss EAP messaging instances and uses the core API. A Jakarta Messaging bridge can be used to bridge any two Jakarta Messaging 2.0 compliant Jakarta Messaging providers and uses the Jakarta Messaging API. It is preferable to use a core bridge instead of a Jakarta Messaging bridge whenever possible. Below is an example configuration of a JBoss EAP messaging core bridge. <subsystem xmlns="urn:jboss:domain:messaging-activemq:4.0"> <server name="default"> ... <bridge name="my-core-bridge" static-connectors="bridge-connector" queue-name="jms.queue.InQueue"/> ... </server> </subsystem> This core bridge can be added using the following management CLI command. Note that when defining a core bridge, you must define a queue-name and either static-connectors or discovery-group . See the table in the appendix for a full list of configurable attributes. 28.1. Configuring a Core Bridge for Duplicate Detection Core bridges can be configured to automatically add a unique duplicate ID value, if there is not already one in the message, before forwarding the message to the target. To configure a core bridge for duplicate message detection set the use-duplicate-detection attribute to true , which is the default value.

Commands:
<subsystem xmlns="urn:jboss:domain:messaging-activemq:4.0"> <server name="default"> <bridge name="my-core-bridge" static-connectors="bridge-connector" queue-name="jms.queue.InQueue"/> </server> </subsystem>
/subsystem=messaging-activemq/server=default/bridge=my-core-bridge:add(static-connectors=[bridge-connector],queue-name=jms.queue.InQueue)
/subsystem=messaging-activemq/server=default/bridge=my-core-bridge:write-attribute(name=use-duplicate-detection,value=true)
Chapter 8. Container Images Based on Red Hat Software Collections 3.3 Component Description Supported architectures Database Images rhscl/mariadb-103-rhel7 MariaDB 10.3 SQL database server (EOL) x86_64, s390x, ppc64le rhscl/redis-5-rhel7 Redis 5 key-value store (EOL) x86_64, s390x, ppc64le Red Hat Developer Toolset Images rhscl/devtoolset-8-toolchain-rhel7 Red Hat Developer Toolset toolchain (EOL) x86_64, s390x, ppc64le rhscl/devtoolset-8-perftools-rhel7 Red Hat Developer Toolset perftools (EOL) x86_64, s390x, ppc64le Legend: x86_64 - AMD64 and Intel 64 architectures s390x - 64-bit IBM Z ppc64le - IBM POWER, little endian All images are based on components from Red Hat Software Collections. The images are available for Red Hat Enterprise Linux 7 through the Red Hat Container Registry. For detailed information about components provided by Red Hat Software Collections 3.3, see the Red Hat Software Collections 3.3 Release Notes . For more information about the Red Hat Developer Toolset 8.1 components, see the Red Hat Developer Toolset 8 User Guide . For information regarding container images based on Red Hat Software Collections 2, see Using Red Hat Software Collections 2 Container Images . EOL images are no longer supported.

Commands:
Chapter 2. Configuring the core RDMA subsystem The rdma service configuration manages the network protocols and communication standards such as InfiniBand, iWARP, and RoCE. Procedure Install the rdma-core package: Verification Install the libibverbs-utils and infiniband-diags packages: List the available InfiniBand devices: Display the information of the mlx4_1 device: Display the status of the mlx4_1 device: The ibping utility pings an InfiniBand address and runs as a client/server by configuring the parameters. Start server mode -S on port number -P with -C InfiniBand channel adapter (CA) name on the host: Start client mode, send some packets -c on port number -P by using -C InfiniBand channel adapter (CA) name with -L Local Identifier (LID) on the host:

Commands:
dnf install rdma-core
dnf install libibverbs-utils infiniband-diags
ibv_devices device node GUID ------ ---------------- mlx4_0 0002c903003178f0 mlx4_1 f4521403007bcba0
ibv_devinfo -d mlx4_1 hca_id: mlx4_1 transport: InfiniBand (0) fw_ver: 2.30.8000 node_guid: f452:1403:007b:cba0 sys_image_guid: f452:1403:007b:cba3 vendor_id: 0x02c9 vendor_part_id: 4099 hw_ver: 0x0 board_id: MT_1090120019 phys_port_cnt: 2 port: 1 state: PORT_ACTIVE (4) max_mtu: 4096 (5) active_mtu: 2048 (4) sm_lid: 2 port_lid: 2 port_lmc: 0x01 link_layer: InfiniBand port: 2 state: PORT_ACTIVE (4) max_mtu: 4096 (5) active_mtu: 4096 (5) sm_lid: 0 port_lid: 0 port_lmc: 0x00 link_layer: Ethernet
ibstat mlx4_1 CA 'mlx4_1' CA type: MT4099 Number of ports: 2 Firmware version: 2.30.8000 Hardware version: 0 Node GUID: 0xf4521403007bcba0 System image GUID: 0xf4521403007bcba3 Port 1: State: Active Physical state: LinkUp Rate: 56 Base lid: 2 LMC: 1 SM lid: 2 Capability mask: 0x0251486a Port GUID: 0xf4521403007bcba1 Link layer: InfiniBand Port 2: State: Active Physical state: LinkUp Rate: 40 Base lid: 0 LMC: 0 SM lid: 0 Capability mask: 0x04010000 Port GUID: 0xf65214fffe7bcba2 Link layer: Ethernet
ibping -S -C mlx4_1 -P 1
ibping -c 50 -C mlx4_0 -P 1 -L 2
14.12.5. Retrieving Storage Volume Information The vol-pool --uuid vol-key-or-path command returns the pool name or UUID for a given volume. By default, the pool name is returned. If the --uuid option is given, the pool UUID is returned instead. The command requires the vol-key-or-path which is the key or path of the volume for which to return the requested information. The vol-path --pool pool-or-uuid vol-name-or-key command returns the path for a given volume. The command requires --pool pool-or-uuid , which is the name or UUID of the storage pool the volume is in. It also requires vol-name-or-key which is the name or key of the volume for which the path has been requested. The vol-name vol-key-or-path command returns the name for a given volume, where vol-key-or-path is the key or path of the volume to return the name for. The vol-key --pool pool-or-uuid vol-name-or-path command returns the volume key for a given volume where --pool pool-or-uuid is the name or UUID of the storage pool the volume is in and vol-name-or-path is the name or path of the volume to return the volume key for.

Commands:
18.3.4. iptables Match Options Different network protocols provide specialized matching options which can be configured to match a particular packet using that protocol. However, the protocol must first be specified in the iptables command. For example -p tcp <protocol-name> (where <protocol-name> is the target protocol), makes options for the specified protocol available. 18.3.4.1. TCP Protocol These match options are available for the TCP protocol ( -p tcp ): --dport - Sets the destination port for the packet. Use either a network service name (such as www or smtp ), port number, or range of port numbers to configure this option. To browse the names and aliases of network services and the port numbers they use, view the /etc/services file. The --destination-port match option is synonymous with --dport . To specify a range of port numbers, separate the two numbers with a colon ( : ), such as -p tcp --dport 3000:3200 . The largest acceptable valid range is 0:65535 . Use an exclamation point character ( ! ) after the --dport option to match all packets which do not use that network service or port. --sport - Sets the source port of the packet using the same options as --dport . The --source-port match option is synonymous with --sport . --syn - Applies to all TCP packets designed to initiate communication, commonly called SYN packets . Any packets that carry a data payload are not touched. Placing an exclamation point character ( ! ) as a flag after the --syn option causes all non-SYN packets to be matched. --tcp-flags - Allows TCP packets with specific set bits, or flags, to match a rule. The --tcp-flags match option accepts two parameters. The first parameter is the mask, which sets the flags to be examined in the packet. The second parameter refers to the flag that must be set to match. The possible flags are: ACK FIN PSH RST SYN URG ALL NONE For example, an iptables rule which contains -p tcp --tcp-flags ACK,FIN,SYN SYN only matches TCP packets that have the SYN flag set and the ACK and FIN flags unset. Using the exclamation point character ( ! ) after --tcp-flags reverses the effect of the match option. --tcp-option - Attempts to match with TCP-specific options that can be set within a particular packet. This match option can also be reversed with the exclamation point character ( ! ).

Commands:
4.12. Bind Mounts and Context-Dependent Path Names GFS2 file systems do not provide support for Context-Dependent Path Names (CDPNs), which allow you to create symbolic links that point to variable destination files or directories. For this functionality in GFS2, you can use the bind option of the mount command. The bind option of the mount command allows you to remount part of a file hierarchy at a different location while it is still available at the original location. The format of this command is as follows. After executing this command, the contents of the olddir directory are available at two locations: olddir and newdir . You can also use this option to make an individual file available at two locations. For example, after executing the following commands the contents of /root/tmp will be identical to the contents of the previously mounted /var/log directory. Alternately, you can use an entry in the /etc/fstab file to achieve the same results at mount time. The following /etc/fstab entry will result in the contents of /root/tmp being identical to the contents of the /var/log directory. After you have mounted the file system, you can use the mount command to see that the file system has been mounted, as in the following example. With a file system that supports Context-Dependent Path Names, you might have defined the /bin directory as a Context-Dependent Path Name that would resolve to one of the following paths, depending on the system architecture. You can achieve this same functionality by creating an empty /bin directory. Then, using a script or an entry in the /etc/fstab file, you can mount each of the individual architecture directories onto the /bin directory with a mount -bind command. For example, you can use the following command as a line in a script. Alternately, you can use the following entry in the /etc/fstab file. A bind mount can provide greater flexibility than a Context-Dependent Path Name, since you can use this feature to mount different directories according to any criteria you define (such as the value of %fill for the file system). Context-Dependent Path Names are more limited in what they can encompass. Note, however, that you will need to write your own script to mount according to a criteria such as the value of %fill . Warning When you mount a file system with the bind option and the original file system was mounted rw , the new file system will also be mounted rw even if you use the ro flag; the ro flag is silently ignored. In this case, the new file system might be marked as ro in the /proc/mounts directory, which may be misleading.

Commands:
mount --bind olddir newdir
cd ~root mkdir ./tmp mount --bind /var/log /root/tmp
/var/log /root/tmp none bind 0 0
mount | grep /tmp /var/log on /root/tmp type none (rw,bind)
/usr/i386-bin /usr/x86_64-bin /usr/ppc64-bin
mount --bind /usr/i386-bin /bin
/usr/1386-bin /bin none bind 0 0
Release Notes and Known Issues Red Hat CodeReady Workspaces 2.1 Release Notes and Known Issues for Red Hat CodeReady Workspaces 2.1 Robert Kratky rkratky@redhat.com Michal Maler mmaler@redhat.com Fabrice Flore-Thebault ffloreth@redhat.com Yana Hontyk yhontyk@redhat.com Red Hat Developer Group Documentation Team devtools-docs@redhat.com

Commands:
Chapter 18. Persistently mounting file systems As a system administrator, you can persistently mount file systems to configure non-removable storage. 18.1. The /etc/fstab file Use the /etc/fstab configuration file to control persistent mount points of file systems. Each line in the /etc/fstab file defines a mount point of a file system. It includes six fields separated by white space: The block device identified by a persistent attribute or a path in the /dev directory. The directory where the device will be mounted. The file system on the device. Mount options for the file system, which includes the defaults option to mount the partition at boot time with default options. The mount option field also recognizes the systemd mount unit options in the x-systemd. option format. Backup option for the dump utility. Check order for the fsck utility. Note The systemd-fstab-generator dynamically converts the entries from the /etc/fstab file to the systemd-mount units. The systemd auto mounts LVM volumes from /etc/fstab during manual activation unless the systemd-mount unit is masked. Note The dump utility used for backup of file systems has been removed in RHEL 9, and is available in the EPEL 9 repository. Example 18.1. The /boot file system in /etc/fstab Block device Mount point File system Options Backup Check UUID=ea74bbec-536d-490c-b8d9-5b40bbd7545b /boot xfs defaults 0 0 The systemd service automatically generates mount units from entries in /etc/fstab . Additional resources fstab(5) and systemd.mount(5) man pages on your system 18.2. Adding a file system to /etc/fstab Configure persistent mount point for a file system in the /etc/fstab configuration file. Procedure Find out the UUID attribute of the file system: For example: Example 18.2. Viewing the UUID of a partition If the mount point directory does not exist, create it: As root, edit the /etc/fstab file and add a line for the file system, identified by the UUID. For example: Example 18.3. The /boot mount point in /etc/fstab Regenerate mount units so that your system registers the new configuration: Try mounting the file system to verify that the configuration works: Additional resources Overview of persistent naming attributes

Commands:
lsblk --fs storage-device
lsblk --fs /dev/sda1 NAME FSTYPE LABEL UUID MOUNTPOINT sda1 xfs Boot ea74bbec-536d-490c-b8d9-5b40bbd7545b /boot
mkdir --parents mount-point
UUID=ea74bbec-536d-490c-b8d9-5b40bbd7545b /boot xfs defaults 0 0
systemctl daemon-reload
mount mount-point