mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 3. What is deployed with AMQ Streams Apache Kafka components are provided for deployment to OpenShift with the AMQ Streams distribution. The Kafka components are generally run as clusters for availability. A typical deployment incorporating Kafka components might include: Kafka cluster of broker nodes ZooKeeper cluster of replicated ZooKeeper instances Kafka Connect cluster for external data connections Kafka MirrorMaker cluster to mirror the Kafka cluster in a secondary cluster Kafka Exporter to extract additional Kafka metrics data for monitoring Kafka Bridge to make HTTP-based requests to the Kafka cluster Cruise Control to rebalance topic partitions across broker nodes Not all of these components are mandatory, though you need Kafka and ZooKeeper as a minimum. Some components can be deployed without Kafka, such as MirrorMaker or Kafka Connect. 3.1. Order of deployment The required order of deployment to an OpenShift cluster is as follows: Deploy the Cluster Operator to manage your Kafka cluster Deploy the Kafka cluster with the ZooKeeper cluster, and include the Topic Operator and User Operator in the deployment Optionally deploy: The Topic Operator and User Operator standalone if you did not deploy them with the Kafka cluster Kafka Connect Kafka MirrorMaker Kafka Bridge Components for the monitoring of metrics The Cluster Operator creates OpenShift resources for the components, such as Deployment , Service , and Pod resources. The names of the OpenShift resources are appended with the name specified for a component when it's deployed. For example, a Kafka cluster named my-kafka-cluster has a service named my-kafka-cluster-kafka .

Commands:
28.2. Network Time Protocol (NTP) Properties As shown in Figure 28.2, "NTP Properties" , the second tabbed window that appears is for configuring NTP. Figure 28.2. NTP Properties The Network Time Protocol (NTP) daemon synchronizes the system clock with a remote time server or time source. The application allows you to configure an NTP daemon to synchronize your system clock with a remote server. To enable this feature, select Enable Network Time Protocol . This enables the NTP Servers list and other options. You can choose one of the predefined servers, edit a predefined server by clicking the Edit or add a new server name by clicking Add . Your system does not start synchronizing with the NTP server until you click OK . After clicking OK , the configuration is saved and the NTP daemon is started (or restarted if it is already running). Clicking the OK button applies any changes made to the date and time, the NTP daemon settings, and the time zone settings. It also exits the program.

Commands:
Networking Guide Red Hat Enterprise Linux 7 Configuring and managing networks, network interfaces, and network services in RHEL 7 Marc Muehlfeld Red Hat Customer Content Services mmuehlfeld@redhat.com Ioanna Gkioka Red Hat Customer Content Services Mirek Jahoda Red Hat Customer Content Services Jana Heves Red Hat Customer Content Services Stephen Wadeley Red Hat Customer Content Services Christian Huffman Red Hat Customer Content Services

Commands:
probe::nfsd.createv3 Name probe::nfsd.createv3 - NFS server creating a regular file or set file attributes for client Synopsis nfsd.createv3 Values iap_mode file access mode filename file name client_ip the ip address of client fh file handle (the first part is the length of the file handle) createmode create mode .The possible values could be: NFS3_CREATE_EXCLUSIVE, NFS3_CREATE_UNCHECKED, or NFS3_CREATE_GUARDED filelen the length of file name iap_valid Attribute flags verifier file attributes (atime,mtime,mode). It's used to reset file attributes for CREATE_EXCLUSIVE truncp trunp arguments, indicates if the file shouldbe truncate Description This probepoints is only called by nfsd3_proc_create and nfsd4_open when op_claim_type is NFS4_OPEN_CLAIM_NULL.

Commands:
8.165. python-virtinst 8.165.1. RHBA-2013:1604 - python-virtinst bug fix and enhancement update Updated python-virtinst packages that fix several bugs and add one enhancement are now available for Red Hat Enterprise Linux 6. The python-virtinst package contains several command-line utilities, including virt-install for building and installing new virtual machines, and virt-clone for cloning existing virtual machines. Bug Fixes BZ# 861972 If there were duplicate USB devices connected to a host device, passing the vendorId or productId value to the "--host-device" option caused the virt-install utility to terminate with the following message: ERROR 'vendor' and 'product', or 'bus' and 'device' are required. This message did not inform about the duplicate devices, which was the cause of the error. The message has been modified to: ERROR 15e1:2007 corresponds to multiple node devices As a result, user is now informed about the true cause of the failed installation. BZ# 916875 Previously, when the "--disk" parameter contained the hash ("#") character, incorrect error messages were displayed. This bug has been fixed and error messages now inform about the unsupported character correctly. BZ# 921480 Prior to this update, the virt-install utility created sparse logical volumes by default. However, sparse logical volumes require further configuration and therefore should be created only by advanced users or management applications. With this update, non-sparse mode is the default and only available setting. BZ# 946972 Under rare circumstances, the virt-clone utility displayed incorrect speed statistics during the clone operation. This bug has been fixed, and correct speed values are now displayed when virt-clone is in action. BZ# 954262 Under certain circumstances, when there was the ".treeinfo" file available on the system, the virt-install utility attempted to get image information from this file. In case ".treeinfo" did not contain this information, virt-install terminated unexpectedly. This bug has been fixed, and virt-install now uses default values in case of incomplete ".treeinfo". BZ# 980334 Previously, an attempt to change the model type of a video device from "qxl" led the virt-manager utility to return the following error message: Error changing VM configuration: XML error: ram attribute only supported for type of qxl The underlying source code has been modified, and the model type of a video device can now be changed without complications. Enhancement BZ# 958496 This update provides a revised list of installation environments that are supported by the virt-manager utility. Users of python-virtinst are advised to upgrade to these updated packages, which fix these bugs and add this enhancement.

Commands:
Chapter 3. The rustfmt formatting tool With the rustfmt formatting tool, you can automatically format the source code of your Rust programs. You can use rusftmt either as a standalone tool or with Cargo. 3.1. Installing rustfmt Complete the following steps to install the rustfmt formatting tool. Prerequisites Rust Toolset is installed. For more information, see Installing Rust Toolset . Procedure Run the following command to install rustfmt : On Red Hat Enterprise Linux 8: On Red Hat Enterprise Linux 9: 3.2. Using rustfmt as a standalone tool Use rustfmt as a standalone tool to format a Rust source file and all its dependencies. As an alternative, use rustfmt with the Cargo build tool. For more information, see Using rustfmt with Cargo . Prerequisites An existing Rust project. For information on how to create a Rust project, see Creating a Rust project . Procedure To format a Rust source file using rustfmt as a standalone tool, run the following command: On Red Hat Enterprise Linux 8: Replace < source_file > with the name of your source file. Alternatively, you can replace < source_file > with standard input. rustfmt then provides its output in standard output. On Red Hat Enterprise Linux 9: Replace < source_file > with the name of your source file. Alternatively, you can replace < source_file > with standard input. rustfmt then provides its output in standard output. Note By default, rustfmt modifies the affected files without displaying details or creating backups. To display details and create backups, run rustfmt with the --write-mode value . 3.3. Using rustfmt with the Cargo build tool Use the rustfmt tool with Cargo to format a Rust source file and all its dependencies. As an alternative, use rustfmt as a standalone tool. For more information, see Using rustfmt as a standalone tool . Prerequisites An existing Rust project. For information on how to create a Rust project, see Creating a Rust project . Procedure To format all source files in a Cargo code package, run the following command: On Red Hat Enterprise Linux 8: On Red Hat Enterprise Linux 9: Note To change the rustfmt formatting options, create the configuration file rustfmt.toml in the project directory and add your configurations to the file. 3.4. Additional resources To display the help pages of rustfmt , run: On Red Hat Enterprise Linux 8: On Red Hat Enterprise Linux 9: To configure the rustfmt tool, create the rustfmt.toml configuration file in the project directory and add your configurations to the file. You can find the configuration options in the Configurations.md file. On Red Hat Enterprise Linux 8, you can find it under the following path: /usr/share/doc/rustfmt/Configurations.md On Red Hat Enterprise Linux 9, you can find it under the following path: /usr/share/doc/rustfmt/Configurations.md

Commands:
yum install rustfmt
dnf install rustfmt
rustfmt < source-file >
rustfmt < source-file >
cargo fmt
cargo fmt
rustfmt --help
rustfmt --help
12.3. Zone Files Zone files contain information about a namespace and are stored in the named working directory, /var/named/ , by default. Each zone file is named according to the file option data in the zone statement, usually in a way that relates to the domain in question and identifies the file as containing zone data, such as example.com.zone . Each zone file may contain directives and resource records . Directives tell the nameserver to perform tasks or apply special settings to the zone. Resource records define the parameters of the zone and assign identities to individual hosts. Directives are optional, but resource records are required to provide name service to a zone. All directives and resource records should be entered on individual lines. Comments can be placed after semicolon characters ( ; ) in zone files. 12.3.1. Zone File Directives Directives begin with the dollar sign character ( USD ) followed by the name of the directive. They usually appear at the top of the zone file. The following are commonly used directives: USDINCLUDE - Configures named to include another zone file in this zone file at the place where the directive appears. This allows additional zone settings to be stored apart from the main zone file. USDORIGIN - Appends the domain name to unqualified records, such as those with the hostname and nothing more. For example, a zone file may contain the following line: Any names used in resource records that do not end in a trailing period ( . ) are appended with example.com . Note The use of the USDORIGIN directive is unnecessary if the zone is specified in /etc/named.conf because the zone name is used as the value for the USDORIGIN directive by default. USDTTL - Sets the default Time to Live (TTL) value for the zone. This is the length of time, in seconds, a zone resource record is valid. Each resource record can contain its own TTL value, which overrides this directive. Increasing this value allows remote nameservers to cache the zone information for a longer period of time, reducing the number of queries for the zone and lengthening the amount of time required to proliferate resource record changes.

Commands:
USDORIGIN example.com.
12.2. Memcached Statistics The following table contains a list of valid statistics available using the memcached protocol in Red Hat JBoss Data Grid. Table 12.1. Memcached Statistics Statistic Data Type Details uptime 32-bit unsigned integer. Contains the time (in seconds) that the memcached instance has been available and running. time 32-bit unsigned integer. Contains the current time. version String Contains the current version. curr_items 32-bit unsigned integer. Contains the number of items currently stored by the instance. total_items 32-bit unsigned integer. Contains the total number of items stored by the instance during its lifetime. cmd_get 64-bit unsigned integer Contains the total number of get operation requests (requests to retrieve data). cmd_set 64-bit unsigned integer Contains the total number of set operation requests (requests to store data). get_hits 64-bit unsigned integer Contains the number of keys that are present from the keys requested. get_misses 64-bit unsigned integer Contains the number of keys that were not found from the keys requested. delete_hits 64-bit unsigned integer Contains the number of keys to be deleted that were located and successfully deleted. delete_misses 64-bit unsigned integer Contains the number of keys to be deleted that were not located and therefore could not be deleted. incr_hits 64-bit unsigned integer Contains the number of keys to be incremented that were located and successfully incremented incr_misses 64-bit unsigned integer Contains the number of keys to be incremented that were not located and therefore could not be incremented. decr_hits 64-bit unsigned integer Contains the number of keys to be decremented that were located and successfully decremented. decr_misses 64-bit unsigned integer Contains the number of keys to be decremented that were not located and therefore could not be decremented. cas_hits 64-bit unsigned integer Contains the number of keys to be compared and swapped that were found and successfully compared and swapped. cas_misses 64-bit unsigned integer Contains the number of keys to be compared and swapped that were not found and therefore not compared and swapped. cas_badval 64-bit unsigned integer Contains the number of keys where a compare and swap occurred but the original value did not match the supplied value. evictions 64-bit unsigned integer Contains the number of eviction calls performed. bytes_read 64-bit unsigned integer Contains the total number of bytes read by the server from the network. bytes_written 64-bit unsigned integer Contains the total number of bytes written by the server to the network. Report a bug

Commands:
4.3. Main Configuration File The /etc/selinux/config file is the main SELinux configuration file. It controls whether SELinux is enabled or disabled and which SELinux mode and SELinux policy is used: SELINUX= The SELINUX option sets whether SELinux is disabled or enabled and in which mode - enforcing or permissive - it is running: When using SELINUX=enforcing , SELinux policy is enforced, and SELinux denies access based on SELinux policy rules. Denial messages are logged. When using SELINUX=permissive , SELinux policy is not enforced. SELinux does not deny access, but denials are logged for actions that would have been denied if running SELinux in enforcing mode. When using SELINUX=disabled , SELinux is disabled, the SELinux module is not registered with the Linux kernel, and only DAC rules are used. SELINUXTYPE= The SELINUXTYPE option sets the SELinux policy to use. Targeted policy is the default policy. Only change this option if you want to use the MLS policy. For information on how to enable the MLS policy, see Section 4.13.2, "Enabling MLS in SELinux" .

Commands:
This file controls the state of SELinux on the system. SELINUX= can take one of these three values: enforcing - SELinux security policy is enforced. permissive - SELinux prints warnings instead of enforcing. disabled - No SELinux policy is loaded. SELINUX=enforcing SELINUXTYPE= can take one of these two values: targeted - Targeted processes are protected, mls - Multi Level Security protection. SELINUXTYPE=targeted
7.259. udev 7.259.1. RHBA-2013:0435 - udev bug fix and enhancement update Updated udev packages that fix several bugs and add one enhancement are now available for Red Hat Enterprise Linux 6. The udev packages implement a dynamic device directory, providing only the devices present on the system. This dynamic directory is managed in user space, dynamically creates and removes devices, provides consistent naming, and a user-space API. Bug Fixes BZ#784697 Previously, the /dev/disk/by-id file contained all expected symbolic links for cciss devices, but only one device link was present in the /dev/disk/by-path/ directory. This bug has been fixed and this file now contains all symbolic links as expected. BZ# 790321 The udev(7) man page did not document the hex encoding of blacklisted characters used in the device or symbolic link names. This update adds a paragraph about character encoding into the SYMLINK section of the udev(7) man page. BZ#829188 Due to a bug in the binutils linker, the libudev library lost the ExecShield (GNU_RELRO) section and was not protected by the ExecShield security mechanism. This update contains libudev with the ExecShield (GNU_RELRO) section included. BZ# 838451 When using multipath devices, the udev utility tried to make a UUID symbolic link for all the different paths, but only the first one succeeded. Consequently, udev wrote several "File exists" error messages to the system log. This update provides a patch to change these messages from being logged as an error message to being logged as an informational message. BZ#847925 When no medium was inserted in a drive, the cdrom_id utility, which is an udev helper tool, could not read DV and CD-ROM drive profiles. Consequently, the udev properties for the device node of the drive may not have contained all properties describing the capabilities of the drive, which could prevent other software using the udev database from offering all functionality for the drive. This bug has been fixed and all udev properties for the drive, which cdrom_id detects via drive's properties, are now stored for the device as expected. Enhancement BZ#826396 Previously, kernel messages showed device names instead of persistent device names provided by udev. As a consequence, device names could point to different devices every boot. This enhancement adds a new feature, which stores the mapping of device names, such as sda or sdb, and persistent device names to kernel messages. All users of udev are advised to upgrade to these updated packages, which fix these bugs and add this enhancement.

Commands:
5.9. Creating Distributed Dispersed Volumes Distributed dispersed volumes support the same configurations of erasure coding as dispersed volumes. The number of bricks in a distributed dispersed volume must be a multiple of (K+M). With this release, the following configurations are supported: Multiple disperse sets containing 6 bricks with redundancy level 2 Multiple disperse sets containing 10 bricks with redundancy level 2 Multiple disperse sets containing 11 bricks with redundancy level 3 Multiple disperse sets containing 12 bricks with redundancy level 4 Multiple disperse sets containing 20 bricks with redundancy level 4 Important Distributed dispersed volume configuration is supported only on JBOD storage. For more information, see Section 19.1.2, "JBOD" . Use gluster volume create to create different types of volumes, and gluster volume info to verify successful volume creation. Prerequisites A trusted storage pool has been created, as described in Section 4.1, "Adding Servers to the Trusted Storage Pool" . Understand how to start and stop volumes, as described in Section 5.10, "Starting Volumes" . Figure 5.5. Illustration of a Distributed Dispersed Volume Creating distributed dispersed volumes Important Red Hat recommends you to review the Distributed Dispersed Volume configuration recommendations explained in Section 11.16, "Recommended Configurations - Dispersed Volume" before creating the Distributed Dispersed volume. Run the gluster volume create command to create the dispersed volume. The syntax is # gluster volume create NEW-VOLNAME disperse-data COUNT [redundancy COUNT ] [transport tcp | rdma (Deprecated) | tcp,rdma] NEW-BRICK... The default value for transport is tcp . Other options can be passed such as auth.allow or auth.reject . See Section 11.1, "Configuring Volume Options" for a full list of parameters. Example 5.9. Distributed Dispersed Volume with Six Storage Servers The above example is illustrated in Figure 5.4, "Illustration of a Dispersed Volume" . In the illustration and example, you are creating 12 bricks from 6 servers. Run # gluster volume start VOLNAME to start the volume. Important The open-behind volume option is enabled by default. If you are accessing the distributed dispersed volume using the SMB protocol, you must disable the open-behind volume option to avoid performance bottleneck on large file workload. Run the following command to disable open-behind volume option: For information on open-behind volume option, see Section 11.1, "Configuring Volume Options" Run gluster volume info command to optionally display the volume information.

Commands:
gluster v create glustervol disperse-data 4 redundancy 2 transport tcp server1:/rhgs1/brick1 server2:/rhgs2/brick2 server3:/rhgs3/brick3 server4:/rhgs4/brick4 server5:/rhgs5/brick5 server6:/rhgs6/brick6 server1:/rhgs7/brick7 server2:/rhgs8/brick8 server3:/rhgs9/brick9 server4:/rhgs10/brick10 server5:/rhgs11/brick11 server6:/rhgs12/brick12 volume create: glutervol: success: please start the volume to access data.
gluster v start glustervol volume start: glustervol: success
gluster volume set VOLNAME open-behind off
Chapter 7. LVM Administration with the LVM GUI In addition to the Command Line Interface (CLI), LVM provides a Graphical User Interface (GUI) which you can use to configure LVM logical volumes. You can bring up this utility by typing system-config-lvm . The LVM chapter of the Red Hat Enterprise Linux Deployment Guide provides step-by-step instructions for configuring an LVM logical volume using this utility. In addition, the LVM GUI is availalbe as part of the Conga management interface. For information on using the LVM GUI with Conga, see the online help for Conga.

Commands:
Chapter 11. DDL Metadata 11.1. DDL Metadata A VDB can define models/schemas using DDL. Here is a small example of how one can define a view inside the -vdb.xml file. See the <metadata> element under <model> . Example 11.1. Example to show view definition Another complete DDL based example is at the end of this section. Note The declaration of metadata using DDL, NATIVE or DDL-FILE is supported out of the box, however the MetadataRepository interface allows users to plug-in their own metadata facilities. For example, you can write a Hibernate based store that can feed the necessary metadata. You can find out more about custom metadata repositories in Red Hat JBoss Data Virtualization Development Guide: Server Development . Note The DDL based schema is not constrained to be defined only for the view models. Note The full grammar for DDL is in the appendix.

Commands:
<model visible = "true" type = "VIRTUAL" name = "customers"> <metadata type = "DDL"><![CDATA[ CREATE VIEW PARTS ( PART_ID integer PRIMARY KEY, PART_NAME varchar(255), PART_COLOR varchar(30), PART_WEIGHT varchar(255) ) AS select a.id as PART_ID, a.name as PART_NAME, b.color as PART_COLOR, b.weight as PART_WEIGHT from modelA.part a, modelB.part b where a.id = b.id ]]> </metadata> </model>