mtpti5iD/redhat-docs_dataset huggingface dataset:
10.4.5. Problems When You Try to Log In If you did not create a user account in the firstboot screens, switch to a console by pressing Ctrl + Alt + F2 , log in as root and use the password you assigned to root. If you cannot remember your root password, boot your system as linux single . If you are using an x86-based system and GRUB is your installed boot loader, type e for edit when the GRUB boot screen has loaded. You are presented with a list of items in the configuration file for the boot label you have selected. Choose the line that starts with kernel and type e to edit this boot entry. At the end of the kernel line, add: Press Enter to exit edit mode. Once the boot loader screen has returned, type b to boot the system. Once you have booted into single user mode and have access to the # prompt, you must type passwd root , which allows you to enter a new password for root. At this point you can type shutdown -r now to reboot the system with the new root password. If you cannot remember your user account password, you must become root. To become root, type su - and enter your root password when prompted. Then, type passwd <username> . This allows you to enter a new password for the specified user account. If the graphical login screen does not appear, check your hardware for compatibility issues. The Hardware Compatibility List can be found at:

Commands:
single
https://hardware.redhat.com/
13.3. Settings to Wipe Virtual Disks After Deletion The wipe_after_delete flag, viewed in the Administration Portal as the Wipe After Delete check box will replace used data with zeros when a virtual disk is deleted. If it is set to false, which is the default, deleting the disk will open up those blocks for reuse but will not wipe the data. It is, therefore, possible for this data to be recovered because the blocks have not been returned to zero. The wipe_after_delete flag only works on block storage. On file storage, for example NFS, the option does nothing because the file system will ensure that no data exists. Enabling wipe_after_delete for virtual disks is more secure, and is recommended if the virtual disk has contained any sensitive data. This is a more intensive operation and users may experience degradation in performance and prolonged delete times. Note The wipe after delete functionality is not the same as secure delete, and cannot guarantee that the data is removed from the storage, just that new disks created on same storage will not expose data from old disks. The wipe_after_delete flag default can be changed to true during the setup process (see Configuring the Red Hat Virtualization Manager ), or by using the engine-config tool on the Red Hat Virtualization Manager. Restart the ovirt-engine service for the setting change to take effect. Note Changing the wipe_after_delete flag's default setting will not affect the Wipe After Delete property of disks that already exist. Setting SANWipeAfterDelete to Default to True Using the Engine Configuration Tool Run the engine-config tool with the --set action: Restart the ovirt-engine service for the change to take effect: The /var/log/vdsm/vdsm.log file located on the host can be checked to confirm that a virtual disk was successfully wiped and deleted. For a successful wipe, the log file will contain the entry, storage_domain_id / volume_id was zeroed and will be deleted . For example: For a successful deletion, the log file will contain the entry, finished with VG: storage_domain_id LVs: list_of_volume_ids , img: image_id . For example: An unsuccessful wipe will display a log message zeroing storage_domain_id / volume_id failed. Zero and remove this volume manually , and an unsuccessful delete will display Remove failed for some of VG: storage_domain_id zeroed volumes: list_of_volume_ids .

Commands:
engine-config --set SANWipeAfterDelete=true
systemctl restart ovirt-engine.service
a9cb0625-d5dc-49ab-8ad1-72722e82b0bf/a49351a7-15d8-4932-8d67-512a369f9d61 was zeroed and will be deleted
finished with VG:a9cb0625-d5dc-49ab-8ad1-72722e82b0bf LVs: {'a49351a7-15d8-4932-8d67-512a369f9d61': ImgsPar(imgs=['11f8b3be-fa96-4f6a-bb83-14c9b12b6e0d'], parent='00000000-0000-0000-0000-000000000000')}, img: 11f8b3be-fa96-4f6a-bb83-14c9b12b6e0d
12.2. Enabling IPv6 for a Subsystem Certificate System automatically configures and manages connections between subsystems. Every subsystem must interact with a CA as members of a security domain and to perform their PKI operations. For these connections, Certificate System subsystems can be recognized by their host's fully-qualified domain name or an IP address. By default, Certificate System resolves IPv4 addresses and host names automatically, but Certificate System can also use IPv6 for their connections. IPv6 is supported for all server connections: to other subsystems, to the administrative console ( pkiconsole ), or through command-line scripts such as tpsclient : Install the Red Hat Certificate System packages. Set the IPv4 and IPv6 addresses in the /etc/hosts file. For example: Then, export the environment variable to use the IPv6 address for the server. For example: Run pkispawn to create the new instance. The values for the server host name in the CS.cfg file will be set to the IPv6 address.

Commands:
op=var_set name=ca_host value= IPv6 address
vim /etc/hosts 192.0.0.0 server.example.com IPv4 address 3ffe:1234:2222:2000:202:55ff:fe67:f527 server6.example.com IPv6 address
export PKI_HOSTNAME=server6.example.com
Chapter 2. Deploying Red Hat build of OpenJDK applications in containers You can deploy Red Hat build of OpenJDK applications in containers and have them run when the container is loaded. Procedure Copy the application JAR to the /deployments directory in the image JAR file. For example, the following shows a brief Dockerfile that adds an application called testubi.jar to the Red Hat build of OpenJDK 8 UBI8 image:

Commands:
FROM registry.access.redhat.com/ubi8/openjdk-8 COPY target/testubi.jar /deployments/testubi.jar
C.13. LocalTopologyManager org.infinispan.topology.LocalTopologyManagerImpl The LocalTopologyManager component controls the cache membership and state transfer in Red Hat JBoss Data Grid. Note The LocalTopologyManager component is only available in clustered mode. Table C.22. Attributes Name Description Type Writable rebalancingEnabled If false, newly started nodes will not join the existing cluster nor will the state be transferred to them. If any of the current cluster members are stopped when rebalancing is disabled, the nodes will leave the cluster but the state will not be rebalanced among the remaining nodes. This will result in fewer copies than specified by the numOwners attribute until rebalancing is enabled again. boolean Yes clusterAvailability If AVAILABLE the node is currently operating regularly. If DEGRADED then data can not be safely accessed due to either a network split, or successive nodes leaving. String No Report a bug

Commands:
5.62. fcoe-target-utils 5.62.1. RHBA-2012:0854 - fcoe-target-utils bug fix and enhancement update Updated fcoe-target-utils packages that fix three bugs and add one enhancement are now available for Red Hat Enterprise Linux 6. The fcoe-target-utils packages provide a command line interface for configuring FCoE LUNs (Fibre Channel over Ethernet Logical Unit Numbers) and backstores. Bug Fixes BZ# 752699 Prior to this update, starting targetadmin without the fcoe-target utility could cause the following output: This update modifies the underlying code so that now a warning message is displayed if targetcli is invoked without running the fcoe-target service. BZ# 813664 Prior to this update, fcoe-target-utils used the executable name "targetadmin" which did not reflect the current name in the upstream version. This update changes the name to "targetcli", to match the upstream version. BZ# 815981 Prior to this update, the configuration state was saved to "tcm_start.sh", and the fcoe-target init script restored the state from this file when the fcoe-target service was started. For increased reliability, this update uses a new method to save and restore fcoe-target configuration; it is now saved to "/etc/target/saveconfig.json". Enhancement BZ# 750277 Prior to this update, the fcoe-target-utils packages for the Fibre Channel over Ethernet (FCoE) target mode were available only as technical preview. With this update, the fcoe-target-utils packages are fully supported in Red Hat Enterprise Linux 6. All users of fcoe-target-utils are advised to upgrade to these updated packages, which fix these bugs and add these enhancements.

Commands:
OSError: [Errno 2] No such file or directory: '/sys/kernel/config/target
6.3. Clustered Modes Red Hat JBoss Data Grid offers the following clustered modes: Replication Mode replicates any entry that is added across all cache instances in the cluster. Invalidation Mode does not share any data, but signals remote caches to initiate the removal of invalid entries. Distribution Mode stores each entry on a subset of nodes instead of on all nodes in the cluster. The clustered modes can be further configured to use synchronous or asynchronous transport for network communications. Report a bug 6.3.1. Asynchronous and Synchronous Operations When a clustered mode (such as invalidation, replication or distribution) is used, data is propagated to other nodes in either a synchronous or asynchronous manner. If synchronous mode is used, the sender waits for responses from receivers before allowing the thread to continue, whereas asynchronous mode transmits data but does not wait for responses from other nodes in the cluster to continue operations. Asynchronous mode prioritizes speed over consistency, which is ideal for use cases such as HTTP session replications with sticky sessions enabled. Such a session (or data for other use cases) is always accessed on the same cluster node, unless this node fails. 23149%2C+Administration+and+Configuration+Guide-6.628-06-2017+13%3A51%3A02JBoss+Data+Grid+6Documentation6.6.1 Report a bug 6.3.2. Cache Mode Troubleshooting 6.3.2.1. Invalid Data in ReadExternal If invalid data is passed to readExternal , it can be because when using Cache.putAsync() , starting serialization can cause your object to be modified, causing the datastream passed to readExternal to be corrupted. This can be resolved if access to the object is synchronized. 23149%2C+Administration+and+Configuration+Guide-6.628-06-2017+13%3A51%3A02JBoss+Data+Grid+6Documentation6.6.1 Report a bug 6.3.2.2. About Asynchronous Communications In Red Hat JBoss Data Grid, the local, distributed and replicated modes are represented by the local-cache , distributed-cache and replicated-cache elements respectively. Each of these elements contains a mode property, the value of which can be set to SYNC for synchronous or ASYNC for asynchronous communications. Example 6.1. Asynchronous Communications Example Configuration Note This configuration is valid for both JBoss Data Grid's usage modes (Library mode and Remote Client-Server mode). Report a bug 6.3.2.3. Cluster Physical Address Retrieval How can the physical addresses of the cluster be retrieved? The physical address can be retrieved using an instance method call. For example: AdvancedCache.getRpcManager().getTransport().getPhysicalAddresses() . 23149%2C+Administration+and+Configuration+Guide-6.628-06-2017+13%3A51%3A02JBoss+Data+Grid+6Documentation6.6.1 Report a bug

Commands:
<replicated-cache name="default" start="EAGER" mode="ASYNC" batching="false" statistics="true"> <!-- Additional configuration information here --> </replicated-cache>
8.228. virt-v2v 8.228.1. RHBA-2013:1547 - virt-v2v bug fix and enhancement update Updated virt-v2v package that fixes several bugs and adds various enhancements is now available for Red Hat Enterprise Linux 6. The virt-v2v package provides a tool for converting virtual machines to use the KVM (Kernel-based Virtual Machine) hypervisor or Red Hat Enterprise Virtualization. The tool modifies both the virtual machine image and its associated libvirt metadata. Also, virt-v2v can configure a guest to use VirtIO drivers if possible. Note The virt-v2v package has been upgraded to upstream version 0.9.1, which provides a number of bug fixes and enhancements over the version. (BZ# 965501 ) Bug Fixes BZ# 809273 After using the virt-v2v utility to migrate a Windows 2003 R2 32bit guest from Red Hat Enterprise Linux 5 Xen to Red Hat Enterprise Linux 6 KVM, the guest did not boot. With this update, the Windows Xen drivers are disabled during conversion, and the guest now boots correctly. BZ# 820928 Previously, virt-v2v assumed that Microsoft Windows operating system could be installed only to the /windows directory. Consequently, when a non-existent path was copied during installation, virt-v2v terminated unexpectedly. With this update, the system path is no longer hardcoded, and virt-v2v no longer crashes in the described scenario. BZ# 829859 Previously, virt-v2v always used the first kernel (0th kernel) instead of the default kernel (ex: default=1). With this update, virt-v2v uses the default kernel to create a new migrated Virtual Machine. BZ# 887884 Prior to this update, during conversion of a Linux guest with multiple console entries on the kernel boot command line, virt-v2v terminated unexpectedly. With this update, guests with multiple consoles can be converted successfully. BZ# 953994 Due to the incompatibility of vmware-tools and the virt-v2v code, the virt-v2v utility was failing to convert ESX Red Hat Enterprise Linux VM to KVM VM (Kernel-based VM) on the vmware-tools-foundation dependency. An upstream patch that fixes the broken dependency has been applied, and conversions now succeed. Users of virt-v2v are advised to upgrade to this updated package, which fixes these bugs and adds these enhancements. 8.228.2. RHBA-2013:1749 - virt-v2v bug fix update Updated virt-v2v package that fixes one bug is now available for Red Hat Enterprise Linux 6. The virt-v2v package provides a tool for converting virtual machines to use the KVM (Kernel-based Virtual Machine) hypervisor or Red Hat Enterprise Virtualization. The tool modifies both the virtual machine image and its associated libvirt metadata. Also, virt-v2v can configure a guest to use VirtIO drivers if possible. Bug Fix BZ# 1028983 An update to virt-v2v included upstream support for the import of OVA images exported by VMware servers. Unfortunately, testing has shown that VMDK images created by recent versions of VMware ESX cannot be reliably supported, thus this feature has been withdrawn. Users of virt-v2v are advised to upgrade to this updated package, which fixes this bug.

Commands:
4.5.2. Identifying and Configuring Services To enhance security, most network services installed with Red Hat Enterprise Linux are turned off by default. There are, however, some notable exceptions: cupsd - The default print server for Red Hat Enterprise Linux. lpd - An alternate print server. xinetd - A super server that controls connections to a host of subordinate servers, such as vsftpd and telnet . sendmail - The Sendmail mail transport agent is enabled by default, but only listens for connections from the localhost . sshd - The OpenSSH server, which is a secure replacement for Telnet. When determining whether to leave these services running, it is best to use common sense and err on the side of caution. For example, if a printer is not available, do not leave cupsd running. The same is true for portmap . If you do not mount NFSv3 volumes or use NIS (the ypbind service), then portmap should be disabled. Red Hat Enterprise Linux ships with three programs designed to switch services on or off. They are the Services Configuration Tool ( system-config-services ), ntsysv , and chkconfig . For information on using these tools, refer to the chapter titled Controlling Access to Services in the System Administrators Guide . Figure 4.3. Services Configuration Tool If unsure of the purpose for a particular service, the Services Configuration Tool has a description field, illustrated in Figure 4.3, " Services Configuration Tool " , that may be of some use. But checking which network services are available to start at boot time is not enough. Good system administrators should also check which ports are open and listening. Refer to Section 5.8, "Verifying Which Ports Are Listening" for more on this subject.

Commands:
Chapter 9. Fail over to the secondary site This chapter describes the steps to fail over from primary site to secondary site in a setup as outlined in Concepts for active-passive deployments together with the blueprints outlined in Building blocks active-passive deployments. 9.1. When to use procedure A failover from the primary site to the secondary site will happen automatically based on the checks configured in the loadbalancer. When the primary site loses its state in Data Grid or a network partition occurs that prevents the synchronization, manual procedures are necessary to recover the primary site before it can handle traffic again, see the Switch back to the primary site chapter. To prevent an automatic fallback to the primary site before those manual steps have been performed, configure the loadbalancer as described following to prevent this from happening automatically. For a graceful switch to the secondary site, follow the instructions in the Switch over to the secondary site chapter. See the Multi-site deployments chapter for different operational procedures. 9.2. Procedure Follow these steps to manually force a failover. 9.2.1. Route53 To force Route53 to mark the primary site as permanently not available and prevent an automatic fallback, edit the health check in AWS to point to a non-existent route ( health/down ).

Commands:
26.2. Native Fibre Channel Drivers and Capabilities Red Hat Enterprise Linux 6 ships with the following native fibre channel drivers: lpfc qla2xxx zfcp mptfc bfa Table 26.1, "Fibre-Channel API Capabilities" describes the different fibre-channel API capabilities of each native Red Hat Enterprise Linux 6 driver. X denotes support for the capability. Table 26.1. Fibre-Channel API Capabilities lpfc qla2xxx zfcp mptfc bfa Transport port_id X X X X X Transport node_name X X X X X Transport port_name X X X X X Remote Port dev_loss_tmo X X X X X Remote Port fast_io_fail_tmo X X [a] X [b] X Host port_id X X X X X Host issue_lip X X X [a] Supported as of Red Hat Enterprise Linux 5.4 [b] Supported as of Red Hat Enterprise Linux 6.0

Commands:
3.5. Deploy a VDB via CLI Prerequisites Red Hat JBoss Data Virtualization must be installed. The JBoss Enterprise Application Platform (EAP) server must be running. Procedure 3.3. Deploy a VDB via CLI Open the command line interface Run the EAP_HOME /bin/jboss-cli.sh command. Connect to the server Run the connect command. Deploy the virtual database If in standalone mode, run deploy PATH / DATABASE .vdb . If in domain mode, run deploy -all-server-groups PATH / DATABASE .vdb . Note In domain mode, you need to select a particular "server-group" or all available server groups are deployment options.

Commands:
33.7. Firewall Configuration The Firewall Configuration window allows you to configure firewall settings for the installed system. Figure 33.10. Firewall Configuration If Disable firewall is selected, the system allows complete access to any active services and ports. No connections to the system are refused or denied. Selecting Enable firewall configures the system to reject incoming connections that are not in response to outbound requests, such as DNS replies or DHCP requests. If access to services running on this machine is required, you can choose to allow specific services through the firewall. Only devices configured in the Network Configuration section are listed as available Trusted devices . Connections from any devices selected in the list are accepted by the system. For example, if eth1 only receives connections from internal system, you might want to allow connections from it. If a service is selected in the Trusted services list, connections for the service are accepted and processed by the system. In the Other ports text field, list any additional ports that should be opened for remote access. Use the following format: port:protocol . For example, to allow IMAP access through the firewall, specify imap:tcp . Numeric ports can also be specified explicitly; to allow UDP packets on port 1234 through the firewall, enter 1234:udp . To specify multiple ports, separate them with commas. 33.7.1. SELinux Configuration Kickstart can set SELinux to enforcing , permissive or disabled mode. Finer grained configuration is not possible at this time.

Commands:
Chapter 2. Non-interactively selecting a system-wide Red Hat build of OpenJDK version on RHEL If you have multiple versions of Red Hat build of OpenJDK installed on RHEL, you can select the default Red Hat build of OpenJDK version to use system-wide in a non-interactive way. This is useful for administrators who have root privileges on a Red Hat Enterprise Linux system and need to switch the default Red Hat build of OpenJDK on many systems in an automated way. Note If you do not have root privileges, you can select a Red Hat build of OpenJDK version by configuring the JAVA_HOME environment variable . Prerequisites You must have root privileges on the system. Multiple versions of Red Hat build of OpenJDK were installed using the yum package manager. Procedure Select the major Red Hat build of OpenJDK version to switch to. For example, for Red Hat build of OpenJDK 17, use java-17-openjdk . Verify that the active Red Hat build of OpenJDK version is the one you specified.

Commands:
PKG_NAME=java-17-openjdk JAVA_TO_SELECT=USD(alternatives --display java | grep "family USDPKG_NAME" | cut -d' ' -f1) alternatives --set java USDJAVA_TO_SELECT
java -version openjdk version "17" 2021-09-14 OpenJDK Runtime Environment 21.9 (build 17+35) OpenJDK 64-Bit Server VM 21.9 (build 17+35, mixed mode, sharing)
Preface Red Hat Ansible Certified Content Collection is included in your subscription to Red Hat Ansible Automation Platform. Red Hat Ansible Certified Content Collection inclues two types of content: Ansible Certified Content Collections and Ansible validated content. Using Ansible automation hub, you can access and curate a unique set of collections from all forms of Ansible content. You can also synchronize Ansible automation hub to create a custom list of collections from Red Hat Ansible Certified Content, Ansible validated content, or Ansible Galaxy community content. At present, Ansible validated collections are only available in your private automation hub Ansible validated content as part of the Platform Installer. When you download Red Hat Ansible Automation Platform with the bundled installer, validated content is pre-populated into the private automation hub by default, but only if you enable the private automation hub as part of the inventory. You can update these collections manually by downloading their packages.

Commands:
8.9. Deleting Snapshot Before deleting a snapshot ensure that the following prerequisites are met: Snapshot with the specified name should be present. Red Hat Gluster Storage nodes should be in quorum. No volume operation (e.g. add-brick, rebalance, etc) should be running on the original / parent volume of the snapshot. To delete a snapshot run the following command: where, snapname - The name of the snapshot to be deleted. For Example: Note Red Hat Gluster Storage volume cannot be deleted if any snapshot is associated with the volume. You must delete all the snapshots before issuing a volume delete. 8.9.1. Deleting Multiple Snapshots Multiple snapshots can be deleted using either of the following two commands. To delete all the snapshots present in a system, execute the following command: To delete all the snapshot present in a specified volume, execute the following command:

Commands:
gluster snapshot delete < snapname >
gluster snapshot delete snap2 Deleting snap will erase all the information about the snap. Do you still want to continue? (y/n) y snapshot delete: snap2: snap removed successfully
gluster snapshot delete all
gluster snapshot delete volume < volname >