mtpti5iD/redhat-docs_dataset huggingface dataset:
11.7. REST Interface Security 11.7.1. Publish REST Endpoints as a Public Interface Red Hat JBoss Data Grid's REST server operates as a management interface by default. To extend its operations to a public interface, alter the value of the interface parameter in the socket-binding element from management to public as follows: Report a bug 11.7.2. Enable Security for the REST Endpoint Use the following procedure to enable security for the REST endpoint in Red Hat JBoss Data Grid. Note The REST endpoint supports any of the JBoss Enterprise Application Platform security subsystem providers. Procedure 11.2. Enable Security for the REST Endpoint To enable security for JBoss Data Grid when using the REST interface, make the following changes to standalone.xml : Specify Security Parameters Ensure that the rest endpoint specifies a valid value for the security-domain and auth-method parameters. Recommended settings for these parameters are as follows: Check Security Domain Declaration Ensure that the security subsystem contains the corresponding security-domain declaration. For details about setting up security-domain declarations, see the JBoss Enterprise Application Platform 6 documentation. Add an Application User Run the relevant script and enter the configuration settings to add an application user. Run the adduser.sh script (located in USDJDG_HOME/bin ). On a Windows system, run the adduser.bat file (located in USDJDG_HOME/bin ) instead. When prompted about the type of user to add, select Application User (application-users.properties) by entering b . Accept the default value for realm ( ApplicationRealm ) by pressing the return key. Specify a username and password. When prompted for a group, enter REST . Ensure the username and application realm information is correct when prompted and enter "yes" to continue. Verify the Created Application User Ensure that the created application user is correctly configured. Check the configuration listed in the application-users.properties file (located in USDJDG_HOME/standalone/configuration/ ). The following is an example of what the correct configuration looks like in this file: Check the configuration listed in the application-roles.properties file (located in USDJDG_HOME/standalone/configuration/ ). The following is an example of what the correct configuration looks like in this file: Test the Server Start the server and enter the following link in a browser window to access the REST endpoint: Note If testing using a GET request, a 405 response code is expected and indicates that the server was successfully authenticated. Report a bug

Commands:
<socket-binding name="http" interface="public" port="8080"/>
<subsystem xmlns="urn:infinispan:server:endpoint:6.1"> <rest-connector virtual-server="default-host" cache-container="local" security-domain="other" auth-method="BASIC"/> </subsystem>
user1=2dc3eacfed8cf95a4a31159167b936fc
user1=REST
http://localhost:8080/rest/namedCache
9.2. Host-based IDS A host-based IDS analyzes several areas to determine misuse (malicious or abusive activity inside the network) or intrusion (breaches from the outside). Host-based IDSes consult several types of log files (kernel, system, server, network, firewall, and more), and compare the logs against an internal database of common signatures for known attacks. UNIX and Linux host-based IDSes make heavy use of syslog and its ability to separate logged events by their severity (for example, minor printer messages versus major kernel warnings). The syslog command is available when installing the sysklogd package, which is included with Red Hat Enterprise Linux. This package provides system logging and kernel message trapping. The host-based IDS filters logs (which, in the case of some network and kernel event logs, can be quite verbose), analyzes them, re-tags the anomalous messages with its own system of severity rating, and collects them in its own specialized log for administrator analysis. A host-based IDS can also verify the data integrity of important files and executables. It checks a database of sensitive files (and any files added by the administrator) and creates a checksum of each file with a message-file digest utility such as md5sum (128-bit algorithm) or sha1sum (160-bit algorithm). The host-based IDS then stores the sums in a plain text file and periodically compares the file checksums against the values in the text file. If any of the file checksums do not match, the IDS alerts the administrator by email or cellular pager. This is the process used by Tripwire, which is discussed in Section 9.2.1, "Tripwire" . 9.2.1. Tripwire Tripwire is the most popular host-based IDS for Linux. Tripwire, Inc., the developers of Tripwire, opened the software source code for the Linux version and licensed it under the terms of the GNU General Public License. Tripwire is available from http://www.tripwire.org/ . Note Tripwire is not included with Red Hat Enterprise Linux and is not supported. It has been included in this document as a reference to users who may be interested in using this popular application.

Commands:
Chapter 45. Mirroring a network interface by using nmcli Network administrators can use port mirroring to replicate inbound and outbound network traffic being communicated from one network device to another. Mirroring traffic of an interface can be helpful in the following situations: To debug networking issues and tune the network flow To inspect and analyze the network traffic To detect an intrusion Prerequisites A network interface to mirror the network traffic to. Procedure Add a network connection profile that you want to mirror the network traffic from: Attach a prio qdisc to enp1s0 for the egress (outgoing) traffic with the 10: handle: The prio qdisc attached without children allows attaching filters. Add a qdisc for the ingress traffic, with the ffff: handle: Add the following filters to match packets on the ingress and egress qdiscs , and to mirror them to enp7s0 : The matchall filter matches all packets, and the mirred action redirects packets to destination. Activate the connection: Verification Install the tcpdump utility: Display the traffic mirrored on the target device ( enp7s0 ): Additional resources How to capture network packets using tcpdump (Red Hat Knowledgebase)

Commands:
nmcli connection add type ethernet ifname enp1s0 con-name enp1s0 autoconnect no
nmcli connection modify enp1s0 +tc.qdisc "root prio handle 10:"
nmcli connection modify enp1s0 +tc.qdisc "ingress handle ffff:"
nmcli connection modify enp1s0 +tc.tfilter "parent ffff: matchall action mirred egress mirror dev enp7s0 " nmcli connection modify enp1s0 +tc.tfilter "parent 10: matchall action mirred egress mirror dev enp7s0 "
nmcli connection up enp1s0
dnf install tcpdump
tcpdump -i enp7s0
Chapter 7. 15 February 2024 This release includes several enhancements, additions, and fixes that have been implemented in Red Hat Ansible Lightspeed. 7.1. New features and enhancements Model customization Organization administrators can now create and use fine-tuned, custom models that are trained on your organization's existing Ansible content. With this capability, you can tune the models to your organization's automation patterns and improve the code recommendation experience. You can configure multiple custom models for your organization. For example, you can create a custom model for your corporate IT automation team and a different one for your engineering team's infrastructure. You can also configure a custom model to make it available for all Ansible users or select Ansible users in your organization. For more information, see Configuring custom models . Streamlined the setup process Previously, organization administrators had to assign seat licenses to users so that they could access Red Hat Ansible Lightspeed. With the new subscription plans from IBM watsonx Code Assistant, organization administrators no longer need to manage access to Red Hat Ansible Lightspeed by assigning or removing seat licenses.

Commands:
2.6.3. Related Books The following books discuss various issues related to resource monitoring and are good resources for Red Hat Enterprise Linux system administrators: The System Administrators Guide ; Red Hat, Inc -- Includes information on many of the resource monitoring tools described here, including OProfile. Linux Performance Tuning and Capacity Planning by Jason R. Fink and Matthew D. Sherer; Sams -- Provides more in-depth overviews of the resource monitoring tools presented here and includes others that might be appropriate for more specific resource monitoring needs. Red Hat Linux Security and Optimization by Mohammed J. Kabir; Red Hat Press -- Approximately the first 150 pages of this book discuss performance-related issues. This includes chapters dedicated to performance issues specific to network, Web, email, and file servers. Linux Administration Handbook by Evi Nemeth, Garth Snyder, and Trent R. Hein; Prentice Hall -- Provides a short chapter similar in scope to this book, but includes an interesting section on diagnosing a system that has suddenly slowed down. Linux System Administration: A User's Guide by Marcel Gagne; Addison Wesley Professional -- Contains a small chapter on performance monitoring and tuning.

Commands:
25.4. Configuration Examples 25.4.1. Changing the Default OpenShift Directory By default, OpenShift stores its data in the /var/lib/openshift/ directory, which is labeled with the openshift_var_lib_t SELinux type. To allow OpenShift to store data in a different directory, label the new directory with the proper SELinux context. The following procedure shows how to change the default OpenShift directory for storing data to /srv/openshift/ : Procedure 25.1. Changing the Default OpenShift Directory for Storing Data As root, create a new openshift/ directory within the /srv directory. The new directory is labeled with the var_t type: As root, use the semanage utility to map /srv/openshift/ to the proper SELinux context: Then, use the restorecon utility as root to apply the changes: The /srv/openshift/ directory is now labeled with the correct openshift_var_lib_t type:

Commands:
~]# mkdir /srv/openshift
~]USD ls -Zd /srv/openshift drwxr-xr-x. root root unconfined_u:object_r:var_t:s0 openshift/
~]# semanage fcontext -a -e /var/lib/openshift /srv/openshift
~]# restorecon -R -v /srv/openshift
~]USD ls -Zd /srv/openshift drwxr-xr-x. root root unconfined_u:object_r:openshift_var_lib_t:s0 openshift/
3.7.2. OProfile OProfile ( oprofile ) is a system-wide performance monitoring tool. It uses the processor's dedicated performance monitoring hardware to retrieve information about the kernel and system executables, such as when memory is referenced, the number of L2 cache requests, and the number of hardware interrupts received. It can also be used to determine processor usage, and which applications and services are used most. OProfile can also be used with Eclipse via the Eclipse OProfile plug-in. This plug-in allows users to easily determine the most time-consuming areas of their code, and perform all command-line functions of OProfile with rich visualization of the results. However, users should be aware of several OProfile limitations: Performance monitoring samples may not be precise - because the processor may execute instructions out of order, a sample may be recorded from a nearby instruction, instead of the instruction that triggered the interrupt. Because OProfile is system-wide and expects processes to start and stop multiple times, samples from multiple runs are allowed to accumulate. This means you may need to clear sample data from runs. It focuses on identifying problems with CPU-limited processes, and therefore does not identify processes that are sleeping while they wait on locks for other events. For further information about using OProfile, refer to the Deployment Guide , available from http://access.redhat.com/site/documentation/Red_Hat_Enterprise_Linux/ , or to the oprofile documentation on your system, located in /usr/share/doc/oprofile- <version> .

Commands:
B.15.2. RHBA-2011:0831 - device-mapper-multipath bug fix update Updated device-mapper-multipath packages that fix two bugs are now available for Red Hat Enterprise Linux 6. The device-mapper-multipath utility provides tools to manage multipath devices by giving the "dm-multipath" kernel module instructions on what to do, as well as by managing the creation and removal of partitions for device-mapper devices. Bug Fixes BZ# 696133 Previously, multipath marked paths as failed if it could not determine whether the path was offline through sysfs. With this update, multipath calls the path_checker function to get the path's state when it cannot be determined. BZ# 702402 Previously, the multipath daemon did not remove restored paths correctly when one dervice path came online after another device path failed. Due to this issue, the multipath daemon could terminate unexpectedly with a segmentation fault on a multipath device when the path_grouping_policy option was set to the group_by_prio value. With this update multipath removes and restores such paths correctly. All users of device-mapper-multipath are advised to upgrade to these updated packages, which fix these bugs.

Commands:
Chapter 1. Overview 1.1. Introduction Cost-Optimized deployments of SAP S/4HANA systems play an important role in S/4HANA migration scenarios, especially in saving costs related to additional nodes. It is also critical if such systems are to be made highly available, in which case, the constraints need to be correctly configured. 1.2. Audience This document is intended for SAP and Red Hat certified or trained administrators and consultants who already have experience setting up highly available solutions using the Red Hat Enterprise Linux (RHEL) HA add-on or other clustering solutions. Access to both SAP Service Marketplace and Red Hat Customer Portal is required to be able to download software and additional documentation. Red Hat Professional Services is highly recommended to set up the cluster and customize the solution to meet the customer's data center requirements, which may be different than the solution presented in this document. 1.3. Concepts This document describes how to set up a Cost-Optimized, two-node cluster solution that conforms to the high availability guidelines established by SAP and Red Hat. It is based on Standalone Enqueue Server 2 (ENSA2), now the default installation in SAP S/4HANA 1809 or newer, on top of RHEL 8 for SAP Solutions or above, and highlights a scale-up SAP HANA instance that supports fully automated failover using SAP HANA System Replication. According to SAP, ENSA2 is the successor to Standalone Enqueue Server 1 (ENSA1). It is a component of the SAP lock concept and manages the lock table. This principle ensures the consistency of data in an ABAP system. During a failover with ENSA1, the ASCS instance is required to "follow" the Enqueue Replication Server (ERS). That is, the HA software had to start the ASCS instance on the host where the ERS instance is currently running. In contrast to ENSA1, the newer ENSA2 model and Enqueue Replicator 2 no longer have these restrictions. For more information on ENSA2, please refer to SAP OSS Note 2630416 - Support for Standalone Enqueue Server 2 . Additionally, the document will also highlight the SAP HANA Scale-Up instance, with fully automated failover using SAP HANA System Replication, where the SAP HANA promotable clone resources will run on each node as per set constraints. This article does NOT cover preparation of the RHEL system for SAP HANA installation, nor the SAP HANA installation procedure. For fast and error-free preparation of the systems for SAP S/4HANA and SAP HANA, we recommend using RHEL System Roles for SAP . The setup described in this documentation shows a configuration of both the above combined, that is, an ENSA 2 model with SAP HANA Scale-up with System Replication managed by a single 2-node pacemaker cluster. This is considered a Cost-Optimized SAP S/4HANA with an Automated SAP HANA Scale-Up System Replication HA Environment. 1.4. Support Policies Please refer to Support Policies for RHEL High Availability Clusters - Management of SAP S/4HANA and Support Policies for RHEL High Availability Clusters - Management of SAP HANA in a Cluster for more details. This solution is supported subject to fulfilling the above policies.

Commands:
3.3. 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: allow_smbd_anon_write Having this Boolean enabled allows smbd to write to a public directory, such as an area reserved for common files that otherwise has no special access restrictions. samba_create_home_dirs Having this Boolean enabled allows Samba to create new home directories independently. This is often done by mechanisms such as PAM. samba_domain_controller When enabled, this Boolean allows Samba to act as a domain controller, as well as giving it permission to execute related commands such as useradd , groupadd and passwd . samba_enable_home_dirs Enabling this Boolean allows Samba to share users' home directories. samba_export_all_ro Export any file or directory, allowing read-only permissions. This allows files and directories that are not labeled with the samba_share_t type to be shared through Samba. When the samba_export_all_ro Boolean is on, but the samba_export_all_rw Boolean is off, write access to Samba shares is denied, even if write access is configured in /etc/samba/smb.conf , as well as Linux permissions allowing write access. samba_export_all_rw Export any file or directory, allowing read and write permissions. This allows files and directories that are not labeled with the samba_share_t type to be exported through Samba. Permissions in /etc/samba/smb.conf and Linux permissions must be configured to allow write access. samba_run_unconfined Having this Boolean enabled allows Samba to run unconfined scripts in the /var/lib/samba/scripts/ directory. samba_share_fusefs This Boolean must be enabled for Samba to share fusefs file systems. samba_share_nfs Disabling this Boolean prevents smbd from having full access to NFS shares via Samba. Enabling this Boolean will allow Samba to share NFS volumes. use_samba_home_dirs Enable this Boolean to use a remote server for Samba home directories. virt_use_samba Allow virtual machine access to CIFS files. 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, run the following command as root:

Commands:
~]# semanage boolean -l | grep service_name
3.7.4. Perf The perf tool provides a number of useful performance counters that let the user assess the impact of other commands on their system: perf stat This command provides overall statistics for common performance events, including instructions executed and clock cycles consumed. You can use the option flags to gather statistics on events other than the default measurement events. As of Red Hat Enterprise Linux 6.4, it is possible to use perf stat to filter monitoring based on one or more specified control groups (cgroups). For further information, read the man page: man perf-stat . perf record This command records performance data into a file which can be later analyzed using perf report . For further details, read the man page: man perf-record . As of Red Hat Enterprise Linux 6.6, the -b and -j options are provided to allow statistical sampling of taken branches. The -b option samples any branches taken, while the -j option can be adjusted to sample branches of different types, such as user level or kernel level branches. perf report This command reads the performance data from a file and analyzes the recorded data. For further details, read the man page: man perf-report . perf list This command lists the events available on a particular machine. These events will vary based on the performance monitoring hardware and the software configuration of the system. For further information, read the man page: man perf-list . perf mem Available as of Red Hat Enterprise Linux 6.6. This command profiles the frequency of each type of memory access operation performed by a specified application or command. This allows a user to see the frequency of load and store operations performed by the profiled application. For further information, read the man page: man perf-mem . perf top This command performs a similar function to the top tool. It generates and displays a performance counter profile in realtime. For further information, read the man page: man perf-top . perf trace This command performs a similar function to the strace tool. It monitors the system calls used by a specified thread or process and all signals received by that application. Additional trace targets are available; refer to the man page for a full list. More information about perf is available in the Red Hat Enterprise Linux Developer Guide , available from http://access.redhat.com/site/documentation/Red_Hat_Enterprise_Linux/ .

Commands:
10.5.28. UserDir UserDir is the subdirectory within each user's home directory where they should place personal HTML files which are served by the Web server. This directive is set to disable by default. The name for the subdirectory is set to public_html in the default configuration. For example, the server might receive the following request: The server would look for the file: In the above example, /home/username/ is the user's home directory (note that the default path to users' home directories may vary). Make sure that the permissions on the users' home directories are set correctly. Users' home directories must be set to 0711. The read (r) and execute (x) bits must be set on the users' public_html directories (0755 also works). Files that are served in a users' public_html directories must be set to at least 0644.

Commands:
http:// example.com /~ username /foo.html
/home/username/public_html/foo.html