mtpti5iD/redhat-docs_dataset huggingface dataset:
2.8.9.5. IPTables and IP Sets The ipset utility is used to administer IP sets in the Linux kernel. An IP set is a framework for storing IP addresses, port numbers, IP and MAC address pairs, or IP address and port number pairs. The sets are indexed in such a way that very fast matching can be made against a set even when the sets are very large. IP sets enable simpler and more manageable configurations as well as providing performance advantages when using iptables . The iptables matches and targets referring to sets create references which protect the given sets in the kernel. A set cannot be destroyed while there is a single reference pointing to it. The use of ipset enables iptables commands, such as those below, to be replaced by a set: The set is created as follows: The set is then referenced in an iptables command as follows: If the set is used more than once a saving in configuration time is made. If the set contains many entries a saving in processing time is made. 2.8.9.5.1. Installing ipset To install the ipset utility, issue the following command as root : To see the usage message:

Commands:
~]# iptables -A INPUT -s 10.0.0.0/8 -j DROP ~]# iptables -A INPUT -s 172.16.0.0/12 -j DROP ~]# iptables -A INPUT -s 192.168.0.0/16 -j DROP
~]# ipset create my-block-set hash:net ~]# ipset add my-block-set 10.0.0.0/8 ~]# ipset add my-block-set 172.16.0.0/12 ~]# ipset add my-block-set 192.168.0.0/16
~]# iptables -A INPUT -m set --set my-block-set src -j DROP
~]# yum install ipset
~]USD ipset -h ipset v6.11 Usage: ipset [options] COMMAND
Chapter 96. KafkaConnectStatus schema reference Used in: KafkaConnect Property Property type Description conditions Condition array List of status conditions. observedGeneration integer The generation of the CRD that was last reconciled by the operator. url string The URL of the REST API endpoint for managing and monitoring Kafka Connect connectors. connectorPlugins ConnectorPlugin array The list of connector plugins available in this Kafka Connect deployment. labelSelector string Label selector for pods providing this resource. replicas integer The current number of pods being used to provide this resource.

Commands:
Preface Providing feedback on Red Hat documentation Red Hat appreciates your feedback on product documentation. To propose improvements, open a Jira issue and describe your suggested changes. Provide as much detail as possible to help the documentation team to address your request quickly. Prerequisite You have a Red Hat Customer Portal account. This account enables you to log in to the Red Hat Jira Software instance. If you do not have an account, you will be prompted to create one. Procedure Click the following link: Create issue . In the Summary text box, enter a brief description of the issue. In the Description text box, provide the following information: The URL of the page where you found the issue. A detailed description of the issue. You can leave the information in any other fields at their default values. In the Reporter field, enter your Jira username. Click Create to submit the Jira issue to the documentation team. Thank you for taking the time to provide feedback.

Commands:
Chapter 8. Cleaning the installer Using the JBoss EAP Management CLI, you have the capability to discard a candidate server that has been prepared using update or revert commands. Procedure Launch the Management CLI: EAP_HOME/bin/jboss-cli.sh Clean the JBoss EAP server: Clean the installer in a stand-alone server: [standalone@localhost:9990 /] installer clean Clean the installer in a managed domain: [domain@localhost:9990 /] installer clean --host=target-host Additional resources Reverting your JBoss EAP server updates in a stand-alone server or a managed domain . Updating JBoss EAP running as a stand-alone server or a managed domain using the Management CLI .

Commands:
EAP_HOME/bin/jboss-cli.sh
[standalone@localhost:9990 /] installer clean
[domain@localhost:9990 /] installer clean --host=target-host
6.6. Booleans for Users Executing Applications Not allowing Linux users to execute applications (which inherit users' permissions) in their home directories and /tmp/ , which they have write access to, helps prevent flawed or malicious applications from modifying files that users own. In Red Hat Enterprise Linux 6, by default, Linux users in the guest_t and xguest_t domains cannot execute applications in their home directories or /tmp/ ; however, by default, Linux users in the user_t and staff_t domains can. Booleans are available to change this behavior, and are configured with the setsebool command. The setsebool command must be run as the Linux root user. The setsebool -P command makes persistent changes. Do not use the -P option if you do not want changes to persist across reboots: guest_t To allow Linux users in the guest_t domain to execute applications in their home directories and /tmp/ : xguest_t To allow Linux users in the xguest_t domain to execute applications in their home directories and /tmp/ : user_t To prevent Linux users in the user_t domain from executing applications in their home directories and /tmp/ : staff_t To prevent Linux users in the staff_t domain from executing applications in their home directories and /tmp/ :

Commands:
~]# setsebool -P allow_guest_exec_content on
~]# setsebool -P allow_xguest_exec_content on
~]# setsebool -P allow_user_exec_content off
~]# setsebool -P allow_staff_exec_content off
15.2. Booting a Guest Using PXE This section demonstrates how to boot a guest virtual machine with PXE. 15.2.1. Using Bridged Networking Procedure 15.2. Booting a guest using PXE and bridged networking Ensure bridging is enabled such that the PXE boot server is available on the network. Boot a guest virtual machine with PXE booting enabled. You can use the virt-install command to create a new virtual machine with PXE booting enabled, as shown in the following example command: Alternatively, ensure that the guest network is configured to use your bridged network, and that the XML guest configuration file has a <boot dev='network'/> element inside the <os> element, as shown in the following example:

Commands:
virt-install --pxe --network bridge=breth0 --prompt
<os> <type arch='x86_64' machine='rhel6.2.0'>hvm</type> <boot dev='network'/> <boot dev='hd'/> </os> <interface type='bridge'> <mac address='52:54:00:5a:ad:cb'/> <source bridge='breth0'/> <target dev='vnet0'/> <alias name='net0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface>
Chapter 5. Red Hat Process Automation Manager projects Red Hat Process Automation Manager projects contain the business assets that you develop in Red Hat Process Automation Manager and are assigned to a space (for example, MyProject within MySpace ). Projects also contain configuration files such as a Maven project object model file ( pom.xml ), which contains build, environment, and other information about the project, and a KIE module descriptor file ( kmodule.xml ), which contains the KIE Base and KIE Session configurations for the assets in the project.

Commands:
2.2. Enabling IP Ports Before deploying a Red Hat Cluster, you must enable certain IP ports on the cluster nodes and on computers that run luci (the Conga user interface server). The following sections specify the IP ports to be enabled and provide examples of iptables rules for enabling the ports: Section 2.2.1, "Enabling IP Ports on Cluster Nodes" Section 2.2.2, "Enabling IP Ports on Computers That Run luci " Section 2.2.3, "Examples of iptables Rules" 2.2.1. Enabling IP Ports on Cluster Nodes To allow Red Hat Cluster nodes to communicate with each other, you must enable the IP ports assigned to certain Red Hat Cluster components. Table 2.1, "Enabled IP Ports on Red Hat Cluster Nodes" lists the IP port numbers, their respective protocols, the components to which the port numbers are assigned, and references to iptables rule examples. At each cluster node, enable IP ports according to Table 2.1, "Enabled IP Ports on Red Hat Cluster Nodes" . (All examples are in Section 2.2.3, "Examples of iptables Rules" .) Table 2.1. Enabled IP Ports on Red Hat Cluster Nodes IP Port Number Protocol Component Reference to Example of iptables Rules 6809 UDP cman (Cluster Manager), for use in clusters with Distributed Lock Manager (DLM) selected Example 2.1, "Port 6809: cman" 11111 TCP ricci (part of Conga remote agent) Example 2.3, "Port 11111: ricci (Cluster Node and Computer Running luci )" 14567 TCP gnbd (Global Network Block Device) Example 2.4, "Port 14567: gnbd" 16851 TCP modclusterd (part of Conga remote agent) Example 2.5, "Port 16851: modclusterd" 21064 TCP dlm (Distributed Lock Manager), for use in clusters with Distributed Lock Manager (DLM) selected Example 2.6, "Port 21064: dlm" 40040, 40042, 41040 TCP lock_gulmd (GULM daemon), for use in clusters with Grand Unified Lock Manager (GULM) selected Example 2.7, "Ports 40040, 40042, 41040: lock_gulmd" 41966, 41967, 41968, 41969 TCP rgmanager (high-availability service management) Example 2.8, "Ports 41966, 41967, 41968, 41969: rgmanager" 50006, 50008, 50009 TCP ccsd (Cluster Configuration System daemon) Example 2.9, "Ports 50006, 50008, 50009: ccsd (TCP)" 50007 UDP ccsd (Cluster Configuration System daemon) Example 2.10, "Port 50007: ccsd (UDP)"

Commands:
Release Notes Red Hat build of Keycloak 26.0 Red Hat Customer Content Services

Commands:
http_server_active_requests 1.0 http_server_requests_seconds_count{method="GET",outcome="SUCCESS",status="200",uri="/realms/{realm}/protocol/{protocol}/auth"} 1.0 http_server_requests_seconds_sum{method="GET",outcome="SUCCESS",status="200",uri="/realms/{realm}/protocol/{protocol}/auth"} 0.048717142
<!-- Before --> <script src="/path/to/keycloak.js"></script> <script> const keycloak = new Keycloak(); </script> <!-- After --> <script type="module"> import Keycloak from '/path/to/keycloak.js'; const keycloak = new Keycloak(); </script>
<script type="importmap"> { "imports": { "keycloak-js": "/path/to/keycloak.js" } } </script> <script type="module"> // The library can now be imported without specifying the full path, providing a similar experience as with a bundler. import Keycloak from 'keycloak-js'; const keycloak = new Keycloak(); </script>
{ "compilerOptions": { "moduleResolution": "Bundler" } }
Chapter 21. Restricting the session to a single application You can start the GNOME session in single-application mode, also known as kiosk mode. In this session, GNOME displays only a full-screen window of the application that you have selected. 21.1. Single-application mode Single-application mode is a modified GNOME session that reconfigures the Mutter window manager into an interactive kiosk. This session locks down certain behavior to make the standard desktop more restrictive. The user can interact only with a single application selected by the administrator. You can set up single-application mode for several use cases, such as: In the communication, entertainment, or education fields As a self-serve machine As an event manager As a registration point The gnome-session-kiosk-session package provides the single-application mode configuration and sessions in RHEL 8. 21.2. Enabling single-application mode This procedure installs and enables single-application mode, which restricts the GNOME session to a single application. Procedure Install the gnome-session-kiosk-session package: As the user that will open the single-application session, create the /home/ user /.local/bin/redhat-kiosk file: Edit the /home/ user /.local/bin/redhat-kiosk file and enter the executable name of the application that you want to launch in single-application mode. For example, to launch the Firefox browser in single-application mode, enter the following content: The while true loop ensures that the application restarts if it terminates for any reason. Make the file executable: If you created the file or its containing directories as a different user than the single-application user, such as root , ensure that the file has the correct permissions: At the GNOME login screen, select the Kiosk session from the gear button menu and log in as the single-application user.

Commands:
yum install gnome-session-kiosk-session
[ user ]USD mkdir -p ~/.local/bin [ user ]USD touch ~/.local/bin/redhat-kiosk
#!/bin/sh while true; do firefox --kiosk https://example.org done
[ user ]USD chmod +x ~/.local/bin/redhat-kiosk
chown -R user : group ~ user /.local
Getting started OpenShift Dedicated 4 Getting started with OpenShift Dedicated Red Hat OpenShift Documentation Team

Commands:
https://oauth-openshift.apps.openshift-cluster.example.com
https://oauth-openshift.apps.<cluster_name>.<cluster_domain>/oauth2callback/<idp_provider_name>
https://nodejs-<project>.<cluster_name>.<hash>.<region>.openshiftapps.com/
Welcome to your Node.js application on OpenShift
5.3. Moving root File Systems from a Single Path Device to a Multipath Device If you have installed your system on a single-path device and later add another path to the root file system, you will need to move your root file system to a multipathed device. This section documents the procedure for moving from a single-path to a multipathed device. After ensuring that you have installed the device-mapper-multipath package, perform the following procedure: Execute the following command to create the /etc/multipath.conf configuration file, load the multipath module, and set chkconfig for the multipathd to on : For further information on using the mpathconf command to set up multipathing, see Section 3.1, "Setting Up DM Multipath" . If the find_multipaths configuration parameter is not set to yes , edit the blacklist and blacklist_exceptions sections of the /etc/multipath.conf file, as described in Section 4.2, "Configuration File Blacklist" . In order for multipath to build a multipath device on top of the root device as soon as it is discovered, enter the following command. This command also ensures that find_multipaths will allow the device, even if it only has one path. For example, if the root device is /dev/sdb , enter the following command. To confirm that your configuration file is set up correctly, you can enter the multipath command and search the output for a line of the following format. This indicates that the command failed to create the multipath device. For example, if the WWID if the device is 3600d02300069c9ce09d41c4ac9c53200, you would see a line in the output such as the following: To rebuild the initramfs file system with multipath , execute the dracut command with the following options: Shut the machine down. Configure the FC switch so that other paths are visible to the machine. Boot the machine. Check whether the root file system ('/') is on the multipathed device.

Commands:
mpathconf --enable
multipath -a root_devname
multipath -a /dev/sdb wwid '3600d02300069c9ce09d41c4ac9c53200' added
date wwid : ignoring map
multipath Oct 21 09:37:19 | 3600d02300069c9ce09d41c4ac9c53200: ignoring map
dracut --force -H --add multipath
Chapter 2. Installation This chapter guides you through the steps to install AMQ Ruby in your environment. 2.1. Prerequisites You must have a subscription to access AMQ release files and repositories. To install packages on Red Hat Enterprise Linux, you must register your system . To use AMQ Ruby, you must install Ruby in your environment. 2.2. Installing on Red Hat Enterprise Linux Procedure Use the subscription-manager command to subscribe to the required package repositories. Replace <version> with 2 for the main release stream or 2.9 for the long term support release stream. If necessary, replace <variant> with the value for your variant of Red Hat Enterprise Linux (for example, server or workstation ). Red Hat Enterprise Linux 7 USD sudo subscription-manager repos --enable=amq-clients- <version> -for-rhel-7- <variant> -rpms Red Hat Enterprise Linux 8 USD sudo subscription-manager repos --enable=amq-clients- <version> -for-rhel-8-x86_64-rpms Use the yum command to install the rubygem-qpid_proton and rubygem-qpid_proton-doc packages. USD sudo yum install rubygem-qpid_proton rubygem-qpid_proton-doc For more information about using packages, see Appendix B, Using Red Hat Enterprise Linux packages .

Commands:
sudo subscription-manager repos --enable=amq-clients- <version> -for-rhel-7- <variant> -rpms
sudo subscription-manager repos --enable=amq-clients- <version> -for-rhel-8-x86_64-rpms
sudo yum install rubygem-qpid_proton rubygem-qpid_proton-doc
Chapter 143. KafkaMirrorMaker2Status schema reference Used in: KafkaMirrorMaker2 Property Property type Description conditions Condition array List of status conditions. observedGeneration integer The generation of the CRD that was last reconciled by the operator. url string The URL of the REST API endpoint for managing and monitoring Kafka Connect connectors. autoRestartStatuses AutoRestartStatus array List of MirrorMaker 2 connector auto restart statuses. connectorPlugins ConnectorPlugin array The list of connector plugins available in this Kafka Connect deployment. connectors map array List of MirrorMaker 2 connector statuses, as reported by the Kafka Connect REST API. labelSelector string Label selector for pods providing this resource. replicas integer The current number of pods being used to provide this resource.

Commands:
Chapter 1. Introduction to OpenShift Data Foundation Red Hat OpenShift Data Foundation is a highly integrated collection of cloud storage and data services for Red Hat OpenShift Container Platform. It is available as part of the Red Hat OpenShift Container Platform Service Catalog, packaged as an operator to facilitate simple deployment and management. Red Hat OpenShift Data Foundation services are primarily made available to applications by way of storage classes that represent the following components: Block storage devices, catering primarily to database workloads. Prime examples include Red Hat OpenShift Container Platform logging and monitoring, and PostgreSQL. Shared and distributed file system, catering primarily to software development, messaging, and data aggregation workloads. Examples include Jenkins build sources and artifacts, Wordpress uploaded content, Red Hat OpenShift Container Platform registry, and messaging using JBoss AMQ. Multicloud object storage, featuring a lightweight S3 API endpoint that can abstract the storage and retrieval of data from multiple cloud object stores. On premises object storage, featuring a robust S3 API endpoint that scales to tens of petabytes and billions of objects, primarily targeting data intensive applications. Examples include the storage and access of row, columnar, and semi-structured data with applications like Spark, Presto, Red Hat AMQ Streams (Kafka), and even machine learning frameworks like TensorFlow and Pytorch. Red Hat OpenShift Data Foundation version 4.x integrates a collection of software projects, including: Ceph, providing block storage, a shared and distributed file system, and on-premises object storage Ceph CSI, to manage provisioning and lifecycle of persistent volumes and claims NooBaa, providing a Multicloud Object Gateway OpenShift Data Foundation, Rook-Ceph, and NooBaa operators to initialize and manage OpenShift Data Foundation services.

Commands:
3.5.2. Modifying or Deleting a Fence Device To modify or delete a fence device, follow these steps: At the detailed menu for the cluster (below the clusters menu), click Shared Fence Devices . Clicking Shared Fence Devices causes the display of the fence devices for a cluster and causes the display of menu items for fence device configuration: Add a Fence Device and Configure a Fence Device . Click Configure a Fence Device . Clicking Configure a Fence Device causes the display of a list of fence devices under Configure a Fence Device . Click a fence device in the list. Clicking a fence device in the list causes the display of a Fence Device Form page for the fence device selected from the list. Either modify or delete the fence device as follows: To modify the fence device, enter changes to the parameters displayed. Refer to Appendix B, Fence Device Parameters for more information about fence device parameters. Click Update this fence device and wait for the configuration to be updated. To delete the fence device, click Delete this fence device and wait for the configuration to be updated. Note You can create shared fence devices on the node configuration page, also. However, you can only modify or delete a shared fence device via Shared Fence Devices at the detailed menu for the cluster (below the clusters menu).

Commands:
21.2. Types The main permission control method used in SELinux targeted policy to provide advanced process isolation is Type Enforcement. All files and processes are labeled with a type: types define a SELinux domain for processes and a SELinux type for files. SELinux policy rules define how types access each other, whether it be a domain accessing a type, or a domain accessing another domain. Access is only allowed if a specific SELinux policy rule exists that allows it. The following types are used with postgresql . Different types allow you to configure flexible access. Note that in the list below are used several regular expression to match the whole possible locations: postgresql_db_t This type is used for several locations. The locations labeled with this type are used for data files for PostgreSQL: /usr/lib/pgsql/test/regres /usr/share/jonas/pgsql /var/lib/pgsql/data /var/lib/postgres(ql)? postgresql_etc_t This type is used for configuration files in the /etc/postgresql/ directory. postgresql_exec_t This type is used for several locations. The locations labeled with this type are used for binaries for PostgreSQL: /usr/bin/initdb(.sepgsql)? /usr/bin/(se)?postgres /usr/lib(64)?/postgresql/bin/.* /usr/lib(64)?/pgsql/test/regress/pg_regress systemd_unit_file_t This type is used for the executable PostgreSQL-related files located in the /usr/lib/systemd/system/ directory. postgresql_log_t This type is used for several locations. The locations labeled with this type are used for log files: /var/lib/pgsql/logfile /var/lib/pgsql/pgstartup.log /var/lib/sepgsql/pgstartup.log /var/log/postgresql /var/log/postgres.log.* /var/log/rhdb/rhdb /var/log/sepostgresql.log.* postgresql_var_run_t This type is used for run-time files for PostgreSQL, such as the process id (PID) in the /var/run/postgresql/ directory.

Commands:
16.5. DHCP for IPv6 (DHCPv6) The ISC DHCP includes support for IPv6 (DHCPv6) since the 4.x release with a DHCPv6 server, client and relay agent functionality. The server, client and relay agents support both IPv4 and IPv6. However, the client and the server can only manage one protocol at a time - for dual support they must be started separately for IPv4 and IPv6. 16.5.1. Configuring a DHCPv6 Server The DHCPv6 server configuration file is installed together with the dhcp package and it can be found at /etc/dhcp/dhcpd6.conf . The sample server configuration file can be found at /usr/share/doc/dhcp-<version>/dhcpd6.conf.sample , in Red Hat Enterprise Linux 6 at /usr/share/doc/dhcp-4.1.1/dhcpd6.conf.sample . A simple DHCPv6 server configuration file can look like this: For more examples, see the dhcpd.conf(5) man page. To start the DHCPv6 service, enter the command service dhcpd6 start as root. To stop the DHCPv6 server, use the command service dhcpdv6 stop . To pass command-line options to dhcpd daemon when the DHCPv6 service starts, use the /etc/sysconfig/dhcpd6 file. This file uses the same structure like the /etc/sysconfig/dhcpd : The value added to the DHCPDARGS option is passed to the DHCPv6 service, which passes it to the dhcpd daemon. For more information, see the STANDARD DHCPV6 OPTIONS section in the dhcpd-options(5) man page. For additional examples, see the Dynamic IPv6 configuration on the Fedora Project wiki.

Commands:
subnet6 2001:db8:0:1::/64 { range6 2001:db8:0:1::129 2001:db8:0:1::254; option dhcp6.name-servers fec0:0:0:1::1; option dhcp6.domain-search "domain.example"; }
cat /etc/sysconfig/dhcpd6 Command line options here DHCPDARGS=