mtpti5iD/redhat-docs_dataset huggingface dataset:
B.91. sysstat B.91.1. RHBA-2010:0912 - sysstat bug fix update An updated sysstat package that fixes various bugs is now available for Red Hat Enterprise Linux 6. The sysstat package provides the sar and iostat commands. These commands enable system monitoring of disk, network, and other I/O activity. Bug Fix BZ# 650125 Due to recent changes in the /proc/interrupts format, running the "mpstat -I ALL" command did not produce the correct output. With this update, the mpstat utility has been updated to recognize the new format, and running the above command now works as expected. BZ# 651813 On a system with a running KVM virtual machine and under very special circumstances, the mpstat utility may have produced an output that contained incorrect values. This error no longer occurs, and the mpstat utility now always produces the correct output. All users of sysstat are advised to upgrade to this updated package, which resolves these issues.

Commands:
13.5. Read Only Disks in Red Hat Virtualization Some applications require administrators to share data with read-only rights. You can do this when creating or editing a disk attached to a virtual machine via the Disks tab in the details view of the virtual machine and selecting the Read Only check box. That way, a single disk can be read by multiple cluster-aware guests, while an administrator maintains writing privileges. You cannot change the read-only status of a disk while the virtual machine is running. Important Mounting a journaled file system requires read-write access. Using the Read Only option is not appropriate for virtual disks that contain such file systems (e.g. EXT3 , EXT4 , or XFS ).

Commands:
Chapter 4. Authorization Modules 4.1. Custom Authorization Modules In situations where the JBoss Data Virtualization built-in role mechanism is not sufficient, a custom org.teiid.PolicyDecider can be installed via a JBoss module. This is a two-stage process: first you must create a jar that contains your custom class, then you must expose the jar as a JBoss module so it can be seen by all of your classes. Implement the org.teiid.PolicyDecider interface and build a custom java class. If you are using maven as your build process, you can use the following dependencies: The PolicyDecider interface is loaded by JBoss Data Virtualization using Java's standard service loader mechanism. For this to work, add the META-INF/services/org.teiid.PolicyDecider file with the full name of your PolicyDecider implementation class as its contents. Here is an example: Package all of these files into a JAR archive. Create a directory called [JDV_HOME]/modules/com/mycompany/main/ . Copy your jar file into the newly-created directory. Create a module.xml file and also put it in the [JDV_HOME]/modules/com/mycompany/main/ directory. Here is an example that shows dependencies specific to JBoss Data Virtualization: Note If your PolicyDecider has any third-party dependencies, add them as dependencies to the module.xml file. Ensure you list all the files required. If dependencies are missing you will be informed when you start the software. After the module has been added, edit the server configuration file ( standalone.xml or its equivalent) to use your module name. The module must be added to the "teiid" subsystem: Restart the system.

Commands:
<dependencies> <dependency> <groupId>org.jboss.teiid</groupId> <artifactId>teiid-api</artifactId> <scope>provided</scope> </dependency> <dependency> <groupId>org.jboss.teiid</groupId> <artifactId>teiid-common-core</artifactId> <scope>provided</scope> </dependency> </dependencies>
org.jboss.teiid.auth.MyCustomPolicyDecider
<?xml version="1.0" encoding="UTF-8"?> <module xmlns="urn:jboss:module:1.0" name="com.mycompany"> <resources> <resource-root path="my_custom_policy.jar" /> <!--add any other dependent jars here, if they are not defined as modules --> </resources> <dependencies> <module name="org.jboss.teiid.common-core"/> <module name="org.jboss.teiid.api"/> <module name="javax.api"/> </dependencies> </module>
<policy-decider-module>MODULE-NAME</policy-decider-module>
Chapter 2. Using Pluggable Authentication Modules (PAM) Pluggable authentication modules are a common framework for authentication and security. Both of Red Hat Enterprise Linux's single sign-on methods - Kerberos and smart cards - depend on underlying PAM configuration. Understanding and using PAM can be very beneficial for planning and implementing a secure, efficient single sign-on solution. 2.1. About PAM Programs that grant users access to a system use authentication to verify each other's identity (that is, to establish that a user is who they say they are). Historically, each program had its own way of authenticating users. In Red Hat Enterprise Linux, many programs are configured to use a centralized authentication mechanism called Pluggable Authentication Modules ( PAM ). PAM uses a pluggable, modular architecture, which affords the system administrator a great deal of flexibility in setting authentication policies for the system. PAM is a useful system for developers and administrators for several reasons: PAM provides a common authentication scheme that can be used with a wide variety of applications. PAM provides significant flexibility and control over authentication for both system administrators and application developers. PAM provides a single, fully-documented library which allows developers to write programs without having to create their own authentication schemes. PAM has an extensive documentation set with much more detail about both using PAM and writing modules to extend or integrate PAM with other applications. Almost all of the major modules and configuration files with PAM have their own manpages. Additionally, the /usr/share/doc/pam- version# directory contains a System Administrators' Guide , a Module Writers' Manual , and the Application Developers' Manual , as well as a copy of the PAM standard, DCE-RFC 86.0. The libraries for PAM are available at http://www.kernel.org/pub/linux/libs/pam/ . This is the primary distribution website for the Linux-PAM project, containing information on various PAM modules, frequently asked questions, and additional PAM documentation.

Commands:
1.2. LVM Architecture Overview For the RHEL 4 release of the Linux operating system, the original LVM1 logical volume manager was replaced by LVM2, which has a more generic kernel framework than LVM1. LVM2 provides the following improvements over LVM1: flexible capacity more efficient metadata storage better recovery format new ASCII metadata format atomic changes to metadata redundant copies of metadata LVM2 is backwards compatible with LVM1, with the exception of snapshot and cluster support. You can convert a volume group from LVM1 format to LVM2 format with the vgconvert command. For information on converting LVM metadata format, see the vgconvert (8) man page. The underlying physical storage unit of an LVM logical volume is a block device such as a partition or whole disk. This device is initialized as an LVM physical volume (PV). To create an LVM logical volume, the physical volumes are combined into a volume group (VG). This creates a pool of disk space out of which LVM logical volumes (LVs) can be allocated. This process is analogous to the way in which disks are divided into partitions. A logical volume is used by file systems and applications (such as databases). Figure 1.1, "LVM Logical Volume Components" shows the components of a simple LVM logical volume: Figure 1.1. LVM Logical Volume Components For detailed information on the components of an LVM logical volume, see Chapter 2, LVM Components .

Commands:
6.6. Booleans for Users Executing Applications Not allowing Linux users to execute applications (which inherit users' permissions) in their home directories and the /tmp directory, which they have write access to, helps prevent flawed or malicious applications from modifying files that users own. Booleans are available to change this behavior, and are configured with the setsebool utility, which must be run as root. The setsebool -P command makes persistent changes. Do not use the -P option if you do not want changes to persist across reboots: guest_t To prevent Linux users in the guest_t domain from executing applications in their home directories and /tmp : xguest_t To prevent Linux users in the xguest_t domain from executing applications in their home directories and /tmp : user_t To prevent Linux users in the user_t domain from executing applications in their home directories and /tmp : staff_t To prevent Linux users in the staff_t domain from executing applications in their home directories and /tmp : To turn the staff_exec_content boolean on and to allow Linux users in the staff_t domain to execute applications in their home directories and /tmp :

Commands:
~]# setsebool -P guest_exec_content off
~]# setsebool -P xguest_exec_content off
~]# setsebool -P user_exec_content off
~]# setsebool -P staff_exec_content off
~]# setsebool -P staff_exec_content on
Chapter 13. Creating an OAuth application in GitHub You can authorize your Red Hat Quay registry to access a GitHub account and its repositories by registering it as a GitHub OAuth application. 13.1. Create new GitHub application Use the following procedure to create an OAuth application in Github. Procedure Log into Github Enterprise. In the navigation pane, select your username Your organizations . In the navigation pane, select Applications . Click Register New Application . The Register a new OAuth application configuration screen is displayed, for example: Enter a name for the application in the Application name textbox. In the Homepage URL textbox, enter your Red Hat Quay URL. Note If you are using public GitHub, the Homepage URL entered must be accessible by your users. It can still be an internal URL. In the Authorization callback URL , enter https://<RED_HAT_QUAY_URL>/oauth2/github/callback . Click Register application to save your settings. When the new application's summary is shown, record the Client ID and the Client Secret shown for the new application.

Commands:
30.2. Preparing to Upgrade Before upgrading the kernel, it is recommended that you take some precautionary steps. First, ensure that working boot media exists for the system. If the boot loader is not configured properly to boot the new kernel, you can use this media to boot into Red Hat Enterprise Linux. USB media often comes in the form of flash devices sometimes called pen drives , thumb disks , or keys , or as an externally-connected hard disk device. Almost all media of this type is formatted as a VFAT file system. You can create bootable USB media on media formatted as ext2 , ext3 , or VFAT . You can transfer a distribution image file or a minimal boot media image file to USB media. Make sure that sufficient free space is available on the device. Around 4 GB is required for a distribution DVD image, around 700 MB for a distribution CD image, or around 10 MB for a minimal boot media image. You must have a copy of the boot.iso file from a Red Hat Enterprise Linux installation DVD, or installation CD-ROM #1, and you need a USB storage device formatted with the VFAT file system and around 16 MB of free space. The following procedure will not affect existing files on the USB storage device unless they have the same path names as the files that you copy onto it. To create USB boot media, perform the following commands as root : Install the SYSLINUX boot loader on the USB storage device: ...where sdX is the device name. Create mount points for boot.iso and the USB storage device: Mount boot.iso : Mount the USB storage device: Copy the ISOLINUX files from the boot.iso to the USB storage device: Use the isolinux.cfg file from boot.iso as the syslinux.cfg file for the USB device: Unmount boot.iso and the USB storage device: You should reboot the machine with the boot media and verify that you are able to boot with it before continuing. Alternatively, on systems with a floppy drive, you can create a boot diskette by installing the mkbootdisk package and running the mkbootdisk command as root. See man mkbootdisk man page after installing the package for usage information. To determine which kernel packages are installed, execute the command yum list installed "kernel-*" at a shell prompt. The output will comprise some or all of the following packages, depending on the system's architecture, and the version numbers may differ: From the output, determine which packages need to be downloaded for the kernel upgrade. For a single processor system, the only required package is the kernel package. See Section 30.1, "Overview of Kernel Packages" for descriptions of the different packages.

Commands:
~]# syslinux /dev/ sdX1
~]# mkdir /mnt/isoboot /mnt/diskboot
~]# mount -o loop boot.iso /mnt/isoboot
~]# mount /dev/ <sdX1> /mnt/diskboot
~]# cp /mnt/isoboot/isolinux/* /mnt/diskboot
~]# grep -v local /mnt/isoboot/isolinux/isolinux.cfg > /mnt/diskboot/syslinux.cfg
~]# umount /mnt/isoboot /mnt/diskboot
~]# yum list installed "kernel-*" kernel.x86_64 2.6.32-17.el6 @rhel-x86_64-server-6 kernel-doc.noarch 2.6.32-17.el6 @rhel-x86_64-server-6 kernel-firmware.noarch 2.6.32-17.el6 @rhel-x86_64-server-6 kernel-headers.x86_64 2.6.32-17.el6 @rhel-x86_64-server-6
Chapter 9. Installing the OpenShift Serverless Logic Operator Installing the OpenShift Serverless Logic Operator enables you to install and use Serverless Workflow on a OpenShift Container Platform cluster. The OpenShift Serverless Logic Operator manages Kubernetes custom resource definitions (CRDs) to configure and deploy the workflows. 9.1. Installing the OpenShift Serverless Logic Operator from the web console You can install the OpenShift Serverless Logic Operator from OperatorHub by using the OpenShift Container Platform web console. Prerequisites You have cluster administrator permissions on OpenShift Container Platform, or you have cluster or dedicated administrator permissions on Red Hat OpenShift Service on AWS or OpenShift Dedicated. For OpenShift Container Platform, your cluster has the Marketplace capability enabled or the Red Hat-provided Operator catalogs source configured manually. You have logged in to the web console. Procedure In the web console, navigate to the Operators OperatorHub page. Scroll, or type the keyword Serverless Logic into the Filter by keyword box to find the OpenShift Serverless Logic Operator. Review the information about the Operator and click Install . On the Install Operator page, ensure that the configuration uses the following settings: The Installation Mode is All namespaces on the cluster (default) . This mode installs the Operator in the default openshift-serverless-logic namespace to watch and be made available to all namespaces in the cluster. The Installed Namespace is openshift-serverless-logic . Select the stable channel as the Update Channel . The stable channel will enable installation of the latest stable release of the OpenShift Serverless Logic Operator. Select Automatic or Manual approval strategy. Click Install to make the Operator available to the selected namespaces on this OpenShift Container Platform cluster. From the Catalog Operator Management page, you can monitor the OpenShift Serverless Logic Operator subscription's installation and upgrade progress. If you selected a Manual approval strategy, the subscription's upgrade status will remain Upgrading until you review and approve its install plan. After approving on the Install Plan page, the subscription upgrade status moves to Up to date . If you selected an Automatic approval strategy, the upgrade status should resolve to Up to date without intervention. Verification After the subscription's upgrade status is Up to date , select Catalog Installed Operators to verify that the OpenShift Serverless Logic Operator eventually shows up and its Status ultimately resolves to InstallSucceeded in the relevant namespace. If it does not, check the following items: Switch to the Catalog Operator Management page and inspect the Operator Subscriptions and Install Plans tabs for any failure or errors under Status . Check the logs in any pods in the openshift-serverless-logic project on the Workloads Pods page that are reporting issues to troubleshoot further. 9.2. Additional resources Managing resources from custom resource definitions Understanding persistent storage Configuring a custom PKI

Commands:
Chapter 61. Chronicle Engine Component Available as of Camel version 2.18 The camel chronicle-engine component let you leverage the power of OpenHFT's Chronicle-Engine 61.1. URI Format chronicle-engine:addresses/path[?options] 61.2. URI Options The Chronicle Engine component has no options. The Chronicle Engine endpoint is configured using URI syntax: with the following path and query parameters: 61.2.1. Path Parameters (2 parameters): Name Description Default Type addresses Required Engine addresses. Multiple addresses can be separated by comma. String path Required Engine path String 61.2.2. Query Parameters (12 parameters): Name Description Default Type action (common) The default action to perform, valid values are: - PUBLISH - PPUBLISH_AND_INDEX - PPUT - PGET_AND_PUT - PPUT_ALL - PPUT_IF_ABSENT - PGET - PGET_AND_REMOVE - PREMOVE - PIS_EMPTY - PSIZE String clusterName (common) Cluster name for queue String filteredMapEvents (common) A comma separated list of Map event type to filer, valid values are: INSERT, UPDATE, REMOVE. String persistent (common) Enable/disable data persistence true boolean subscribeMapEvents (common) Set if consumer should subscribe to Map events, default true. true boolean subscribeTopicEvents (common) Set if consumer should subscribe to TopicEvents,d efault false. false boolean subscribeTopologicalEvents (common) Set if consumer should subscribe to TopologicalEvents,d efault false. false boolean wireType (common) The Wire type to use, default to binary wire. BINARY String bridgeErrorHandler (consumer) Allows for bridging the consumer to the Camel routing Error Handler, which mean any exceptions occurred while the consumer is trying to pickup incoming messages, or the likes, will now be processed as a message and handled by the routing Error Handler. By default the consumer will use the org.apache.camel.spi.ExceptionHandler to deal with exceptions, that will be logged at WARN or ERROR level and ignored. false boolean exceptionHandler (consumer) To let the consumer use a custom ExceptionHandler. Notice if the option bridgeErrorHandler is enabled then this option is not in use. By default the consumer will deal with exceptions, that will be logged at WARN or ERROR level and ignored. ExceptionHandler exchangePattern (consumer) Sets the exchange pattern when the consumer creates an exchange. ExchangePattern synchronous (advanced) Sets whether synchronous processing should be strictly used, or Camel is allowed to use asynchronous processing (if supported). false boolean 61.3. Spring Boot Auto-Configuration The component supports 2 options, which are listed below. Name Description Default Type camel.component.chronicle-engine.enabled Enable chronicle-engine component true Boolean camel.component.chronicle-engine.resolve-property-placeholders Whether the component should resolve property placeholders on itself when starting. Only properties which are of String type can use property placeholders. true Boolean

Commands:
chronicle-engine:addresses/path[?options]
chronicle-engine:addresses/path
7.235. xorg-x11-drv-mga 7.235.1. RHBA-2015:1412 - xorg-x11-drv-mga bug fix update Updated xorg-x11-drv-mga packages that fix one bug are now available for Red Hat Enterprise Linux 6. The xorg-x11-drv-mga packages provide a video driver for Matrox G-series chip sets for the X.Org implementation of the X Window System. Bug Fix BZ# 1177095 Previously, the mga driver used the default color depth of 16 bpp regardless of the configuration. Consequently, it was impossible to run the X server with a custom color depth such as 24 or 32 bpp. With this update, the mga driver honors the configuration properly, and as a result, the desired color depth is used. Users of xorg-x11-drv-mga are advised to upgrade to these updated packages, which fix this bug.

Commands:
Chapter 4. Diagnosing and Correcting Problems with GFS2 File Systems This chapter provides information about some common GFS2 issues and how to address them. 4.1. GFS2 File System Shows Slow Performance You may find that your GFS2 file system shows slower performance than an ext3 file system. GFS2 performance may be affected by a number of influences and in certain use cases. Information that addresses GFS2 performance issues is found throughout this document.

Commands:
Chapter 1. Read Me 1.1. Back Up Your Data Warning Red Hat recommends that you back up your system settings and data before undertaking any of the configuration tasks mentioned in this book. 1.2. Variable Name: EAP_HOME EAP_HOME refers to the root directory of the Red Hat JBoss Enterprise Application Platform installation on which JBoss Data Virtualization has been deployed. 1.3. Variable Name: MODE MODE will either be standalone or domain depending on whether JBoss Data Virtualization is running in standalone or domain mode. Substitute one of these whenever you see MODE in a file path in this documentation. (You need to set this variable yourself, based on where the product has been installed in your directory structure.) 1.4. Red Hat Documentation Site Red Hat's official documentation site is available at https://access.redhat.com/site/documentation/ . There you will find the latest version of every book, including this one.

Commands:
Chapter 4. Upgrading the Red Hat Service Interconnect Operator and sites You can now choose from the following channels: stable-1.8 - Limit updates to 1.8.x (long term support). stable-1 - Limit updates to 1.x. stable - All releases. Note If you are using stable or stable-1 , you can upgrade automatically. To upgrade from the LTS version to 1.8, switch channel to stable-1.8 . If you install the Operator again as described in Installing the Operator , existing sites are not removed. If you chose automatic updates when installing the Red Hat Service Interconnect Operator, sites are upgraded to future releases whenever a new version of Service Interconnect is available for the channel you chose. If you chose manual updates, complete this procedure to upgrade your sites. Procedure Log into the OpenShift console. Navigate to the Installed Operators page. If Upgrade available is displayed as the Status for the Red Hat Service Interconnect Operator, click that text. On the InstallPlan details page, click Preview InstallPlan . Click Approve to upgrade sites. Warning Upgrading sites by upgrading the Operator can affect related images provisioned using other methods. By default, sites created using the CLI are not affected by Operator upgrades. To prevent issues with sites not managed by the Operator, make sure the skupper-site ConfigMap specifies internal.skupper.io/site-controller-ignore as true , for example:

Commands:
metadata: labels: internal.skupper.io/site-controller-ignore: "true"