mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 1. Security hardening settings for SAP HANA You should consider the following before applying the approaches and practices to SAP HANA and SAP application systems: You can install SAP HANA or SAP NetWeaver software and relevant packages with the help of RHEL System Roles for SAP. For more information, refer to Red Hat Enterprise Linux System Roles for SAP and Installing the Minimum Amount of Packages Required . You should implement the recommended settings and steps on a non-production system before making any changes or editing the files according to the Security Hardening guide. It is recommended that you backup the system. You must at least make a backup of the /etc directory. If you follow the steps described in Blocking and allowing applications by using fapolicyd , you must also perform the steps described in the Configuring fapolicyd to allow only SAP HANA executables document. If you follow the steps described in Using SELinux for RHEL, you must also perform the steps described in Using SELinux for SAP HANA. To enhance users' management and access to the RHEL for SAP Solution system, you can configure secure remote communication, sudo access, and set password policy and complexity. For more information, refer to the following: Using secure communications between two systems with OpenSSH Managing sudo access What is pam_faillock and how to use it in Red Hat Enterprise Linux 8 & 9? Set Password Policy & Complexity for RHEL 8 & 9 via pam_pwhistory, pam_pwquality & pam_faillock To keep your Red Hat Enterprise Linux for SAP Solutions systems secured against newly discovered threats and vulnerabilities, refer to Managing and monitoring security updates .

Commands:
16.2. XML Representation of a Floating Disk Example 16.1. An XML representation of a disk device

Commands:
<disk id="ed7feafe-9aaf-458c-809a-ed789cdbd5b4" href="/ovirt-engine/api/disks/ed7feafe-9aaf-458c-809a-ed789cdbd5b4"> <link rel="statistics" href="/ovirt-engine/api/disks/ed7feafe-9aaf-458c-809a-ed789cdbd5b4/statistics"/> <storage_domains> <storage_domain id="fabe0451-701f-4235-8f7e-e20e458819ed"/> </storage_domains> <size>10737418240</size> <type>system</type> <status> <state>ok</state> </status> <interface>virtio</interface> <format>raw</format> <bootable>true</bootable> <shareable>true</shareable> <lunStorage> <storage> <logical_unit id="lun1"> </logical_unit> <storage> </lunStorage> </disk>
Index , Upgrading From Red Hat Enterprise Linux 6 High Availability Add-On , Pacemaker Overview , Pacemaker Architecture Components , Pacemaker Configuration and Management Tools , Upgrading From Red Hat Enterprise Linux 6 High Availability Add-On C cluster fencing, Fencing Overview quorum, Quorum Overview F fencing, Fencing Overview H High Availability Add-On difference between Release 6 and 7, Overview of Differences Between Releases Q quorum, Quorum Overview

Commands:
4.4.3.2. The sudo Command The sudo command offers another approach to giving users administrative access. When trusted users precede an administrative command with sudo , they are prompted for their own password. Then, once authenticated and assuming that the command is permitted, the administrative command is executed as if by the root user. The basic format of the sudo command is as follows: In the above example, <command> would be replaced by a command normally reserved for the root user, such as mount . Important Users of the sudo command should take extra care to log out before walking away from their machines since sudoers can use the command again without being asked for a password within a five minute period. This setting can be altered via the configuration file, /etc/sudoers . The sudo command allows for a high degree of flexibility. For instance, only users listed in the /etc/sudoers configuration file are allowed to use the sudo command and the command is executed in the user's shell, not a root shell. This means the root shell can be completely disabled, as shown in Section 4.4.1, "Allowing Root Access" . The sudo command also provides a comprehensive audit trail. Each successful authentication is logged to the file /var/log/messages and the command issued along with the issuer's user name is logged to the file /var/log/secure . Another advantage of the sudo command is that an administrator can allow different users access to specific commands based on their needs. Administrators wanting to edit the sudo configuration file, /etc/sudoers , should use the visudo command. To give someone full administrative privileges, type visudo and add a line similar to the following in the user privilege specification section: This example states that the user, juan , can use sudo from any host and execute any command. The example below illustrates the granularity possible when configuring sudo : This example states that any user can issue the command /sbin/shutdown -h now as long as it is issued from the console. The man page for sudoers has a detailed listing of options for this file.

Commands:
sudo <command>
juan ALL=(ALL) ALL
%users localhost=/sbin/shutdown -h now
3.5. Repairing an XFS File System To repair an XFS file system, use xfs_repair : The xfs_repair utility is highly scalable and is designed to repair even very large file systems with many inodes efficiently. Unlike other Linux file systems, xfs_repair does not run at boot time, even when an XFS file system was not cleanly unmounted. In the event of an unclean unmount, xfs_repair simply replays the log at mount time, ensuring a consistent file system. Warning The xfs_repair utility cannot repair an XFS file system with a dirty log. To clear the log, mount and unmount the XFS file system. If the log is corrupt and cannot be replayed, use the -L option ("force log zeroing") to clear the log, that is, xfs_repair -L /dev/device . Be aware that this may result in further corruption or data loss. For more information about repairing an XFS file system, see man xfs_repair .

Commands:
xfs_repair /dev/device
17.4. Actions 17.4.1. Export Template Action Note The export storage domain is deprecated. Storage data domains can be unattached from a data center and imported to another data center in the same environment, or in a different environment. Virtual machines, floating virtual disk images, and templates can then be uploaded from the imported storage domain to the attached data center. See the Importing Existing Storage Domains section in the Red Hat Virtualization Administration Guide for information on importing storage domains. The templates collection contains an export action. The export action exports a template to an Export storage domain. A destination storage domain is specified with a storage_domain reference. The export action reports a failed action if a virtual machine template of the same name exists in the destination domain. Set the exclusive parameter to true to change this behavior and overwrite any existing virtual machine template. Example 17.7. Action to export a template to an export storage domain

Commands:
POST /ovirt-engine/api/templates/00000000-0000-0000-0000-000000000000/export HTTP/1.1 Accept: application/xml Content-type: application/xml <action> <storage_domain id="00000000-0000-0000-0000-000000000000"/> <exclusive>true<exclusive/> </action>
probe::vm.write_shared_copy Name probe::vm.write_shared_copy - Page copy for shared page write Synopsis vm.write_shared_copy Values zero boolean indicating whether it is a zero page (can do a clear instead of a copy) name Name of the probe point address The address of the shared write Context The process attempting the write. Description Fires when a write to a shared page requires a page copy. This is always preceded by a vm.write_shared.

Commands:
6.4. Changing the Default Mapping In Red Hat Enterprise Linux 6, Linux users are mapped to the SELinux __default__ login by default (which is in turn mapped to the SELinux unconfined_u user). If you would like new Linux users, and Linux users not specifically mapped to an SELinux user to be confined by default, change the default mapping with the semanage login command. For example, run the following command as the Linux root user to change the default mapping from unconfined_u to user_u : Run the semanage login -l command as the Linux root user to verify the __default__ login is mapped to user_u : If a new Linux user is created and an SELinux user is not specified, or if an existing Linux user logs in and does not match a specific entry from the semanage login -l output, they are mapped to user_u , as per the __default__ login. To change back to the default behavior, run the following command as the Linux root user to map the __default__ login to the SELinux unconfined_u user:

Commands:
~]# semanage login -m -S targeted -s "user_u" -r s0 __default__
~]# semanage login -l Login Name SELinux User MLS/MCS Range __default__ user_u s0 root unconfined_u s0-s0:c0.c1023 system_u system_u s0-s0:c0.c1023
~]# semanage login -m -S targeted -s "unconfined_u" -r s0-s0:c0.c1023 __default__
Chapter 8. Adjusting IdM clients during recovery While IdM servers are being restored, you may need to adjust IdM clients to reflect changes in the replica topology. Procedure Adjusting DNS configuration : If /etc/hosts contains any references to IdM servers, ensure that hard-coded IP-to-hostname mappings are valid. If IdM clients are using IdM DNS for name resolution, ensure that the nameserver entries in /etc/resolv.conf point to working IdM replicas providing DNS services. Adjusting Kerberos configuration : By default, IdM clients look to DNS Service records for Kerberos servers, and will adjust to changes in the replica topology: If IdM clients have been hard-coded to use specific IdM servers in /etc/krb5.conf : make sure kdc , master_kdc and admin_server entries in /etc/krb5.conf are pointing to IdM servers that work properly: Adjusting SSSD configuration : By default, IdM clients look to DNS Service records for LDAP servers and adjust to changes in the replica topology: If IdM clients have been hard-coded to use specific IdM servers in /etc/sssd/sssd.conf , make sure the ipa_server entry points to IdM servers that are working properly: Clearing SSSD's cached information : The SSSD cache may contain outdated information pertaining to lost servers. If users experience inconsistent authentication problems, purge the SSSD cache : Verification Verify the Kerberos configuration by retrieving a Kerberos Ticket-Granting-Ticket as an IdM user. Verify the SSSD configuration by retrieving IdM user information.

Commands:
grep dns_lookup_kdc /etc/krb5.conf dns_lookup_kdc = true
grep dns_lookup_kdc /etc/krb5.conf dns_lookup_kdc = false
[realms] EXAMPLE.COM = { kdc = functional-server.example.com :88 master_kdc = functional-server.example.com :88 admin_server = functional-server.example.com :749 default_domain = example.com pkinit_anchors = FILE:/var/lib/ipa-client/pki/kdc-ca-bundle.pem pkinit_pool = FILE:/var/lib/ipa-client/pki/ca-bundle.pem }
grep ipa_server /etc/sssd/sssd.conf ipa_server = _srv_ , functional-server.example.com
grep ipa_server /etc/sssd/sssd.conf ipa_server = functional-server.example.com
sss_cache -E
kinit admin Password for admin@EXAMPLE.COM: klist Ticket cache: KCM:0 Default principal: admin@EXAMPLE.COM Valid starting Expires Service principal 10/31/2019 18:44:58 11/25/2019 18:44:55 krbtgt/EXAMPLE.COM@EXAMPLE.COM
id admin uid=1965200000(admin) gid=1965200000(admins) groups=1965200000(admins)
Chapter 3. Default FIPS configurations in Red Hat build of OpenJDK 8 3.1. Security providers The Red Hat build of OpenJDK security policy is controled by the global java security policy file. You can find the java security policy file at USDJRE_HOME/lib/security/java.security . With FIPS mode enabled, Red Hat build of OpenJDK replaces the installed security providers with the following ones (in descending priority order): SunPKCS11-NSS-FIPS Initialized with a Network Security Services (NSS) Software Token (PKCS#11 backend). The NSS Software Token is configured as follows: name = NSS-FIPS nssLibraryDirectory = /usr/lib64 nssSecmodDirectory = /etc/pki/nssdb nssDbMode = readOnly nssModule = fips The NSS library implements a FIPS-compliant Software Token. Also, FIPS policy-aware in RHEL. SUN For X.509 certificates support only. Make sure that your application is not using other cryptographic algorithms from this provider. For example, MessageDigest.getInstance("SHA-256", Security.getProvider("SUN")) would work but lead to a non-FIPS compliant MessageDigest service. SunEC For SunPKCS11 auxiliary helpers only. Make sure that your application is not explicitly using this provider. SunJSSE Initialized with the SunPKCS11-NSS-FIPS provider for all cryptographic primitives required by the TLS engine, including key derivation. 3.2. Crypto-policies With FIPS mode enabled, Red Hat build of OpenJDK takes configuration values of cryptographic algorithms from global crypto-policies. You can find these values at /etc/crypto-policies/back-ends/java.config . You can use the update-crypto-policies tooling from RHEL to manage crypto-policies in a consistent way. Note A crypto-policies approved algorithm might not be usable in Red Hat build of OpenJDK's FIPS mode. This occurs when a FIPS-compliant implementation is not available in the NSS library or when it is not supported in Red Hat build of OpenJDK's SunPKCS11 security provider. 3.3. Trust Anchor certificates Red Hat build of OpenJDK uses the global Trust Anchor certificates repository when in FIPS mode. You can locate this repository at /etc/pki/java/cacerts . Use the update-ca-trust tooling from RHEL to manage certificates in a consistent way. 3.4. Key store With FIPS mode, Red Hat build of OpenJDK uses the NSS DB as a read-only PKCS#11 store for keys. As a result, the keystore.type security property is set to PKCS11 . You can locate the NSS DB repository at /etc/pki/nssdb . Use the modutil tooling in RHEL to manage NSS DB keys. Revised on 2024-11-25 10:50:15 UTC

Commands:
2.5.4. The Sysstat Suite of Resource Monitoring Tools While the tools may be helpful for gaining more insight into system performance over very short time frames, they are of little use beyond providing a snapshot of system resource utilization. In addition, there are aspects of system performance that cannot be easily monitored using such simplistic tools. Therefore, a more sophisticated tool is necessary. Sysstat is such a tool. Sysstat contains the following tools related to collecting I/O and CPU statistics: iostat Displays an overview of CPU utilization, along with I/O statistics for one or more disk drives. mpstat Displays more in-depth CPU statistics. Sysstat also contains tools that collect system resource utilization data and create daily reports based on that data. These tools are: sadc Known as the system activity data collector, sadc collects system resource utilization information and writes it to a file. sar Producing reports from the files created by sadc , sar reports can be generated interactively or written to a file for more intensive analysis. The following sections explore each of these tools in more detail. 2.5.4.1. The iostat command The iostat command at its most basic provides an overview of CPU and disk I/O statistics: Below the first line (which contains the system's kernel version and hostname, along with the current date), iostat displays an overview of the system's average CPU utilization since the last reboot. The CPU utilization report includes the following percentages: Percentage of time spent in user mode (running applications, etc.) Percentage of time spent in user mode (for processes that have altered their scheduling priority using nice(2) ) Percentage of time spent in kernel mode Percentage of time spent idle Below the CPU utilization report is the device utilization report. This report contains one line for each active disk device on the system and includes the following information: The device specification, displayed as dev <major-number> - sequence-number , where <major-number> is the device's major number [6] , and <sequence-number> is a sequence number starting at zero. The number of transfers (or I/O operations) per second. The number of 512-byte blocks read per second. The number of 512-byte blocks written per second. The total number of 512-byte blocks read. The total number of 512-byte block written. This is just a sample of the information that can be obtained using iostat . For more information, refer to the iostat(1) man page. [6] Device major numbers can be found by using ls -l to display the desired device file in /dev/ . The major number appears after the device's group specification.

Commands:
Linux 2.4.20-1.1931.2.231.2.10.ent (pigdog.example.com) 07/11/2003 avg-cpu: %user %nice %sys %idle 6.11 2.56 2.15 89.18 Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn dev3-0 1.68 15.69 22.42 31175836 44543290
18.12.8. References to Other Filters Any filter may hold references to other filters. Individual filters may be referenced multiple times in a filter tree but references between filters must not introduce loops. Example 18.7. An Example of a clean traffic filter The following shows the XML of the clean-traffic network filter referencing several other filters. To reference another filter, the XML node filterref needs to be provided inside a filter node. This node must have the attribute filter whose value contains the name of the filter to be referenced. New network filters can be defined at any time and may contain references to network filters that are not known to libvirt, yet. However, once a virtual machine is started or a network interface referencing a filter is to be hotplugged, all network filters in the filter tree must be available. Otherwise the virtual machine will not start or the network interface cannot be attached.

Commands:
<filter name='clean-traffic'> <uuid>6ef53069-ba34-94a0-d33d-17751b9b8cb1</uuid> <filterref filter='no-mac-spoofing'/> <filterref filter='no-ip-spoofing'/> <filterref filter='allow-incoming-ipv4'/> <filterref filter='no-arp-spoofing'/> <filterref filter='no-other-l2-traffic'/> <filterref filter='qemu-announce-self'/> </filter>
Chapter 1. Activating Red Hat Ansible Automation Platform Red Hat Ansible Automation Platform uses available subscriptions or a subscription manifest to authorize the use of Ansible Automation Platform. To obtain a subscription, you can do either of the following: Use your Red Hat customer or Satellite credentials when you launch Ansible Automation Platform. Upload a subscriptions manifest file either using the Red Hat Ansible Automation Platform interface or manually in an Ansible playbook. 1.1. Activate with credentials When Ansible Automation Platform launches for the first time, the Ansible Automation Platform Subscription screen automatically displays. You can use your Red Hat credentials to retrieve and import your subscription directly into Ansible Automation Platform. Procedures Enter your Red Hat username and password. Click Get Subscriptions . Note You can also use your Satellite username and password if your cluster nodes are registered to Satellite through Subscription Manager. Review the End User License Agreement and select I agree to the End User License Agreement . The Tracking and Analytics options are checked by default. These selections help Red Hat improve the product by delivering you a much better user experience. You can opt out by deselecting the options. Click Submit . Once your subscription has been accepted, the license screen displays and navigates you to the Dashboard of the Ansible Automation Platform interface. You can return to the license screen by clicking the Settings icon ⚙ and selecting the License tab from the Settings screen. 1.2. Activate with a manifest file If you have a subscriptions manifest, you can upload the manifest file either using the Red Hat Ansible Automation Platform interface or manually in an Ansible playbook. Prerequisites You must have a Red Hat Subscription Manifest file exported from the Red Hat Customer Portal. For more information, see Obtaining a manifest file . Uploading with the interface Complete steps to generate and download the manifest file Log in to Red Hat Ansible Automation Platform. If you are not immediately prompted for a manifest file, go to Settings License . Make sure the Username and Password fields are empty. Click Browse and select the manifest file. Click . Note If the BROWSE button is disabled on the License page, clear the USERNAME and PASSWORD fields. Uploading manually If you are unable to apply or update the subscription info using the Red Hat Ansible Automation Platform interface, you can upload the subscriptions manifest manually in an Ansible playbook using the license module in the ansible.controller collection. - name: Set the license using a file license: manifest: "/tmp/my_manifest.zip"

Commands:
- name: Set the license using a file license: manifest: "/tmp/my_manifest.zip"
4.9. Configuring Global Cluster Resources You can configure global resources that can be used by any service running in the cluster, and you can configure resources that are available only to a specific service. To add a global cluster resource, follow the steps in this section. You can add a resource that is local to a particular service when you configure the service, as described in Section 4.10, "Adding a Cluster Service to the Cluster" . From the cluster-specific page, you can add resources to that cluster by clicking on Resources along the top of the cluster display. This displays the resources that have been configured for that cluster. Click Add . This displays the Add Resource to Cluster drop-down menu. Click the drop-down box under Add Resource to Cluster and select the type of resource to configure. Enter the resource parameters for the resource you are adding. Appendix B, HA Resource Parameters describes resource parameters. Click Submit . Clicking Submit returns to the resources page that displays the display of Resources , which displays the added resource (and other resources). To modify an existing resource, perform the following steps. From the luci Resources page, click on the name of the resource to modify. This displays the parameters for that resource. Edit the resource parameters. Click Apply . To delete an existing resource, perform the following steps. From the luci Resources page, click the check box for any resources to delete. Click Delete . As of the Red Hat Enterprise Linux 6.6 release, you can sort the columns in a resource list by clicking on the header for the sort category. Clicking on the Name/IP header once sorts the resources alphabetically, according to resource name. Clicking on the Name/IP header a second time sourts the resources in reverse alphabetic order, according to resource name. Clicking on the Type header once sorts the resources alphabetically, according to resource type. Clicking on the Type header a second time sourts the resources in reverse alphabetic order, according to resource type. Clicking on the In Use header once sorts the resources so that they are grouped according to whether they are in use or not.

Commands:
9.3.6. Tuning Domain Process CPU Pinning with virsh Important These are example commands only. You will need to substitute values according to your environment. The emulatorpin option applies CPU affinity settings to threads that are associated with each domain process. For complete pinning, you must use both virsh vcpupin (as shown previously) and virsh emulatorpin for each guest. For example:

Commands:
% virsh emulatorpin rhel6u4 3-4