mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 17. Verifying the Red Hat Decision Manager installation After you have installed Red Hat Process Automation Manager, create an asset to verify that the installation is working. Procedure In a terminal window, navigate to the EAP_HOME /bin directory and enter the following command to start Red Hat Process Automation Manager: Note If you deployed Business Central without KIE Server, you can start Business Central with the standalone.sh script without specifying the standalone-full.xml file. In this case, ensure that you make any configuration changes to the standalone.xml file before starting Business Central. In a web browser, enter localhost:8080/business-central . If you configured Red Hat Process Automation Manager to run from a domain name, replace localhost with the domain name, for example: http://www.example.com:8080/business-central If you configured Red Hat Process Automation Manager to run in a cluster, replace localhost with the IP address of a particular node, for example: http://<node_IP_address>:8080/business-central Enter the admin user credentials that you created during installation. The Business Central home page appears. Select Menu Deploy Execution Servers . Confirm that default-kieserver is listed under Server Configurations . Select Menu Design Projects . Open the MySpace space. Click Try Samples Mortgages OK . The Assets window appears. Click Add Asset Data Object . Enter MyDataObject in the Data Object field and click OK . Click Spaces MySpace Mortgages and confirm that MyDataObject is in the list of assets. Delete the Mortgages project.

Commands:
./standalone.sh -c standalone-full.xml
Chapter 3. Technology Previews Important Technology Preview features are not supported with Red Hat production service-level agreements (SLAs) and might not be functionally complete; therefore, Red Hat does not recommend implementing any Technology Preview features in production environments. This Technology Preview feature provides early access to upcoming product innovations, enabling you to test functionality and provide feedback during the development process. For more information about support scope, see Technology Preview Features Support Scope . 3.1. Cluster rebalancing with Cruise Control You can now install Cruise Control and use it to rebalance a Kafka cluster. Cruise Control helps to reduce the time and effort involved in running an efficient and balanced Kafka cluster. A zipped distribution of Cruise Control is available for download from the Customer Portal . To install Cruise Control, you configure each Kafka broker to use the provided Metrics Reporter. Then, you set Cruise Control properties, including optimization goals, and start Cruise Control using the provided script. The Cruise Control server is hosted on a single machine for the whole Kafka cluster. When Cruise Control is running, you can use the REST API to: Generate dry run optimization proposals from multiple optimization goals Initiate an optimization proposal to rebalance the Kafka cluster Other Cruise Control features are not currently supported, including anomaly detection, notifications, write-your-own goals, and changing the topic replication factor. See Cruise Control for cluster rebalancing .

Commands:
8.109. mailx 8.109.1. RHBA-2013:1129 - mailx bug fix update Updated mailx packages that fix two bugs are now available for Red Hat Enterprise Linux 6. The mailx packages contain a mail user agent that is mostly used to manage mail using scripts. Bug Fixes BZ#845098 Prior to this update, the "mail" utility provided with the Red Hat Enterprise Linux 6 mailx packages was not fully compatible with the utility provided with the Red Hat Enterprise Linux 5 mailx package and packages in earlier releases of Red Hat Enterprise Linux. Consequently, some user scripts written for the mail utility did not work with "mail" in Red Hat Enterprise Linux 6. Support for multiple versions of the "mail" utility has been added to the mailx packages. This allows the user to install alternative packages providing this utility, for example, bsd-mailx. BZ#857120 The mailx command did not set the error return code when it failed to send an e-mail because the TMPDIR environment variable was set to an invalid path. As a consequence, error checking was incorrect and therefore not helpful. With this update, the correct return code is set when mailx fails to send an e-mail. The error checking now works properly. Users of mailx are advised to upgrade to these updated packages, which fix these bugs.

Commands:
Getting started with .NET on RHEL 8 .NET 9.0 Installing and running .NET 9.0 on RHEL 8 Red Hat Customer Content Services

Commands:
sudo dnf install dotnet-sdk-9.0 -y
dotnet --info
dotnet new console --output my-app
dotnet run --project my-app
Hello World!
dotnet publish my-app -f net9.0
dotnet publish my-app -f net9.0 -r rhel.8- architecture --self-contained false
dotnet new mvc --output mvc_runtime_example
dotnet publish mvc_runtime_example -f net9.0 /p:PublishProfile=DefaultContainer /p:ContainerBaseImage=registry.access.redhat.com/ubi8/dotnet-90-runtime:latest
podman run -rm -p8080:8080 mvc_runtime_example
xdg-open http://127.0.0.1:8080
Chapter 8. Reinstalling an Existing Host as a Self-Hosted Engine Node You can convert an existing, standard host in a self-hosted engine environment to a self-hosted engine node capable of hosting the Manager virtual machine. Warning When installing or reinstalling the host's operating system, Red Hat strongly recommends that you first detach any existing non-OS storage that is attached to the host to avoid accidental initialization of these disks, and with that, potential data loss. Procedure Click Compute Hosts and select the host. Click Management Maintenance and OK . Click Installation Reinstall . Click the Hosted Engine tab and select DEPLOY from the drop-down list. Click OK . The host is reinstalled with self-hosted engine configuration, and is flagged with a crown icon in the Administration Portal. After reinstalling the hosts as self-hosted engine nodes, you can check the status of the new environment by running the following command on one of the nodes: If the new environment is running without issue, you can decommission the original Manager machine.

Commands:
hosted-engine --vm-status
30.3. Starting Initial Setup Manually Once you once finished the Initial Setup , the application does not start again when you boot the system. To manually start the Initial Setup on system boot: Enable the service: Optionally, to display all menu options, including the ones previously set, create an empty /.unconfigured file to start Initial Setup in reconfiguration mode: Note that, regardless of this setting, the license agreement entry is not displayed again if you previously accepted it. Reboot the system. Note The initial-setup-gui (graphical mode) or initial-setup (text mode) packages must be installed for to run Initial Setup .

Commands:
systemctl enable initial-setup.service
touch /.unconfigured
Chapter 13. Storage Connections 13.1. Storage Connection Elements Table 13.1. Storage Connection Base Elements Element Type Description Properties type One of nfs , posixfs , local , or iscsi The type of storage domain. address string The hostname or IP address of the storage domain. (Only required for NFS and iSCSI) host string The id or name of the hypervisor. The host is optional. Providing it will attempt a connection to the storage via the host; not providing it will lead to persisting storage details in the database. Table 13.2. Storage Connection File-based Storage Elements Element Type Description Properties path string The mounted file path of the storage domain. The path cannot be updated to one already used by a storage connection. mount_options string The options for mounting the PosixFS share. vfs_type string The Linux-supported file system type of the PosixFS share. nfs_version string The version of NFS used. nfs_timeo integer The amount of time, in deciseconds, the NFS client will wait for a request to complete. nfs_retrans integer The number of retransmissions the NFS client will attempt to complete a request. Table 13.3. Storage Connection iSCSI elements Element Type Description Properties port integer The TCP port used for the iSCSI storage domain. target string The target IQN for the storage device. username string A CHAP user name for logging into a target. password string A CHAP password for logging into a target.

Commands:
Chapter 7. Security 7.1. Securing connections with SSL/TLS AMQ Python uses SSL/TLS to encrypt communication between clients and servers. To connect to a remote server with SSL/TLS, use a connection URL with the amqps scheme. Example: Enabling SSL/TLS container.connect(" amqps ://example.com") 7.2. Connecting with a user and password AMQ Python can authenticate connections with a user and password. To specify the credentials used for authentication, set the user and password options on the connect() method. Example: Connecting with a user and password container.connect("amqps://example.com", user="alice" , password="secret" ) 7.3. Configuring SASL authentication AMQ Python uses the SASL protocol to perform authentication. SASL can use a number of different authentication mechanisms . When two network peers connect, they exchange their allowed mechanisms, and the strongest mechanism allowed by both is selected. Note The client uses Cyrus SASL to perform authentication. Cyrus SASL uses plug-ins to support specific SASL mechanisms. Before you can use a particular SASL mechanism, the relevant plug-in must be installed. For example, you need the cyrus-sasl-plain plug-in in order to use SASL PLAIN authentication. To see a list of Cyrus SASL plug-ins in Red Hat Enterprise Linux, use the yum search cyrus-sasl command. To install a Cyrus SASL plug-in, use the yum install PLUG-IN command. By default, AMQ Python allows all of the mechanisms supported by the local SASL library configuration. To restrict the allowed mechanisms and thereby control what mechanisms can be negotiated, use the allowed_mechs connection option. It takes a string containing a space-separated list of mechanism names. Example: Configuring SASL authentication container.connect("amqps://example.com", allowed_mechs="ANONYMOUS" ) This example forces the connection to authenticate using the ANONYMOUS mechanism even if the server we connect to offers other options. Valid mechanisms include ANONYMOUS , PLAIN , SCRAM-SHA-256 , SCRAM-SHA-1 , GSSAPI , and EXTERNAL . AMQ Python enables SASL by default. To disable it, set the sasl_enabled connection option to false. Example: Disabling SASL event.container.connect("amqps://example.com", sasl_enabled=False ) 7.4. Authenticating using Kerberos Kerberos is a network protocol for centrally managed authentication based on the exchange of encrypted tickets. See Using Kerberos for more information. Configure Kerberos in your operating system. See Configuring Kerberos to set up Kerberos on Red Hat Enterprise Linux. Enable the GSSAPI SASL mechanism in your client application. container.connect("amqps://example.com", allowed_mechs="GSSAPI" ) Use the kinit command to authenticate your user credentials and store the resulting Kerberos ticket. USD kinit <user> @ <realm> Run the client program.

Commands:
container.connect(" amqps ://example.com")
container.connect("amqps://example.com", user="alice" , password="secret" )
container.connect("amqps://example.com", allowed_mechs="ANONYMOUS" )
event.container.connect("amqps://example.com", sasl_enabled=False )
container.connect("amqps://example.com", allowed_mechs="GSSAPI" )
kinit <user> @ <realm>
Chapter 6. Installing the load balancer The following example provides general guidance for configuring an HAProxy load balancer using Red Hat Enterprise Linux 8 server. However, you can install any suitable load balancing software solution that supports TCP forwarding. Procedure Install HAProxy: Install the following package that includes the semanage tool: Configure SELinux to allow HAProxy to bind any port: Configure the load balancer to balance the network load for the ports as described in Table 6.1, "Ports configuration for the load balancer" . For example, to configure ports for HAProxy, edit the /etc/haproxy/haproxy.cfg file to correspond with the table. For more information, see Configuration example for haproxy.cfg for HAProxy load balancer with Satellite 6 in the Red Hat Knowledgebase . Table 6.1. Ports configuration for the load balancer Service Port Mode Balance Mode Destination HTTP 80 TCP roundrobin port 80 on all Capsule Servers HTTPS and RHSM 443 TCP source port 443 on all Capsule Servers Anaconda for template retrieval 8000 TCP roundrobin port 8000 on all Capsule Servers Puppet ( Optional ) 8140 TCP roundrobin port 8140 on all Capsule Servers PuppetCA ( Optional ) 8141 TCP roundrobin port 8140 only on the system where you configure Capsule Server to sign Puppet certificates Capsule HTTPS for Host Registration and optionally OpenSCAP 9090 TCP roundrobin port 9090 on all Capsule Servers Configure the load balancer to disable SSL offloading and allow client-side SSL certificates to pass through to back end servers. This is required because communication from clients to Capsule Servers depends on client-side SSL certificates. Start and enable the HAProxy service:

Commands:
dnf install haproxy
dnf install policycoreutils-python-utils
semanage boolean --modify --on haproxy_connect_any
systemctl enable --now haproxy
Appendix E. LVM Volume Group Metadata The configuration details of a volume group are referred to as the metadata. By default, an identical copy of the metadata is maintained in every metadata area in every physical volume within the volume group. LVM volume group metadata is stored as ASCII. If a volume group contains many physical volumes, having many redundant copies of the metadata is inefficient. It is possible to create a physical volume without any metadata copies by using the --metadatacopies 0 option of the pvcreate command. Once you have selected the number of metadata copies the physical volume will contain, you cannot change that at a later point. Selecting 0 copies can result in faster updates on configuration changes. Note, however, that at all times every volume group must contain at least one physical volume with a metadata area (unless you are using the advanced configuration settings that allow you to store volume group metadata in a file system). If you intend to split the volume group in the future, every volume group needs at least one metadata copy. The core metadata is stored in ASCII. A metadata area is a circular buffer. New metadata is appended to the old metadata and then the pointer to the start of it is updated. You can specify the size of metadata area with the --metadatasize option of the pvcreate command. The default size may be too small for volume groups that contain physical volumes and logical volumes that number in the hundreds. E.1. The Physical Volume Label By default, the pvcreate command places the physical volume label in the 2nd 512-byte sector. This label can optionally be placed in any of the first four sectors, since the LVM tools that scan for a physical volume label check the first 4 sectors. The physical volume label begins with the string LABELONE . The physical volume label contains: Physical volume UUID Size of block device in bytes NULL-terminated list of data area locations NULL-terminated lists of metadata area locations Metadata locations are stored as offset and size (in bytes). There is room in the label for about 15 locations, but the LVM tools currently use 3: a single data area plus up to two metadata areas.

Commands:
8.44. firstboot 8.44.1. RHBA-2013:1595 - firstboot bug fix update Updated firstboot packages that fix one bug are now available for Red Hat Enterprise Linux 6. The firstboot utility runs after system installation and guides the user through a series of steps that allows for easier configuration of the machine. Bug Fix BZ# 876018 The code handling the response to a two-button dialog prompted the user to click one of the buttons. After clicking the close button or pressing the Escape key, the response was ignored, and the post-installation process continued even after disagreeing to the end-user license agreement (EULA) in Red Hat Enterprise Linux 6. With this update, the code has been modified to close the dialog and stay on the underlying screen. As a result, clicking the close button or pressing the Escape key works as expected. Users of firstboot are advised to upgrade to these updated packages, which fix this bug.

Commands:
1.4. Routing Methods Red Hat Enterprise Linux uses Network Address Translation or NAT routing for Load Balancer Add-On, which allows the administrator tremendous flexibility when utilizing available hardware and integrating the Load Balancer Add-On into an existing network. 1.4.1. NAT Routing Figure 1.3, "Load Balancer Add-On Implemented with NAT Routing" , illustrates Load Balancer Add-On utilizing NAT routing to move requests between the Internet and a private network. Figure 1.3. Load Balancer Add-On Implemented with NAT Routing In the example, there are two NICs in the active LVS router. The NIC for the Internet has a real IP address on eth0 and has a floating IP address aliased to eth0:1. The NIC for the private network interface has a real IP address on eth1 and has a floating IP address aliased to eth1:1. In the event of failover, the virtual interface facing the Internet and the private facing virtual interface are taken-over by the backup LVS router simultaneously. All of the real servers located on the private network use the floating IP for the NAT router as their default route to communicate with the active LVS router so that their abilities to respond to requests from the Internet is not impaired. In this example, the LVS router's public floating IP address and private NAT floating IP address are aliased to two physical NICs. While it is possible to associate each floating IP address to its own physical device on the LVS router nodes, having more than two NICs is not a requirement. Using this topology, the active LVS router receives the request and routes it to the appropriate server. The real server then processes the request and returns the packets to the LVS router which uses network address translation to replace the address of the real server in the packets with the LVS router's public VIP address. This process is called IP masquerading because the actual IP addresses of the real servers is hidden from the requesting clients. Using this NAT routing, the real servers may be any kind of machine running various operating systems. The main disadvantage is that the LVS router may become a bottleneck in large cluster deployments because it must process outgoing as well as incoming requests. The ipvs modules utilize their own internal NAT routines that are independent of iptables and ip6tables NAT. This will facilitate both ipv4 and ipv6 NAT when the real server is configured for NAT as opposed to DR in the /etc/keepalived/keepalived.conf file.

Commands:
Chapter 14. Security A runtime version of OpenSSL is masked and SSL_OP_NO_TLSv1_1 must not be used with OpenSSL 1.0.0 Because certain applications perform incorrect version check of the OpenSSL version, the actual runtime version of OpenSSL is masked and the build-time version is reported instead. Consequently, it is impossible to detect the currently running OpenSSL version using the SSLeay() function. Additionally, passing the value equivalent to the SSL_OP_NO_TLSv1_1 option as present on OpenSSL 1.0.1 to the SSL_CTX_set_options() function when running with OpenSSL 1.0.0 breaks the SSL/TLS support completely. To work around this problem, use another way to detect the currently running OpenSSL version. For example, it is possible to obtain a list of enabled ciphers with the SSL_get_ciphers() function and search a TLS 1.2 cipher by parsing the list using the SSL_CIPHER_description() function. This indicates an application that runs with the OpenSSL version later than 1.0.0 because TLS 1.2 support is present since version 1.0.1. (BZ# 1497859 )

Commands:
40.3. Starting and Stopping OProfile To start monitoring the system with OProfile, execute the following command as root: Output similar to the following is displayed: The settings in /root/.oprofile/daemonrc are used. The OProfile daemon, oprofiled , is started; it periodically writes the sample data to the /var/lib/oprofile/samples/ directory. The log file for the daemon is located at /var/lib/oprofile/oprofiled.log . To stop the profiler, execute the following command as root:

Commands:
opcontrol --start
Using log file /var/lib/oprofile/oprofiled.log Daemon started. Profiler running.
opcontrol --shutdown
6.6. Configuring port forwarding using nftables Port forwarding enables administrators to forward packets sent to a specific destination port to a different local or remote port. For example, if your web server does not have a public IP address, you can set a port forwarding rule on your firewall that forwards incoming packets on port 80 and 443 on the firewall to the web server. With this firewall rule, users on the internet can access the web server using the IP or host name of the firewall. 6.6.1. Forwarding incoming packets to a different local port This section describes an example of how to forward incoming IPv4 packets on port 8022 to port 22 on the local system. Procedure 6.17. Forwarding incoming packets to a different local port Create a table named nat with the ip address family: Add the prerouting and postrouting chains to the table: Note Pass the -- option to the nft command to avoid that the shell interprets the negative priority value as an option of the nft command. Add a rule to the prerouting chain that redirects incoming packets on port 8022 to the local port 22 : 6.6.2. Forwarding incoming packets on a specific local port to a different host You can use a destination network address translation ( DNAT ) rule to forward incoming packets on a local port to a remote host. This enables users on the Internet to access a service that runs on a host with a private IP address. The procedure describes how to forward incoming IPv4 packets on the local port 443 to the same port number on the remote system with the 192.0.2.1 IP address. Prerequisite You are logged in as the root user on the system that should forward the packets. Procedure 6.18. Forwarding incoming packets on a specific local port to a different host Create a table named nat with the ip address family: Add the prerouting and postrouting chains to the table: Note Pass the -- option to the nft command to avoid that the shell interprets the negative priority value as an option of the nft command. Add a rule to the prerouting chain that redirects incoming packets on port 443 to the same port on 192.0.2.1 : Add a rule to the postrouting chain to masquerade outgoing traffic: Enable packet forwarding:

Commands:
nft add table ip nat
nft -- add chain ip nat prerouting { type nat hook prerouting priority -100 \; }
nft add rule ip nat prerouting tcp dport 8022 redirect to : 22
nft add table ip nat
nft -- add chain ip nat prerouting { type nat hook prerouting priority -100 \; } nft add chain ip nat postrouting { type nat hook postrouting priority 100 \; }
nft add rule ip nat prerouting tcp dport 443 dnat to 192.0.2.1
nft add rule ip nat postrouting ip daddr 192.0.2.1 masquerade
echo "net.ipv4.ip_forward=1" > /etc/sysctl.d/95-IPv4-forwarding.conf sysctl -p /etc/sysctl.d/95-IPv4-forwarding.conf