mtpti5iD/redhat-docs_dataset huggingface dataset:
22.4. Defining the Recovery Process There are a lot of tools that can help with disaster recovery, but an effective recovery process circles back to having a well-defined plan of what to do in every scenario. Two things, at least, need to be clearly identified: What signals a disaster? Some things are obvious (a massive power outage, network loss, or fire), but other situations need to be defined. For example, what signals that a backup server needs to be brought online? Who responds to a disaster and how? Once a disaster situation occurs, who has the responsibility to act? How are they notified of the event? What are they expected to do? Important Store a printed copy off the disaster recovery plan off-site. Test the disaster recovery plan on a regular basis and after configuration and infrastructure changes.

Commands:
Chapter 5. Deploying the all-in-one Red Hat OpenStack Platform environment To deploy your all-in-one environment, complete the following steps: Log in to registry.redhat.io with your Red Hat credentials: Export the environment variables that the deployment command uses. In this example, deploy the all-in-one environment with the eth1 interface that has the IP addresses 192.168.25.2 and 192.168.25.3 on the management network: Set the hostname. If the node is using localhost.localdomain, the deployment will fail. Run the deployment command. Ensure that you include all .yaml files relevant to your environment: After a successful deployment, you can use the clouds.yaml configuration file in the /home/USDUSER/.config/openstack directory to query and verify the OpenStack services: To access the dashboard, go to to http://192.168.25.2/dashboard and use the default username admin and the password from the USDHOME/config/openstack/clouds.yaml file:

Commands:
[stack@all-in-one]USD sudo podman login registry.redhat.io
[stack@all-in-one]USD export IP=192.168.25.2 [stack@all-in-one]USD export VIP=192.168.25.3 [stack@all-in-one]USD export NETMASK=24 [stack@all-in-one]USD export INTERFACE=eth1
[stack@all-in-one]USD hostnamectl set-hostname all-in-one.example.net [stack@all-in-one]USD hostnamectl set-hostname all-in-one.example.net --transient
[stack@all-in-one]USD sudo openstack tripleo deploy --templates --local-ip=USDIP/USDNETMASK --control-virtual-ip=USDVIP -e /usr/share/openstack-tripleo-heat-templates/environments/standalone/standalone-tripleo.yaml -r /usr/share/openstack-tripleo-heat-templates/roles/Standalone.yaml -e USDHOME/containers-prepare-parameters.yaml -e USDHOME/standalone_parameters.yaml --output-dir USDHOME --standalone
[stack@all-in-one]USD export OS_CLOUD=standalone [stack@all-in-one]USD openstack endpoint list
[stack@all-in-one]USD cat USDHOME/.config/openstack/clouds.yaml | grep password:
Chapter 8. Monitoring Dashboard Features 8.1. Dashboard Search You can search the available dashboards by the dashboard name. The available filters to search a particular dashboard are starred and tags. The dashboard search functionality is accessed through the dashboard selector, located at the top of the Grafana interface. Figure 8.1. Dashboard Search 8.2. Dashboard Time Range The Grafana interface provides time range management of the the data being visualized. You can change the time range for a graph to view the data at different points in time At the top right, you can access the master Dashboard time picker. It shows the currently selected time range and the refresh interval. Clicking the master Dashboard time picker, toggles a menu for time range controls. Time range The time range filter allows to mix both explicit and relative time ranges. The explicit time range format is YYYY-MM-DD HH:MM:SS . Quick Range Quick ranges are preset values to choose a relative time. Refreshing every When enabled, auto-refresh will reload the dashboard at the specified time range. 8.3. Dashboard Sharing The Dashboard Selector is the primary navigation tool to move between different dashboards. Figure 8.2. Dashboard Selector

Commands:
28.5. Enhancing Hardware Support By default, Red Hat Enterprise Linux attempts to automatically detect and configure support for all of the components of your computer. Red Hat Enterprise Linux supports the majority of hardware in common use with the software drivers that are included with the operating system. To support other devices you may supply additional drivers during the installation process, or at a later time. 28.5.1. Overriding Automatic Hardware Detection For some models of device automatic hardware configuration may fail, or cause instability. In these cases, you may need to disable automatic configuration for that type of device, and take additional steps to manually configure the device after the installation process is complete. Note Refer to the Release Notes for information on known issues with specific devices. To override the automatic hardware detection, use one or more of the following options: Table 28.3. Hardware Options Compatibility Option Disable all hardware detection noprobe Disable graphics, keyboard, and mouse detection headless Disable passing keyboard and mouse information to stage 2 of the installation program nopass Use basic VESA driver for video xdriver=vesa Disable shell access on virtual console 2 during installation noshell Disable advanced configuration and power interface (ACPI) acpi=off Disable machine check exception (MCE) CPU self-diagnosis. nomce Disable non-uniform memory access on the AMD64 architecture numa-off Force kernel to detect a specific amount of memory, where xxx is a value in megabytes mem= xxx m Enable DMA only for IDE and SATA drives libata.dma=1 Disable BIOS-assisted RAID nodmraid Disable Firewire device detection nofirewire Disable parallel port detection noparport Disable PC Card (PCMCIA) device detection nopcmcia Disable all probing of network hardware nonet Note The isa option causes the system to display an additional text screen at the beginning of the installation process. Use this screen to configure the ISA devices on your computer. Important Other kernel boot options have no particular meaning for anaconda and do not affect the installation process. However, if you use these options to boot the installation system, anaconda will preserve them in the bootloader configuration.

Commands:
2.2.2.2. Protect portmap With iptables To further restrict access to the portmap service, it is a good idea to add iptables rules to the server and restrict access to specific networks. Below are two example iptables commands. The first allows TCP connections to the port 111 (used by the portmap service) from the 192.168.0.0/24 network. The second allows TCP connections to the same port from the localhost. This is necessary for the sgi_fam service used by Nautilus . All other packets are dropped. To similarly limit UDP traffic, use the following command: Note Refer to Section 2.8, "Firewalls" for more information about implementing firewalls with iptables commands.

Commands:
~]# iptables -A INPUT -p tcp -s ! 192.168.0.0/24 --dport 111 -j DROP ~]# iptables -A INPUT -p tcp -s 127.0.0.1 --dport 111 -j ACCEPT
~]# iptables -A INPUT -p udp -s ! 192.168.0.0/24 --dport 111 -j DROP
31.5. Issue Reporting In the event that an issue is encountered while working with VDO, it is important to gather as much information as possible to assist Red Hat Sales Engineers in attempting to reproduce the issue. Issue reports should include the following: A detailed description of the test environment; see the section called "Test Environment" for specifics The VDO configuration The use case that generated the issue The actions that were being performed at the time of the error The text of any error messages on the console or terminal The kernel log files Kernel crash dumps, if available The result of sosreport , which will capture data describing the entire Linux environment

Commands:
26.7. Miscellaneous Parameters The following parameters can be defined in a parameter file but do not work in a CMS configuration file. askmethod Do not use an automatically detected DVD as installation source but ask for the installation method to manually specify the installation source. This parameter is useful if you booted from an FCP-attached DVD but want to continue with another installation source, for example on the network or on a local hard disk. mediacheck Turns on testing of an ISO-based installation source; for example, when booted from an FCP-attached DVD or using repo= with an ISO on local hard disk or mounted with NFS. nompath Disables support for multipathing devices. proxy=[ protocol ://][ username [: password ]@] host [: port ] Specify a proxy to use with installation over HTTP, HTTPS, or FTP. rescue Boot into a rescue system running from a ramdisk that can be used to fix and restore an installed system. stage2= URL Specifies a path to an install.img file instead of to an installation source. Otherwise, follows the same syntax as repo= . If stage2 is specified, it typically takes precedence over other methods of finding install.img . However, if anaconda finds install.img on local media, the stage2 URL will be ignored. If stage2 is not specified and install.img cannot be found locally, anaconda looks to the location given by repo= or method= . If only stage2= is given without repo= or method= , anaconda uses whatever repos the installed system would have enabled by default for installation. syslog= IP/hostname [: port ] Makes the installer send log messages to a remote syslog server. The boot parameters described here are the most useful for installations and trouble shooting on System z, but only a subset of those that influence the installer. Refer to Chapter 28, Boot Options for a more complete list of installer boot parameters.

Commands:
Preface In Authentication , you learnt how to authenticate users to Red Hat Developer Hub. Developer Hub knowns who the users are. In this book, learn how to authorize users to perform actions in Developer Hub. Define what users can do in Developer Hub. Role-Based Access Control (RBAC) is a security concept that controls access to resources in a system, and specifies a mapping between users of the system, and the actions they can perform on resources in the system. You define roles with specific permissions, and then assign the roles to users and groups. RBAC on Developer Hub is built on top of the Permissions framework, which defines RBAC policies in code. Rather than defining policies in code, the Developer Hub RBAC feature allows you to define policies in a declarative fashion using a simple CSV based format. You can define the policies by using Developer Hub web interface or REST API, rather than editing the CSV directly. To define authorizations in Developer Hub: The Developer Hub administrator enables and gives access to the RBAC feature. You define your roles and policies by combining the following methods: The Developer Hub policy administrator uses the Developer Hub web interface or REST API. The Developer Hub administrator edits the main Developer Hub configuration file. The Developer Hub administrator edits external files.

Commands:
Chapter 3. Monitoring and Analyzing System Performance This chapter briefly introduces tools that can be used to monitor and analyze system and application performance, and points out the situations in which each tool is most useful. The data collected by each tool can reveal bottlenecks or other system problems that contribute to less-than-optimal performance. 3.1. The proc File System The proc "file system" is a directory that contains a hierarchy of files that represent the current state of the Linux kernel. It allows applications and users to see the kernel's view of the system. The proc directory also contains information about the hardware of the system, and any currently running processes. Most of these files are read-only, but some files (primarily those in /proc/sys ) can be manipulated by users and applications to communicate configuration changes to the kernel. For further information about viewing and editing files in the proc directory, see the Deployment Guide , available at http://access.redhat.com/site/documentation/Red_Hat_Enterprise_Linux/ .

Commands:
Chapter 57. Data objects Data objects are the building blocks for the rule assets that you create. Data objects are custom data types implemented as Java objects in specified packages of your project. For example, you might create a Person object with data fields Name , Address , and DateOfBirth to specify personal details for loan application rules. These custom data types determine what data your assets and your decision services are based on. 57.1. Creating data objects The following procedure is a generic overview of creating data objects. It is not specific to a particular business asset. Procedure In Business Central, go to Menu Design Projects and click the project name. Click Add Asset Data Object . Enter a unique Data Object name and select the Package where you want the data object to be available for other rule assets. Data objects with the same name cannot exist in the same package. In the specified DRL file, you can import a data object from any package. Importing data objects from other packages You can import an existing data object from another package directly into the asset designers like guided rules or guided decision table designers. Select the relevant rule asset within the project and in the asset designer, go to Data Objects New item to select the object to be imported. To make your data object persistable, select the Persistable checkbox. Persistable data objects are able to be stored in a database according to the JPA specification. The default JPA is Hibernate. Click Ok . In the data object designer, click add field to add a field to the object with the attributes Id , Label , and Type . Required attributes are marked with an asterisk (*). Id: Enter the unique ID of the field. Label: (Optional) Enter a label for the field. Type: Enter the data type of the field. List: (Optional) Select this check box to enable the field to hold multiple items for the specified type. Figure 57.1. Add data fields to a data object Click Create to add the new field, or click Create and continue to add the new field and continue adding other fields. Note To edit a field, select the field row and use the general properties on the right side of the screen.

Commands:
Chapter 9. Clustering Clusters are multiple computers (nodes) working together to increase reliability, scalability, and availability to critical production services. High Availability using Red Hat Enterprise Linux 7 can be deployed in a variety of configurations to suit varying needs for performance, high-availability, load balancing, and file sharing. Refer to Section 19.5, "Clustering and High Availability" for a list of documents available for Red Hat Enterprise Linux 7 providing information about configuration and management of Red Hat High Availability Add-On. 9.1. Pacemaker Cluster Manager Red Hat Enterprise Linux 7 replaces rgmanager with Pacemaker for managing cluster resources and recovering from node failures. Some of the benefits of Pacemaker include: Automatic synchronization and versioning of the resource configuration; A flexible resource and fencing model that can more closely match the user's environment; Fencing can be used to recover from resource-level failures; Time-based configuration options; The ability to run the same resource on multiple nodes. For example, a web server or cluster file system; The ability to run the same resource on multiple nodes in one of two different modes. For example, a sync source and target; Pacemaker does not require a distributed lock manager; Configurable behavior when quorum is lost or multiple partitions are formed.

Commands:
7.31. cpuspeed 7.31.1. RHBA-2015:1440 - cpuspeed bug fix update Updated cpuspeed packages that fix one bug are now available for Red Hat Enterprise Linux 6. The cpuspeed packages contain a daemon that dynamically changes the speed of processors depending upon their current workload. These packages also allow users to enable CPU frequency scaling using in-kernel CPUfreq governors on Intel Centrino, AMD Athlon 64, and AMD Opteron platforms. Bug Fix BZ# 1196755 , BZ# 1211828 , BZ# 1219780 , BZ# 1225024 A update brought in a change in the kernel introducing the intel_pstate driver, incompatible with how scaling was managed until Red Hat Enterprise Linux 6.7. Consequently, the cpuspeed service printed needless error messages during system boot and shutdown. With this update, platforms using intel_pstate support only the "performance" and "powersave" scaling governors, the default option and default state being "powersave". If the user has set a different governor from the above-mentioned, for example "ondemand" or "conservative", they have to edit the configuration and choose one from the two, "powersave" or "performance". In addition, needless error messages are no longer returned. Users of cpuspeed are advised to upgrade to these updated packages, which fix this bug.

Commands:
14.7. Repairing Changed UID and GID Numbers When a user logs into an IdM system or service, SSSD on that system caches their user name together with the UID and GID of the user. SSSD then uses the UID as the identifying key for the user. If a user with the same user name but a different UID attempts to log into the system, SSSD registers two different UIDs and assumes that there are two different users with conflicting user names. This can pose a problem if a UID of a user changes. In such a situation, SSSD incorrectly interprets the user with a modified UID as a new user, instead of recognizing that it as the same user with a different UID. If the UID of an existing user changes, the user cannot log into SSSD and associated services and domains. This also affects client applications that use SSSD for identity information. To work around this problem, if a UID or GID changes, clear the SSSD cache, which ensures that the user is able to log in again. For example, to clear the SSSD cache for a specified user, use the sss_cache utility as follows:

Commands:
sss_cache -u user
14.15.2. Managing Snapshots The sections that follow describe actions that can be done in order to manipulate domain snapshots. Snapshots take the disk, memory, and device state of a domain at a specified point-in-time, and save it for future use. Snapshots have many uses, from saving a "clean" copy of an OS image to saving a domain's state before what may be a potentially destructive operation. Snapshots are identified with a unique name. See the libvirt website for documentation of the XML format used to represent properties of snapshots. 14.15.2.1. Creating Snapshots The virsh snapshot-create command creates a snapshot for domain with the properties specified in the domain XML file (such as <name> and <description> elements, as well as <disks>). To create a snapshot, run: The domain name, ID, or UID may be used as the domain requirement. The XML requirement is a string must contain the <name>, <description> and <disks> elements. Note Live snapshots are not supported in Red Hat Enterprise Linux. There are additional options available with the virsh snapshot-create command for use with live snapshots which are visible in libvirt, but not supported in Red Hat Enterprise Linux 6. The options available in Red Hat Enterprise Linux include: --redefine specifies that if all XML elements produced by snapshot-dumpxml are valid; it can be used to migrate snapshot hierarchy from one machine to another, to recreate hierarchy for the case of a transient domain that goes away and is later recreated with the same name and UUID, or to make slight alterations in the snapshot metadata (such as host-specific aspects of the domain XML embedded in the snapshot). When this option is supplied, the xmlfile argument is mandatory, and the domain's current snapshot will not be altered unless the --current option is also given. --no-metadata creates the snapshot, but any metadata is immediately discarded (that is, libvirt does not treat the snapshot as current, and cannot revert to the snapshot unless --redefine is later used to teach libvirt about the metadata again). --reuse-external , if used, this option specifies the location of an existing external XML snapshot to use. If an existing external snapshot does not already exist, the command will fail to take a snapshot to avoid losing contents of the existing files.

Commands:
snapshot-create <domain> <xmlfile> [--redefine] [--current] [--no-metadata] [--reuse-external]
Chapter 40. Migrating to IdM on RHEL 7 from FreeIPA on non-RHEL Linux distributions To migrate a FreeIPA deployment on a non-RHEL Linux distribution to an Identity Management (IdM) deployment on RHEL 7 servers, you must first add a new RHEL 7 IdM Certificate Authority (CA) replica to your existing FreeIPA environment, transfer certificate-related roles to it, and then retire the non-RHEL FreeIPA servers. Important Performing an in-place conversion of a non-RHEL FreeIPA server to a RHEL 7 IdM server using the Convert2RHEL tool is not supported. Prerequisites You have determined the domain level of your non-RHEL FreeIPA certificate authority (CA) renewal server. For more information, see Displaying the Current Domain Level . You have installed RHEL 7.9 on the system that you want to become the new CA renewal server. Procedure To perform the migration, follow the same procedure as Migrating Identity Management from Red Hat Enterprise Linux 6 to Version 7 , with your non-RHEL FreeIPA CA server acting as the RHEL 6 server: If the original non-RHEL CA renewal server is running FreeIPA version 3.1 or older, Update the Identity Management Schema . To display the installed FreeIPA version, use the ipa --version command. Configure a RHEL 7 server and add it as an IdM replica to your current FreeIPA environment on the non-RHEL Linux distribution. If the domain level for your domain is 0, see Installing the RHEL 7 Replica . If the domain level is 1, follow the steps described in Creating the Replica: Introduction . Make the RHEL 7 replica the CA renewal server, stop generating the certificate revocation list (CRL) on the non-RHEL server and redirect CRL requests to the RHEL 7 replica. For details, see Transitioning the CA Services to the Red Hat Enterprise Linux 7 Server . Stop the original non-RHEL FreeIPA CA renewal server to force domain discovery to the new RHEL 7 server. For details, see Stop the Red Hat Enterprise Linux 6 Server . Install new replicas on other RHEL 7 systems and decommission the non-RHEL server. For details, see steps after migrating the master CA server . Important Red Hat recommends having IdM replicas of only one major RHEL version in your topology. For this reason, do not delay decommissioning the old server. Additional resources Migrating Identity Management from Red Hat Enterprise Linux 6 to Version 7

Commands:
Chapter 10. Concepts for database connection pools This section is intended when you want to understand considerations and best practices on how to configure database connection pools for Red Hat build of Keycloak. For a configuration where this is applied, visit Deploy Red Hat build of Keycloak for HA with the Red Hat build of Keycloak Operator . 10.1. Concepts Creating new database connections is expensive as it takes time. Creating them when a request arrives will delay the response, so it is good to have them created before the request arrives. It can also contribute to a stampede effect where creating a lot of connections in a short time makes things worse as it slows down the system and blocks threads. Closing a connection also invalidates all server side statements caching for that connection. For the best performance, the values for the initial, minimal and maximum database connection pool size should all be equal. This avoids creating new database connections when a new request comes in which is costly. Keeping the database connection open for as long as possible allows for server side statement caching bound to a connection. In the case of PostgreSQL, to use a server-side prepared statement, a query needs to be executed (by default) at least five times . See the PostgreSQL docs on prepared statements for more information.

Commands: