mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 14. DHCP Servers Dynamic Host Configuration Protocol ( DHCP ) is a network protocol that automatically assigns TCP/IP information to client machines. Each DHCP client connects to the centrally located DHCP server, which returns the network configuration (including the IP address, gateway, and DNS servers) of that client. 14.1. Why Use DHCP? DHCP is useful for automatic configuration of client network interfaces. When configuring the client system, you can choose DHCP instead of specifying an IP address, netmask, gateway, or DNS servers. The client retrieves this information from the DHCP server. DHCP is also useful if you want to change the IP addresses of a large number of systems. Instead of reconfiguring all the systems, you can just edit one configuration file on the server for the new set of IP addresses. If the DNS servers for an organization changes, the changes happen on the DHCP server, not on the DHCP clients. When you restart the network or reboot the clients, the changes go into effect. If an organization has a functional DHCP server correctly connected to a network, laptops and other mobile computer users can move these devices from office to office. Note that administrators of DNS and DHCP servers, as well as any provisioning applications, should agree on the host name format used in an organization. See Section 6.1.1, "Recommended Naming Practices" for more information on the format of host names.

Commands:
Chapter 1. Overview Red Hat build of Apache Qpid ProtonJ2 is a lightweight AMQP 1.0 library for the Java platform. It enables you to write Java applications that send and receive AMQP messages. Red Hat build of Apache Qpid ProtonJ2 is part of AMQ Clients, a suite of messaging libraries supporting multiple languages and platforms. For information on available clients, see AMQ Clients . 1.1. Key features SSL/TLS for secure communication Flexible SASL authentication Seamless conversion between AMQP and native data types Access to all the features and capabilities of AMQP 1.0 An integrated development environment with full IntelliSense API documentation 1.2. Supported standards and protocols Red Hat build of Apache Qpid ProtonJ2 supports the following industry-recognized standards and network protocols: Version 1.0 of the Advanced Message Queueing Protocol (AMQP) Versions 1.0, 1.1, 1.2, and 1.3 of the Transport Layer Security (TLS) protocol, the successor to SSL Simple Authentication and Security Layer (SASL) mechanisms ANONYMOUS, PLAIN, and EXTERNAL Modern TCP with IPv6 1.3. Supported configurations Refer to Red Hat AMQ Supported Configurations on the Red Hat Customer Portal for current information regarding Red Hat build of Apache Qpid ProtonJ2 supported configurations. 1.4. Terms and concepts This section introduces the core API entities and describes how they operate together. Table 1.1. API terms Entity Description Client A context for creating Connections to Brokers Connection A channel for communication between two peers on a network Session A context for sending and receiving messages Sender A channel for sending messages to a target Receiver A channel for receiving messages from a source Delivery A Delivery received from a IReceiver that can be acted upon and contains a message Message A mutable holder of application data Red Hat build of Apache Qpid ProtonJ2 sends and receives messages . Messages are transferred to Brokers via Senders and from Brokers using Receivers . Received Messages are wrapped in a Delivery which can be Accepted, Rejected or Released. Senders and Receivers are created using Connections which are in turn created using Clients . Sessions are established over Connections . 1.5. Document conventions The sudo command In this document, sudo is used for any command that requires root privileges. Exercise caution when using sudo because any changes can affect the entire system. For more information about sudo , see Using the sudo command . File paths In this document, all file paths are valid for Linux, UNIX, and similar operating systems (for example, /home/andrea ). On Microsoft Windows, you must use the equivalent Windows paths (for example, C:\Users\andrea ). Variable text This document contains code blocks with variables that you must replace with values specific to your environment. Variable text is enclosed in arrow braces and styled as italic monospace. For example, in the following command, replace <project-dir> with the value for your environment: USD cd <project-dir>

Commands:
cd <project-dir>
Chapter 91. Using canonicalized DNS host names in IdM DNS canonicalization is disabled by default on Identity Management (IdM) clients to avoid potential security risks. For example, if an attacker controls the DNS server and a host in the domain, the attacker can cause the short host name, such as demo , to resolve to a compromised host, such as malicious.example.com . In this case, the user connects to a different server than expected. This procedure describes how to use canonicalized host names on IdM clients. 91.1. Adding an alias to a host principal By default, Identity Management (IdM) clients enrolled by using the ipa-client-install command do not allow to use short host names in service principals. For example, users can use only host/demo.example.com@EXAMPLE.COM instead of host/demo@EXAMPLE.COM when accessing a service. Follow this procedure to add an alias to a Kerberos principal. Note that you can alternatively enable canonicalization of host names in the /etc/krb5.conf file. For details, see Enabling canonicalization of host names in service principals on clients . Prerequisites The IdM client is installed. The host name is unique in the network. Procedure Authenticate to IdM as the admin user: Add the alias to the host principal. For example, to add the demo alias to the demo.examle.com host principal: 91.2. Enabling canonicalization of host names in service principals on clients Follow this procedure to enable canonicalization of host names in services principals on clients. Note that if you use host principal aliases, as described in Adding an alias to a host principal , you do not need to enable canonicalization. Prerequisites The Identity Management (IdM) client is installed. You are logged in to the IdM client as the root user. The host name is unique in the network. Procedure Set the dns_canonicalize_hostname parameter in the [libdefaults] section in the /etc/krb5.conf file to false : 91.3. Options for using host names with DNS host name canonicalization enabled If you set dns_canonicalize_hostname = true in the /etc/krb5.conf file as explained in Enabling canonicalization of host names in service principals on clients , you have the following options when you use a host name in a service principal: In Identity Management (IdM) environments, you can use the full host name in a service principal, such as host/demo.example.com@EXAMPLE.COM . In environments without IdM, but if the RHEL host as a member of an Active Directory (AD) domain, no further considerations are required, because AD domain controllers (DC) automatically create service principals for NetBIOS names of the machines enrolled into AD.

Commands:
kinit admin
ipa host-add-principal demo.example.com --principal= demo
[libdefaults] dns_canonicalize_hostname = true
13.2.23. Creating Domains: Primary Server and Backup Servers Identity and authentication providers for a domain can be configured for automatic failover. SSSD attempts to connect to the specified, primary server first. If that server cannot be reached, then SSSD then goes through the listed backup servers, in order. Note SSSD tries to connect to the primary server every 30 seconds, until the connection can be re-established, and then switches from the backup to the primary. All of the major service areas have optional settings for primary and backup servers [3] . Table 13.11. Primary and Secondary Server Parameters Service Area Primary Server Attribute Backup Server Attribute LDAP identity provider ldap_uri ldap_backup_uri Active Directory identity provider ad_server ad_backup_server Identity Management (IdM or IPA) identity provider ipa_server ipa_backup_server Kerberos authentication provider krb5_server krb5_backup_server Kerberos authentication provider krb5_server krb5_backup_server Password change provider ldap_chpass_uri ldap_chpass_backup_uri One and only one server can be set as the primary server. (And, optionally, the primary server can be set to service discovery, using _srv_ rather than a host name.) Multiple backup servers can be set, in a comma-separated list. The backup server list is in order of preference, so the first server listed is tried first. [3] Most services default to the identity provider server if a specific server for that service is not set.

Commands:
[domain/EXAMPLE] id_provider = ad ad_server = ad.example.com ad_backup_server = ad1.example.com, ad-backup.example.com
7.286. xorg-x11-drv-wacom 7.286.1. RHBA-2013:0296 - xorg-x11-drv-wacom bug fix and enhancement update Updated xorg-x11-drv-wacom packages that fix several bugs and add various enhancements are now available for Red Hat Enterprise Linux 6. The xorg-x11-drv-wacom packages contain the X.Org X11 input drivers for Wacom graphics tablets. Note The xorg-x11-drv-wacom package has been upgraded to upstream version 0.16.1, which provides a number of bug fixes and enhancements over the version. (BZ#835266) Bug Fixes BZ#859851 Due to a bug in the input driver, covering the Expresskeys on the Wacom Intuos5 graphics tablet caused a spurious stylus jump to the upper left corner (0,0). This bug has been fixed and the described issue no longer occurs. BZ# 862939 Previously, the xorg.conf configuration file with two devices containing the same input node caused a double free error and subsequent failure of the X server. With this update, xorg.conf has been fixed, and the server crash is now prevented. Enhancements BZ# 838751 With this update, support for the Wacom Intuos5 series graphics tablets has been added to the xorg-x11-drv-wacom package. BZ#857088 With this update, support for the Wacom Cintiq 22HD series graphics tablets has been added to the xorg-x11-drv-wacom package. All users of xorg-x11-drv-wacom are advised to upgrade to these updated packages, which fix these bugs and add these enhancements.

Commands:
Chapter 4. Setting up to Debug Applications Red Hat Enterprise Linux offers multiple debugging and instrumentation tools to analyze and troubleshoot internal application behavior. Select the Debugging Tools and Desktop Debugging and Performance Tools Add-ons during the system installation to install the GNU Debugger (GDB) , Valgrind , SystemTap , ltrace , strace , and other tools. For the latest versions of GDB , Valgrind , SystemTap , strace , and ltrace , install Red Hat Developer Toolset . This installs memstomp , too. NOTE: Red Hat Developer Toolset is shipped as a Software Collection. The scl utility allows you to use it, running commands with the Red Hat Developer Toolset binaries used in preference to the Red Hat Enterprise Linux system equivalent. The memstomp utility is available only as a part of Red Hat Developer Toolset. In case installing the whole Developer Toolset is not desirable and memstomp is required, install only its component from Red Hat Developer Toolset. Install the yum-utils package in order to use the debuginfo-install tool: To debug applications and libraries available as part of Red Hat Enterprise Linux, install their respective debuginfo and source packages from the Red Hat Enterprise Linux repositories using the debuginfo-install tool. This applies to core dump file analysis, too. Install kernel debuginfo and source packages required by the SystemTap application. See the SystemTap Beginners Guide, Chapter 2.1.1., Installing SystemTap . To capture kernel dumps, install and configure kdump . Follow the instructions in the Kernel Crash Dump Guide, Chapter 7.2., Installing and Configuring kdump . Make sure SELinux policies allow the relevant applications to run not only normally but in debugging situations, too. See SELinux User's and Administrator's Guide, Section 11.3., Fixing Problems . Additional Resources Section 20.1, "Enabling Debugging with Debugging Information" SystemTap Beginners Guide

Commands:
yum install devtoolset-9
yum install devtoolset-9-memstomp
yum install yum-utils
5.7. Logging HAProxy Messages to rsyslog You can configure your system to log HAProxy messages to rsyslog by writing to the /dev/log socket. Alternately you can target the TCP loopback address, however this results in slower performance. The following procedure configures HAProxy to log messages to rsyslog . In the global section of the HAProxy configuration file, use the log directive to target the /dev/log socket. Update the frontend , backend , and listen proxies to send messages to the rsyslog service you configured in the global section of the HAProxy configuration file. To do this, add a log global directive to the defaults section of the configuration file, as shown. If you are running HAProxy within a chrooted environment, or you let HAProxy create a chroot directory for you by using the chroot configuration directive, then the socket must be made available within that chroot directory. You can do this by modifying the rsyslog configuration to create a new listening socket within the chroot filesystem. To do this, add the following lines to your rsyslog configuration file. To customize what and where HAProxy log messages will appear, you can use rsyslog filters as described in Basic Configuration of Rsyslog in the System Administrator's Guide .

Commands:
log /dev/log local0
defaults log global option httplog
USDModLoad imuxsock USDAddUnixListenSocket PATH_TO_CHROOT /dev/log
4.235. powerpc-utils 4.235.1. RHEA-2011:1562 - powerpc-utils bug fix and enhancement update An updated powerpc-utils package that fixes several bugs and adds various enhancements is now available for Red Hat Enterprise Linux 6. The powerpc-utils package provides various utilities for a PowerPC platform. The powerpc-utils package has been upgraded to upstream version 1.2.10, which provides a number of bug fixes and enhancements over the version. The powerpc-utils package now provides the following new features: BZ# 694541 The page coalescing feature that provides the ability to share identical pages in physical memory among multiple logical partitions. Identical pages are consolidated into one shared read-only copy, and expanded into individual copies if an individual partition change occurs. BZ# 632705 The lparstat tool that provides the ability to display various attributes of IBM Power Logical Partitions, such as CPU and memory entitlement and other similar attributes. Bug Fixes BZ# 698433 When removing memory from logical partition (LPAR) in Dynamic Logical Partitioning (DLPAR), the dynamic memory manager (drmgr) did not set the memory off-line correctly. As a consequence, the kernel of the LPAR panicked. This update corrects the code so that drmgr now sets memory off-line properly, and the kernel no longer crashes when removing memory in DLPAR. BZ# 739888 The drmgr(8) manual page contained obsolete information that drmgr is a part of the ppc64-utils suite. This has been corrected, and the manual page now states that drmgr is a part of the powerpc-utils suite. BZ# 739957 The ofpathname script was not able to convert the Open Firmware device path name to the logical device name for SAN disks. With this update, ofpathname converts path names to device names correctly. All users of powerpc-utils are advised to upgrade to this updated package, which fixes these bugs and adds these enhancements.

Commands:
Appendix C. Anaconda UI specific commands C.1. Commands used in Anaconda The "pwpolicy" command is an Anaconda UI specific command that can be used only in the %anaconda section of the kickstart file. pwpolicy (optional) This command can be used to enforce a custom password policy, which specifies requirements for passwords created during installation, based on factors such as password length and strength. Replace name with either root , user or luks to enforce the policy for the root password, user passwords, or LUKS passphrase, respectively. The libpwquality library is used to check minimum password requirements (length and quality). You can use the pwscore and pwmake commands provided by the libpwquality package to check the quality score of a password, or to create a random password with a given score. See the pwscore(1) and pwmake(1) man page for details about these commands. Important This command can only be used inside the %anaconda section. --minlen= - Sets the minimum allowed password length, in characters. The default is 6 . --minquality= - Sets the minimum allowed password quality as defined by the libpwquality library. The default value is 1 . --strict - Enables strict password enforcement. Passwords which do not meet the requirements specified in --minquality= and --minlen= will not be accepted. This option is disabled by default. --notstrict - Passwords which do not meet the minimum quality requirements specified by the --minquality= and -minlen= options will be allowed, after Done is clicked twice. --emptyok - Allows the use of empty passwords. Enabled by default for user passwords. --notempty - Disallows the use of empty passwords. Enabled by default for the root password and the LUKS passphrase. --changesok - Allows changing the password in the user interface, even if the Kickstart file already specifies a password. Disabled by default. --nochanges - Disallows changing passwords which are already set in the Kickstart file. Enabled by default.

Commands:
pwpolicy name [--minlen= length ] [--minquality= quality ] [--strict|--nostrict] [--emptyok|--noempty] [--changesok|--nochanges]
Chapter 5. Important notes 5.1. Preferred clients In general, AMQ clients that support the AMQP 1.0 standard are preferred for new application development. However, the following exceptions apply: If your implementation requires distributed transactions, use the AMQ Core Protocol JMS client. If you require MQTT or STOMP in your domain (for IoT applications, for instance), use community-supported MQTT or STOMP clients. The considerations above do not necessarily apply if you are already using: The AMQ OpenWire JMS client (the JMS implementation previously provided in A-MQ 6) The AMQ Core Protocol JMS client (the JMS implementation previously provided with HornetQ) 5.2. Legacy clients Deprecation of the CMS and NMS APIs The ActiveMQ CMS and NMS messaging APIs are deprecated in AMQ 7. It is recommended that users of the CMS API migrate to AMQ C++, and users of the NMS API migrate to AMQ .NET. The CMS and NMS APIs might have reduced functionality in AMQ 7. Deprecation of the legacy AMQ C++ client The legacy AMQ C++ client (the C++ client previously provided in MRG Messaging) is deprecated in AMQ 7. It is recommended that users of this API migrate to AMQ C++. The Core API is unsupported The Artemis Core API client is not supported. This client is distinct from the AMQ Core Protocol JMS client, which is supported.

Commands:
Chapter 4. Deploy the Configured Back End The Director installation uses a non-root user to execute commands, which includes orchestrating the deployment of the Block Storage back end. In Creating a Director Installation User , a user named stack is created for this purpose. This user is configured with elevated privileges. To deploy the lone back end configured in Chapter 3, Define a Single Back End , first log in as the stack user to the Undercloud. Then, deploy the back end (defined in the edited ~/templates/cinder-dellsc-config.yaml ) by running the following: Important If you passed any extra environment files when you created the overcloud, pass them again here using the -e option to avoid making undesired changes to the overcloud. For more information, see Modifying the overcloud environment in the Director Installation and Usage guide.

Commands:
openstack overcloud deploy --templates -e ~/templates/cinder-dellsc-config.yaml
2.4. Verifying that Red Hat Gluster Storage Instance is Running You can verify that the Red Hat Gluster Storage instance is running by performing a remote login to the Red Hat Gluster Storage instance and issuing a command. To verify that the Red Hat Gluster Storage instance is running: Navigate to http://aws.amazon.com . Log in to Amazon Web Services. The AWS Management Console screen displays. Click the EC2 option. The EC2 Management Console displays. In the Instances section click the Instances link. The screen displays your current instances. Check the Instance State column and verify that the instance is running. A yellow circle indicates a pending status while a green circle indicates that the instance is running. Select the instance and verify the details displayed in the Description tab. Use the domain name in the Public DNS field to remotely log in to the Red Hat Amazon Machine Image instance by using the following commands: Note You must use the key pair that was selected or created when launching the instance. For example, the key pair file name is rhs-aws.pem , and the Public DNS is ec2-user@ec2-23-20-52-123.compute-1.amazonaws.com : Verify that the glusterd daemon is running on the instance using the following command: # service glusterd status Note Samba and NFS-Ganesha channels are disabled by default. To use standalone Samba and NFS-Ganesha: For enabling and installing the Red Hat Gluster Storage Samba repository, see Deploying Samba on Red Hat Gluster Storage in Red Hat Gluster Storage 3.5 Installation Guide . For enabling and installing the Red Hat Gluster Storage NFS-Ganesha repository, see Deploying NFS-Ganesha on Red Hat Gluster Storage in Red Hat Gluster Storage 3.5 Installation Guide . Important Before using yum update to update the Amazon EC2 Red Hat Gluster Storage AMI, follow the steps listed in the Knowledgebase article at https://access.redhat.com/solutions/1556793

Commands:
ssh -i Key_Pair_File Public_DNS sudo su
ssh -i rhs-aws.pem ec2-user@ec2-23-20-52-123.compute-1.amazonaws.com sudo su