mtpti5iD/redhat-docs_dataset huggingface dataset:
5.3.3. /proc/driver/ This directory contains information for specific drivers in use by the kernel. A common file found here is rtc which provides output from the driver for the system's Real Time Clock (RTC) , the device that keeps the time while the system is switched off. Sample output from /proc/driver/rtc looks like the following: For more information about the RTC, refer to the following installed documentation: /usr/share/doc/kernel-doc- <version> /Documentation/rtc.txt .

Commands:
rtc_time : 16:21:00 rtc_date : 2004-08-31 rtc_epoch : 1900 alarm : 21:16:27 DST_enable : no BCD : yes 24hr : yes square_wave : no alarm_IRQ : no update_IRQ : no periodic_IRQ : no periodic_freq : 1024 batt_status : okay
Chapter 7. Modifying existing projects in Business Central Business Central includes a number of sample projects that you can use to get familiar with the product and its features. The sample projects have been designed and created to demonstrate a variety of business scenarios. You can modify the sample projects to meet your specific business needs. For example, Red Hat Decision Manager 7.13 contains the Mortgages sample project, which consists of predefined data objects, guided decision tables, guided rules, forms, and a business process. You can edit the sample to refine your business process. If none of the existing Business Central project samples align with your requirements, you can create a new project or import one from a Git repository. For more information, see Chapter 9, Importing projects from Git repositories . You can import any other project from Git. For example, a project that was developed in another Business Central instance.

Commands:
Chapter 8. Logging subsystem tuning You can further improve upon JBoss EAP logging subsystem performance in production environments by disabling logging to the console , configuring appropriate logging levels , and specifying the best location to store log files . Additional resources For more information on configuring the logging subsystem, see the logging chapter in the JBoss EAP Configuration Guide . 8.1. Disabling logging to the console Disabling console logging can improve JBoss EAP performance. Although outputting logs to the console can be useful in development and testing environments, for production environments, in most cases, it is not necessary. The JBoss EAP root logger includes a console log handler for all default standalone server profiles except standalone-full-ha . The default managed domain profiles do not include a console handler. Procedure To remove the default console handler from the root logger, use the following management CLI command: 8.2. Configuring logging levels For ideal performance, ensure that you configure the logging levels for your production environment appropriately. For example, although INFO or DEBUG levels might be appropriate for development or testing environments, in most cases you should set your production environment logging level to something higher, such as WARN or ERROR . Additional resources For details on setting log levels for different logging handlers, see Configuring log handlers in the JBoss EAP Configuration Guide . 8.3. Configuring the location of the log files You should consider the storage location of log files as a potential performance issue. If you save logs to a file system or disk configuration that has poor I/O throughput, it has the potential to affect the whole platform's performance. To prevent logging from impacting JBoss EAP performance, set your log locations to high-performance dedicated disks that have a lot of space. Additional resources For details on configuring log file locations for different logging handlers, see Configuring log handlers in the JBoss EAP Configuration Guide .

Commands:
/subsystem=logging/root-logger=ROOT:remove-handler(name=CONSOLE)
4.9. Configuring atime Updates Each file inode and directory inode has three time stamps associated with it: ctime - The last time the inode status was changed mtime - The last time the file (or directory) data was modified atime - The last time the file (or directory) data was accessed If atime updates are enabled as they are by default on GFS and other Linux file systems then every time a file is read, its inode needs to be updated. Because few applications use the information provided by atime , those updates can require a significant amount of unnecessary write traffic and file-locking traffic. That traffic can degrade performance; therefore, it may be preferable to turn off atime updates. Two methods of reducing the effects of atime updating are available: Mount with noatime Tune GFS atime quantum 4.9.1. Mount with noatime A standard Linux mount option, noatime , can be specified when the file system is mounted, which disables atime updates on that file system. Usage BlockDevice Specifies the block device where the GFS file system resides. MountPoint Specifies the directory where the GFS file system should be mounted. Example In this example, the GFS file system resides on the /dev/vg01/lvol0 and is mounted on directory /gfs1 with atime updates turned off.

Commands:
mount -t gfs BlockDevice MountPoint -o noatime
mount -t gfs /dev/vg01/lvol0 /gfs1 -o noatime
Chapter 2. Deploying Quarkus applications You can deploy your Quarkus application on OpenShift by using any of the the following build strategies: Docker build S2I Binary Source S2I For more details about each of these build strategies, see Chapter 1. OpenShift build strategies and Quarkus of the Deploying your Quarkus applications to OpenShift Container Platform guide. Note The OpenShift Docker build strategy is the preferred build strategy that supports Quarkus applications targeted for JVM as well as Quarkus applications compiled to native executables. You can configure the deployment strategy using the quarkus.openshift.build-strategy property.

Commands:
Preface Providing feedback on Red Hat documentation You can provide feedback or report an error by submitting the Create Issue form in Jira. The Jira issue will be created in the Red Hat Hybrid Cloud Infrastructure Jira project, where you can track the progress of your feedback. Ensure that you are logged in to Jira. If you do not have a Jira account, you must create a Red Hat Jira account . Launch the Create Issue form . Complete the Summary , Description , and Reporter fields. In the Description field, include the documentation URL, chapter or section number, and a detailed description of the issue. Click Create .

Commands:
Chapter 2. Multipath Devices Without DM-Multipath, each path from a server node to a storage controller is treated by the system as a separate device, even when the I/O path connects the same server node to the same storage controller. DM-Multipath provides a way of organizing the I/O paths logically, by creating a single multipath device on top of the underlying devices. 2.1. Multipath Device Identifiers Each multipath device has a World Wide Identifier (WWID), which is guaranteed to be globally unique and unchanging. By default, the name of a multipath device is set to its WWID. Alternately, you can set the user_friendly_names option in the multipath configuration file, which sets the alias to a node-unique name of the form mpath n . For example, a node with two HBAs attached to a storage controller with two ports via a single unzoned FC switch sees four devices: /dev/sda , /dev/sdb , dev/sdc , and /dev/sdd . DM-Multipath creates a single device with a unique WWID that reroutes I/O to those four underlying devices according to the multipath configuration. When the user_friendly_names configuration option is set to yes , the name of the multipath device is set to mpath n . When new devices are brought under the control of DM-Multipath, the new devices may be seen in three different places under the /dev directory: /dev/mapper/mpath n , /dev/mpath/mpath n , and /dev/dm- n . The devices in /dev/mapper are created early in the boot process. Use these devices to access the multipathed devices, for example when creating logical volumes. The devices in /dev/mpath are provided as a convenience so that all multipathed devices can be seen in one directory. These devices are created by the udev device manager and may not be available on startup when the system needs to access them. Do not use these devices for creating logical volumes or filesystems. Any devices of the form /dev/dm- n are for internal use only and should never be used. For information on the multipath configuration defaults, including the user_friendly_names configuration option, see see Section 4.3, "Configuration File Defaults" . You can also set the name of a multipath device to a name of your choosing by using the alias option in the multipaths section of the multipath configuration file. For information on the multipaths section of the multipath configuration file, see see Section 4.4, "Multipaths Device Configuration Attributes" .

Commands:
7.5. Add a Certificate to a Truststore Using Keytool Procedure 7.3. Add a Certificate to a Truststore Using Keytool Run the keytool -import -alias ALIAS -file public.cert -storetype TYPE -keystore server.truststore command: If the specified truststore already exists, enter the existing password for that truststore, otherwise enter a new password: Enter yes when prompted to trust the certificate: Result The certificate in public.cert has been added to the new truststore named server.truststore .

Commands:
keytool -import -alias teiid -file public.cert -storetype JKS -keystore server.truststore
Enter keystore password: <password>
Owner: CN=<user's name>, OU=<dept name>, O=<company name>, L=<city>, ST=<state>, C=<country> Issuer: CN=<user's name>, OU=<dept name>, O=<company name>, L=<city>, ST=<state>, C=<country> Serial number: 416d8636 Valid from: Fri Jul 31 14:47:02 CDT 2009 until: Sat Jul 31 14:47:02 CDT 2010 Certificate fingerprints: MD5: 22:4C:A4:9D:2E:C8:CA:E8:81:5D:81:35:A1:84:78:2F SHA1: 05:FE:43:CC:EA:39:DC:1C:1E:40:26:45:B7:12:1C:B9:22:1E:64:63 Trust this certificate? [no]: yes
Chapter 6. Performing post-upgrade tasks After you have upgraded your system to RHEL 8, complete especially the following tasks: Verify the state of the upgraded system. For a list of recommended steps, see the Verifying the post-upgrade state of the RHEL 8 system chapter in the Upgrading from RHEL 7 to RHEL 8 document. Perform major recommended tasks to ensure your system is supported. For a list of recommended steps, see the Performing post-upgrade tasks chapter in the Upgrading from RHEL 7 to RHEL 8 document. Re-evaluate and re-apply your security policies. For detailed instructions, see the Applying security policies section in the Upgrading from RHEL 7 to RHEL 8 document. Restore the default SELinux security contexts on the file system: Note that restoring the SELinux security contexts can be time-consuming on large file systems. Optionally, you can exclude large or remote file systems, by using the -e directory parameter. For further details, see the restorecon(8) man page on your system. Manually migrate applications that were not handled during the upgrade. This can apply both to applications available in the base RHEL and applications provided by Red Hat Software Collections , Red Hat Developer Toolset , or Red Hat Developer Tools . On a RHEL 8 host, a number of user space components are distributed as Application Streams. For information about using Application Streams, see the Installing, managing, and removing user-space components documentation. For migration instructions, see the RHEL 8 documentation on the Red Hat Customer Portal for the respective component, for example for databases, the Database servers chapter in the Deploying different types of servers documentation. Resolve potential problems with installed packages. For details, see Section 7.1, "Ensuring that installed packages match the current major RHEL version" .

Commands:
restorecon -Rv /
2.2.2. Features of GRUB GRUB contains several features that make it preferable to other boot loaders available for the x86 architecture. Below is a partial list of some of the more important features: GRUB provides a true command-based, pre-OS environment on x86 machines. This feature affords the user maximum flexibility in loading operating systems with specified options or gathering information about the system. For years, many non-x86 architectures have employed pre-OS environments that allow system booting from a command line. GRUB supports Logical Block Addressing (LBA) mode. LBA places the addressing conversion used to find files in the hard drive's firmware, and is used on many IDE and all SCSI hard devices. Before LBA, boot loaders could encounter the 1024-cylinder BIOS limitation, where the BIOS could not find a file after the 1024 cylinder head of the disk. LBA support allows GRUB to boot operating systems from partitions beyond the 1024-cylinder limit, so long as the system BIOS supports LBA mode. Most modern BIOS revisions support LBA mode. GRUB can read ext2 partitions. This functionality allows GRUB to access its configuration file, /boot/grub/grub.conf , every time the system boots, eliminating the need for the user to write a new version of the first stage boot loader to the MBR when configuration changes are made. The only time a user needs to reinstall GRUB on the MBR is if the physical location of the /boot/ partition is moved on the disk. For details on installing GRUB to the MBR, refer to Section 2.3, "Installing GRUB" .

Commands:
Chapter 3. Distribution selection Red Hat provides several distributions of Red Hat build of OpenJDK. This module helps you select the distribution that is right for your needs. All distributions of OpenJDK contain the JDK Flight Recorder (JFR) feature. This feature produces diagnostics and profiling data that can be consumed by other applications, such as JDK Mission Control (JMC). Red Hat build of OpenJDK RPMs for RHEL 8 RPM distributions of Red Hat build of OpenJDK 8, Red Hat build of OpenJDK 11, and Red Hat build of OpenJDK 11 for RHEL 8. Red Hat build of OpenJDK 8 JRE portable archive for RHEL Portable Red Hat build of OpenJDK 8 JRE archive distribution for RHEL 7 and 8 hosts. Red Hat build of OpenJDK 8 portable archive for RHEL Portable Red Hat build of OpenJDK 8 archive distribution for RHEL 7 and 8 hosts. Red Hat build of OpenJDK 11 JRE portable archive for RHEL Portable Red Hat build of OpenJDK 11 JRE archive distribution for RHEL 7 and 8 hosts. Red Hat build of OpenJDK 11 portable archive for RHEL Portable Red Hat build of OpenJDK 11 archive distribution for RHEL 7 and 8 hosts. Red Hat build of OpenJDK 11 JRE portable archive for RHEL Portable Red Hat build of OpenJDK 11 JRE archive distribution for RHEL 7 and 8 hosts. Red Hat build of OpenJDK 11 portable archive for RHEL Portable Red Hat build of OpenJDK 11 archive distribution for RHEL 7 and 8 hosts. Red Hat build of OpenJDK archive for Windows Red Hat build of OpenJDK 8, Red Hat build of OpenJDK 11, and Red Hat build of OpenJDK 11 distributions for all supported Windows hosts. Recommended for cases where multiple Red Hat build of OpenJDK versions may be installed on a host. This distribution includes the following: Java Web Start Mission Control Red Hat build of OpenJDK installers for Windows Red Hat build of OpenJDK 8, Red Hat build of OpenJDK 11, and Red Hat build of OpenJDK 11 MSI installers for all supported Windows hosts. Optionally installs Java Web Start and sets environment variables. Suitable for system wide installs of a single Red Hat build of OpenJDK version. Additional resources For more information about the JDK Flight Recorder (JFR), see Introduction to JDK Flight Recorder . For more information about the JDK Flight Recorder (JFR), see Introduction to JDK Mission Control . JDK Mission Control is available for RHEL with Red Hat Software Collections 3.2 . Revised on 2024-05-09 16:46:12 UTC

Commands:
19.5. Changing the Priority of Group Password Policies A user may belong to multiple groups, each with different password policies. Since only one policy can be in effect for a user, there has to be a method to assign precedence to policies. That is done through priority . The highest priority is zero (0). The lower the number, the higher the priority. This is set initially when the password policy is created. It can be modified after the policy is created by resetting the --priority option. When a user belongs to multiple groups, the group password policy with the lowest priority number has the highest priority.

Commands:
kinit admin ipa pwpolicy-mod examplegroup --priority=10
Appendix A. MSI-based installer properties The Red Hat build of OpenJDK for Windows MSI-based installer includes the JDK Files component and the following optional properties: Table A.1. Red Hat build of OpenJDK for Windows MSI-based installer properties Property Description Default value OpenJDK Runtime - Windows Registry Sets registry keys that other software can use to locate JDK installation files. Yes OpenJDK Runtime - Path Variable Adds the Runtime to the Path variable so it is available from the command line. Yes OpenJDK Runtime - JAVA_HOME System Variable JAVA_HOME is used by some programs to find the Java runtime. No OpenJDK Runtime - REDHAT_JAVA_HOME System Variable REDHAT_JAVA_HOME can be used by some programs to find the Red Hat build of OpenJDK runtime. No OpenJDK Runtime - Jar Files Association This enables Jar files to be run from within Windows Explorer. No Mission Control - Files Contains files that are installed in the <installdir> \missioncontrol directory. No Mission Control - Path Variable Appends <installdir> \missioncontrol to the system PATH environment variable. No Revised on 2024-05-03 15:37:58 UTC

Commands:
Integrating the Red Hat Hybrid Cloud Console with third-party applications Red Hat Hybrid Cloud Console 1-latest Configuring integrations between third-party tools and the Red Hat Hybrid Cloud Console Red Hat Customer Content Services

Commands:
<protocol>://http-inputs-<host>.splunkcloud.com:<port>
<protocol>://http-inputs.<host>.splunkcloud.com:<port>
https://http-inputs.myhost.splunkcloud.com:443
https://http-inputs-otherhost.splunkcloud.com:443
8.7. Install the ODBC Driver on Solaris Prerequisites Administrative permissions are required. Download the correct ODBC driver package ( jboss-dv-psqlodbc-[VERSION]-X.zip ) from https://access.redhat.com/jbossnetwork/ . Unzip the installation package Unzip the installation package to /opt directory. Set the PATH property so that the ODBC binaries are used from the directory where you have unzipped the driver. USD export PATH = USDPATH:/opt/redhat/jboss-dv/v6/psqlodbc/bin Set the ODBCINI environmental variable to match the existing odbc.ini. USD export ODBCINI=/opt/redhat/jboss-dv/v6/psqlodbc/etc/odbc.ini Note If you are using the Bourne Shell as your Solaris terminal, you can add the two export commands above to your ~/.profile file, so that you do not need to run them every time. Likewise, if you are using Bash, save them in your ~/.bash_profile file instead.

Commands:
Chapter 1. Installation options The following table presents the various Red Hat Update Infrastructure 4 components. Table 1.1. Red Hat Update Infrastructure components and functions Component Acronym Function Alternative Red Hat Update Appliance RHUA Downloads content from the Red Hat content delivery network and stores it on the shared storage None Content Delivery Server CDS Provides the yum repositories that clients connect to for the updated packages None HAProxy None Provides load balancing across CDS nodes Existing load balancing solution Shared storage None Provides shared storage Existing storage solution The following table describes how to perform installation tasks. Table 1.2. Red Hat Update Infrastructure installation tasks Installation Task Performed on Install RHEL 8 RHUA, CDS, and HAProxy Register the system with the RHUI consumer type RHUA Register the system with the default consumer type CDS and HAProxy Apply updates RHUA, CDS and HAProxy Install rhui-installer RHUA Run rhui-installer RHUA 1.1. Option 1: Full installation A RHUA with shared storage Two or more CDS nodes with this shared storage One or more HAProxy load-balancers 1.2. Option 2: Installation with an existing storage solution A RHUA with an existing storage solution Two or more CDS nodes with this existing storage solution One or more HAProxy load-balancers 1.3. Option 3: Installation with an existing load-balancer solution A RHUA with shared storage Two or more CDS nodes with this shared storage An existing load-balancer 1.4. Option 4: Installation with existing storage and load-balancer solutions A RHUA with an existing storage solution Two or more CDS nodes with this existing shared storage An existing load-balancer Important Red Hat Update Infrastructure must be used with at least two CDS nodes and a load-balancer node. Installation without any load-balancer node and with a single CDS node is unsupported. The following figure depicts a high-level view of how the various Red Hat Update Infrastructure 4 components interact. Figure 1.1. Red Hat Update Infrastructure 4 overview Install the RHUA and CDS nodes on separate x86_64 servers (bare metal or virtual machines). Ensure all the servers and networks that connect to RHUI can access the Red Hat Subscription Management service.

Commands:
Chapter 6. Disabling the Fuse Console You can disable the Fuse Console on JBoss EAP so that it becomes inaccessible to all users without affecting any other component. Procedure To disable the Fuse Console on JBoss EAP, do one of the following: Remove the Fuse Console deployment file: USDEAP_HOME/standalone/deployments/hawtio-wildfly-xxxxx.war Undeploy the Fuse Console by using the JBoss EAP admin console or command line interface.

Commands:
6.2.4. Creating the File System The following command creates a GFS2 file system on the logical volume. The following commands mount the logical volume and report the file system disk space usage.

Commands:
mkfs.gfs2 -plock_nolock -j 1 /dev/volgroup01/striped_logical_volume This will destroy any data on /dev/volgroup01/striped_logical_volume. Are you sure you want to proceed? [y/n] y Device: /dev/volgroup01/striped_logical_volume Blocksize: 4096 Filesystem Size: 492484 Journals: 1 Resource Groups: 8 Locking Protocol: lock_nolock Lock Table: Syncing All Done
mount /dev/volgroup01/striped_logical_volume /mnt df Filesystem 1K-blocks Used Available Use% Mounted on /dev/mapper/VolGroup00-LogVol00 13902624 1656776 11528232 13% / /dev/hda1 101086 10787 85080 12% /boot tmpfs 127880 0 127880 0% /dev/shm /dev/volgroup01/striped_logical_volume 1969936 20 1969916 1% /mnt
C. Revision History Revision History Revision 0-15.400 2013-10-31 Rudiger Landmann Rebuild with publican 4.0.0 Revision 0-15 2012-07-18 Anthony Towns Rebuild for Publican 3.0 Revision 1.0-0 Tue Dec 07 2010 Ryan Lerch Added Release Notes Updates for the General Availability (GA)

Commands:
C.2. Host Tags In a cluster configuration, you can define host tags in the configuration files. If you set hosttags = 1 in the tags section, a host tag is automatically defined using the machine's hostname. This allow you to use a common configuration file which can be replicated on all your machines so they hold identical copies of the file, but the behavior can differ between machines according to the hostname. For information on the configuration files, see Appendix B, The LVM Configuration Files . For each host tag, an extra configuration file is read if it exists: lvm_ hosttag. conf. If that file defines new tags, then further configuration files will be appended to the list of files to read in. For example, the following entry in the configuration file always defines tag1 , and defines tag2 if the hostname is host1 .

Commands:
tags { tag1 { } tag2 { host_list = ["host1"] } }