mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 3. Red Hat build of OpenJDK 8.0.372 release notes The latest Red Hat build of OpenJDK 8 release might include new features. Additionally, the latest release might enhance, deprecate, or remove features that originated from Red Hat build of OpenJDK 8 releases. Note For all the other changes and security fixes, see OpenJDK 8u372 Released . Red Hat build of OpenJDK new features and enhancements Review the following release notes to understand new features and feature enhancements that the Red Hat build of OpenJDK 8.0.372 release provides: Detection of control group (cgroup) v2 host systems in Linux containers The Red Hat build of OpenJDK 8.0.372 release includes an update to the HotSpot runtime code and the core libraries code in the JDK. This update enables the detection of cgroup v2 host systems when running Red Hat build of OpenJDK within a Linux container. Previously, from Red Hat build of OpenJDK release 8u202 onward, the container detection code recognized cgroup v1 (legacy) host Linux systems only. Now, from Red Hat build of OpenJDK 8.0.372 onward, Red Hat build of OpenJDK detects both versions of the underlying cgroups pseudo file-system and applies corresponding container limits to the Red Hat build of OpenJDK runtime. Without this enhancement, when running on a cgroup v2 Linux host system, Red Hat build of OpenJDK would have used the underlying hosts' resource limits instead of applying container resource limits. See JDK-8305562 (JDK Bug System) . Configuration of third port for remote Java Management Extensions (JMX) In release Red Hat build of OpenJDK 8.0.372, you can configure a local access port for remote JMX connections by setting the com.sun.management.jmxremote.local.port property. In releases,Red Hat build of OpenJDK selected this local port at random, which could lead to port collisions. The com.sun.management.jmxremote.local.port property works in the same way as the existing properties for configuring the remote access port ( com.sun.management.jmxremote.port ) and the Remote Method Invocation (RMI) port ( com.sun.management.jmxremote.rmi.port ). See JDK-8234484 (JDK Bug System) . Certigna (Dhimyotis) root certificate authority (CA) certificate added In release Red Hat build of OpenJDK 8.0.372, the cacerts truststore includes the Certigna (Dhimyotis) root certificate: Name: Certigna (Dhimyotis) Alias name: certignarootca Distinguished name: CN=Certigna, O=Dhimyotis, C=FR See JDK-8245654 (JDK Bug System) . Enhanced Swing platform support In earlier releases of Red Hat build of OpenJDK, HTML object tags rendered embedded in Swing HTML components. With release Red Hat build of OpenJDK 8.0.372, rendering only occurs if you set the new system property swing.html.object to true. By default, the swing.html.object property is set to false. JDK bug system reference ID: JDK-8296832.

Commands:
Chapter 4. Container Images Based on Red Hat Software Collections 3.7 Component Description Supported architectures Application Images rhscl/ruby-30-rhel7 Ruby 3.0 platform for building and running applications x86_64, s390x, ppc64le rhscl/ruby-27-rhel7 Ruby 2.7 platform for building and running applications (EOL) x86_64, s390x, ppc64le rhscl/ruby-26-rhel7 Ruby 2.6 platform for building and running applications (EOL) x86_64, s390x, ppc64le Database Images rhscl/mariadb-105-rhel7 MariaDB 10.5 SQL database server x86_64, s390x, ppc64le rhscl/postgresql-13-rhel7 PostgreSQL 13 SQL database server x86_64, s390x, ppc64le Red Hat Developer Toolset Images rhscl/devtoolset-10-toolchain-rhel7 Red Hat Developer Toolset toolchain (EOL) x86_64, s390x, ppc64le rhscl/devtoolset-10-perftools-rhel7 Red Hat Developer Toolset perftools (EOL) x86_64, s390x, ppc64le Legend: x86_64 - AMD64 and Intel 64 architectures s390x - 64-bit IBM Z ppc64le - IBM POWER, little endian All images are based on components from Red Hat Software Collections. The images are available for Red Hat Enterprise Linux 7 through the Red Hat Container Registry. For detailed information about components provided by Red Hat Software Collections 3.7 , see the Red Hat Software Collections 3.7 Release Notes . For more information about the Red Hat Developer Toolset 10 components, see the Red Hat Developer Toolset 10 User Guide . For information regarding container images based on Red Hat Software Collections 2, see Using Red Hat Software Collections 2 Container Images . EOL images are no longer supported.

Commands:
10.3. National Industrial Security Program Operating Manual (NISPOM) The NISPOM (also called DoD 5220.22-M), as a component of the National Industrial Security Program (NISP), establishes a series of procedures and requirements for all government contractors with regard to classified information. The current NISPOM is dated February 28, 2006 with incorporated major changes from March 28, 2013. The NISPOM document can be downloaded from the following URL: http://www.nispom.org/NISPOM-download.html .

Commands:
15.5. Configuring a Default Server List From the system administrator's point of view, it is not possible to set a group of bookmarks for all users at once. Nevertheless, the system administrator can allow access to file shares for their users. Nautilus stores a list of file-sharing servers in the ~/.config/nautilus/servers file in the XBEL format. It is possible to add the list of file-sharing servers to that file to make file shares easily accessible to your users. Note XBEL (XML Bookmark Exchange Language) is an XML standard that lets you share URIs (Uniform Resource Identifiers). In GNOME, XBEL is used to share desktop bookmarks in applications such as Nautilus . In the example below, Nautilus creates a bookmark titled GNOME FTP with the URI ftp://ftp.gnome.org/ in the ~/.config/nautilus/servers file. Example 15.4. The ~/.config/nautilus/servers File <?xml version="1.0" encoding="UTF-8"?> <xbel version="1.0" xmlns:bookmark="http://www.freedesktop.org/standards/desktop-bookmarks" xmlns:mime="http://www.freedesktop.org/standards/shared-mime-info"> <bookmark href="<input>ftp://ftp.gnome.org/</input>"> <title><input>GNOME FTP</input></title> </bookmark> </xbel>

Commands:
<?xml version="1.0" encoding="UTF-8"?> <xbel version="1.0" xmlns:bookmark="http://www.freedesktop.org/standards/desktop-bookmarks" xmlns:mime="http://www.freedesktop.org/standards/shared-mime-info"> <bookmark href="<input>ftp://ftp.gnome.org/</input>"> <title><input>GNOME FTP</input></title> </bookmark> </xbel>
15.2. Booleans SELinux is based on the least level of access required for a service to run. Services can be run in a variety of ways; therefore, you need to specify how you run your services. Use the following Booleans to set up SELinux: ftpd_anon_write When disabled, this Boolean prevents vsftpd from writing to files and directories labeled with the public_content_rw_t type. Enable this Boolean to allow users to upload files using FTP. The directory where files are uploaded to must be labeled with the public_content_rw_t type and Linux permissions must be set accordingly. ftpd_full_access When this Boolean is enabled, only Linux (DAC) permissions are used to control access, and authenticated users can read and write to files that are not labeled with the public_content_t or public_content_rw_t types. ftpd_use_cifs Having this Boolean enabled allows vsftpd to access files and directories labeled with the cifs_t type; therefore, having this Boolean enabled allows you to share file systems mounted using Samba through vsftpd . ftpd_use_nfs Having this Boolean enabled allows vsftpd to access files and directories labeled with the nfs_t type; therefore, this Boolean allows you to share file systems mounted using NFS through vsftpd . ftpd_connect_db Allow FTP daemons to initiate a connection to a database. httpd_enable_ftp_server Allow the httpd daemon to listen on the FTP port and act as a FTP server. tftp_anon_write Having this Boolean enabled allows TFTP access to a public directory, such as an area reserved for common files that otherwise has no special access restrictions. Important Red Hat Enterprise Linux 7.7 does not provide the ftp_home_dir Boolean. See the Red Hat Enterprise Linux 7.3 Release Notes document for more information. Note Due to the continuous development of the SELinux policy, the list above might not contain all Booleans related to the service at all times. To list them, enter the following command: Enter the following command to view description of a particular Boolean: Note that the additional policycoreutils-devel package providing the sepolicy utility is required for this command to work.

Commands:
~]USD getsebool -a | grep service_name
~]USD sepolicy booleans -b boolean_name
1.6. Know Your Business Whether you work for a large, multinational corporation or a small community college, you must still understand the nature of the business environment in which you work. This can be boiled down to one question: What is the purpose of the systems you administer? The key point here is to understand your systems' purpose in a more global sense: Applications that must be run within certain time frames, such as at the end of a month, quarter, or year The times during which system maintenance may be done New technologies that could be used to resolve long-standing business problems By taking into account your organization's business, you will find that your day-to-day decisions will be better for your users, and for you.

Commands:
7.246. system-config-kickstart 7.246.1. RHEA-2013:0470 - system-config-kickstart enhancement update An updated system-config-kickstart package that adds one enhancement is now available for Red Hat Enterprise Linux 6. The system-config-kickstart package contains Kickstart Configurator, a graphical tool for creating kickstart files. Enhancement BZ#819813 This update contains a complete Assamese translation of the system-config-kickstart package. Users requiring Assamese translation of system-config-kickstart are advised to upgrade to this updated package, which adds this enhancement.

Commands:
3.7.3. Configuring Specific Applications Different applications provide their own configuration mechanisms for TLS . This section describes the TLS -related configuration files employed by the most commonly used server applications and offers examples of typical configurations. Regardless of the configuration you choose to use, always make sure to mandate that your server application enforces server-side cipher order , so that the cipher suite to be used is determined by the order you configure. 3.7.3.1. Configuring the Apache HTTP Server The Apache HTTP Server can use both OpenSSL and NSS libraries for its TLS needs. Depending on your choice of the TLS library, you need to install either the mod_ssl or the mod_nss module (provided by eponymous packages). For example, to install the package that provides the OpenSSL mod_ssl module, issue the following command as root: The mod_ssl package installs the /etc/httpd/conf.d/ssl.conf configuration file, which can be used to modify the TLS -related settings of the Apache HTTP Server . Similarly, the mod_nss package installs the /etc/httpd/conf.d/nss.conf configuration file. Install the httpd-manual package to obtain a complete documentation for the Apache HTTP Server , including TLS configuration. The directives available in the /etc/httpd/conf.d/ssl.conf configuration file are described in detail in /usr/share/httpd/manual/mod/mod_ssl.html . Examples of various settings are in /usr/share/httpd/manual/ssl/ssl_howto.html . When modifying the settings in the /etc/httpd/conf.d/ssl.conf configuration file, be sure to consider the following three directives at the minimum: SSLProtocol Use this directive to specify the version of TLS (or SSL ) you want to allow. SSLCipherSuite Use this directive to specify your preferred cipher suite or disable the ones you want to disallow. SSLHonorCipherOrder Uncomment and set this directive to on to ensure that the connecting clients adhere to the order of ciphers you specified. For example: Note that the above configuration is the bare minimum, and it can be hardened significantly by following the recommendations outlined in Section 3.7.1, "Choosing Algorithms to Enable" . To configure and use the mod_nss module, modify the /etc/httpd/conf.d/nss.conf configuration file. The mod_nss module is derived from mod_ssl , and as such it shares many features with it, not least the structure of the configuration file, and the directives that are available. Note that the mod_nss directives have a prefix of NSS instead of SSL . See https://git.fedorahosted.org/cgit/mod_nss.git/plain/docs/mod_nss.html for an overview of information about mod_nss , including a list of mod_ssl configuration directives that are not applicable to mod_nss .

Commands:
~]# yum install mod_ssl
SSLProtocol all -SSLv2 -SSLv3 SSLCipherSuite HIGH:!aNULL:!MD5 SSLHonorCipherOrder on
Appendix C. S3 common response status codes The following table lists the valid common HTTP response status and its corresponding code. Table C.1. Response Status HTTP Status Response Code 100 Continue 200 Success 201 Created 202 Accepted 204 NoContent 206 Partial content 304 NotModified 400 InvalidArgument 400 InvalidDigest 400 BadDigest 400 InvalidBucketName 400 InvalidObjectName 400 UnresolvableGrantByEmailAddress 400 InvalidPart 400 InvalidPartOrder 400 RequestTimeout 400 EntityTooLarge 403 AccessDenied 403 UserSuspended 403 RequestTimeTooSkewed 404 NoSuchKey 404 NoSuchBucket 404 NoSuchUpload 405 MethodNotAllowed 408 RequestTimeout 409 BucketAlreadyExists 409 BucketNotEmpty 411 MissingContentLength 412 PreconditionFailed 416 InvalidRange 422 UnprocessableEntity 500 InternalError

Commands:
22.4. Additional Resources For configuration options not covered here, please refer to the following resources. 22.4.1. Installed Documentation smb.conf man page - explains how to configure the Samba configuration file smbd man page - describes how the Samba daemon works smbclient and findsmb man pages - learn more about these client tools /usr/share/doc/samba- <version-number> /docs/ - help files included with the samba package

Commands:
Chapter 3. Using the OpenShift Container Platform dashboard to get cluster information Access the OpenShift Container Platform dashboard, which captures high-level information about the cluster, by navigating to Home Dashboards Overview from the OpenShift Container Platform web console. The OpenShift Container Platform dashboard provides various cluster information, captured in individual dashboard cards. 3.1. About the OpenShift Container Platform dashboards page The OpenShift Container Platform dashboard consists of the following cards: Details provides a brief overview of informational cluster details. Status include ok , error , warning , in progress , and unknown . Resources can add custom status names. Cluster ID Provider Version Cluster Inventory details number of resources and associated statuses. It is helpful when intervention is required to resolve problems, including information about: Number of nodes Number of pods Persistent storage volume claims Bare metal hosts in the cluster, listed according to their state (only available in metal3 environment). Cluster Capacity charts help administrators understand when additional resources are required in the cluster. The charts contain an inner ring that displays current consumption, while an outer ring displays thresholds configured for the resource, including information about: CPU time Memory allocation Storage consumed Network resources consumed Cluster Utilization shows the capacity of various resources over a specified period of time, to help administrators understand the scale and frequency of high resource consumption. Events lists messages related to recent activity in the cluster, such as pod creation or virtual machine migration to another host. Top Consumers helps administrators understand how cluster resources are consumed. Click on a resource to jump to a detailed page listing pods and nodes that consume the largest amount of the specified cluster resource (CPU, memory, or storage).

Commands:
29.3. Scenario 1: Using SSSD as Part of Migration Important This is a general migration procedure, but it may not work in every environment. It is strongly recommended that you set up a test LDAP environment and test the migration process before attempting to migrate the real LDAP environment. Set up SSSD. Using SSSD allows the required Kerberos keys and server certificates to be delivered to the clients. Install SSSD on every client machine: Configure an LDAP identity provider in SSSD to use the existing Directory Server for all functions (authentication, identity lookups, access, and password changes). This ensures every client works properly with the existing directory service. Install Identity Management, including any custom LDAP directory schema [11] , on a different machine from the existing LDAP directory. Enable the IdM server to allow migration: Disable the compat plug-in. Restart the IdM Directory Server instance. Run the IdM migration script, ipa migrate-ds . At its most basic, this requires only the LDAP URL of the LDAP directory instance to migrate: Simply passing the LDAP URL migrates all of the directory data using common default settings. The user and group data can be selectively migrated by specifying other options, as covered in Section 29.2, "Examples for Using migrate-ds" . Once the information is exported, the script adds all required IdM object classes and attributes and converts DNs in attributes to match the IdM directory tree. Re-enable the compat plug-in. Restart the IdM Directory Server instance. Move clients that have SSSD installed from the LDAP backend to the Identity Management backend and enroll them as client with IdM. This downloads the required keys and certificates. On Red Hat Enterprise Linux clients, this can be done using the ipa-client-install command. For example: # ipa-client-install --enable-dns-updates Have users log into a machine with SSSD and Identity Management backend. This generates the required Kerberos keys for the user. To monitor the user migration process, query the existing LDAP directory to see which user accounts have a password but do not yet have a Kerberos principal key. Note Include the quotes around the filter so that it is not interpreted by the shell. Once users have been migrated over, configure non-SSSD clients to use the IdM domain, as required. When the migration of all clients and users is complete, decommission the LDAP directory. [11] There is limited support for custom user and group schema in Identity Management.

Commands:
yum install sssd
ipa config-mod --enable-migration=TRUE
ipa-compat-manage disable
service dirsrv restart
ipa migrate-ds ldap://ldap.example.com:389
ipa-compat-manage enable
service dirsrv restart
ipa-client-install --enable-dns-updates
ldapsearch -LL -x -D 'cn=Directory Manager' -w secret -b 'ou=people,dc=example,dc=com' '(&(!(krbprincipalkey=*))(userpassword=*))' uid
Chapter 8. Deploying Red Hat Insights If you are using Red Hat Insights as the data collection tool, deploy Red Hat Insights on every RHEL system that is managed by Red Hat Satellite. Do these steps To install Red Hat Insights, see the following information: Installing Red Hat Insights Learn more To learn more about what data Red Hat Insights collects and your options for controlling that data, see the following information: What data does Red Hat Insights collect? 8.1. Installing Red Hat Insights Install Red Hat Insights to collect information about your inventory. Procedure Install the Insights client on every RHEL system that is managed by Red Hat Satellite by using the following instructions: Red Hat Insights on Satellite Red Hat Enterprise Linux (RHEL) Note The Insights client is installed by default on RHEL 8 and later systems unless the minimal installation option was used to install RHEL. However, the client must still be registered, as documented in the client installation instructions. 8.2. What data does Red Hat Insights collect? When the Red Hat Insights client is installed on a system, it collects data about that system on a daily basis and sends it to the Red Hat Insights cloud application. The data might also be shared with other applications on the Hybrid Cloud Console, such as inventory or the subscriptions service services. Insights provides configuration and command options, including options for data obfuscation and data redaction, to manage that data. For more information, see the Client Configuration Guide for Red Hat Insights , available with the Red Hat Insights product documentation. You might also want to examine the types of data that Insights collects and sends to Red Hat or add controls to the data that is sent. For additional information that supplements the information available in the product documentation, see the following articles: For more information about the use of the insights-client --offline command to generate an offline dump of the data before you register a system to Insights, see How can I see what data is collected by Red Hat Insights? For more information about the use of the insights-client --no-upload command to run a test data collection process, see System Information Collected by Red Hat Insights . For more information about the use of the remove.conf file and its options to exclude specific data from collection based on file, command, pattern, and keyword settings, see Opting Out of Sending Metadata from Red Hat Insights Client .

Commands:
34.6. Configure Partition Handling In Red Hat JBoss Data Grid, partition handling is disabled as a default. Declarative Configuration (Library Mode) Enable partition handling declaratively as follows: Programmatic Configuration (Library Mode) Enable partition handling programmatically as follows: Declarative Configuration (Remote Client-server Mode) Enable partition handling declaratively in remote client-server mode by using the following configuration: Report a bug

Commands:
<namedCache name="myCache"> <clustering mode="distribution"> <partitionHandling enabled="true" /> </clustering> </namedCache>
ConfigurationBuilder dcc = new ConfigurationBuilder(); dcc.clustering().partitionHandling().enabled(true);
<subsystem xmlns="urn:infinispan:server:core:6.2" default-cache-container="clustered"> <cache-container name="clustered" default-cache="default" statistics="true"> <distributed-cache name="default" mode="SYNC" segments="20" owners="2" remote-timeout="30000" start="EAGER"> <partition-handling enabled="true" /> <locking isolation="READ_COMMITTED" acquire-timeout="30000" concurrency-level="1000" striping="false"/> <transaction mode="NONE"/> </distributed-cache> </cache-container> </subsystem>