mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 4. Updating Red Hat build of OpenJDK 8 on RHEL The following sections provide instructions for updating Red Hat build of OpenJDK 8 on RHEL. 4.1. Updating Red Hat build of OpenJDK 8 on RHEL by using yum The installed Red Hat build of OpenJDK packages can be updated using the yum system package manager. Prerequisites You must have root privileges on the system. Procedure Check the current Red Hat build of OpenJDK version: A list of installed Red Hat build of OpenJDK packages displays. Update a specific package. For example: Verify that the update worked by checking the current Red Hat build of OpenJDK versions: Note If the output from the command shows that you have a different major version of Red Hat build of OpenJDK checked out on your system, you can enter the following command in your CLI to switch your system to use Red Hat build of OpenJDK 8: 4.2. Updating Red Hat build of OpenJDK 8 on RHEL by using an archive You can update Red Hat build of OpenJDK using the archive. This is useful if the Red Hat build of OpenJDK administrator does not have root privileges. Prerequisites Know the generic path pointing to your JDK or JRE installation. For example, ~/jdks/java-8 Procedure Remove the existing symbolic link of the generic path to your JDK or JRE. For example: Install the latest version of the JDK or JRE in your installation location. Additional resources For instructions on installing a JRE, see Installing a JRE on RHEL using an archive . For instructions on installing a JDK, see Installing Red Hat build of OpenJDK on RHEL using an archive . Revised on 2024-05-10 09:08:29 UTC

Commands:
sudo yum list installed "java*"
Installed Packages java-1.8.0-openjdk.x86_64 1:1.8.0.322.b06-2.el8_5 @rhel-8-for-x86_64-appstream-rpms java-11-openjdk.x86_64 1:11.0.14.0.9-2.el8_5 @rhel-8-for-x86_64-appstream-rpms java-17-openjdk.x86_64 1:17.0.2.0.8-4.el8_5 @rhel-8-for-x86_64-appstream-rpms
sudo yum update java-1.8.0-openjdk
java -version openjdk version "1.8.0_322" OpenJDK Runtime Environment (build 1.8.0_322-b06) OpenJDK 64-Bit Server VM (build 25.322-b06, mixed mode)
sudo update-alternatives --config 'java'
unlink ~/jdks/java-8
E.5. GRUB Terminology One of the most important things to understand before using GRUB is how the program refers to devices, such as hard drives and partitions. This information is particularly important when configuring GRUB to boot multiple operating systems. E.5.1. Device Names When referring to a specific device with GRUB, do so using the following format (note that the parentheses and comma are very important syntactically): ( <type-of-device><bios-device-number> , <partition-number> ) The <type-of-device> specifies the type of device from which GRUB boots. The two most common options are hd for a hard disk or fd for a 3.5 diskette. A lesser used device type is also available called nd for a network disk. Instructions on configuring GRUB to boot over the network are available online at http://www.gnu.org/software/grub/manual/ . The <bios-device-number> is the BIOS device number. The primary IDE hard drive is numbered 0 and a secondary IDE hard drive is numbered 1 . This syntax is roughly equivalent to that used for devices by the kernel. For example, the a in hda for the kernel is analogous to the 0 in hd0 for GRUB, the b in hdb is analogous to the 1 in hd1 , and so on. The <partition-number> specifies the number of a partition on a device. Like the <bios-device-number> , most types of partitions are numbered starting at 0 . However, BSD partitions are specified using letters, with a corresponding to 0 , b corresponding to 1 , and so on. Note The numbering system for devices under GRUB always begins with 0 , not 1 . Failing to make this distinction is one of the most common mistakes made by new users. To give an example, if a system has more than one hard drive, GRUB refers to the first hard drive as (hd0) and the second as (hd1) . Likewise, GRUB refers to the first partition on the first drive as (hd0,0) and the third partition on the second hard drive as (hd1,2) . In general the following rules apply when naming devices and partitions under GRUB: It does not matter if system hard drives are IDE or SCSI, all hard drives begin with the letters hd . The letters fd are used to specify 3.5 diskettes. To specify an entire device without respect to partitions, leave off the comma and the partition number. This is important when telling GRUB to configure the MBR for a particular disk. For example, (hd0) specifies the MBR on the first device and (hd3) specifies the MBR on the fourth device. If a system has multiple drive devices, it is very important to know how the drive boot order is set in the BIOS. This is a simple task if a system has only IDE or SCSI drives, but if there is a mix of devices, it becomes critical that the type of drive with the boot partition be accessed first.

Commands:
5.4.16.8.2. The warn RAID Fault Policy In the following example, the raid_fault_policy field has been set to warn in the lvm.conf file. The RAID logical volume is laid out as follows. If the /dev/sdh device fails, the system log will display error messages. In this case, however, LVM will not automatically attempt to repair the RAID device by replacing one of the images. Instead, if the device has failed you can replace the device with the --repair argument of the lvconvert command, as shown below. Note that even though the failed device has been replaced, the display still indicates that LVM could not find the failed device. This is because, although the failed device has been removed from the RAID logical volume, the failed device has not yet been removed from the volume group. To remove the failed device from the volume group, you can execute vgreduce --removemissing VG . If the device failure is a transient failure or you are able to repair the device that failed, as of Red Hat Enterprise Linux release 6.5 you can initiate recovery of the failed device with the --refresh option of the lvchange command. Previously it was necessary to deactivate and then activate the logical volume. The following command refreshes a logical volume.

Commands:
lvs -a -o name,copy_percent,devices my_vg LV Copy% Devices my_lv 100.00 my_lv_rimage_0(0),my_lv_rimage_1(0),my_lv_rimage_2(0) [my_lv_rimage_0] /dev/sdh1(1) [my_lv_rimage_1] /dev/sdf1(1) [my_lv_rimage_2] /dev/sdg1(1) [my_lv_rmeta_0] /dev/sdh1(0) [my_lv_rmeta_1] /dev/sdf1(0) [my_lv_rmeta_2] /dev/sdg1(0)
lvconvert --repair my_vg/my_lv /dev/sdh1: read failed after 0 of 2048 at 250994294784: Input/output error /dev/sdh1: read failed after 0 of 2048 at 250994376704: Input/output error /dev/sdh1: read failed after 0 of 2048 at 0: Input/output error /dev/sdh1: read failed after 0 of 2048 at 4096: Input/output error Couldn't find device with uuid fbI0YO-GX7x-firU-Vy5o-vzwx-vAKZ-feRxfF. Attempt to replace failed RAID images (requires full device resync)? [y/n]: y lvs -a -o name,copy_percent,devices my_vg Couldn't find device with uuid fbI0YO-GX7x-firU-Vy5o-vzwx-vAKZ-feRxfF. LV Copy% Devices my_lv 64.00 my_lv_rimage_0(0),my_lv_rimage_1(0),my_lv_rimage_2(0) [my_lv_rimage_0] /dev/sde1(1) [my_lv_rimage_1] /dev/sdf1(1) [my_lv_rimage_2] /dev/sdg1(1) [my_lv_rmeta_0] /dev/sde1(0) [my_lv_rmeta_1] /dev/sdf1(0) [my_lv_rmeta_2] /dev/sdg1(0)
lvchange --refresh my_vg/my_lv
1.4. Image Builder system requirements The lorax tool underlying Image Builder performs a number of potentially insecure and unsafe actions while creating the system images. For this reason, use a virtual machine to run Image Builder. The environment where Image Builder runs must meet requirements listed in the following table. Table 1.2. Image Builder system requirements Parameter Minimal Required Value System type A dedicated virtual machine Processor 2 cores Memory 4 GiB Disk space 20 GiB Access privileges Administrator level (root) Network Connectivity to Internet Note Creating images on virtual machine directly installed on UEFI systems is not supported.

Commands:
Chapter 23. Viewing and adding comments to a task You can add comments to a task and also view the existing comments of a task in Business Central. Procedure In Business Central, go to Menu Track Task Inbox . On the Task Inbox page, click the task to open it. On the task page, click the Work tab or the Comments tab. In the Comment field, enter the task related comment and click Add Comment icon. All task related comments are displayed in a tabular form in the Work as well as Comments tab. Note To select or clear the Show task comments at work tab check box, go to the Business Central home page, click the Settings icon and select the Process Administration option. Only users with the admin role have access to enable or disable this feature.

Commands:
6.14.3. Configuring a Two-Node Cluster If you are configuring a two-node cluster, you can execute the following command to allow a single node to maintain quorum (for example, if one node fails): Note that this command resets all other properties that you can set with the --setcman option to their default values, as described in Section 6.1.5, "Commands that Overwrite Settings" . When you use the ccs --setcman command to add, remove, or modify the two_node option, you must restart the cluster for this change to take effect. For information on starting and stopping a cluster with the ccs command, see Section 7.2, "Starting and Stopping a Cluster" .

Commands:
ccs -h host --setcman two_node=1 expected_votes=1
Chapter 1. Managing Ansible Content Collection synclists in automation hub You can use Ansible automation hub to distribute the relevant Red Hat Certified collections content to your users by creating synclists. 1.1. About Red Hat Ansible Certified Content Collections synclists A synclist is a curated group of Red Hat Certified collections that is assembled by your organization administrator that synchronizes with your local Ansible automation hub. You can use synclists to manage only the content that you want and exclude unnecessary collections. You can design and manage your synclist from the content available as part of Red Hat content on console.redhat.com Each synclist has its own unique repository URL that you can use to designate as a remote source for content in automation hub and is securely accessed using an API token. Note Initially, Ansible validated content is only available through the private automation hub installer. Organization Administrators can preload all Ansible validated content collections at install time and put them into a staging state where they can be reviewed to avoid uploading unnecessary collections. 1.2. Creating a synclist of Red Hat Ansible Certified Content Collections You can create a synclist of curated Red Hat Ansible Certified Content in Ansible automation hub on console.redhat.com. Your synclist repository is located under Automation Hub Repo Management , which is updated whenever you choose to manage content within Ansible Certified Content Collections. All Ansible Certified Content Collections are included by default in your initial organization synclist. Prerequisites You have a valid Ansible Automation Platform subscription. You have Organization Administrator permissions for console.redhat.com. The following domain names are part of either the firewall or the proxy's allowlist for successful connection and download of collections from automation hub or Galaxy server: galaxy.ansible.com cloud.redhat.com console.redhat.com sso.redhat.com Ansible automation hub resources are stored in Amazon Simple Storage and the following domain name is in the allow list: automation-hub-prd.s3.us-east-2.amazonaws.com ansible-galaxy.s3.amazonaws.com SSL inspection is disabled either when using self signed certificates or for the Red Hat domains. Procedure Log in to console.redhat.com . Navigate to Automation Hub Collections . Use the toggle switch on each collection to determine whether to exclude it from your synclist. When you finish managing collections for your synclist, navigate to Automation Hub Repo Management to initiate the remote repository synchronization to your private automation hub. Optional: If your remote repository is already configured, you can manually synchronize Red Hat Ansible Certified Content Collections to your private automation hub to update the collections content that you made available to local users.

Commands:
Appendix A. Revision History Revision History Revision 9-2 Wed Mar 15 2017 Mirek Jahoda Version for 6.9 GA publication. Revision 9-1 Tue Jan 3 2017 Mirek Jahoda Version for 6.9 Beta publication. Revision 7-4 Wed May 3 2016 Robert Kratky Release of the SELinux Guide for Red Hat Enterprise Linux 6.8 GA. Revision 7-1 Thu Jul 9 2015 Barbora Ancincova Release of the SELinux Guide for Red Hat Enterprise Linux 6.7 GA. Revision 6-0 Fri Oct 10 2014 Barbora Ancincova Release of the SELinux Guide for Red Hat Enterprise Linux 6.6 GA. Revision 5-0 Fri Sep 12 2014 Barbora Ancincova Release of the SELinux Guide for Red Hat Enterprise Linux 6.5 GA. Revision 4-0 Feb Fri 22 2013 Tomas Capek Release of the SELinux Guide for Red Hat Enterprise Linux 6.4 GA. Revision 3-0 Wed Jun 20 2012 Martin Prpic Release of the SELinux Guide for Red Hat Enterprise Linux 6.3 GA. Revision 2-0 Tue Dec 6 2011 Martin Prpic Release of the SELinux Guide for Red Hat Enterprise Linux 6.2 GA. Revision 1.9-0 Wed Mar 3 2010 Scott Radvan Revision for Red Hat Enterprise Linux 6

Commands:
E.2.26. /proc/swaps This file measures swap space and its utilization. For a system with only one swap partition, the output of /proc/swaps may look similar to the following: While some of this information can be found in other files in the /proc/ directory, /proc/swap provides a snapshot of every swap file name, the type of swap space, the total size, and the amount of space in use (in kilobytes). The priority column is useful when multiple swap files are in use. The lower the priority, the more likely the swap file is to be used.

Commands:
Filename Type Size Used Priority /dev/mapper/VolGroup00-LogVol01 partition 524280 0 -1
8.4.6. Configuration Overview: Remote Node This section provides a high-level summary overview of the steps to perform to configure a Pacemaker remote node and to integrate that node into an existing Pacemaker cluster environment. On the node that you will be configuring as a remote node, allow cluster-related services through the local firewall. Note If you are using iptables directly, or some other firewall solution besides firewalld , simply open the following ports, which can be used by various clustering components: TCP ports 2224, 3121, and 21064, and UDP port 5405. Install the pacemaker_remote daemon on the remote node. All nodes (both cluster nodes and remote nodes) must have the same authentication key installed for the communication to work correctly. If you already have a key on an existing node, use that key and copy it to the remote node. Otherwise, create a new key on the remote node. Run the following set of commands on the remote node to create a directory for the authentication key with secure permissions. The following command shows one method to create an encryption key on the remote node. Start and enable the pacemaker_remote daemon on the remote node. On the cluster node, create a location for the shared authentication key with the same path as the authentication key on the remote node and copy the key into that directory. In this example, the key is copied from the remote node where the key was created. Run the following command from a cluster node to create a remote resource. In this case the remote node is remote1 . After creating the remote resource, you can treat the remote node just as you would treat any other node in the cluster. For example, you can create a resource and place a resource constraint on the resource to run on the remote node as in the following commands, which are run from a cluster node. Warning Never involve a remote node connection resource in a resource group, colocation constraint, or order constraint. Configure fencing resources for the remote node. Remote nodes are fenced the same way as cluster nodes. Configure fencing resources for use with remote nodes the same as you would with cluster nodes. Note, however, that remote nodes can never initiate a fencing action. Only cluster nodes are capable of actually executing a fencing operation against another node.

Commands:
firewall-cmd --permanent --add-service=high-availability success firewall-cmd --reload success
yum install -y pacemaker-remote resource-agents pcs
mkdir -p --mode=0750 /etc/pacemaker chgrp haclient /etc/pacemaker
dd if=/dev/urandom of=/etc/pacemaker/authkey bs=4096 count=1
systemctl enable pacemaker_remote.service systemctl start pacemaker_remote.service
mkdir -p --mode=0750 /etc/pacemaker chgrp haclient /etc/pacemaker scp remote1:/etc/pacemaker/authkey /etc/pacemaker/authkey
pcs resource create remote1 ocf:pacemaker:remote
pcs resource create webserver apache configfile=/etc/httpd/conf/httpd.conf op monitor interval=30s pcs constraint location webserver prefers remote1
function::sprint_stack Name function::sprint_stack - Return stack for kernel addresses from string Synopsis Arguments stk String with list of hexadecimal (kernel) addresses Description Perform a symbolic lookup of the addresses in the given string, which is assumed to be the result of a prior call to backtrace . Returns a simple backtrace from the given hex string. One line per address. Includes the symbol name (or hex address if symbol couldn't be resolved) and module name (if found). Includes the offset from the start of the function if found, otherwise the offset will be added to the module (if found, between brackets). Returns the backtrace as string (each line terminated by a newline character). Note that the returned stack will be truncated to MAXSTRINGLEN, to print fuller and richer stacks use print_stack. NOTE it is recommended to use sprint_syms instead of this function.

Commands:
sprint_stack:string(stk:string)
C.5. CacheManager org.infinispan.manager.DefaultCacheManager The CacheManager component acts as a manager, factory, and container for caches in the system. Table C.8. Attributes Name Description Type Writable cacheManagerStatus The status of the cache manager instance. String No clusterMembers Lists members in the cluster. String No clusterName Cluster name. String No clusterSize Size of the cluster in the number of nodes. int No createdCacheCount The total number of created caches, including the default cache. String No definedCacheCount The total number of defined caches, excluding the default cache. String No definedCacheNames The defined cache names and their statuses. The default cache is not included in this representation. String No name The name of this cache manager. String No nodeAddress The network address associated with this instance. String No physicalAddresses The physical network addresses associated with this instance. String No runningCacheCount The total number of running caches, including the default cache. String No version Infinispan version. String No globalConfigurationAsProperties Global configuration properties Properties No Table C.9. Operations Name Description Signature startCache Starts the default cache associated with this cache manager. void startCache() startCache Starts a named cache from this cache manager. void startCache (String p0) 23149%2C+Administration+and+Configuration+Guide-6.628-06-2017+13%3A51%3A02JBoss+Data+Grid+6Documentation6.6.1 Report a bug

Commands:
21.3.2. Hostname Formats The host(s) can be in the following forms: Single machine - A fully qualified domain name (that can be resolved by the server), hostname (that can be resolved by the server), or an IP address. Series of machines specified with wildcards - Use the * or ? character to specify a string match. Wildcards are not to be used with IP addresses; however, they may accidentally work if reverse DNS lookups fail. When specifying wildcards in fully qualified domain names, dots (.) are not included in the wildcard. For example, *.example.com includes one.example.com but does not include one.two.example.com. IP networks - Use a.b.c.d/z , where a.b.c.d is the network and z is the number of bits in the netmask (for example 192.168.0.0/24). Another acceptable format is a.b.c.d/netmask , where a.b.c.d is the network and netmask is the netmask (for example, 192.168.100.8/255.255.255.0). Netgroups - In the format @group-name , where group-name is the NIS netgroup name.

Commands:
9.3. Overview of Security Methods Directory Server offers several methods to design an overall security policy that is adapted to specific needs. The security policy should be strong enough to prevent sensitive information from being modified or retrieved by unauthorized users, but also simple enough to administer easily. A complex security policy can lead to mistakes that either prevent people from accessing information that they need to access or, worse, allow people to modify or retrieve directory information that they should not be allowed to access. Table 9.1. Security Methods Available in Directory Server Security Method Description Authentication A means for one party to verify another's identity. For example, a client gives a password to Directory Server during an LDAP bind operation. Password policies Defines the criteria that a password must satisfy to be considered valid; for example, age, length, and syntax. Encryption Protects the privacy of information. When data is encrypted, it is scrambled in a way that only the recipient can understand. Access control Tailors the access rights granted to different directory users and provides a means of specifying required credentials or bind attributes. Account deactivation Disables a user account, group of accounts, or an entire domain so that all authentication attempts are automatically rejected. Secure connections Maintains the integrity of information by encrypting connections with TLS, Start TLS, or SASL. If information is encrypted during transmission, the recipient can determine that it was not modified during transit. Secure connections can be required by setting a minimum security strength factor. Auditing Determines if the security of the directory has been compromised; one simple auditing method is reviewing the log files maintained by the directory. SELinux Uses security policies on the Red Hat Enterprise Linux machine to restrict and control access to Directory Server files and processes. Combine any number of these tools for maintaining security in the security design, and incorporate other features of the directory service, such as replication and data distribution, to support the security design.

Commands:
Chapter 8. Viewing and managing Quartz Schedules Quartz ( http://www.quartz-scheduler.org/ ) is a richly featured, open source job scheduling library that you can integrate within most Java applications. You can use Quartz to create simple or complex schedules for executing jobs. A job is defined as a standard Java component that can execute virtually anything that you program it to do. The Fuse Console shows the Quartz tab if your Camel route deploys the camel-quartz2 component. Note that you can alternately access Quartz mbeans through the JMX tree view. Procedure In the Fuse Console, click the Quartz tab. The Quartz page includes a treeview of the Quartz Schedulers and Scheduler , Triggers , and Jobs tabs. To pause or start a scheduler, click the buttons on the Scheduler tab. Click the Triggers tab to view the triggers that determine when jobs will run. For example, a trigger can specify to start a job at a certain time of day (to the millisecond), on specified days, or repeated a specified number of times or at specific times. To filter the list of triggers select State , Group , Name , or Type from the drop-down list. You can then further filter the list by selecting or typing in the fill-on field. To pause, resume, update, or manually fire a trigger, click the options in the Action column. Click the Jobs tab to view the list of running jobs. You can sort the list by the columns in the table: Group , Name , Durable , Recover , Job ClassName , and Description .

Commands: