mtpti5iD/redhat-docs_dataset huggingface dataset:
Appendix A. Using an NFS share for content storage Your environment requires adequate hard disk space to fulfill content storage. In some situations, it is useful to use an NFS share to store this content. This appendix shows how to mount the NFS share on your Satellite Server's content management component. Important Use high-bandwidth, low-latency storage for the /var/lib/pulp file system. Red Hat Satellite has many I/O-intensive operations; therefore, high-latency, low-bandwidth storage might have issues with performance degradation. Procedure Create the NFS share. This example uses a share at nfs.example.com:/Satellite/pulp . Ensure this share provides the appropriate permissions to Satellite Server and its apache user. Stop Satellite services on your Satellite Server: Ensure Satellite Server has the nfs-utils package installed: You need to copy the existing contents of /var/lib/pulp to the NFS share. First, mount the NFS share to a temporary location: Copy the existing contents of /var/lib/pulp to the temporary location: Set the permissions for all files on the share to use the pulp user. Unmount the temporary storage location: Remove the existing contents of /var/lib/pulp : Edit the /etc/fstab file and add the following line: This makes the mount persistent across system reboots. Ensure to include the SELinux context. Enable the mount: Confirm the NFS share mounts to var/lib/pulp : Also confirm that the existing content exists at the mount on var/lib/pulp : Start Satellite services on your Satellite Server: Satellite Server now uses the NFS share to store content. Run a content synchronization to ensure the NFS share works as expected. For more information, see Section 4.7, "Synchronizing repositories" .

Commands:
satellite-maintain service stop
satellite-maintain packages install nfs-utils
mkdir /mnt/temp mount -o rw nfs.example.com:/Satellite/pulp /mnt/temp
cp -r /var/lib/pulp/* /mnt/temp/.
umount /mnt/temp
rm -rf /var/lib/pulp/*
nfs.example.com:/Satellite/pulp /var/lib/pulp nfs rw,hard,intr,context="system_u:object_r:pulpcore_var_lib_t:s0"
mount -a
df Filesystem 1K-blocks Used Available Use% Mounted on nfs.example.com:/Satellite/pulp 309506048 58632800 235128224 20% /var/lib/pulp
ls /var/lib/pulp
satellite-maintain service start
24.4. Viewing Block Devices and File Systems 24.4.1. Using the lsblk Command The lsblk command allows you to display a list of available block devices. To do so, type the following at a shell prompt: lsblk For each listed block device, the lsblk command displays the device name ( NAME ), major and minor device number ( MAJ:MIN ), if the device is removable ( RM ), what is its size ( SIZE ), if the device is read-only ( RO ), what type is it ( TYPE ), and where the device is mounted ( MOUNTPOINT ). For example: By default, lsblk lists block devices in a tree-like format. To display the information as an ordinary list, add the -l command-line option: lsblk -l For instance: For a complete list of available command-line options, see the lsblk (8) manual page.

Commands:
~]USD lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sr0 11:0 1 1024M 0 rom vda 252:0 0 20G 0 rom |-vda1 252:1 0 500M 0 part /boot `-vda2 252:2 0 19.5G 0 part |-vg_kvm-lv_root (dm-0) 253:0 0 18G 0 lvm / `-vg_kvm-lv_swap (dm-1) 253:1 0 1.5G 0 lvm [SWAP]
~]USD lsblk -l NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sr0 11:0 1 1024M 0 rom vda 252:0 0 20G 0 rom vda1 252:1 0 500M 0 part /boot vda2 252:2 0 19.5G 0 part vg_kvm-lv_root (dm-0) 253:0 0 18G 0 lvm / vg_kvm-lv_swap (dm-1) 253:1 0 1.5G 0 lvm [SWAP]
27.2. Disabling Console Program Access To disable access by users to console programs, run the following command as root: In environments where the console is otherwise secured (BIOS and boot loader passwords are set, Ctrl + Alt + Delete is disabled, the power and reset switches are disabled, and so forth), you may not want to allow any user at the console to run poweroff , halt , and reboot , which are accessible from the console by default. To remove these abilities, run the following commands as root:

Commands:
rm -f /etc/security/console.apps/*
rm -f /etc/security/console.apps/poweroff rm -f /etc/security/console.apps/halt rm -f /etc/security/console.apps/reboot
16.10.3. Using virt-win-reg To read out Registry keys, specify the name of the guest virtual machine (or its disk image) and the name of the Registry key. You must use single quotes to surround the name of the desired key: The output is in the standard text-based format used by .REG files on Windows. Note Hex-quoting is used for strings because the format does not properly define a portable encoding method for strings. This is the only way to ensure fidelity when transporting .REG files from one machine to another. You can make hex-quoted strings printable by piping the output of virt-win-reg through this simple Perl script: To merge changes into the Windows Registry of an offline guest virtual machine, you must first prepare a .REG file. There is a great deal of documentation about doing this available here . When you have prepared a .REG file, enter the following: This will update the registry in the guest virtual machine.

Commands:
virt-win-reg WindowsGuest 'HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Uninstall' | less
perl -MEncode -pe's?hex\((\d+)\):(\S+)?USDt=USD1;USD_=USD2;s,\,,,g;"str(USDt):\"".decode(utf16le=>pack("H*",USD_))."\""?eg'
virt-win-reg --merge WindowsGuest input.reg
function::kernel_string2_utf16 Name function::kernel_string2_utf16 - Retrieves UTF-16 string from kernel memory with alternative error string Synopsis Arguments addr The kernel address to retrieve the string from err_msg The error message to return when data isn't available Description This function returns a null terminated UTF-8 string converted from the UTF-16 string at a given kernel memory address. Reports the given error message on string copy fault or conversion error.

Commands:
kernel_string2_utf16:string(addr:long,err_msg:string)
2.2. Global Inventory The top section of the Dashboard provides a global inventory of the Red Hat Virtualization resources and includes items for data centers, clusters, hosts, storage domains, virtual machines, and events. Icons show the status of each resource and numbers show the quantity of the each resource with that status. Figure 2.2. Global Inventory The title shows the number of a type of resource and their status is displayed below the title. Clicking on the resource title navigates to the related page in the Red Hat Virtualization Manager. The status for Clusters is always displayed as N/A. Table 2.1. Resource Status Icon Status None of that resource added to Red Hat Virtualization. Shows the number of a resource with a warning status. Clicking on the icon navigates to the appropriate page with the search limited to that resource with a warning status. The search is limited differently for each resource: Data Centers : The search is limited to data centers that are not operational or non-responsive. Gluster Volumes : The search is limited to gluster volumes that are powering up, paused, migrating, waiting, suspended, or powering down. Hosts : The search is limited to hosts that are unassigned, in maintenance mode, installing, rebooting, preparing for maintenance, pending approval, or connecting. Storage Domains : The search is limited to storage domains that are uninitialized, unattached, inactive, in maintenance mode, preparing for maintenance, detaching, or activating. Virtual Machines : The search is limited to virtual machines that are powering up, paused, migrating, waiting, suspended, or powering down. Events : The search is limited to events with the severity of warning. Shows the number of a resource with an up status. Clicking on the icon navigates to the appropriate page with the search limited to resources that are up. Shows the number of a resource with a down status. Clicking on the icon navigates to the appropriate page with the search limited to resources with a down status. The search is limited differently for each resource: Data Centers : The search is limited to data centers that are uninitialized, in maintenance mode, or with a down status. Gluster Volumes : The search is limited to gluster volumes that are detached or inactive. Hosts : The search is limited to hosts that are non-responsive, have an error, have an installation error, non-operational, initializing, or down. Storage Domains : The search is limited to storage domains that are detached or inactive. Virtual Machines : The search is limited to virtual machines that are down, not responding, or rebooting. Shows the number of events with an alert status. Clicking on the icon navigates to Events with the search limited to events with the severity of alert. Shows the number of events with an error status. Clicking on the icon navigates to Events with the search limited to events with the severity of error.

Commands:
Chapter 4. Technology Preview Technology Preview features provide early access to upcoming product innovations, enabling you to test functionality and provide feedback during the development process. However, these features are not fully supported under Red Hat Subscription Level Agreements, may not be functionally complete, and are not intended for production use. As Red Hat considers making future iterations of Technology Preview features generally available, we will attempt to resolve any issues that customers experience when using these features. See: Technology Preview support scope . None.

Commands:
Preface You can convert a standalone Red Hat Virtualization Manager to a self-hosted engine by backing up the standalone Manager and restoring it in a new self-hosted environment. The difference between the two environment types is explained below: Standalone Manager Architecture The Red Hat Virtualization Manager runs on a physical server, or a virtual machine hosted in a separate virtualization environment. A standalone Manager is easier to deploy and manage, but requires an additional physical server. The Manager is only highly available when managed externally with a product such as Red Hat's High Availability Add-On. The minimum setup for a standalone Manager environment includes: One Red Hat Virtualization Manager machine. The Manager is typically deployed on a physical server. However, it can also be deployed on a virtual machine, as long as that virtual machine is hosted in a separate environment. The Manager must run on Red Hat Enterprise Linux 7. A minimum of two hosts for virtual machine high availability. You can use Red Hat Enterprise Linux hosts or Red Hat Virtualization Hosts (RHVH). VDSM (the host agent) runs on all hosts to facilitate communication with the Red Hat Virtualization Manager. One storage service, which can be hosted locally or on a remote server, depending on the storage type used. The storage service must be accessible to all hosts. Figure 1. Standalone Manager Red Hat Virtualization Architecture Self-Hosted Engine Architecture The Red Hat Virtualization Manager runs as a virtual machine on self-hosted engine nodes (specialized hosts) in the same environment it manages. A self-hosted engine environment requires one less physical server, but requires more administrative overhead to deploy and manage. The Manager is highly available without external HA management. The minimum setup of a self-hosted engine environment includes: One Red Hat Virtualization Manager virtual machine that is hosted on the self-hosted engine nodes. The RHV-M Appliance is used to automate the installation of a Red Hat Enterprise Linux 7 virtual machine, and the Manager on that virtual machine. A minimum of two self-hosted engine nodes for virtual machine high availability. You can use Red Hat Enterprise Linux hosts or Red Hat Virtualization Hosts (RHVH). VDSM (the host agent) runs on all hosts to facilitate communication with the Red Hat Virtualization Manager. The HA services run on all self-hosted engine nodes to manage the high availability of the Manager virtual machine. One storage service, which can be hosted locally or on a remote server, depending on the storage type used. The storage service must be accessible to all hosts. Figure 2. Self-Hosted Engine Red Hat Virtualization Architecture

Commands:
5.3.8. Changing the Parameters of a Volume Group The vgchange command is used to deactivate and activate volume groups, as described in Section 5.3.9, "Activating and Deactivating Volume Groups" . You can also use this command to change several volume group parameters for an existing volume group. The following command changes the maximum number of logical volumes of volume group vg00 to 128. For a description of the volume group parameters you can change with the vgchange command, see the vgchange (8) man page.

Commands:
vgchange -l 128 /dev/vg00
5.4. Frontend Settings The frontend settings configure the servers' listening sockets for client connection requests. A typical HAProxy configuration of the frontend may look like the following: The frontend called main is configured to the 192.168.0.10 IP address and listening on port 80 using the bind parameter. Once connected, the use backend specifies that all sessions connect to the app back end.

Commands:
frontend main bind 192.168.0.10:80 default_backend app
7.196. python-psycopg2 7.196.1. RHBA-2013:0327 - python-psycopg2 bug fix and enhancement update Updated python-psycopg2 packages that fix multiple bugs and add various enhancements are now available for Red Hat Enterprise Linux 6. The python-psycopg2 packages provide a PostgreSQL database adapter for the Python programming language (like pygresql and popy). The main advantages of psycopg2 are that it supports the full Python DBAPI-2.0 and that it is thread safe at level 2. Note The python-psycopg2 packages have been upgraded to upstream version 2.0.14, which provides a number of bug fixes and enhancements over the version, including the fix for a memory leak in cursor handling. This update also ensures better compatibility with the PostgreSQL object-relational database management system version 8.4. (BZ# 765998 ) Bug Fixes BZ# 711095 Prior to this update, a copy operation terminated unexpectedly if a second thread in a single application triggered the Python garbage collection while the copy operation was in progress. This update adds the appropriate object reference count adjustments to the code. BZ# 843723 Prior to this update, object reference counting could, under certain circumstances, cause assertion failures in Python. This update modifies the underlying code to avoid these failures. All users of psycopg2 are advised to upgrade to these updated packages, which fix these bugs and add these enhancements.

Commands:
Chapter 146. KafkaNodePoolTemplate schema reference Used in: KafkaNodePoolSpec Property Description podSet Template for Kafka StrimziPodSet resource. ResourceTemplate pod Template for Kafka Pods . PodTemplate perPodService Template for Kafka per-pod Services used for access from outside of OpenShift. ResourceTemplate perPodRoute Template for Kafka per-pod Routes used for access from outside of OpenShift. ResourceTemplate perPodIngress Template for Kafka per-pod Ingress used for access from outside of OpenShift. ResourceTemplate persistentVolumeClaim Template for all Kafka PersistentVolumeClaims . ResourceTemplate kafkaContainer Template for the Kafka broker container. ContainerTemplate initContainer Template for the Kafka init container. ContainerTemplate

Commands:
8.104. lksctp-tools 8.104.1. RHBA-2013:1726 - lksctp-tools bug fix and enhancement update Updated lksctp-tools packages that fix several bugs and add various enhancements are now available for Red Hat Enterprise Linux 6. These packages are intended to supplement the Stream Control Transmission Protocol (SCTP) implementation, which has been a part of the kernel since kernel version 2.5.36. For more information on LKSCTP see the section titled "LKSCTP - Linux Kernel SCTP" in the README file included in the package documentation. These packages contain the base runtime library and command line tools. Note The lksctp-tools packages have been upgraded to upstream version 1.0.10, which provide a number of bug fixes and enhancements over the version. The patches include updates in the header file which enable users to make use of new SCTP kernel features, for example, the introduction of SCTP_GET_ASSOC_STATS socket option in order to retrieve association statistics. (BZ# 855379 , BZ# 908390 , BZ# 912557 , BZ# 953383 ) Users of lksctp-tools are advised to upgrade to these updated packages, which fix these bugs and add these enhancements.

Commands:
3.2. Configuring Fence Devices Configuring fence devices consists of creating, updating, and deleting fence devices for the cluster. You must configure the fence devices in a cluster before you can configure fencing for the nodes in the cluster. Creating a fence device consists of selecting a fence device type and entering parameters for that fence device (for example, name, IP address, login, and password). Updating a fence device consists of selecting an existing fence device and changing parameters for that fence device. Deleting a fence device consists of selecting an existing fence device and deleting it. This section provides procedures for the following tasks: Creating fence devices - Refer to Section 3.2.1, "Creating a Fence Device" . Once you have created and named a fence device, you can configure the fence devices for each node in the cluster, as described in Section 3.3, "Configuring Fencing for Cluster Members" . Updating fence devices - Refer to Section 3.2.2, "Modifying a Fence Device" . Deleting fence devices - Refer to Section 3.2.3, "Deleting a Fence Device" . From the cluster-specific page, you can configure fence devices for that cluster by clicking on Fence Devices along the top of the cluster display. This displays the fence devices for the cluster and displays the menu items for fence device configuration: Add and Delete . This is the starting point of each procedure described in the following sections. Note If this is an initial cluster configuration, no fence devices have been created, and therefore none are displayed. Figure 3.1, "luci fence devices configuration page" shows the fence devices configuration screen before any fence devices have been created. Figure 3.1. luci fence devices configuration page 3.2.1. Creating a Fence Device To create a fence device, follow these steps: From the Fence Devices configuration page, click Add . Clicking Add displays the Add Fence Device (Instance) dialog box. From this dialog box, select the type of fence device to configure. Specify the information in the Add Fence Device (Instance) dialog box according to the type of fence device. In some cases you will need to specify additional node-specific parameters for the fence device when you configure fencing for the individual nodes. Click Submit . After the fence device has been added, it appears on the Fence Devices configuration page.

Commands:
Chapter 12. Kafka Streams API overview The Kafka Streams API allows applications to receive data from one or more input streams, execute complex operations like mapping, filtering or joining, and write the results into one or more output streams. It is part of the kafka-streams JAR package that is available in the Red Hat Maven repository. 12.1. Adding the Kafka Streams API as a dependency to your Maven project This procedure shows you how to add the AMQ Streams Java clients as a dependency to your Maven project. Prerequisites A Maven project with an existing pom.xml . Procedure Add the Red Hat Maven repository to the <repositories> section of your pom.xml file. Add kafka-streams to the <dependencies> section of your pom.xml file. Build your Maven project.

Commands:
<?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <!-- ... --> <repositories> <repository> <id>redhat-maven</id> <url>https://maven.repository.redhat.com/ga/</url> </repository> </repositories> <!-- ... --> </project>
<?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <!-- ... --> <dependencies> <dependency> <groupId>org.apache.kafka</groupId> <artifactId>kafka-streams</artifactId> <version>2.7.0.redhat-00005</version> </dependency> </dependencies> <!-- ... --> </project>
26.9. Replacing the Web Server's and LDAP Server's Certificate To replace the service certificates for the web server and LDAP server: Request a new certificate. You can do this using: the integrated CA: see Section 24.1.1, "Requesting New Certificates for a User, Host, or Service" for details. an external CA: generate a private key and certificate signing request (CSR). For example, using OpenSSL: Submit the CSR to the external CA. The process differs depending on the service to be used as the external CA. Replace the Apache web server's private key and certificate: Replace the LDAP server's private key and certificate:

Commands:
openssl req -new -newkey rsa:2048 -days 365 -nodes -keyout new.key -out new.csr -subj '/CN= idmserver.idm.example.com ,O= IDM.EXAMPLE.COM '
ipa-server-certinstall -w --pin= password new.key new.crt
ipa-server-certinstall -d --pin= password new.key new.cert
7.162. policycoreutils 7.162.1. RHBA-2015:1360 - policycoreutils bug fix update Updated policycoreutils packages that fix several bugs are now available for Red Hat Enterprise Linux 6. The policycoreutils packages contain the core utilities that are required for the basic operation of a Security-Enhanced Linux (SELinux) system and its policies. Bug Fixes BZ# 995778 Previously, the sepolgen utility was a part of the policycore-gui package, even though it does not require any GUI. With this update, sepolgen is a part of the policycore-python package. BZ# 1111999 The "audit2allow -br" command did not work properly when the "LANG" environment variable was set to a different language than "US/English". The underlying source code has been modified, and "audit2allow -br" now works as expected. BZ# 1113083 When running the fixfiles utility in "verify" or "check" mode, fixfiles changed certain SELinux contexts even if it was not supposed to. With this update, fixfiles has been modified to only print incorrect SELinux contexts instead of changing them when running in aforementioned modes. BZ# 1122850 The semanage utility previously listed only changes made to the currently used SELinux policy. For example, when the targeted policy was loaded and changes were made to the Multi-Level Security (MLS) policy, the "semanage -S mls -o" command did not list all the changes, even when the changes were applied correctly. This bug has been fixed, and semanage now lists all changes as expected. BZ# 1148062 A new "noreload" option was implemented for semanage commands in Red Hat Enterprise Linux 6.6. However, due to a missing reload initialization in the semanageRecords() function, users could not enable Booleans directly using the seobject python module that comes from the policycoreutils-python utility. This bug has been fixed, and users can now set Booleans correctly using the seobject python module. Users of policycoreutils are advised to upgrade to these updated packages, which fix these bugs.

Commands: