mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 2. Multipath Devices Without DM-Multipath, each path from a server node to a storage controller is treated by the system as a separate device, even when the I/O path connects the same server node to the same storage controller. DM-Multipath provides a way of organizing the I/O paths logically, by creating a single multipath device on top of the underlying devices. 2.1. Multipath Device Identifiers Each multipath device has a World Wide Identifier (WWID), which is guaranteed to be globally unique and unchanging. By default, the name of a multipath device is set to its WWID. Alternately, you can set the user_friendly_names option in the multipath configuration file, which sets the alias to a node-unique name of the form mpath n . For example, a node with two HBAs attached to a storage controller with two ports by means of a single unzoned FC switch sees four devices: /dev/sda , /dev/sdb , dev/sdc , and /dev/sdd . DM-Multipath creates a single device with a unique WWID that reroutes I/O to those four underlying devices according to the multipath configuration. When the user_friendly_names configuration option is set to yes , the name of the multipath device is set to mpath n . When new devices are brought under the control of DM-Multipath, the new devices may be seen in two different places under the /dev directory: /dev/mapper/mpath n and /dev/dm- n . The devices in /dev/mapper are created early in the boot process. Use these devices to access the multipathed devices, for example when creating logical volumes. Any devices of the form /dev/dm- n are for internal use only and should never be used. For information on the multipath configuration defaults, including the user_friendly_names configuration option, see Section 4.3, "Configuration File Defaults" . You can also set the name of a multipath device to a name of your choosing by using the alias option in the multipaths section of the multipath configuration file. For information on the multipaths section of the multipath configuration file, see Section 4.4, "Multipaths Device Configuration Attributes" .

Commands:
7.4. Extract a Self-signed Certificate from the Keystore Procedure 7.2. Extract a Self-signed Certificate from the Keystore Run the keytool -export -alias ALIAS -keystore server.keystore -rfc -file public.cert command: Enter the keystore password when prompted: Result This creates the public.cert file that contains a certificate signed with the private key in the server.keystore .

Commands:
keytool -export -alias teiid -keystore server.keystore -rfc -file public.cert
Enter keystore password: <password>
14.22.13. Updating an Existing Network Definition File This command updates the given section of an existing network definition, taking effect immediately, without needing to destroy and re-start the network. This command is one of "add-first", "add-last", "add" (a synonym for add-last), "delete", or "modify". section is one of ""bridge", "domain", "ip", "ip-dhcp-host", "ip-dhcp-range", "forward", "forward-interface", "forward-pf", "portgroup", "dns-host", "dns-txt", or "dns-srv", each section being named by a concatenation of the xml element hierarchy leading to the element being changed. For example, "ip-dhcp-host" will change a <host> element that is contained inside a <dhcp> element inside an <ip> element of the network. xml is either the text of a complete xml element of the type being changed (for e "<host mac="00:11:22:33:44:55' ip='192.0.2.1'/>", or the name of a file that contains a complete xml element. Disambiguation is done by looking at the first character of the provided text - if the first character is "<", it is xml text, if the first character is not ">", it is the name of a file that contains the xml text to be used. The --parent-index option is used to specify which of several parent elements the requested element is in (0-based). For example, a dhcp <host> element could be in any one of multiple <ip> elements in the network; if a parent-index isn't provided, the "most appropriate" <ip> element will be selected (usually the only one that already has a <dhcp> element), but if --parent -index is given, that particular instance of <ip> will get the modification. If --live is specified, affect a running network. If --config is specified, affect the startup of a persistent network. If -- current is specified, affect the current network state. Both --live and --config options may be given, but --current is exclusive. Not specifying any option is the same as specifying --current . To update the configuration file, run:

Commands:
virsh net-update network command section xml [--parent-index index] [[--live] [--config] | [--current]]
Chapter 23. Managing JMS destinations The JMX Navigator view lets you add or delete JMS destinations in a running instance of Red Hat Fuse. Important These changes are not persistent across broker restarts. 23.1. Adding a JMS destination Overview When testing a new scenario, it is convenient to add a new JMS destination to one of your brokers. Procedure To add a JMS destination to a broker: In the JMX Navigator view, under the broker node for which you want to add a destination, select either the Queues child or the Topics child. Right-click the selected node to open the context menu, and then select either Create Queue or Create Topic . In either the Create Queue or Create Topic dialog, enter a name for the new destination. Click OK . Right-click either the Queues or the Topics child, and then select Refresh . The new destination appears in the JMX Navigator view under the Queues child or the Topics child. Related topics Section 23.2, "Deleting a JMS destination" 23.2. Deleting a JMS destination Overview When testing failover scenarios or other scenarios that involve handling failures, it is helpful to be able to easily remove a JMS destination. Procedure To delete a JMS destination: In the JMX Navigator view, under the Queues child or the Topics child, select the JMS destination you want to delete. Right-click the selected destination to open the context menu, and then select Delete Queue/Topic . Related topics Section 23.1, "Adding a JMS destination"

Commands:
6.11. Cluster Resources Cleanup If a resource has failed, a failure message appears when you display the cluster status. If you resolve that resource, you can clear that failure status with the pcs resource cleanup command. This command resets the resource status and failcount , telling the cluster to forget the operation history of a resource and re-detect its current state. The following command cleans up the resource specified by resource_id . If you do not specify a resource_id , this command resets the resource status and failcount for all resources. As of Red Hat Enterprise Linux 7.5, the pcs resource cleanup command probes only the resources that display as a failed action. To probe all resources on all nodes you can enter the following command: By default, the pcs resource refresh command probes only the nodes where a resource's state is known. To probe all resources even if the state is not known, enter the following command:

Commands:
pcs resource cleanup resource_id
pcs resource refresh
pcs resource refresh --full
7.136. nfs-utils 7.136.1. RHBA-2015:1342 - nfs-utils bug fix and enhancement update Updated nfs-utils packages that fix several bugs and add one enhancement are now available for Red Hat Enterprise Linux 6. The nfs-utils packages provide a daemon for the kernel Network File System (NFS) server and related tools, which provides better performance than the traditional Linux NFS server used by most users. These packages also contain the mount.nfs, umount.nfs, and showmount programs. Bug Fixes BZ# 1007281 Previously, the mountstats tool incorrectly parsed arguments that ended with the slash character (/). Consequently, the mountstats command failed when the directory name included a slash at the end. This bug has been fixed, and the mountstats command no longer fails in this scenario. BZ# 1194802 The rpc.mountd daemon contained memory leaks, which caused rpc.mountd to use an excessive amount of memory and an undue number of CPU cycles. With this update, several memory leaks identified by the Valgrind tool have been plugged, and the described problem no longer occurs. BZ# 1026446 Previously, when the "mount -o remount" command was used and the mount failed, no error message was displayed. With this update, a relevant error message is displayed in this scenario. BZ# 1164317 The rpc.mountd daemon did not correctly parse IP-restricted submount exports. As a consequence, some exports were not accessible when they should have been. This bug has been fixed, and exports are now accessible when appropriate. Enhancement BZ# 1172827 The mountstats tool has been updated to include the latest upstream features and improve performance. Several new options have been introduced ("--file" or "-f", "--since" or "-S", "--raw" or "-R"), output of the iostat and nfsstat commands has been improved, and relevant manual pages have been updated. Users of nfs-utils are advised to upgrade to these updated packages, which fix these bugs and add this enhancement. After installing this update, the nfs service will be restarted automatically.

Commands:
Chapter 4. Configuring cost management notifications The Red Hat Hybrid Cloud Console notifications service can automatically alert you to potential issues with cost management. Notification administrators can configure notifications for your organization from the Notifications menu on the Red Hat Hybrid Cloud Console Settings page. To set up a notification integration, go to Configuring notifications and integrations on the Red Hat Hybrid Cloud Console . After you set up the notification type, select the type of event you want Red Hat Hybrid Cloud Console to notify you about. For cost management, you can create the following types of notification events. Availability status Your cloud integration stopped sending data. Check that your integration is set up correctly. Refer to the cost management integration documentation for your cloud provider. Missing OpenShift Container Platform Cost Model You did not configure a cost model for an OpenShift Container Platform integration. You must configure a cost model for your OpenShift Container Platform integrations to accurately calculate your organization's costs. CM Operator Stale Data The data received from the Cost Management Metrics Operator is stale. Cost management uses this data to calculate costs for your integrations. When this data is stale, the cost management service does not calculate your organization's most recent costs.

Commands:
29.3. Starting and Stopping OProfile To start monitoring the system with OProfile, execute the following command as root: Output similar to the following is displayed: The settings in /root/.oprofile/daemonrc are used. The OProfile daemon, oprofiled , is started; it periodically writes the sample data to the /var/lib/oprofile/samples/ directory. The log file for the daemon is located at /var/lib/oprofile/oprofiled.log . Important On a Red Hat Enterprise Linux 6 system, the nmi_watchdog registers with the perf subsystem. Due to this, the perf subsystem grabs control of the performance counter registers at boot time, blocking OProfile from working. To resolve this, either boot with the nmi_watchdog=0 kernel parameter set, or run the following command to disable nmi_watchdog at run time: To re-enable nmi_watchdog , use the following command: To stop the profiler, execute the following command as root:

Commands:
~]# opcontrol --start
Using log file /var/lib/oprofile/oprofiled.log Daemon started. Profiler running.
~]# echo 0 > /proc/sys/kernel/nmi_watchdog
~]# echo 1 > /proc/sys/kernel/nmi_watchdog
~]# opcontrol --shutdown
Chapter 19. configuration This chapter describes the commands under the configuration command. 19.1. configuration show Display configuration details Usage: Table 19.1. Command arguments Value Summary -h, --help Show this help message and exit --mask Attempt to mask passwords (default) --unmask Show password in clear text Table 19.2. Output formatter options Value Summary -f {json,shell,table,value,yaml}, --format {json,shell,table,value,yaml} The output format, defaults to table -c COLUMN, --column COLUMN Specify the column(s) to include, can be repeated to show multiple columns Table 19.3. JSON formatter options Value Summary --noindent Whether to disable indenting the json Table 19.4. Shell formatter options Value Summary --prefix PREFIX Add a prefix to all variable names Table 19.5. Table formatter options Value Summary --max-width <integer> Maximum display width, <1 to disable. you can also use the CLIFF_MAX_TERM_WIDTH environment variable, but the parameter takes precedence. --fit-width Fit the table to the display width. implied if --max- width greater than 0. Set the environment variable CLIFF_FIT_WIDTH=1 to always enable --print-empty Print empty table if there is no data to show.

Commands:
openstack configuration show [-h] [-f {json,shell,table,value,yaml}] [-c COLUMN] [--noindent] [--prefix PREFIX] [--max-width <integer>] [--fit-width] [--print-empty] [--mask | --unmask]
2.6.4.3. Altering xinetd Configuration Files A range of directives are available for services protected by xinetd . This section highlights some of the more commonly used options. 2.6.4.3.1. Logging Options The following logging options are available for both /etc/xinetd.conf and the service-specific configuration files within the /etc/xinetd.d/ directory. The following is a list of some of the more commonly used logging options: ATTEMPT - Logs the fact that a failed attempt was made ( log_on_failure ). DURATION - Logs the length of time the service is used by a remote system ( log_on_success ). EXIT - Logs the exit status or termination signal of the service ( log_on_success ). HOST - Logs the remote host's IP address ( log_on_failure and log_on_success ). PID - Logs the process ID of the server receiving the request ( log_on_success ). USERID - Logs the remote user using the method defined in RFC 1413 for all multi-threaded stream services ( log_on_failure and log_on_success ). For a complete list of logging options, see the xinetd.conf man page.

Commands:
8.2.2. Creating the LVM Physical Volumes Once the boot partition is created, the remainder of all disk space can be allocated to LVM partitions. The first step in creating a successful LVM implementation is the creation of the physical volume(s). Select New . Select physical volume (LVM) from the File System Type pulldown menu as shown in Figure 8.5, "Creating a Physical Volume" . Figure 8.5. Creating a Physical Volume You cannot enter a mount point yet (you can once you have created all your physical volumes and then all volume groups). A physical volume must be constrained to one drive. For Allowable Drives , select the drive on which the physical volume are created. If you have multiple drives, all drives are selected, and you must deselect all but one drive. Enter the size that you want the physical volume to be. Select Fixed size to make the physical volume the specified size, select Fill all space up to (MB) and enter a size in MBs to give range for the physical volume size, or select Fill to maximum allowable size to make it grow to fill all available space on the hard disk. If you make more than one growable, they share the available free space on the disk. Select Force to be a primary partition if you want the partition to be a primary partition. Click OK to return to the main screen. Repeat these steps to create as many physical volumes as needed for your LVM setup. For example, if you want the volume group to span over more than one drive, create a physical volume on each of the drives. The following figure shows both drives completed after the repeated process: Figure 8.6. Two Physical Volumes Created

Commands:
Chapter 1. Uninstalling Builds As a cluster administrator, you can uninstall the Builds for Red Hat OpenShift Operator. Uninstalling the Operator does not automatically remove the custom resources (CRs) and Builds components. To uninstall the Builds for Red Hat OpenShift Operator, perform the following tasks: Delete the custom resources (CRs) that were created by default when you installed the Operator. Note If you uninstall the Operator without removing the CRs, you cannot remove them later. Uninstall the Operator. 1.1. Deleting the Builds components and custom resources Delete the custom resources (CRs) that were created by default during Operator installation. Prerequisites You are logged in to the OpenShift Container Platform cluster as an administrator. Procedure In the Administrator perspective of the web console, navigate to Administration Custom Resource Definition . In the Filter by name box, enter shipwright.io to search for the Builds for Red Hat OpenShift Operator CRs. Click CRD Config to see the Custom Resource Definition Details page. Click the Actions drop-down list, and select Delete Custom Resource Definition . Note Deleting the CRs deletes the Builds controller and all the related components and tasks on the cluster. Click Delete to confirm the deletion of the CRs. 1.2. Uninstalling the Builds for Red Hat OpenShift Operator You can uninstall the Builds for Red Hat OpenShift Operator by using the Administrator perspective in the web console. Prerequisites You are logged in to the OpenShift Container Platform cluster as an administrator. You have deleted the Builds components and custom resources. Procedure Navigate to Operators OperatorHub . In the OperatorHub page, search for the Builds for Red Hat OpenShift Operator by using the Filter by keyword box. Click the Builds for Red Hat OpenShift Operator tile. The Operator tile indicates that the Operator is installed. In the Builds for Red Hat OpenShift Operator description page, click Uninstall . Additional resources Deleting Operators from a cluster

Commands:
4.4. sVirt Labeling Like other services under the protection of SELinux, sVirt uses process based mechanisms, labels and restrictions to provide extra security and control over guest instances. Labels are applied automatically to resources on the system based on the currently running virtual machines (dynamic), but can also be manually specified by the administrator (static), to meet any specific requirements that may exist. 4.4.1. Types of sVirt Labels The following table outlines the different sVirt labels that can be assigned to resources such as virtual machine processes, image files and shared content: Table 4.2. sVirt Labels Type SELinux Context Description/Effect Virtual Machine Processes system_u:system_r:svirt_t: MCS1 MCS1 is a randomly selected field. Currently approximately 500,000 labels are supported. Virtual Machine Image system_u:object_r:svirt_image_t: MCS1 Only svirt_t processes with the same MCS1 fields are able to read/write these image files and devices. Virtual Machine Shared Read/Write Content system_u:object_r:svirt_image_t:s0 All svirt_t processes are allowed to write to the svirt_image_t:s0 files and devices. Virtual Machine Shared Shared Read Only content system_u:object_r:svirt_content_t:s0 All svirt_t processes are able to read files/devices with this label. Virtual Machine Image system_u:object_r:virt_content_t:s0 System default label used when an image exits. No svirt_t virtual processes are allowed to read files/devices with this label.

Commands:
3.2. Configure the Security Audit Logger (Remote Client-Server Mode) Use the following code to configure the audit logger in Red Hat JBoss Data Grid Remote Client-Server Mode. To use a different audit logger, specify it in the <authorization> element. The <authorization> element must be within the <cache-container> element in the Infinispan subsystem (in the standalone.xml configuration file). Note The default audit logger for server mode is org.jboss.as.clustering.infinispan.subsystem.ServerAuditLogger which sends the log messages to the server audit log. See the Management Interface Audit Logging chapter in the JBoss Enterprise Application Platform Administration and Configuration Guide for more information. Report a bug

Commands:
<cache-container name="local" default-cache="default"> <security> <authorization audit-logger="org.infinispan.security.impl.DefaultAuditLogger"> <identity-role-mapper/> <role name="admin" permissions="ALL"/> <role name="reader" permissions="READ"/> <role name="writer" permissions="WRITE"/> <role name="supervisor" permissions="ALL_READ ALL_WRITE"/> </authorization> </security> <local-cache name="default" start="EAGER"> <locking isolation="NONE" acquire-timeout="30000" concurrency-level="1000" striping="false"/> <transaction mode="NONE"/> <security> <authorization roles="admin reader writer supervisor"/> </security> </local-cache>
8.19. Installation Complete Congratulations! Your Red Hat Enterprise Linux installation is now complete! Click the Reboot button to reboot your system and begin using Red Hat Enterprise Linux. Remember to remove any installation media if it is not ejected automatically upon reboot. After your computer's normal power-up sequence has completed, Red Hat Enterprise Linux loads and starts. By default, the start process is hidden behind a graphical screen that displays a progress bar. Eventually, a GUI login screen (or if the X Window System is not installed, a login: prompt) appears. If your system was installed with the X Window System during this installation process, the first time you start your Red Hat Enterprise Linux system, applications to set up your system are launched. These applications guide you through initial configuration of Red Hat Enterprise Linux and allow you to set your system time and date, register your machine with Red Hat Network, and more. See Chapter 30, Initial Setup for information about the configuration process. For instructions on post-installation procedures, configuration and updates for Red Hat Enterprise Linux Atomic Host, see the Getting Started withRed Hat Enterprise Linux Atomic Host document.

Commands:
Preface Depending on the type of your deployment, you can choose one of the following procedures to replace a storage device: For dynamically created storage clusters deployed on AWS, see: Section 1.1, "Replacing operational or failed storage devices on AWS user-provisioned infrastructure" . Section 1.2, "Replacing operational or failed storage devices on AWS installer-provisioned infrastructure" . For dynamically created storage clusters deployed on VMware, see Section 2.1, "Replacing operational or failed storage devices on VMware infrastructure" . For dynamically created storage clusters deployed on Microsoft Azure, see Section 3.1, "Replacing operational or failed storage devices on Azure installer-provisioned infrastructure" . For storage clusters deployed using local storage devices, see: Section 5.1, "Replacing operational or failed storage devices on clusters backed by local storage devices" . Section 5.2, "Replacing operational or failed storage devices on IBM Power" . Section 5.3, "Replacing operational or failed storage devices on IBM Z or IBM LinuxONE infrastructure" . Note OpenShift Data Foundation does not support heterogeneous OSD sizes.

Commands: