mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 11. Storage Considerations During Installation Many storage device and file system settings can only be configured at install time. Other settings, such as file system type, can only be modified up to a certain point without requiring a reformat. As such, it is prudent that you plan your storage configuration accordingly before installing Red Hat Enterprise Linux 6. This chapter discusses several considerations when planning a storage configuration for your system. For actual installation instructions (including storage configuration during installation), refer to the Installation Guide provided by Red Hat. 11.1. Updates to Storage Configuration During Installation Installation configuration for the following settings/devices has been updated for Red Hat Enterprise Linux 6: Fibre-Channel over Ethernet (FCoE) Anaconda can now configure FCoE storage devices during installation. Storage Device Filtering Interface Anaconda now has improved control over which storage devices are used during installation. You can now control which devices are available/visible to the installer, in addition to which devices are actually used for system storage. There are two paths through device filtering: Basic Path For systems that only use locally attached disks and firmware RAID arrays as storage devices Advanced Path For systems that use SAN (e.g. multipath, iSCSI, FCoE) devices Auto-partitioning and /home Auto-partitioning now creates a separate logical volume for the /home file system when 50GB or more is available for allocation of LVM physical volumes. The root file system ( / ) will be limited to a maximum of 50GB when creating a separate /home logical volume, but the /home logical volume will grow to occupy all remaining space in the volume group.

Commands:
Chapter 1. Kafka tuning overview Fine-tuning the performance of your Kafka deployment involves optimizing various configuration properties according to your specific requirements. This section provides an introduction to common configuration options available for Kafka brokers, producers, and consumers. While a minimum set of configurations is necessary for Kafka to function, Kafka properties allow for extensive adjustments. Through configuration properties, you can enhance latency, throughput, and overall efficiency, ensuring that your Kafka deployment meets the demands of your applications. For effective tuning, take a methodical approach. Begin by analyzing relevant metrics to identify potential bottlenecks or areas for improvement. Adjust configuration parameters iteratively, monitoring the impact on performance metrics, and then refine your settings accordingly. For more information about Apache Kafka configuration properties, see the Apache Kafka documentation . Note The guidance provided here offers a starting point for tuning your Kafka deployment. Finding the optimal configuration depends on factors such as workload, infrastructure, and performance objectives. 1.1. Mapping properties and values How you specify configuration properties depends on the type of deployment. If you deployed Streams for Apache Kafka on OCP, you can use the Kafka resource to add configuration for Kafka brokers through the config property. With Streams for Apache Kafka on RHEL, you add the configuration to a properties file as environment variables. When you add config properties to custom resources, you use a colon (':') to map the property and value. Example configuration in a custom resource num.partitions:1 When you add the properties as environment variables, you use an equal sign ('=') to map the property and value. Example configuration as an environment variable num.partitions=1 Note Some examples in this guide may show resource configuration specifically for Streams for Apache Kafka on OpenShift. However, the properties presented are equally applicable as environment variables when using Streams for Apache Kafka on RHEL. 1.2. Tools that help with tuning The following tools help with Kafka tuning: Cruise Control generates optimization proposals that you can use to assess and implement a cluster rebalance Kafka Static Quota plugin sets limits on brokers Rack configuration spreads broker partitions across racks and allows consumers to fetch data from the nearest replica Additional resources For more information on these tools, see the following guides: Configuring Streams for Apache Kafka on OpenShift Using Streams for Apache Kafka on RHEL in KRaft mode Using Streams for Apache Kafka on RHEL with ZooKeeper

Commands:
num.partitions:1
num.partitions=1
Chapter 2. Installing the Red Hat JBoss Core Services 2.4.57 You can install the Apache HTTP Server 2.4.57 on Red Hat Enterprise Linux or Microsoft Windows. For more information, see the following sections of the installation guide: Installing the JBCS Apache HTTP Server on RHEL from archive files Installing the JBCS Apache HTTP Server on RHEL from RPM packages Installing the JBCS Apache HTTP Server on Microsoft Windows

Commands:
8.48. e2fsprogs 8.48.1. RHBA-2014:1566 - e2fsprogs bug fix and enhancement update Updated e2fsprogs packages that fix several bugs and add one enhancement are now available for Red Hat Enterprise Linux 6. The e2fsprogs packages provide a number of utilities for creating, checking, modifying, and correcting any inconsistencies in the ext2 file systems. Bug Fixes BZ# 1036122 The resize2fs utility sometimes caused file system corruption during an offline resize of an ext4 file system. This happened because resize2fs did not reserve all existing metadata blocks prior to executing the resize operation. This update fixes resize2fs to reserve all existing metadata blocks as expected in this situation. BZ# 1040122 The tune2fs man page states that the "-f" option can be used to remove a file system journal even if the journal requires replay. However, earlier versions of tune2fs did not behave as documented. This update allows tune2fs to remove a dirty journal by supplying two "-f" options on the command line. BZ# 1093446 With versions of mke2fs, it was possible to specify an unsupported and unmountable file system revision on the command line by using the "-r" option. The mke2fs utility now refuses to create a file system with a revision higher than is currently supported. BZ# 1097061 Previously, the e2image program could run against a mounted block device, resulting in an inconsistent metadata image. With this update, the e2image program now displays a warning message if the block device is mounted, and requires the "-f" option to proceed in this case. BZ# 1112242 With versions of e2fsck, "zeroed-out" directory blocks were not reported or repaired. The e2fsck utility now detects and repairs this type of corruption. In addition, this update adds the following Enhancement BZ# 1052409 The enable_periodic_fsck option has been added to /etc/mke2fs.conf to enable or disable periodic e2fsck operations when creating new file systems with the mke2fs utility. A periodic file system check is enabled by default. Users of e2fsprogs are advised to upgrade to these updated packages, which fix these bugs and add this enhancement.

Commands:
Preface The Red Hat build of Cryostat is a container-native implementation of JDK Flight Recorder (JFR) that you can use to securely monitor the Java Virtual Machine (JVM) performance in workloads that run on an OpenShift Container Platform cluster. You can use Cryostat 2.2 to start, stop, retrieve, archive, import, and export JFR data for JVMs inside your containerized applications by using a web console or an HTTP API. Depending on your use case, you can store and analyze your recordings directly on your Red Hat OpenShift cluster by using the built-in tools that Cryostat provides or you can export recordings to an external monitoring application to perform a more in-depth analysis of your recorded data. Important Red Hat build of Cryostat is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process. For more information about the support scope of Red Hat Technology Preview features, see Technology Preview Features Support Scope .

Commands:
5.39. createrepo 5.39.1. RHBA-2012:0354 - createrepo bug fix and enhancement update An updated createrepo package that fixes one bug is now available for Red Hat Enterprise Linux 6. This package contains scripts that generate a common metadata repository from a directory of RPM packages. Bug Fix BZ# 623105 Prior to this update, the shebang line of the modifyrepo.py script contained "#!/usr/bin/env python", so the system path was used to locate the Python executable. When another version of Python was installed on the system, and "/usr/local/python" was specified in the PATH environment variable, scripts did not work due to Python compatibility problems. With this update, the shebang line is modified to "#!/usr/bin/python", so that the system version of Python is always used. All users of createrepo are advised to upgrade to this updated package, which fixes this bug.

Commands:
Appendix A. Capsule Server Scalability Considerations The maximum number of Capsule Servers that Satellite Server can support has no fixed limit. The tested limit is 17 Capsule Servers with 2 vCPUs on a Satellite Server with Red Hat Enterprise Linux 7. However, scalability is highly variable, especially when managing Puppet clients. Capsule Server scalability when managing Puppet clients depends on the number of CPUs, the run-interval distribution, and the number of Puppet managed resources. Capsule Server has a limitation of 100 concurrent Puppet agents running at any single point in time. Running more than 100 concurrent Puppet agents results in a 503 HTTP error. For example, assuming that Puppet agent runs are evenly distributed with less than 100 concurrent Puppet agents running at any single point during a run-interval, a Capsule Server with 4 CPUs has a maximum of 1250 - 1600 Puppet clients with a moderate workload of 10 Puppet classes assigned to each Puppet client. Depending on the number of Puppet clients required, the Satellite installation can scale out the number of Capsule Servers to support them. If you want to scale your Capsule Server when managing Puppet clients, the following assumptions are made: There are no external Puppet clients reporting directly to the Satellite integrated Capsule. All other Puppet clients report directly to an external Capsule. There is an evenly distributed run-interval of all Puppet agents. Note Deviating from the even distribution increases the risk of overloading Satellite Server. The limit of 100 concurrent requests applies. The following table describes the scalability limits using the recommended 4 CPUs. Table A.1. Puppet Scalability Using 4 CPUs Puppet Managed Resources per Host Run-Interval Distribution 1 3000 - 2500 10 2400 - 2000 20 1700 - 1400 The following table describes the scalability limits using the minimum 2 CPUs. Table A.2. Puppet Scalability Using 2 CPUs Puppet Managed Resources per Host Run-Interval Distribution 1 1700 - 1450 10 1500 - 1250 20 850 - 700

Commands:
18.12.10.11. ICMPv6 Protocol ID: icmpv6 The chain parameter is ignored for this type of traffic and should either be omitted or set to root. Table 18.13. ICMPv6 protocol types Attribute Name Datatype Definition srcmacaddr MAC_ADDR MAC address of sender srcipaddr IP_ADDR Source IP address srcipmask IP_MASK Mask applied to source IP address dstipaddr IP_ADDR Destination IP address dstipmask IP_MASK Mask applied to destination IP address srcipfrom IP_ADDR start of range of source IP address scripto IP_ADDR end of range of source IP address dstipfrom IP_ADDR Start of range of destination IP address dstipto IP_ADDR End of range of destination IP address type UINT16 ICMPv6 type code UINT16 ICMPv6 code comment STRING text string up to 256 characters state STRING comma separated list of NEW,ESTABLISHED,RELATED,INVALID or NONE ipset STRING The name of an IPSet managed outside of libvirt ipsetflags IPSETFLAGS flags for the IPSet; requires ipset attribute

Commands:
Chapter 2. Upgrading the Red Hat Developer Hub Helm Chart You can upgrade to a later version of Red Hat Developer Hub in OpenShift Container Platform by using either the web console or the CLI. OpenShift Container Platform web console In the Developer perspective, click Helm to open the Helm Releases tab. Click the overflow menu on the Helm release that you want to use and select Upgrade . On the Upgrade Helm Release page, select the version of Developer Hub that you want to upgrade to from the chart version drop-down list. Click Upgrade . Note It might take a few minutes to delete the resources in the older versions and to start the newer versions of the Developer Hub pods. Close all open Developer Hub web pages, and log in again to verify that the upgrade was successful. OpenShift Container Platform CLI Log in to the OpenShift Container Platform cluster as the cluster administrator and switch to the project or namespace in which Developer Hub was installed. oc login -u <user> -p <password> https://api.<HOSTNAME>:6443 oc project my-rhdh-project For a new version of the Developer Hub Helm chart, run the following upgrade command: helm upgrade -i rhdh -f new-values.yml \ openshift-helm-charts/redhat-developer-hub --version 1.4.2 Note You can also provide extra values to the chart by creating a new-values.yml file on your workstation with values that override the attributes in the installed chart or by adding new attributes.

Commands:
login -u <user> -p <password> https://api.<HOSTNAME>:6443 project my-rhdh-project
helm upgrade -i rhdh -f new-values.yml openshift-helm-charts/redhat-developer-hub --version 1.4.2
Chapter 20. structured Original log entry as a structured object. This field may be present if the forwarder was configured to parse structured JSON logs. If the original log entry was a valid structured log, this field will contain an equivalent JSON structure. Otherwise this field will be empty or absent, and the message field will contain the original log message. The structured field can have any subfields that are included in the log message, there are no restrictions defined here. Data type group Example value map[message:starting fluentd worker pid=21631 ppid=21618 worker=0 pid:21631 ppid:21618 worker:0]

Commands:
Chapter 17. Using NetworkManager to disable IPv6 for a specific connection On a system that uses NetworkManager to manage network interfaces, you can disable the IPv6 protocol if the network only uses IPv4. If you disable IPv6 , NetworkManager automatically sets the corresponding sysctl values in the Kernel. Note If disabling IPv6 using kernel tunables or kernel boot parameters, additional consideration must be given to system configuration. For more information, see the Red Hat Knowledgebase solution How do I disable or enable the IPv6 protocol in RHEL . 17.1. Disabling IPv6 on a connection using nmcli You can use the nmcli utility to disable the IPv6 protocol on the command line. Prerequisites The system uses NetworkManager to manage network interfaces. Procedure Optional: Display the list of network connections: Set the ipv6.method parameter of the connection to disabled : Restart the network connection: Verification Display the IP settings of the device: If no inet6 entry is displayed, IPv6 is disabled on the device. Verify that the /proc/sys/net/ipv6/conf/ enp1s0 /disable_ipv6 file now contains the value 1 : The value 1 means that IPv6 is disabled for the device.

Commands:
nmcli connection show NAME UUID TYPE DEVICE Example 7a7e0151-9c18-4e6f-89ee-65bb2d64d365 ethernet enp1s0
nmcli connection modify Example ipv6.method "disabled"
nmcli connection up Example
ip address show enp1s0 2: enp1s0 : <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 52:54:00:6b:74:be brd ff:ff:ff:ff:ff:ff inet 192.0.2.1/24 brd 192.10.2.255 scope global noprefixroute enp1s0 valid_lft forever preferred_lft forever
cat /proc/sys/net/ipv6/conf/ enp1s0 /disable_ipv6 1
Chapter 8. ODBC Support 8.1. Install the ODBC Driver on Red Hat Enterprise Linux Prerequisites Administrative permissions are required. Download the correct ODBC driver package ( jboss-dv-psqlodbc-[version]- X .rpm ) from https://access.redhat.com/jbossnetwork/ . Install the package: sudo yum localinstall jboss-dv-psqlodbc-[version]- X .rpm . Note Installation packages for different operating systems can be downloaded from https://access.redhat.com/jbossnetwork/ .

Commands:
5.63. fcoe-utils 5.63.1. RHBA-2012:0851 - fcoe-utils bug fix and enhancement update Updated fcoe-utils packages that fix several bugs and add various enhancements are now available for Red Hat Enterprise Linux 6. The fcoe-utils package allows users to use Fibre Channel over Ethernet (FCoE). The package contains the fcoeadm command-line tool for configuring FCoE interfaces, and the fcoemon service to configure DCB (Data Center Bridging) Ethernet QoS filters. The fcoe-utils package has been upgraded to upstream version 1.0.22, which provides a number of bug fixes and enhancements over the version, including bash-completion enhancements and changing of the default FCoE interface names from 'device.vlan-fcoe' to 'device.vlan'. The -f (--fipvlan) option can be used to apply the behavior. (BZ# 788511 ) Bug Fix BZ# 804936 The "service fcoe status" command returned an incorrect return value when the fcoe service was running. With this update, the underlying code has been modified and fcoe now returns the correct code under these circumstances. All users of fcoe-utils are advised to upgrade to these updated packages, which fix these bugs and add these enhancements.

Commands:
Chapter 4. Versioning 4.1. Virtual Database Versioning Virtual database (VDB) versioning allows you to deploy multiple versions of a VDB simultaneously, and to specify which version will be used in certain scenarios. When an application connects to JBoss Data Virtualization, you can set the desired version of a VDB using a connection property. (Refer to the Red Hat JBoss Data Virtualization User Guide for more information.) If a specific version is set, then you can only connect to that VDB. If no version is set, the deployed VDBs are searched until the appropriate version is found. This feature helps support more dynamic migration scenarios.

Commands:
Chapter 8. Clustering and High Availability Administrative UI enhancements Luci, the web-based administrative UI for configuring clusters, has been updated to include the following: A confirmation dialog box appears when removing a clustered service. The UI includes an improved restart icon. The Add a child resource button has been simplified. An option to enable debugging from the UI has been added. Automatic timeout of inactive luci authenticated sessions As of Red Hat Enterprise Linux 6.3, luci authenticated sessions automatically time out after 15 minutes of inactivity. This period can be configured in the /etc/sysconfig/luci file by modifying the who.auth_tkt_timeout parameter. New libqb package The libqb package provides a library with the primary purpose of providing high performance client server reusable features, such as high performance logging, tracing, inter-process communication, and polling. This package is introduced as a dependency of the pacemaker package, and is considered a Technology Preview in Red Hat Enterprise Linux 6.3. Pacemaker now uses libqb logging Because of the newly added libqb dependency, pacemaker now uses its logging functionality to provide less verbosity while keeping the ability to debug and support pacemaker . Utilizing CPG API for inter-node locking Rgmanager includes a feature which enables it to utilize Corosync's Closed Process Group (CPG) API for inter-node locking. This feature is automatically enabled when Corosync's Redundant Ring Protocol (RRP) feature is enabled. Corosync's RRP feature is considered fully supported. However, when used with the rest of the High-Availability Add-Ons, it is considered a Technology Preview.

Commands:
Chapter 24. Servers and Services Printing a PDF file upside down with cups is currently impossible In the CUPS printing system, the -o orientation-requested=6 option in the lp -d [printer] -o orientation-requested=6 [filename] command, which is expected to rotate the printed page by 180deg, does not work. (BZ#1099617) Printing PDF files using the fit-to-page and fitplot options does not work on printers with hardware margins In the CUPS printing system, the lp -d printer-with-hwmargins -o fit-to-page and lp -d printer-with-hwmargins -o fitplot commands use the -o fit-to-page and -o fitplot options which resize the document to be printed so that it fits the paper size. The options do not work for printing PDF files on printers with hardware margins. (BZ#1268131) DHCP client sends unicast requests through the incorrect interface DHCP client does not support multiple interfaces on the same subnet and it is not able to ensure that unicast requests go through the right interface. Consequently, DHCP client fails to renew a lease, and network configuration stops working. There is no known workaround at this point. DHCP client cannot be used in configuration with two interfaces connected to the same subnet. (BZ# 1297445 ) A *.dsc file converted from a *.pdf file by the pdf2dsc script cannot be opened in Evince It is no longer possible to convert a *.pdf (Portable Document Format) file into a *.dsc (Document Structure Convention) file with the pdf2dsc script, and open the converted *.dsc file with the Evince GNOME document viewer, located outside the Ghostscript's sandbox. It is a result of the fixed -dSAFER option, which forces Ghostscript to operate in sandbox mode. For details and a workaround, see https://access.redhat.com/articles/2948831 . (BZ# 1411843 )

Commands:
function::print_ubacktrace Name function::print_ubacktrace - Print stack back trace for current task. EXPERIMENTAL! Synopsis Arguments None Description Equivalent to print_ustack( ubacktrace ), except that deeper stack nesting may be supported. Returns nothing. Note To get (full) backtraces for user space applications and shared shared libraries not mentioned in the current script run stap with -d /path/to/exe-or-so and/or add --ldd to load all needed unwind data.

Commands:
function print_ubacktrace()
6.9. VDB Reuse VDBs may reuse other VDBs deployed in the same server instance by using an "import-vdb" declaration in the vdb.xml file (see Section 6.1, "VDB Definition" ). An imported VDB can have its tables and procedures referenced by views and procedures in the importing VDB as if they are part of the VDB. Imported VDBs are required to exist before an importing VDB may start. If an imported VDB is undeployed, then any importing VDB will be stopped. An imported VDB includes all of its models and may not conflict with any model, data policy, or source already defined in the importing VDB. Once a VDB is imported it is mostly operationally independent from the base VDB. Only cost related metadata may be updated for an object from an imported VDB in the scope of the importing VDB. All other updates must be made through the original VDB, but they will be visible in all imported VDBs. Even materialized views are separately maintained for an imported VDB in the scope of each importing VDB. Example 6.3. Example reuse VDB XML In the above example the reuse VDB will have access to all of the models defined in the common VDB and adds in the "new-model".

Commands:
<vdb name="reuse" version="1"> <import-vdb name="common" version="1" import-data-policies="false"/> <model visible="true" type="VIRTUAL" name="new-model"> <metadata type = "DDL"><![CDATA[ CREATE VIEW x ( y varchar ) AS select * from old-model.tbl; ]]> </metadata> </model> </vdb>