mtpti5iD/redhat-docs_dataset huggingface dataset:
17.4. xinetd Configuration Files The configuration files for xinetd are as follows: /etc/xinetd.conf - The global xinetd configuration file. /etc/xinetd.d/ - The directory containing all service-specific files. 17.4.1. The /etc/xinetd.conf File The /etc/xinetd.conf file contains general configuration settings which effect every service under xinetd 's control. It is read once when the xinetd service is started, so for configuration changes to take effect, the administrator must restart the xinetd service. Below is a sample /etc/xinetd.conf file: These lines control the following aspects of xinetd : instances - Sets the maximum number of requests xinetd can handle at once. log_type - Configures xinetd to use the authpriv log facility, which writes log entries to the /var/log/secure file. Adding a directive such as FILE /var/log/xinetdlog would create a custom log file called xinetdlog in the /var/log/ directory. log_on_success - Configures xinetd to log if the connection is successful. By default, the remote host's IP address and the process ID of server processing the request are recorded. log_on_failure - Configures xinetd to log if there is a connection failure or if the connection is not allowed. cps - Configures xinetd to allow no more than 25 connections per second to any given service. If this limit is reached, the service is retired for 30 seconds. includedir /etc/xinetd.d/ - Includes options declared in the service-specific configuration files located in the /etc/xinetd.d/ directory. Refer to Section 17.4.2, "The /etc/xinetd.d/ Directory" for more information. Note Often, both the log_on_success and log_on_failure settings in /etc/xinetd.conf are further modified in the service-specific log files. For this reason, more information may appear in a given service's log than the /etc/xinetd.conf file may indicate. Refer to Section 17.4.3.1, "Logging Options" for additional information.

Commands:
defaults { instances = 60 log_type = SYSLOG authpriv log_on_success = HOST PID log_on_failure = HOST cps = 25 30 } includedir /etc/xinetd.d
D.3. Controlling Activation with Tags You can specify in the configuration file that only certain logical volumes should be activated on that host. For example, the following entry acts as a filter for activation requests (such as vgchange -ay ) and only activates vg1/lvol0 and any logical volumes or volume groups with the database tag in the metadata on that host. There is a special match "@*" that causes a match only if any metadata tag matches any host tag on that machine. As another example, consider a situation where every machine in the cluster has the following entry in the configuration file: If you want to activate vg1/lvol2 only on host db2 , do the following: Run lvchange --addtag @db2 vg1/lvol2 from any host in the cluster. Run lvchange -ay vg1/lvol2 . This solution involves storing hostnames inside the volume group metadata.

Commands:
activation { volume_list = ["vg1/lvol0", "@database" ] }
tags { hosttags = 1 }
Chapter 22. How is the subscription threshold calculated? In the subscriptions service, the usage and utilization graph for most product pages contains a subscription threshold. This line shows the maximum capacity of similar subscriptions across all of your contracts. Note Some product pages do not show a subscription threshold on the graph. For a product page that includes pay-as-you-go On-Demand subscriptions, that graph does not display a subscription threshold because of the characteristics of that subscription type. For an account that includes any subscription with a unit of measurement (UoM) of "Unlimited" as part of the terms, the graph for any product page that includes this subscription does not display a subscription threshold. If filtering is used to exclude this subscription from the views, the graph will display a subscription threshold for the filtered data. To measure the maximum capacity of an organization's account and plot the subscription threshold line in the graph, the subscriptions service does the following steps: Accesses the Red Hat internal subscription services to gather subscription-related contract data for the account. Analyzes every subscription in the account, including each SKU (stock-keeping unit) that was purchased and the amount of each SKU that was purchased. Determines which products are provided in each SKU that is found. Calculates the maximum amount of technology that is provided by a subscription by multiplying the amount of technology that a SKU allows by the number of that SKU that was purchased in the subscription. The amount of technology that a SKU allows is the unit of measurement for the SKU multiplied by the number of these units (the limit) that the SKU provides. Adds the maximum amount of technology for every subscription to determine the subscription threshold that appears on the graph for every product or product portfolio. Analyzes the available subscription attributes data (also known as system purpose data or subscription settings) to enable filtering of that data with the filters in the subscriptions service.

Commands:
Chapter 11. Dashboard (horizon) Parameters You can modify the horizon service with dashboard parameters. Parameter Description HorizonAllowedHosts A list of IP/Hostname for the server OpenStack Dashboard (horizon) is running on. Used for header checks. The default value is * . HorizonCustomizationModule OpenStack Dashboard (horizon) has a global overrides mechanism available to perform customizations. HorizonDomainChoices Specifies available domains to choose from. We expect an array of hashes, and the hashes should have two items each (name, display) containing OpenStack Identity (keystone) domain name and a human-readable description of the domain respectively. HorizonHelpURL On top of dashboard there is a Help button. This button could be used to re-direct user to vendor documentation or dedicated help portal. The default value is http://docs.openstack.org . HorizonPasswordValidator Regex for password validation. HorizonPasswordValidatorHelp Help text for password validation. HorizonSecret Secret key for the webserver. HorizonSecureCookies Set CSRF_COOKIE_SECURE / SESSION_COOKIE_SECURE in OpenStack Dashboard (horizon). The default value is false . HorizonSessionTimeout Set session timeout for horizon in seconds. The default value is 1800 . HorizonVhostExtraParams Extra parameters for OpenStack Dashboard (horizon) vhost configuration. The default value is {'add_listen': 'true', 'priority': '10', 'access_log_format': '%a %l %u %t \\"%r\\" %>s %b \\"%%{}{Referer}i\\" \\"%%{}{User-Agent}i\\"', 'options': ['FollowSymLinks', 'MultiViews']} . MemcachedIPv6 Enable IPv6 features in Memcached. The default value is false . TimeZone The timezone to be set on the overcloud. The default value is UTC . WebSSOChoices Specifies the list of SSO authentication choices to present. Each item is a list of an SSO choice identifier and a display message. The default value is [['OIDC', 'OpenID Connect']] . WebSSOEnable Enable support for Web Single Sign-On. The default value is false . WebSSOIDPMapping Specifies a mapping from SSO authentication choice to identity provider and protocol. The identity provider and protocol names must match the resources defined in keystone. The default value is {'OIDC': ['myidp', 'openid']} . WebSSOInitialChoice The initial authentication choice to select by default. The default value is OIDC .

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: 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
Chapter 1. Searching for vulnerability information You can use the Trusted Profile Analyzer service to find existing Software Bill of Materials (SBOM), Vulnerability Exploitability eXchange (VEX) documents, and common vulnerability and exposure (CVE) information for Red Hat products and packages. Important Trusted Profile Analyzer managed service provides only information for the following Red Hat products: Red Hat Enterprise Linux Universal Base Image (UBI) versions 8 and 9. The Java Quarkus library. Prerequisites A Red Hat user account to access the Red Hat Hybrid Cloud Console . Procedure Open a web browser. Go to the Application and Data Services home page on the Hybrid Cloud Console. If prompted, log in to the Hybrid Cloud Console with your credentials. On the navigation menu, click Trusted Profile Analyzer . On the Trusted Profile Analyzer home page, click the Subscribe and launch button. A new web browser window opens to the Trusted Profile Analyzer console home page. Note By subscribing, your registered email address goes onto the product mailing list, so you can receive information about new product developments. On the Home page, in the search field, enter your search criteria and click Search . On the search results page, you can filter the results by Red Hat products, download SBOM files, view package vulnerability information, and view any possible remediations. Note The number shown on the Advisories tab is how many times your search criteria made a match. On the Products and containers tab, the number in the Product advisories column shows the number of advisories for that specific product.

Commands:
Chapter 8. Troubleshooting Builds The builder instances started by the build manager are ephemeral. This means that they will either get shut down by Red Hat Quay on timeouts or failure, or garbage collected by the control plane (EC2/K8s). In order to obtain the builds logs, you must do so while the builds are running. 8.1. DEBUG config flag The DEBUG flag can be set to true in order to prevent the builder instances from getting cleaned up after completion or failure. For example: EXECUTORS: - EXECUTOR: ec2 DEBUG: true ... - EXECUTOR: kubernetes DEBUG: true ... When set to true , the debug feature prevents the build nodes from shutting down after the quay-builder service is done or fails. It also prevents the build manager from cleaning up the instances by terminating EC2 instances or deleting Kubernetes jobs. This allows debugging builder node issues. Debugging should not be set in a production cycle. The lifetime service still exists; for example, the instance still shuts down after approximately two hours. When this happens, EC2 instances are terminated and Kubernetes jobs are completed. Enabling debug also affects the ALLOWED_WORKER_COUNT because the unterminated instances and jobs still count toward the total number of running workers. As a result, the existing builder workers must be manually deleted if ALLOWED_WORKER_COUNT is reached to be able to schedule new builds . 8.2. Troubleshooting OpenShift Container Platform and Kubernetes Builds Use the following procedure to troubleshooting OpenShift Container Platform Kubernetes Builds. Procedure Create a port forwarding tunnel between your local machine and a pod running with either an OpenShift Container Platform cluster or a Kubernetes cluster by entering the following command: USD oc port-forward <builder_pod> 9999:2222 Establish an SSH connection to the remote host using a specified SSH key and port, for example: USD ssh -i /path/to/ssh/key/set/in/ssh_authorized_keys -p 9999 core@localhost Obtain the quay-builder service logs by entering the following commands: USD systemctl status quay-builder USD journalctl -f -u quay-builder

Commands:
EXECUTORS: - EXECUTOR: ec2 DEBUG: true - EXECUTOR: kubernetes DEBUG: true
oc port-forward <builder_pod> 9999:2222
ssh -i /path/to/ssh/key/set/in/ssh_authorized_keys -p 9999 core@localhost
systemctl status quay-builder
journalctl -f -u quay-builder
Chapter 5. Setting up Systems as IdM Clients A client is any system which is a member of the Identity Management domain. While this is frequently a Red Hat Enterprise Linux system (and IdM has special tools to make configuring Red Hat Enterprise Linux clients very simple), machines with other operating systems can also be added to the IdM domain. One important aspect of an IdM client is that only the system configuration determines whether the system is part of the domain. (The configuration includes things like belonging to the Kerberos domain, DNS domain, and having the proper authentication and certificate setup.) Note IdM does not require any sort of agent or daemon running on a client for the client to join the domain. However, for the best management options, security, and performance, clients should run the System Security Services Daemon (SSSD). For more information on SSSD, see the SSSD chapter in the Deployment Guide the SSSD project page . This chapter explains how to configure a system to join an IdM domain. Note Clients can only be configured after at least one IdM server has been installed. 5.1. What Happens in Client Setup Whether the client configuration is performed automatically on Red Hat Enterprise Linux systems using the client setup script or manually on other systems, the general process of configuring a machine to serve as an IdM client is mostly the same, with slight variation depending on the platform: Retrieve the CA certificate for the IdM CA. Create a separate Kerberos configuration to test the provided credentials. This enables a Kerberos connection to the IdM XML-RPC server, necessary to join the IdM client to the IdM domain. This Kerberos configuration is ultimately discarded. Setting up the Kerberos configuration includes specifying the realm and domain details, and default ticket attributes. Forwardable tickets are configured by default, which facilitates connection to the administration interface from any operating system, and also provides for auditing of administration operations. For example, this is the Kerberos configuration for Red Hat Enterprise Linux systems: Run the ipa-join command to perform the actual join. Obtain a service principal for the host service and installs it into /etc/krb5.keytab . For example, host/ipa.example.com@EXAMPLE.COM . Enable certmonger, retrieve an SSL server certificate, and install the certificate in /etc/pki/nssdb . Disable the nscd daemon. Configure SSSD or LDAP/KRB5, including NSS and PAM configuration files. Configure an OpenSSH server and client, as well as enabling the host to create DNS SSHFP records. Configure NTP.

Commands:
[libdefaults] default_realm = EXAMPLE.COM dns_lookup_realm = false dns_lookup_kdc = false rdns = false forwardable = yes ticket_lifetime = 24h [realms] EXAMPLE.COM = { kdc = server.example.com:88 admin_server = server.example.com:749 } [domain_realm] .example.com = EXAMPLE.COM example.com = EXAMPLE.COM
Chapter 3. Device Drivers This chapter provides a comprehensive listing of all device drivers which were updated in Red Hat Enterprise Linux 6.7. Storage Drivers The hpsa driver has been upgraded to version 3.4.4-1-RH4. The lpfc driver has been upgraded to version 10.6.0.20. The megaraid_sas driver has been upgraded to version 06.806.08.00-rh3. The mpt2sas driver has been upgraded to version 20.101.00.00. The mpt3sas driver has been upgraded to version 04.100.00.00-rh. The Multiple Devices (MD) drivers have been upgraded to the latest upstream version. The Nonvolatile Memory Express (NVMe) driver has been upgraded to version 0.10. The qla4xxx driver has been upgraded to version 5.03.00.00.06.07-k0. The qla2xxx driver has been upgraded to version 8.07.00.16.06.7-k. Network Drivers The be2net driver has been upgraded to version 10.4r. The cnic driver has been upgraded to version 2.5.20. The bonding driver has been upgraded to version 3.7.1. The forcedeth driver has been upgraded to the latest upstream version. The i40e driver has been upgraded to version 1.2.9-k. The qlcnic driver has been upgraded to version 5.3.62.1. The r8169 driver has been upgraded to version 2.3LK-NAPI. Miscellaneous Drivers The drm driver has been upgraded to the latest upstream version. The scsi_debug driver has been updated to version 1.82.

Commands:
5.10. authconfig 5.10.1. RHBA-2012:0931 - authconfig bug fix and enhancement update Updated authconfig packages that fix multiple bugs and add two enhancements are now available for Red Hat Enterprise Linux 6. The authconfig packages provide a command line utility and a GUI application that can configure a workstation to be a client for certain network user information and authentication schemes, and other user information and authentication related options. Bug Fixes BZ# 689717 Prior to this update, SSSD configuration files failed to parse if the files were not correctly formatted. As a consequence, the authconfig utility could abort unexpectedly. With this update, the error is correctly handled, the configuration file is backed up, and a new file is created. BZ# 708850 Prior to this update, the man page "authconfig(8)" referred to non-existing obsolete configuration files. This update modifies the man page to point to configuration files that are currently modified by authconfig. BZ# 749700 Prior to this update, a deprecated "krb_kdcip" option was set instead of the "krb5_server" option when the SSSD configuration was updated. This update modifies the SSSD configuration setting to use the "krb5_server" option to set the Kerberos KDC server address. BZ# 755975 Prior to this update, the authconfig command always returned the exit value "1" when the "--savebackup" option was used, due to handling of nonexisting configuration files on the system. With this update, the exit value is "0" if the configuration backup succeeds even if some configuration files which can be handled by authconfig, are not present on the system. Enhancements BZ# 731094 Prior to this update, the authconfig utility did not support the SSSD configuration with the IPA backend. This update allows to join an IPAv2 domain with the system via the ipa-client-install command. BZ# 804615 With this update, the nss_sss module is also used in the "services" entry of the nsswitch.conf file when configuring this file. All users of authconfig are advised to upgrade to these updated packages, which fix these bugs and add these enhancements.

Commands:
Chapter 5. Network connections 5.1. Connection Options This section describes how to configure how to configure connections. The ConnectionOptions object can be provided to a Client instance when creating a new connection and allows configuration of several different aspects of the resulting Connection instance. ConnectionOptions can be passed in the connect method on IClient and are used to configure Example: Configuring authentication ConnectionOptions connectionOptions = new ConnectionOptions(); connectionOptions.User = "user" connectionOptions.Password = "password" IConnection connection = client.Connect(serverHost, serverPort, connectionOptions); For a definitive list of options refer to Connection Options 5.1.1. Connection Transport Options The ConnectionOptions object exposes a set of configuration options for the underlying I/O transport layer known as the TransportOptions which allows for fine grained configuration of network level options. Example: Configuring transport options ConnectionOptions connectionOptions = new ConnectionOptions(); connectionOptions.TransportOptions.TcpNoDelay = false; IConnection connection = client.Connect(serverHost, serverPort, connectionOptions); For a definitive list of options refer to Connection Transport Options 5.2. Reconnect and failover When creating a new connection it is possible to configure that connection to perform automatic connection recovery. Example: Configuring transport reconnection and failover ConnectionOptions connectionOptions = new ConnectionOptions(); connectionOptions.ReconnectOptions.ReconnectEnabled = true; connectionOptions.ReconnectOptions.ReconnectDelay = 30_000; connectionOptions.ReconnectOptions.AddReconnectLocation(<hostname>, <port>); IConnection connection = client.Connect(serverHost, serverPort, connectionOptions); For a definitive list of options refer to Reconnect and failover

Commands:
ConnectionOptions connectionOptions = new ConnectionOptions(); connectionOptions.User = "user" connectionOptions.Password = "password" IConnection connection = client.Connect(serverHost, serverPort, connectionOptions);
ConnectionOptions connectionOptions = new ConnectionOptions(); connectionOptions.TransportOptions.TcpNoDelay = false; IConnection connection = client.Connect(serverHost, serverPort, connectionOptions);
ConnectionOptions connectionOptions = new ConnectionOptions(); connectionOptions.ReconnectOptions.ReconnectEnabled = true; connectionOptions.ReconnectOptions.ReconnectDelay = 30_000; connectionOptions.ReconnectOptions.AddReconnectLocation(<hostname>, <port>); IConnection connection = client.Connect(serverHost, serverPort, connectionOptions);
Chapter 62. Security certutil does not return the NSS database password requirements in FIPS mode When creating a new Network Security Services (NSS) database with the certutil tool, the user has nowhere to find out what the database password requirements are when running in FIPS mode. The prompt message does not provide password requirements, and certutil returns only a generic error message: (BZ# 1401809 ) systemd-importd runs as init_t The systemd-importd service is using the NoNewPrivileges security flag in the systemd unit file. This blocks the SELinux domain transition from the init_t to systemd_importd_t domain. (BZ# 1365944 ) The SCAP password length requirement is ignored in the kickstart installation The interactive kickstart installation does not enforce the password length check defined by the SCAP rule and accepts shorter root passwords. To work around this problem, use the --strict option with the pwpolicy root command in the kickstart file. (BZ#1372791) rhnsd.pid is writable by group and others In Red Hat Enterprise Linux 7.4, the default permissions of the /var/run/rhnsd.pid file are set to -rw-rw-rw-. . This setting is not secure. To work around this problem, change the permissions of this file to be writable only by the owner: (BZ#1480306)

Commands:
certutil: could not authenticate to token NSS FIPS 140-2 Certificate DB.: SEC_ERROR_IO: An I/O error occurred during security authorization.
chmod go-w /var/run/rhnsd.pid