mtpti5iD/redhat-docs_dataset huggingface dataset:
11.3. Python Client Code The following code is an example of interacting with the Red Hat JBoss Data Grid REST API using Python. The provided code requires only the standard HTTP library. Example 11.2. Using the REST API with Python Report a bug

Commands:
import httplib #How to insert data conn = httplib.HTTPConnection("localhost:8080") data = "SOME DATA HERE \!" #could be string, or a file conn.request("POST", "/rest/default/0", data, {"Content-Type": "text/plain"}) response = conn.getresponse() print response.status #How to retrieve data import httplib conn = httplib.HTTPConnection("localhost:8080") conn.request("GET", "/rest/default/0") response = conn.getresponse() print response.status print response.read()
11.4.2.5. Recipe Examples Procmail is an extremely flexible program, but as a result of this flexibility, composing Procmail recipes from scratch can be difficult for new users. The best way to develop the skills to build Procmail recipe conditions stems from a strong understanding of regular expressions combined with looking at many examples built by others. A thorough explanation of regular expressions is beyond the scope of this section. The structure of Procmail recipes and useful sample Procmail recipes can be found at various places on the Internet (such as http://www.iki.fi/era/procmail/links.html ). The proper use and adaptation of regular expressions can be derived by viewing these recipe examples. In addition, introductory information about basic regular expression rules can be found in the grep man page. The following simple examples demonstrate the basic structure of Procmail recipes and can provide the foundation for more intricate constructions. A basic recipe may not even contain conditions, as is illustrated in the following example: The first line specifies that a local lockfile is to be created but does not specify a name, so Procmail uses the destination file name and appends the value specified in the LOCKEXT environment variable. No condition is specified, so every message matches this recipe and is placed in the single spool file called new-mail.spool , located within the directory specified by the MAILDIR environment variable. An MUA can then view messages in this file. A basic recipe, such as this, can be placed at the end of all rc files to direct messages to a default location. The following example matched messages from a specific email address and throws them away. With this example, any messages sent by spammer@domain.com are sent to the /dev/null device, deleting them. Warning Be certain that rules are working as intended before sending messages to /dev/null for permanent deletion. If a recipe inadvertently catches unintended messages, and those messages disappear, it becomes difficult to troubleshoot the rule. A better solution is to point the recipe's action to a special mailbox, which can be checked from time to time to look for false positives. Once satisfied that no messages are accidentally being matched, delete the mailbox and direct the action to send the messages to /dev/null . The following recipe grabs email sent from a particular mailing list and places it in a specified folder. Any messages sent from the tux-lug@domain.com mailing list are placed in the tuxlug mailbox automatically for the MUA. Note that the condition in this example matches the message if it has the mailing list's email address on the From , CC , or To lines. Consult the many Procmail online resources available in Section 11.6, "Additional Resources" for more detailed and powerful recipes.

Commands:
:0: new-mail.spool
:0 * ^From: spammer@domain.com /dev/null
:0: * ^(From|CC|To).*tux-lug tuxlug
Chapter 1. Installing OpenShift Lightspeed The installation process for Red Hat OpenShift Lightspeed consists of two main tasks: configuring the Large Language Model (LLM) provider and installing the Lightspeed Operator. 1.1. Large Language Model (LLM) configuration overview You should configure the Large Language Model (LLM) provider you will use prior to installing the OpenShift Lightspeed Operator. 1.1.1. About OpenAI configuration with OpenShift Lightspeed To configure OpenAI as the LLM provider to be used with OpenShift Lightspeed, you must use either your OpenAI API key or OpenAI project name during the configuration process. The OpenAI service has a feature for projects and service accounts. You may use a service account in a dedicated project so that you can precisely track OpenShift Lightspeed usage. For more information, see the official OpenAI product documentation . 1.1.2. About Azure OpenAI configuration with OpenShift Lightspeed You need a Microsoft Azure OpenAI service instance. There must be at least one model deployment in Microsoft Azure OpenAI Studio for that instance. For more information, see the official Microsoft Azure OpenAI product documentation . 1.1.3. About IBM WatsonX configuration with OpenShift Lightspeed You need an IBM Cloud project with access to IBM WatsonX. You will also need your IBM WatsonX API key. For more information, see the official IBM WatsonX product documentation . 1.2. Installing the OpenShift Lightspeed Operator Prerequisites You have deployed OpenShift Container Platform 4.15 or later. The cluster must be connected to the Internet and have telemetry enabled. You are logged in to the OpenShift Container Platform web console as a user with the cluster-admin role. You have access to the OpenShift CLI (oc). You have successfully configured your Large Language Model (LLM) provider so that OpenShift Lightspeed can communicate with it. Procedure In the OpenShift Container Platform web console, navigate to the Operators OperatorHub page. Search for Lightspeed. Locate the Lightspeed Operator, and click to select it. When the prompt that discusses the community operator appears, click Continue . Click Install . Use the default installation settings presented, and click Install to continue. Click Operators Installed Operators to verify that the Lightspeed Operator is installed. Succeeded should appear in the Status column.

Commands:
4.2.4. Blacklist Exceptions You can use the blacklist_exceptions section of the configuration file to enable multipathing on devices that have been blacklisted by default. For example, if you have a large number of devices and want to multipath only one of them (with the WWID of 3600d0230000000000e13955cc3757803), instead of individually blacklisting each of the devices except the one you want, you could instead blacklist all of them, and then allow only the one you want by adding the following lines to the /etc/multipath.conf file. When specifying devices in the blacklist_exceptions section of the configuration file, you must specify the exceptions in the same way they were specified in the blacklist. For example, a WWID exception will not apply to devices specified by a devnode blacklist entry, even if the blacklisted device is associated with that WWID. Similarly, devnode exceptions apply only to devnode entries, and device exceptions apply only to device entries.

Commands:
blacklist { wwid "*" } blacklist_exceptions { wwid "3600d0230000000000e13955cc3757803" }
7.272. wget 7.272.1. RHBA-2012:1353 - wget bug fix update Updated wget packages that fix one bug are now available for Red Hat Enterprise Linux 6. The wget packages provide the GNU Wget file retrieval utility for HTTP, HTTPS, and FTP protocols. Wget provides various useful features, such as the ability to work in the background while the user is logged out, recursive retrieval of directories, file name wildcard matching or updating files in dependency on file timestamp comparison. Bug Fixes BZ# 754168 Prior to this update, the wget package contained a redundant URL to the wget upstream project. This update modifies the specification file to list the correct http://www.gnu.org/software/wget/. BZ#814208 Prior to this update, the wget utility did not previously work as intended with the "-T, --timeout" option set when http server did not answer the SSL handshake. Wget source code has been patched, to ensure that wget aborts the connection when using --timeout option correctly. BZ#714893 Prior to this update, the wget utility source code was lacking check of the HTTP response parsing function return value. In some cases, when HTTP response header was malformed (fuzzed), the parsing function returned error. Because the returned value was not checked, it then resulted in Segmentation Fault. This update adds check of the HTTP response parsing function return value in the wget source code. Now when HTTP response header is malformed (fuzzed) and the parsing function returns error, the following error message is thrown and wget retries the request: All users of wget are advised to upgrade to these updated packages, which fix this bug.

Commands:
2012-10-01 10:13:44 ERROR -1: Malformed status line.
Chapter 5. Important notes 5.1. Preferred clients In general, AMQ clients that support the AMQP 1.0 standard are preferred for new application development. However, the following exceptions apply: If your implementation requires distributed transactions, use the AMQ Core Protocol JMS client. If you require MQTT or STOMP in your domain (for IoT applications, for instance), use community-supported MQTT or STOMP clients. 5.2. Legacy clients Deprecation of the AMQ OpenWire JMS client The AMQ OpenWire JMS client is now deprecated in AMQ 7. It is recommended that users of this client migrate to AMQ JMS or AMQ Core Protocol JMS. Deprecation of the CMS and NMS APIs The ActiveMQ CMS and NMS messaging APIs are deprecated in AMQ 7. It is recommended that users of the CMS API migrate to AMQ C++, and users of the NMS API migrate to AMQ .NET. The CMS and NMS APIs might have reduced functionality in AMQ 7. Deprecation of the legacy AMQ C++ client The legacy AMQ C++ client (the C++ client previously provided in MRG Messaging) is deprecated in AMQ 7. It is recommended that users of this API migrate to AMQ C++. The Core API is unsupported The Artemis Core API client is not supported. This client is distinct from the AMQ Core Protocol JMS client, which is supported.

Commands:
Chapter 59. Servers and Services Rsyslog cannot proceed if the default maximum of open files is exceeded Rsyslog sometimes runs over the default limits for maximum number of open files. Consequently, rsyslog cannot open new files. To work around this problem, modify the rsyslog configuration by increasing this limit to align with systemd-journald. To do so, create a drop-in file named /etc/systemd/system/rsyslog.service.d/increase_nofile_limit.conf with the following content: (BZ# 1553700 ) Upgrading a RHEL 7.5 node to RHEL 7.6 in RHOSP 10 breaks virtual machines on the node Currently, upgrading a Red Hat Enterprise Linux 7.5 node to Red Hat Enterprise Linux 7.6 in Red Hat OpenStack Plaform 10 causes virtual machines hosted on that node to become unable to start. To work around this problem, edit the /etc/modprobe.d/kvm.rt.tuned.conf file on the compute node, remove the following line, and reboot the node: For this to work reliably, perform the changes before upgrading the node from RHEL 7.5 to RHEL 7.6. (BZ# 1649408 ) FTP-based logins are unavailable for a common vsftpd configuration This update removes the /sbin/nologin and /usr/sbin/nologin login shells from the /etc/shells file due to security reasons. Consequently, when the configuration of the Very Secure File Transfer Protocol Daemon, vsftpd , is modified to enable the chroot_local_user , FTP logins are impossible. To work around this problem, add /sbin/nologin or /usr/sbin/nologin , respectively, to the /etc/shells file. As a result, a login shell for users that are allowed to use FTP, but not SSH, is available again. However, note that this workaround exposes vsftpd to the security risk described at https://access.redhat.com/security/cve/cve-2018-1113 . (BZ# 1647485 , BZ#1571104) Teaming might not work correctly in the rescue system after applying RHBA-2019:0498 Updates provided by advisory RHBA-2019:0498 fixed several problems in ReaR affecting complex network configurations. These bugs previously made it impossible to restore backups accessed over the network without manual intervention. However, in case of teaming, this update might introduce another problem. If the team has multiple member interfaces, the team device might not be configured correctly in the rescue system. To work around this problem, preserve the behavior by adding the following line in the /etc/rear/local.conf file : For the newly added LACP support, temporarily remove all interfaces but one from the team during the rescue image creation process as a workaround. (BZ# 1685166 )

Commands:
[Service] LimitNOFILE=16384
options kvm_intel ple_gap=0
SIMPLIFY_TEAMING=y
Chapter 1. Dependent Products Support Matrix Automation Services Catalog is dependent on and integrated with Ansible Tower server in the Ansible Automation Platform. The following table details supported versions of Ansible Tower server for use with all versions of Automation Services Catalog. Table 1.1. Ansible Tower Ansible Tower Version Status 3.7 Supported 3.6 Supported 3.5 Not supported Note Automation Services Catalog support of a Ansible Tower version ends at the same time as that of the Ansible Tower version going end of life.

Commands:
2.3.2. Virtualized to Virtualized Migration (V2V) Red Hat Enterprise Linux 6 provides tools for converting virtual machines from other types of hypervisors to KVM. The virt-v2v tool converts and imports virtual machines from Xen, other versions of KVM, VMware ESX, and Hyper-V. In Red Hat Enterprise Linux 6.5 and later, the virt-v2v tool converts and imports virtual machines with virtual disk image formats including VHDX, VMDK, OVF, raw, and qcow2. Important The V2V tool for Red Hat Enterprise Linux 6 has been deprecated, and it is recommended to use the Red Hat Enterprise Linux 7 version. For more information, refer to the Red Hat Enterprise Linux 6 V2V Guide .

Commands:
Chapter 26. Data objects Data objects are the building blocks for the rule assets that you create. Data objects are custom data types implemented as Java objects in specified packages of your project. For example, you might create a Person object with data fields Name , Address , and DateOfBirth to specify personal details for loan application rules. These custom data types determine what data your assets and your decision services are based on. 26.1. Creating the ITOrderService data object The ITOrderService data object specifies the data type that will be used to define the IT Orders variables. Prerequisites The IT_Orders_New project is created. Procedure Click Add Asset Data Object . In the Create new Data Object wizard, enter the following values: Data Object: ITOrderService Package: com.myspace.it_orders_new Click Ok . Click to the Package drop-down menu to specify a new package for the data object. Input org.jbpm.demo.it_orders.services and click Add . Click Save , and then click Yes, Move to confirm your changes. 26.2. Creating the Survey data object The Survey data object contains data fields, such as deliveredOnTime and missingEquipment. You will use the data and values when you design your case. Prerequisites The IT_Orders_New project is created. Procedure In Business Central, go to Menu Design Projects and click IT_Orders_New . Click Add Asset Data Object . In the Create new Data Object wizard, enter the following values: Data Object : Survey Package : com.myspace.it_orders_new Click Ok . Add the Survey data object constraints. Click add field . Enter the following values: Id : comment Label : Leave empty Type : String Click Create and continue , and then enter the following values: Id : deliveredOnTime Label : Leave empty Type : Boolean Click Create and continue , and then enter the following values: Id : missingEquipment Label : Leave empty Type : String Click Create and continue , and then enter the following values: Id : satisfied Label : Leave empty Type : Boolean Click Create . Click Save to confirm your changes. Figure 26.1. Survey data object details

Commands:
Chapter 1. Updating Red Hat Enterprise Linux AI Red Hat Enterprise Linux AI allows you to update your instance so you can use the latest version of RHEL AI and InstructLab. 1.1. Updating your RHEL AI instance You can update your instance to use the latest version of RHEL AI and InstructLab Prerequisets You installed and deployed a Red Hat Enterprise Linux AI instance on one of the supported platforms. You created a Red Hat registry account. You have root user access on your machine. Procedure Log into your Red Hat registry account with the podman command: USD sudo podman login registry.redhat.io --username <user-name> --password <user-password> --authfile /etc/ostree/auth.json Or you can log in with the skopeo command: USD sudo skopeo login registry.redhat.io --username <user-name> --password <user-password> --authfile /etc/ostree/auth.json Upgrading to a minor version of Red Hat Enterprise Linux AI You can upgrade your instance to use the latest version of Red Hat Enterprise Linux AI by running the following command: USD sudo bootc switch <latest-rhelai-image> where <path-to-latest-image> Specify the latest version of the RHEL AI image. Example command USD sudo bootc switch registry.redhat.io/rhelai1/bootc-nvidia-rhel9:1.3 Restart your system by running the following command: USD sudo reboot -n Upgrading to a z-stream version of Red Hat Enterprise Linux AI If a z-stream exists, you can upgrade your system to a z-stream version of RHEL AI by running the folllowing command: USD sudo bootc upgrade --apply It is recommended to re-initialize your environment and configurations after you upgrade to the latest RHEL AI version. Warning The ilab config init command overrides your existing config.yaml file and sets it to the default configurations per your system hardware. If you customized the config.yaml file, ensure you are familiar with your custom configurations before re-initializing. USD ilab config init

Commands:
sudo podman login registry.redhat.io --username <user-name> --password <user-password> --authfile /etc/ostree/auth.json
sudo skopeo login registry.redhat.io --username <user-name> --password <user-password> --authfile /etc/ostree/auth.json
sudo bootc switch <latest-rhelai-image>
sudo bootc switch registry.redhat.io/rhelai1/bootc-nvidia-rhel9:1.3
sudo reboot -n
sudo bootc upgrade --apply
ilab config init
5.2. Supported Application Logging Frameworks Red Hat JBoss LogManager supports the following logging frameworks: JBoss Logging, which is included with Red Hat JBoss Data Grid 6. Apache Commons Logging Simple Logging Facade for Java (SLF4J) Apache log4j Java SE Logging (java.util.logging) Report a bug 5.2.1. About JBoss Logging JBoss Logging is the application logging framework that is included in JBoss Enterprise Application Platform 6. As a result of this inclusion, Red Hat JBoss Data Grid 6 also uses JBoss Logging. JBoss Logging provides an easy way to add logging to an application. Add code to the application that uses the framework to send log messages in a defined format. When the application is deployed to an application server, these messages can be captured by the server and displayed and/or written to file according to the server's configuration. Report a bug 5.2.2. JBoss Logging Features JBoss Logging includes the following features: Provides an innovative, easy to use typed logger. Full support for internationalization and localization. Translators work with message bundles in properties files while developers can work with interfaces and annotations. Build-time tooling to generate typed loggers for production, and runtime generation of typed loggers for development. Report a bug

Commands:
8.3.4. Permissive Domains When SELinux is running in permissive mode, SELinux does not deny access, but denials are logged for actions that would have been denied if running in enforcing mode. Previously, it was not possible to make a single domain permissive (remember: processes run in domains). In certain situations, this led to making the whole system permissive to troubleshoot issues. Permissive domains allow an administrator to configure a single process (domain) to run permissive, rather than making the whole system permissive. SELinux checks are still performed for permissive domains; however, the kernel allows access and reports an AVC denial for situations where SELinux would have denied access. Permissive domains have the following uses: They can be used for making a single process (domain) run permissive to troubleshoot an issue without putting the entire system at risk by making it permissive. They allow an administrator to create policies for new applications. Previously, it was recommended that a minimal policy be created, and then the entire machine put into permissive mode, so that the application could run, but SELinux denials still logged. audit2allow could then be used to help write the policy. This put the whole system at risk. With permissive domains, only the domain in the new policy can be marked permissive, without putting the whole system at risk. 8.3.4.1. Making a Domain Permissive To make a domain permissive, run the semanage permissive -a domain command, where domain is the domain you want to make permissive. For example, run the following command as the Linux root user to make the httpd_t domain (the domain the Apache HTTP Server runs in) permissive: To view a list of domains you have made permissive, run the semodule -l | grep permissive command as the Linux root user. For example: If you no longer want a domain to be permissive, run the semanage permissive -d domain command as the Linux root user. For example:

Commands:
~]# semanage permissive -a httpd_t
~]# semodule -l | grep permissive permissive_httpd_t 1.0 permissivedomains 1.0.0
~]# semanage permissive -d httpd_t
Chapter 5. Creating a Puppet Config Group A Puppet config group is a named list of Puppet classes that allows you to combine their capabilities and assign them to managed hosts at a click. This is equivalent to the concept of profiles in pure Puppet. Procedure In the Satellite web UI, navigate to Configure > Config Groups . Click the Create Config Group button. Select the classes you want to add to the config group. Choose a meaningful Name for the Puppet config group. Add selected Puppet classes to the Included Classes field. Click Submit to save the changes.

Commands: