mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 12. Using Automated Notifications The Certificate System can be configured to send automatic email notifications to end users when certificates are issued or revoked or to an agent when a new request has arrived in the agent request queue. This chapter describes automated notifications and details how to enable, configure, and customize the notification email messages that are sent. Note Because of the types of notifications that can be sent, only Certificate Managers have the ability to be configured for notifications; this option is not available on the other subsystems. 12.1. About Automated Notifications for the CA Automated notifications are email messages sent when a specified event occurs. The system uses listeners that monitor the system to determine when a particular event has occurred; when the event happens, then the system is triggered to send an email to the configured recipient. Each type of notification uses a template, either in plain text or HTML, to construct the notification message. The template contains text and tokens that are expanded to fill in the correct information for a particular event. The messages can be customized by changing the text and tokens contained in the templates. The HTML templates can also be customized for different appearances and formatting. 12.1.1. Types of Automated Notifications There are three types of automated notifications: Certificate Issued . A notification message is automatically sent to users who have been issued certificates. A rejection message is sent to a user if the user's certificate request is rejected. Certificate Revocation . A notification message is automatically sent to users when the user certificate is revoked. Request in Queue . A notification message is automatically sent to one or more agents when a request enters the agent request queue, using the email addresses set for the agent. This notification type sends an email every time a message enters the queue. For more information about the request in queue job, see Section 13.1.2.2, "requestInQueueNotifier (RequestInQueueJob)" . There is also a job that sends a notification to agents about the status of the queue, which includes a summary of the queue status at certain intervals. 12.1.2. Determining End-Entity Email Addresses The notification system determines the email address of an end entity by checking first the certificate request or revocation request, then the subject name of the certificate, and last the Subject Alternative Name extension of the certificate, if the certificate contains this extension. If an email address cannot be found, the notification is sent to the email address specified in the Sender's Email Address field of the Notification panel.

Commands:
Chapter 2. Differences from upstream OpenJDK 21 Red Hat build of OpenJDK in Red Hat Enterprise Linux contains a number of structural changes from the upstream distribution of OpenJDK. The Microsoft Windows version of Red Hat build of OpenJDK attempts to follow Red Hat Enterprise Linux updates as closely as possible. The following list details the most notable Red Hat build of OpenJDK 21 changes: FIPS support. Red Hat build of OpenJDK 21 automatically detects whether RHEL is in FIPS mode and automatically configures Red Hat build of OpenJDK 21 to operate in that mode. This change does not apply to Red Hat build of OpenJDK builds for Microsoft Windows. Cryptographic policy support. Red Hat build of OpenJDK 21 obtains the list of enabled cryptographic algorithms and key size constraints from the RHEL system configuration. These configuration components are used by the Transport Layer Security (TLS) encryption protocol, the certificate path validation, and any signed JARs. You can set different security profiles to balance safety and compatibility. This change does not apply to Red Hat build of OpenJDK builds for Microsoft Windows. The src.zip file includes the source for all of the JAR libraries shipped with Red Hat build of OpenJDK. Red Hat build of OpenJDK on RHEL uses system-wide timezone data files as a source for timezone information. Red Hat build of OpenJDK on RHEL uses system-wide CA certificates. Red Hat build of OpenJDK on Microsoft Windows includes the latest available timezone data from RHEL. Red Hat build of OpenJDK on Microsoft Windows uses the latest available CA certificates from RHEL. Additional resources See, Improve system FIPS detection (RHEL Planning Jira) See, Using system-wide cryptographic policies (RHEL documentation)

Commands:
5.9. Multipath Command Options Table 5.1, "Useful multipath Command Options" describes some options of the multipath command that you may find useful. Table 5.1. Useful multipath Command Options Option Description -l Display the current multipath configuration gathered from sysfs and the device mapper. -ll Display the current multipath configuration gathered from sysfs , the device mapper, and all other available components on the system. -f device Remove the named multipath device. -F Remove all unused multipath devices. -w device (Red Hat Enterprise Linux 6.6 and later) Remove the wwid of the specified device from the wwids file. -W (Red Hat Enterprise Linux 6.6 and later) Reset the wwids file to include only the current multipath devices.

Commands:
15.2. Applying Custom Object Classes to New User Entries User and group accounts are created with a predefined set of LDAP object classes applied to the entry. Any attributes which belong to the object class can be added to the user entry. While the standard and IdM-specific LDAP object classes will cover most deployment scenarios, administrators can create custom object classes with custom attributes. Note that after an administrator modifies the list of default object classes, new entries will contain the custom object classes but the old entries are not automatically modified. 15.2.1. From the Web UI Add all of the custom schema elements to the 389 Directory Server instance used by Identity Management. Adding schema elements is described in the schema chapter of the Directory Server Administrator's Guide . Open the IPA Server tab. Select the Configuration subtab. Scroll to the User Options area. Figure 15.1. User Options in Server Configuration At the bottom of the users area, click Add to include a new field for another object class. Important Always include the existing default object classes when the configuration is updated. Otherwise, the current settings will be overwritten. If any object classes required by Identity Management are not included, then subsequent attempts to add an entry will fail with object class violations. Figure 15.2. Changing Default User Object Classes When the changes are complete, click Save at the top of the Configuration page. 15.2.2. From the Command Line Add all of the custom schema elements to the 389 Directory Server instance used by Identity Management. Adding schema elements is described in the schema chapter of the Directory Server Administrator's Guide . Add the new object class to the list of object classes added to entries. The option for user object classes is --userobjectclasses . Important Always include the existing default object classes when the configuration is updated. Otherwise, the current settings will be overwritten. If any object classes required by Identity Management are not included, then subsequent attempts to add an entry will fail with object class violations. All object classes must be included in the list of object classes. The information passed with the config-mod command overwrites the values. This can be done by specifying each object class with a --userobjectclasses argument or by listing all of the object classes in a comma-separated list inside curly braces with no spaces allowed, such as {attr1,attr2,attr3} . Especially for long lists, it can be easier to use the curly braces than multiple options. For example: Note To use the curly braces option, the brace expansion feature must be switched on. To activate the feature, use the set command:

Commands:
[bjensen@server ~]USD ipa config-mod --userobjectclasses= {top,person,organizationalperson,inetorgperson,inetuser,posixaccount,krbprincipalaux,krbticketpolicyaux,ipaobject,ipasshuser, employeeinfo }
set -o braceexpand
4.169. mailcap 4.169.1. RHBA-2011:1118 - mailcap bug fix update An updated mailcap package that fixes one bug is now available for Red Hat Enterprise Linux 6. The mailcap package contains the mailcap file, which is used by the metamail program. Metamail reads the mailcap file to determine how it should display non-text or multimedia material. mailcap associates a particular type of file with a particular program that a mail agent or other program can call in order to handle the file. Mailcap should be installed to allow certain programs to be able to handle non-text files. Bug Fix BZ# 610793 Prior to this update, the mime.types database did not contain the WebM MIME type (video/webm). The problem has been resolved in this update by including the MIME type in the database. All users of mailcap are advised to upgrade to this updated package, which fixes this bug.

Commands:
Chapter 7. Security fixes Cryostat 2.0 includes security fixes that improve upon security offered from the release of Cryostat. Review each security fix for its description. jsoup Java library The jsoup Java library that is pre-installed with Cryostat 2.0 now upgraded from version 1.13.1 to version 1.14.2. This new version improves upon the jsoup Java library's handling of HTML and XML syntax. Addtional resources For more information about the bug fixes associated with the jsoup 1.14.2 release, see jsoup Java HTML Parser release 1.14.2 on the jsoup documentation website. Revised on 2022-11-25 08:58:08 UTC

Commands:
3.8. Aggressive Link Power Management Aggressive Link Power Management (ALPM) is a power-saving technique that helps the disk save power by setting a SATA link to the disk to a low-power setting during idle time (that is when there is no I/O). ALPM automatically sets the SATA link back to an active power state once I/O requests are queued to that link. Power savings introduced by ALPM come at the expense of disk latency. As such, you should only use ALPM if you expect the system to experience long periods of idle I/O time. ALPM is only available on SATA controllers that use the Advanced Host Controller Interface (AHCI). For more information about AHCI, see http://www.intel.com/technology/serialata/ahci.htm . When available, ALPM is enabled by default. ALPM has three modes: min_power This mode sets the link to its lowest power state (SLUMBER) when there is no I/O on the disk. This mode is useful for times when an extended period of idle time is expected. medium_power This mode sets the link to the second lowest power state (PARTIAL) when there is no I/O on the disk. This mode is designed to allow transitions in link power states (for example during times of intermittent heavy I/O and idle I/O) with as small impact on performance as possible. medium_power mode allows the link to transition between PARTIAL and fully-powered (that is "ACTIVE") states, depending on the load. Note that it is not possible to transition a link directly from PARTIAL to SLUMBER and back; in this case, either power state cannot transition to the other without transitioning through the ACTIVE state first. max_performance ALPM is disabled; the link does not enter any low-power state when there is no I/O on the disk. To check whether your SATA host adapters actually support ALPM you can check if the file /sys/class/scsi_host/host*/link_power_management_policy exists. To change the settings simply write the values described in this section to these files or display the files to check for the current setting. Important Setting ALPM to min_power or medium_power will automatically disable the "Hot Plug" feature.

Commands:
Chapter 3. Defining sequential actions in ITSM integration using order processes Order processes are the primary Automation Services Catalog feature by which you integrate user-ordered products with your ITSM system. Order processes are comprised of products in Automation Services Catalog that are intended to execute job templates that perform actions in your ITSM system. These processes are comprised of Before order and After order actions. You define your order processes as those products designed to run before and after a product your users order, so that information is passed across the sequence of orders. Example sequence before order - a product that creates a ticket in the ITSM system. product order - a web server. after order - a product that closes the ticket in the ITSM system. You define the sequence and what products are run by creating an order process that you apply to either your products or at the portfolio level. For this example workflow, we need to create a order processes and attach them to our before order , product order , and after order . 3.1. Creating an order process As a catalog administrator, create order processes to allow you to execute your Ansible Tower playbooks before and after a product is ordered. Prerequisites To create an order process with your Ansible Tower playbooks, you must have an Ansible Tower cluster added as a source. Procedure Select Order Processes from the main navigation. Click Create . Provide an order process name and description. From the drop-down menus, select actions that will occur before and after an order provision. Note The drop-down menus will display playbooks pulled from your Ansible Tower source. Only one Before and After action is supported for each order process. Review the new Order Process details, then click Create . 3.2. Setting an order process for a product Set an order process that will apply to a single product. Procedure Select Products from the main navigation, then select a product. Click More actions and select Set order processes . Expand the drop-down menu and select an order process. Note Ansible Automation Platform currently only supports one order process per product provision. Click Save .

Commands:
8.172. perl-Authen-SASL 8.172.1. RHBA-2014:0641 - perl-Authen-SASL bug fix update An updated perl-Authen-SASL package that fixes one bug is now available for Red Hat Enterprise Linux 6. Simple Authentication and Security Layer (SASL) is a generic mechanism for authentication used by several network protocols. The Authen::SASL module provides an implementation framework that all protocols should be able to share. Bug Fix BZ# 965739 Due to a bug in the Authen::SASL Perl module, the substr() function attempted to read data outside of the appropriate string. As a consequence, when the user was authenticated against an LDAP server over SASL, performing logical operations, such as search, with a Perl program on that server failed. With this update, the Authen::SASL module verifies the length of the string that is encrypted and written to a filehandle. As a result, performing a search returns correct results in the described situation. Users of perl-Authen-SASL are advised to upgrade to this updated package, which fixes this bug.

Commands:
Chapter 2. Updating a model Red Hat Enterprise Linux AI allows you to upgrade LLMs that you locally downloaded to the latest version of the model. Table 2.1. RHEL AI version 1.4 LLM support Feature Description Version introduced NVIDIA AMD granite-8b-starter Granite student model for customizing and fine-tuning 1.3 Generally available Technology preview granite-8b-redhat-lab Granite model for inference serving 1.3 Generally available Technology preview granite-8b-lab-v2-preview Preview of the version 2 8b Granite model for inference serving 1.3 Technology preview Technology preview granite-3.1-8b-starter-v1 Version 1 of the Granite 3.1 base model for customizing and fine-tuning 1.4 Generally available Technology preview granite-3.1-8b-lab-v1 Version 1 of the Granite 3.1 model for inference serving 1.4 Generally available Technology preview 2.1. Updating the models You can upgrade your local models to the latest version of the model using the RHEL AI tool set. Prerequisites You installed the InstructLab tools with the bootable container image. You initialized InstructLab and can use the ilab CLI. You downloaded LLMs on Red Hat Enterprise Linux AI. You created a Red Hat registry account and logged in on your machine. Procedure You can upgrade any model by running the following command. USD ilab model download --repository <repository_and_model> --release latest where: <repository_and_model> Specifies the repository location of the model as well as the model. You can access the models from the registry.redhat.io/rhelai1/ repository. <release> Specifies the version of the model. Set to latest , or a specific version of the model, for the most up to date version of the model. Verification You can view all the downloaded models on your system with the following command: USD ilab model list

Commands:
ilab model download --repository <repository_and_model> --release latest
ilab model list
Appendix C. Revision History Revision History Revision 8.1-1 Fri Feb 28 2020 Steven Levine Document version for 7.8 Beta publication. Revision 7.1-1 Wed Aug 7 2019 Steven Levine Document version for 7.7 GA publication. Revision 6.1-1 Thu Oct 4 2018 Steven Levine Document version for 7.6 GA publication. Revision 5.1-2 Thu Mar 15 2018 Steven Levine Document version for 7.5 GA publication. Revision 5.1-0 Thu Dec 14 2017 Steven Levine Document version for 7.5 Beta publication. Revision 4.1-9 Tue Oct 17 2017 Steven Levine Updated version for 7.4. Revision 4.1-5 Wed Jul 19 2017 Steven Levine Document version for 7.4 GA publication. Revision 4.1-2 Wed May 10 2017 Steven Levine Preparing document for 7.4 Beta publication. Revision 3.1-10 Tue May 2 2017 Steven Levine Update to version for 7.3 GA publication. Revision 3.1-4 Mon Oct 17 2016 Steven Levine Version for 7.3 GA publication. Revision 3.1-3 Wed Aug 17 2016 Steven Levine Preparing document for 7.3 Beta publication. Revision 2.1-8 Mon Nov 9 2015 Steven Levine Preparing document for 7.2 GA publication Revision 2.1-5 Mon Aug 24 2015 Steven Levine Preparing document for 7.2 Beta publication. Revision 1.1-9 Mon Feb 23 2015 Steven Levine Version for 7.1 GA release Revision 1.1-7 Thu Dec 11 2014 Steven Levine Version for 7.1 Beta release Revision 0.1-41 Mon Jun 2 2014 Steven Levine Version for 7.0 GA release Revision 0.1-2 Thu May 16 2013 Steven Levine First printing of initial draft

Commands:
4.8. Configuring Red Hat Satellite Errata Management for a Virtual Machine In the Administration Portal, you can configure a virtual machine to display the available errata. The virtual machine needs to be associated with a Red Hat Satellite server to show available errata. Red Hat Virtualization 4.3 supports errata management with Red Hat Satellite 6.5. Prerequisites The host on which the virtual machine runs needs to be configured to receive errata information from Satellite. For more information, see Configuring Satellite Errata Management for a Host in the Administration Guide . The virtual machine must have the ovirt-guest-agent package installed. This package allows the virtual machine to report its host name to the Red Hat Virtualization Manager. This allows the Red Hat Satellite server to identify the virtual machine as a content host and report the applicable errata. For more information on installing the ovirt-guest-agent package see the following topics: Section 2.4.2, "Installing the Guest Agents and Drivers on Red Hat Enterprise Linux" for Red Hat Enterprise Linux virtual machines Section 3.3.2, "Installing the Guest Agents, Tools, and Drivers on Windows" for Windows virtual machines The virtual machine must be registered to the Satellite server as a content host and have the katello-agent package installed. For information on how to configure a host registration and how to register a host and install the katello-agent package see Registering Hosts in the Red Hat Satellite document Managing Hosts . Important Virtual machines are identified in the Satellite server by their FQDN. This ensures that an external content host ID does not need to be maintained in Red Hat Virtualization. Procedure To configure Red Hat Satellite errata management: Click Compute Virtual Machines and select a virtual machine. Click Edit . Click the Foreman/Satellite tab. Select the required Satellite server from the Provider drop-down list. Click OK .

Commands:
Chapter 1. Introduction to patching and upgrading 1.1. Patching and upgrading JBoss EAP Major upgrades A major upgrade or migration is required when an application is moved from one major release to another, for example, from JBoss EAP 6.4 to JBoss EAP 7.0. If an application follows the Jakarta specifications, does not access deprecated APIs, and does not contain proprietary code, you might be able to run the application in JBoss EAP 7 without any code changes. However, the server configuration has changed in JBoss EAP 7 and requires migration. This type of migration is addressed in the JBoss EAP Migration Guide . Minor updates JBoss EAP periodically provides point releases, which are minor updates that include bug fixes, security fixes, and new features. Information about the changes made in a point release are documented in the JBoss EAP Migration Guide and in the 7.4.0 Release Notes . You can use the JBoss Server Migration Tool to automatically upgrade from one point release to another, for example, from JBoss EAP 7.4.0 to JBoss EAP 7.4.1 For information about how to configure and run the JBoss Server Migration Tool, see Using the JBoss Server Migration Tool . If you prefer, you can perform a manual upgrade of the server configuration. Instructions on how to perform a manual upgrade are documented in this guide. For more information, see Upgrading JBoss EAP . Cumulative patches JBoss EAP also periodically provides cumulative patches that contain bug and security fixes. Cumulative patches increment the release by the last digit, for example, from 7.4.0 to 7.4.1. Patch installation is addressed in the Patching JBoss EAP chapter of this guide.

Commands:
Part I. Managing and monitoring KIE Server As a system administrator, you can install, configure, and upgrade Red Hat Process Automation Manager for production environments, quickly and easily troubleshoot system failures, and ensure that systems are running optimally. Prerequisites Red Hat JBoss Enterprise Application Platform 7.4 is installed. For more information, see Red Hat JBoss Enterprise Application Platform 7.4 Installation Guide . Red Hat Process Automation Manager is installed. For more information, see Planning a Red Hat Process Automation Manager installation . Red Hat Process Automation Manager is running and you can log in to Business Central with the admin role. For more information, see Planning a Red Hat Process Automation Manager installation . Note For information about managing and monitoring business processes that run on KIE Server, see Managing and monitoring business processes in Business Central .

Commands:
Chapter 3. Using Spring Session 3.1. Enabling Spring Session Support Data Grid Spring Session support is built on SpringRemoteCacheManager and SpringEmbeddedCacheManager . The Data Grid starter produces those beans by default. Procedure Add this starter to your project. Add Spring Session to the classpath. Add the following annotations to your configuration: @EnableCaching @EnableInfinispanRemoteHttpSession @EnableInfinispanEmbeddedHttpSession Note Data Grid does not provide a default cache. To use Spring Session, you must first create a Data Grid cache.

Commands: