mtpti5iD/redhat-docs_dataset huggingface dataset:
8.2.5. Dialup Interfaces If connecting to the Internet via a dialup connection, a configuration file is necessary for the interface. PPP interface files are named using the following format ifcfg-ppp <X> (where <X> is a unique number corresponding to a specific interface). The PPP interface configuration file is created automatically when wvdial , the Network Administration Tool or Kppp is used to create a dialup account. It is also possible to create and edit this file manually. The following is a typical ifcfg-ppp0 file: Serial Line Internet Protocol (SLIP) is another dialup interface, although it is used less frequently. SLIP files have interface configuration file names such as ifcfg-sl0 . Other options, not already discussed, that may be used in these files include: DEFROUTE= <answer> , where <answer> is one of the following: yes - Set this interface as the default route. no - Do not set this interface as the default route. DEMAND= <answer> , where <answer> is one of the following: yes - This interface allows pppd to initiate a connection when someone attempts to use it. no - A connection must be manually established for this interface. IDLETIMEOUT= <value> , where <value> is the number of seconds of idle activity before the interface disconnects itself. INITSTRING= <string> , where <string> is the initialization string passed to the modem device. This option is primarily used in conjunction with SLIP interfaces. LINESPEED= <value> , where <value> is the baud rate of the device. Possible standard values include 57600 , 38400 , 19200 , and 9600 . MODEMPORT= <device> , where <device> is the name of the serial device that is used to establish the connection for the interface. MTU= <value> , where <value> is the Maximum Transfer Unit (MTU) setting for the interface. The MTU refers to the largest number of bytes of data a frame can carry, not counting its header information. In some dialup situations, setting this to a value of 576 results in fewer packets dropped and a slight improvement to the throughput for a connection. NAME= <name> , where <name> is the reference to the title given to a collection of dialup connection configurations. PAPNAME= <name> , where <name> is the username given during the Password Authentication Protocol (PAP) exchange that occurs to allow connections to a remote system. PERSIST= <answer> , where <answer> is one of the following: yes - This interface should be kept active at all times, even if deactivated after a modem hang up. no - This interface should not be kept active at all times. REMIP= <address> , where <address> is the remote system's IP address. This is usually left unspecified. WVDIALSECT= <name> , where <name> associates this interface with a dialer configuration in /etc/wvdial.conf . This file contains the phone number to be dialed and other important information for the interface.

Commands:
DEVICE=ppp0 NAME=test WVDIALSECT=test MODEMPORT=/dev/modem LINESPEED=115200 PAPNAME=test USERCTL=true ONBOOT=no PERSIST=no DEFROUTE=yes PEERDNS=yes DEMAND=no IDLETIMEOUT=600
Chapter 2. Cluster Operation This chapter provides a summary of the various cluster functions and features. From establishing cluster quorum to node fencing for isolation, these disparate features comprise the core functionality of the High Availability Add-On. 2.1. Quorum Overview In order to maintain cluster integrity and availability, cluster systems use a concept known as quorum to prevent data corruption and loss. A cluster has quorum when more than half of the cluster nodes are online. To mitigate the chance of data corruption due to failure, Pacemaker by default stops all resources if the cluster does not have quorum. Quorum is established using a voting system. When a cluster node does not function as it should or loses communication with the rest of the cluster, the majority working nodes can vote to isolate and, if needed, fence the node for servicing. For example, in a 6-node cluster, quorum is established when at least 4 cluster nodes are functioning. If the majority of nodes go offline or become unavailable, the cluster no longer has quorum Pacemaker stops clustered services. The quorum features in Pacemaker prevent what is also known as split-brain , a phenomenon where the cluster is separated from communication but each part continues working as separate clusters, potentially writing to the same data and possibly causing corruption or loss. Quorum support in the High Availability Add-On are provided by a Corosync plug-in called votequorum , which allows administrators to configure a cluster with a number of votes assigned to each system in the cluster and ensuring that only when a majority of the votes are present, cluster operations are allowed to proceed. In a situation where there is no majority (such as a two-node cluster where the internal communication network link becomes unavailable, resulting in a 50% cluster split), votequorum can be configured to have a tiebreaker policy, which administrators can configure to continue quorum using the remaining cluster nodes that are still in contact with the available cluster node that has the lowest node ID.

Commands:
18.12.10.7. TCP/UDP/SCTP Protocol ID: tcp, udp, sctp The chain parameter is ignored for this type of traffic and should either be omitted or set to root. . Table 18.9. TCP/UDP/SCTP 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 scripto IP_ADDR Start of range of source IP address srcipfrom 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 scrportstart UNIT16 Start of range of valid source ports; requires protocol srcportend UINT16 End of range of valid source ports; requires protocol dstportstart UNIT16 Start of range of valid destination ports; requires protocol dstportend UNIT16 End of range of valid destination ports; requires protocol comment STRING text string up to 256 characters state STRING comma separated list of NEW,ESTABLISHED,RELATED,INVALID or NONE flags STRING TCP-only: format of mask/flags with mask and flags each being a comma separated list of SYN,ACK,URG,PSH,FIN,RST or NONE or ALL ipset STRING The name of an IPSet managed outside of libvirt ipsetflags IPSETFLAGS flags for the IPSet; requires ipset attribute

Commands:
17.5. Configuring RAID Sets Most RAID sets are configured during creation, typically through the firmware menu or from the installer. In some cases, you may need to create or modify RAID sets after installing the system, preferably without having to reboot the machine and enter the firmware menu to do so. Some hardware RAID controllers allow you to configure RAID sets on-the-fly or even define completely new sets after adding extra disks. This requires the use of driver-specific utilities, as there is no standard API for this. Refer to your hardware RAID controller's driver documentation for information on this. mdadm The mdadm command-line tool is used to manage software RAID in Linux, i.e. mdraid . For information on the different mdadm modes and options, refer to man mdadm . The man page also contains useful examples for common operations like creating, monitoring, and assembling software RAID arrays. dmraid As the name suggests, dmraid is used to manage device-mapper RAID sets. The dmraid tool finds ATARAID devices using multiple metadata format handlers, each supporting various formats. For a complete list of supported formats, run dmraid -l . As mentioned earlier in Section 17.3, "Linux RAID Subsystems" , the dmraid tool cannot configure RAID sets after creation. For more information about using dmraid , refer to man dmraid .

Commands:
5.52. dnsmasq 5.52.1. RHEA-2012:0869 - dnsmasq enhancement update Updated dnsmasq packages that add an enhancement are now available for Red Hat Enterprise Linux 6. The dnsmasq package contains Dnsmasq, a lightweight DNS (Domain Name Server) forwarder and DHCP (Dynamic Host Configuration Protocol) server. Enhancement BZ# 794792 A new subpackage, dnsmasq-utils, has been added. The dnsmasq-utils subpackage contains the dhcp_lease_time and dhcp_release utilities, which serve to query and remove DHCP server leases using the standard DHCP protocol. All dnsmasq users are advised to upgrade to these updated packages, which add this enhancement.

Commands:
3.2. Creating an Image Builder blueprint with command-line interface This procedure describes how to create a new Image Builder blueprint using the command-line interface. Procedure 1. Create a plain text file with the following contents: Replace BLUEPRINT-NAME and LONGER BLUEPRINT DESCRIPTION with a name and description for your blueprint. Replace 0.0.1 with a version number according to the Semantic Versioning scheme. 2. For every package that you want to be included in the blueprint, add the following lines to the file: Replace package-name with name of the package, such as httpd , gdb-doc , or coreutils . Replace package-version with a version to use. This field supports dnf version specifications: For a specific version, use the exact version number such as 7.30 For latest available version, use the asterisk * For a latest minor version, use format such as 7.* . 3. Blueprints can be customized in a number of ways. For example, Simultaneous Multi-Threading (SMT) can be disabled by performing the steps below. For additional customizations available, please see the Section 3.7, " Supported Image Customizations " section. 4. Save the file as BLUEPRINT-NAME.toml and close the text editor. 5. Push (import) the blueprint: Replace BLUEPRINT-NAME with the value you used in steps. 6. To verify that the blueprint has been pushed and exists, list the existing blueprints: 7. Check whether the components and versions listed in the blueprint and their dependencies are valid:

Commands:
name = " BLUEPRINT-NAME " description = " LONGER BLUEPRINT DESCRIPTION TEXT " version = " 0.0.1 "
[[packages]] name = " package-name " version = " package-version "
[customizations.kernel] append = "nosmt=force"
composer-cli blueprints push BLUEPRINT-NAME.toml
composer-cli blueprints list
composer-cli blueprints depsolve BLUEPRINT-NAME
24.2. Viewing Memory Usage 24.2.1. Using the free Command The free command allows you to display the amount of free and used memory on the system. To do so, type the following at a shell prompt: free The free command provides information about both the physical memory ( Mem ) and swap space ( Swap ). It displays the total amount of memory ( total ), as well as the amount of memory that is in use ( used ), free ( free ), shared ( shared ), in kernel buffers ( buffers ), and cached ( cached ). For example: By default, free displays the values in kilobytes. To display the values in megabytes, supply the -m command-line option: free -m For instance: For a complete list of available command-line options, see the free (1) manual page.

Commands:
~]USD free total used free shared buffers cached Mem: 760752 661332 99420 0 6476 317200 -/+ buffers/cache: 337656 423096 Swap: 1540088 283652 1256436
~]USD free -m total used free shared buffers cached Mem: 742 646 96 0 6 309 -/+ buffers/cache: 330 412 Swap: 1503 276 1227
Chapter 1. Long Term Support for AMQ Broker 7.11 AMQ Broker 7.11 has been designated as a Long Term Support (LTS) release version. For details of the terms of an LTS release, see How long are AMQ LTS releases supported? Support for Red Hat Enterprise Linux and OpenShift Container Platform The AMQ Broker 7.11 LTS version supports: Red Hat Enterprise Linux 7, 8 and 9 OpenShift Container Platform 4.12, 4.13, 4.14 or 4.15 Red Hat strives to ensure that AMQ Broker remains compatible with future versions of OpenShift Container Platform; however this compatibility cannot be guaranteed. Interoperability testing is performed for each new OpenShift Container Platform version. If no compatibility issues are found, the new OpenShift Container Platform version is added to the Red Hat AMQ Broker 7 Supported Configurations .

Commands:
25.8. Creating a Self-Signed Certificate You can create your own self-signed certificate. Note that a self-signed certificate does not provide the security guarantees of a CA-signed certificate. Refer to Section 25.5, "Types of Certificates" for more details about certificates. To make your own self-signed certificate, first create a random key using the instructions provided in Section 25.6, "Generating a Key" . Once you have a key, make sure you are in the /usr/share/ssl/certs/ directory, and type the following command: The following output is shown and you are prompted for your passphrase (unless you generated a key without a passphrase): , you are asked for more information. The computer's output and a set of inputs looks like the following (provide the correct information for your organization and host): After you provide the correct information, a self-signed certificate is created in /etc/httpd/conf/ssl.crt/server.crt . Restart the secure server after generating the certificate with following the command:

Commands:
make testcert
umask 77 ; /usr/bin/openssl req -new -key -set_serial num /etc/httpd/conf/ssl.key/server.key -x509 -days 365 -out /etc/httpd/conf/ssl.crt/server.crt Using configuration from /usr/share/ssl/openssl.cnf Enter pass phrase:
You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [GB]: US State or Province Name (full name) [Berkshire]: North Carolina Locality Name (eg, city) [Newbury]: Raleigh Organization Name (eg, company) [My Company Ltd]: My Company, Inc. Organizational Unit Name (eg, section) []: Documentation Common Name (your name or server's hostname) []: myhost.example.com Email Address []: myemail@example.com
/sbin/service httpd restart
8.145. module-init-tools 8.145.1. RHBA-2014:1437 - module-init-tools bug fix update Updated module-init-tools packages that fix one bug are now available for Red Hat Enterprise Linux 6. The module-init-tools packages include various programs needed for automatic loading and unloading of modules under 2.6 kernels, as well as other module management programs. Device drivers and file systems are two examples of loaded and unloaded modules. Bug Fix BZ# 1045169 The modprobe utility did not previously recognize information about soft module dependencies in the modinfo section of the queried kernel modules. This update implements support for soft module dependencies, and the "modprobe --show-depends" command now returns this information as expected. Users of module-init-tools are advised to upgrade to these updated packages, which fix this bug.

Commands:
4.328. tomcatjss 4.328.1. RHBA-2011:1674 - tomcatjss bug fix update An updated tomcatjss package that fixes one bug is now available for Red Hat Enterprise Linux 6. The tomcatjss package provides a Java Secure Socket Extension (JSSE) implementation using Java Security Services (JSS) for Tomcat 6. Bug Fix BZ# 705107 If the server "admin" port was configured to accept a specific client authentication certificate, such as SSL (Secure Sockets Layer) certificate, other alternative authentication types failed even if the port was configured to accept them. The underlying code has been modified and the alternative authentication types are successful if called upon. All tomcatjss users are advised to upgrade to this updated package, which fixes this bug.

Commands:
A.2. Creating Dump Files You can request a dump of the core of a guest virtual machine to a file so that errors in the virtual machine can be diagnosed, for example by the crash utility . Warning In Red Hat Enterprise Linux 7.5 and later, the Kernel Address Space Randomization (KASLR) feature prevents guest dump files from being readable by crash . To fix this, add the <vmcoreinfo/> element to the <features> section of the XML configuration files of your guests. Note, however, that migrating guests with <vmcoreinfo/> fails if the destination host is using an OS that does not support <vmcoreinfo/> . These include Red Hat Enterprise Linux 7.4 and earlier, as well as Red Hat Enterprise Linux 6.9 and earlier. A.2.1. Creating virsh Dump Files Executing the virsh dump command sends a request to dump the core of a guest virtual machine to a file so errors in the virtual machine can be diagnosed. Running this command may require you to manually ensure proper permissions on file and path specified by the argument corefilepath . The virsh dump command is similar to a core dump(or the crash utility). For further information, see Creating a Dump File of a Guest Virtual Machine's Core . A.2.2. Saving a Core Dump Using a Python Script The dump-guest-memory.py python script implements a GNU Debugger (GDB) extension that extracts and saves a guest virtual machine's memory from the core dump after the qemu-kvm process crashes on a host. If the host-side QEMU process crash is related to guest actions, investigating the guest state at the time of the QEMU process crash could be useful. The python script implements a GDB extension. This is a new command for the GDB. After opening the core dump file of the original (crashed) QEMU process with GDB, the python script can be loaded into GDB. The new command can then be executed from the GDB prompt. This extracts a guest memory dump from the QEMU core dumpto a new local file. To use the dump-guest-memory.py python script: Install the qemu-kvm-debuginfo package on the system. Launch GDB, opening the core dump file saved for the crashed /usr/libexec/qemu-kvm binary. The debug symbols load automatically. Load the new command in GDB: Note After loading the python script, the built-in GDB help command can provide detailed information about the dump-guest-memory extension. Run the command in GDB. For example: Open /home/user/extracted-vmcore with the crash utility for guest kernel analysis. For more information about extracting guest virtual machine cores from QEMU core files for use with the crash utility, see How to extract ELF cores from 'gcore' generated qemu core files for use with the 'crash' utility .

Commands:
source /usr/share/qemu-kvm/dump-guest-memory.py
dump-guest-memory /home/user/extracted-vmcore X86_64
7.6.2. Useful Websites http://www.X.org/ - Home page of the X.Org Foundation, which produces the X11R6.8 release of the X Window System. The X11R6.8 release is bundled with Red Hat Enterprise Linux to control the necessary hardware and provide a GUI environment. http://xorg.freedesktop.org/ - Home page of the XR116.8 release, which provides binaries and documention for the X Window System. http://dri.sourceforge.net/ - Home page of the DRI (Direct Rendering Infrastructure) project. The DRI is the core hardware 3D acceleration component of X. http://www.gnome.org/ - Home of the GNOME project. http://www.kde.org/ - Home of the KDE desktop environment. http://nexp.cs.pdx.edu/fontconfig/ - Home of the Fontconfig font subsystem for X.

Commands:
Chapter 3. Technology Previews Important Technology Preview features are not supported with Red Hat production service-level agreements (SLAs) and might not be functionally complete; therefore, Red Hat does not recommend implementing any Technology Preview features in production environments. This Technology Preview feature provides early access to upcoming product innovations, enabling you to test functionality and provide feedback during the development process. For more information about support scope, see Technology Preview Features Support Scope . 3.1. Cruise Control for cluster rebalancing Note Cruise Control remains in Technology Preview, with some new enhancements . You can deploy Cruise Control and use it to rebalance your Kafka cluster using optimization goals - defined constraints on CPU, disk, network load, and more. In a balanced Kafka cluster, the workload is more evenly distributed across the broker pods. Cruise Control is configured and deployed as part of a Kafka resource. You can use the default optimization goals or modify them to suit your requirements. Example YAML configuration files for Cruise Control are provided in examples/cruise-control/ . When Cruise Control is deployed, you can create KafkaRebalance custom resources to: Generate optimization proposals from multiple optimization goals Rebalance a Kafka cluster based on an optimization proposal Other Cruise Control features are not currently supported, including anomaly detection, notifications, write-your-own goals, and changing the topic replication factor. See Cruise Control for cluster rebalancing . 3.1.1. Enhancements to the Technology Preview The following enhancements have been added to the Technology Preview of Cruise Control for cluster rebalancing. New goal: Minimum topic leaders per broker You can use a new goal named MinTopicLeadersPerBrokerGoal . For each topic in a defined group of topics, the goal ensures that each active broker has at least a certain number of leader replicas. MinTopicLeadersPerBrokerGoal is a default goal and is preset as a hard goal. See Optimization goals overview Logging enhancements: Dynamic logging configuration and Log4j 2 Cruise Control now supports dynamic logging configuration. This means that changing the logging level for Cruise Control no longer triggers a rolling update to the Kafka cluster or the Cruise Control pod. Log4j 2 is now used for Cruise Control logging. You must update existing configurations for Cruise Control logging from Log4j to Log4j 2 compatible syntax. Logging is configured in the Kafka custom resource. For inline logging , replace the cruisecontrol.root.logger property with the rootLogger.level property. For external logging , replace the existing configuration with a new configuration file named log4j2.properties . The configuration must use Log4j 2 compatible syntax. See External logging and Cruise Control configuration

Commands:
15.3. Files Installed with vsftpd The vsftpd RPM installs the daemon ( /usr/sbin/vsftpd ), its configuration and related files, as well as FTP directories onto the system. The following is a list of the files and directories most often considered when configuring vsftpd : /etc/rc.d/init.d/vsftpd - The initialization script ( initscript ) used by the /sbin/service command to start, stop, or reload vsftpd . Refer to Section 15.4, "Starting and Stopping vsftpd " for more information about using this script. /etc/pam.d/vsftpd - The Pluggable Authentication Modules (PAM) configuration file for vsftpd . This file defines the requirements a user must meet to login to the FTP server. For more information, refer to Chapter 16, Pluggable Authentication Modules (PAM) . /etc/vsftpd/vsftpd.conf - The configuration file for vsftpd . Refer to Section 15.5, " vsftpd Configuration Options" for a list of important options contained within this file. /etc/vsftpd.ftpusers - A list of users not allowed to log into vsftpd . By default, this list includes the root , bin , and daemon users, among others. /etc/vsftpd.user_list - This file can be configured to either deny or allow access to the users listed, depending on whether the userlist_deny directive is set to YES (default) or NO in /etc/vsftpd/vsftpd.conf . If /etc/vsftpd.user_list is used to grant access to users, the usernames listed must not appear in /etc/vsftpd.ftpusers . /var/ftp/ - The directory containing files served by vsftpd . It also contains the /var/ftp/pub/ directory for anonymous users. Both directories are world-readable, but writable only by the root user.

Commands: