mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 80. Decision engine in Red Hat Process Automation Manager The decision engine is the rules engine in Red Hat Process Automation Manager. The decision engine stores, processes, and evaluates data to execute the business rules or decision models that you define. The basic function of the decision engine is to match incoming data, or facts , to the conditions of rules and determine whether and how to execute the rules. The decision engine operates using the following basic components: Rules: Business rules or DMN decisions that you define. All rules must contain at a minimum the conditions that trigger the rule and the actions that the rule dictates. Facts: Data that enters or changes in the decision engine that the decision engine matches to rule conditions to execute applicable rules. Production memory: Location where rules are stored in the decision engine. Working memory: Location where facts are stored in the decision engine. Agenda: Location where activated rules are registered and sorted (if applicable) in preparation for execution. When a business user or an automated system adds or updates rule-related information in Red Hat Process Automation Manager, that information is inserted into the working memory of the decision engine in the form of one or more facts. The decision engine matches those facts to the conditions of the rules that are stored in the production memory to determine eligible rule executions. (This process of matching facts to rules is often referred to as pattern matching .) When rule conditions are met, the decision engine activates and registers rules in the agenda, where the decision engine then sorts prioritized or conflicting rules in preparation for execution. The following diagram illustrates these basic components of the decision engine: Figure 80.1. Overview of basic decision engine components For more details and examples of rule and fact behavior in the decision engine, see Chapter 82, Inference and truth maintenance in the decision engine . These core concepts can help you to better understand other more advanced components, processes, and sub-processes of the decision engine, and as a result, to design more effective business assets in Red Hat Process Automation Manager.

Commands:
Chapter 1. Ceph block devices and OpenStack The Red Hat Enterprise Linux OpenStack Platform Director provides two methods for using Ceph as a backend for Glance, Cinder, Cinder Backup and Nova: OpenStack creates the Ceph storage cluster: OpenStack Director can create a Ceph storage cluster. This requires configuring templates for the Ceph OSDs. OpenStack handles the installation and configuration of Ceph nodes. With this scenario, OpenStack will install the Ceph monitors with the OpenStack controller nodes. OpenStack connects to an existing Ceph storage cluster: OpenStack Director, using Red Hat OpenStack Platform 9 and higher, can connect to a Ceph monitor and configure the Ceph storage cluster for use as a backend for OpenStack. The foregoing methods are the preferred methods for configuring Ceph as a backend for OpenStack, because they will handle much of the installation and configuration automatically. This document details the manual procedure for configuring Ceph, QEMU, libvirt and OpenStack to use Ceph as a backend. This document is intended for use for those who do not intend to use the RHEL OSP Director. Note A running Ceph storage cluster and at least one OpenStack node is required to use Ceph block devices as a backend for OpenStack. Three parts of OpenStack integrate with Ceph's block devices: Images: OpenStack Glance manages images for VMs. Images are immutable. OpenStack treats images as binary blobs and downloads them accordingly. Volumes: Volumes are block devices. OpenStack uses volumes to boot VMs, or to attach volumes to running VMs. OpenStack manages volumes using Cinder services. Ceph can serve as a black end for OpenStack Cinder and Cinder Backup. Guest Disks: Guest disks are guest operating system disks. By default, when booting a virtual machine, its disk appears as a file on the file system of the hypervisor, by default, under /var/lib/nova/instances/<uuid>/ directory. OpenStack Glance can store images in a Ceph block device, and can use Cinder to boot a virtual machine using a copy-on-write clone of an image. Important Ceph doesn't support QCOW2 for hosting a virtual machine disk. To boot virtual machines, either ephemeral backend or booting from a volume, the Glance image format must be RAW. OpenStack can use Ceph for images, volumes or guest disks virtual machines. There is no requirement for using all three. Additional Resources See the Red Hat OpenStack Platform documentation for additional details.

Commands:
Chapter 33. Data Interoperability 33.1. Protocol Interoperability Red Hat JBoss Data Grid protocol interoperability allows data in the form of raw bytes to be read/write accessed by different protocols, such as REST, Memcached, and Hot Rod, that are written in various programming languages, such as C++ or Java. By default, each protocol stores data in the most efficient format for that protocol, ensuring transformations are not required when retrieving entries. When this data is required to be accessed from multiple protocols, compatibility mode must be enabled on caches that are being shared. Enabling Compatibility Mode The compatibility element's marshaller parameter may be set to a custom marshaler to enable compatibility conversions. An example of this is found below: Example 33.1. Compatibility Mode Enabled For more information on protocol interoperability refer to the Use Cases and Requirements section in the JBoss Data Grid Developer Guide. Report a bug

Commands:
<cache-container name="local" default-cache="default" statistics="true"> <local-cache name="default" start="EAGER" statistics="true"> <compatibility marshaller="com.example.CustomMarshaller"/> </local-cache> </cache-container>
Appendix A. Revision History Revision History Revision 4-9.33.402 Fri Oct 25 2013 Rudiger Landmann Rebuild with Publican 4.0.0 Revision 4-9.33 2012-07-22 Anthony Towns Rebuild for Publican 3.0 Revision 3-0 Wed Feb 16 2011 Jaromir Hradilek Corrected a typing error in the vsftpd configuration. Corrected several formatting issues. Re-included missing images. Revision 2-0 Wed Nov 26 2008 Don Domingo Removed computeroutput tags nested inside screens, was causing ugly one-liner screens.

Commands:
Preface Red Hat Fuse provides two enterprise monitoring tools for viewing and managing Fuse integrations: The Fuse Console is a web-based console that you access from a browser to monitor and manage a running Fuse container. The Fuse Console is based on Hawtio open source software ( https://hawt.io/ ). This guide describes how to use the Fuse Console. Prometheus stores system and integration-level metrics for Fuse distributions. You can use a graphical analytics interface, such as Grafana, to view and analyze the stored historical data. To learn more about using Prometheus, see the following documentation: the Prometheus documentation Fuse on OpenShift Guide Installing and Operating Fuse Online on OpenShift Container Platform The audience for this guide is Red Hat Fuse on JBoss EAP administrators. This guide assumes that you are familiar with the Red Hat Fuse platform, Apache Camel, and the processing requirements for your organization.

Commands:
E.7. GRUB Commands GRUB allows a number of useful commands in its command line interface. Some of the commands accept options after their name; these options should be separated from the command and other options on that line by space characters. The following is a list of useful commands: boot - Boots the operating system or chain loader that was last loaded. chainloader </path/to/file> - Loads the specified file as a chain loader. If the file is located on the first sector of the specified partition, use the blocklist notation, +1 , instead of the file name. The following is an example chainloader command: displaymem - Displays the current use of memory, based on information from the BIOS. This is useful to determine how much RAM a system has prior to booting it. initrd </path/to/initrd> - Enables users to specify an initial RAM disk to use when booting. An initrd is necessary when the kernel needs certain modules in order to boot properly, such as when the root partition is formatted with the ext3 or ext4 file system. The following is an example initrd command: install <stage-1> <install-disk> <stage-2> p config-file - Installs GRUB to the system MBR. <stage-1> - Signifies a device, partition, and file where the first boot loader image can be found, such as (hd0,0)/grub/stage1 . <install-disk> - Specifies the disk where the stage 1 boot loader should be installed, such as (hd0) . <stage-2> - Passes the stage 2 boot loader location to the stage 1 boot loader, such as (hd0,0)/grub/stage2 . p <config-file> - This option tells the install command to look for the menu configuration file specified by <config-file> , such as (hd0,0)/grub/grub.conf . Warning The install command overwrites any information already located on the MBR. kernel </path/to/kernel> <option-1> <option-N> ... - Specifies the kernel file to load when booting the operating system. Replace </path/to/kernel> with an absolute path from the partition specified by the root command. Replace <option-1> with options for the Linux kernel, such as root=/dev/VolGroup00/LogVol00 to specify the device on which the root partition for the system is located. Multiple options can be passed to the kernel in a space separated list. The following is an example kernel command: The option in the example specifies that the root file system for Linux is located on the hda5 partition. root ( <device-type> <device-number> , <partition> ) - Configures the root partition for GRUB, such as (hd0,0) , and mounts the partition. The following is an example root command: rootnoverify ( <device-type> <device-number> , <partition> ) - Configures the root partition for GRUB, just like the root command, but does not mount the partition. Other commands are also available; type help --all for a full list of commands. For a description of all GRUB commands, refer to the documentation available online at http://www.gnu.org/software/grub/manual/ .

Commands:
chainloader +1
initrd /initrd-2.6.8-1.523.img
kernel /vmlinuz-2.6.8-1.523 ro root=/dev/VolGroup00/LogVol00
root (hd0,0)
5.165. libvirt-qmf 5.165.1. RHBA-2012:1001 - libvirt-qmf bug fix update Updated libvirt-qmf packages that fix one bug are now available for Red Hat Enterprise Linux 6. The libvirt-qmf packages provide an interface with libvirt using Qpid Management Framework (QMF), which utilizes the Advanced Message Queuing Protocol (AMQP). AMQP is an open standard application layer protocol providing reliable transport of messages. Bug Fix BZ# 830087 The libvirt-qmf packages included in Red Hat Enterprise Linux 6.2 were of version 0.3.0-7, whereas the packages in Red Hat Enterprise Linux 6.3 were of version 0.3.0-6. To prevent possible problems with upgrading, Red Hat Enterprise Linux 6.3 now uses libvirt-qmf version 0.3.0-8. All users of libvirt-qmf are advised to upgrade to these updated packages, which fix this bug. 5.165.2. RHBA-2012:0983 - libvirt-qmf bug fix update Updated libvirt-qmf packages that fix one bug are now available for Red Hat Enterprise Linux 6. The libvirt-qmf packages provide an interface with libvirt using Qpid Management Framework (QMF), which utilizes the Advanced Message Queuing Protocol (AMQP). AMQP is an open standard application layer protocol providing reliable transport of messages. Bug Fix BZ# 806950 Prior to this update, Qpid APIs used the libpidclient and libpidcommon libraries, which were not application binary interface (ABI) stable. This update removes these dependencies so that Qpid rebuilds do not affect the libvirt-qmf packages. All users of libvirt-qmf are advised to upgrade to these updated packages, which fix this bug.

Commands:
Part I. Creating a filtered or unfiltered Azure cloud integration Before you create an Azure integration, first decide if you want to create a filtered or unfiltered integration. Unfiltered flow An unfiltered integration enables cost management to directly read your billing reports from Azure. You can select the scope of the reports later on. To create an unfiltered integration, go to Creating an unfiltered Azure integration . Filtered flow A filtered integration enables you to customize and filter your data before cost management reads it. Some customers use the filtered integration to share billing data with only certain Red Hat products. It is more complex to set up and configure a filtered integration than an unfiltered one. To create a filtered integration, go to Creating a filtered Azure integration . Note You must create either a filtered or unfiltered integration. Do not follow both sets of instructions.

Commands:
5.4. Removing a Disk from a Logical Volume This example shows how you can remove a disk from an existing logical volume, either to replace the disk or to use the disk as part of a different volume. In order to remove a disk, you must first move the extents on the LVM physical volume to a different disk or set of disks. 5.4.1. Moving Extents to Existing Physical Volumes In this example, the logical volume is distributed across four physical volumes in the volume group myvg . We want to move the extents off of /dev/sdb1 so that we can remove it from the volume group. If there are enough free extents on the other physical volumes in the volume group, you can execute the pvmove command on the device you want to remove with no other options and the extents will be distributed to the other devices. After the pvmove command has finished executing, the distribution of extents is as follows: Use the vgreduce command to remove the physical volume /dev/sdb1 from the volume group. The disk can now be physically removed or allocated to other users.

Commands:
pvs -o+pv_used PV VG Fmt Attr PSize PFree Used /dev/sda1 myvg lvm2 a- 17.15G 12.15G 5.00G /dev/sdb1 myvg lvm2 a- 17.15G 12.15G 5.00G /dev/sdc1 myvg lvm2 a- 17.15G 12.15G 5.00G /dev/sdd1 myvg lvm2 a- 17.15G 2.15G 15.00G
pvmove /dev/sdb1 /dev/sdb1: Moved: 2.0% /dev/sdb1: Moved: 79.2% /dev/sdb1: Moved: 100.0%
pvs -o+pv_used PV VG Fmt Attr PSize PFree Used /dev/sda1 myvg lvm2 a- 17.15G 7.15G 10.00G /dev/sdb1 myvg lvm2 a- 17.15G 17.15G 0 /dev/sdc1 myvg lvm2 a- 17.15G 12.15G 5.00G /dev/sdd1 myvg lvm2 a- 17.15G 2.15G 15.00G
vgreduce myvg /dev/sdb1 Removed "/dev/sdb1" from volume group "myvg" pvs PV VG Fmt Attr PSize PFree /dev/sda1 myvg lvm2 a- 17.15G 7.15G /dev/sdb1 lvm2 -- 17.15G 17.15G /dev/sdc1 myvg lvm2 a- 17.15G 12.15G /dev/sdd1 myvg lvm2 a- 17.15G 2.15G
12.5.3. Security BIND supports a number of different methods to protect the updating and transfer of zones, on both master and slave nameservers: DNSSEC - Short for DNS SECurity , this feature allows for zones to be cryptographically signed with a zone key . In this way, the information about a specific zone can be verified as coming from a nameserver that has signed it with a particular private key, as long as the recipient has that nameserver's public key. BIND version 9 also supports the SIG(0) public/private key method of message authentication. TSIG - Short for Transaction SIGnatures , this feature allows a transfer from master to slave only after verifying that a shared secret key exists on both nameservers. This feature strengthens the standard IP address-based method of transfer authorization. An attacker would not only need to have access to the IP address to transfer the zone, but they would also need to know the secret key. BIND version 9 also supports TKEY , which is another shared secret key method of authorizing zone transfers.

Commands:
Chapter 21. Red Hat Enterprise Linux Atomic Host 7.5.2 21.1. Atomic Host OStree update : New Tree Version: 7.5.2 (hash: 7eae04224d894f6f0b57bf3c77f78c749d64813bd1543290f4b0276c81082617) Changes since Tree Version 7.5.1 (hash: c28680604bc84f472804a8f8c787917496739bc61529cbee7c474f68d4daeb81) Updated packages : cockpit-ostree-169-1.el7 rpm-ostree-client-2018.5-1.atomic.el7 21.2. Extras Updated packages : WALinuxAgent-2.2.18-2.el7 python-docker-py-1.10.6-4.el7 cockpit-169-1.el7 ostree-2018.5-1.el7 oci-systemd-hook-0.1.16-1.git05bd9a0.el7 skopeo-0.1.30-1.dev.gitca3bff6.el7 podman-0.6.1-3.git3e0ff12.el7 flannel-0.7.1-4.el7 etcd-3.2.22-1.el7 buildah-1.1-1.gitfbf46d3.el7 atomic-1.22.1-22.git5a342e3.el7 container-storage-setup-0.10.0-1.gitdf0dcd5.el7 docker-1.13.1-68.gitdded712.el7 dpdk-17.11-11.el7 container-selinux-2.66-1.el7 New packages : containernetworking-plugins-0.7.0-101.el7 21.2.1. Container Images Updated : Red Hat Enterprise Linux 7 Init Container Image (rhel7/rhel7-init) Red Hat Enterprise Linux Atomic Identity Management Server Container Image (rhel7/ipa-server) Red Hat Enterprise Linux Atomic Image (rhel-atomic, rhel7-atomic, rhel7/rhel-atomic) Red Hat Enterprise Linux Atomic Net-SNMP Container Image (rhel7/net-snmp) Red Hat Enterprise Linux Atomic SSSD Container Image (rhel7/sssd) Red Hat Enterprise Linux Atomic Support Tools Container Image (rhel7/support-tools) Red Hat Enterprise Linux Atomic Tools Container Image (rhel7/rhel-tools) Red Hat Enterprise Linux Atomic cockpit-ws Container Image (rhel7/cockpit-ws) Red Hat Enterprise Linux Atomic etcd Container Image (rhel7/etcd) Red Hat Enterprise Linux Atomic flannel Container Image (rhel7/flannel) Red Hat Enterprise Linux Atomic open-vm-tools Container Image (rhel7/open-vm-tools) Red Hat Enterprise Linux Atomic openscap Container Image (rhel7/openscap) Red Hat Enterprise Linux Atomic rsyslog Container Image (rhel7/rsyslog) Red Hat Enterprise Linux Atomic sadc Container Image (rhel7/sadc) Red Hat Enterprise Linux Container Image (rhel7.5, rhel7, rhel7/rhel, rhel) 21.3. New Features Distribution of architecture-specific base images will change in 7.6 Currently, the multi-architecture base OS images are available in the rhel7 repository and in the architecture-specific repository, for example rhel7/ppc64le . This will continue until RHEL Atomic Host 7.6. With RHEL Atomic Host 7.6, base images for all architectures will be available in the rhel7 repository. When you pull the base image, the image for the correct architecture will be pulled automatically based on the architecture you are using. Users of the architecture-specific repositories will need to update the from line in dockerfiles.

Commands:
Chapter 24. Kernel e1000e cards might not get an IPv4 address Some e1000e network interface cards (NICs) might fail to get an IPv4 address assigned after the system is rebooted. To work around this problem, add the following line to the /etc/sysconfig/network-scripts/ifcfg-<interface> file: (BZ#822725) System freeze when loading Intel Skylake integrated graphics cards On systems with Intel Skylake integrated graphics cards present, the system can freeze during the initial boot process when it starts to load the video driver. This known issue is caused by a race condition in version 2.6.32 of the kernel firmware loader. As a workaround, if using the installer CD, try installing with the basic video driver. Otherwise, add the nomodeset parameter to the kernel command line, which instructs the kernel to not load Intel Skylake integrated graphics driver and use BIOS modes instead. (BZ#1309875) ecb fails when dracut is not upgraded When upgrading only the kernel rpm from Red Hat Enterprise Linux 6.7 to version 6.8, it is necessary to also upgrade the dracut package to the latest version, that is dracut-004-409.el6.rpm, to enable the ecb module to work. The ecb kernel module is needed by the drbg kernel module when using the AES implementation on non-x86 architectures. Otherwise, the drbg AES implementation fails with a warning message while other drbg modules still work. (BZ#1315832) kernel panic in xfrm6 stack During an overload and when Ethernet Flow Control is disabled, if IPSec policy is configured for the IPv6 protocol, sending UDP datagrams over the IPv6 protocol can lead to a kernel panic. So far, there is no workaround or fix available. (BZ#1327680) Intel Xeon v5 causes GPU to hang On GT3 and GT4 architectures, Intel Xeon v5 integrated graphics can experience problems with GPU lock-up, leading to GPU hang. As a workaround, add the i915.enable_rc6=0 option to the kernel command line to disable the RC6 power saving state on Intel Xeon v5. (BZ#1323945)

Commands:
LINKDELAY=10
Chapter 5. Using Smart Cards with the Enterprise Security Client When a smart card is enrolled , it means that user-specific keys and certificates are generated and placed on the card. In Red Hat Enterprise Linux, the interface that works between the user and the system which issues certificates is the Enterprise Security Client . The Enterprise Security Client recognizes when a smart card is inserted (or removed) and signals the appropriate subsystem in Red Hat Certificate System. That subsystem then generates the certificate materials and sends them to the Enterprise Security Client, which writes them to the token. That is the enrollment process. The following sections contain basic instructions on using the Enterprise Security Client for token enrollment, formatting, and password reset operations. 5.1. Supported Smart Cards The Enterprise Security Client supports smart cards which are JavaCard 2.1 or higher and Global Platform 2.01-compliant and was tested using the following cards: Safenet 330J Java smart cards Gemalto 64K V2 tokens, both as a smart card and GemPCKey USB form factor key Gemalto GCx4 72K and TOPDLGX4 144K common access cards (CAC) Oberthur ID One V5.2 common access cards (CAC) Personal identity verification (PIV) cards, compliant with FIPS 201 Note Enterprise Security Client does not provision PIV or CAC cards, but it will read them and display information. Smart card testing was conducted using two card readers: SCM SCR331 CCID OMNIKEY 3121 The only card manager applet supported with Enterprise Security Client is the CoolKey applet.

Commands: