mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 2. Conversion methods Depending on your requirements, you can convert to RHEL by using one of the following methods: Converting by using the command-line interface - Use this method to convert a small number of servers, or to convert a large number of servers at scale by using custom automation. Note If you have a Satellite subscription but plan to convert by using the command-line interface, you can access the required RHEL packages through Satellite instead of using the Red Hat Content Delivery Network (CDN). For more information about how to convert by using the command-line interface, see Planning a RHEL conversion and Converting using the command-line . Converting by using Red Hat Satellite - Use this method to convert a large number of servers at scale. To convert by using Satellite, you must have a Satellite subscription. For more information about how to convert by using Satellite, see Converting a Host to Red Hat Enterprise Linux . Converting by using Red Hat Insights - Use this method to convert multiple systems in a user-friendly GUI interface without needing a Satellite subscription. Systems must be connected to the internet. Systems are fully onboarded with Red Hat Insights after the conversion. Note Insights supports conversions with Red Hat Enterprise Linux for Third Party Migration with the pay-as-you-go pricing model on Amazon Web Services (AWS). For more information, see Red Hat Enterprise Linux for Third Party Linux Migration . For more information about how to convert by using Red Hat Insights, see Planning a RHEL conversion and Converting using Insights .

Commands:
function::user_long Name function::user_long - Retrieves a long value stored in user space Synopsis Arguments addr the user space address to retrieve the long from Description Returns the long value from a given user space address. Returns zero when user space data is not accessible. Note that the size of the long depends on the architecture of the current user space task (for those architectures that support both 64/32 bit compat tasks).

Commands:
user_long:long(addr:long)
Chapter 2. Requirements for scaling storage Before you proceed to scale the storage nodes, refer to the following sections to understand the node requirements for your specific Red Hat OpenShift Data Foundation instance: Platform requirements Resource requirements Storage device requirements Dynamic storage devices Local storage devices Capacity planning Important Always ensure that you have plenty of storage capacity. If storage ever fills completely, it is not possible to add capacity or delete or migrate content away from the storage to free up space completely. Full storage is very difficult to recover. Capacity alerts are issued when cluster storage capacity reaches 75% (near-full) and 85% (full) of total capacity. Always address capacity warnings promptly, and review your storage regularly to ensure that you do not run out of storage space. If you do run out of storage space completely, contact Red Hat Customer Support .

Commands:
3.2. ia64 Architectures Bugzilla #163910 In this update, the 64-bit Intel Itanium2 architecture includes runtime support for 32-bit applications through the use of Intel's IA-32 Execution Layer. The IA-32 Execution Layer is provided on the Extras disc for the Intel Itanium2 architecture. In addition, a set of 32-bit libraries and applications are provided on a separate 32-bit Compatibility Layer disc. The IA-32 Execution Layer and 32-bit compatibility packages together provide a runtime environment for 32-bit applications on the 64-bit native distribution. To install the IA-32 Execution Layer and required 32-bit compatibility packages, follow these steps: Install Red Hat Enterprise Linux 4.8 for the Intel Itanium2 Architecture. Insert the Red Hat Enterprise Linux 4 Extras CD, which contains the ia32el package. After the system has mounted the CD, change to the directory containing the Extras packages. For example: cd /media/cdrom/RedHat/RPMS/ Install the ia32el and ksh packages: rpm -Uvh ia32el-< version >.ia64.rpm ksh-< version >.ia64.rpm where <version> is the respective versions of the ia32el and ksh packages to be installed. Eject the Extras CD: eject /media/cdrom To verify the installation of the 32-bit compatibility layer and libraries after installation, confirm if the /emul directory exists and contains files. To verify that the 32-bit compatibility mode is in effect, type the following in a shell prompt: service ia32el status At this point you can install compatibility libraries by inserting the 32-bit Compatibility Layer disc. You may choose to install all of the packages available on the disc or choose the particular packages required in order to provide runtime support for your 32-bit applications.

Commands:
2.3. Multiple Cache Managers Cache managers are an entry point to the cache and Red Hat JBoss Data Grid allows users to create multiple cache managers. Each cache manager is configured with a different global configuration, which includes settings for things like JMX, executors and clustering. Report a bug 2.3.1. Create Multiple Caches with a Single Cache Manager Red Hat JBoss Data Grid allows using the same cache manager to create multiple caches, each with a different cache mode (synchronous and asynchronous cache modes). Report a bug 2.3.2. Using Multiple Cache Managers Red Hat JBoss Data Grid allows multiple cache managers to be used. In most cases, such as with replication and networking components, cache instances share internal components and a single cache manager is sufficient. However, if multiple caches are required to have different network characteristics, for example if one cache uses the TCP protocol and the other uses the UDP protocol, multiple cache managers must be used. Report a bug 2.3.3. Create Multiple Cache Managers Red Hat JBoss Data Grid allows users to create multiple cache managers of various types by repeating the procedure used to create the first cache manager (and adjusting the contents of the configuration file, if required). To use the declarative API to create multiple new cache managers, copy the contents of the infinispan.xml file to a new configuration file. Edit the new file for the desired configuration and then use the new file for a new cache manager. Report a bug

Commands:
Chapter 1. About the Fuse Console The Red Hat Fuse Console is a web console based on HawtIO open source software. For a list of supported browsers, go to Supported Configurations . The Fuse Console provides a central interface to examine and manage the details of one or more deployed Fuse containers. You can also monitor Red Hat Fuse and system resources, perform updates, and start or stop services. The Fuse Console is available when you install Red Hat Fuse standalone or use Fuse on OpenShift. The integrations that you can view and manage in the Fuse Console depend on the plugins that are running. Possible plugins include: Camel JMX OSGI Runtime Logs

Commands:
10.2. Multi-Source Model Configuration To mark a model as multi-source, multisource can be set to true and then more than one source can be listed for the model in the vdb.xml file. The following example shows a single model dynamic VDB with multiple sources defined. <vdb name="vdbname" version="1"> <model visible="true" type="PHYSICAL" name="Customers" path="/Test/Customers.xmi"> <property name="multisource" value="true"/> <!-- optional properties <property name="multisource.columnName" value="somename"/> <property name="multisource.addColumn" value="true"/> --> <source name="chicago" translator-name="oracle" connection-jndi-name="chicago-customers"/> <source name="newyork" translator-name="oracle" connection-jndi-name="newyork-customers"/> <source name="la" translator-name="oracle" connection-jndi-name="la-customers"/> </model> </vdb> Note Currently the tooling support for managing the multi-source feature is limited, so if you need to use this feature build the VDB as usual in the Teiid Designer and then edit the vdb.xml file in the VDB archive using a Text editor to add the additional sources as defined above. You must deploy a separate data source for each source defined in the XML file. In the above example, the VDB defined has single model called Customers , that has multiple sources ( chicago , newyork , and la ) that define different instances of data.

Commands:
<vdb name="vdbname" version="1"> <model visible="true" type="PHYSICAL" name="Customers" path="/Test/Customers.xmi"> <property name="multisource" value="true"/> <!-- optional properties <property name="multisource.columnName" value="somename"/> <property name="multisource.addColumn" value="true"/> --> <source name="chicago" translator-name="oracle" connection-jndi-name="chicago-customers"/> <source name="newyork" translator-name="oracle" connection-jndi-name="newyork-customers"/> <source name="la" translator-name="oracle" connection-jndi-name="la-customers"/> </model> </vdb>
Chapter 2. Considerations for Using GNBD with Device-Mapper Multipath GNBD with device-mapper multipath allows you to configure multiple GNBD server nodes (nodes that export GNBDs to GFS nodes) to provide redundant paths to the storage devices. The GNBD server nodes, in turn, present multiple storage paths to GFS nodes via redundant GNBDs. When using GNBD with device-mapper multipath, if a GNBD server node becomes unavailable, another GNBD server node can provide GFS nodes with access to storage devices. If you are using GNBD with device-mapper multipath, you need to take the following into consideration: Linux page caching, as desribed in Section 2.1, "Linux Page Caching" . Fencing GNBD server nodes, as described in Section 2.2, "Fencing GNBD Server Nodes" . GNBD device names; export names for GNBD devices must be unique. Additionally, you must specify the -u or -U when using the gnbd_export command. Exporting GNBD devices is described in Chapter 3, GNBD Driver and Command Usage . 2.1. Linux Page Caching For GNBD with device-mapper multipath, do not specify Linux page caching (the -c option of the gnbd_export command). All GNBDs that are part of a logical volume must run with caching disabled . Data corruption occurs if the GNBDs are run with caching enabled. Refer to Section 3.1, "Exporting a GNBD from a Server" for more information about using the gnbd_export command for GNBD with device-mapper multipath.

Commands:
4.4. Tracking Password Change Times Password change operations are normally treated as any other modification to an entry, so the update time is recorded in the lastModified operational attribute. However, there can be times when the time of the last password change needs to be recorded separately, to make it easier to update passwords in Active Directory synchronization or to connect with other LDAP clients. The passwordTrackUpdateTime attribute within the password policy tells the server to record a timestamp for the last time that the password was updated for an entry. The password change time itself is stored as an operational attribute on the user entry, pwdUpdateTime (which is separate from the modifyTimestamp or lastModified operational attributes). The passwordTrackUpdateTime attribute can be set as part of the global password policy or on a subtree or user-level policy, depending on what clients need to access the password change time. Setting password policies is described in Section 20.4, "Managing the Password Policy" .

Commands:
Chapter 100. Plugin schema reference Used in: Build Property Property type Description name string The unique name of the connector plugin. Will be used to generate the path where the connector artifacts will be stored. The name has to be unique within the KafkaConnect resource. The name has to follow the following pattern: ^[a-z][-_a-z0-9]*[a-z]USD . Required. artifacts JarArtifact , TgzArtifact , ZipArtifact , MavenArtifact , OtherArtifact array List of artifacts which belong to this connector plugin. Required.

Commands:
Chapter 110. KafkaTopicStatus schema reference Used in: KafkaTopic Property Property type Description conditions Condition array List of status conditions. observedGeneration integer The generation of the CRD that was last reconciled by the operator. topicName string Topic name. topicId string The topic's id. For a KafkaTopic with the ready condition, this will change only if the topic gets deleted and recreated with the same name. replicasChange ReplicasChangeStatus Replication factor change status.

Commands:
Chapter 1. Overview Product Life Cycle Note Red Hat Enterprise Linux 6 is now in the Maintenance Support 2 phase of the product life cycle. New functionality and new hardware enablement are not planned for availability in this phase. Red Hat Enterprise Linux 6.9 therefore provides a stable release focused on bug fixes. Subsequent updates will be limited to qualified critical security fixes and business-impacting urgent issues. Please refer to Red Hat Enterprise Linux Life Cycle for more information. In-place Upgrade As Red Hat Enterprise Linux subscriptions are not tied to a particular release, existing customers can update their Red Hat Enterprise Linux 6 infrastructure to Red Hat Enterprise Linux 7 at any time, free of charge, to take advantage of recent upstream innovations. To simplify the upgrade to Red Hat Enterprise Linux 7, Red Hat provides the Preupgrade Assistant and Red Hat Upgrade Tool . For more information, see Chapter 2, General Updates . Security With the addition of TLS protocol version 1.2 support to the GnuTLS component, Red Hat Enterprise Linux 6 offers complete support for TLS 1.2 in the provided security libraries. TLS 1.2 is recommended by modern security standards such as PCI-DSS 3.1. For more information, see Chapter 11, Security . OpenSCAP 1.2.13 has been certified by the National Institute of Standards and Technology's (NIST) Security Content Automation Protocol (SCAP) 1.2 in the Authenticated Configuration Scanner category with the Common Vulnerabilities and Exposure (CVE) option. For details, see Chapter 11, Security . Cryptographic protocols and algorithms that are considered insecure, such as MD5, SHA0, RC4, or DH shorter than 1024 bits, have been deprecated. In addition, support for EXPORT cipher suites has been removed. For details, see the Red Hat Enterprise Linux 6.9 Technical Notes . Red Hat Insights Since Red Hat Enterprise Linux 6.7, the Red Hat Insights service is available. Red Hat Insights is a proactive service designed to enable you to identify, examine, and resolve known technical issues before they affect your deployment. Insights leverages the combined knowledge of Red Hat Support Engineers, documented solutions, and resolved issues to deliver relevant, actionable information to system administrators. The service is hosted and delivered through the customer portal at https://access.redhat.com/insights/ or through Red Hat Satellite. To register your systems, follow the Getting Started Guide for Insights . For further information, data security and limits, refer to https://access.redhat.com/insights/splash/ . Red Hat Customer Portal Labs Red Hat Customer Portal Labs is a set of tools in a section of the Customer Portal available at https://access.redhat.com/labs/ . The applications in Red Hat Customer Portal Labs can help you improve performance, quickly troubleshoot issues, identify security problems, and quickly deploy and configure complex applications. Some of the most popular applications are, for example: Kickstart Configurator Registration Assistant NFS Helper Linter for Dockerfile Multipath Helper iSCSI Helper Code Browser

Commands:
Chapter 5. Deleting a machine You can delete a specific machine. 5.1. Deleting a specific machine You can delete a specific machine. Note You cannot delete a control plane machine. Prerequisites Install an OpenShift Container Platform cluster. Install the OpenShift CLI ( oc ). Log in to oc as a user with cluster-admin permission. Procedure View the machines that are in the cluster and identify the one to delete: USD oc get machine -n openshift-machine-api The command output contains a list of machines in the <clusterid>-worker-<cloud_region> format. Delete the machine: USD oc delete machine <machine> -n openshift-machine-api Important By default, the machine controller tries to drain the node that is backed by the machine until it succeeds. In some situations, such as with a misconfigured pod disruption budget, the drain operation might not be able to succeed in preventing the machine from being deleted. You can skip draining the node by annotating "machine.openshift.io/exclude-node-draining" in a specific machine. If the machine being deleted belongs to a machine set, a new machine is immediately created to satisfy the specified number of replicas. 5.2. Additional resources Replacing an unhealthy etcd member .

Commands:
oc get machine -n openshift-machine-api
oc delete machine <machine> -n openshift-machine-api
Chapter 93. ExternalConfiguration schema reference The type ExternalConfiguration has been deprecated. Please use KafkaConnectTemplate instead. Used in: KafkaConnectSpec , KafkaMirrorMaker2Spec Full list of ExternalConfiguration schema properties Configures external storage properties that define configuration options for Kafka Connect connectors. You can mount ConfigMaps or Secrets into a Kafka Connect pod as environment variables or volumes. Volumes and environment variables are configured in the externalConfiguration property in KafkaConnect.spec or KafkaMirrorMaker2.spec . When applied, the environment variables and volumes are available for use when developing your connectors. For more information, see Loading configuration values from external sources . 93.1. ExternalConfiguration schema properties Property Property type Description env ExternalConfigurationEnv array The env property has been deprecated. The external configuration environment variables are deprecated and will be removed in the future. Please use the environment variables in a container template instead. Makes data from a Secret or ConfigMap available in the Kafka Connect pods as environment variables. volumes ExternalConfigurationVolumeSource array The volumes property has been deprecated. The external configuration volumes are deprecated and will be removed in the future. Please use the additional volumes and volume mounts in pod and container templates instead to mount additional secrets or config maps. Makes data from a Secret or ConfigMap available in the Kafka Connect pods as volumes.

Commands:
Chapter 12. Concepts to automate Data Grid CLI commands When interacting with an external Data Grid in Kubernetes, the Batch CR allows you to automate this using standard oc commands. 12.1. When to use it Use this when automating interactions on Kubernetes. This avoids providing usernames and passwords and checking shell script outputs and their status. For human interactions, the CLI shell might still be a better fit. 12.2. Example The following Batch CR takes a site offline as described in the operational procedure Take site offline . apiVersion: infinispan.org/v2alpha1 kind: Batch metadata: name: take-offline namespace: keycloak 1 spec: cluster: infinispan 2 config: | 3 site take-offline --all-caches --site=site-a site status --all-caches --site=site-a 1 The Batch CR must be created in the same namespace as the Data Grid deployment. 2 The name of the Infinispan CR. 3 A multiline string containing one or more Data Grid CLI commands. Once the CR has been created, wait for the status to show the completion. oc -n keycloak wait --for=jsonpath='{.status.phase}'=Succeeded Batch/take-offline Note Modifying a Batch CR instance has no effect. Batch operations are "one-time" events that modify Infinispan resources. To update .spec fields for the CR, or when a batch operation fails, you must create a new instance of the Batch CR. 12.3. Further reading For more information, see the Data Grid Operator Batch CR documentation .

Commands:
apiVersion: infinispan.org/v2alpha1 kind: Batch metadata: name: take-offline namespace: keycloak 1 spec: cluster: infinispan 2 config: | 3 site take-offline --all-caches --site=site-a site status --all-caches --site=site-a
-n keycloak wait --for=jsonpath='{.status.phase}'=Succeeded Batch/take-offline
3.2. Mounting an XFS File System An XFS file system can be mounted with no extra options, for example: The default for Red Hat Enterprise Linux 7 is inode64. Note Unlike mke2fs , mkfs.xfs does not utilize a configuration file; they are all specified on the command line. Write Barriers By default, XFS uses write barriers to ensure file system integrity even when power is lost to a device with write caches enabled. For devices without write caches, or with battery-backed write caches, disable the barriers by using the nobarrier option: For more information about write barriers, see Chapter 22, Write Barriers . Direct Access Technology Preview Since Red Hat Enterprise Linux 7.3, Direct Access (DAX) is available as a Technology Preview on the ext4 and XFS file systems. It is a means for an application to directly map persistent memory into its address space. To use DAX, a system must have some form of persistent memory available, usually in the form of one or more Non-Volatile Dual Inline Memory Modules (NVDIMMs), and a file system that supports DAX must be created on the NVDIMM(s). Also, the file system must be mounted with the dax mount option. Then, an mmap of a file on the dax-mounted file system results in a direct mapping of storage into the application's address space.

Commands:
mount /dev/ device /mount/point
mount -o nobarrier /dev/device /mount/point
3.3. Unmounting a GFS2 File System GFS2 file systems that have been mounted manually rather than automatically through Pacemaker will not be known to the system when file systems are unmounted at system shutdown. As a result, the GFS2 script will not unmount the GFS2 file system. After the GFS2 shutdown script is run, the standard shutdown process kills off all remaining user processes, including the cluster infrastructure, and tries to unmount the file system. This unmount will fail without the cluster infrastructure and the system will hang. To prevent the system from hanging when the GFS2 file systems are unmounted, you should do one of the following: Always use Pacemaker to manage the GFS2 file system. For information on configuring a GFS2 file system in a Pacemaker cluster, see Chapter 5, Configuring a GFS2 File System in a Cluster . If a GFS2 file system has been mounted manually with the mount command, be sure to unmount the file system manually with the umount command before rebooting or shutting down the system. If your file system hangs while it is being unmounted during system shutdown under these circumstances, perform a hardware reboot. It is unlikely that any data will be lost since the file system is synced earlier in the shutdown process. The GFS2 file system can be unmounted the same way as any Linux file system, by using the umount command. Note The umount command is a Linux system command. Information about this command can be found in the Linux umount command man pages. Usage MountPoint Specifies the directory where the GFS2 file system is currently mounted.

Commands:
umount MountPoint
3.3.4. Testing the Fence Configuration As of Red Hat Enterprise Linux Release 6.4, you can test the fence configuration for each node in a cluster with the fence_check utility. The following example shows the output of a successful execution of this command. For information on this utility, see the fence_check (8) man page.

Commands:
fence_check fence_check run at Wed Jul 23 09:13:57 CDT 2014 pid: 4769 Testing host-098 method 1: success Testing host-099 method 1: success Testing host-100 method 1: success
22.18. Configuring Clock Sources To list the available clock sources on your system, issue the following commands: In the above example, the kernel is using kvm-clock . This was selected at boot time as this is a virtual machine. To override the default clock source, add a line similar to the following in grub.conf : The available clock source is architecture dependent.

Commands:
~]USD cd /sys/devices/system/clocksource/clocksource0/ clocksource0]USD cat available_clocksource kvm-clock tsc hpet acpi_pm clocksource0]USD cat current_clocksource kvm-clock
clocksource=tsc