mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 9. Verifying system certificates using IdM Healthcheck Learn more about identifying issues with system certificates in Identity Management (IdM) by using the Healthcheck tool. For details, see Healthcheck in IdM . 9.1. System certificates Healthcheck tests The Healthcheck tool includes several tests for verifying system (DogTag) certificates. To see all tests, run the ipa-healthcheck with the --list-sources option: You can find all tests under the ipahealthcheck.dogtag.ca source: DogtagCertsConfigCheck This test compares the CA (Certificate Authority) certificates in its NSS database to the same values stored in CS.cfg . If they do not match, the CA fails to start. Specifically, it checks: auditSigningCert cert-pki-ca against ca.audit_signing.cert ocspSigningCert cert-pki-ca against ca.ocsp_signing.cert caSigningCert cert-pki-ca against ca.signing.cert subsystemCert cert-pki-ca against ca.subsystem.cert Server-Cert cert-pki-ca against ca.sslserver.cert If Key Recovery Authority (KRA) is installed: transportCert cert-pki-kra against ca.connector.KRA.transportCert DogtagCertsConnectivityCheck This test verifies connectivity. This test is equivalent to the ipa cert-show 1 command which checks: The PKI proxy configuration in Apache IdM being able to find a CA The RA agent client certificate Correctness of CA replies to requests Note that the test checks a certificate with serial #1 because you want to verify that a cert-show can be executed and get back an expected result from CA (either the certificate or a not found). Note Run these tests on all IdM servers when trying to find an issue. 9.2. Screening system certificates using Healthcheck Follow this procedure to run a standalone manual test of Identity Management (IdM) certificates using the Healthcheck tool. Since, the Healthcheck tool includes many tests, you can narrow the results by including only DogTag tests: --source=ipahealthcheck.dogtag.ca Procedure To run Healthcheck restricted to DogTag certificates, enter: An example of a successful test: An example of a failed test: Additional resources See man ipa-healthcheck .

Commands:
ipa-healthcheck --list-sources
ipa-healthcheck --source=ipahealthcheck.dogtag.ca
{ "source: ipahealthcheck.dogtag.ca", "check: DogtagCertsConfigCheck", "result: SUCCESS", "uuid: 9b366200-9ec8-4bd9-bb5e-9a280c803a9c", "when: 20191008135826Z", "duration: 0.252280", "kw:" { "key": "Server-Cert cert-pki-ca", "configfile": "/var/lib/pki/pki-tomcat/conf/ca/CS.cfg" } }
{ "source: ipahealthcheck.dogtag.ca", "check: DogtagCertsConfigCheck", "result: CRITICAL", "uuid: 59d66200-1447-4b3b-be01-89810c803a98", "when: 20191008135912Z", "duration: 0.002022", "kw:" { "exception": "NSDB /etc/pki/pki-tomcat/alias not initialized", } }
Chapter 3. Adding the Red Hat Integration - AMQ Interconnect The Red Hat Integration - AMQ Interconnect creates and manages AMQ Interconnect router networks in OpenShift Container Platform. This Operator must be installed separately for each project that uses it. You use OperatorHub to add the Operator to your OpenShift Container Platform cluster. Note Installing an Operator requires administrator-level privileges for your OpenShift cluster. Prerequisites Access to an OpenShift Container Platform 4.5 or 4.6 cluster using a cluster-admin account. Red Hat Integration - AMQ Certificate Manager Operator is installed in the OpenShift Container Platform cluster if required. Procedure In the OpenShift Container Platform web console, navigate to Operators OperatorHub . Choose Red Hat Integration - AMQ Interconnect from the list of available Operators, and then click Install . On the Operator Installation page, select the namespace into which you want to install the Operator, and then click Install . The Installed Operators page appears displaying the status of the Operator installation. Verify that the AMQ Interconnect Operator is displayed and wait until the Status changes to Succeeded . If the installation is not successful, troubleshoot the error: Click Red Hat Integration - AMQ Interconnect on the Installed Operators page. Select the Subscription tab and view any failures or errors.

Commands:
Chapter 10. Running a security compliance scan on demand Hosts perform OpenSCAP scans regularly by the CRON schedule defined in the compliance policies assigned to hosts. However, you can also run a scan on a host for all configured compliance policies manually at any time. Prerequisites Your user account has a role assigned that has the view_hosts , create_job_invocations , and view_job_invocations permissions. You have created a compliance policy and deployed it on the host. For more information about managing policies, see Chapter 8, Managing compliance policies . For more information about deploying policies, see Chapter 9, Deploying compliance policies . Procedure Navigate to Hosts > All Hosts . Click the hostname of the required host. On the host details page, expand the Schedule a job dropdown menu. Select Run OpenSCAP scan . Verification In the host details overview, locate the Recent jobs card. Select the Running tab. Unless the job has already finished, the table shows a job called Run scan for all OpenSCAP policies . On the Recent jobs card, select the Finished tab. If the job has finished successfully, you should see the succeeded status in the row of the job. Optional: Click the job name to review invocation details.

Commands:
7.144. openldap 7.144.1. RHBA-2015:1292 - openldap bug fix and enhancement update Updated openldap packages that fix several bugs and add various enhancements are now available for Red Hat Enterprise Linux 6. OpenLDAP is an open-source suite of Lightweight Directory Access Protocol (LDAP) applications and development tools. LDAP is a set of protocols used to access and maintain distributed directory information services over an IP network. The openldap packages contain configuration files, libraries, and documentation for OpenLDAP. Note The openldap packages have been upgraded to upstream version 2.4.40, which provides a number of bug fixes and enhancements over the version. (BZ# 1147983 ) Bug Fixes BZ# 1144294 Previously, openldap did not correctly handle when multiple processes attempted to establish an encrypted connection at the same time. Consequently, utilities, such as the nslcd service, could terminate unexpectedly with a segmentation fault. Incorrect thread initialization code that caused this bug has been fixed. As a result, utilities no longer crash when processes establish multiple concurrent encrypted connections. BZ# 1164369 Previously, the server could terminate unexpectedly when processing SRV records due to invalid memory access. The error that caused the invalid memory access has been corrected, and the server no longer crashes when processing SRV records. BZ# 1193519 Prior to this update, user data was deleted after updating openldap when the slapd.conf file was used to store the configuration, but the slapd.d/ directory also existed. This update fixes incorrect logic in the post-installation script, and user data is no longer deleted in this situation. BZ# 1202696 The server sometimes terminated unexpectedly with a segmentation fault on IBM Power Systems due to a regression. A code optimization that caused this problem has been removed, preventing the segmentation fault from occurring. As a result, the server no longer crashes in this situation. Enhancements BZ# 1155390 This update introduces the Check Password extension for OpenLDAP, required for PCI compliance. BZ# 1160467 Support for the TLS protocol version 1.1 and later has been added. Users of openldap are advised to upgrade to these updated packages, which fix these bugs and add these enhancements.

Commands:
C.17. RollingUpgradeManager org.infinispan.upgrade.RollingUpgradeManager The RollingUpgradeManager component handles the control hooks in order to migrate data from one version of Red Hat JBoss Data Grid to another. Table C.27. Operations Name Description Signature disconnectSource Disconnects the target cluster from the source cluster according to the specified migrator. void disconnectSource(String p0) recordKnownGlobalKeyset Dumps the global known keyset to a well-known key for retrieval by the upgrade process. void recordKnownGlobalKeyset() synchronizeData Synchronizes data from the old cluster to this using the specified migrator. long synchronizeData(String p0) Report a bug

Commands:
10.7. Scheduling Geo-replication as a Cron Job Cron is a daemon that can be used to schedule the execution of recurring tasks according to a combination of the time, day of the month, month, day of the week, and week. Cron assumes that the system is ON continuously. If the system is not ON when a task is scheduled, it is not executed. A script is provided to run geo-replication only when required or to schedule geo-replication to run during low I/O. For more information on installing Cron and configuring Cron jobs, see Automating System Tasks in the Red Hat Enterprise Linux 7 System Administrator's Guide . The script provided to schedule the geo-replication session, performs the following: Stops the geo-replication session, if started Starts the geo-replication session Sets the Checkpoint Checks the status of checkpoint until it is complete After the checkpoint is complete, stops the geo-replication session Run geo-replication Session To run a geo-reolication session only when required, run the following script: For example, Run the following command to view the help: Schedule a Cron Job To schedule geo-replication to run automatically using Cron: For example, to run geo-replication daily at 20:30 hours, run the following:

Commands:
python /usr/share/glusterfs/scripts/schedule_georep.py MASTERVOL SLAVEHOST SLAVEVOL
python /usr/share/glusterfs/scripts/schedule_georep.py Volume1 storage.backup.com slave-vol
python /usr/share/glusterfs/scripts/schedule_georep.py --help
minute hour day month day-of-week directory_and_script-to-execute MASTERVOL SLAVEHOST SLAVEVOL >> log_file_for_script_output
30 20 * * * root python /usr/share/glusterfs/scripts/schedule_georep.py --no-color Volume1 storage.backup.com slave-vol >> /var/log/glusterfs/schedule_georep.log 2>&1
Chapter 1. Red Hat Enterprise Linux 6.5 International Languages Red Hat Enterprise Linux 6.5 supports installation of multiple languages and changing of languages based on your requirements. The following languages are supported in Red Hat Enterprise Linux 6.5: East Asian Languages - Japanese, Korean, Simplified Chinese, and Traditional Chinese European Languages - English, German, Spanish, French, Portuguese Brazilian, and Russian, Indic Languages - Assamese, Bengali, Gujarati, Hindi, Kannada, Malayalam, Marathi, Oriya, Punjabi, Tamil, and Telugu The table below summarizes the currently supported languages, their locales, default fonts installed and packages required for some of the supported languages Table 1.1. Red Hat Enterprise Linux 6 International Languages Territory Language Locale Fonts Package Names China Simplified Chinese zh_CN.UTF-8 AR PL (ShanHeiSun and Zenkai) Uni fonts-chinese, scim-pinyin, scim-tables Japan Japanese ja_JP.UTF-8 Sazanami (Gothic and Mincho) fonts-japanese, scim-anthy Korea Hangul ko_KR.UTF-8 Baekmuk (Batang, Dotum, Gulim, Headline) fonts-korean, scim-hangul Taiwan Traditional Chinese zh_TW.UTF-8 AR PL (ShanHeiSun and Zenkai) Uni fonts-chinese, scim-chewing, scim-tables Brazil Portuguese pt_BR.UTF-8 standard latin fonts France French ft_FR.UTF-8 standard latin fonts Germany German de_DE.UTF-8 standard latin fonts Italy Italy it_IT.UTF-8 standard latin fonts Russia Russian ru_RU.UTF-8 KOI8-R, fonts-KOI8-R-100dpi, fonts-KOI8-R-75dpi and xorg-x11-fonts-cyrillic fonts-KO18-R, fonts-KO18-R-100 dpi,fonts-KO18-R-75dpi, xorg-x11-fonts-cyrillic Spain Spanish es_ES.UTF-8 standard latin fonts India Assamese as_IN.UTF-8 Lohit Bengali fonts-bengali, scim-m17n, m17n-db-assamese Bengali bn_IN.UTF-8 Lohit Bengali fonts-bengali, scim-m17n, m17n-db-bengali Gujarati gu_IN.UTF-8 Lohit Gujarati fonts-gujarati, scim-m17n, m17n-db-gujarati Hindi hi_IN.UTF-8 Lohit Hindi fonts-hindi, scim-m17n, m17n-db-hindi Kannada kn_IN.UTF-8 Lohit Kannada fonts-kannada, scim-m17n, m17n-db-kannada Malayalam ml_IN.UTF-8 Lohit Malayalam fonts-malayalam, scim-m17n, m17n-db-malayalam Marathi mr_IN.UTF-8 Lohit Hindi fonts-hindi, scim-m17n, m17n-db-marathi Oriya or_IN.UTF-8 Lohit Oriya fonts-oriya, scim-m17n, m17n-db-oriya Punjabi pa_IN.UTF-8 Lohit Punjabi fonts-punjabi, scim-m17n, m17n-db-punjabi Tamil ta_IN.UTF-8 Lohit Tamil fonts-tamil, scim-m17n, m17n-db-tamil Telugu te_IN.UTF-8 Lohit Telugu fonts-telugu, scim-m17n, m17n-db-telugu

Commands:
19.2. TCP Wrappers Many UNIX system administrators are accustomed to using TCP wrappers to manage access to certain network services. Any network services managed by xinetd (as well as any program with built-in support for libwrap ) can use TCP wrappers to manage access. xinetd can use the /etc/hosts.allow and /etc/hosts.deny files to configure access to system services. As the names imply, hosts.allow contains a list of rules that allow clients to access the network services controlled by xinetd , and hosts.deny contains rules to deny access. The hosts.allow file takes precedence over the hosts.deny file. Permissions to grant or deny access can be based on individual IP address (or hostnames) or on a pattern of clients. Refer to the Reference Guide and hosts_access in section 5 of the man pages ( man 5 hosts_access ) for details. 19.2.1. xinetd To control access to Internet services, use xinetd , which is a secure replacement for inetd . The xinetd daemon conserves system resources, provides access control and logging, and can be used to start special-purpose servers. xinetd can be used to provide access only to particular hosts, to deny access to particular hosts, to provide access to a service at certain times, to limit the rate of incoming connections and/or the load created by connections, and more xinetd runs constantly and listens on all ports for the services it manages. When a connection request arrives for one of its managed services, xinetd starts up the appropriate server for that service. The configuration file for xinetd is /etc/xinetd.conf , but the file only contains a few defaults and an instruction to include the /etc/xinetd.d directory. To enable or disable an xinetd service, edit its configuration file in the /etc/xinetd.d directory. If the disable attribute is set to yes , the service is disabled. If the disable attribute is set to no , the service is enabled. You can edit any of the xinetd configuration files or change its enabled status using the Services Configuration Tool , ntsysv , or chkconfig . For a list of network services controlled by xinetd , review the contents of the /etc/xinetd.d directory with the command ls /etc/xinetd.d .

Commands:
7.89. iscsi-initiator-utils 7.89.1. RHEA-2015:1371 - iscsi-initiator-utils enhancement update Updated iscsi-initiator-utils packages that add one enhancement are now available for Red Hat Enterprise Linux 6. The iscsi-initiator-utils packages provide the server daemon for the Internet Small Computer System Interface (iSCSI) protocol, as well as the utility programs used to manage it. The iSCSI protocol is a protocol for distributed disk access using SCSI commands sent over Internet Protocol (IP) networks. Enhancement BZ# 691746 The Internet Small Computer System Interface (iSCSI) now supports safe logout. Previously, an iSCSI session was allowed to log out even when an iSCSI device was still mounted, which could cause the host to become unresponsive. This update adds the "iscsi.safe_logout" option. With "iscsi.safe_logout" set to "Yes" in the /etc/iscsi/iscsid.conf file, the system blocks attempts to log out of an iSCSI session when one or more connected iSCSI drives are mounted. Users of iscsi-initiator-utils are advised to upgrade to these updated packages, which add this enhancement.

Commands:
Chapter 2. Architectures Red Hat Enterprise Linux 8.10 is distributed with the kernel version 4.18.0-553, which provides support for the following architectures: AMD and Intel 64-bit architectures The 64-bit ARM architecture IBM Power Systems, Little Endian 64-bit IBM Z Make sure you purchase the appropriate subscription for each architecture. For more information, see Get Started with Red Hat Enterprise Linux - additional architectures . For a list of available subscriptions, see Subscription Utilization on the Customer Portal.

Commands:
10.5.12. LoadModule LoadModule is used to load Dynamic Shared Object (DSO) modules. More information on the Apache HTTP Server's DSO support, including instructions for using the LoadModule directive, can be found in Section 10.7, "Adding Modules" . Note, the load order of the modules is no longer important with Apache HTTP Server 2.0. Refer to Section 10.2.1.3, "Dynamic Shared Object (DSO) Support" for more information about Apache HTTP Server 2.0 DSO support.

Commands:
5.2. abrt and libreport 5.2.1. RHSA-2013:0215 - Important: abrt and libreport security update Updated abrt and libreport packages that fix two security issues are now available for Red Hat Enterprise Linux 6. The Red Hat Security Response Team has rated this update as having important security impact. Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) associated with each description below. ABRT (Automatic Bug Reporting Tool) is a tool to help users to detect defects in applications and to create a bug report with all the information needed by a maintainer to fix it. It uses a plug-in system to extend its functionality. libreport provides an API for reporting different problems in applications to different bug targets, such as Bugzilla, FTP, and Trac. Security Fixes CVE-2012-5659 It was found that the /usr/libexec/abrt-action-install-debuginfo-to-abrt-cache tool did not sufficiently sanitize its environment variables. This could lead to Python modules being loaded and run from non-standard directories (such as /tmp/). A local attacker could use this flaw to escalate their privileges to that of the abrt user. CVE-2012-5660 A race condition was found in the way ABRT handled the directories used to store information about crashes. A local attacker with the privileges of the abrt user could use this flaw to perform a symbolic link attack, possibly allowing them to escalate their privileges to root. Red Hat would like to thank Martin Carpenter of Citco for reporting the CVE-2012-5660 issue. CVE-2012-5659 was discovered by Miloslav Trmac of Red Hat. All users of abrt and libreport are advised to upgrade to these updated packages, which correct these issues.

Commands:
8.59. finger 8.59.1. RHBA-2014:0587 - finger bug fix update Updated finger packages that fix one bug are now available for Red Hat Enterprise Linux 6. The finger utility allows users to display information about users on the system, including their login names, full names, and the time they logged in to the system. Bug Fix BZ# 816328 When the "compat" method is specified in the nsswitch.conf file, special entries containing the "+" or "-" characters are allowed to be used in the /etc/passwd file. Previously, when the finger utility was run with a "username" argument on a host that had the special entries in /etc/passwd, finger terminated with a segmentation fault. With this update, the code that handles the "username" argument has been fixed to perform the necessary checks and the finger utility no longer crashes in the described scenario. All users of finger are advised to upgrade to these updated packages, which fix this bug.

Commands:
11.7. Network Function Files Red Hat Enterprise Linux makes use of several files that contain important common functions used to bring interfaces up and down. Rather than forcing each interface control file to contain these functions, they are grouped together in a few files that are called upon when necessary. The /etc/sysconfig/network-scripts/network-functions file contains the most commonly used IPv4 functions, which are useful to many interface control scripts. These functions include contacting running programs that have requested information about changes in the status of an interface, setting host names, finding a gateway device, verifying whether or not a particular device is down, and adding a default route. As the functions required for IPv6 interfaces are different from IPv4 interfaces, a /etc/sysconfig/network-scripts/network-functions-ipv6 file exists specifically to hold this information. The functions in this file configure and delete static IPv6 routes, create and remove tunnels, add and remove IPv6 addresses to an interface, and test for the existence of an IPv6 address on an interface.

Commands:
Chapter 6. Administrative Tasks 6.1. Shutting Down a Virtual Machine You can turn off a virtual machine using Shutdown or Power Off . Shutdown gracefully shuts down a virtual machine. Power Off executes a hard shutdown. A graceful shutdown is usually preferable to a hard shutdown. Note If an exclamation point appears to the virtual machine, a snapshot deletion process has failed, and you may not be able to restart the machine after shutting it down. Try to delete the snapshot again and ensure that the explanation mark disappears before shutting down the virtual machine. See Section 6.9.4, "Deleting a Snapshot" for more information. Procedure Click Compute Virtual Machines and select a running virtual machine. Click Shutdown . Optionally in the Administration Portal, enter a Reason for shutting down the virtual machine in the Shut down Virtual Machine(s) confirmation window. This allows you to provide an explanation for the shutdown, which will appear in the logs and when the virtual machine is powered on again. Note The virtual machine shutdown Reason field will only appear if it has been enabled in the cluster settings. For more information, see Explanation of Settings and Controls in the New Cluster and Edit Cluster Windows in the Administration Guide . Click OK in the Shut down Virtual Machine(s) confirmation window. If the virtual machine gracefully shuts down, the Status of the virtual machine changes to Down . If the virtual machine does not gracefully shut down, click the down arrow to Shutdown and then click Power Off to execute a hard shutdown.

Commands:
8.5. Automatically Starting Guest Virtual Machines This section covers how to make guest virtual machines start automatically during the host physical machine system's boot phase. This example uses virsh to set a guest virtual machine, TestServer , to automatically start when the host physical machine boots. The guest virtual machine now automatically starts with the host physical machine. To stop a guest virtual machine automatically booting use the --disable parameter The guest virtual machine no longer automatically starts with the host physical machine.

Commands:
virsh autostart TestServer Domain TestServer marked as autostarted
virsh autostart --disable TestServer Domain TestServer unmarked as autostarted