mtpti5iD/redhat-docs_dataset huggingface dataset:
5.5. Load Balancing Policy: Power_Saving Figure 5.2. Power Saving Scheduling Policy A power saving load balancing policy selects the host for a new virtual machine according to lowest CPU or highest available memory. The maximum CPU load and minimum available memory that is allowed for hosts in a cluster for a set amount of time is defined by the power saving scheduling policy's parameters. Beyond these limits the environment's performance will degrade. The power saving parameters also define the minimum CPU load and maximum available memory allowed for hosts in a cluster for a set amount of time before the continued operation of a host is considered an inefficient use of electricity. If a host has reached the maximum CPU load or minimum available memory and stays there for more than the set time, the virtual machines on that host are migrated one by one to the host that has the lowest CPU or highest available memory depending on which parameter is being utilized. Host resources are checked once per minute, and one virtual machine is migrated at a time until the host CPU load is below the defined limit or the host available memory is above the defined limit. If the host's CPU load falls below the defined minimum level or the host's available memory rises above the defined maximum level the virtual machines on that host are migrated to other hosts in the cluster as long as the other hosts in the cluster remain below maximum CPU load and above minimum available memory. When an under-utilized host is cleared of its remaining virtual machines, the Manager will automatically power down the host machine, and restart it again when load balancing requires or there are not enough free hosts in the cluster.

Commands:
Chapter 8. Known issues in Red Hat Decision Manager 7.13.1 This section lists known issues with Red Hat Decision Manager 7.13.1. 8.1. Business Central Unable to deploy Business Central using JDK version 11.0.16 [ RHPAM-4497 ] Issue: It is not possible to deploy Business Central if your installation uses JDK version 11.0.16. Actual result: Business Central does not deploy when launched. Expected result: Business Central deploys successfully. Workaround: Use a JDK version such as 11.0.5 or earlier. 8.2. Form Modeler Date type process variable is empty when the process is started using Business Central form with the showTime set to false [ RHPAM-4514 ] Issue: When you use the default form rendering in Business Central and the process variable field has showTime=false , the started process instance shows that the variable is empty. The affected types are java.time.LocalDateTime , java.time.LocalDate , java.time.LocalTime , and java.util.Date . Steps to reproduce: Define the process variable with a specific type. Generate a form. Open a form and set showTime=false for a specified field. Deploy the project. Open the process form. Specify the value in the process form. Check the process instance variables. The value for the specified variable is empty. Workaround: None. Form in KIE Server with a java.util.Date field does not allow the time to be inserted [ RHPAM-4513 ] Issue: When a process has a variable of type java.util.Date , the generated form, if the showTime attribute is true , does not allow inserting the time part. Then after submitting the Date variable shows all zeros in the time part of the datatype. Workaround: None. 8.3. Red Hat OpenShift Container Platform PostgreSQL 13 Pod won't start because of an incompatible data dirctory [ RHPAM-4464 ] Issue: When you start a PostgreSQL pod after you upgrade the operator, the pod fails to start and you receive the following message: Incompatible data directory. This container image provides PostgreSQL '13', but data directory is of version '10'. This image supports automatic data directory upgrade from '12', please carefully consult image documentation about how to use the 'USDPOSTGRESQL_UPGRADE' startup option. Workaround: Check the version of PostgreSQL: If the PostgreSQL version returned is 12.x or earlier, upgrade PostgreSQL: Red Hat Decision Manager version PostgreSQL version Upgrade instructions 7.13.1 7.10 Follow the instructions in Upgrading database (by switching to newer PostgreSQL image version) to upgrade to PostgreSQL 12.x. 7.13.2 7.10 1. Follow the instructions in Upgrading database (by switching to newer PostgreSQL image version) to upgrade to PostgreSQL 12.x. 2. Follow the instructions in Upgrading database (by switching to newer PostgreSQL image version) to upgrade to PostgreSQL 13.x. 7.13.2 7.12 Follow the instructions in Upgrading database (by switching to newer PostgreSQL image version) to upgrade to PostgreSQL 13.x. Verify that PostpreSQL has been upgraded to your required version:

Commands:
postgres -V
postgres -V
8.8. NIST SCAP 1.2 Certification As of Red Hat Enterprise Linux 6.6, OpenSCAP ( openscap ) is certified by the National Institute of Standards and Technology's (NIST) Security Content Automation Protocol (SCAP) 1.2. SCAP provides a standardized approach to maintaining the security of enterprise systems, allowing you to automatically verify the presence of patches, check system security configuration settings, and examine systems for signs of compromise. Red Hat Enterprise Linux 6.6 also includes a new package, scap-security-guide , which provides more information on how to get the best out of OpenSCAP.

Commands:
4.5. Alternate Options for Creating a Replica Much of the core configuration of the replica is identical to that of the server from which it was created, such as the realm name and directory settings. However, while the settings need to match, it is not required that a replica manage the same services as the server. This is true for major services (DNS and CAs) and for minor services (NTP and OpenSSH). The difference settings can be defined in the ipa-replica-prepare command or in the ipa-replica-install command. 4.5.1. Different DNS Settings For DNS, the ipa-replica-prepare command can be used to configure DNS settings specific to the replica, meaning its IP address and reverse zone. For example: If the server does not host any DNS services, then the replica can be set up to host DNS services for the Identity Management domain. As with installing a server, this is done with the --setup-dns option, and then settings for forward and reverse zones. For example, to configure DNS services for the replica with no forwarders and using an existing reverse zone: The DNS options are described in the ipa-replica-prepare and ipa-replica-install manpages. 4.5.2. Different CA Settings The CA configuration of the replica must echo the CA configuration of the server. If the server is configured with an integrated Dogtag Certificate System instance (regardless of whether it is a root CA or whether it is subordinate to an external CA), then the replica can either create its own integrated CA which is subordinate to the server CA or it can forgo having a CA at all, and forward all requests to the server's CA. If the replica will have its own CA, then it uses the --setup-ca option. The rest of the configuration is taken from the server's configuration. However, if the server was installed without any CA at all, then is nowhere to forward certificate opterations - including the ability to request certificates for the new replica instance. All of the certificates for the replica, as with the server, must be requested and retrieved before installing the replica and then submitted with the installation command. The only exception is the root CA certificate; this is retrieved from the server as part of the replica setup. 4.5.3. Different Services There are three support services that are installed on both servers and replicas by default: NTP, OpenSS client, and OpenSSH server. Any or all of this can be disabled on a replica. For example:

Commands:
ipa-replica-prepare ipareplica.example.com --ip-address=192.68.0.0 --no-reverse
ipa-replica-install ipareplica.example.com --setup-dns --no-forwarders --no-reverse --no-host-dns
ipa-replica-install ipareplica.example.com --setup-ca
ipa-replica-install ipareplica.example.com --dirsrv_pkcs12=/tmp/dirsrv-cert.p12 --dirsrv_pin=secret1 --http_pkcs12=/tmp/http-cert.p12 --http_pin=secret2
ipa-replica-install ... --no-ntp --no-ssh --no-sshd
F.4. SysV Init Runlevels The SysV init runlevel system provides a standard process for controlling which programs init launches or halts when initializing a runlevel. SysV init was chosen because it is easier to use and more flexible than the traditional BSD-style init process. The configuration files for SysV init are located in the /etc/rc.d/ directory. Within this directory, are the rc , rc.local , rc.sysinit , and, optionally, the rc.serial scripts as well as the following directories: The init.d/ directory contains the scripts used by the /sbin/init command when controlling services. Each of the numbered directories represent the six runlevels configured by default under Red Hat Enterprise Linux. F.4.1. Runlevels The idea behind SysV init runlevels revolves around the idea that different systems can be used in different ways. For example, a server runs more efficiently without the drag on system resources created by the X Window System. Or there may be times when a system administrator may need to operate the system at a lower runlevel to perform diagnostic tasks, like fixing disk corruption in runlevel 1. The characteristics of a given runlevel determine which services are halted and started by init . For instance, runlevel 1 (single user mode) halts any network services, while runlevel 3 starts these services. By assigning specific services to be halted or started on a given runlevel, init can quickly change the mode of the machine without the user manually stopping and starting services. The following runlevels are defined by default under Red Hat Enterprise Linux: 0 - Halt 1 - Single-user text mode 2 - Not used (user-definable) 3 - Full multi-user text mode 4 - Not used (user-definable) 5 - Full multi-user graphical mode (with an X-based login screen) 6 - Reboot In general, users operate Red Hat Enterprise Linux at runlevel 3 or runlevel 5 - both full multi-user modes. Users sometimes customize runlevels 2 and 4 to meet specific needs, since they are not used. The default runlevel for the system is listed in /etc/inittab . To find out the default runlevel for a system, look for the line similar to the following near the bottom of /etc/inittab : The default runlevel listed in this example is five, as the number after the first colon indicates. To change it, edit /etc/inittab as root. Warning Be very careful when editing /etc/inittab . Simple typos can cause the system to become unbootable. If this happens, either use a boot CD or DVD, enter single-user mode, or enter rescue mode to boot the computer and repair the file. For more information on single-user and rescue mode, refer to Chapter 36, Basic System Recovery . It is possible to change the default runlevel at boot time by modifying the arguments passed by the boot loader to the kernel. For information on changing the runlevel at boot time, refer to Section E.9, "Changing Runlevels at Boot Time" .

Commands:
init.d/ rc0.d/ rc1.d/ rc2.d/ rc3.d/ rc4.d/ rc5.d/ rc6.d/
id:5:initdefault:
21.5. Miscellaneous Parameters The following parameters can be defined in a parameter file but do not work in a CMS configuration file. rd.live.check Turns on testing of an ISO-based installation source; for example, when booted from an FCP-attached DVD or using inst.repo= with an ISO on local hard disk or mounted with NFS. nompath Disables support for multipath devices. proxy=[ protocol ://][ username [: password ]@] host [: port ] Specify a proxy to use with installation over HTTP, HTTPS, or FTP. inst.rescue Boot into a rescue system running from a RAM disk that can be used to fix and restore an installed system. inst.stage2= URL Specifies a path to an install.img file instead of to an installation source. Otherwise, follows the same syntax as inst.repo= . If inst.stage2 is specified, it typically takes precedence over other methods of finding install.img . However, if Anaconda finds install.img on local media, the inst.stage2 URL will be ignored. If inst.stage2 is not specified and install.img cannot be found locally, Anaconda looks to the location given by inst.repo= or method= . If only inst.stage2= is given without inst.repo= or method= , Anaconda uses whatever repos the installed system would have enabled by default for installation. Use the option multiple times to specify multiple HTTP, HTTPS or FTP sources. The HTTP, HTTPS or FTP paths are then tried sequentially until one succeeds: inst.syslog= IP/hostname [: port ] Sends log messages to a remote syslog server. The boot parameters described here are the most useful for installations and trouble shooting on IBM Z, but only a subset of those that influence the installation program. See Chapter 23, Boot Options for a more complete list of available boot parameters.

Commands:
inst.stage2=host1/install.img inst.stage2=host2/install.img inst.stage3=host3/install.img
8.116. libproxy 8.116.1. RHBA-2014:1556 - libproxy bug fix update Updated libproxy packages that fix several bugs and add various enhancements are now available for Red Hat Enterprise Linux 6. The libproxy library handles all the details of proxy configuration. It provides a stable external API, dynamic adjustment to changing network topology, small core footprint, without external dependencies within libproxy core (though libproxy plug-ins may have dependencies). Bug Fixes BZ# 802765 Previously, the libproxy utility attempted to locate the /etc/proxy.conf file from the current working directory. Consequently, the configuration file was not always found. This bug has been fixed and libproxy now locates /etc/proxy.conf as expected. BZ# 874492 A flaw was found in the way libproxy handled the downloading of proxy auto-configuration (PAC) files. Consequently, programs using libproxy terminated unexpectedly with a segmentation fault when processing PAC files that contained syntax errors. With this update, the handling of PAC files has been fixed in libproxy, thus preventing the segmentation fault. BZ# 979356 Due to a bug in the libproxy packages, the "reporter-upload" command used by Automatic Bug Reporting Tool terminated unexpectedly if given an "scp" URL that did not contain a password. This bug has been fixed, and reporter-upload no longer crashes in the aforementioned scenario. Users of libproxy are advised to upgrade to these updated packages, which fix these bugs.

Commands:
14.6. Additional Resources For more information about OpenSSH and OpenSSL, see the resources listed below. 14.6.1. Installed Documentation sshd (8) - a manual page for the sshd daemon. ssh (1) - a manual page for the ssh client. scp (1) - a manual page for the scp utility. sftp (1) - a manual page for the sftp utility. ssh-keygen (1) - a manual page for the ssh-keygen utility. ssh_config (5) - a manual page with a full description of available SSH client configuration options. sshd_config (5) - a manual page with a full description of available SSH daemon configuration options. /usr/share/doc/openssh- version / Contains detailed information on the protocols supported by OpenSSH.

Commands:
Chapter 2. Installing online or offline Choose the Ansible Automation Platform installer you need to install private automation hub based on your Red Hat Enterprise Linux environment internet connectivity. Review the following scenarios and determine which Ansible Automation Platform installer meets your needs. Note You must have a valid Red Hat customer account to access Ansible Automation Platform installer downloads on the Red Hat Customer Portal. Installing with internet access Install private automation hub using the Ansible Automation Platform installer if your Red Hat Enterprise Linux environment is connected to the internet. Installing with internet access will retrieve the latest required repositories, packages, and dependencies. Navigate to Download Red Hat Ansible Automation Platform . Click Download Now for the Ansible Automation Platform <latest-version> Setup . Extract the files: USD tar xvzf ansible-automation-platform-setup-<latest-version>.tar.gz Installing without internet access Install private automation hub using the Ansible Automation Platform Bundle installer if you are unable to access the internet, or would prefer not to install separate components and dependencies from online repositories. Access to Red Hat Enterprise Linux repositories is still needed. All other dependencies are included in the tar archive. Navigate to Download Red Hat Ansible Automation Platform . Click Download Now for the Ansible Automation Platform <latest-version> Setup Bundle . Extract the files: USD tar xvzf ansible-automation-platform-setup-bundle-<latest-version>.tar.gz

Commands:
tar xvzf ansible-automation-platform-setup-<latest-version>.tar.gz
tar xvzf ansible-automation-platform-setup-bundle-<latest-version>.tar.gz
Chapter 39. System and Subscription Management Non-working Back button in the Subscription Manager add-on for Initial Setup The Back button on the first panel of the Subscription Manager add-on for the Initial Setup utility does not work. To work around this problem, click Done at the top of Initial Setup to exit the registration workflow. virt-who fails to change host-to-guest association to the Candlepin server When adding, removing, or migrating a guest, the virt-who utility currently fails to send the host-to-guest mapping and prints a RateLimitExceededException error to the log file. To work around the problem, set the VIRTWHO_INTERVAL= parameter in the /etc/sysconfig/virt-who file to a large number, such as 600. This allows the mapping to be changed correctly, but causes changes in the host-to-guest mapping to take significantly longer to be processed. ReaR fails to create an ISO on IBM System z ReaR is unable to create an ISO image on IBM System z systems. To work around this problem, use a different type of rescue system than ISO. ReaR supports only grub during system recovery ReaR supports only the grub boot loader. Consequently, ReaR cannot automatically recover a system with a different boot loader. Notably, yaboot is not yet supported by ReaR on PowerPC machines. To work around this problem, edit the boot loader manually.

Commands:
18.3.4.4. Additional Match Option Modules Additional match options are also available through modules loaded by the iptables command. To use a match option module, load the module by name using the -m option, such as -m <module-name> (replacing <module-name> with the name of the module). A large number of modules are available by default. It is even possible to create modules that provide additional functionality. The following is a partial list of the most commonly used modules: limit module - Places limits on how many packets are matched to a particular rule. This is especially beneficial when used in conjunction with the LOG target as it can prevent a flood of matching packets from filling up the system log with repetitive messages or using up system resources. Refer to Section 18.3.5, "Target Options" for more information about the LOG target. The limit module enables the following options: --limit - Sets the number of matches for a particular range of time, specified with a number and time modifier arranged in a <number>/<time> format. For example, using --limit 5/hour only lets a rule match 5 times in a single hour. If a number and time modifier are not used, the default value of 3/hour is assumed. --limit-burst - Sets a limit on the number of packets able to match a rule at one time. This option should be used in conjunction with the --limit option, and it accepts a number to set the burst threshold. If no number is specified, only five packets are initially able to match the rule. state module - Enables state matching. The state module enables the following options: --state - match a packet with the following connection states: ESTABLISHED - The matching packet is associated with other packets in an established connection. INVALID - The matching packet cannot be tied to a known connection. NEW - The matching packet is either creating a new connection or is part of a two-way connection not previously seen. RELATED - The matching packet is starting a new connection related in some way to an existing connection. These connection states can be used in combination with one another by separating them with commas, such as -m state --state INVALID,NEW . mac module - Enables hardware MAC address matching. The mac module enables the following option: --mac-source - Matches a MAC address of the network interface card that sent the packet. To exclude a MAC address from a rule, place an exclamation point character ( ! ) after the --mac-source match option. To view other match options available through modules, refer to the iptables man page.

Commands:
4.7. Synchronizing Configuration Files After configuring the primary LVS router, there are several configuration files that must be copied to the backup LVS router before you start the Load Balancer Add-On. These files include: /etc/sysconfig/ha/lvs.cf - the configuration file for the LVS routers. /etc/sysctl - the configuration file that, among other things, turns on packet forwarding in the kernel. /etc/sysconfig/iptables - If you are using firewall marks, you should synchronize one of these files based on which network packet filter you are using. Important The /etc/sysctl.conf and /etc/sysconfig/iptables files do not change when you configure the Load Balancer Add-On using the Piranha Configuration Tool. 4.7.1. Synchronizing lvs.cf Anytime the LVS configuration file, /etc/sysconfig/ha/lvs.cf , is created or updated, you must copy it to the backup LVS router node. Warning Both the active and backup LVS router nodes must have identical lvs.cf files. Mismatched LVS configuration files between the LVS router nodes can prevent failover. The best way to do this is to use the scp command. Important To use scp the sshd must be running on the backup router, see Section 2.1, "Configuring Services on the LVS Router" for details on how to properly configure the necessary services on the LVS routers. Issue the following command as the root user from the primary LVS router to sync the lvs.cf files between the router nodes: scp /etc/sysconfig/ha/lvs.cf n.n.n.n :/etc/sysconfig/ha/lvs.cf In the command, replace n.n.n.n with the real IP address of the backup LVS router.

Commands:
2. New Packages 2.1. RHEA-2011:0533 - new package: 389-ds-base New 389-ds-base packages are now available for Red Hat Enterprise Linux 6. The 389 Directory Server is an LDAPv3 compliant server. The 389-ds-base package includes the LDAP server and command line utilities for server administration. This enhancement update adds the 389-ds-base package to Red Hat Enterprise Linux 6. (BZ# 642408 ) All users who require the 389 Directory Server are advised to install these new packages.

Commands: