mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 25. Apache HTTP Secure Server Configuration 25.1. Introduction This chapter provides basic information on the Apache HTTP Server with the mod_ssl security module enabled to use the OpenSSL library and toolkit. The combination of these three components are referred to in this chapter as the secure Web server or just as the secure server. The mod_ssl module is a security module for the Apache HTTP Server. The mod_ssl module uses the tools provided by the OpenSSL Project to add a very important feature to the Apache HTTP Server - the ability to encrypt communications. In contrast, regular HTTP communications between a browser and a Web server are sent in plain text, which could be intercepted and read by someone along the route between the browser and the server. This chapter is not meant to be complete and exclusive documentation for any of these programs. When possible, this guide points to appropriate places where you can find more in-depth documentation on particular subjects. This chapter shows you how to install these programs. You can also learn the steps necessary to generate a private key and a certificate request, how to generate your own self-signed certificate, and how to install a certificate to use with your secure server. The mod_ssl configuration file is located at /etc/httpd/conf.d/ssl.conf . For this file to be loaded, and hence for mod_ssl to work, you must have the statement Include conf.d/*.conf in the /etc/httpd/conf/httpd.conf file. This statement is included by default in the default Apache HTTP Server configuration file.

Commands:
3.3. Recording Statistical History The ETL service collects data into the statistical tables every minute. Data is stored for every minute of the past 24 hours, at a minimum, but can be stored for as long as 48 hours depending on the last time a deletion job was run. Minute-by-minute data more than two hours old is aggregated into hourly data and stored for two months. Hourly data more than two days old is aggregated into daily data and stored for five years. Hourly data and daily data can be found in the hourly and daily tables. Each statistical datum is kept in its respective aggregation level table: samples, hourly, and daily history. All history tables also contain a history_id column to uniquely identify rows. Tables reference the configuration version of a host in order to enable reports on statistics of an entity in relation to its past configuration.

Commands:
Chapter 4. External storage services Red Hat OpenShift Data Foundation can make services from an external Red Hat Ceph Storage cluster available for consumption through OpenShift Container Platform clusters running on the following platforms: VMware vSphere Bare metal Red Hat OpenStack platform (Technology Preview) IBM Power IBM Z The OpenShift Data Foundation operators create and manage services to satisfy Persistent Volume (PV) and Object Bucket Claims (OBCs) against the external services. External cluster can serve block, file and object storage classes for applications that run on OpenShift Container Platform. The operators do not deploy or manage the external clusters.

Commands:
Chapter 4. Configuration example for load-balancing with mod_proxy_cluster You can configure JBCS to use the mod_proxy_cluster connector for load-balancing in a Red Hat Enterprise Linux system. When you want to configure a load-balancing solution that uses mod_proxy_cluster , you must perform the following tasks: Set up JBCS as a proxy server . Configure a Tomcat worker node . Define iptables firewall rules . 4.1. Setting up JBCS as a proxy server When you configure JBCS to use mod_proxy_cluster , you must set up JBCS as a proxy server by specifying configuration details in the mod_proxy_cluster.conf file. Procedure Go to the JBCS_HOME /httpd/conf.d/ directory. Create a file named mod_proxy_cluster.conf . Enter the following configuration details: Important As shown in the preceding example, the mod_proxy_cluster package requires that you set the MemManagerFile directive in the conf.d file to cache/mod_proxy_cluster . Note The preceding example shows how to set up JBCS as a proxy server that is listening on localhost . 4.2. Configuring a Tomcat worker node When you configure JBCS to use mod_proxy_cluster , you must configure a Tomcat worker node by adding a Listener element to the server.xml file. Prerequisites You have set up JBCS as a proxy server . Procedure Open the JWS_HOME /tomcat <VERSION> /conf/server.xml file. Add the following Listener element: <Listener className="org.jboss.modcluster.container.catalina.standalone.ModClusterListener" advertise="true"/> 4.3. Defining iptables firewall rules example When you configure JBCS to use mod_proxy_cluster , you must define firewall rules by using iptables . Prerequisites You have configured a Tomcat worker node . Procedure Use iptables to define a set of firewall rules. For example: Note The preceding example shows to define firewall rules for a cluster node on the 192.168.1.0/24 subnet.

Commands:
LoadModule proxy_cluster_module modules/mod_proxy_cluster.so LoadModule cluster_slotmem_module modules/mod_cluster_slotmem.so LoadModule manager_module modules/mod_manager.so LoadModule advertise_module modules/mod_advertise.so MemManagerFile cache/mod_proxy_cluster <IfModule manager_module> Listen 6666 <VirtualHost *:6666> <Directory /> Require ip 127.0.0.1 </Directory> ServerAdvertise on EnableMCPMReceive <Location /mod_cluster_manager> SetHandler mod_cluster-manager Require ip 127.0.0.1 </Location> </VirtualHost> </IfModule>
<Listener className="org.jboss.modcluster.container.catalina.standalone.ModClusterListener" advertise="true"/>
/sbin/iptables -I INPUT 5 -p udp -d 224.0.1.0/24 -j ACCEPT -m comment --comment "mod_proxy_cluster traffic" /sbin/iptables -I INPUT 6 -p udp -d 224.0.0.0/4 -j ACCEPT -m comment --comment "JBoss Cluster traffic" /sbin/iptables -I INPUT 9 -p udp -s 192.168.1.0/24 -j ACCEPT -m comment --comment "cluster subnet for inter-node communication" /sbin/iptables -I INPUT 10 -p tcp -s 192.168.1.0/24 -j ACCEPT -m comment --comment "cluster subnet for inter-node communication" /etc/init.d/iptables save
Chapter 7. MTR 1.2.2 7.1. Known issues For a complete list of all known issues, see the list of MTR 1.2.2 known issues in Jira. 7.2. Resolved issues CVE-2023-44487 netty-codec-http2: HTTP/2: Multiple HTTP/2 enabled web servers are vulnerable to a DDoS attack (Rapid Reset Attack) A flaw was found in handling multiplexed streams in the HTTP/2 protocol, which was utilized by Migration Toolkit for Runtimes (MTR). A client could repeatedly make a request for a new multiplex stream and immediately send an RST_STREAM frame to cancel it. This creates additional workload for the server in terms of setting up and dismantling streams, while avoiding any server-side limitations on the maximum number of active streams per connection, resulting in a denial of service due to server resource consumption. (WINDUP-4072) For more details, see (CVE-2023-44487) CVE-2023-37460 plexus-archiver: Arbitrary File Creation in AbstractUnArchiver A flaw was found in the Plexus Archiver, which was utilized by MTR. While using AbstractUnArchiver for extracting, an archive could lead to arbitrary file creation and possible remote code execution (RCE). This flaw will bypass directory destination verification if an archive with an entry in the destination directory as a symbolic link whose target does not exist. The plexus-archiver is a test scoped artifact so not included in any of the MTR distributions. (WINDUP-4053) For more details, see (CVE-2023-37460) EAP 7.3 and EAP 7.4 rules with target EAP 7.0 and above This MTR release makes a correction to some rules to support migrating to EAP 7.3 and above, to ensure the rules are ignored if the target is EAP 7.2 or below. (WINDUPRULE-1038)

Commands:
22.2. Defining the Type of Rollover Disaster recovery, as the introduction says, is the process for transitioning from one system to another system with as little interruption of service as possible. That's called a rollover , and there are three different ways of doing a rollover: A hot rollover means that the infrastructure is completely mirrored at another site and that the backup site is always up and current with the primary site. This requires only a few adjustments to switch operations from the primary to the backup. A warm rollover means that all of the elements for the backup site are in place (adequate network connections, all required applications and hardware) but the system is not actively running or necessarily configured. This can require some extra time to configure the machines and get the system running. A cold rollover means that a site is available but there are few resources immediately available to set it up. The obvious difference in the types of rollover is the time and expense necessary to set up the backup site. Hot and warm sites have higher initial expenditures to set up and run. A mix of rollover types can be used, depending on the specific disaster scenario being planned. For example, a rollover plan for the loss of a single server could use a hot rollover easily and relatively cheaply by creating and keeping a virtual machine copy of the Directory Server instance which can be brought online within minutes. It would not even require keeping the virtual machine in a separate facility or network. On the other hand, a cold rollover could be planned for the loss of an entire data center or office. Match the rollover process to the severity of the disaster scenario, your budget and available resources, and the likelihood of encountering problems.

Commands:
Chapter 1. Introduction to AMQ Broker on OpenShift Container Platform Red Hat AMQ Broker 7.10 is available as a containerized image for use with OpenShift Container Platform (OCP) 4.12, 4.13, 4.14 or 4.15. AMQ Broker is based on Apache ActiveMQ Artemis. It provides a message broker that is JMS-compliant. After you have set up the initial broker pod, you can quickly deploy duplicates by using OpenShift Container Platform features. 1.1. Version compatibility and support For details about OpenShift Container Platform image version compatibility, see: OpenShift Container Platform 4.x Tested Integrations Note All deployments of AMQ Broker on OpenShift Container Platform now use RHEL 8 based images. 1.2. Unsupported features Master-slave-based high availability High availability (HA) achieved by configuring master and slave pairs is not supported. Instead, AMQ Broker uses the HA capabilities provided in OpenShift Container Platform. External clients cannot use the topology information provided by AMQ Broker When an AMQ Core Protocol JMS Client or an AMQ JMS Client connects to a broker in an OpenShift Container Platform cluster, the broker can send the client the IP address and port information for each of the other brokers in the cluster, which serves as a failover list for clients if the connection to the current broker is lost. The IP address provided for each broker is an internal IP address, which is not accessible to clients that are external to the OpenShift Container Platform cluster. To prevent external clients from trying to connect to a broker using an internal IP address, set the following configuration in the URI used by the client to initially connect to a broker. Client Configuration AMQ Core Protocol JMS Client useTopologyForLoadBalancing=false AMQ JMS Client failover.amqpOpenServerListAction=IGNORE 1.3. Document conventions This document uses the following conventions for the sudo command, file paths, and replaceable values. The sudo command In this document, sudo is used for any command that requires root privileges. You should always exercise caution when using sudo , as any changes can affect the entire system. For more information about using sudo , see The sudo Command . About the use of file paths in this document In this document, all file paths are valid for Linux, UNIX, and similar operating systems (for example, /home/... ). If you are using Microsoft Windows, you should use the equivalent Microsoft Windows paths (for example, C:\Users\... ). Replaceable values This document sometimes uses replaceable values that you must replace with values specific to your environment. Replaceable values are lowercase, enclosed by angle brackets ( < > ), and are styled using italics and monospace font. Multiple words are separated by underscores ( _ ) . For example, in the following command, replace <project_name> with your own project name. USD oc new-project <project_name>

Commands:
oc new-project <project_name>
Support Red Hat Advanced Cluster Security for Kubernetes 4.7 Getting support for Red Hat Advanced Cluster Security for Kubernetes Red Hat OpenShift Documentation Team

Commands:
export ROX_PASSWORD= <rox_password> && export ROX_CENTRAL_ADDRESS= <address>:<port_number> 1
roxctl -e "USDROX_CENTRAL_ADDRESS" -p "USDROX_PASSWORD" central debug download-diagnostics
export ROX_API_TOKEN= <api_token>
roxctl -e "USDROX_CENTRAL_ADDRESS" central debug download-diagnostics
1.7. Post-installation Script You have the option of adding commands to run on the system once the installation is complete. This section must be at the end of the kickstart file and must start with the %post command. This section is useful for functions such as installing additional software and configuring an additional nameserver. Note If you configured the network with static IP information, including a nameserver, you can access the network and resolve IP addresses in the %post section. If you configured the network for DHCP, the /etc/resolv.conf file has not been completed when the installation executes the %post section. You can access the network, but you can not resolve IP addresses. Thus, if you are using DHCP, you must specify IP addresses in the %post section. Note The post-install script is run in a chroot environment; therefore, performing tasks such as copying scripts or RPMs from the installation media do not work. --nochroot Allows you to specify commands that you would like to run outside of the chroot environment. The following example copies the file /etc/resolv.conf to the file system that was just installed. --interpreter /usr/bin/python Allows you to specify a different scripting language, such as Python. Replace /usr/bin/python with the scripting language of your choice. 1.7.1. Examples Turn services on and off: Run a script named runme from an NFS share: Note NFS file locking is not supported while in kickstart mode, therefore -o nolock is required when mounting an NFS mount. Add a user to the system:

Commands:
%post --nochroot cp /etc/resolv.conf /mnt/sysimage/etc/resolv.conf
/sbin/chkconfig --level 345 telnet off /sbin/chkconfig --level 345 finger off /sbin/chkconfig --level 345 lpd off /sbin/chkconfig --level 345 httpd on
mkdir /mnt/temp mount -o nolock 10.10.0.2:/usr/new-machines /mnt/temp open -s -w -- /mnt/temp/runme umount /mnt/temp
/usr/sbin/useradd bob /usr/bin/chfn -f "Bob Smith" bob /usr/sbin/usermod -p 'kjdfUSD04930FTH/ ' bob
macro::json_output_array_string_value Name macro::json_output_array_string_value - Output a string value for metric in an array. Synopsis Arguments array_name The name of the array. array_index The array index (as a string) indicating where to store the string value. metric_name The name of the string metric. value The string value to output. Description The json_output_array_string_value macro is designed to be called from the 'json_data' probe in the user's script to output a metric's string value that is in an array. This metric should have been added with json_add_array_string_metric .

Commands:
@json_output_array_string_value(array_name,array_index,metric_name,value)
4.4.5. Disabling/Enabling Quota Accounting By default, quota accounting is enabled; therefore, GFS keeps track of disk usage for every user and group even when no quota limits have been set. Quota accounting incurs unnecessary overhead if quotas are not used. You can disable quota accounting completely by setting the quota_account tunable parameter to 0. This must be done on each node and after each mount. (The 0 setting is not persistent across unmounts.) Quota accounting can be enabled by setting the quota_account tunable parameter to 1. Usage MountPoint Specifies the GFS file system to which the actions apply. quota_account {0|1} 0 = disabled 1 = enabled Comments To enable quota accounting on a file system, the quota_account parameter must be set back to 1. Afterward, the GFS quota file must be initialized to account for all current disk usage for users and groups on the file system. The quota file is initialized by running: gfs_quota init -f MountPoint . Note Initializing the quota file requires scanning the entire file system and may take a long time. Examples This example disables quota accounting on file system /gfs on a single node. This example enables quota accounting on file system /gfs on a single node and initializes the quota file.

Commands:
fs_tool settune MountPoint quota_account {0|1}
gfs_tool settune /gfs quota_account 0
gfs_tool settune /gfs quota_account 1 gfs_quota init -f /gfs
8.93. libpcap 8.93.1. RHBA-2013:1727 - libpcap bug fix and enhancement update Updated libpcap packages that fix several bugs and add various enhancements are now available for Red Hat Enterprise Linux 6. The Packet Capture library (pcap) provides a high level interface to packet capture systems. All packets on the network, even those destined for other hosts, are accessible through this mechanism. It also supports saving captured packets to a 'savefile', and reading packets from a 'savefile'. libpcap provides implementation-independent access to the underlying packet capture facility provided by the operating system. Note The libpcap packages have been upgraded to upstream version 1.4.1, which provides a number of bug fixes and enhancements over the version. (BZ# 916749 ) Bug Fixes BZ# 723108 Previously, the libpcap library generated wrong filtering code for Berkeley Packet Filter (BPF) infrastructure. As a consequence, the in-kernel packet filter was discarding some packets which should have been received by userspace process. Moreover, the tcpdump utility produced incorrect output when a fragmentation of IPv6 packet occurred because of the MTUlink. To fix this bug, the code which deals with BPF filter generation has been fixed to check for fragmentation headers in IPv6 PDUs before checking for the final protocol. As a result, the kernel filter no longer discards IPv6 fragments when source-site fragmentation occurs during IPv6 transmission and tcpdump receives all packets. BZ# 731789 Prior to this update, libpcap was unable to open a capture device with small values of SnapLen, which caused libpcap to return an error code and tcpdump to exit prematurely. Calculation of frames for memory mapping packet capture mechanism has been adjusted not to truncate packets to smaller values than actual SnapLen, thus fixing the bug. As a result, libpcap no longer returns errors when trying to open a capture device with small values of SnapLen, and applications using libpcap are able to process packets. Users of libpcap are advised to upgrade to these updated packages, which fix these bugs and add these enhancements.

Commands:
3.22. RHEA-2011:1757 - new package: virt-who A new virt-who package is now available for Red Hat Enterprise Linux 6. The virt-who package provides an agent that collects information about virtual guests present in the system and reports them to the Red Hat Subscription Manager tool. This enhancement update adds the virt-who package to Red Hat Enterprise Linux 6. (BZ# 725832 ) All users are advised to install this new package.

Commands:
Chapter 7. Finalizing your GitHub application After installing RHTAP, you must replace the placeholder values you previously entered in your GitHub application with values specific to your cluster. This allows anyone who installs the GitHub application to authenticate to Red Hat Developer Hub, and use Red Hat Trusted Application Pipeline. Prerequisites: ClusterAdmin access to an OpenShift cluster via the web console Procedure: By opening the link generated at the end of the last procedure, you should be in the OpenShift console, using the Administrator view. If not, navigate to view in the OpenShift Console for your cluster. Use the left navigation bar to go to Pipelines > Pipelines . In the Project field, below the banner of the page, select rhtap . Select the PipelineRun tab. Select the PipelineRun with a name that starts with rhtap-pe-info- . Navigate to the Logs tab. In a separate browser tab, return to the GitHub Apps page ( Settings > Developer settings > GitHub Apps ). to your new custom application, click Edit . Replace the placeholder values for the following fields with the new values found in the logs of the PipelineRun you executed in the OpenShift console: Homepage URL Callback URL Webhook URL Scroll to the bottom of the page and click Save . In a separate tab, navigate to the address you entered as the new homepage URL for your GitHub application. Choose GitHub as the sign-in method by clicking the SIGN IN button. In the popup window, authorize your custom GitHub application as requested. You should be immediately redirected to Red Hat Developer Hub (RHDH). Any developer who downloads your GitHub application can also authenticate by using that application, and by running the second PipelineRun generated in the third procedure. In RHDH, developers can then leverage the automated, customizable, and secure CI/CD functionality of Red Hat Trusted Application Pipeline. Revised on 2024-07-15 21:03:35 UTC

Commands:
3.6. Caching Limitations XML, BLOB, CLOB, and OBJECT type cannot be used as part of the cache key for prepared statement of procedure cache keys. The exact SQL string, including the cache hint if present, must match the cached entry for the results to be reused. This allows cache usage to skip parsing and resolving for faster responses. Result set caching is transactional by default using the NON_XA transaction mode. To use full XA support, change the configuration to use NON_DURABLE_XA. Clearing the results cache clears all cache entries for all VDBs.

Commands:
11.3.3.3. Server Options Server options must be placed on their own line in .fetchmailrc after a poll or skip action. auth <auth-type> - Replace <auth-type> with the type of authentication to be used. By default, password authentication is used, but some protocols support other types of authentication, including kerberos_v5 , kerberos_v4 , and ssh . If the any authentication type is used, Fetchmail first tries methods that do not require a password, then methods that mask the password, and finally attempts to send the password unencrypted to authenticate to the server. interval <number> - Polls the specified server every <number> of times that it checks for email on all configured servers. This option is generally used for email servers where the user rarely receives messages. port <port-number> - Replace <port-number> with the port number. This value overrides the default port number for the specified protocol. proto <protocol> - Replace <protocol> with the protocol, such as pop3 or imap , to use when checking for messages on the server. timeout <seconds> - Replace <seconds> with the number of seconds of server inactivity after which Fetchmail gives up on a connection attempt. If this value is not set, a default of 300 seconds is assumed.

Commands: