mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 4. Configuring SSSD to use LDAP and require TLS authentication The System Security Services Daemon (SSSD) is a daemon that manages identity data retrieval and authentication on a Red Hat Enterprise Linux host. A system administrator can configure the host to use a standalone LDAP server as the user account database. The administrator can also specify the requirement that the connection with the LDAP server must be encrypted with a TLS certificate. Note The SSSD configuration option to enforce TLS, ldap_id_use_start_tls , defaults to false . When using ldap:// without TLS for identity lookups, it can pose a risk for an attack vector, namely a man-in-the-middle (MITM) attack which could allow you to impersonate a user by altering, for example, the UID or GID of an object returned in an LDAP search. Ensure that your setup operates in a trusted environment and decide if it is safe to use unencrypted communication for id_provider = ldap . Note id_provider = ad and id_provider = ipa are not affected as they use encrypted connections protected by SASL and GSSAPI. If it is not safe to use unencrypted communication, you should enforce TLS by setting the ldap_id_use_start_tls option to true in the /etc/sssd/sssd.conf file. 4.1. An OpenLDAP client using SSSD to retrieve data from LDAP in an encrypted way The authentication method of the LDAP objects can be either a Kerberos password or an LDAP password. Note that the questions of authentication and authorization of the LDAP objects are not addressed here. Important Configuring SSSD with LDAP is a complex procedure requiring a high level of expertise in SSSD and LDAP. Consider using an integrated and automated solution such as Active Directory or Red Hat Identity Management (IdM) instead. For details about IdM, see Planning Identity Management . Identity :leveloffset: +1

Commands:
8.10.4. frequency, mode, and present The frequency attribute is used to set a fixed frequency, and is measured in Hz. This attribute is only relevant when the name element has a value of tsc . All other timers operate at a fixed frequency ( pit , rtc ). mode determines how the time source is exposed to the guest virtual machine. This attribute is only relevant for a name value of tsc . All other timers are always emulated. Command is as follows: <timer name='tsc' frequency='NNN' mode='auto|native|emulate|smpsafe'/> . Mode definitions are given in the table. Table 8.5. mode attribute values Value Description auto Native if TSC is unstable, otherwise allow native TSC access. native Always allow native TSC access. emulate Always emulate TSC. smpsafe Always emulate TSC and interlock SMP present is used to override the default set of timers visible to the guest virtual machine.. Table 8.6. present attribute values Value Description yes Force this timer to the visible to the guest virtual machine. no Force this timer to not be visible to the guest virtual machine.

Commands:
3.2. Eviction Strategies Each eviction strategy has specific benefits and use cases, as outlined below: Table 3.1. Eviction Strategies Strategy Name Operations Details EvictionStrategy.NONE No eviction occurs. This is the default eviction strategy in Red Hat JBoss Data Grid. EvictionStrategy.LRU Least Recently Used eviction strategy. This strategy evicts entries that have not been used for the longest period. This ensures that entries that are reused periodically remain in memory. EvictionStrategy.UNORDERED Unordered eviction strategy. This strategy evicts entries without any ordered algorithm and may therefore evict entries that are required later. However, this strategy saves resources because no algorithm related calculations are required before eviction. This strategy is recommended for testing purposes and not for a real work implementation. EvictionStrategy.LIRS Low Inter-Reference Recency Set eviction strategy. LIRS is an eviction algorithm that suits a large variety of production use cases. Report a bug 3.2.1. LRU Eviction Algorithm Limitations In the Least Recently Used (LRU) eviction algorithm, the least recently used entry is evicted first. The entry that has not been accessed the longest gets evicted first from the cache. However, LRU eviction algorithm sometimes does not perform optimally in cases of weak access locality. The weak access locality is a technical term used for entries which are put in the cache and not accessed for a long time and entries to be accessed soonest are replaced. In such cases, problems such as the following can appear: Single use access entries are not replaced in time. Entries that are accessed first are unnecessarily replaced. 23149%2C+Administration+and+Configuration+Guide-6.628-06-2017+13%3A51%3A02JBoss+Data+Grid+6Documentation6.6.1 Report a bug

Commands:
12.3.4. Reverse Name Resolution Zone Files A reverse name resolution zone file is used to translate an IP address in a particular namespace into a FQDN. It looks very similar to a standard zone file, except that PTR resource records are used to link the IP addresses to a fully qualified domain name. A PTR record looks similar to this: The <last-IP-digit> is the last number in an IP address which points to a particular system's FQDN. In the follow example, IP addresses 10.0.1.20 through 10.0.1.25 are pointed to corresponding FQDNs. This zone file would be called into service with a zone statement in the named.conf file which looks similar to the following: There is very little difference between this example and a standard zone statement, except for the zone name. Note that a reverse name resolution zone requires the first three blocks of the IP address reversed followed by .in-addr.arpa . This allows the single block of IP numbers used in the reverse name resolution zone file to be associated with the zone.

Commands:
<last-IP-digit> IN PTR <FQDN-of-system>
USDORIGIN 1.0.10.in-addr.arpa. USDTTL 86400 @ IN SOA dns1.example.com. hostmaster.example.com. ( 2001062501 ; serial 21600 ; refresh after 6 hours 3600 ; retry after 1 hour 604800 ; expire after 1 week 86400 ) ; minimum TTL of 1 day IN NS dns1.example.com. IN NS dns2.example.com. 20 IN PTR alice.example.com. 21 IN PTR betty.example.com. 22 IN PTR charlie.example.com. 23 IN PTR doug.example.com. 24 IN PTR ernest.example.com. 25 IN PTR fanny.example.com.
zone "1.0.10.in-addr.arpa" IN { type master; file "example.com.rr.zone"; allow-update { none; }; };
Chapter 6. Installing a three-node cluster on vSphere In OpenShift Container Platform version 4.15, you can install a three-node cluster on VMware vSphere. A three-node cluster consists of three control plane machines, which also act as compute machines. This type of cluster provides a smaller, more resource efficient cluster, for cluster administrators and developers to use for testing, development, and production. You can install a three-node cluster using either installer-provisioned or user-provisioned infrastructure. 6.1. Configuring a three-node cluster You configure a three-node cluster by setting the number of worker nodes to 0 in the install-config.yaml file before deploying the cluster. Setting the number of worker nodes to 0 ensures that the control plane machines are schedulable. This allows application workloads to be scheduled to run from the control plane nodes. Note Because application workloads run from control plane nodes, additional subscriptions are required, as the control plane nodes are considered to be compute nodes. Prerequisites You have an existing install-config.yaml file. Procedure Set the number of compute replicas to 0 in your install-config.yaml file, as shown in the following compute stanza: Example install-config.yaml file for a three-node cluster apiVersion: v1 baseDomain: example.com compute: - name: worker platform: {} replicas: 0 # ... If you are deploying a cluster with user-provisioned infrastructure: Configure your application ingress load balancer to route HTTP and HTTPS traffic to the control plane nodes. In a three-node cluster, the Ingress Controller pods run on the control plane nodes. For more information, see the "Load balancing requirements for user-provisioned infrastructure". After you create the Kubernetes manifest files, make sure that the spec.mastersSchedulable parameter is set to true in cluster-scheduler-02-config.yml file. You can locate this file in <installation_directory>/manifests . For more information, see "Creating the Kubernetes manifest and Ignition config files" in "Installing a cluster on vSphere with user-provisioned infrastructure". Do not create additional worker nodes. Example cluster-scheduler-02-config.yml file for a three-node cluster apiVersion: config.openshift.io/v1 kind: Scheduler metadata: creationTimestamp: null name: cluster spec: mastersSchedulable: true policy: name: "" status: {} 6.2. steps Installing a cluster on vSphere with customizations Installing a cluster on vSphere with user-provisioned infrastructure

Commands:
apiVersion: v1 baseDomain: example.com compute: - name: worker platform: {} replicas: 0
apiVersion: config.openshift.io/v1 kind: Scheduler metadata: creationTimestamp: null name: cluster spec: mastersSchedulable: true policy: name: "" status: {}
Part VIII. Testing a decision service using test scenarios As a business analyst or business rules developer, you can use test scenarios in Business Central to test a decision service before a project is deployed. You can test DMN-based and rules-based decision services to ensure these are functioning properly and as expected. Also, you can test a decision service at any time during project development. Prerequisites The space and project for the decision service have been created in Business Central. For details, see Getting started with decision services . Business rules and their associated data objects have been defined for the rules-based decision service. For details, see Designing a decision service using guided decision tables . DMN decision logic and its associated custom data types have been defined for the DMN-based decision service. For details, see Designing a decision service using DMN models . Note Having defined business rules is not a technical prerequisite for test scenarios, because the scenarios can test the defined data that constitutes the business rules. However, creating the rules first is helpful so that you can also test entire rules in test scenarios and so that the scenarios more closely match the intended decision service. For DMN-based test scenarios ensure that the DMN decision logic and its associated custom data types are defined for the decision service.

Commands:
Chapter 3. New Packages 3.1. RHEA-2011:1627 - new packages: btparser New btparser packages are now available for Red Hat Enterprise Linux 6. The btparser is a backtrace parser and analyzer library, which works with backtraces produced by the GNU Project Debugger. It can parse a text file with a backtrace to a tree of C structures, allowing to analyze the threads and frames of the backtrace and process them. This enhancement update adds the btparser package to Red Hat Enterprise Linux 6. (BZ# 708038 ) All users who require btparser are advised to install this new package.

Commands:
19.2. Introduction to Directory Servers During installation, Red Hat Virtualization Manager creates an admin user on the internal domain. The user is also referred to as admin@internal . This account is intended for use when initially configuring the environment and for troubleshooting. After you have attached an external directory server, added the directory users, and assigned them with appropriate roles and permissions, the admin@internal user can be disabled if it is not required.The directory servers supported are: 389ds 389ds RFC-2307 Schema Active Directory IBM Security Directory Server IBM Security Directory Server RFC-2307 Schema FreeIPA iDM Novell eDirectory RFC-2307 Schema OpenLDAP RFC-2307 Schema OpenLDAP Standard Schema Oracle Unified Directory RFC-2307 Schema RFC-2307 Schema (Generic) Red Hat Directory Server (RHDS) Red Hat Directory Server (RHDS) RFC-2307 Schema iPlanet Important It is not possible to install Red Hat Virtualization Manager ( rhevm ) and IdM ( ipa-server ) on the same system. IdM is incompatible with the mod_ssl package, which is required by Red Hat Virtualization Manager. Important If you are using Active Directory as your directory server, and you want to use sysprep in the creation of templates and virtual machines, then the Red Hat Virtualization administrative user must be delegated control over the Domain to: Join a computer to the domain Modify the membership of a group For information on creation of user accounts in Active Directory, see http://technet.microsoft.com/en-us/library/cc732336.aspx . For information on delegation of control in Active Directory, see http://technet.microsoft.com/en-us/library/cc732524.aspx .

Commands:
Appendix A. Applying custom configuration to Red Hat Satellite When you install and configure Satellite for the first time by using satellite-installer , you can specify that the DNS and DHCP configuration files are not to be managed by Puppet by using the installer flags --foreman-proxy-dns-managed=false and --foreman-proxy-dhcp-managed=false . If these flags are not specified during the initial installer run, rerunning of the installer overwrites all manual changes, for example, rerun for upgrade purposes. If changes are overwritten, you must run the restore procedure to restore the manual changes. For more information, see Restoring Manual Changes Overwritten by a Puppet Run . To view all installer flags available for custom configuration, run satellite-installer --scenario satellite --full-help . Some Puppet classes are not exposed to the Satellite installer. To manage them manually and prevent the installer from overwriting their values, specify the configuration values by adding entries to configuration file /etc/foreman-installer/custom-hiera.yaml . This configuration file is in YAML format, consisting of one entry per line in the format of <puppet class>::<parameter name>: <value> . Configuration values specified in this file persist across installer reruns. Common examples include: For Apache, to set the ServerTokens directive to return only the product name: To turn off the Apache server signature entirely: The Puppet modules for the Satellite installer are stored under /usr/share/foreman-installer/modules . Check the .pp files (for example: moduleName /manifests/ example .pp) to look up the classes, parameters, and values. Alternatively, use the grep command to do keyword searches. Setting some values may have unintended consequences that affect the performance or functionality of Red Hat Satellite. Consider the impact of the changes before you apply them, and test the changes in a non-production environment first. If you do not have a non-production Satellite environment, run the Satellite installer with the --noop and --verbose options. If your changes cause problems, remove the offending lines from custom-hiera.yaml and rerun the Satellite installer. If you have any specific questions about whether a particular value is safe to alter, contact Red Hat support.

Commands:
apache::server_tokens: Prod
apache::server_signature: Off
Chapter 1. Installing RHEL 8 for SAP Solutions You can install RHEL 8 in interactive mode or you can perform an unattended installation using Kickstart. This document explains how to perform an interactive installation. For Kickstart installation, use Server as your base environment and take into account the recommendations from SAP HANA Storage Requirements and Performing SAP HANA Sizing . For a test system, you can remove the default /home file system allocation and use a large root ( / ) file system. Prerequisites You have downloaded the installation image for the desired and supported RHEL 8 minor release from the Red Hat Customer Portal . Important SAP HANA is supported only on particular minor releases of RHEL 8 (for example RHEL 8.2). For more information on which minor RHEL 8 releases are supported by SAP, see the SAP note 2235581 . You have downloaded the installation media for the desired and supported SAP HANA 2 SPS04 or SPS05 revision from the SAP Software Downloads Portal . Procedure Boot your server from the RHEL 8 installation source. For more information on how to boot your server from the RHEL 8 image, see Performing a standard RHEL installation . Select the language and click Continue . Under LOCALIZATION , select the desired keyboard layout, supported languages, and time and date. Under SOFTWARE , click Software Selection . In the Software Selection window, select Server as your Base Environment and click Done . Note Do not select any additional software. Under SYSTEM , click Installation Destination . In the Installation Destination window, select the storage configuration according to your needs and click Done . Note Take into account the recommendations from SAP HANA Storage Requirements and Performing SAP HANA Sizing . For a test system, you can remove the default /home file system allocation and use a large root ( / ) file system. Under SYSTEM , click Network & Host Name , and configure your network connection. Click Begin Installation . Configure USER SETTINGS : To set the root password, click Root Password . To set user, user name, and password, click User Creation . Once RHEL is successfully installed, click Reboot . Additional resources Performing a standard RHEL installation Performing an advanced RHEL installation SAP note 2772999 - RHEL 8.x: Installation and Configuration SAP note 2777782 - Recommended OS Settings for RHEL 8 SAP HANA Server Installation and Update Guide SAP HANA Storage Requirements Performing SAP HANA Sizing

Commands:
Chapter 16. Enabling Prometheus metrics Prometheus is an open-source systems and service monitoring and alerting toolkit that you can use to monitor services deployed in a standalone Apache Karaf container. Prometheus collects and stores metrics from configured services at given intervals, evaluates rule expressions, displays the results, and can trigger alerts if a specified condition becomes true. Important Red Hat support for Prometheus is limited to the setup and configuration recommendations provided in Red Hat product documentation. Prometheus uses "exporters" that are installed and configured on the clients to expose an endpoint to Prometheus format. This endpoint is an HTTP interface that provides a list of metrics and the current values of the metrics. Prometheus periodically scrapes each target-defined endpoint and writes the collected data to its database. Prometheus gathers data over an extended time, rather than just for the currently running session. Prometheus stores the data so that you can graphically visualize and run queries on the data. 16.1. Enabling the export of metrics from a standalone Apache Karaf container Prometheus uses a configuration file ( https://raw.githubusercontent.com/jboss-fuse/application-templates/master/prometheus/prometheus-config.yml ) which includes metrics exposed by Camel. Note The metrics that you can identify are limited to those supplied in JMX. You must deploy a Fuse application in order for Apache Camel metrics to be generated. Procedure To enable the export of Prometheus metrics from a standalone Apache Karaf container using the command line: Open a command prompt and make sure you are in the etc/ directory of your Apache Karaf installation. Type the following command to create the Prometheus configuration file from the example file in the etc/ directory: The exporter is only available when you use the fuse or fuse.bat command to start Fuse: run bin/fuse on Linux/Unix or bin\fuse.bat on Windows. When Fuse has restarted, you can view the exposed metrics by opening a web browser at: http://localhost:9779 Note Optionally you can change the default values of the KARAF_PROMETHEUS_PORT and KARAF_PROMETHEUS_CONFIG configuration variables from the command line. 16.2. Configuring the Prometheus server to scrape exposed metrics from the Apache Karaf container To enable the Prometheus server to scrape metrics from the Apache Karaf container, the endpoint which exposes the metrics must be added to the targets property of the Prometheus configuration file. Procedure Navigate to the /prometheus.yml configuration file in the Prometheus installation directory. Add the Apache Karaf endpoint to scrape: scrape_configs: - job_name: 'prometheus' # metrics_path defaults to '/metrics' # scheme defaults to 'http'. static_configs: - targets: ['localhost:9779']

Commands:
cp prometheus-config.yml-example prometheus-config.yml
scrape_configs: - job_name: 'prometheus' # metrics_path defaults to '/metrics' # scheme defaults to 'http'. static_configs: - targets: ['localhost:9779']
Chapter 8. Windows node upgrades You can ensure your Windows nodes have the latest updates by upgrading the Windows Machine Config Operator (WMCO). 8.1. Windows Machine Config Operator upgrades When a new version of the Windows Machine Config Operator (WMCO) is released that is compatible with the current cluster version, the Operator is upgraded based on the upgrade channel and subscription approval strategy it was installed with when using the Operator Lifecycle Manager (OLM). The WMCO upgrade results in the Kubernetes components in the Windows machine being upgraded. Note If you are upgrading to a new version of the WMCO and want to use cluster monitoring, you must have the openshift.io/cluster-monitoring=true label present in the WMCO namespace. If you add the label to a pre-existing WMCO namespace, and there are already Windows nodes configured, restart the WMCO pod to allow monitoring graphs to display. For a non-disruptive upgrade, the WMCO terminates the Windows machines configured by the version of the WMCO and recreates them using the current version. This is done by deleting the Machine object, which results in the drain and deletion of the Windows node. To facilitate an upgrade, the WMCO adds a version annotation to all the configured nodes. During an upgrade, a mismatch in version annotation results in the deletion and recreation of a Windows machine. To have minimal service disruptions during an upgrade, the WMCO only updates one Windows machine at a time. After the update, it is recommended that you set the spec.os.name.windows parameter in your workload pods. The WMCO uses this field to authoritatively identify the pod operating system for validation and is used to enforce Windows-specific pod security context constraints (SCCs). Important The WMCO is only responsible for updating Kubernetes components, not for Windows operating system updates. You provide the Windows image when creating the VMs; therefore, you are responsible for providing an updated image. You can provide an updated Windows image by changing the image configuration in the MachineSet spec. For more information on Operator upgrades using the Operator Lifecycle Manager (OLM), see Updating installed Operators .

Commands:
probe::kprocess.exec_complete Name probe::kprocess.exec_complete - Return from exec to a new program Synopsis kprocess.exec_complete Values retstr A string representation of errno (SystemTap v2.5+) success A boolean indicating whether the exec was successful errno The error number resulting from the exec name Name of the system call ( " execve " ) (SystemTap v2.5+) Context On success, the context of the new executable. On failure, remains in the context of the caller. Description Fires at the completion of an exec call. Aliased to the syscall.execve.return probe in SystemTap v2.5+.

Commands: