mtpti5iD/redhat-docs_dataset huggingface dataset:
8.234. system-config-kdump 8.234.1. RHBA-2014:1529 - system-config-kdump bug fix update An updated system-config-kdump package that fixes several bugs is now available for Red Hat Enterprise Linux 6. The system-config-kdump tool is a graphical utility used to configure kernel crash dumping via the kdump and kexec utilities. Bug Fixes BZ# 962724 On the IBM System z architecture, the system-config-kdump utility updated bootloader settings only when the kdump service was already running. However, since system-config-kdump does not run when kdump is disabled, it was impossible to enable kdump on the IBM System z architecture. With this update, the bootloader configuration updates regardless of the status of the kdump service, and the kdump feature can now be enabled on this architecture using the system-config-kdump interface. BZ# 1017611 Prior to this update, the drop-down list of raw devices in the system-config-kdump interface incorrectly included partitions that were already in use. As a consequence, users could choose these partitions as the targets for copying the kdump file, which in turn corrupted the file system. With this update, the system-config-kdump interface only lists unused partitions in the list of raw devices, and it is therefore no longer possible for kdump to cause files system corruption in the described scenario. BZ# 987681 Previously, the kdump parser of kernel parameters did not properly handle entries that contain quoted strings. As a consequence, modifying boot options via system-config-kdump on a system that used quoted strings in the kernel parameters could lead to the system failing to boot. With this update, the parser correctly accounts for quoted strings and kernel parameters with quoted strings are now handled properly. BZ# 1030533 Prior to this update, the automatic kdump memory thresholds in system-config-kdump did not match their respective values in the kernel. Consequently, selecting the "Automated kdump memory setting" option in the system-config-kdump interface on some systems disabled kdump. The memory thresholds in system-config-kdump have been updated to reflect those in the kernel, and on systems with sufficient memory, "Automated kdump memory settings" no longer disables kdump. However, on systems with not enough memory, this option is disabled and the memory for kdump has to be configured manually. BZ# 977981 Previously, system-config-kdump used an incorrect path to bootloader configuration on EFI systems using the GRUB bootloader on AMD64 and Intel 64 architectures. Consequently, it was not possible to configure kdump memory on these systems. This update adds the correct path to the list of known bootloader configuration paths, and it is now possible to configure kdump memory in the described circumstances. Users of system-config-kdump are advised to upgrade to this updated package, which fixes these bugs.

Commands:
2.5. Document Overview This remainder of this document includes the following chapters: Chapter 3, LVM Components describes the components that make up an LVM logical volume. Chapter 4, LVM Administration Overview provides an overview of the basic steps you perform to configure LVM logical volumes, whether you are using the LVM Command Line Interface (CLI) commands or the LVM Graphical User Interface (GUI). Chapter 5, LVM Administration with CLI Commands summarizes the individual administrative tasks you can perform with the LVM CLI commands to create and maintain logical volumes. Chapter 6, LVM Configuration Examples provides a variety of LVM configuration examples. Chapter 7, LVM Troubleshooting provides instructions for troubleshooting a variety of LVM issues. Chapter 8, LVM Administration with the LVM GUI summarizes the operating of the LVM GUI. Appendix A, The Device Mapper describes the Device Mapper that LVM uses to map logical and physical volumes. Appendix B, The LVM Configuration Files describes the LVM configuration files. Appendix D, LVM Object Tags describes LVM object tags and host tags. Appendix E, LVM Volume Group Metadata describes LVM volume group metadata, and includes a sample copy of metadata for an LVM volume group.

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

Commands:
Chapter 7. Network Time Protocol You need to ensure that systems within your Red Hat OpenStack Platform cluster have accurate and consistent timestamps between systems. Red Hat OpenStack Platform on Red Hat Enterprise Linux 8 supports Chrony for time management. For more information, see Using the Chrony suite to configure NTP . 7.1. Why consistent time is important Consistent time throughout your organization is important for both operational and security needs: Identifying a security event Consistent timekeeping helps you correlate timestamps for events on affected systems so that you can understand the sequence of events. Authentication and security systems Security systems can be sensitive to time skew, for example: A kerberos-based authentication system might refuse to authenticate clients that are affected by seconds of clock skew. Transport layer security (TLS) certificates depend on a valid source of time. A client to server TLS connection fails if the difference between client and server system times exceeds the Valid From date range. Red Hat OpenStack Platform services Some core OpenStack services are especially dependent on accurate timekeeping, including High Availability (HA) and Ceph. 7.2. NTP design Network time protocol (NTP) is organized in a hierarchical design. Each layer is called a stratum. At the top of the hierarchy are stratum 0 devices such as atomic clocks. In the NTP hierarchy, stratum 0 devices provide reference for publicly available stratum 1 and stratum 2 NTP time servers. Do not connect your data center clients directly to publicly available NTP stratum 1 or 2 servers. The number of direct connections would put unnecessary strain on the public NTP resources. Instead, allocate a dedicated time server in your data center, and connect the clients to that dedicated server. Configure instances to receive time from your dedicated time servers, not the host on which they reside. Note Service containers running within the Red Hat OpenStack Platform environment still receive time from the host on which they reside.

Commands:
Chapter 3. Red Hat build of OpenJDK features The latest Red Hat build of OpenJDK 17 release might include new features. Additionally, the latest release might enhance, deprecate, or remove features that originated from Red Hat build of OpenJDK 17 releases. Note For all the other changes and security fixes, see OpenJDK 17.0.7 Released . Red Hat build of OpenJDK enhancements Red Hat build of OpenJDK 17 provides enhancements to features originally created in releases of Red Hat build of OpenJDK. Certigna (Dhimyotis) root certificate authority (CA) certificate added In release Red Hat build of OpenJDK 17.0.7, the cacerts truststore includes the Certigna (Dhimyotis) root certificate: Name: Certigna (Dhimyotis) Alias name: certignarootca Distinguished name: CN=Certigna, O=Dhimyotis, C=FR See JDK-8245654 (JDK Bug System) . New Java Flight Recorder (JFR) event jdk.InitialSecurityProperty With Red Hat build of OpenJDK 17.0.7, the initial security properties that the java.security.Security class loads are now accessible in the new JFR event, jdk.InitialSecurityProperty . The jdk.InitialSecurityProperty event contains the following two fields: Key: The security property key. Value: The corresponding security property value. By using this new event and the existing jdk.SecurityPropertyModification event, you can now monitor security properties throughout their lifecycle. In this release, you can also print initial security properties to the standard error output stream when the -Djava.security.debug=properties property is passed to the Java virtual machine. See JDK-8292177 (JDK Bug System) . Error thrown if java.security file fails to load In releases, if Red Hat build of OpenJDK could not load the java.security file, a hard-coded set of security properties was used. This set of properties was not fully maintained and it was unclear to the user when they were being used. Now, with Red Hat build of OpenJDK 17.0.7, if Red Hat build of OpenJDK cannot load the java.security file, Red Hat build of OpenJDK displays an InternalError error message. See JDK-8155246 (JDK Bug System) . listRoots method returns all available drives on Windows In releases, the java.io.File.listRoots() method on Windows systems filtered out any disk drives that were not accessible or did not have media loaded. However, this filtering led to observable performance issues. With release Red Hat build of OpenJDK 17.0.7, the listRoots method returns all available disk drives unfiltered. See JDK-8208077 (JDK Bug System) . Enhanced Swing platform support In earlier releases of Red Hat build of OpenJDK, HTML object tags rendered embedded in Swing HTML components. With release Red Hat build of OpenJDK 17.0.7, rendering only occurs if you set the new system property swing.html.object to true. By default, the swing.html.object property is set to false. JDK bug system reference ID: JDK-8296832.

Commands:
Chapter 15. Integration Options Red Hat Single Sign-On (RH-SSO) is a single sign-on solution that you can use to secure your browser applications with your REST web services and Git access. When you integrate Red Hat Decision Manager with RH-SSO, you create an SSO and identity management (IDM) environment for Red Hat Decision Manager. The session management feature of RH-SSO enables you to use a single authentication for different Red Hat Decision Manager environments on the internet. The following chapters describe how you can integrate RH-SSO with Red Hat Decision Manager: Chapter 18, Authenticating Business Central through RH-SSO To authenticate Red Hat Decision Manager through an RH-SSO server, you must secure both the Red Hat Decision Manager web client (Business Central) and remote services through RH-SSO.This integration enables you to connect to Red Hat Decision Manager through RH-SSO using either Business Central or a remote service consumer. Chapter 19, Authenticating KIE Server through RH-SSO To authenticate KIE Server through an RH-SSO server, you must secure the remote services provided by KIE Server. Doing this enables any remote Red Hat Decision Manager service consumer (user or a service) to authenticate through RH-SSO. Note that KIE Server does not have a web interface. Chapter 20, Authenticating third-party clients through RH-SSO If Business Central or KIE Server are using RH-SSO, third-party clients must authenticate themselves using RH-SSO. After authentication, they can consume the remote service endpoints provided by Business Central and KIE Server, such as the REST API or remote file system services. To facilitate LDAP integration with Red Hat Decision Manager, consider using RH-SSO with LDAP. For information, see the "LDAP and Active Directory" section of the Red Hat Single Sign-On Server Administration Guide .

Commands:
Chapter 2. Build strategies You can use a curated set of build strategies or cluster build strategies on the OpenShift Container Platform cluster. The Builds for Red Hat OpenShift Operator automatically installs these strategies for use. This automated installation of strategies helps you to quickly get started with Builds. Builds supports the following cluster build strategies: buildah : Supported on all platforms source-to-image : Supported on the linux/amd64 platform Note The buildpacks build strategy is currently in Developer Preview . For more information, see the buildpacks example . 2.1. Buildah The buildah cluster build strategy uses a Dockerfile to build a container image and pushes it to the target registry. You must specify the Dockerfile in the spec.paramValues field of the Build CR. You can share the buildah strategy across different namespaces within your cluster because the Builds for Red Hat OpenShift Operator installs the buildah strategy at cluster level. You can configure the following parameters for the buildah strategy: Table 2.1. Configuration parameters for buildah Name Type Description Default build-args array Key-value pair of the arguments required by the Dockerfile that is used during the build [] registries-block array List of registries that must be blocked [] registries-insecure array List of insecure registries with their fully qualified domain name (FQDN) [] registries-search array List of registries to search short name images ["registry.redhat.io", "quay.io"] dockerfile string Path of the Dockerfile that is used during the build "Dockerfile" storage-driver string Storage drivers that are used by buildah , such as overlay or vfs "vfs" Note For more information, see Configuring build strategies in the Additional resources section. 2.2. Source-to-image This build strategy is composed of source-to-image and buildah . You can use this strategy to generate a container file and prepare the application to build with a builder image. You must specify the builder image in the spec.paramValues field of the Build CR. You can share the source-to-image strategy across different namespaces within your cluster because the Builds for Red Hat OpenShift Operator installs the source-to-image strategy at cluster level. You can configure the following parameters for the source-to-image strategy: Table 2.2. Configuration parameters for source-to-image Name Type Description Default registries-block array List of registries that must be blocked [] registries-insecure array List of insecure registries with their FQDN [] registries-search array List of registries to search short name images ["registry.redhat.io", "quay.io"] builder-image string Location of the builder image that is used during the build NA storage-driver string Storage drivers that are used by source-to-image , such as overlay or vfs "vfs" 2.3. Additional resources Installing Builds by using the web console Installing Builds by using the CLI Configuring build strategies Creating a ShipwrightBuild resource by using the web console

Commands:
Chapter 37. Ad hoc and dynamic tasks You can use case management to carry out tasks ad hoc, rather than following a strict end-to-end process. You can also add tasks to a case dynamically during run time. Ad hoc tasks are defined in the case modeling phase. Ad hoc tasks that are not configured as AdHoc Autostart are optional and might not be used during a case. Therefore, they must be triggered by a signal event or by a Java API. Dynamic tasks are defined during the case execution and are not present in the case definition model. Dynamic tasks address specific needs that arise during the case. They can be added to the case and worked on at any time using a case application, as demonstrated in the Red Hat Process Automation Manager Showcase application. Dynamic tasks can also be added by Java and Remote API calls. Dynamic tasks can be user or service activities, while ad hoc tasks can be any type of task. For more information about task types, see "BPMN2 tasks in process designer" in Designing business processes using BPMN models . Dynamic processes are any reusable sub-process from a case project. Ad hoc nodes with no incoming connections are configured in the node's AdHoc Autostart property and are triggered automatically when the case instance is started. Ad hoc tasks are optional tasks that are configured in a case definition. Because they are ad hoc, they must be triggered in some way, usually by a signal event or Java API call.

Commands:
C.6. USB 3 / xHCI Support USB 3 (xHCI) USB host adapter emulation is supported in Red Hat Enterprise Linux 7.2 and above. All USB speeds are available, meaning any generation of USB device can be plugged into a xHCI bus. Additionally, no companion controllers (for USB 1 devices) are required. Note, however, that USB 3 bulk streams are not supported. Advantages of xHCI: Virtualization-compatible hardware design, meaning xHCI emulation requires less CPU resources than versions due to reduced polling overhead. USB passthrough of USB 3 devices is available. Limitations of xHCI: Not supported for Red Hat Enterprise Linux 5 guests. See Figure 16.19, "Domain XML example for USB3/xHCI devices" for a domain XML device example for xHCI devices.

Commands:
14.4. The (Non-transactional) CarMart Quickstart Using JBoss Enterprise Web Server The Carmart (non-transactional) quickstart is supported for JBoss Data Grid's Library Mode with the JBoss Enterprise Web Server container. Report a bug 14.4.1. Build and Deploy the CarMart Quickstart to JBoss Enterprise Web Server The following procedure provides directions to build and deploy the CarMart quickstart to the JBoss Enterprise Web Server. Prerequisites Prerequisites for this procedure are as follows: Ensure that the JBoss Data Grid and JBoss Enterprise Application Platform Maven repositories are installed and configured. For details, see Chapter 3, Install and Use the Maven Repositories Select JBoss Enterprise Web Server 2 (or better) for your application and install it. Procedure 14.4. Build the CarMart Quickstart to the Server (Library Mode) Start the Server Depending on your operating system, use the appropriate command from the following to start the first instance of your selected application server: For Linux users: For Windows users: Navigate to the Root Directory Open a command line and navigate to the root directory of this quickstart. Build and Deploy your Application Use the following command to build and deploy your application using Maven: Result The target war file ( target/ jboss-carmart.war ) is deployed to the running instance of the selected server. Report a bug 14.4.2. View the CarMart Quickstart Using JBoss Enterprise Web Server The following procedure outlines how to view the CarMart quickstart on the JBoss Enterprise Web Server: Prerequisite The CarMart quickstart must be built and deployed to be viewed. Procedure 14.5. View the CarMart Quickstart To view the application, use your browser to navigate to the following link: Report a bug 14.4.3. Remove the CarMart Quickstart from JBoss Enterprise Web Server The following procedure provides directions to remove an already deployed application from JBoss Enterprise Web Server. Procedure 14.6. Remove an Application from JBoss Enterprise Web Server To remove an application, use the following command from the root directory of this quickstart: Report a bug

Commands:
USDJBOSS_EWS_HOME/tomcat7/bin/catalina.sh run
USDJBOSS_EWS_HOME\tomcat7\bin\catalina.bat run
mvn -Plibrary-tomcat clean package tomcat:deploy
http://localhost:8080/jboss-carmart
mvn tomcat:undeploy -Plibrary-tomcat
10.4.6. Is Your RAM Not Being Recognized? Sometimes, the kernel does not recognize all of your memory (RAM). You can check this with the cat /proc/meminfo command. Verify that the displayed quantity is the same as the known amount of RAM in your system. If they are not equal, add the following line to the /boot/grub/grub.conf : Replace xx with the amount of RAM you have in megabytes. In /boot/grub/grub.conf , the above example would look similar to the following: Once you reboot, the changes made to grub.conf are reflected on your system. Once you have loaded the GRUB boot screen, type e for edit. You are presented with a list of items in the configuration file for the boot label you have selected. Choose the line that starts with kernel and type e to edit this boot entry. At the end of the kernel line, add where xx equals the amount of RAM in your system. Press Enter to exit edit mode. Once the boot loader screen has returned, type b to boot the system. Remember to replace xx with the amount of RAM in your system. Press Enter to boot.

Commands:
mem= xx M
NOTICE: You have a /boot partition. This means that all kernel paths are relative to /boot/ default=0 timeout=30 splashimage=(hd0,0)/grub/splash.xpm.gz title Red Hat Enterprise Linux Client (2.6.32.130.el6.i686) root (hd0,1) kernel /vmlinuz-(2.6.32.130.el6.i686 ro root=UUID=04a07c13-e6bf-6d5a-b207-002689545705 mem=1024M initrd /initrd-(2.6.32.130.el6.i686.img
mem= xx M
20.16.6.2. Block / character devices The host physical machine's block / character devices can be passed through to the guest virtual machine by using management tools to modify the domain xml hostdev element. Note that this is only possible with container based virtualization. ... <hostdev mode='capabilities' type='storage'> <source> <block>/dev/sdf1</block> </source> </hostdev> ... Figure 20.30. Devices - host physical machine device assignment block character devices An alternative approach is this: ... <hostdev mode='capabilities' type='misc'> <source> <char>/dev/input/event3</char> </source> </hostdev> ... Figure 20.31. Devices - host physical machine device assignment block character devices alternative 1 Another alternative approach is this: ... <hostdev mode='capabilities' type='net'> <source> <interface>eth0</interface> </source> </hostdev> ... Figure 20.32. Devices - host physical machine device assignment block character devices alternative 2 The components of this section of the domain XML are as follows: Table 20.14. Block / character device elements Parameter Description hostdev This is the main container for describing host physical machine devices. For block/character devices passthrough mode is always capabilities and type is block for a block device and char for a character device. source This describes the device as seen from the host physical machine. For block devices, the path to the block device in the host physical machine OS is provided in the nested block element, while for character devices the char element is used

Commands:
<hostdev mode='capabilities' type='storage'> <source> <block>/dev/sdf1</block> </source> </hostdev>
<hostdev mode='capabilities' type='misc'> <source> <char>/dev/input/event3</char> </source> </hostdev>
<hostdev mode='capabilities' type='net'> <source> <interface>eth0</interface> </source> </hostdev>