mtpti5iD/redhat-docs_dataset huggingface dataset:
7.304. cups 7.304.1. RHBA-2013:1163 - cups bug fix update Updated cups packages that fix a bug are now available for Red Hat Enterprise Linux 6. The Common UNIX Printing System (CUPS) provides a portable printing layer for Linux, UNIX, and similar operating systems. Bug Fix BZ# 994480 For queues using the "ipp" back-end, print jobs containing more than one file were previously treated as though all files were in the same format as the first file in the job when transferring the job to the remote IPP system. This has been corrected by declaring each file as having an unknown document format ("application/octet-stream") for multiple file jobs, and leaving format detection to the remote IPP system. All users of cups are advised to upgrade to these updated packages, which fix this bug.

Commands:
Chapter 1. Overview of alt-java Red Hat packages contain a mitigation for the SSB vulnerability in the form of a patch for the java binary. This patch disables an optimization present in x86-64 (Intel and AMD) processors. Disabling that optimization reduces the risk of kernel side-channel attacks, but also reduces CPU performance. Since the patch reduces performance, it has been removed from the java launcher. A new binary alt-java is now available. From the January 2021 Critical Patch Update release (1.8.0 282.b08, 11.0.10.9) onwards, the alt-java binary is included in Red Hat build of OpenJDK 17 and Red Hat build of OpenJDK 11 GA RPM packages. Additional resources For more information about the performance impact of SSB mitigation, see Kernel Side-Channel Attack using Speculative Store Bypass - CVE-2018-3639 on the Red Hat Customer Portal For more information about the java binary patch, see RH1566890 in the Red Hat Bugzilla documentation.

Commands:
E.2.9. /proc/filesystems This file displays a list of the file system types currently supported by the kernel. Sample output from a generic /proc/filesystems file looks similar to the following: The first column signifies whether the file system is mounted on a block device. Those beginning with nodev are not mounted on a device. The second column lists the names of the file systems supported. The mount command cycles through the file systems listed here when one is not specified as an argument.

Commands:
nodev sysfs nodev rootfs nodev bdev nodev proc nodev sockfs nodev binfmt_misc nodev usbfs nodev usbdevfs nodev futexfs nodev tmpfs nodev pipefs nodev eventpollfs nodev devpts ext2 nodev ramfs nodev hugetlbfs iso9660 nodev mqueue ext3 nodev rpc_pipefs nodev autofs
2.31. RHEA-2011:0613 - new package: python-krbV A new python-krbV package is now available for Red Hat Enterprise Linux 6. Kerberos is a network authentication system. The krbV module provides a Python binding to the Kerberos 5 libraries, and allows Python programs to utilize Kerberos functions and services. This enhancement update adds the python-krbV package to Red Hat Enterprise Linux 6. (BZ# 642414 ) All users who require the krbV Python module should install this new package.

Commands:
Chapter 8. Upgrading Ansible Automation Platform Operator on OpenShift Container Platform The Ansible Automation Platform Operator simplifies the installation, upgrade and deployment of new Red Hat Ansible Automation Platform instances in your OpenShift Container Platform environment. 8.1. Upgrade considerations Red Hat Ansible Automation Platform version 2.0 was the first release of the Ansible Automation Platform Operator. If you are upgrading from version 2.0, continue to the Upgrading the Ansible Automation Platform Operator procedure. If you are using a version of OpenShift Container Platform that is not supported by the version of Red Hat Ansible Automation Platform to which you are upgrading, you must upgrade your OpenShift Container Platform cluster to a supported version prior to upgrading. Refer to the Red Hat Ansible Automation Platform Life Cycle to determine the OpenShift Container Platform version needed. For information about upgrading your cluster, refer to Updating clusters . 8.2. Prerequisites To upgrade to a newer version of Ansible Automation Platform Operator, it is recommended that you do the following: Create AutomationControllerBackup and AutomationHubBackup objects. For help with this see Creating Red Hat Ansible Automation Platform backup resources Review the release notes for the new Ansible Automation Platform version to which you are upgrading and any intermediate versions. 8.3. Upgrading the Ansible Automation Platform Operator To upgrade to the latest version of Ansible Automation Platform Operator on OpenShift Container Platform, do the following: Prodedure Log in to OpenShift Container Platform. Navigate to Operators Installed Operators . Select the Subscriptions tab. Under Upgrade status , click Upgrade Available . Click Preview InstallPlan . Click Approve .

Commands:
Chapter 4. Updating Red Hat build of OpenJDK 21 on Red Hat Enterprise Linux The following sections provide instructions for updating Red Hat build of OpenJDK 21 on Red Hat Enterprise Linux. 4.1. Updating Red Hat build of OpenJDK 21 on RHEL by using yum You can update the installed Red Hat build of OpenJDK packages by 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 You can install multiple major versions of Red Hat build of OpenJDK on your local system. If you need to switch from one major version to another major version, issue the following command in your command-line interface (CLI) and then follow the onscreen prompts: 4.2. Updating Red Hat build of OpenJDK 21 on RHEL by using an archive You can update Red Hat build of OpenJDK by using an archive file. 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-21 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 by using an archive . For instructions on installing a JDK, see Installing Red Hat build of OpenJDK on RHEL by using an archive . Revised on 2024-11-19 12:33:15 UTC

Commands:
sudo yum list installed "java*"
sudo yum update java-21-openjdk
java -version
sudo update-alternatives --config 'java'
unlink ~/jdks/java-21
8.227. virt-p2v 8.227.1. RHEA-2013:1631 - virt-p2v bug fix and enhancement update Updated virt-p2v packages that fix several bugs and add various enhancements are now available for Red Hat Enterprise Linux 6. Virt-p2v is a tool for conversion of a physical server to a virtual guest. Note The virt-p2v package has been upgraded to upstream version 0.9.1, which provides a number of bug fixes and enhancements over the version. (BZ# 976832 ) Users of virt-p2v are advised to upgrade to these updated packages, which fix these bugs and add these enhancements.

Commands:
15.2. Types The main permission control method used in SELinux targeted policy to provide advanced process isolation is Type Enforcement. All files and processes are labeled with a type: types define a SELinux domain for processes and a SELinux type for files. SELinux policy rules define how types access each other, whether it be a domain accessing a type, or a domain accessing another domain. Access is only allowed if a specific SELinux policy rule exists that allows it. The following types are used with Red Hat Gluster Storage. Different types allow you to configure flexible access: Process types glusterd_t The Gluster processes are associated with the glusterd_t SELinux type. Types on executables glusterd_initrc_exec_t The SELinux-specific script type context for the Gluster init script files. glusterd_exec_t The SELinux-specific executable type context for the Gluster executable files. Port Types gluster_port_t This type is defined for glusterd . By default, glusterd uses 204007-24027, and 38465-38469 TCP ports. File Contexts glusterd_brick_t This type is used for files threated as glusterd brick data. glusterd_conf_t This type is associated with the glusterd configuration data, usually stored in the /etc/ directory. glusterd_log_t Files with this type are treated as glusterd log data, usually stored under the /var/log/ directory. glusterd_tmp_t This type is used for storing the glusterd temporary files in the /tmp/ directory. glusterd_var_lib_t This type allows storing the glusterd files in the /var/lib/ directory. glusterd_var_run_t This type allows storing the glusterd files in the /run/ or /var/run/ directory.

Commands:
Chapter 1. Introducing Insights image builder on Red Hat Hybrid Cloud Console 1.1. Insights image builder on Red Hat Hybrid Cloud Console Insights image builder is a tool bundled with Red Hat Insights, within console.redhat.com . The console experience is also known as the Red Hat Hybrid Cloud Console. With Insights image builder, RHEL customers can: Create customized system images, that can have a subscription activation key already embedded Add additional packages to the image during image creation Upload the customized images to the targeted clouds such as Amazon Web Services , Microsoft Azure , and Google Cloud Platform Download your customized images and upload it to the private VMware vSphere client Create customized Bare Metal and Guest images RHEL customers can create images for a variety of deployment types, built according to the standards that are recommended for each deployment type.

Commands:
2.6. Additional Resources This section includes various resources that can be used to learn more about resource monitoring and the Red Hat Enterprise Linux-specific subject matter discussed in this chapter. 2.6.1. Installed Documentation The following resources are installed in the course of a typical Red Hat Enterprise Linux installation. free(1) man page -- Learn how to display free and used memory statistics. top(1) man page -- Learn how to display CPU utilization and process-level statistics. watch(1) man page -- Learn how to periodically execute a user-specified program, displaying fullscreen output. GNOME System Monitor Help menu entry -- Learn how to graphically display process, CPU, memory, and disk space utilization statistics. vmstat(8) man page -- Learn how to display a concise overview of process, memory, swap, I/O, system, and CPU utilization. iostat(1) man page -- Learn how to display CPU and I/O statistics. mpstat(1) man page -- Learn how to display individual CPU statistics on multiprocessor systems. sadc(8) man page -- Learn how to collects system utilization data. sa1(8) man page -- Learn about a script that runs sadc periodically. sar(1) man page -- Learn how to produce system resource utilization reports. sa2(8) man page -- Learn how to produce daily system resource utilization report files. nice(1) man page -- Learn how to change process scheduling priority. oprofile(1) man page -- Learn how to profile system performance. op_visualise(1) man page -- Learn how to graphically display OProfile data.

Commands:
7.5. Runlevels and X In most cases, the default installation of Red Hat Enterprise Linux configures a machine to boot into a graphical login environment, known as runlevel 5. It is possible, however, to boot into the text-only multi-user mode called runlevel 3 and begin an X session from there. For more information about runlevels, refer to Section 1.4, "SysV Init Runlevels" . The following subsections review how X starts up in both runlevel 3 and runlevel 5. 7.5.1. Runlevel 3 When in runlevel 3, the best way to start an X session is to log in and type startx . The startx command is a front-end to the xinit command, which launches the X server ( Xorg ) and connects X client applications to it. Because the user is already logged into the system at runlevel 3, startx does not launch a display manager or authenticate users. Refer to Section 7.5.2, "Runlevel 5" for more information about display managers. When the startx command is executed, it searches for an .xinitrc file in the user's home directory to define the desktop environment and possibly other X client applications to run. If no .xinitrc file is present, it uses the system default /etc/X11/xinit/xinitrc file instead. The default xinitrc script then looks for user-defined files and default system files, including .Xresources , .Xmodmap , and .Xkbmap in the user's home directory, and Xresources , Xmodmap , and Xkbmap in the /etc/X11/ directory. The Xmodmap and Xkbmap files, if they exist, are used by the xmodmap utility to configure the keyboard. The Xresources file is read to assign specific preference values to applications. After setting these options, the xinitrc script executes all scripts located in the /etc/X11/xinit/xinitrc.d/ directory. One important script in this directory is xinput , which configures settings such as the default language. , the xinitrc script tries to execute .Xclients in the user's home directory and turns to /etc/X11/xinit/Xclients if it cannot be found. The purpose of the Xclients file is to start the desktop environment or, possibly, just a basic window manager. The .Xclients script in the user's home directory starts the user-specified desktop environment in the .Xclients-default file. If .Xclients does not exist in the user's home directory, the standard /etc/X11/xinit/Xclients script attempts to start another desktop environment, trying GNOME first and then KDE followed by twm . The user is returned to a text mode user session after logging out of X from runlevel 3.

Commands:
Chapter 7. Managing data loss The proper response to a data loss event will depend on the number of replicas that have been affected and the type of lost data. 7.1. Responding to isolated data loss When a data loss event occurs, minimize replicating the data loss by immediately isolating the affected servers. Then create replacement replicas from the unaffected remainder of the environment. Prerequisites A robust IdM replication topology with multiple replicas. See Preparing for server loss with replication . Procedure To limit replicating the data loss, disconnect all affected replicas from the rest of the topology by removing their replication topology segments. Display all domain replication topology segments in the deployment. Delete all domain topology segments involving the affected servers. Perform the same actions with any ca topology segments involving any affected servers. The servers affected by the data loss must be abandoned. To create replacement replicas, see Recovering multiple servers with replication . 7.2. Responding to limited data loss among all servers A data loss event can affect all replicas in the environment, such as replication carrying out an accidental deletion among all servers. If data loss is known and limited, manually re-add lost data. Prerequisites A Virtual Machine (VM) snapshot or IdM backup of an IdM server that contains the lost data. Procedure If you need to review any lost data, restore the VM snapshot or backup to an isolated server on a separate network. Add the missing information to the database using ipa or ldapadd commands. Additional resources Recovering from data loss with VM snapshots Backing Up and Restoring IdM 7.3. Responding to undefined data loss among all servers If data loss is severe or undefined, deploy a new environment from a Virtual Machine (VM) snapshot of a server. Prerequisites A Virtual Machine (VM) snapshot contains the lost data. Procedure Restore an IdM Certificate Authority (CA) Replica from a VM snapshot to a known good state, and deploy a new IdM environment from it. See Recovering from only a VM snapshot . Add any data created after the snapshot was taken using ipa or ldapadd commands. Additional resources Recovering from data loss with VM snapshots

Commands:
ipa topologysegment-find Suffix name: domain ------------------ 8 segments matched ------------------ Segment name: segment1 Left node: server.example.com Right node: server2.example.com Connectivity: both ---------------------------- Number of entries returned 8 ----------------------------
ipa topologysegment-del Suffix name: domain Segment name: segment1 ----------------------------- Deleted segment "segment1" -----------------------------
ipa topologysegment-find Suffix name: ca ------------------ 1 segments matched ------------------ Segment name: ca_segment Left node: server.example.com Right node: server2.example.com Connectivity: both ---------------------------- Number of entries returned 1 ---------------------------- ipa topologysegment-del Suffix name: ca Segment name: ca_segment ----------------------------- Deleted segment "ca_segment" -----------------------------
34.2. Split Brain Timing: Detecting a Split When using the FD_ALL protocol a given node becomes suspected after the following amount of milliseconds have passed: Important The amount of time taken in the formulas above is how long it takes JBoss Data Grid to install a cluster view without the leavers; however, as JBoss Data Grid runs inside a JVM excessive Garbage Collection (GC) times can increase this time beyond the failure detection outlined above. JBoss Data Grid has no control over these GC times, and excessive GC on the coordinator can delay this detection by an amount equal to the GC time. Report a bug

Commands:
FD_ALL.timeout + FD_ALL.interval + VERIFY_SUSPECT.timeout + GMS.view_ack_collection_timeout
7.2. Run Red Hat JBoss Data Grid in Standalone Mode Standalone mode refers to a single instance of Red Hat JBoss Data Grid operating in local mode. In local mode, JBoss Data Grid operates as a simple single node in-memory data cache. Run the following script to start JBoss Data Grid in standalone mode: This command starts JBoss Data Grid using the default configuration information provided in the USDJDG_HOME/standalone/configuration/ standalone.xml file. Report a bug

Commands:
USDJDG_HOME/bin/standalone.sh
Part I. Designing business processes using BPMN models As a business processes developer, you can use Business Central in Red Hat Process Automation Manager or the Red Hat Process Automation Manager BPMN modeler in VS Code to design business processes to meet specific business requirements. This document describes business processes and the concepts and options for creating them using the process designer in Red Hat Process Automation Manager. This document also describes the BPMN2 elements in Red Hat Process Automation Manager. For more details about BPMN2, see the Business Process Model and Notation Version 2.0 specification. Prerequisites Red Hat JBoss Enterprise Application Platform 7.4 is installed. For details, see Red Hat JBoss Enterprise Application Platform 7.4 Installation Guide . Red Hat Process Automation Manager is installed and configured with KIE Server. For more information, see Installing and configuring Red Hat Process Automation Manager on Red Hat JBoss EAP 7.4 . Red Hat Process Automation Manager is running and you can log in to Business Central with the developer role. For more information, see Planning a Red Hat Process Automation Manager installation .

Commands:
7.43. e2fsprogs 7.43.1. RHBA-2015:1442 - e2fsprogs bug fix update Updated e2fsprogs packages that fix one bug are now available for Red Hat Enterprise Linux 6. The e2fsprogs packages provide a number of utilities for creating, checking, modifying, and correcting any inconsistencies in the ext2 file systems. Bug Fix BZ# 1218262 Previously, if the superblock of an ext2, ext3, or ext4 file system contained a "last mount" or "last check" time which was set in the future, the e2fsck utility did not fix the error in "preen" mode. As a consequence, an incorrect system clock could stop the boot process and wait for an administrator intervention due to a failed boot-time file system check. With this update, these time-stamp errors are fixed automatically in "preen" mode, and the boot process is no longer interrupted in the described situation. Users of e2fsprogs are advised to upgrade to these updated packages, which fix this bug.

Commands:
Chapter 53. Case roles Case roles provide an additional layer of abstraction for user participation in case handling. Roles, users, and groups are used for different purposes in case management. Roles Roles drive the authorization for a case instance and are used for user activity assignments. A user or one or more groups can be assigned to the owner role. The owner is whoever the case belongs to. Roles are not restricted to a single set of people or groups as part of a case definition. Use roles to specify task assignments instead of assigning a specific user or group to a task assignment to ensure that the case remains dynamic. Groups A group is a collection of users who are able to carry out a particular task or have a set of specified responsibilities. You can assign any number of people to a group and assign any group to a role. You can add or change members of a group at any time. Do not hard code a group to a particular task. Users A user is an individual who can be given a particular task when you assign them a role or add them to a group. Note Do not create a user called unknown in process engine or KIE Server. The unknown user account is a reserved system name with superuser access. The unknown user account performs tasks related to the SLA violation listener when there are no users logged in. The following example illustrates how the preceding case management concepts apply to a hotel reservation with the following information: Role : Guest Group : Receptionist , Maid User : Marilyn The Guest role assignment affects the specific work of the associated case and is unique to all case instances. Every case instance will have its own role assignments. The number of users or groups that can be assigned to a role is limited by the case Cardinality , which is set during role creation in the process designer and case definition. For example, the hotel reservation case has only one guest while the IT_Orders sample project has two suppliers of IT hardware. When roles are defined, ensure that roles are not hard-coded to a single set of people or groups as part of case definition and that they can differ for each case instance. This is why case role assignments are important. Role assignments can be assigned or removed when a case starts or at any time when a case is active. Although roles are optional, use roles in case definitions to maintain an organized workflow. Important Always use roles for task assignments instead of actual user or group names. This ensures that the case and user or group assignments can be made as late as required. Roles are assigned to users or groups and authorized to perform tasks when a case instance is started.

Commands: