mtpti5iD/redhat-docs_dataset huggingface dataset:
1.5. Shutting Down To shut down Red Hat Enterprise Linux, the root user may issue the /sbin/shutdown command. The shutdown man page has a complete list of options, but the two most common uses are: After shutting everything down, the -h option halts the machine, and the -r option reboots. PAM console users can use the reboot and halt commands to shut down the system while in runlevels 1 through 5. For more information about PAM console users, refer to Section 16.7, "PAM and Device Ownership" . If the computer does not power itself down, be careful not to turn off the computer until a message appears indicating that the system is halted. Failure to wait for this message can mean that not all the hard drive partitions are unmounted, which can lead to file system corruption.

Commands:
/sbin/shutdown -h now /sbin/shutdown -r now
Chapter 22. Performance tuning considerations with KIE Server The following key concepts or suggested practices can help you optimize KIE Server performance. These concepts are summarized in this section as a convenience and are explained in more detail in the cross-referenced documentation, where applicable. This section will expand or change as needed with new releases of Red Hat Process Automation Manager. Ensure that development mode is enabled during development You can set KIE Server or specific projects in Business Central to use production mode or development mode. By default, KIE Server and all new projects in Business Central are in development mode. This mode provides features that facilitate your development experience, such as flexible project deployment policies, and features that optimize KIE Server performance during development, such as disabled duplicate GAV detection. Use development mode until your Red Hat Process Automation Manager environment is established and completely ready for production mode. For more information about configuring the environment mode or duplicate GAV detection, see the following resources: Chapter 8, Configuring the environment mode in KIE Server and Business Central Packaging and deploying an Red Hat Process Automation Manager project Adapt KIE Server capabilities and extensions to your specific needs The capabilities in KIE Server are determined by plug-in extensions that you can enable, disable, or further extend to meet your business needs. By default, KIE Server extensions are exposed through REST or JMS data transports and use predefined client APIs. You can extend existing KIE Server capabilities with additional REST endpoints, extend supported transport methods beyond REST or JMS, or extend functionality in the KIE Server client. This flexibility in KIE Server functionality enables you to adapt your KIE Server instances to your business needs, instead of adapting your business needs to the default KIE Server capabilities. For information about enabling, disabling, or extending KIE Server capabilities, see Chapter 21, KIE Server capabilities and extensions .

Commands:
probe::ioblock_trace.request Name probe::ioblock_trace.request - Fires just as a generic block I/O request is created for a bio. Synopsis Values None Description name - name of the probe point q - request queue on which this bio was queued. devname - block device name ino - i-node number of the mapped file bytes_done - number of bytes transferred sector - beginning sector for the entire bio flags - see below BIO_UPTODATE 0 ok after I/O completion BIO_RW_BLOCK 1 RW_AHEAD set, and read/write would block BIO_EOF 2 out-out-bounds error BIO_SEG_VALID 3 nr_hw_seg valid BIO_CLONED 4 doesn't own data BIO_BOUNCED 5 bio is a bounce bio BIO_USER_MAPPED 6 contains user pages BIO_EOPNOTSUPP 7 not supported rw - binary trace for read/write request vcnt - bio vector count which represents number of array element (page, offset, length) which make up this I/O request idx - offset into the bio vector array phys_segments - number of segments in this bio after physical address coalescing is performed. size - total size in bytes bdev - target block device bdev_contains - points to the device object which contains the partition (when bio structure represents a partition) p_start_sect - points to the start sector of the partition structure of the device Context The process makes block I/O request

Commands:
ioblock_trace.request
Chapter 16. Red Hat Network Red Hat Network is an Internet solution for managing one or more Red Hat Enterprise Linux systems. All Security Alerts, Bug Fix Alerts, and Enhancement Alerts (collectively known as Errata Alerts) can be downloaded directly from Red Hat using the Package Updater standalone application or through the RHN website available at https://rhn.redhat.com/ . Figure 16.1. Your RHN Red Hat Network saves you time because you receive email when updated packages are released. You do not have to search the Web for updated packages or security alerts. By default, Red Hat Network installs the packages as well. You do not have to learn how to use RPM or worry about resolving software package dependencies; RHN does it all. Red Hat Network features include: Errata Alerts - learn when Security Alerts, Bug Fix Alerts, and Enhancement Alerts are issued for all the systems in your network Figure 16.2. Relevant Errata Automatic email notifications - Receive an email notification when an Errata Alert is issued for your system(s) Scheduled Errata Updates - Schedule delivery of Errata Updates Package installation - Schedule package installation on one or more systems with the click of a button Package Updater - Use the Package Updater to download the latest software packages for your system (with optional package installation) Red Hat Network website - Manage multiple systems, downloaded individual packages, and schedule actions such as Errata Updates through a secure Web browser connection from any computer Warning You must activate your Red Hat Enterprise Linux product before registering your system with Red Hat Network to make sure your system is entitled to the correct services. To activate your product, go to: After activating your product, register it with Red Hat Network to receive Errata Updates. The registration process gathers information about the system that is required to notify you of updates. For example, a list of packages installed on the system is compiled so you are only notified about updates that are relevant to your system. The first time the system is booted, the Software Update Setup Assistant prompts you to register. If you did not register then, select Applications (the main menu on the panel) => System Tools => Package Updater on your desktop to start the registration process. Alternately, execute the command yum update from a shell prompt. Figure 16.3. Registering with RHN After registering, use one of the following methods to start receiving updates: Select Applications (the main menu on the panel) => System Tools => Package Updater on your desktop Execute the command yum from a shell prompt Use the RHN website at https://rhn.redhat.com/ Click on the package icon when it appears in the panel to launch the Package Updater . For more detailed instructions, refer to the documentation available at: Note Red Hat Enterprise Linux includes a convenient panel icon that displays visible alerts when there is an update for your Red Hat Enterprise Linux system. This panel icon is not present if no updates are available.

Commands:
http://www.redhat.com/apps/activate/
http://www.redhat.com/docs/manuals/RHNetwork/
Providing feedback on Red Hat build of Quarkus documentation To report an error or to improve our documentation, log in to your Red Hat Jira account and submit an issue. If you do not have a Red Hat Jira account, then you will be prompted to create an account. Procedure Click the following link to create a ticket . Enter a brief description of the issue in the Summary . Provide a detailed description of the issue or enhancement in the Description . Include a URL to where the issue occurs in the documentation. Clicking Submit creates and routes the issue to the appropriate documentation team.

Commands:
Chapter 65. KafkaAutoRebalanceConfiguration schema reference Used in: CruiseControlSpec Property Property type Description mode string (one of [remove-brokers, add-brokers]) Specifies the mode for automatically rebalancing when brokers are added or removed. Supported modes are add-brokers and remove-brokers . template LocalObjectReference Reference to the KafkaRebalance custom resource to be used as the configuration template for the auto-rebalancing on scaling when running for the corresponding mode.

Commands:
Chapter 10. Uninstalling a cluster on OpenStack You can remove a cluster that you deployed to Red Hat OpenStack Platform (RHOSP). 10.1. Removing a cluster that uses installer-provisioned infrastructure You can remove a cluster that uses installer-provisioned infrastructure from your cloud. Note If you deployed your cluster to the AWS C2S Secret Region, the installation program does not support destroying the cluster; you must manually remove the cluster resources. Note After uninstallation, check your cloud provider for any resources not removed properly, especially with User Provisioned Infrastructure (UPI) clusters. There might be resources that the installer did not create or that the installer is unable to access. For example, some Google Cloud resources require IAM permissions in shared VPC host projects, or there might be unused health checks that must be deleted . Prerequisites You have a copy of the installation program that you used to deploy the cluster. You have the files that the installation program generated when you created your cluster. Procedure From the directory that contains the installation program on the computer that you used to install the cluster, run the following command: USD ./openshift-install destroy cluster \ --dir <installation_directory> --log-level info 1 2 1 For <installation_directory> , specify the path to the directory that you stored the installation files in. 2 To view different details, specify warn , debug , or error instead of info . Note You must specify the directory that contains the cluster definition files for your cluster. The installation program requires the metadata.json file in this directory to delete the cluster. Optional: Delete the <installation_directory> directory and the OpenShift Container Platform installation program.

Commands:
./openshift-install destroy cluster --dir <installation_directory> --log-level info 1 2
Chapter 4. Example applications with Red Hat build of Kogito microservices Red Hat build of Kogito microservices include example applications in the rhpam-7.13.5-kogito-and-optaplanner-quickstarts.zip file. These example applications contain various types of services on Red Hat build of Quarkus or Spring Boot to help you develop your own applications. The services use one or more Decision Model and Notation (DMN) decision models, Drools Rule Language (DRL) rule units, Predictive Model Markup Language (PMML) models, or Java classes to define the service logic. For information about each example application and instructions for using them, see the README file in the relevant application folder. Note When you run examples in a local environment, ensure that the environment matches the requirements that are listed in the README file of the relevant application folder. Also, this might require making the necessary network ports available, as configured for Red Hat build of Quarkus, Spring Boot, and docker-compose where applicable. The following list describes some of the examples provided with Red Hat build of Kogito microservices: Note These quick start examples showcase a supported setup. Other quickstarts not listed might use technology that is provided by the upstream community only and therefore not fully supported by Red Hat. Decision services dmn-quarkus-example and dmn-springboot-example : A decision service (on Red Hat build of Quarkus or Spring Boot) that uses DMN to determine driver penalty and suspension based on traffic violations. rules-quarkus-helloworld : A Hello World decision service on Red Hat build of Quarkus with a single DRL rule unit. ruleunit-quarkus-example and ruleunit-springboot-example : A decision service (on Red Hat build of Quarkus or Spring Boot) that uses DRL with rule units to validate a loan application and that exposes REST operations to view application status. dmn-pmml-quarkus-example and dmn-pmml-springboot-example : A decision service (on Red Hat build of Quarkus or Spring Boot) that uses DMN and PMML to determine driver penalty and suspension based on traffic violations. dmn-drools-quarkus-metrics and dmn-drools-springboot-metrics : A decision service (on Red Hat build of Quarkus or Spring Boot) that enables and consumes the runtime metrics monitoring feature in Red Hat build of Kogito. pmml-quarkus-example and pmml-springboot-example : A decision service (on Red Hat build of Quarkus or Spring Boot) that uses PMML. For more information, see Designing a decision service using DMN models , Designing a decision service using DRL rules , and Designing a decision service using PMML models .

Commands:
probe::sunrpc.svc.drop Name probe::sunrpc.svc.drop - Drop RPC request Synopsis sunrpc.svc.drop Values rq_xid the transmission id in the request sv_name the service name rq_prot the IP protocol of the reqeust peer_ip the peer address where the request is from rq_proc the procedure number in the request rq_vers the program version in the request rq_prog the program number in the request

Commands:
Chapter 5. June 2024 5.1. Node networking costs for OpenShift on cloud Costs associated with ingress and egress network traffic for individual nodes are now separated. A new project called network unattributed shows costs related to network traffic. You can use a cost model to distribute theses network costs in a similar way to platform and worker unallocated costs. 5.2. Default to AWS savings plan If you have an AWS savings plan for the EC2 instances running on OpenShift nodes, cost management uses the savings plan cost by default.

Commands:
18.12.11.2. Limiting Number of Connections To limit the number of connections a guest virtual machine may establish, a rule must be provided that sets a limit of connections for a given type of traffic. If for example a VM is supposed to be allowed to only ping one other IP address at a time and is supposed to have only one active incoming ssh connection at a time. Example 18.10. XML sample file that sets limits to connections The following XML fragment can be used to limit connections Note Limitation rules must be listed in the XML prior to the rules for accepting traffic. According to the XML file in Example 18.10, "XML sample file that sets limits to connections" , an additional rule for allowing DNS traffic sent to port 22 go out the guest virtual machine, has been added to avoid ssh sessions not getting established for reasons related to DNS lookup failures by the ssh daemon. Leaving this rule out may result in the ssh client hanging unexpectedly as it tries to connect. Additional caution should be used in regards to handling timeouts related to tracking of traffic. An ICMP ping that the user may have terminated inside the guest virtual machine may have a long timeout in the host physical machine's connection tracking system and will therefore not allow another ICMP ping to go through. The best solution is to tune the timeout in the host physical machine's sysfs with the following command:# echo 3 > /proc/sys/net/netfilter/nf_conntrack_icmp_timeout . This command sets the ICMP connection tracking timeout to 3 seconds. The effect of this is that once one ping is terminated, another one can start after 3 seconds. If for any reason the guest virtual machine has not properly closed its TCP connection, the connection to be held open for a longer period of time, especially if the TCP timeout value was set for a large amount of time on the host physical machine. In addition, any idle connection may result in a time out in the connection tracking system which can be re-activated once packets are exchanged. However, if the limit is set too low, newly initiated connections may force an idle connection into TCP backoff. Therefore, the limit of connections should be set rather high so that fluctuations in new TCP connections do not cause odd traffic behavior in relation to idle connections.

Commands:
[...] <rule action='drop' direction='in' priority='400'> <tcp connlimit-above='1'/> </rule> <rule action='accept' direction='in' priority='500'> <tcp dstportstart='22'/> </rule> <rule action='drop' direction='out' priority='400'> <icmp connlimit-above='1'/> </rule> <rule action='accept' direction='out' priority='500'> <icmp/> </rule> <rule action='accept' direction='out' priority='500'> <udp dstportstart='53'/> </rule> <rule action='drop' direction='inout' priority='1000'> <all/> </rule> [...]
1.3. Configuring the iptables Firewall to Allow Cluster Components Note The ideal firewall configuration for cluster components depends on the local environment, where you may need to take into account such considerations as whether the nodes have multiple network interfaces or whether off-host firewalling is present. The example here, which opens the ports that are generally required by a Pacemaker cluster, should be modified to suit local conditions. Table 1.1, "Ports to Enable for High Availability Add-On" shows the ports to enable for the Red Hat High Availability Add-On and provides an explanation for what the port is used for. You can enable all of these ports by means of the firewalld daemon by executing the following commands. Table 1.1. Ports to Enable for High Availability Add-On Port When Required TCP 2224 Required on all nodes (needed by the pcsd Web UI and required for node-to-node communication) It is crucial to open port 2224 in such a way that pcs from any node can talk to all nodes in the cluster, including itself. When using the Booth cluster ticket manager or a quorum device you must open port 2224 on all related hosts, such as Booth arbiters or the quorum device host. TCP 3121 Required on all nodes if the cluster has any Pacemaker Remote nodes Pacemaker's crmd daemon on the full cluster nodes will contact the pacemaker_remoted daemon on Pacemaker Remote nodes at port 3121. If a separate interface is used for cluster communication, the port only needs to be open on that interface. At a minimum, the port should open on Pacemaker Remote nodes to full cluster nodes. Because users may convert a host between a full node and a remote node, or run a remote node inside a container using the host's network, it can be useful to open the port to all nodes. It is not necessary to open the port to any hosts other than nodes. TCP 5403 Required on the quorum device host when using a quorum device with corosync-qnetd . The default value can be changed with the -p option of the corosync-qnetd command. UDP 5404 Required on corosync nodes if corosync is configured for multicast UDP UDP 5405 Required on all corosync nodes (needed by corosync ) TCP 21064 Required on all nodes if the cluster contains any resources requiring DLM (such as clvm or GFS2 ) TCP 9929, UDP 9929 Required to be open on all cluster nodes and booth arbitrator nodes to connections from any of those same nodes when the Booth ticket manager is used to establish a multi-site cluster.

Commands:
firewall-cmd --permanent --add-service=high-availability firewall-cmd --add-service=high-availability
7.176. perl-GSSAPI 7.176.1. RHBA-2012:1340 - perl-GSSAPI bug fix update Updated perl-GSSAPI packages that fix one bug are now available for Red Hat Enterprise Linux 6. The perl-GSSAPI packages provide Perl extension for GSSAPIv2 access. Bug Fix BZ# 657274 Prior to this update, the perl-GSSAPI specification file used a krb5-devel file which was removed. As a consequence, the perl-GSSAPI package could not be rebuilt. This update modifies the specification file to use the current krb5-devel files. All users of perl-GSSAPI are advised to upgrade to these updated packages, which fix this bug.

Commands:
Chapter 2. Maintenance support 2.1. Maintenance support for JBoss EAP XP When a new JBoss EAP XP major version is released, maintenance support for the major version begins. Maintenance support usually lasts for 12 weeks. If you use a JBoss EAP XP major version that is outside of its maintenance support length, you might experience issues as the development of security patches and bug fixes no longer apply. To avoid such issues, upgrade to the newest JBoss EAP XP major version release that is compatible with your JBoss EAP version. Additional resources For information about maintenance support, see the Red Hat JBoss Enterprise Application Platform expansion pack (JBoss EAP XP or EAP XP) Life Cycle and Support Policies located on the Red Hat Customer Portal.

Commands:
Chapter 4. Networking Operators overview OpenShift Container Platform supports multiple types of networking Operators. You can manage the cluster networking using these networking Operators. 4.1. Cluster Network Operator The Cluster Network Operator (CNO) deploys and manages the cluster network components in an OpenShift Container Platform cluster. This includes deployment of the Container Network Interface (CNI) network plugin selected for the cluster during installation. For more information, see Cluster Network Operator in OpenShift Container Platform . 4.2. DNS Operator The DNS Operator deploys and manages CoreDNS to provide a name resolution service to pods. This enables DNS-based Kubernetes Service discovery in OpenShift Container Platform. For more information, see DNS Operator in OpenShift Container Platform . 4.3. Ingress Operator When you create your OpenShift Container Platform cluster, pods and services running on the cluster are each allocated IP addresses. The IP addresses are accessible to other pods and services running nearby but are not accessible to external clients. The Ingress Operator implements the Ingress Controller API and is responsible for enabling external access to OpenShift Container Platform cluster services. For more information, see Ingress Operator in OpenShift Container Platform . 4.4. External DNS Operator The External DNS Operator deploys and manages ExternalDNS to provide the name resolution for services and routes from the external DNS provider to OpenShift Container Platform. For more information, see Understanding the External DNS Operator . 4.5. Ingress Node Firewall Operator The Ingress Node Firewall Operator uses an extended Berkley Packet Filter (eBPF) and eXpress Data Path (XDP) plugin to process node firewall rules, update statistics and generate events for dropped traffic. The operator manages ingress node firewall resources, verifies firewall configuration, does not allow incorrectly configured rules that can prevent cluster access, and loads ingress node firewall XDP programs to the selected interfaces in the rule's object(s). For more information, see Understanding the Ingress Node Firewall Operator 4.6. Network Observability Operator The Network Observability Operator is an optional Operator that allows cluster administrators to observe the network traffic for OpenShift Container Platform clusters. The Network Observability Operator uses the eBPF technology to create network flows. The network flows are then enriched with OpenShift Container Platform information and stored in Loki. You can view and analyze the stored network flows information in the OpenShift Container Platform console for further insight and troubleshooting. For more information, see About Network Observability Operator .

Commands: