mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 19. Red Hat Enterprise Linux 7.5 for ARM Red Hat Enterprise Linux 7.5 for ARM introduces Red Hat Enterprise Linux 7.5 user space with an updated kernel, which is based on version 4.14 and is provided by the kernel-alt packages. The offering is distributed with other updated packages but most of the packages are standard Red Hat Enterprise Linux 7 Server RPMs. Installation ISO images are available on the Customer Portal Downloads page . For information about Red Hat Enterprise Linux 7.5 user space, see the Red Hat Enterprise Linux 7 documentation . For information regarding the version, refer to Red Hat Enterprise Linux 7.4 for ARM - Release Notes . The following packages are provided as Development Preview in this release: libvirt (Optional channel) qemu-kvm-ma (Optional channel) Note KVM virtualization is a Development Preview on the 64-bit ARM architecture, and thus is not supported by Red Hat. For more information, see the Virtualization Deployment and Administration Guide . Customers may contact Red Hat and describe their use case, which will be taken into consideration for a future release of Red Hat Enterprise Linux. 19.1. New Features and Updates Core Kernel This update introduces the qrwlock queue write lock for 64-bit ARM systems. The implementation of this mechanism improves performance and prevents lock starvation by ensuring fair handling of multiple CPUs competing for the global task lock. This change also resolves a known issue, which was present in earlier releases and which caused soft lockups under heavy load. Note that any kernel modules built for versions of Red Hat Enterprise Linux 7 for ARM (against the kernel-alt packages) must be rebuilt against the updated kernel. (BZ#1507568) Security USBGuard is now fully supported on 64-bit ARM systems The USBGuard software framework provides system protection against intrusive USB devices by implementing basic whitelisting and blacklisting capabilities based on device attributes. Using USBGuard on 64-bit ARM systems, previously available as a Technology Preview, is now fully supported.

Commands:
Chapter 5. Red Hat Decision Manager projects Red Hat Decision Manager projects contain the business assets that you develop in Red Hat Decision Manager and are assigned to a space (for example, MyProject within MySpace ). Projects also contain configuration files such as a Maven project object model file ( pom.xml ), which contains build, environment, and other information about the project, and a KIE module descriptor file ( kmodule.xml ), which contains the KIE Base and KIE Session configurations for the assets in the project.

Commands:
Chapter 4. Refining your view of systems in the advisor service The Systems view shows all of your systems that have the Insights client installed and reporting advisor data. The Systems list can be refined in the following ways. 4.1. Filter by name Search for the host or system name. 4.2. Sorting options Use the sorting arrows above the following columns to order your systems table: Name. Alphabetize by A to Z or Z to A. Number of recommendations. Order by the number of recommendations impacting each system. Last seen. Order by the number of minutes, hours, or days since an archive was last uploaded from the system to the advisor service. 4.3. Filtering systems by tags, SAP workloads, and groups in the advisor service Filter results in the advisor service UI by custom group tags, SAP workloads, and Satellite groups to quickly locate and view the systems you want to focus on. In the advisor service, access tag, workload, and group filters using the Filter results box, located in the upper left corner of the page in the Red Hat Insights for Red Hat Enterprise Linux application. The filter dropdown menu shows all of the tags associated with the account, allowing you to click one or more parameters by which to filter. To filter by tags in the advisor service, complete the following steps: Procedure Navigate to the Operations > Advisor > Systems page and log in if necessary. The Filter results box is in most views in the Red Hat Insights for Red Hat Enterprise Linux application and these procedures work anywhere you access Filter results . Click the arrow on the Filter results box and scroll to see the tags available for systems on this account. Select one or more tags to filter by SAP workloads, Satellite host group, or a custom group. Applied tags are visible to the Filter results box. View the filtered results throughout the advisor service. To remove the tag, click Clear filters . Additional resources To learn more about system-group tags in Insights for Red Hat Enterprise Linux, see chapter, System tags and groups .

Commands:
3.3. Deploy a VDB via File Deployment Prerequisites Red Hat JBoss Data Virtualization must be installed. Procedure 3.1. Deploy a VDB via File Deployment Copy your VDB into the deploy directory Copy your VDB file into the EAP_HOME /standalone/deployments directory. Create a marker file Create an empty marker file of the same name with extension .dodeploy in the same directory. For example, if your VDB name is enterprise.vdb , then the marker file name must be enterprise.vdb.dodeploy . Note This only works in standalone mode. For domain mode, you must use one of the other available methods.

Commands:
5.360. xinetd 5.360.1. RHBA-2012:1162 - xinetd bug fix update An updated xinetd package that fixes one bug is now available for Red Hat Enterprise Linux 6. Xinetd is a secure replacement for inetd, the Internet services daemon. Xinetd provides access control for all services based on the address of the remote host and/or on time of access, and can prevent denial-of-access attacks. Xinetd provides extensive logging, has no limit on the number of server arguments, and allows users to bind specific services to specific IP addresses on a host machine. Each service has its own specific configuration file for Xinetd; the files are located in the /etc/xinetd.d directory. Bug Fix BZ# 841916 Due to incorrect handling of a file descriptor array in the service.c source file, some of the descriptors remained open when xinetd was under heavy load. Additionally, the system log was filled with a large number of messages that took up a lot of disk space over time. This bug has been fixed in the code, xinetd now handles the file descriptors correctly and no longer fills the system log. All users of xinetd are advised to upgrade to this updated package, which fixes this bug. 5.360.2. RHBA-2012:0409 - xinetd bug fix update An updated xinetd package that fixes multiple bugs is now available for Red Hat Enterprise Linux 6. The xinetd daemon is a secure replacement for xinetd, the Internet services daemon. The xinetd daemon provides access control for all services based on the address of the remote host, on time of access, or both, and can prevent denial of service (DoS) attacks. Bug Fixes BZ# 694820 Under certain circumstances, the xinetd daemon could become unresponsive (for example, when trying to acquire an already acquired lock for writing to its log file) when an unexpected signal arrived. With this update, the daemon handles unexpected signals correctly and no longer hangs under these circumstances. BZ# 697783 Previously, a bug in the xinetd code could cause corruption of the time_t variable resulting in the following compiler warning: A patch has been applied to address this issue, so that the warning no longer occurs. BZ# 697788 Previously, the xinetd daemon ignored the "port" line of the service configuration file, and it was therefore impossible to bind certain RPC services to a specific port. The underlying source code has been modified to ensure that xinetd honors the "port" line, so that the port numbers are now handled appropriately. BZ# 711787 Incorrect use of the realloc() function could cause memory corruption. This resulted in the xinetd daemon terminating unexpectedly right after the start when a large number of services had been configured. The realloc() function has been removed, which ensures that memory corruption no longer occurs in this scenario, and the xinetd daemon starts successfully even when configuring a large number of services. All users of xinetd are advised to upgrade to this updated package, which fixes these bugs.

Commands:
warning: dereferencing type-punned pointer will break strict-aliasing rules
Red Hat build of Eclipse Vert.x 4.3.7 - Planned End of Life The Red Hat build of Eclipse Vert.x 4.3.7 is the last supported release that Red Hat plans to provide. The full support ends on May 31, 2023. See the product life cycle page for details. Red Hat will continue to deliver security and bug fixes for Red Hat build of Eclipse Vert.x with 4.3.x releases until the product end of life. You can migrate Eclipse Vert.x applications to the Red Hat build of Quarkus. Red Hat build of Quarkus Quarkus is a Kubernetes-native Java framework tailored for JVM and native compilation, created using the best Java libraries and standards. It provides an effective solution for running Java applications in environments such as serverless, microservices, containers, Kubernetes, FaaS, or the cloud. The reactive capabilities of Quarkus use Eclipse Vert.x internally, and you can reuse Eclipse Vert.x applications in Quarkus. Therefore, migration of Eclipse Vert.x applications to Quarkus is the recommended option. See the Quarkus product page and documentation for more information. We will create resources to help you with the migration process.

Commands:
Chapter 6. Known Issues SB-1165 : Database application fails to run because org.apache.tomcat.jdbc.pool.DataSource can not be found. ENTSBT-1211 : A running service does not automatically recover after a short time, as it should, after pressing the Stop Service button in the Health Check Spring Boot Example. ENTSBT-1243 : The provided hibernate-core version is not compatible with Spring Boot 2.7. ENTSBT-1258 : jakarta.xml.bind-api-2.3.3.redhat-00001-sources.jar file, which is a dependency for Dekorate 2.11.5, is not brought in. ENTSBT-1261 : Running crud-example throws java.sql.SQLFeatureNotSupportedException exception. ENTSBT-1332 : Enabling pooledPreparedStatements causes a StackOverflowError on transaction timeout. ENTSBT-1354 : The Narayana Spring Boot starter includes spring-boot-starter version 2.7.2 . Use Maven version 3.8.5 to ensure that spring-boot.version is overridden as expected. When using a Maven version other than 3.8.5, if you specify the value of spring-boot.version by using mvn -Dspring-boot.version , the spring-boot-starter version is not always overridden.

Commands:
1.9. Expect the Unexpected While the phrase "expect the unexpected" is trite, it reflects an underlying truth that all system administrators must understand: There will be times when you are caught off-guard. After becoming comfortable with this uncomfortable fact of life, what can a concerned system administrator do? The answer lies in flexibility; by performing your job in such a way as to give you (and your users) the most options possible. Take, for example, the issue of disk space. Given that never having sufficient disk space seems to be as much a physical law as the law of gravity, it is reasonable to assume that at some point you will be confronted with a desperate need for additional disk space right now . What would a system administrator who expects the unexpected do in this case? Perhaps it is possible to keep a few disk drives sitting on the shelf as spares in case of hardware problems [2] . A spare of this type could be quickly deployed [3] on a temporary basis to address the short-term need for disk space, giving time to more permanently resolve the issue (by following the standard procedure for procuring additional disk drives, for example). By trying to anticipate problems before they occur, you will be in a position to respond more quickly and effectively than if you let yourself be surprised. [2] And of course a system administrator that expects the unexpected would naturally use RAID (or related technologies) to lessen the impact of a critical disk drive failing during production. [3] Again, system administrators that think ahead configure their systems to make it as easy as possible to quickly add a new disk drive to the system.

Commands:
8.8. Generating a New Unique MAC Address In some cases you will need to generate a new and unique MAC address for a guest virtual machine. There is no command line tool available to generate a new MAC address at the time of writing. The script provided below can generate a new MAC address for your guest virtual machines. Save the script on your guest virtual machine as macgen.py . Now from that directory you can run the script using ./macgen.py and it will generate a new MAC address. A sample output would look like the following: 8.8.1. Another Method to Generate a New MAC for Your Guest Virtual Machine You can also use the built-in modules of python-virtinst to generate a new MAC address and UUID for use in a guest virtual machine configuration file: The script above can also be implemented as a script file as seen below.

Commands:
./macgen.py 00:16:3e:20:b0:11
#!/usr/bin/python macgen.py script to generate a MAC address for guest virtual machines # import random # def randomMAC(): mac = [ 0x00, 0x16, 0x3e, random.randint(0x00, 0x7f), random.randint(0x00, 0xff), random.randint(0x00, 0xff) ] return ':'.join(map(lambda x: "%02x" % x, mac)) # print randomMAC()
echo 'import virtinst.util ; print virtinst.util.uuidToString(virtinst.util.randomUUID())' | python echo 'import virtinst.util ; print virtinst.util.randomMAC()' | python
#!/usr/bin/env python -*- mode: python; -*- print "" print "New UUID:" import virtinst.util ; print virtinst.util.uuidToString(virtinst.util.randomUUID()) print "New MAC:" import virtinst.util ; print virtinst.util.randomMAC() print ""
3.5.2. Disk Drives with MBR on UEFI Systems Systems with UEFI firmware require a disk with a GUID Partition Table (GPT). When installing Red Hat Enterprise Linux on a disk with a Master Boot Record (MBR; sometimes also called msdos ) label, the disk must be relabeled. This means you can not reuse existing partitions on a MBR-partitioned disk, and all data on the disk will be lost. Make sure to back up all data on the drive before installing Red Hat Enterprise Linux. A GUID Partition Table is only required on the system's boot drive - the disk where the boot loader is installed. Other drives can be labeled with a Master Boot Record and their partition layout can be reused. There are several ways to install Red Hat Enterprise Linux on an UEFI system and use a drive which has a Master Boot Record. You can: Attach the drive to an existing Linux system and use an utility such as parted or fdisk to create a GPT label on the drive. For example, to create a GPT label on disk /dev/sdc using parted , use the following command: Warning Make sure you specify the correct drive. Relabeling a disk will destroy all data on it, and parted will not ask you for a confirmation. Perform an automated Kickstart installation, and use the clearpart and zerombr commands. If your system uses UEFI firmware, using these commands on the boot drive will relabel it with a GPT. During a manual installation in the graphical user interface, when you get to the partitioning screen. Select an option other than custom partitioning (for example Use All Space ). Make sure to check the Review and modify partitioning layout check box, and click . On the following screen, modify the automatically created layout so it suits your needs. After you finish and click , Anaconda will use your layout and relabel the drive automatically.

Commands:
parted /dev/sdc mklabel gpt
Chapter 1. Supported upgrade paths The in-place upgrade replaces the RHEL 8 operating system on your system with a RHEL 9 version. Important It is not possible to perform an in-place upgrade directly from RHEL 7 to RHEL 9. However, you can perform an in-place upgrade from RHEL 7 to RHEL 8 and then perform a second in-place upgrade to RHEL 9. For more information, see Upgrading from RHEL 7 to RHEL 8 . Currently, it is possible to perform an in-place upgrade from the following source RHEL 8 minor versions to the following target RHEL 9 minor versions: Table 1.1. Supported upgrade paths System configuration Source OS version Target OS version RHEL RHEL 8.8 RHEL 9.2 RHEL 8.10 RHEL 9.4 RHEL 8.10 RHEL 9.5 RHEL with SAP HANA RHEL 8.8 RHEL 9.2 RHEL 8.10 RHEL 9.4 For more information about supported upgrade paths, see Supported in-place upgrade paths for Red Hat Enterprise Linux and the In-place upgrade Support Policy .

Commands:
15.2. Configure Lock Striping (Remote Client-Server Mode) Lock striping in Red Hat JBoss Data Grid's Remote Client-Server mode is enabled by setting the striping element to true . Example 15.1. Lock Striping (Remote Client-Server Mode) Note The default isolation mode for the Remote Client-Server mode configuration is READ_COMMITTED . If the isolation attribute is included to explicitly specify an isolation mode, it is ignored, a warning is thrown, and the default value is used instead. The locking element uses the following attributes: The acquire-timeout attribute specifies the maximum time to attempt a lock acquisition. The default value for this attribute is 10000 milliseconds. The concurrency-level attribute specifies the concurrency level for lock containers. Adjust this value according to the number of concurrent threads interacting with JBoss Data Grid. The default value for this attribute is 32 . The striping attribute specifies whether a shared pool of locks is maintained for all entries that require locking ( true ). If set to false , a lock is created for each entry. Lock striping controls the memory footprint but can reduce concurrency in the system. The default value for this attribute is false . Report a bug

Commands:
<locking acquire-timeout="20000" concurrency-level="500" striping="true" />
Chapter 11. Customizing the Developer Portal layout You can customize the look and feel of the entire Developer Portal to match your own branding. A standard CSS stylesheet is available to provide an easy starting point for your customizations. To create layout templates, use the code for Main layout as your starting point. In this tutorial, you'll add your own CSS customizations to your Developer Portal and reload it to put your new styling changes live. 11.1. Creating a new CSS file There is a default stylesheet, default.css . This is quite large and complex, so rather than extend it, it is better to create your own stylesheet for any of your own customizations to overwrite the defaults. You create a new stylesheet the same way you create a page. Remember to choose an appropriate MIME content type in the advanced page settings. Important Make sure that the selected layout is blank. Otherwise the page layout HTML will obscure the CSS rules. 11.2. Linking the stylesheet into your page layout Add the link to your custom CSS in each of your layout templates (or in a partial if you have a common HEAD section) after the link to bootstrap.css. For example: Now enjoy the beauty of your own unique branding! 11.3. Defining page layout templates The general idea is to define a separate layout for each of the different page styles in your portal. There is one standard layout called Main layout when you start. Do not make any changes to this layout until you are an expert at using the Developer Portal because this layout is used by all system-generated pages. Typically, you want a unique style for the home page of your portal. The Main layout template is a starting point for your customizations. To create a page layout template: Open Main layout and copy its code to the clipboard. Create a new layout, give it a title, a system name, and select Liquid enabled . Paste the Main layout code into your new layout. Remove the sidebar menu by deleting this line from your new layout: Customize the code to create your layout template.

Commands:
<link rel="stylesheet" href="/stylesheets/custom.css">
{% include 'submenu'%}
Preface Red Hat Enterprise Linux minor releases are an aggregation of individual enhancement, security and bug fix errata. The Red Hat Enterprise Linux 6.3 Release Notes documents the major changes made to the Red Hat Enterprise Linux 6 operating system and its accompanying applications for this minor release. Detailed notes on changes (that is, bugs fixed, enhancements added, and known issues found) in this minor release are available in the Technical Notes . The Technical Notes document also contains a complete list of all currently available Technology Previews along with packages that provide them. Important The online Red Hat Enterprise Linux 6.3 Release Notes , which are located online here , are to be considered the definitive, up-to-date version. Customers with questions about the release are advised to consult the online Release and Technical Notes for their version of Red Hat Enterprise Linux. Should you require information regarding the Red Hat Enterprise Linux life cycle, refer to https://access.redhat.com/support/policy/updates/errata/ .

Commands:
Chapter 2. Preparing to deploy multiple OpenShift Data Foundation storage clusters Before you begin the deployment of OpenShift Data Foundation using dynamic, local, or external storage, ensure that your resource requirements are met. See the Resource requirements section in the Planning guide. Things you should remember before installing multiple OpenShift Data Foundation storage clusters: openshift-storage and openshift-storage-extended are the exclusively supported namespaces. Internal storage cluster is restricted to the OpenShift Data Foundation operator namespace. External storage cluster is permissible in both operator and non-operator namespaces. Multiple storage clusters are not supported in the same namespace. Hence, the external storage system will not be visible under the OpenShift Data Foundation operator page as the operator is under openshift-storage namespace and the external storage system is not. Customers running external storage clusters in the operator namespace cannot utilize multiple storage clusters. Multicloud Object Gateway is supported solely within the operator namespace. It is ignored in other namespaces. RADOS Gateway (RGW) can be in either the operator namespace, a non-operator namespace, or both Network File System (NFS) is enabled as long as it is enabled for at least one of the clusters. Topology is enabled as long as it is enabled for at least one of the clusters. Topology domain labels are set as long as the internal cluster is present. The Topology view of the cluster is only supported for OpenShift Data Foundation internal mode deployments. Different multus settings are not supported for multiple storage clusters.

Commands:
Chapter 23. Apache CXF Binding IDs Table of Binding IDs Table 23.1. Binding IDs for Message Bindings Binding ID CORBA http://cxf.apache.org/bindings/corba HTTP/REST http://apache.org/cxf/binding/http SOAP 1.1 http://schemas.xmlsoap.org/wsdl/soap/http SOAP 1.1 w/ MTOM http://schemas.xmlsoap.org/wsdl/soap/http?mtom=true SOAP 1.2 http://www.w3.org/2003/05/soap/bindings/HTTP/ SOAP 1.2 w/ MTOM http://www.w3.org/2003/05/soap/bindings/HTTP/?mtom=true XML http://cxf.apache.org/bindings/xformat

Commands: