mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 2. Managing physical device drives using the Web Console 2.1. Creating a partition table using the Web Console Follow these steps to create a new partition table on a drive using the Web Console. Log in to the Web Console. Click the hostname Storage . Click any drive under Drives . The Drive Overview page opens. Click Create partition table . Figure 2.1. Drive Content The Format device window opens. Specify whether to Erase existing data completely by overwriting it with zeroes. Specify the Partitioning style to use. Click Format . 2.2. Formatting a disk partition using the Web Console Follow these steps to format a partition with a file system using the Web Console. Log in to the Web Console. Click the hostname Storage . Click any drive under Drives . The Drive Overview page opens. Click the device under Content . In the Filesystem subtab, click Format . The Filesystem subtab The Format Device window appears. Specify whether to Erase existing data completely by overwriting it with zeroes. Specify the file system Type to use. Specify a Name for the file system. Specify whether to use default or customized Mounting behavior. If you selected Custom , specify a Mount Point and check any Mount options you want this file system to use. Click Format .

Commands:
Chapter 9. Verify your deployment After deployment is complete, verify that your deployment has completed successfully. Browse to the Administration Portal, for example, http://engine.example.com/ovirt-engine . Administration Console Login Log in using the administrative credentials added during hosted engine deployment. When login is successful, the Dashboard appears. Administration Console Dashboard Verify that your cluster is available. Administration Console Dashboard - Clusters Verify that one host is available. Click Compute Hosts . Verify that your host is listed with a Status of Up . Verify that all storage domains are available. Click Storage Domains . Verify that the Active icon is shown in the first column. Administration Console - Storage Domains

Commands:
Chapter 3. Shenandoah garbage collector modes You can run Shenandoah in three different modes. Select a specific mode with the -XX:ShenandoahGCMode=<name> . The following list describes each Shenandoah mode: normal/satb (product, default) This mode runs a concurrent garbage collector (GC) with Snapshot-At-The-Beginning (SATB) marking. This marking mode does the similar work as G1, the default garbage collector for Red Hat build of OpenJDK 11. iu (experimental) This mode runs a concurrent GC with Incremental Update (IU) marking. It can reclaim unreachably memory more aggressively. This marking mode mirrors the SATB mode. This may make marking less conservative, especially around accessing weak references. passive (diagnostic) This mode runs Stop the World Event GCs. This mode is used for functional testing, but sometimes it is useful for bisecting performance anomalies with GC barriers, or to ascertain the actual live data size in the application.

Commands:
Chapter 8. Assigning a Puppet class to an individual host Procedure In the Satellite web UI, navigate to Hosts > All Hosts . Locate the host you want to add the ntp Puppet class to and click Edit . Select the Puppet ENC tab and look for the ntp class. Click the + symbol to ntp to add the ntp submodule to the list of included classes . Click Submit to save your changes. Tip If the Puppet classes tab of an individual host is empty, check if it is assigned to the proper Puppet environment. Verify the Puppet configuration. Navigate to Hosts > All Hosts and select the host. From the top overflow menu, select Legacy UI . Under Details , click Puppet YAML . This produces output similar as follows: --- parameters: // shortened YAML output classes: ntp: servers: '["0.de.pool.ntp.org","1.de.pool.ntp.org","2.de.pool.ntp.org","3.de.pool.ntp.org"]' environment: production ... Verify the ntp configuration. Connect to your host using SSH and check the content of /etc/ntp.conf . This example assumes your host is running CentOS 7 . Other operating systems may store the ntp config file in a different path. Tip You may need to run the Puppet agent on your host by executing the following command: Running the following command on the host checks which ntp servers are used for clock synchronization: This returns output similar as follows: # ntp.conf: Managed by puppet. server 0.de.pool.ntp.org server 1.de.pool.ntp.org server 2.de.pool.ntp.org server 3.de.pool.ntp.org You now have a working ntp module which you can add to a host or group of hosts to roll out your ntp configuration automatically.

Commands:
--- parameters: // shortened YAML output classes: ntp: servers: '["0.de.pool.ntp.org","1.de.pool.ntp.org","2.de.pool.ntp.org","3.de.pool.ntp.org"]' environment: production
puppet agent -t
cat /etc/ntp.conf
ntp.conf: Managed by puppet. server 0.de.pool.ntp.org server 1.de.pool.ntp.org server 2.de.pool.ntp.org server 3.de.pool.ntp.org
8.178. rgmanager 8.178.1. RHBA-2013:1600 - rgmanager bug fix update Updated rgmanager packages that fix two bugs are now available for Red Hat Enterprise Linux 6. The rgmanager package contains the Red Hat Resource Group Manager, which is used to create and manage high-availability server applications in the event of system downtime. Bug Fixes BZ# 862075 Previously, if the main rgmanager process died, either by an unexpected termination with a segmentation fault or by killing it manually, any service running on it, was immediately recovered on another node rather than waiting for fencing, like the rgmanager process did in versions. This was problematic for services containing Highly Available Logical Volume Manager (HA-LVM) resources using tagging, because the start operation failed if the tag that was found belonged to a node that was still a member of the cluster. With this update, service recovery is delayed until after the node is removed from the configuration and fenced, which allows the LVM resource to recover properly. BZ# 983296 Previously, attempts to start an MRG Messaging (MRG-M) broker caused rgmanager to terminate unexpectedly with a segmentation fault. This was caused by subtle memory corruption introduced by calling the pthread_mutex_unlock() function on a mutual exclusion that was not locked. This update addresses scenarios where memory could be corrupted when calling pthread_mutex_unlock(), and rgmanager no longer terminates unexpectedly in the described situation. Users of rgmanager are advised to upgrade to these updated packages, which fix these bugs.

Commands:
5.3. Default Settings The default settings configure parameters that apply to all proxy subsections in a configuration ( frontend , backend , and listen ). A typical default section may look like the following: Note Any parameter configured in proxy subsection ( frontend , backend , or listen ) takes precedence over the parameter value in default . mode specifies the protocol for the HAProxy instance. Using the http mode connects source requests to real servers based on HTTP, ideal for load balancing web servers. For other applications, use the tcp mode. log specifies log address and syslog facilities to which log entries are written. The global value refers the HAProxy instance to whatever is specified in the log parameter in the global section. option httplog enables logging of various values of an HTTP session, including HTTP requests, session status, connection numbers, source address, and connection timers among other values. option dontlognull disables logging of null connections, meaning that HAProxy will not log connections wherein no data has been transferred. This is not recommended for environments such as web applications over the Internet where null connections could indicate malicious activities such as open port-scanning for vulnerabilities. retries specifies the number of times a real server will retry a connection request after failing to connect on the first try. The various timeout values specify the length of time of inactivity for a given request, connection, or response. These values are generally expressed in milliseconds (unless explicitly stated otherwise) but may be expressed in any other unit by suffixing the unit to the numeric value. Supported units are us (microseconds), ms (milliseconds), s (seconds), m (minutes), h (hours) and d (days). http-request 10s gives 10 seconds to wait for a complete HTTP request from a client. queue 1m sets one minute as the amount of time to wait before a connection is dropped and a client receives a 503 or "Service Unavailable" error. connect 10s specifies the number of seconds to wait for a successful connection to a server. client 1m specifies the amount of time (in minutes) a client can remain inactive (it neither accepts nor sends data). server 1m specifies the amount of time (in minutes) a server is given to accept or send data before timeout occurs.

Commands:
defaults mode http log global option httplog option dontlognull retries 3 timeout http-request 10s timeout queue 1m timeout connect 10s timeout client 1m timeout server 1m
B.109. yaboot B.109.1. RHBA-2010:0854 - yaboot bug fix update An updated yaboot package that fixes a bug is now available. The yaboot package is a boot loader for Open Firmware based PowerPC systems. It can be used to boot IBM eServer System p machines. Bug Fix BZ# 642694 Previously, yaboot netboot failed to operate in an environment where the gateway is not same as the 'tftp' server, even though the 'tftp' server is on the same subnet. This issue was caused by yaboot's inability to check whether an IP address is valid. With this update, an IP address validity check has been added that resolves this issue. All users of yaboot are advised to upgrade to this updated package, which resolves this issue.

Commands:
2.3. Recording Statistical History The ETL service collects data into the statistical tables every minute. Data is stored for every minute of the past 24 hours, at a minimum, but can be stored for as long as 48 hours depending on the last time a deletion job was run. Minute-by-minute data more than two hours old is aggregated into hourly data and stored for two months. Hourly data more than two days old is aggregated into daily data and stored for five years. Hourly data and daily data can be found in the hourly and daily tables. Each statistical datum is kept in its respective aggregation level table: samples, hourly, and daily history. All history tables also contain a history_id column to uniquely identify rows. Tables reference the configuration version of a host in order to enable reports on statistics of an entity in relation to its past configuration.

Commands:
2.7. Storage Domain Autorecovery in Red Hat Virtualization Hosts in a Red Hat Virtualization environment monitor storage domains in their data centers by reading metadata from each domain. A storage domain becomes inactive when all hosts in a data center report that they cannot access the storage domain. Rather than disconnecting an inactive storage domain, the Manager assumes that the storage domain has become inactive temporarily, because of a temporary network outage for example. Once every 5 minutes, the Manager attempts to re-activate any inactive storage domains. Administrator intervention may be required to remedy the cause of the storage connectivity interruption, but the Manager handles re-activating storage domains as connectivity is restored.

Commands:
Chapter 30. Adding the IdM CA service to an IdM server in a deployment without a CA If you previously installed an Identity Management (IdM) domain without the certificate authority (CA) component, you can add the IdM CA service to the domain by using the ipa-ca-install command. Depending on your requirements, you can select one of the following options: Note For details on the supported CA configurations, see Planning your CA services . 30.1. Installing the first IdM CA as the root CA into an existing IdM domain If you previously installed Identity Management (IdM) without the certificate authority (CA) component, you can install the CA on an IdM server subsequently. Follow this procedure to install, on the idmserver server, an IdM CA that is not subordinate to any external root CA. Prerequisites You have root permissions on idmserver . The IdM server is installed on idmserver . Your IdM deployment has no CA installed. You know the IdM Directory Manager password. Procedure On idmserver , install the IdM Certificate Server CA: On each IdM host in the topology, run the ipa-certupdate utility to update the host with the information about the new certificate from the IdM LDAP. Important If you do not run ipa-certupdate after generating the IdM CA certificate, the certificate will not be distributed to the other IdM machines. 30.2. Installing the first IdM CA with an external CA as the root CA into an existing IdM domain If you previously installed Identity Management (IdM) without the certificate authority (CA) component, you can install the CA on an IdM server subsequently. Follow this procedure to install, on the idmserver server, an IdM CA that is subordinate to an external root CA, with zero or several intermediate CAs in between. Prerequisites You have root permissions on idmserver . The IdM server is installed on idmserver . Your IdM deployment has no CA installed. You know the IdM Directory Manager password. Procedure Start the installation: Wait till the command line informs you that a certificate signing request (CSR) has been saved. Submit the CSR to the external CA. Copy the issued certificate to the IdM server. Continue the installation by adding the certificates and full path to the external CA files to ipa-ca-install : On each IdM host in the topology, run the ipa-certupdate utility to update the host with the information about the new certificate from the IdM LDAP. Important Failing to run ipa-certupdate after generating the IdM CA certificate means that the certificate will not be distributed to the other IdM machines.

Commands:
[root@idmserver ~] ipa-ca-install
[root@idmserver ~] ipa-ca-install --external-ca
ipa-ca-install --external-cert-file=/root/master.crt --external-cert-file=/root/ca.crt
3.7. Selecting an Installation Method What type of installation method do you wish to use? The following installation methods are available: DVD If you have a DVD drive and the Red Hat Enterprise Linux DVD you can use this method. Refer to Section 8.3.1, "Installing from a DVD" , for DVD installation instructions. If you booted the installation from a piece of media other than the installation DVD, you can specify the DVD as the installation source with the linux askmethod or linux repo=cdrom: device :/ device boot option, or by selecting Local CD/DVD on the Installation Method menu (refer to Section 8.3, "Installation Method" ). Hard Drive If you have copied the Red Hat Enterprise Linux ISO images to a local hard drive, you can use this method. You need a boot CD-ROM (use the linux askmethod or linux repo=hd: device :/ path boot option), or by selecting Hard drive on the Installation Method menu (refer to Section 8.3, "Installation Method" ). Refer to Section 8.3.2, "Installing from a Hard Drive" , for hard drive installation instructions. NFS If you are installing from an NFS server using ISO images or a mirror image of Red Hat Enterprise Linux, you can use this method. You need a boot CD-ROM (use the linux askmethod or linux repo=nfs: server :options :/ path boot option, or the NFS directory option on the Installation Method menu described in Section 8.3, "Installation Method" ). Refer to Section 8.3.4, "Installing via NFS" for network installation instructions. Note that NFS installations may also be performed in GUI mode. URL If you are installing directly from an HTTP or HTTPS (Web) server or an FTP server, use this method. You need a boot CD-ROM (use the linux askmethod , linux repo=ftp:// user : password @ host / path , or linux repo=http:// host / path boot option, or linux repo=https:// host / path boot option,or the URL option on the Installation Method menu described in Section 8.3, "Installation Method" ). Refer to Section 8.3.5, "Installing via FTP, HTTP, or HTTPS" , for FTP, HTTP, and HTTPS installation instructions. If you booted the distribution DVD and did not use the alternate installation source option askmethod , the stage loads automatically from the DVD. Proceed to Section 8.2, "Language Selection" . Note If you boot from a Red Hat Enterprise Linux installation DVD, the installation program loads its stage from that disc. This happens regardless of which installation method you choose, unless you eject the disc before you proceed. The installation program still downloads package data from the source you choose.

Commands:
Chapter 1. What is resource optimization for OpenShift? Resource optimization for OpenShift uses current and historical data from OpenShift to recommend actions to take: Shows metrics for CPU and memory usage and analyzes them Compares defined container requests and limits Analyzes the historical usage patterns to return optimization recommendations Reports usage of applications and deployments Optimizes the size of your pods Manages costs The data that resource optimization for OpenShift provides can improve your resource allocation and help you save money on your OpenShift cluster deployment.

Commands:
Chapter 8. Configuring your Logging deployment 8.1. Configuring CPU and memory limits for logging components You can configure both the CPU and memory limits for each of the logging components as needed. 8.1.1. Configuring CPU and memory limits The logging components allow for adjustments to both the CPU and memory limits. Procedure Edit the ClusterLogging custom resource (CR) in the openshift-logging project: USD oc -n openshift-logging edit ClusterLogging instance apiVersion: "logging.openshift.io/v1" kind: "ClusterLogging" metadata: name: "instance" namespace: openshift-logging ... spec: managementState: "Managed" logStore: type: "elasticsearch" elasticsearch: nodeCount: 3 resources: 1 limits: memory: 16Gi requests: cpu: 200m memory: 16Gi storage: storageClassName: "gp2" size: "200G" redundancyPolicy: "SingleRedundancy" visualization: type: "kibana" kibana: resources: 2 limits: memory: 1Gi requests: cpu: 500m memory: 1Gi proxy: resources: 3 limits: memory: 100Mi requests: cpu: 100m memory: 100Mi replicas: 2 collection: logs: type: "fluentd" fluentd: resources: 4 limits: memory: 736Mi requests: cpu: 200m memory: 736Mi 1 Specify the CPU and memory limits and requests for the log store as needed. For Elasticsearch, you must adjust both the request value and the limit value. 2 3 Specify the CPU and memory limits and requests for the log visualizer as needed. 4 Specify the CPU and memory limits and requests for the log collector as needed.

Commands:
oc -n openshift-logging edit ClusterLogging instance
apiVersion: "logging.openshift.io/v1" kind: "ClusterLogging" metadata: name: "instance" namespace: openshift-logging spec: managementState: "Managed" logStore: type: "elasticsearch" elasticsearch: nodeCount: 3 resources: 1 limits: memory: 16Gi requests: cpu: 200m memory: 16Gi storage: storageClassName: "gp2" size: "200G" redundancyPolicy: "SingleRedundancy" visualization: type: "kibana" kibana: resources: 2 limits: memory: 1Gi requests: cpu: 500m memory: 1Gi proxy: resources: 3 limits: memory: 100Mi requests: cpu: 100m memory: 100Mi replicas: 2 collection: logs: type: "fluentd" fluentd: resources: 4 limits: memory: 736Mi requests: cpu: 200m memory: 736Mi
18.12.5.2. DHCP Snooping CTRL_IP_LEARNING= dhcp (DHCP snooping) provides additional anti-spoofing security, especially when combined with a filter allowing only trusted DHCP servers to assign IP addresses. To enable this, set the variable DHCPSERVER to the IP address of a valid DHCP server and provide filters that use this variable to filter incoming DHCP responses. When DHCP snooping is enabled and the DHCP lease expires, the guest virtual machine will no longer be able to use the IP address until it acquires a new, valid lease from a DHCP server. If the guest virtual machine is migrated, it must get a new valid DHCP lease to use an IP address (for example, by bringing the VM interface down and up again). Note Automatic DHCP detection listens to the DHCP traffic the guest virtual machine exchanges with the DHCP server of the infrastructure. To avoid denial-of-service attacks on libvirt, the evaluation of those packets is rate-limited, meaning that a guest virtual machine sending an excessive number of DHCP packets per second on an interface will not have all of those packets evaluated and thus filters may not get adapted. Normal DHCP client behavior is assumed to send a low number of DHCP packets per second. Further, it is important to setup appropriate filters on all guest virtual machines in the infrastructure to avoid them being able to send DHCP packets. Therefore guest virtual machines must either be prevented from sending UDP and TCP traffic from port 67 to port 68 or the DHCPSERVER variable should be used on all guest virtual machines to restrict DHCP server messages to only be allowed to originate from trusted DHCP servers. At the same time anti-spoofing prevention must be enabled on all guest virtual machines in the subnet. Example 18.6. Activating IPs for DHCP snooping The following XML provides an example for the activation of IP address learning using the DHCP snooping method:

Commands:
<interface type='bridge'> <source bridge='virbr0'/> <filterref filter='clean-traffic'> <parameter name='CTRL_IP_LEARNING' value='dhcp'/> </filterref> </interface>
17.4.3.4. Resource Management Options The xinetd daemon can add a basic level of protection from a Denial of Service (DoS) attacks. Below is a list of directives which can aid in limiting the effectiveness of such attacks: per_source - Defines the maximum number of instances for a service per source IP address. It accepts only integers as an argument and can be used in both xinetd.conf and in the service-specific configuration files in the xinetd.d/ directory. cps - Defines the maximum of connections per second. This directive takes two integer arguments separated by white space. The first is the maximum number of connections allowed to the service per second. The second is the number of seconds xinetd must wait before re-enabling the service. It accepts only integers as an argument and can be used in both xinetd.conf and in the service-specific configuration files in the xinetd.d/ directory. max_load - Defines the CPU usage threshold for a service. It accepts a floating point number argument. There are more resource management options available for xinetd . Refer to the chapter titled Server Security in the Security Guide for more information, as well as the xinetd.conf man page.

Commands:
4.127. libatasmart 4.127.1. RHBA-2012:0703 - libatasmart bug fix update Updated libatasmart packages that fix one bug are now available for Red Hat Enterprise Linux 6. The libatasmart packages contain a small and lightweight parser library for ATA S.M.A.R.T. hard disk health monitoring. Bug Fix BZ# 824918 Due to libatasmart incorrectly calculating the number of bad sectors, certain tools, for example gnome-disk-utility, could erroneously report hard disks with Self-Monitoring, Analysis and Reporting Technology (S.M.A.R.T) as failing when logging in GNOME. This update corrects the bad sector calculation, which ensures that tools such as gnome-disk-utility do not report false positive warnings in this scenario. All users of libatasmart are advised to upgrade to these updated packages, which fix this bug.

Commands: