mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 1. Preparing to deploy OpenShift Data Foundation When you deploy OpenShift Data Foundation on OpenShift Container Platform using local storage devices, you can create internal cluster resources. This approach internally provisions base services and all applications can access additional storage classes. Before you begin the deployment of Red Hat OpenShift Data Foundation using local storage, ensure that your resource requirements are met. See requirements for installing OpenShift Data Foundation using local storage devices . On the external key management system (KMS), When the Token authentication method is selected for encryption then refer to Enabling cluster-wide encryption with the Token authentication using KMS . Ensure that you are using signed certificates on your Vault servers. After you have addressed the above, follow these steps in the order given: Install the Red Hat OpenShift Data Foundation Operator . Install Local Storage Operator . Find the available storage devices . Create the OpenShift Data Foundation cluster service on IBM Z . 1.1. Requirements for installing OpenShift Data Foundation using local storage devices Node requirements The cluster must consist of at least three OpenShift Container Platform worker or infrastructure nodes with locally attached-storage devices on each of them. Each of the three selected nodes must have at least one raw block device available. OpenShift Data Foundation uses the one or more available raw block devices. Note Make sure that the devices have a unique by-id device name for each available raw block device. The devices you use must be empty, the disks must not include Physical Volumes (PVs), Volume Groups (VGs), or Logical Volumes (LVs) remaining on the disk. For more information, see the Resource requirements section in the Planning guide . 1.2. Enabling cluster-wide encryption with KMS using the Token authentication method You can enable the key value backend path and policy in the vault for token authentication. Prerequisites Administrator access to the vault. A valid Red Hat OpenShift Data Foundation Advanced subscription. For more information, see the knowledgebase article on OpenShift Data Foundation subscriptions . Carefully, select a unique path name as the backend path that follows the naming convention since you cannot change it later. Procedure Enable the Key/Value (KV) backend path in the vault. For vault KV secret engine API, version 1: For vault KV secret engine API, version 2: Create a policy to restrict the users to perform a write or delete operation on the secret: Create a token that matches the above policy:

Commands:
vault secrets enable -path=odf kv
vault secrets enable -path=odf kv-v2
echo ' path "odf/*" { capabilities = ["create", "read", "update", "delete", "list"] } path "sys/mounts" { capabilities = ["read"] }'| vault policy write odf -
vault token create -policy=odf -format json
probe::nfs.proc.read_setup Name probe::nfs.proc.read_setup - NFS client setting up a read RPC task Synopsis nfs.proc.read_setup Values offset the file offset server_ip IP address of server prot transfer protocol version NFS version count read bytes in this execution size read bytes in this execution Description The read_setup function is used to setup a read RPC task. It is not doing the actual read operation.

Commands:
8.3. SSSD SSSD (System Security Services Daemon) offers access to remote identity and authentication mechanisms, referred to as providers . SSSD allows these providers to be configured as SSSD back-ends, abstracting the actual (local and network) identity and authentication sources. It also allows any kind of identity data provider to be plugged in. A domain is a database containing user information, which can serve as the source of a provider's identity information. Multiple identity providers are supported, allowing two or more identity servers to act as separate user namespaces. Collected information is available to applications on the front-end through standard PAM and NSS interfaces. SSSD runs as a suite of services, independent of the applications that use it. Those applications therefore no longer need to make their own connections to remote domains, or even be aware of which is being used. Robust local caching of identity and group membership information allows operations regardless of where identity comes from (e.g., LDAP, NIS, IPA, DB, Samba, and so on), offers improved performance, and allows authentication to be performed even when operating offline and online authentication is unavailable. SSSD also allows the use of multiple providers of the same type (e.g., multiple LDAP providers) and allows domain-qualified identity requests to be resolved by those different providers. Further details can found in the Red Hat Enterprise Linux 6 Deployment Guide.

Commands:
Chapter 6. Finding More Information The following table includes additional Red Hat documentation for reference: The Red Hat OpenStack Platform documentation suite can be found here: Red Hat OpenStack Platform Documentation Suite Table 6.1. List of Available Documentation Component Reference Red Hat Enterprise Linux Red Hat OpenStack Platform is supported on Red Hat Enterprise Linux 8.0. For information on installing Red Hat Enterprise Linux, see the corresponding installation guide at: Red Hat Enterprise Linux Documentation Suite . Red Hat OpenStack Platform To install OpenStack components and their dependencies, use the Red Hat OpenStack Platform director. The director uses a basic OpenStack installation as the undercloud to install, configure, and manage the OpenStack nodes in the final overcloud . Ensure that you have one extra host machine for the installation of the undercloud, in addition to the environment necessary for the deployed overcloud. For detailed instructions, see Red Hat OpenStack Platform Director Installation and Usage . For information on configuring advanced features for a Red Hat OpenStack Platform enterprise environment using the Red Hat OpenStack Platform director, such as network isolation, storage configuration, SSL communication, and general configuration method, see Advanced Overcloud Customization . NFV Documentation For more details on planning and configuring your Red Hat OpenStack Platform deployment with single root I/O virtualization (SR-IOV) and Open vSwitch with Data Plane Development Kit (OVS-DPDK), see Network Function Virtualization Planning and Configuration Guide .

Commands:
System Administrator's Guide Red Hat Enterprise Linux 7 Deployment, configuration, and administration of RHEL 7 Abstract The System Administrator's Guide documents relevant information regarding the deployment, configuration, and administration of Red Hat Enterprise Linux 7. It is oriented towards system administrators with a basic understanding of the system. Note To expand your expertise, you might also be interested in the Red Hat System Administration I (RH124) , Red Hat System Administration II (RH134) , Red Hat System Administration III (RH254) , or RHCSA Rapid Track (RH199) training courses. If you want to use Red Hat Enterprise Linux 7 with the Linux Containers functionality, see Product Documentation for Red Hat Enterprise Linux Atomic Host . For an overview of general Linux Containers concept and their current capabilities implemented in Red Hat Enterprise Linux 7, see Overview of Containers in Red Hat Systems . The topics related to containers management and administration are described in the Red Hat Enterprise Linux Atomic Host 7 Managing Containers guide.

Commands:
9.8.2. NFS security with AUTH_GSS The release of NFSv4 brought a revolution to NFS security by mandating the implementation of RPCSEC_GSS and the Kerberos version 5 GSS-API mechanism. However, RPCSEC_GSS and the Kerberos mechanism are also available for all versions of NFS. In FIPS mode, only FIPS-approved algorithms can be used. With the RPCSEC_GSS Kerberos mechanism, the server no longer depends on the client to correctly represent which user is accessing the file, as is the case with AUTH_SYS. Instead, it uses cryptography to authenticate users to the server, preventing a malicious client from impersonating a user without having that user's kerberos credentials. Note It is assumed that a Kerberos ticket-granting server (KDC) is installed and configured correctly, prior to configuring an NFSv4 server. Kerberos is a network authentication system which allows clients and servers to authenticate to each other through use of symmetric encryption and a trusted third party, the KDC. For more information on Kerberos see Red Hat's Identity Management Guide . To set up RPCSEC_GSS, use the following procedure: Procedure 9.4. Set up RPCSEC_GSS Create nfs/client. mydomain @ MYREALM and nfs/server. mydomain @ MYREALM principals. Add the corresponding keys to keytabs for the client and server. On the server side, add sec=krb5,krb5i,krb5p to the export. To continue allowing AUTH_SYS, add sec=sys,krb5,krb5i,krb5p instead. On the client side, add sec=krb5 (or sec=krb5i , or sec=krb5p depending on the set up) to the mount options. For more information, such as the difference between krb5 , krb5i , and krb5p , refer to the exports and nfs man pages or to Section 9.5, "Common NFS Mount Options" . For more information on the RPCSEC_GSS framework, including how rpc.svcgssd and rpc.gssd inter-operate, refer to http://www.citi.umich.edu/projects/nfsv4/gssd/ . 9.8.2.1. NFS security with NFSv4 NFSv4 includes ACL support based on the Microsoft Windows NT model, not the POSIX model, because of the former's features and wide deployment. Another important security feature of NFSv4 is the removal of the use of the MOUNT protocol for mounting file systems. This protocol presented possible security holes because of the way that it processed file handles.

Commands:
19.6. Virtualization Virtualization Getting Started Guide The Virtualization Getting Started Guide is an introduction to virtualization on Red Hat Enterprise Linux 7. Virtualization Deployment and Administration Guide The Virtualization Deployment and Administration Guide provides information on installing, configuring, and managing virtualization on Red Hat Enterprise Linux 7. Virtualization Security Guide The Virtualization Security Guide provides an overview of virtualization security technologies provided by Red Hat, and provides recommendations for securing virtualization hosts, guests, and shared infrastructure and resources in virtualized environments. Virtualization Tuning and Optimization Guide The Virtualization Tuning and Optimization Guide covers KVM and virtualization performance. Within this guide you can find tips and suggestions for making full use of KVM performance features and options for your host systems and virtualized guests.

Commands:
Chapter 1. Remediations overview After identifying the highest remediation priorities in your Red Hat Enterprise Linux (RHEL) infrastructure, you can create remediation playbooks that fix those issues. Subscription requirements Red Hat Insights for Red Hat Enterprise Linux is included with every RHEL subscription. No additional subscriptions are required to use Insights remediation features. User requirements All Insights users will automatically have access to read, create, and manage remediation playbooks. 1.1. User Access settings in the Red Hat Hybrid Cloud Console All users on your account have access to most of the data in Insights for Red Hat Enterprise Linux. 1.1.1. Predefined User Access groups and roles To make groups and roles easier to manage, Red Hat provides two predefined groups and a set of predefined roles. 1.1.1.1. Predefined groups The Default access group contains all users in your organization. Many predefined roles are assigned to this group. It is automatically updated by Red Hat. Note If the Organization Administrator makes changes to the Default access group its name changes to Custom default access group and it is no longer updated by Red Hat. The Default admin access group contains only users who have Organization Administrator permissions. This group is automatically maintained and users and roles in this group cannot be changed. 1.1.2. User Access roles for remediations users The Remediations user role enables standard or enhanced access to remediations features in Insights for Red Hat Enterprise Linux. The Remediations user role is included in the Default access group and permits access to view existing playbooks and to create new playbooks. Remediations users cannot execute playbooks on systems.

Commands:
B.45.2. RHSA-2011:0479 - Moderate: libvirt security and bug fix update Updated libvirt packages that fix one security issue and one bug are now available for Red Hat Enterprise Linux 6. The Red Hat Security Response Team has rated this update as having moderate security impact. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) associated with each description below. The libvirt library is a C API for managing and interacting with the virtualization capabilities of Linux and other operating systems. In addition, libvirt provides tools for remotely managing virtualized systems. CVE-2011-1486 A flaw was found in the way libvirtd handled error reporting for concurrent connections. A remote attacker able to establish read-only connections to libvirtd on a server could use this flaw to crash libvirtd. Bug Fix BZ# 668692 Previously, running qemu under a different UID prevented it from accessing files with mode 0660 permissions that were owned by a different user, but by a group that qemu was a member of. All libvirt users are advised to upgrade to these updated packages, which contain backported patches to resolve these issues. After installing the updated packages, libvirtd must be restarted ("service libvirtd restart") for this update to take effect.

Commands:
3.12. Partial Results Mode JBoss Data Virtualization supports a partial results query mode. This mode changes the behavior of the query processor so the server returns results even when some data sources are unavailable. For example, suppose that two data sources exist for different suppliers and your data designers have created a virtual group that creates a union between the information from the two suppliers. If your application submits a query without using partial results query mode and one of the suppliers'\u0080\u0099 databases is down, the query against the virtual group returns an exception. However, if your application runs the same query in partial results query mode, the server returns data from the running data source and no data from the data source that is down. When using partial results mode, if a source throws an exception during processing it does not cause the user's query to fail. Rather, that source is treated as returning no more rows after the failure point. Most commonly, that source will return 0 rows. This behavior is most useful when using UNION or OUTER JOIN queries as these operations handle missing information in a useful way. Most other kinds of queries will simply return 0 rows to the user when used in partial results mode and the source is unavailable. Note In some instances, (typically when you are using JDBC sources), if the source is not available initially, its absence will prevent Teiid from automatically determining the appropriate set of source capabilities. If you see an exception indicating that the capabilities for an unavailable source are not valid in partial results mode, then it may be necessary to manually set the database version or similar property on the translator to ensure that the capabilities are known even if the source is not available.

Commands:
4.6. Using Function Modifiers In some cases you may need to translate the function differently or even insert additional function calls above or below the function being translated. The JDBC translator provides an abstract class FunctionModifier for this purpose. During the start method a modifier instance can be registered against a given function name via a call to JDBCExecutionFactory.registerFunctionModifier . The FunctionModifier has a method called translate . Use the translate method to change the way the function is represented. An example of overriding the translate method to change the MOD(a, b) function into an infix operator for Sybase (a % b). The translate method returns a list of strings and language objects that will be assembled by the translator into a final string. The strings will be used as is and the language objects will be further processed by the translator. public class ModFunctionModifier extends FunctionModifier { public List translate(Function function) { List parts = new ArrayList(); parts.add("("); Expression[] args = function.getParameters().toArray(new Expression[0]); parts.add(args[0]); parts.add(" % "); parts.add(args[1]); parts.add(")"); return parts; } } In addition to building your own FunctionModifiers, there are a number of pre-built generic function modifiers that are provided with the translator. Table 4.2. Common Modifiers Modifier Description AliasModifier Handles renaming a function ("ucase" to "upper" for example) EscapeSyntaxModifier Wraps a function in the standard JDBC escape syntax for functions: {fn xxxx()} To register the function modifiers for your supported functions, you must call the ExecutionFactory.registerFunctionModifier(String name, FunctionModifier modifier) method. public class ExtendedJDBCExecutionFactory extends JDBCExecutionFactory { @Override public void start() { super.start(); // register functions. registerFunctionModifier("abs", new MyAbsModifier()); registerFunctionModifier("concat", new AliasModifier("concat2")); } } Support for the two functions being registered ("abs" and "concat") must be declared in the capabilities as well. Functions that do not have modifiers registered will be translated as usual.

Commands:
public class ModFunctionModifier extends FunctionModifier { public List translate(Function function) { List parts = new ArrayList(); parts.add("("); Expression[] args = function.getParameters().toArray(new Expression[0]); parts.add(args[0]); parts.add(" % "); parts.add(args[1]); parts.add(")"); return parts; } }
public class ExtendedJDBCExecutionFactory extends JDBCExecutionFactory { @Override public void start() { super.start(); // register functions. registerFunctionModifier("abs", new MyAbsModifier()); registerFunctionModifier("concat", new AliasModifier("concat2")); } }
Appendix C. Using your subscription AMQ is provided through a software subscription. To manage your subscriptions, access your account at the Red Hat Customer Portal. C.1. Accessing your account Procedure Go to access.redhat.com . If you do not already have an account, create one. Log in to your account. C.2. Activating a subscription Procedure Go to access.redhat.com . Navigate to My Subscriptions . Navigate to Activate a subscription and enter your 16-digit activation number. C.3. Downloading release files To access .zip, .tar.gz, and other release files, use the customer portal to find the relevant files for download. If you are using RPM packages or the Red Hat Maven repository, this step is not required. Procedure Open a browser and log in to the Red Hat Customer Portal Product Downloads page at access.redhat.com/downloads . Locate the Red Hat AMQ entries in the INTEGRATION AND AUTOMATION category. Select the desired AMQ product. The Software Downloads page opens. Click the Download link for your component. C.4. Registering your system for packages To install RPM packages for this product on Red Hat Enterprise Linux, your system must be registered. If you are using downloaded release files, this step is not required. Procedure Go to access.redhat.com . Navigate to Registration Assistant . Select your OS version and continue to the page. Use the listed command in your system terminal to complete the registration. For more information about registering your system, see one of the following resources: Red Hat Enterprise Linux 6 - Registering the system and managing subscriptions Red Hat Enterprise Linux 7 - Registering the system and managing subscriptions Red Hat Enterprise Linux 8 - Registering the system and managing subscriptions

Commands:
33.2. Supported DNS Zone Types IdM supports two DNS zone types: master and forward zones. Note This guide uses the BIND terminology for zone types which is different from the terminology used for Microsoft Windows DNS. Master zones in BIND serve the same purpose as forward lookup zones and reverse lookup zones in Microsoft Windows DNS. Forward zones in BIND serve the same purpose as conditional forwarders in Microsoft Windows DNS. Master DNS zones Master DNS zones contain authoritative DNS data and can accept dynamic DNS updates. This behavior is equivalent to the type master setting in standard BIND configuration. Master zones are managed using the ipa dnszone-* commands. In compliance with standard DNS rules, every master zone must contain SOA and NS records. IdM generates these records automatically when the DNS zone is created, but the NS records must be manually copied to the parent zone to create proper delegation. In accordance with standard BIND behavior, forwarding configuration specified for master zones only affects queries for names for which the server is not authoritative. Example 33.1. Example Scenario for DNS Forwarding The IdM server contains the test.example. master zone. This zone contains an NS delegation record for the sub.test.example. name. In addition, the test.example. zone is configured with the 192.0.2.254 forwarder IP address. A client querying the name nonexistent.test.example. receives the NXDomain answer, and no forwarding occurs because the IdM server is authoritative for this name. On the other hand, querying for the sub.test.example. name is forwarded to the configured forwarder 192.0.2.254 because the IdM server is not authoritative for this name. Forward DNS zones Forward DNS zones do not contain any authoritative data. All queries for names belonging to a forward DNS zone are forwarded to a specified forwarder. This behavior is equivalent to the type forward setting in standard BIND configuration. Forward zones are managed using the ipa dnsforwardzone-* commands.

Commands:
A.2.2. The dmsetup ls Command You can list the device names of mapped devices with the dmsetup ls command. You can list devices that have at least one target of a specified type with the dmsetup ls --target target_type command. For other options of the dmsetup ls , see the dmsetup man page. The following example shows the command to list the device names of currently configured mapped devices. The following example shows the command to list the devices names of currently configured mirror mappings. LVM configurations that are stacked on multipath or other device mapper devices can be complex to sort out. The dmsetup ls command provides a --tree option that displays dependencies between devices as a tree, as in the following example.

Commands:
dmsetup ls testgfsvg-testgfslv3 (253:4) testgfsvg-testgfslv2 (253:3) testgfsvg-testgfslv1 (253:2) VolGroup00-LogVol01 (253:1) VolGroup00-LogVol00 (253:0)
dmsetup ls --target mirror lock_stress-grant--02.1722 (253, 34) lock_stress-grant--01.1720 (253, 18) lock_stress-grant--03.1718 (253, 52) lock_stress-grant--02.1716 (253, 40) lock_stress-grant--03.1713 (253, 47) lock_stress-grant--02.1709 (253, 23) lock_stress-grant--01.1707 (253, 8) lock_stress-grant--01.1724 (253, 14) lock_stress-grant--03.1711 (253, 27)
dmsetup ls --tree vgtest-lvmir (253:13) ├─vgtest-lvmir_mimage_1 (253:12) │ └─mpathep1 (253:8) │ └─mpathe (253:5) │ ├─ (8:112) │ └─ (8:64) ├─vgtest-lvmir_mimage_0 (253:11) │ └─mpathcp1 (253:3) │ └─mpathc (253:2) │ ├─ (8:32) │ └─ (8:16) └─vgtest-lvmir_mlog (253:4) └─mpathfp1 (253:10) └─mpathf (253:6) ├─ (8:128) └─ (8:80)