mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 9. Industry Standards and Certification FIPS 140 Revalidations Federal Information Processing Standards (FIPS) publications 140 is a U.S. government security standard that specifies the security requirements that must be satisfied by a cryptographic module utilized within a security system protecting sensitive, but unclassified information. The standard provides four increasing, qualitative levels of security: Level 1, Level 2, Level 3, and Level 4. These levels are intended to cover the wide range of potential applications and environments in which cryptographic modules may be employed. The security requirements cover areas related to the secure design and implementation of a cryptographic module. These areas include cryptographic module specification, cryptographic module ports and interfaces; roles, services, and authentication; finite state model; physical security; operational environment; cryptographic key management; electromagnetic interference/electromagnetic compatibility (EMI/EMC); self-tests; design assurance; and mitigation of other attacks. Red Hat Enterprise Linux 6.5 supports NSA Suite B cryptography enhancements and certifications. These cryptographic algorithms provide highly secure networking communication. NSA SUITE B is required for government agencies under NIST 800 - 131. Components of NSA Suite B cryptography include the following: Advanced Encryption Standard (AES) encryption GCM mode of operation Elliptic Curve Diffie-Hellman (ECDH) Secure Hash Algorithm 2 (SHA-256) The following targets are in the process of validation: NSS FIPS-140 Level 1 Suite B Elliptic Curve Cryptography (ECC) OpenSSH (Client and Server) Openswan dm-crypt OpenSSL Kernel Crypto AES-GCM, AES-CTS, AES-CTR ciphers

Commands:
Chapter 3. Deprecated features This section describes features that have been deprecated from AMQ Broker. Hawtio dispatch console plugin Starting in 7.3, AMQ Broker no longer ships with the Hawtio dispatch console plugin, dispatch-hawtio-console.war . Previously, the dispatch console was used to manage AMQ Interconnect. However, AMQ Interconnect now uses its own, standalone web console. Network pinger Starting in 7.5, network pinging is a deprecated feature. Network pinging cannot protect a broker cluster from network isolation issues that can lead to irrecoverable message loss. This feature will be removed in a future release. Red Hat continues to support existing AMQ Broker deployments that use network pinging. However, Red Hat no longer recommends use of network pinging in new deployments. For guidance on configuring a broker cluster for high availability and to avoid network isolation issues, see Implementing high availability in Configuring AMQ Broker .. Application templates for AMQ Broker on OpenShift Container Platform Starting in 7.8, the use of application templates for deploying AMQ Broker on OpenShift Container Platform is a deprecated feature. This feature will be removed in a future release. Red Hat continues to support existing deployments that are based on application templates. However, Red Hat does not recommend using application templates for new deployments. For new deployments, Red Hat recommends using the AMQ Broker Operator. For information on installing and deploying the Operator, see Deploying AMQ Broker on OpenShift Container Platform using the AMQ Broker Operator in Deploying AMQ Broker on OpenShift .

Commands:
Chapter 6. Message delivery 6.1. Writing to a streamed large message To write to a large message, use the BytesMessage.writeBytes() method. The following example reads bytes from a file and writes them to a message: Example: Writing to a streamed large message BytesMessage message = session.createBytesMessage(); File inputFile = new File(inputFilePath); InputStream inputStream = new FileInputStream(inputFile); int numRead; byte[] buffer = new byte[1024]; while ((numRead = inputStream.read(buffer, 0, buffer.length)) != -1) { message.writeBytes(buffer, 0, numRead); } 6.2. Reading from a streamed large message To read from a large message, use the BytesMessage.readBytes() method. The following example reads bytes from a message and writes them to a file: Example: Reading from a streamed large message BytesMessage message = (BytesMessage) consumer.receive(); File outputFile = new File(outputFilePath); OutputStream outputStream = new FileOutputStream(outputFile); int numRead; byte buffer[] = new byte[1024]; for (int pos = 0; pos < message.getBodyLength(); pos += buffer.length) { numRead = message.readBytes(buffer); outputStream.write(buffer, 0, numRead); }

Commands:
BytesMessage message = session.createBytesMessage(); File inputFile = new File(inputFilePath); InputStream inputStream = new FileInputStream(inputFile); int numRead; byte[] buffer = new byte[1024]; while ((numRead = inputStream.read(buffer, 0, buffer.length)) != -1) { message.writeBytes(buffer, 0, numRead); }
BytesMessage message = (BytesMessage) consumer.receive(); File outputFile = new File(outputFilePath); OutputStream outputStream = new FileOutputStream(outputFile); int numRead; byte buffer[] = new byte[1024]; for (int pos = 0; pos < message.getBodyLength(); pos += buffer.length) { numRead = message.readBytes(buffer); outputStream.write(buffer, 0, numRead); }
Chapter 2. Cache Managers A Cache Manager is the primary mechanism to retrieve a cache instance in Red Hat JBoss Data Grid, and is a starting point for using the cache. In JBoss Data Grid, a cache manager is useful because: it creates cache instances on demand. it retrieves existing cache instances (i.e. caches that have already been created). Report a bug 2.1. Types of Cache Managers Red Hat JBoss Data Grid offers the following Cache Managers: EmbeddedCacheManager is a cache manager that runs within the Java Virtual Machine (JVM) used by the client. Currently, JBoss Data Grid offers only the DefaultCacheManager implementation of the EmbeddedCacheManager interface. RemoteCacheManager is used to access remote caches. When started, the RemoteCacheManager instantiates connections to the Hot Rod server (or multiple Hot Rod servers). It then manages the persistent TCP connections while it runs. As a result, RemoteCacheManager is resource-intensive. The recommended approach is to have a single RemoteCacheManager instance for each Java Virtual Machine (JVM). Report a bug

Commands:
Chapter 2. Overview of responsibilities for Red Hat Advanced Cluster Security Cloud Service This documentation outlines Red Hat and customer responsibilities for the RHACS Cloud Service managed service. 2.1. Shared responsibilities for RHACS Cloud Service While Red Hat manages the RHACS Cloud Service services, also referred to as Central services , the customer has certain responsibilities. Resource or action Red Hat responsibility Customer responsibility Hosted components, also called Central components Platform monitoring Software updates High availability Backup and restore Security Infrastructure configuration Scaling Maintenance Vulnerability management Access and identity authorization Secured clusters (on-premise or cloud) Software updates Backup and restore Security Infrastructure configuration Scaling Maintenance Access and identity authorization Vulnerability management

Commands:
4.10. Red Hat Virtualization 4.3 Batch Update 9 (ovirt-4.3.12) 4.10.1. Bug Fix These bugs were fixed in this release of Red Hat Virtualization: BZ# 1889738 4.10.2. Known Issues These known issues exist in Red Hat Virtualization at this time: BZ# 1897179

Commands:
Previously, when performing an upgrade of the Red Hat Virtualization Host, the directory holding configuration files on the Manager was not created correctly. In this release, the directory is created correctly during an upgrade.
After running engine-setup and upgrading the Red hat Virtualization Manager from 4.3.x to 4.3.x+1, a complete yum update fails due to an Ansible dependency that cannot be satisfied with the current subscription channel. Workaround: see https://access.redhat.com/solutions/5480561
Chapter 1. Backing up Central database by using the roxctl CLI Central stores information about the following: Activity observed in your clusters Information retrieved from integrated image registries or Scanners Red Hat Advanced Cluster Security for Kubernetes (RHACS) configuration Backing up the Central database is critical to ensure data integrity and system reliability. Regular backups of the database, which contain the necessary configurations, resources, events, and certificates, protect against database failures, corruption, and accidental data loss. You can use the roxctl CLI to back up and restore the Central database by using the backup command. This command requires an API token or your administrator password. 1.1. On-demand backups by using an API token You can back up the entire database of RHACS by using an API token. Prerequisites You have an API token with the Admin role. You have installed the roxctl CLI. Procedure Set the ROX_API_TOKEN and the ROX_ENDPOINT environment variables by running the following commands: USD export ROX_API_TOKEN=<api_token> USD export ROX_ENDPOINT=<address>:<port_number> Initiate a backup for Central by running the following command: USD roxctl central backup 1 1 You can use the --output option to specify the backup file location. By default, the roxctl CLI saves the backup file in the directory where you run the command. Additional resources System roles 1.2. On-demand backups by using the administrator password You can back up the entire database of RHACS by using your administrator password. Prerequisites You have the administrator password. You have installed the roxctl CLI. Procedure Set the ROX_ENDPOINT environment variable by running the following command: USD export ROX_ENDPOINT=<address>:<port_number> Initiate a backup for Central by running the following command: USD roxctl -p <admin_password> central backup 1 1 For <admin_password> , specify the administrator password. By default, the roxctl CLI saves the backup file in the directory in which you run the command. You can use the --output option to specify the backup file location.

Commands:
export ROX_API_TOKEN=<api_token>
export ROX_ENDPOINT=<address>:<port_number>
roxctl central backup 1
export ROX_ENDPOINT=<address>:<port_number>
roxctl -p <admin_password> central backup 1
Chapter 137. AutoRestartStatus schema reference Used in: KafkaConnectorStatus , KafkaMirrorMaker2Status Property Property type Description count integer The number of times the connector or task is restarted. connectorName string The name of the connector being restarted. lastRestartTimestamp string The last time the automatic restart was attempted. The required format is 'yyyy-MM-ddTHH:mm:ssZ' in the UTC time zone.

Commands:
Chapter 40. Virtualization Problematic GRUB 2 navigation with KVM When using the serial console through KVM, holding down an arrow key for an extended period of time to navigate in the GRUB 2 menu results in erratic behavior. To work around this problem, avoid the rapid input caused by holding an arrow key down for a longer time. Resizing GUID Partition Table (GPT) disks on Hyper-V guests causes partition table errors The Hyper-V manager supports shrinking a GPT-partitioned disk on a guest if there is free space after the last partition, by allowing the user to drop the unused last part of the disk. However, this operation will silently delete the secondary GPT header on the disk, which may trigger error messages when guest examines the partition table (for example, with parted(8)). This is a known limit of Hyper-V. To work around this, it is possible to manually restore the secondary GPT header with the gdisk(8) expert command e , after shrinking the GPT disk. This also occurs when using Hyper-V's Expand option, but can also be fixed with the parted(8) tool. Bridge creation with virsh iface-bridge fails When installing Red Hat Enterprise Linux 7 from other sources than the network, network device names are not specified by default in the interface configuration files (this is done with a DEVICE= line). As a consequence, creating a network bridge by using the virsh iface-bridge command fails with an error message. To work around the problem, add DEVICE= lines into the /etc/sysconfig/network-scripts/ifcfg-* files. QEMU-emulated CAC smart cards incompatible with ActivClient software Currently, Common Access Card (CAC) smart cards emulated with QEMU are not accepted by ActivClient software. To work around this problem, disable the pcscd daemon, provision a Windows KVM guest, preconfigure it in the virt-viewer tool and select the USB redirection option, install the ActivClient software, and reboot the KVM guest. With this setup, ActivClient accepts the emulated CAC card. virtio-win VFD files do not contain Windows 10 drivers Due to limitations on floppy file size, the virtual floppy disk (VFD) files in the virtio-win packages do not contain a Windows 10 folder. If a user needs to install Windows 10 drivers from a VFD, they can use the Windows 8 or Windows 8.1 drivers instead. Alternatively, the Windows 10 drivers can be installed from the ISO file in the /usr/share/virtio-win/ directory. Migrated guests do not display the boot menu on the serial console Virtual machines (VMs) created on Red Hat Enterprise Linux 6 that have no graphics card (such as VMs created using the virt-install utility with the --graphics none option) do not show the boot menu on the serial console anymore after migrating to Red Hat Enterprise Linux 7 hosts. To work around this problem, add the <bios useserial='yes'/> line to the domain.xml file, which allows the boot menu to display as expected. Note that if the XML file is modified this way, it should not be used on Red Hat Enterprise Linux 6.6 or earlier, as these do not benefit from changes introduced for BZ#1162759 .

Commands:
B.14. dbus B.14.1. RHSA-2011:0376 - Moderate: dbus security update Updated dbus packages that fix one security issue are now available for Red Hat Enterprise Linux 5 and 6. The Red Hat Security Response Team has rated this update as having moderate security impact. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) associated with each description below. D-Bus is a system for sending messages between applications. It is used for the system-wide message bus service and as a per-user-login-session messaging facility. CVE-2010-4352 A denial of service flaw was discovered in the system for sending messages between applications. A local user could send a message with an excessive number of nested variants to the system-wide message bus, causing the message bus (and, consequently, any process using libdbus to receive messages) to abort. All users are advised to upgrade to these updated packages, which contain a backported patch to correct this issue. For the update to take effect, all running instances of dbus-daemon and all running applications using the libdbus library must be restarted, or the system rebooted.

Commands:
4.356. xorg-x11-drv-qxl 4.356.1. RHEA-2011:1621 - xorg-x11-drv-qxl bug fix and enhancement update An updated xorg-x11-drv-qxl package that fixes multiple bugs and adds various enhancements is now available for Red Hat Enterprise Linux 6. The xorg-x11-drv-qxl package provides an X11 video driver for the QEMU QXL video accelerator. This driver makes it possible to use Red Hat Enterprise Linux 6 as a guest operating system under the KVM kernel module and the QEMU multi-platform emulator, using the SPICE protocol. The xorg-x11-drv-qxl package has been upgraded to upstream version 0.0.14, which provides a number of bug fixes and enhancements over the version. BZ# 713857 All users of xorg-x11-drv-qxl are advised to upgrade to this updated package, which fixes these bugs and adds these enhancements. 4.356.2. RHBA-2012:0380 - xorg-x11-drv-qxl bug fix update An updated xorg-x11-drv-qxl package that fixes two bug is now available for Red Hat Enterprise Linux 6. The xorg-x11-drv-qxl package provides an X11 video driver for the QEMU QXL video accelerator. This driver makes it possible to use Red Hat Enterprise Linux 6 as a guest operating system under the KVM kernel module and the QEMU multi-platform emulator, using the SPICE protocol. Bug Fixes BZ# 794877 The QXL driver for Red Hat Enterprise Linux 6.2 did not contain the compatibility layer. As a consequence, updating a Red Hat Enterprise Linux 6 guest running on a Red Hat Enterprise Linux 5 host in the Red Hat Enterprise Virtualization 2.2 environment caused the SPICE client window to become black after the update, and therefore unusable. A patch has been applied to ensure proper compatibility and the driver now works correctly in the described scenario. BZ# 799524 The QXL driver for Red Hat Enterprise Linux 6.2 was not able to cache images on the client side. This led to visible and significant impact on user experience (users could have experienced delays when loading images contained in web presentations or slideshows). With this update, images can be optionally cached on the client side. All users of xorg-x11-drv-qxl are advised to upgrade to this updated package, which fixes these bugs.

Commands:
9.3. Lucene Directory Configuration for Replicated Indexing Define the following properties in the Hibernate configuration and in the Persistence unit configuration file when using standard JPA. For instance, to change all of the default storage indexes the following property could be configured: This may also be performed on unique indexes. In the following example tickets and actors are index names: Lucene's DirectoryProvider uses the following options to configure the cache names: locking_cachename - Cache name where Lucene's locks are stored. Defaults to LuceneIndexesLocking . data_cachename - Cache name where Lucene's data is stored, including the largest data chunks and largest objects. Defaults to LuceneIndexesData . metadata_cachename - Cache name where Lucene's metadata is stored. Defaults to LuceneIndexesMetadata . To adjust the name of the locking cache to CustomLockingCache use the following: In addition, large files of the index are split into a smaller, configurable, chunk. It is often recommended to set the index's chunk_size to the highest value that may be handled efficiently by the network. Hibernate Search already contains internally a default configuration which uses replicated caches to hold the indexes. It is important that if more than one node writes to the index at the same time, configure a JMS backend. For more information on the configuration, see the Hibernate Search documentation. Important In settings where distribution mode is needed to configure, the LuceneIndexesMetadata and LuceneIndexesLocking caches should always use replication mode in all the cases. Report a bug

Commands:
hibernate.search.default.directory_provider=infinispan
hibernate.search.tickets.directory_provider=infinispan hibernate.search.actors.directory_provider=filesystem
hibernate.search.default.directory_provider.locking_cachname="CustomLockingCache"
18.12. Installation Source To specify a file or a location to install Red Hat Enterprise Linux from, select Installation Source from the Installation Summary screen. On this screen, you can choose between locally available installation media such an ISO file, or a network location. Figure 18.8. Installation Source Screen Select one of the following options: ISO file This option will appear if the installation program detected a partitioned hard drive with mountable file systems. Select this option, click the Choose an ISO button, and browse to the installation ISO file's location on your system. Then click Verify to ensure that the file is suitable for installation. On the network To specify a network location, select this option and choose from the following options in the drop-down menu: http:// https:// ftp:// nfs Using your selection as the start of the location URL, type the rest into the address box. If you choose NFS, another box will appear for you to specify any NFS mount options. Important When selecting an NFS-based installation source, you must specify the address with a colon ( : ) character separating the host name from the path. For example: To configure a proxy for an HTTP or HTTPS source, click the Proxy setup button. Check Enable HTTP proxy and type the URL into the Proxy URL box. If your proxy requires authentication, check Use Authentication and enter a user name and password. Click Add . If your HTTP or HTTP URL refers to a repository mirror list, mark the check box under the input field. You can also specify additional repositories to gain access to more installation environments and software add-ons. See Section 18.14, "Software Selection" for more information. To add a repository, click the + button. To delete a repository, click the - button. Click the arrow icon to revert to the list of repositories, that is, to replace current entries with those that were present at the time you entered the Installation Source screen. To activate or deactivate a repository, click the check box in the Enabled column at each entry in the list. In the right part of the form, you can name your additional repository and configure it the same way as the primary repository on the network. Once you have selected your installation source, click Done to return to the Installation Summary screen.

Commands:
server.example.com : /path/to/directory
2.4. Multipath Devices in Logical Volumes After creating multipath devices, you can use the multipath device names just as you would use a physical device name when creating an LVM physical volume. For example, if /dev/mapper/mpatha is the name of a multipath device, the following command will mark /dev/mapper/mpatha as a physical volume. You can use the resulting LVM physical device when you create an LVM volume group just as you would use any other LVM physical device. Note If you attempt to create an LVM physical volume on a whole device on which you have configured partitions, the pvcreate command will fail. Note that the Anaconda and Kickstart installation programs create empty partition tables if you do not specify otherwise for every block device. If you wish to use the whole device rather than a partition, you must remove the existing partitions from the device. You can remove existing partitions with the kpartx -d and the fdisk commands. If your system has block devices that are greater that 2Tb, you can use the parted command to remove partitions. When you create an LVM logical volume that uses active/passive multipath arrays as the underlying physical devices, you should include filters in the lvm.conf to exclude the disks that underlie the multipath devices. This is because if the array automatically changes the active path to the passive path when it receives I/O, multipath will failover and failback whenever LVM scans the passive path if these devices are not filtered. For active/passive arrays that require a command to make the passive path active, LVM prints a warning message when this occurs. To filter all SCSI devices in the LVM configuration file ( lvm.conf ), include the following filter in the devices section of the file.

Commands:
pvcreate /dev/mapper/mpatha
filter = [ "r/block/", "r/disk/", "r/sd.*/", "a/.*/" ]
E.2.21. /proc/mounts This file provides a list of all mounts in use by the system: The output found here is similar to the contents of /etc/mtab , except that /proc/mounts is more up-to-date. The first column specifies the device that is mounted, the second column reveals the mount point, and the third column tells the file system type, and the fourth column tells you if it is mounted read-only ( ro ) or read-write ( rw ). The fifth and sixth columns are dummy values designed to match the format used in /etc/mtab .

Commands:
rootfs / rootfs rw 0 0 /proc /proc proc rw,nodiratime 0 0 none /dev ramfs rw 0 0 /dev/mapper/VolGroup00-LogVol00 / ext3 rw 0 0 none /dev ramfs rw 0 0 /proc /proc proc rw,nodiratime 0 0 /sys /sys sysfs rw 0 0 none /dev/pts devpts rw 0 0 usbdevfs /proc/bus/usb usbdevfs rw 0 0 /dev/hda1 /boot ext3 rw 0 0 none /dev/shm tmpfs rw 0 0 none /proc/sys/fs/binfmt_misc binfmt_misc rw 0 0 sunrpc /var/lib/nfs/rpc_pipefs rpc_pipefs rw 0 0