mtpti5iD/redhat-docs_dataset huggingface dataset:
4.2.2. Displaying Physical Volumes There are three commands you can use to display properties of LVM physical volumes: pvs , pvdisplay , and pvscan . The pvs command provides physical volume information in a configurable form, displaying one line per physical volume. The pvs command provides a great deal of format control, and is useful for scripting. For information on using the pvs command to customize your output, see Section 4.9, "Customized Reporting for LVM" . The pvdisplay command provides a verbose multi-line output for each physical volume. It displays physical properties (size, extents, volume group, etc.) in a fixed format. The following example shows the output of the pvdisplay command for a single physical volume. The pvscan command scans all supported LVM block devices in the system for physical volumes. The following command shows all physical devices found: You can define a filter in the lvm.conf so that this command will avoid scanning specific physical volumes. For information on using filters to control which devices are scanned, see Section 4.6, "Controlling LVM Device Scans with Filters" .

Commands:
pvdisplay --- Physical volume --- PV Name /dev/sdc1 VG Name new_vg PV Size 17.14 GB / not usable 3.40 MB Allocatable yes PE Size (KByte) 4096 Total PE 4388 Free PE 4375 Allocated PE 13 PV UUID Joqlch-yWSj-kuEn-IdwM-01S9-XO8M-mcpsVe
pvscan PV /dev/sdb2 VG vg0 lvm2 [964.00 MB / 0 free] PV /dev/sdc1 VG vg0 lvm2 [964.00 MB / 428.00 MB free] PV /dev/sdc2 lvm2 [964.84 MB] Total: 3 [2.83 GB] / in use: 2 [1.88 GB] / in no VG: 1 [964.84 MB]
13.2.18. Domain Options: Using DNS Service Discovery DNS service discovery, defined in RFC 2782 , allows applications to check the SRV records in a given domain for certain services of a certain type; it then returns any servers discovered of that type. With SSSD, the identity and authentication providers can either be explicitly defined (by IP address or host name) or they can be discovered dynamically, using service discovery. If no provider server is listed - for example, if id_provider = ldap is set without a corresponding ldap_uri parameter - then discovery is automatically used. The DNS discovery query has this format: For example, a scan for an LDAP server using TCP in the example.com domain looks like this: Note For every service with which to use service discovery, add a special DNS record to the DNS server: For SSSD, the service type is LDAP by default, and almost all services use TCP (except for Kerberos, which starts with UDP). For service discovery to be enabled, the only thing that is required is the domain name. The default is to use the domain portion of the machine host name, but another domain can be specified (using the dns_discovery_domain parameter). So, by default, no additional configuration needs to be made for service discovery - with one exception. The password change provider has server discovery disabled by default, and it must be explicitly enabled by setting a service type. While no configuration is necessary, it is possible for server discovery to be customized by using a different DNS domain ( dns_discovery_domain ) or by setting a different service type to scan for. For example: Lastly, service discovery is never used with backup servers; it is only used for the primary server for a provider. What this means is that discovery can be used initially to locate a server, and then SSSD can fall back to using a backup server. To use discovery for the primary server, use _srv_ as the primary server value, and then list the backup servers. For example: Note Service discovery cannot be used with backup servers, only primary servers. If a DNS lookup fails to return an IPv4 address for a host name, SSSD attempts to look up an IPv6 address before returning a failure. This only ensures that the asynchronous resolver identifies the correct address. The host name resolution behavior is configured in the lookup family order option in the sssd.conf configuration file.

Commands:
_ service ._ protocol.domain
_ldap._tcp.example.com
_service._protocol._domain TTL priority weight port hostname
[domain/EXAMPLE] chpass_provider = ldap ldap_chpass_dns_service_name = ldap
[domain/EXAMPLE] id _provider = ldap dns_discovery_domain = corp.example.com ldap_dns_service_name = ldap chpass_provider = krb5 ldap_chpass_dns_service_name = kerberos
[domain/EXAMPLE] id _provider = ldap ldap_uri = _srv_ ldap_backup_uri = ldap://ldap2.example.com auth_provider = krb5 krb5_server = _srv_ krb5_backup_server = kdc2.example.com chpass_provider = krb5 ldap_chpass_dns_service_name = kerberos ldap_chpass_uri = _srv_ ldap_chpass_backup_uri = kdc2.example.com
Chapter 23. Identifying virtual devices with tags 23.1. Tagging virtual devices In Red Hat OpenStack Platform, if you launch a VM instance with multiple network interfaces or block devices, you can use device tagging to communicate the intended role of each device to the instance operating system. Tags are assigned to devices at instance boot time, and are available to the instance operating system through the metadata API and the configuration drive (if enabled). Procedure To tag virtual devices, use the tag parameters, --block-device and --nic , when creating instances. Example The resulting tags are added to the existing instance metadata and are available through both the metadata API, and on the configuration drive. In this example, the following devices section populates the metadata: Sample contents of the meta_data.json file: The device tag metadata is available using GET /openstack/latest/meta_data.json from the metadata API. If the configuration drive is enabled, and mounted under /configdrive in the instance operating system, the metadata is also present in /configdrive/openstack/latest/meta_data.json .

Commands:
nova boot test-vm --flavor m1.tiny --image cirros --nic net-id=55411ca3-83dd-4036-9158-bf4a6b8fb5ce,tag=nfv1 --block-device id=b8c9bef7-aa1d-4bf4-a14d-17674b370e13,bus=virtio,tag=database-server NFVappServer
{ "devices": [ { "type": "nic", "bus": "pci", "address": "0030:00:02.0", "mac": "aa:00:00:00:01", "tags": ["nfv1"] }, { "type": "disk", "bus": "pci", "address": "0030:00:07.0", "serial": "disk-vol-227", "tags": ["database-server"] } ] }
Chapter 37. Red Hat Enterprise Linux Atomic Host 7.2.7 This release doesn't include any updated images and the latest version of Atomic Host cloud images remains at 7.2.6-1. The latest "Red Hat Atomic Host Installer" ISO image remains at 7.2.3-1 as well. OSTree has been updated and new deployments can be created with any of those images and updated to the latest release by running the atomic host upgrade command. 37.1. Atomic Host OStree update : New Tree Version: 7.2.7 (hash: dae35767902aad07b087d359be20f234d244da79fdd4734cd2fbc3ee39b12cf8) Changes since Tree Version 7.2.6 (hash: 347c3f5eb641e69fc602878c646cf42c4bcd5d9f36847a1f24ff8f3ec80f17b1) Updated packages : selinux-policy-3.13.1-63.atomic.el7.7 37.2. Extras Updated packages : docker-1.10.3-46.el7.14 docker-latest-1.12.1-2.el7 etcd-2.3.7-4.el7 oci-register-machine-0-1.8.gitaf6c129.el7 37.2.1. Container Images Updated : Red Hat Enterprise Linux Container Image (rhel7/rhel) Red Hat Enterprise Linux Atomic Tools Container Image (rhel7/rhel-tools) Red Hat Enterprise Linux Atomic rsyslog Container Image (rhel7/rsyslog) Red Hat Enterprise Linux Atomic sadc Container Image (rhel7/sadc) 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 Kubernetes-controller Container Image (rhel7/kubernetes-controller-mgr) Red Hat Enterprise Linux Atomic Kubernetes-apiserver Container Image (rhel7/kubernetes-apiserver) Red Hat Enterprise Linux Atomic Kubernetes-scheduler Container Image (rhel7/kubernetes-scheduler) Red Hat Enterprise Linux Atomic SSSD Container Image (rhel7/sssd) (Technology Preview) Red Hat Enterprise Linux Atomic openscap Container Image (rhel7/openscap) (Technology Preview) 37.3. New Features docker-latest has been upgraded to version 1.12.1 The docker-latest packages are now version 1.12.1. The following article has been updated to reflect the changes Introducing docker-latest for RHEL 7 and RHEL Atomic Host . docker 1.12 uses runc as a runtime environment Since docker version 1.11, runc is used instead of libcontainer for container runtime. The docker-latest packages contain 1.12, and runc can be found in /usr/libexec/docker/docker-runc . However, docker-runc is for internal use only by docker. If you want to use the runc command, you still need the runc package installed on your system. For RHEL Atomic Host, it is part of the OSTree by default, and for Red Hat Enterprise Linux 7, it is available as a separate package. Important Red Hat does not support modifying which runc binary is used by docker. docker swarm is now available As of 1.12 release, the upstream Docker project has embedded Docker Swarm in the docker binary. To avoid any unintended bugs, Red Hat has chosen to include Swarm as an unsupported add-on. For container orchestration, Red Hat recommends OpenShift and Kubernetes.

Commands:
Chapter 9. Enabling FIPS mode with RHEL image builder You can create a customized image and boot a FIPS-enabled RHEL image. Before you compose the image, you must change the value of the fips directive in your blueprint. Prerequisites You are logged in as the root user or a user who is a member of the weldr group. Procedure Create a plain text file in the Tom's Obvious, Minimal Language (TOML) format with the following content: Import the blueprint to the RHEL image builder server: List the existing blueprints to check whether the created blueprint is successfully imported and exists: Check whether the components and versions listed in the blueprint and their dependencies are valid: Build the customized RHEL image: Review the image status: Download the image: RHEL image builder downloads the image to the current directory path. The UUID number and the image size are displayed alongside: Verification Log in to the system image with the username and password that you configured in your blueprint. Check if FIPS mode is enabled:

Commands:
name = "system-fips-mode-enabled" description = "blueprint with FIPS enabled " version = "0.0.1" [customizations] fips = true [[customizations.user]] name = "admin" password = "admin" groups = ["users", "wheel"]
composer-cli blueprints push <blueprint-name> .toml
composer-cli blueprints show <blueprint-name>
composer-cli blueprints depsolve <blueprint-name>
composer-cli compose start \ <blueprint-name> \ <image-type> \
composer-cli compose status ... <UUID> FINISHED <date> <blueprint-name> <blueprint-version> <image-type> ...
composer-cli compose image <UUID>
<UUID-image-name.type> : <size> MB
fips-mode-setup --check FIPS mode is enabled.
Understanding OpenShift GitOps Red Hat OpenShift GitOps 1.15 Introduction to OpenShift GitOps Red Hat OpenShift Documentation Team

Commands:
oc adm must-gather --image=registry.redhat.io/openshift-gitops-1/must-gather-rhel8:v1.10.0
oc adm must-gather -- /usr/bin/gather_audit_logs
NAMESPACE NAME READY STATUS RESTARTS AGE openshift-must-gather-5drcj must-gather-bklx4 2/2 Running 0 72s openshift-must-gather-5drcj must-gather-s8sdh 2/2 Running 0 72s
oc adm must-gather --image=registry.redhat.io/openshift-gitops-1/must-gather-rhel8:v1.10.0
oc adm must-gather --image=registry.redhat.io/openshift-gitops-1/must-gather-rhel8:<image_version_tag> 1
oc adm must-gather --image=registry.redhat.io/openshift-gitops-1/must-gather-rhel8:v1.10.0
tar -cvaf must-gather.tar.gz must-gather.local.4157245944708210399 1
7.127. mgetty 7.127.1. RHBA-2015:0711 - mgetty bug fix update Updated mgetty packages that fix one bug are now available for Red Hat Enterprise Linux 6. The mgetty packages contain a modem getty utility that allows logins over a serial line, for example using a modem. If you are using a Class 2 or Class 2.0 modem, mgetty can receive faxes. The mgetty-sendfax package is required to send faxes. Bug Fix BZ# 729003 Missing files with debug information have been added to the mgetty-debuginfo packages for seven binary files shipped in the mgetty package. Users of mgetty are advised to upgrade to these updated packages, which fix this bug.

Commands:
Chapter 1. Navigating CodeReady Workspaces using the Dashboard The Dashboard is accessible on your cluster from a URL like http:// <che-instance> . <IP-address> .mycluster.mycompany.com/dashboard/ . This section describes how to access this URL on OpenShift. 1.1. Logging in to CodeReady Workspaces on OpenShift for the first time using OAuth This section describes how to log in to CodeReady Workspaces on OpenShift for the first time using OAuth. Prerequisites Contact the administrator of the OpenShift instance to obtain the Red Hat CodeReady Workspaces URL . Procedure Navigate to the Red Hat CodeReady Workspaces URL to display the Red Hat CodeReady Workspaces login page. Choose the OpenShift OAuth option. The Authorize Access page is displayed. Click on the Allow selected permissions button. Update the account information: specify the Username , Email , First name and Last name fields and click the Submit button. Validation steps The browser displays the Red Hat CodeReady Workspaces Dashboard . 1.2. Logging in to CodeReady Workspaces on OpenShift for the first time registering as a new user This section describes how to log in to CodeReady Workspaces on OpenShift for the first time registering as a new user. Prerequisites Contact the administrator of the OpenShift instance to obtain the Red Hat CodeReady Workspaces URL . Procedure Navigate to the Red Hat CodeReady Workspaces URL to display the Red Hat CodeReady Workspaces login page. Choose the Register as a new user option. Update the account information: specify the Username , Email , First name and Last name field and click the Submit button. Validation steps The browser displays the Red Hat CodeReady Workspaces Dashboard . 1.3. Finding CodeReady Workspaces cluster URL using the OpenShift 4 CLI This section describes how to obtain the CodeReady Workspaces cluster URL using the OpenShift 4 CLI (command line interface). The URL can be retrieved from the OpenShift logs or from the checluster Custom Resource. Prerequisites An instance of Red Hat CodeReady Workspaces running on OpenShift. User is located in a CodeReady Workspaces installation namespace. Procedure To retrieve the CodeReady Workspaces cluster URL from the checluster CR (Custom Resource), run: USD oc get checluster --output jsonpath='{.items[0].status.cheURL}' Alternatively, to retrieve the CodeReady Workspaces cluster URL from the OpenShift logs, run: USD oc logs --tail=10 `(oc get pods -o name | grep operator)` | \ grep "available at" | \ awk -F'available at: ' '{print USD2}' | sed 's/"//'

Commands:
oc get checluster --output jsonpath='{.items[0].status.cheURL}'
oc logs --tail=10 `(oc get pods -o name | grep operator)` | grep "available at" | awk -F'available at: ' '{print USD2}' | sed 's/"//'
7.321. polkit 7.321.1. RHSA-2013:1270 - Important: polkit security update Updated polkit packages that fix one security issue are now available for Red Hat Enterprise Linux 6. The Red Hat Security Response Team has rated this update as having important security impact. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available from the CVE link associated with the description below. PolicyKit is a toolkit for defining and handling authorizations. Security Fix CVE-2013-4288 A race condition was found in the way the PolicyKit pkcheck utility checked process authorization when the process was specified by its process ID via the --process option. A local user could use this flaw to bypass intended PolicyKit authorizations and escalate their privileges. Note: Applications that invoke pkcheck with the --process option need to be modified to use the pid,pid-start-time,uid argument for that option, to allow pkcheck to check process authorization correctly. Red Hat would like to thank Sebastian Krahmer of the SUSE Security Team for reporting this issue. All polkit users should upgrade to these updated packages, which contain a backported patch to correct this issue. The system must be rebooted for this update to take effect.

Commands:
Chapter 22. Write Barriers A write barrier is a kernel mechanism used to ensure that file system metadata is correctly written and ordered on persistent storage, even when storage devices with volatile write caches lose power. File systems with write barriers enabled ensures that data transmitted via fsync() is persistent throughout a power loss. Enabling write barriers incurs a substantial performance penalty for some applications. Specifically, applications that use fsync() heavily or create and delete many small files will likely run much slower. 22.1. Importance of Write Barriers File systems safely update metadata, ensuring consistency. Journalled file systems bundle metadata updates into transactions and send them to persistent storage in the following manner: The file system sends the body of the transaction to the storage device. The file system sends a commit block. If the transaction and its corresponding commit block are written to disk, the file system assumes that the transaction will survive any power failure. However, file system integrity during power failure becomes more complex for storage devices with extra caches. Storage target devices like local S-ATA or SAS drives may have write caches ranging from 32MB to 64MB in size (with modern drives). Hardware RAID controllers often contain internal write caches. Further, high end arrays, like those from NetApp, IBM, Hitachi and EMC (among others), also have large caches. Storage devices with write caches report I/O as "complete" when the data is in cache; if the cache loses power, it loses its data as well. Worse, as the cache de-stages to persistent storage, it may change the original metadata ordering. When this occurs, the commit block may be present on disk without having the complete, associated transaction in place. As a result, the journal may replay these uninitialized transaction blocks into the file system during post-power-loss recovery; this will cause data inconsistency and corruption. How Write Barriers Work Write barriers are implemented in the Linux kernel via storage write cache flushes before and after the I/O, which is order-critical . After the transaction is written, the storage cache is flushed, the commit block is written, and the cache is flushed again. This ensures that: The disk contains all the data. No re-ordering has occurred. With barriers enabled, an fsync() call also issues a storage cache flush. This guarantees that file data is persistent on disk even if power loss occurs shortly after fsync() returns.

Commands:
4.4.2. Persistent Device Numbers Major and minor device numbers are allocated dynamically at module load. Some applications work best if the block device always is activated with the same device (major and minor) number. You can specify these with the lvcreate and the lvchange commands by using the following arguments: Use a large minor number to be sure that it hasn't already been allocated to another device dynamically. If you are exporting a file system using NFS, specifying the fsid parameter in the exports file may avoid the need to set a persistent device number within LVM.

Commands:
--persistent y --major major --minor minor
Chapter 44. Installing and running IBM WebSphere Application Server IBM WebSphere Application Server must be installed and running for you to apply many of the configurations that accommodate KIE Server. This section describes how to install and start IBM WebSphere. For the most up-to-date and detailed installation instructions, see the IBM Knowledge Center . Procedure Download IBM Installation Manager version 1.8.5 or later from the IBM Installation Manager and Packaging Utility download links page. IBM Installation Manager is required for installing IBM WebSphere. Extract the downloaded archive and run the following command as the root user in the new directory: The IBM Installation Manager opens. Go to File Preferences and click Add Repository . In the Add Repository window, enter the repository URL for IBM WebSphere 9.0. You can find all the repository URLs in the Online product repositories for IBM WebSphere Application Server offerings page of the IBM Knowledge Center. In your command terminal, navigate to the IBM WebSphere Application Server folder location that you specified during the installation. Change to the /bin directory and run a command similar to the following example to create an IBM WebSphere profile, user name, and password. A profile defines the run time environment. The profile includes all the files that the server processes in the runtime environment and that you can change. The user is required for login. In your command terminal, navigate to the bin directory within the profile that you created (for example, /profiles/testprofile/bin ) and run the following command to start the IBM WebSphere Application Server instance: Replace <SERVER_NAME> with the IBM WebSphere Application Server name defined in Servers Server Types IBM WebSphere Application Servers of the WebSphere Integrated Solutions Console. Open the following URL in a web browser: <HOST> is the system name or IP address of the target server. For example, to start the WebSphere Integrated Solutions Console for a local instance of IBM WebSphere running on your system, enter the following URL in a web browser: When the login page of the WebSphere Integrated Solutions Console appears, enter your administrative credentials.

Commands:
sudo ./install
sudo ./manageprofiles.sh -create -profileName testprofile -profilePath /profiles/testprofile -adminUserName websphere -adminPassword password123
sudo ./startServer.sh <SERVER_NAME>
http://<HOST>:9060/ibm/console
http://localhost:9060/ibm/console
Chapter 3. Enabling Linux control group version 2 (cgroup v2) By default, OpenShift Container Platform uses Linux control group version 1 (cgroup v1) in your cluster. You can enable Linux control group version 2 (cgroup v2) upon installation. Enabling cgroup v2 in OpenShift Container Platform disables all cgroup version 1 controllers and hierarchies in your cluster. cgroup v2 is the version of the Linux cgroup API. cgroup v2 offers several improvements over cgroup v1, including a unified hierarchy, safer sub-tree delegation, new features such as Pressure Stall Information , and enhanced resource management and isolation. You can switch between cgroup v1 and cgroup v2, as needed, by editing the node.config object. For more information, see "Configuring the Linux cgroup on your nodes" in the "Additional resources" of this section. 3.1. Enabling Linux cgroup v2 during installation You can enable Linux control group version 2 (cgroup v2) when you install a cluster by creating installation manifests. Procedure Create or edit the node.config object to specify the v2 cgroup: apiVersion: config.openshift.io/v1 kind: Node metadata: name: cluster spec: cgroupMode: "v2" Proceed with the installation as usual. Additional resources OpenShift Container Platform installation overview Configuring the Linux cgroup on your nodes

Commands:
apiVersion: config.openshift.io/v1 kind: Node metadata: name: cluster spec: cgroupMode: "v2"
Chapter 10. Improving Import Performance Very large entry sizes or a large number of entries can negatively impact server performance during import operations. This section describes how to tune both Directory Server settings and operating system settings to improve the import performance. 10.1. Tuning Directory Server for Large Database Imports and Imports with Large Attributes Update the entry cache in the following scenarios: You want to import a very large database. You want to import a database with large attributes, such as binary attributes that store certificate chains or images. For details, about setting the size of the entry cache, see Section 6.1, "The Database and Entry Cache Auto-Sizing Feature" and Section 6.3, "Manually Setting the Entry Cache Size" .

Commands: