mtpti5iD/redhat-docs_dataset huggingface dataset:
10.2.5. Creating a Guest Virtual Machine Disk Backup libvirt can communicate with qemu-ga to assure that snapshots of guest virtual machine file systems are consistent internally and ready for use on an as needed basis. Improvements in Red Hat Enterprise Linux 6 have been made to make sure that both file and application level synchronization (flushing) is done. Guest system administrators can write and install application-specific freeze/thaw hook scripts. Before freezing the filesystems, the qemu-ga invokes the main hook script (included in the qemu-ga package). The freezing process temporarily deactivates all guest virtual machine applications. Just before filesystems are frozen, the following actions occur: File system applications / databases flush working buffers to the virtual disk and stop accepting client connections Applications bring their data files into a consistent state Main hook script returns qemu-ga freezes the filesystems and management stack takes a snapshot Snapshot is confirmed Filesystem function resumes Thawing happens in reverse order. Use the snapshot-create-as command to create a snapshot of the guest disk. See Section 14.15.2.2, "Creating a snapshot for the current domain" for more details on this command. Note An application-specific hook script might need various SELinux permissions in order to run correctly, as is done when the script needs to connect to a socket in order to talk to a database. In general, local SELinux policies should be developed and installed for such purposes. Accessing file system nodes should work out of the box, after issuing the restorecon -FvvR command listed in Table 10.1, "QEMU guest agent package contents" in the table row labeled /etc/qemu-ga/fsfreeze-hook.d/ . The qemu-guest-agent binary RPM includes the following files: Table 10.1. QEMU guest agent package contents File name Description /etc/rc.d/init.d/qemu-ga Service control script (start/stop) for the QEMU guest agent. /etc/sysconfig/qemu-ga Configuration file for the QEMU guest agent, as it is read by the /etc/rc.d/init.d/qemu-ga control script. The settings are documented in the file with shell script comments. /usr/bin/qemu-ga QEMU guest agent binary file. /usr/libexec/qemu-ga/ Root directory for hook scripts. /usr/libexec/qemu-ga/fsfreeze-hook Main hook script. No modifications are needed here. /usr/libexec/qemu-ga/fsfreeze-hook.d/ Directory for individual, application-specific hook scripts. The guest system administrator should copy hook scripts manually into this directory, ensure proper file mode bits for them, and then run restorecon -FvvR on this directory. /usr/share/qemu-kvm/qemu-ga/ Directory with sample scripts (for example purposes only). The scripts contained here are not executed. The main hook script, /usr/libexec/qemu-ga/fsfreeze-hook logs its own messages, as well as the application-specific script's standard output and error messages, in the following log file: /var/log/qemu-ga/fsfreeze-hook.log . For more information, refer to the qemu-guest-agent wiki page at wiki.qemu.org or libvirt.org .

Commands:
4.237. prelink 4.237.1. RHEA-2011:1768 - prelink enhancement update An updated prelink package that adds one enhancement is now available for Red Hat Enterprise Linux 6. The prelink utility is used to modify ELF shared libraries and executables. It reduces the number of relocations that need to be resolved at runtime, and thus enables faster start-up. Enhancement BZ# 739460 To improve performance on AMD Family 15h processors, the prelink utility has been adapted to align 32-bit libraries on 32 KB boundaries. All users of prelink are advised to upgrade to this updated package, which adds this enhancement.

Commands:
5.3. Understanding Domain Transitions: sepolicy transition Previously, the setrans utility was used to examine if transition between two domain or process types is possible and printed out all intermediary types that are used to transition between these domains or processes. In Red Hat Enterprise Linux 7, setrans is provided as part of the sepolicy suite and the sepolicy transition command is now used instead. The sepolicy transition command queries a SELinux policy and creates a process transition report. The sepolicy transition command requires two command-line arguments - a source domain (specified by the -s option) and a target domain (specified by the -t option). If only the source domain is entered, sepolicy transition lists all possible domains that the source domain can transition to. The following output does not contain all entries. The " @ " character means " execute " : If the target domain is specified, sepolicy transition examines SELinux policy for all transition paths from the source domain to the target domain and lists these paths. The output below is not complete: See the sepolicy-transition (8) manual page for further information about sepolicy transition .

Commands:
~]USD sepolicy transition -s httpd_t httpd_t @ httpd_suexec_exec_t --> httpd_suexec_t httpd_t @ mailman_cgi_exec_t --> mailman_cgi_t httpd_t @ abrt_retrace_worker_exec_t --> abrt_retrace_worker_t httpd_t @ dirsrvadmin_unconfined_script_exec_t --> dirsrvadmin_unconfined_script_t httpd_t @ httpd_unconfined_script_exec_t --> httpd_unconfined_script_t
~]USD sepolicy transition -s httpd_t -t system_mail_t httpd_t @ exim_exec_t --> system_mail_t httpd_t @ courier_exec_t --> system_mail_t httpd_t @ sendmail_exec_t --> system_mail_t httpd_t ... httpd_suexec_t @ sendmail_exec_t --> system_mail_t httpd_t ... httpd_suexec_t @ exim_exec_t --> system_mail_t httpd_t ... httpd_suexec_t @ courier_exec_t --> system_mail_t httpd_t ... httpd_suexec_t ... httpd_mojomojo_script_t @ sendmail_exec_t --> system_mail_t
4.3. Supported Web Browsers Certificate System 10.0 supports the following browsers: Table 4.1. Supported Web Browsers by Platform Platform Agent Services End User Pages Red Hat Enterprise Linux Firefox 60 and later [a] Firefox 60 and later [a] [a] This Firefox version no longer supports the crypto web object used to generate and archive keys from the browser. As a result, expect limited functionality in this area. Note The only fully-supported browser for the HTML-based instance configuration is Mozilla Firefox.

Commands:
10.4. Cloning OCSP Subsystems Configure the master OCSP, and back up the keys. In the CS.cfg file for the master OCSP, set the OCSP.Responder.store.defStore.refreshInSec parameter to any non-zero number other than 21600; 21600 is the setting for a clone. Create the clone subsystem instance using the pkispawn utility. For examples of the configuration file required by pkispawn when cloning OCSP subsystems, see the pkispawn (8) man page. Restart the Directory Server instance used by the clone. Note Restarting the Directory Server reloads the updated schema, which is required for proper performance. Restart the clone instance. After configuring the clone, test to make sure that the master-clone relationship is functioning: Set up OCSP publishing in the master CA so that the CRL is published to the master OCSP. Once the CRL is successfully published, check both the master and cloned OCSP's List Certificate Authorities link in the agent pages. The list should be identical. Use the OCSPClient tool to submit OCSP requests to the master and the cloned Online Certificate Status Manager. The tool should receive identical OCSP responses from both managers.

Commands:
vim /etc/ instance_name /CS.cfg OCSP.Responder.store.defStore.refreshInSec=15000
systemctl dirsrv@ instance_name .service
pki-server restart instance_name
2.2. Types of Storage Backing Storage Domains Storage domains can be implemented using block based and file based storage. File Based Storage The file based storage types supported by Red Hat Virtualization are NFS, GlusterFS, other POSIX compliant file systems, and storage local to hosts. Note GlusterFS Storage is deprecated, and will no longer be supported in future releases. File based storage is managed externally to the Red Hat Virtualization environment. NFS storage is managed by a Red Hat Enterprise Linux NFS server, or other third party network attached storage server. Hosts can manage their own local storage file systems. Block Based Storage Block storage uses unformatted block devices. Block devices are aggregated into volume groups by the Logical Volume Manager (LVM). An instance of LVM runs on all hosts, unaware of the instances running on other hosts. VDSM adds clustering logic on top of LVM by scanning volume groups for changes. When changes are detected, VDSM updates individual hosts by telling them to refresh their volume group information. The hosts divide the volume group into logical volumes, writing logical volume metadata to disk. If more storage capacity is added to an existing storage domain, the Red Hat Virtualization Manager causes VDSM on each host to refresh volume group information. A Logical Unit Number (LUN) is an individual block device. One of the supported block storage protocols, iSCSI or Fibre Channel, is used to connect to a LUN. The Red Hat Virtualization Manager manages software iSCSI connections to the LUNs. All other block storage connections are managed externally to the Red Hat Virtualization environment. Any changes in a block based storage environment, such as the creation of logical volumes, extension or deletion of logical volumes and the addition of a new LUN are handled by LVM on a specially selected host called the Storage Pool Manager. Changes are then synced by VDSM which storage metadata refreshes across all hosts in the cluster.

Commands:
8.128. numactl 8.128.1. RHBA-2013:1712 - numactl bug fix update Updated numactl packages that fix two bugs are now available for Red Hat Enterprise Linux 6. The numactl packages provide a simple Non-Uniform Memory Access (NUMA) policy support and consist of the numactl program to run other programs with a specific NUMA policy and the libnuma library to do allocations in applications using the NUMA policy. Bug Fixes BZ# 881779 Prior to this update, the "localalloc" option was not described clearly in the numactl(8) manual page, which could cause confusion. This update adds a clear description of "localalloc" to the numactl(8) manual page. BZ# 987507 Due to a bug in the numastat utility source code, output of the "numastat -m" command reported incorrect values of the amount of allocated static huge page memory. A patch has been applied to address this bug, and numastat now calculates huge page sizes properly. Users of numactl are advised to upgrade to these updated packages, which fix these bugs.

Commands:
Chapter 4. Using Builds in a network-restricted environment The Red Hat OpenShift Pipelines Operator provides support for injecting the proxy environment variables in the network-restricted environments. 4.1. Verifying cluster-wide proxy As a cluster administrator, you can verify the cluster-wide proxy settings. Procedure To verify if the cluster-wide proxy is correctly configured, run the following command: USD oc describe proxy/cluster The cluster proxy object displays the proxy server and certificate information. 4.2. Verifying the proxy environment variables As a cluster administrator, you can verify the environment variables to ensure that the proxy settings are correctly configured for builds for Red Hat OpenShift on an OpenShift Container Platform cluster. Procedure To verify the environment variables, run the following command: USD oc set env deployment/openshift-builds-operator --list -n openshift-builds | grep PROXY The following example output lists the HTTP_PROXY , HTTPS_PROXY , and NO_PROXY environment variables: HTTP_PROXY=http://192.168.130.1:3128 HTTPS_PROXY=https://192.168.130.1:3129 NO_PROXY=.cluster.local,.svc,.testing,10.217.0.0/22,10.217.4.0/23,127.0.0.1,192.168.126.0/24,192.168.1 30.11,api-int.crc.testing,localhost 4.3. Additional resources Red Hat OpenShift Pipelines Operator in a restricted environment Configuring cluster-wide proxy

Commands:
oc describe proxy/cluster
oc set env deployment/openshift-builds-operator --list -n openshift-builds | grep PROXY
HTTP_PROXY=http://192.168.130.1:3128 HTTPS_PROXY=https://192.168.130.1:3129 NO_PROXY=.cluster.local,.svc,.testing,10.217.0.0/22,10.217.4.0/23,127.0.0.1,192.168.126.0/24,192.168.1 30.11,api-int.crc.testing,localhost
2.8.3.2. Basic Firewall Policies Establishing basic firewall policies creates a foundation for building more detailed, user-defined rules. Each iptables chain is comprised of a default policy, and zero or more rules which work in concert with the default policy to define the overall ruleset for the firewall. The default policy for a chain can be either DROP or ACCEPT. Security-minded administrators typically implement a default policy of DROP, and only allow specific packets on a case-by-case basis. For example, the following policies block all incoming and outgoing packets on a network gateway: It is also recommended that any forwarded packets - network traffic that is to be routed from the firewall to its destination node - be denied as well, to restrict internal clients from inadvertent exposure to the Internet. To do this, use the following rule: When you have established the default policies for each chain, you can create and save further rules for your particular network and security requirements. The following sections describe how to save iptables rules and outline some of the rules you might implement in the course of building your iptables firewall.

Commands:
~]# iptables -P INPUT DROP ~]# iptables -P OUTPUT DROP
~]# iptables -P FORWARD DROP
6.3. IPsec Installation Implementing IPsec requires that the ipsec-tools RPM package be installed on all IPsec hosts (if using a host-to-host configuration) or routers (if using a network-to-network configuration). The RPM package contains essential libraries, daemons, and configuration files to aid in setup of the IPsec connection, including: /sbin/setkey - manipulates the key management and security attributes of IPsec in the kernel. This executable is controlled by the racoon key management daemon. For more information on setkey , refer to the setkey (8) man page. /sbin/racoon - the IKE key management daemon, used to manage and control security associations and key sharing between IPsec-connected systems. This daemon can be configured by editing the /etc/racoon/racoon.conf file. For more information about racoon , refer to the racoon (8) man page. /etc/racoon/racoon.conf - the racoon daemon configuration file used to configure various aspects of the IPsec connection, including authentication methods and encryption algorithms used in the connection. For a complete listing of directives available, refer to the racoon.conf (5) man page. Configuring IPsec on Red Hat Enterprise Linux can be done via the Network Administration Tool or by manually editing networking and IPsec configuration files. For more information about using the Network Administration Tool , refer to the System Administrators Guide . To connect two network-connected hosts via IPsec, refer to Section 6.4, "IPsec Host-to-Host Configuration" . To connect one LAN/WAN to another via IPsec, refer to Section 6.5, "IPsec Network-to-Network configuration" .

Commands:
Chapter 5. Deleting a machine You can delete a specific machine. 5.1. Deleting a specific machine You can delete a specific machine. Note You cannot delete a control plane machine. Prerequisites Install an OpenShift Container Platform cluster. Install the OpenShift CLI ( oc ). Log in to oc as a user with cluster-admin permission. Procedure View the machines that are in the cluster by running the following command: USD oc get machine -n openshift-machine-api The command output contains a list of machines in the <clusterid>-<role>-<cloud_region> format. Identify the machine that you want to delete. Delete the machine by running the following command: USD oc delete machine <machine> -n openshift-machine-api Important By default, the machine controller tries to drain the node that is backed by the machine until it succeeds. In some situations, such as with a misconfigured pod disruption budget, the drain operation might not be able to succeed. If the drain operation fails, the machine controller cannot proceed removing the machine. You can skip draining the node by annotating machine.openshift.io/exclude-node-draining in a specific machine. If the machine that you delete belongs to a machine set, a new machine is immediately created to satisfy the specified number of replicas. 5.2. Additional resources Replacing an unhealthy etcd member .

Commands:
oc get machine -n openshift-machine-api
oc delete machine <machine> -n openshift-machine-api
Preface OpenJDK (Open Java Development Kit) is a free and open source implementation of the Java Platform, Standard Edition (Java SE). The Red Hat build of OpenJDK is available in three versions: 8u, 11u, and 17u. Packages for the Red Hat build of OpenJDK are available on Red Hat Enterprise Linux and Microsoft Windows platforms and shipped as a JDK and a JRE in the Red Hat Ecosystem Catalog.

Commands:
Preface Red Hat OpenShift Data Foundation supports deployment on existing Red Hat OpenShift Container Platform (RHOCP) IBM Power clusters in connected or disconnected environments along with out-of-the-box support for proxy environments. Both internal and external OpenShift Data Foundation clusters are supported on IBM Power. See Planning your deployment and Preparing to deploy OpenShift Data Foundation for more information about deployment requirements. To deploy OpenShift Data Foundation, follow the appropriate deployment process based on your requirement: Internal-Attached Devices mode Deploy using local storage devices Deploy standalone Multicloud Object Gateway component External mode using Red Hat Ceph Storage External mode

Commands:
2.3. LVM Logical Volumes In LVM, a volume group is divided up into logical volumes. There are three types of LVM logical volumes: linear volumes, striped volumes, and mirrored volumes. These are described in the following sections. 2.3.1. Linear Volumes A linear volume aggregates multiple physical volumes into one logical volume. For example, if you have two 60GB disks, you can create a 120GB logical volume. The physical storage is concatenated. Creating a linear volume assigns a range of physical extents to an area of a logical volume in order. For example, as shown in Figure 2.2, "Extent Mapping" logical extents 1 to 99 could map to one physical volume and logical extents 100 to 198 could map to a second physical volume. From the point of view of the application, there is one device that is 198 extents in size. Figure 2.2. Extent Mapping The physical volumes that make up a logical volume do not have to be the same size. Figure 2.3, "Linear Volume with Unequal Physical Volumes" shows volume group VG1 with a physical extent size of 4MB. This volume group includes 2 physical volumes named PV1 and PV2 . The physical volumes are divided into 4MB units, since that is the extent size. In this example, PV1 is 100 extents in size (400MB) and PV2 is 200 extents in size (800MB). You can create a linear volume any size between 1 and 300 extents (4MB to 1200MB). In this example, the linear volume named LV1 is 300 extents in size. Figure 2.3. Linear Volume with Unequal Physical Volumes You can configure more than one linear logical volume of whatever size you desire from the pool of physical extents. Figure 2.4, "Multiple Logical Volumes" shows the same volume group as in Figure 2.3, "Linear Volume with Unequal Physical Volumes" , but in this case two logical volumes have been carved out of the volume group: LV1 , which is 250 extents in size (1000MB) and LV2 which is 50 extents in size (200MB). Figure 2.4. Multiple Logical Volumes

Commands:
B.15.3. RHBA-2011:0384 - device-mapper-multipath bug fix update Updated device-mapper-multipath packages that resolve an issue are now available for Red Hat Enterprise Linux 6. The device-mapper-multipath packages provide tools to manage multipath devices by giving the "dm-multipath" kernel module instructions on what to do, as well as by managing the creation and removal of partitions for Device-Mapper devices. Bug Fix BZ# 684684 Prior to this update, multipathd did not always remove a path's sysfs device from cache when the path was removed. Also, multipathd searched the cache and created sysfs devices without the 'vecs' lock held. As a result, paths would occasionally have invalid sysfs devices, causing multipathd crashes and other errors. With this update, multipathd always removes the sysfs device from cache when deleting the path, and it only accesses the cache with the 'vecs' lock held. All users of device-mapper-multipath are advised to upgrade to these updated packages, which resolve this issue.

Commands:
Chapter 13. Eliminating typographical errors in local SSSD configuration You can test if the /etc/sssd/sssd.conf file on your host contains any typographical errors using the sssctl config-check command. Prerequisites You are logged in as root. The sssd-tools package is installed. Procedure Enter the sssctl config-check command: Open the /etc/sssd/sssd.conf file and correct the typo. If you, for example, received the error message in the step, replace ldap_search with ldap_search_base : Save the file. Restart SSSD: Verification Enter the sssctl config-check command: The /etc/sssd/sssd.conf file now has no typographical errors.

Commands:
sssctl config-check Issues identified by validators: 1 [rule/allowed_domain_options]: Attribute 'ldap_search' is not allowed in section 'domain/example1'. Check for typos. Messages generated during configuration merging: 0 Used configuration snippet files: 0
[...] [domain/example1] ldap_search_base = dc=example,dc=com [...]
systemctl restart sssd
sssctl config-check Issues identified by validators: 0 Messages generated during configuration merging: 0 Used configuration snippet files: 0