mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 8. Using a Red Hat Image Builder image for provisioning In Satellite, you can enable integration with the RHEL web console to perform actions and monitor your hosts. Using the RHEL web console, you can access Red Hat Image Builder and build images that you can then upload to an HTTP server and use this image to provision hosts. When you configure Satellite for image provisioning, Anaconda installer partitions disks, downloads and mounts the image and copies files over to a host. The preferred image type is TAR. Ensure that your blueprint to build the TAR image includes a kernel package. For more information about integrating the RHEL web console with Satellite, see Host management and monitoring using the RHEL web console in Managing hosts . Prerequisites An existing TAR image created using Red Hat Image Builder. Procedure On Satellite, create a custom product, add a custom file repository to this product, and upload the image to the repository. For more information, see Importing Individual ISO Images and Files in Managing content . In the Satellite web UI, navigate to Configure > Host Groups , and select the host group that you want to use. Click the Parameters tab, and then click Add Parameter . In the Name field, enter kickstart_liveimg . From the Type list, select string . In the Value field, enter the absolute path or a relative path in the following format custom/ product / repository / image_name that points to the exact location where you store the image. Click Submit to save your changes. You can use this image for bare-metal provisioning and provisioning using a compute resource. For more information about bare-metal provisioning, see Chapter 5, Using PXE to provision hosts . For more information about provisioning with different compute resources, see the relevant chapter for the compute resource that you want to use.

Commands:
Chapter 5. Deploying standalone Multicloud Object Gateway Deploying only the Multicloud Object Gateway component with the OpenShift Data Foundation provides the flexibility in deployment and helps to reduce the resource consumption. Use this section to deploy only the standalone Multicloud Object Gateway component, which involves the following steps: * Installing the Local Storage Operator. * Installing Red Hat OpenShift Data Foundation Operator * Creating standalone Multicloud Object Gateway :leveloffset: +2

Commands:
Chapter 34. ExternalLogging schema reference Used in: CruiseControlSpec , EntityTopicOperatorSpec , EntityUserOperatorSpec , KafkaBridgeSpec , KafkaClusterSpec , KafkaConnectSpec , KafkaMirrorMaker2Spec , KafkaMirrorMakerSpec , ZookeeperClusterSpec The type property is a discriminator that distinguishes use of the ExternalLogging type from InlineLogging . It must have the value external for the type ExternalLogging . Property Property type Description type string Must be external . valueFrom ExternalConfigurationReference ConfigMap entry where the logging configuration is stored.

Commands:
7.38. dhcp 7.38.1. RHBA-2015:1258 - dhcp bug fix and enhancement update Updated dhcp packages that fix several bugs and add one enhancement are now available for Red Hat Enterprise Linux 6. The Dynamic Host Configuration Protocol (DHCP) is a protocol that allows individual devices on an IP network to get their own network configuration information, including an IP address, a subnet mask, and a broadcast address. The dhcp packages provide a relay agent and ISC DHCP service required to enable and administer DHCP on a network. Bug Fixes BZ# 1130804 Previously, the DHCPv6 client was sometimes started to configure a network interface which was not fully loaded. Consequently, dhclient failed to run because the network interface did not have a link-local address yet, which the DHCPv6 client requires. This update adds a wait loop into dhclient-script, and dhclient no longer fails due to a missing link-local address. BZ# 1150587 When the dhcpd daemon was using a plain interface as well as an interface configured as a VLAN trunk, and the dhcpd daemon was configured to listen only on the plain interface, it detected traffic also from VLAN networks, regardless of the configuration. As a consequence, dhcpd was generating incorrect responses. With this update, the bug has been corrected, and in the described scenario, dhcpd now ignores tagged requests, and thus generates correct responses. BZ# 1151054 When running the DHCPv6 relay agent and the "lower" interface was specified ("-l") on the command line before the "upper" interface ("-u"), message relaying did not work. The underlying source code has been fixed, and DHCPv6 relay agent now relays messages properly. BZ# 1185075 When a large number of nodes with InfiniBand network cards booted at the same time, some nodes were assigned duplicate IP addresses. With this update, generation of the xid field in DHCP messages sent by the client has been fixed for the xid fields to be unique, and nodes are now assigned unique IP addresses as expected. BZ# 1187967 Previously, attempting to run the dhcrelay and dhcrelay6 services simultaneously prevented the latter service from starting. The dhcrelay6 init script has been fixed, and running both dhcrelay and dhcrelay6 services no longer causes problems. Enhancement BZ# 1058674 With this update, the dhcpd daemon is able to handle dhcp option 97 - Client Machine Identifier (pxe-client-id), so it is now possible to statically allocate an IP address for a particular client based on its identifier, sent in option 97. Users of dhcp are advised to upgrade to these updated packages, which fix these bugs and add this enhancement.

Commands:
Appendix E. Other Technical Documentation Both Anaconda and Red Hat Enterprise Linux systems use a common set of software components. For detailed information on key technologies, see the web sites listed below. Boot Loader Red Hat Enterprise Linux uses the GRUB2 boot loader. See the corresponding chapter in the RRed Hat Enterprise Linux 7 System Administrator's Guide . Storage Management Logical Volume Management (LVM) provides administrators with a range of facilities to manage storage. By default, the Red Hat Enterprise Linux installation process formats drives as LVM volumes. For further details about LVM, see the Red Hat Enterprise Linux 7 Logical Volume Manager Administration Guide . Remote Displays Red Hat Enterprise Linux and Anaconda include VNC (Virtual Network Computing) software to enable remote access to graphical displays. For more information about VNC, see the TigerVNC chapter in the Red Hat Enterprise Linux 7 System Administrator's Guide . You can also use the VNC Configurator application on the Red Hat Customer Portal to guide you through VNC server and client setup. Remote System Access Red Hat Enterprise Linux incorporates the OpenSSH suite to provide remote access to the system. The SSH service enables a number of functions, which include access to the command-line from other systems, remote command execution, and network file transfers. During the installation process, Anaconda might use the scp feature of OpenSSH to transfer crash reports to remote systems. For further details about OpenSSH, see the corresponding section in the Red Hat Enterprise Linux 7 System Administrator's Guide . Access Control SELinux provides Mandatory Access Control (MAC) capabilities that supplement the standard Linux security features. See the Red Hat Enterprise Linux 7 SELinux User's and Administrator's Guide for further information. Firewall Red Hat Enterprise Linux uses firewalld to provide firewall features. For further information, see the corresponding chapter in the Red Hat Enterprise Linux 7 Security Guide . Software Installation Red Hat Enterprise Linux uses yum to manage the RPM packages that make up the system. See the corresponding chapter in the Red Hat Enterprise Linux 7 Administrator's Guide for further information. Virtualization Virtualization provides the capability to simultaneously run multiple operating systems on the same computer. Red Hat Enterprise Linux also includes tools to install and manage the secondary systems on a Red Hat Enterprise Linux host. You can select virtualization support during the installation process, or at any time thereafter. See the Red Hat Enterprise Linux 7 Virtualization Deployment and Administration Guide for more information.

Commands:
Configuring OpenShift Data Foundation Disaster Recovery for OpenShift Workloads Red Hat OpenShift Data Foundation 4.18 The OpenShift Data Foundation Disaster Recovery capabilities for Metropolitan and Regional regions is now General Available which also includes Disaster Recovery with stretch cluster. Red Hat Storage Documentation Team Abstract The intent of this solution guide is to detail the steps necessary to deploy OpenShift Data Foundation for disaster recovery with Advanced Cluster Management and stretch cluster to achieve a highly available storage infrastructure.

Commands:
14.6. Methods 14.6.1. Creating a Host Creation of a new host requires the name , address and root_password elements. Example 14.6. Creating a host The root_password element is only included in the client-provided initial representation and is not exposed in the representations returned from subsequent requests. 14.6.2. Updating a Host The name , description , cluster , power_management , transparent_hugepages and ksm elements are updatable post-creation. Example 14.7. Updating a host 14.6.3. Removing a Host Removal of a host requires a DELETE request. Example 14.8. Removing a host

Commands:
POST /ovirt-engine/api/hosts HTTP/1.1 Accept: application/xml Content-type: application/xml <host> <name>host2</name> <address>host2.example.com</address> <root_password>p@55w0Rd!</root_password> </host>
PUT /ovirt-engine/api/hosts/00000000-0000-0000-0000-000000000000 HTTP/1.1 Accept: application/xml Content-type: application/xml <host> <name>host3</name> </host>
DELETE /ovirt-engine/api/hosts/00000000-0000-0000-0000-000000000000 HTTP/1.1 HTTP/1.1 204 No Content
Chapter 5. Using the API For more information, see the AMQ JavaScript API reference and AMQ JavaScript example suite . 5.1. Handling messaging events AMQ JavaScript is an asynchronous event-driven API. To define how the application handles events, the user registers event-handling functions on the container object. These functions are then called as network activity or timers trigger new events. Example: Handling messaging events var rhea = require("rhea"); var container = rhea.create_container(); container.on("sendable", function (event) { console.log("A message can be sent"); }); container.on("message", function (event) { console.log("A message is received"); }); These are only a few common-case events. The full set is documented in the AMQ JavaScript API reference . 5.2. Accessing event-related objects The event argument has attributes for accessing the object the event is regarding. For example, the connection_open event sets the event connection attribute. In addition to the primary object for the event, all objects that form the context for the event are set as well. Attributes with no relevance to a particular event are null. Example: Accessing event-related objects event. container event. connection event. session event. sender event. receiver event. delivery event. message 5.3. Creating a container The container is the top-level API object. It is the entry point for creating connections, and it is responsible for running the main event loop. It is often constructed with a global event handler. Example: Creating a container var rhea = require("rhea"); var container = rhea.create_container(); 5.4. Setting the container identity Each container instance has a unique identity called the container ID. When AMQ JavaScript makes a network connection, it sends the container ID to the remote peer. To set the container ID, pass the id option to the create_container method. Example: Setting the container identity var container = rhea.create_container( {id: "job-processor-3"} ); If the user does not set the ID, the library will generate a UUID when the container is constucted.

Commands:
var rhea = require("rhea"); var container = rhea.create_container(); container.on("sendable", function (event) { console.log("A message can be sent"); }); container.on("message", function (event) { console.log("A message is received"); });
event. container event. connection event. session event. sender event. receiver event. delivery event. message
var rhea = require("rhea"); var container = rhea.create_container();
var container = rhea.create_container( {id: "job-processor-3"} );
8.153. piranha 8.153.1. RHBA-2013:1618 - piranha bug fix update Updated piranha packages that fix two bugs are now available for Red Hat Enterprise Linux 6. Piranha provides high-availability and load-balancing services for Red Hat Enterprise Linux. The piranha packages contain various tools to administer and configure the Linux Virtual Server (LVS), as well as the heartbeat and failover components. LVS is a dynamically-adjusted kernel routing mechanism that provides load balancing, primarily for Web and FTP servers. Bug Fixes BZ# 903711 Previously, the lvsd daemon did not properly activate the "sorry server" fallback service when all real servers were unavailable. Consequently, incoming traffic for a virtual service with no available real servers was not directed to "sorry server". This bug has been fixed and the lvsd daemon now properly activates "sorry server" when no real servers are available. BZ# 980169 In certain cases, most often caused by brief network outages, high latency between directors, or aggressive keepalive and deadtime settings, the lvsd daemon did not properly terminate when signaled by the pulse daemon. Consequently, lvsd ran on both master and backup directories having multiple virtual IPs (VIPs). With this update, lvsd has been modified to correctly catch and handle all signals from the pulse daemon. As a result, the redundant VIP is now properly removed. Users of piranha are advised to upgrade to these updated packages, which fix these bugs.

Commands:
4.5. Cisco UCS Table 4.6, "Cisco UCS" lists the fence device parameters used by fence_cisco_ucs , the fence agent for Cisco UCS. Table 4.6. Cisco UCS luci Field cluster.conf Attribute Description Name name A name for the Cisco UCS device. IP Address or Hostname ipaddr The IP address or host name assigned to the device. IP port (optional) ipport The TCP port to use to connect to the device. Login login The login name used to access the device. Password passwd The password used to authenticate the connection to the device. Password Script (optional) passwd_script The script that supplies a password for access to the fence device. Using this supersedes the Password parameter. Use SSL ssl Use SSL connections to communicate with the device. Sub-Organization suborg Additional path needed to access suborganization. Power Wait (seconds) power_wait Number of seconds to wait after issuing a power off or power on command. Power Timeout (seconds) power_timeout Number of seconds to continue testing for a status change after issuing a power off or power on command. The default value is 20. Shell Timeout (seconds) shell_timeout Number of seconds to wait for a command prompt after issuing a command. The default value is 3. Login Timeout (seconds) login_timeout Number of seconds to wait for a command prompt after login. The default value is 5. Times to Retry Power On Operation retry_on Number of attempts to retry a power on operation. The default value is 1. Port (Outlet) Number port Name of virtual machine. Delay (optional) delay The number of seconds to wait before fencing is started. The default value is 0. Figure 4.5, "Cisco UCS" shows the configuration screen for adding a Cisco UCS fence device. Figure 4.5. Cisco UCS The following command creates a fence device instance for a Cisco UCS device: The following is an example cluster.conf entry for the fence_cisco_ucs device as created using either Conga or ccs :

Commands:
ccs -f cluster.conf --addfencedev ucs agent=fence_cisco_ucs ipaddr=192.168.0.1 login=root passwd=password123 suborg=/org-RHEL/org-Fence/
<fencedevices> <fencedevice agent="fence_cisco_ucs" ipaddr="192.168.0.1" login="root" name="ciscoucstest1" passwd="password123" power_wait="60" ssl="on" suborg="/org-RHEL/org-Fence/"/> </fencedevices>
Chapter 17. Cache Stores The cache store connects Red Hat JBoss Data Grid to the persistent data store. Cache stores are associated with individual caches. Different caches attached to the same cache manager can have different cache store configurations. Note If a clustered cache is configured with an unshared cache store (where shared is set to false ), on node join, stale entries which might have been removed from the cluster might still be present in the stores and can reappear. Report a bug 17.1. Cache Loaders and Cache Writers Integration with the persistent store is done through the following SPIs located in org.infinispan.persistence.spi : CacheLoader CacheWriter AdvancedCacheLoader AdvancedCacheWriter CacheLoader and CacheWriter provide basic methods for reading and writing to a store. CacheLoader retrieves data from a data store when the required data is not present in the cache, and CacheWriter is used to enforce entry passivation and activation on eviction in a cache. AdvancedCacheLoader and AdvancedCacheWriter provide operations to manipulate the underlying storage in bulk: parallel iteration and purging of expired entries, clear and size. The org.infinispan.persistence.file.SingleFileStore is a good starting point to write your own store implementation. Note Previously, JBoss Data Grid used the old API ( CacheLoader , extended by CacheStore ), which is also still available. Report a bug

Commands:
Chapter 60. CruiseControlTemplate schema reference Used in: CruiseControlSpec Property Property type Description deployment DeploymentTemplate Template for Cruise Control Deployment . pod PodTemplate Template for Cruise Control Pods . apiService InternalServiceTemplate Template for Cruise Control API Service . podDisruptionBudget PodDisruptionBudgetTemplate Template for Cruise Control PodDisruptionBudget . cruiseControlContainer ContainerTemplate Template for the Cruise Control container. tlsSidecarContainer ContainerTemplate The tlsSidecarContainer property has been deprecated. Template for the Cruise Control TLS sidecar container. serviceAccount ResourceTemplate Template for the Cruise Control service account.

Commands:
7.209. redhat-release 7.209.1. RHEA-2013:0379 - redhat-release enhancement update for Red Hat Enterprise Linux 6.4 Enhanced redhat-release packages are now available for Red Hat Enterprise Linux 6.4. The redhat-release package contains licensing information regarding, and identifies the installed version of, Red Hat Enterprise Linux. These updated redhat-release packages reflect changes made for the release of Red Hat Enterprise Linux 6.4. Users of Red Hat Enterprise Linux 6 are advised to upgrade to these updated redhat-release packages, which add this enhancement.

Commands:
4.184. module-init-tools 4.184.1. RHBA-2012:0366 - module-init-tools bug fix and enhancement update An updated module-init-tools package that fixes two bugs and adds one enhancement is now available for Red Hat Enterprise Linux 6. The module-init-tools package includes various programs needed for automatic loading and unloading of modules under 2.6 and later kernels, as well as other module management programs. Device drivers and file systems are two examples of loaded and unloaded modules. Bug Fixes BZ# 787741 Previously, if the "override" keyword was present in the depmod.conf file without any parameters specified, the depmod utility terminated unexpectedly with a segmentation fault. A patch has been applied to ensure that the depmod utility no longer crashes and a syntax warning is displayed instead. BZ# 797183 Previously, on low-memory systems (such as low-memory high-performance infrastructure, or HPC, nodes or virtual machines), depmod could use excessive amount of memory. As a consequence, the depmod process was killed by the OOM (out of memory) mechanism, and the system was unable to boot. With this update, the free() function is correctly used on several places in the code so that so that depmod's memory consumption is reduced. Enhancement BZ# 787748 This update adds the "backports" directory to the search path in the depmod.conf file, which is necessary to support integration of the compat-wireless package into kernel packages. All users of module-init-tools are advised to upgrade to this updated package, which fixes these bugs and adds this enhancement.

Commands:
probe::nfs.proc.rename Name probe::nfs.proc.rename - NFS client renames a file on server Synopsis nfs.proc.rename Values new_fh file handle of new parent dir new_filelen length of new file name old_name old file name version NFS version (the function is used for all NFS version) old_fh file handle of old parent dir prot transfer protocol new_name new file name old_filelen length of old file name server_ip IP address of server

Commands:
5.3. Volume Group Administration This section describes the commands that perform the various aspects of volume group administration. 5.3.1. Creating Volume Groups To create a volume group from one or more physical volumes, use the vgcreate command. The vgcreate command creates a new volume group by name and adds at least one physical volume to it. The following command creates a volume group named vg1 that contains physical volumes /dev/sdd1 and /dev/sde1 . When physical volumes are used to create a volume group, its disk space is divided into 4MB extents, by default. This extent is the minimum amount by which the logical volume may be increased or decreased in size. Large numbers of extents will have no impact on I/O performance of the logical volume. You can specify the extent size with the -s option to the vgcreate command if the default extent size is not suitable. You can put limits on the number of physical or logical volumes the volume group can have by using the -p and -l arguments of the vgcreate command. By default, a volume group allocates physical extents according to common-sense rules such as not placing parallel stripes on the same physical volume. This is the normal allocation policy. You can use the --alloc argument of the vgcreate command to specify an allocation policy of contiguous , anywhere , or cling . In general, allocation policies other than normal are required only in special cases where you need to specify unusual or nonstandard extent allocation. For further information on how LVM allocates physical extents, see Section 5.3.2, "LVM Allocation" . LVM volume groups and underlying logical volumes are included in the device special file directory tree in the /dev directory with the following layout: For example, if you create two volume groups myvg1 and myvg2 , each with three logical volumes named lv01 , lv02 , and lv03 , six device special files are created: The device special files are not present if the corresponding logical volume is not currently active. The maximum device size with LVM is 8 Exabytes on 64-bit CPUs.

Commands:
vgcreate vg1 /dev/sdd1 /dev/sde1
/dev/ vg / lv /
/dev/myvg1/lv01 /dev/myvg1/lv02 /dev/myvg1/lv03 /dev/myvg2/lv01 /dev/myvg2/lv02 /dev/myvg2/lv03