mtpti5iD/redhat-docs_dataset huggingface dataset:
4.4. GLOBAL SETTINGS The GLOBAL SETTINGS panel is where the you define the networking details for the primary LVS router's public and private network interfaces. Figure 4.3. The GLOBAL SETTINGS Panel The top half of this panel sets up the primary LVS router's public and private network interfaces. These are the interfaces already configured in Section 3.1.1, "Configuring Network Interfaces for Load Balancer Add-On with NAT" . Primary server public IP In this field, enter the publicly routable real IP address for the primary LVS node. Primary server private IP Enter the real IP address for an alternative network interface on the primary LVS node. This address is used solely as an alternative heartbeat channel for the backup router and does not have to correlate to the real private IP address assigned in Section 3.1.1, "Configuring Network Interfaces for Load Balancer Add-On with NAT" . You may leave this field blank, but doing so will mean there is no alternate heartbeat channel for the backup LVS router to use and therefore will create a single point of failure. Note The private IP address is not needed for Direct Routing configurations, as all real servers as well as the LVS directors share the same virtual IP addresses and should have the same IP route configuration. Note The primary LVS router's private IP can be configured on any interface that accepts TCP/IP, whether it be an Ethernet adapter or a serial port. TCP Timeout Enter the time (in seconds) before a TCP session will timeout. The default timeout value is 0. TCP Fin Timeout Enter the time (in seconds) before a TCP session will timeout after receiving a FIN packet. The default timeout value is 0. UDP Timeout Enter the time (in seconds) before a UDP session will timeout. The default timeout value is 0. Use network type Click the NAT button to select NAT routing. Click the Direct Routing button to select direct routing. The three fields deal specifically with the NAT router's virtual network interface connecting the private network with the real servers. These fields do not apply to the direct routing network type. NAT Router IP Enter the private floating IP in this text field. This floating IP should be used as the gateway for the real servers. NAT Router netmask If the NAT router's floating IP needs a particular netmask, select it from drop-down list. NAT Router device Use this text field to define the device name of the network interface for the floating IP address, such as eth1:1 . Note You should alias the NAT floating IP address to the Ethernet interface connected to the private network. In this example, the private network is on the eth1 interface, so eth1:1 is the floating IP address. Warning After completing this page, click the ACCEPT button to make sure you do not lose any changes when selecting a new panel.

Commands:
8.76. irqbalance 8.76.1. RHBA-2013:1583 - irqbalance bug fix update Updated irqbalance packages that fix several bugs are now available for Red Hat Enterprise Linux 6. The irqbalance packages provide a daemon that evenly distributes interrupt request (IRQ) load across multiple CPUs for enhanced performance. Bug Fixes BZ# 951720 Previously, irqbalance warned about MSI interrupts, and that IRQs would not be properly classified due to the use of a kernel version older than kernel-2.6.32-279. This update blocks users from using irqbalance with an older version of the kernel, without features required for processing MSI interrupts, and warning messages are no longer received. BZ# 975524 Due to recent changes in the irqbalance packages, the /var/run/irqbalance.pid file was not created upon start of the irqbalance service, causing irqbalance to become non-compliant with the Linux Standard Base (LSB) specification. This update provides a patch fixing this problem so the irqbalance packages are LSB compliant again. BZ# 991363 A bug in the irqbalance code caused the irqbalance daemon to terminate with a segmentation fault when a CPU was hot plugged or hot unplugged. This update fixes a corrupted IRQ rebalance list and the irqbalance daemon no longer crashes in this scenario. Users of irqbalance are advised to upgrade to these updated packages, which fix these bugs.

Commands:
Chapter 63. Deprecated Device Drivers Deprecated Device Drivers The following device drivers continue to be supported until the end of life of Red Hat Enterprise Linux 7 but will likely not be supported in future major releases of this product and are not recommended for new deployments. 3w-9xxx 3w-sas aic79xx aoe arcmsr ata drivers: acard-ahci sata_mv sata_nv sata_promise sata_qstor sata_sil sata_sil24 sata_sis sata_svw sata_sx4 sata_uli sata_via sata_vsc bfa cxgb3 cxgb3i e1000 floppy hptiop initio isci iw_cxgb3 mptbase mptctl mptsas mptscsih mptspi mtip32xx mvsas mvumi OSD drivers: osd libosd osst pata drivers: pata_acpi pata_ali pata_amd pata_arasan_cf pata_artop pata_atiixp pata_atp867x pata_cmd64x pata_cs5536 pata_hpt366 pata_hpt37x pata_hpt3x2n pata_hpt3x3 pata_it8213 pata_it821x pata_jmicron pata_marvell pata_netcell pata_ninja32 pata_oldpiix pata_pdc2027x pata_pdc202xx_old pata_piccolo pata_rdc pata_sch pata_serverworks pata_sil680 pata_sis pata_via pdc_adma pm80xx(pm8001) pmcraid qla3xxx stex sx8 tulip ufshcd wireless drivers: carl9170 iwl4965 iwl3945 mwl8k rt73usb rt61pci rtl8187 wil6210

Commands:
5.112. iproute 5.112.1. RHBA-2012:0835 - iproute bug fix and enhancement update An updated iproute package that fixes two bugs and adds three enhancements is now available for Red Hat Enterprise Linux 6. The iproute package contains networking utilities (ip and rtmon, for example), which are designed to use the advanced networking capabilities of the Linux kernel. Bug Fixes BZ# 730627 The ip6tunnel mode command passed a zeroed parameter structure to the kernel, which attempted to change all tunnel parameters to zero and failed. Consequently, users could not change ip6tunnel parameters. With this update, the ip6tunnel code has been changed so that it updates only the changed parameters. As a result, it is now possible for users to adjust ip6tunnel parameters as expected. BZ# 736106 The lnstat utility used an incorrect file descriptor for its dump output. Consequently, the lnstat utility printed its dump output to stderr rather than to stdout. The code has been fixed and lnstat now prints its dump output to stdout. Enhancements BZ# 748767 The tc utility (a traffic control tool) has been enhanced to allow users to work with the Multi-queue priority (MQPRIO) Queueing Discipline (qdiscs) scheduler. With MQPRIO qdiscs, QOS can be offloaded from NICs that support external QOS schedulers. As a result, it is now possible for users to monitor traffic classes, gather statistics, set socket-buffer (SKB) priority and socket-priority-to-traffic-class mapping. BZ# 788120 The tc utility has been updated to work with Quick Fair Queueing (QFQ) kernel features. Users can now take advantage of the new QFQ-traffic scheduler from user space. BZ# 812779 This update adds support for multiple multicast routing tables. Users are advised to upgrade to this updated iproute package, which fixes these bugs and adds these enhancements.

Commands:
Chapter 1. Getting started Learn about how to get started with Red Hat Ceph Storage and its basic features. This information is designed for customers that are new to Red Hat Ceph Storage or established customers wanting an overview of how Red Hat Ceph Storage works and where to start in the workflow. This information provides basic workflows for Red Hat Ceph Storage. For detailed instructions links to the correct documentation sections are provided. Use this information to understand how to use Red Hat Ceph Storage basic workflows. For detailed instructions links to the correct documentation section are provided. Before you begin to start working with Red Hat Ceph Storage, familiarize yourself with the following information: Compatibility Matrix for Red Hat Ceph Storage 8.0 Minimum hardware considerations Network considerations for Red Hat Ceph Storage Basic Red Hat Ceph Storage considerations

Commands:
5.8.3. Mounting an NFS Volume By default, NFS mounts on the client side are labeled with a default context defined by policy for NFS volumes. In common policies, this default context uses the nfs_t type. Depending on policy configuration, services, such as Apache HTTP Server and MySQL, may not be able to read files labeled with the nfs_t type. This may prevent file systems labeled with this type from being mounted and then read or exported by other services. If you would like to mount an NFS volume and read or export that file system with another service, use the context option when mounting to override the nfs_t type. Use the following context option to mount NFS volumes so that they can be shared via the Apache HTTP Server: Since these changes are not written to disk, the context specified with this option does not persist between mounts. Therefore, this option must be used with the same context specified during every mount to retain the desired context. For information about making context mount persistent, refer to the Section 5.8.5, "Making Context Mounts Persistent" . As an alternative to mounting file systems with context options, Booleans can be enabled to allow services access to file systems labeled with the nfs_t type. Refer to Managing Confined Services for instructions on configuring Booleans to allow services access to the nfs_t type.

Commands:
~]# mount server:/export /local/mount/point -o context="system_u:object_r:httpd_sys_content_t:s0"
Chapter 13. Installing Using Anaconda This chapter provides step-by-step instructions for installing Red Hat Enterprise Linux using the Anaconda installer. The bulk of this chapter describes installation using the graphical user interface. A text mode is also available for systems with no graphical display, but this mode is limited in certain aspects (for example, custom partitioning is not possible in text mode). If your system does not have the ability to use the graphical mode, you can: Use Kickstart to automate the installation as described in Chapter 27, Kickstart Installations Perform the graphical installation remotely by connecting to the installation system from another computer with a graphical display using the VNC (Virtual Network Computing) protocol - see Chapter 25, Using VNC 13.1. Introduction to Anaconda The Red Hat Enterprise Linux installer, Anaconda , is different from most other operating system installation programs due to its parallel nature. Most installers follow a fixed path: you must choose your language first, then you configure network, then installation type, then partitioning, and so on. There is usually only one way to proceed at any given time. In Anaconda you are only required to select your language and locale first, and then you are presented with a central screen, where you can configure most aspects of the installation in any order you like. This does not apply to all parts of the installation process, however - for example, when installing from a network location, you must configure the network before you can select which packages to install. Some screens will be automatically configured depending on your hardware and the type of media you used to start the installation. You can still change the detected settings in any screen. Screens which have not been automatically configured, and therefore require your attention before you begin the installation, are marked by an exclamation mark. You cannot start the actual installation process before you finish configuring these settings. Additional differences appear in certain screens; notably the custom partitioning process is very different from other Linux distributions. These differences are described in each screen's subsection.

Commands:
Chapter 2. Providing feedback in the Ansible plug-ins The Ansible plug-ins provide a feedback form where you can suggest new features and content, as well as general feedback. Click the Ansible A icon in the Red Hat Developer Hub navigation panel. Click the Feedback icon to display the feedback form. Enter the feedback you want to provide. Tick the I understand that feedback is shared with Red Hat checkbox. Click Submit . Note To ensure that Red Hat receives your feedback, exclude your Red Hat Developer Hub URL in any browser ad blockers or privacy tools.

Commands:
37.2. Persistent Module Loading Kernel modules are usually loaded directly by the facility that requires them, which is given correct settings in the /etc/modprobe.conf file. However, it is sometimes necessary to explicitly force the loading of a module at boot time. Red Hat Enterprise Linux checks for the existence of the /etc/rc.modules file at boot time, which contains various commands to load modules. The rc.modules should be used, and not rc.local because rc.modules is executed earlier in the boot process. For example, the following commands configure loading of the foo module at boot time (as root): Note This approach is not necessary for network and SCSI interfaces because they have their own specific mechanisms.

Commands:
echo modprobe foo >> /etc/rc.modules chmod +x /etc/rc.modules
7.2. Known Issues Enabling user authentication against an LDAP server using authconfig --enableldapauth does not correctly set up the /etc/nslcd.conf configuration file. Consequently, LDAP users will be denied access to the system. To work around this issue, remove the line containing pam_password md5 from the /etc/nslcd.conf file. The System Security Services Daemon (SSSD) currently supports following LDAP referrals on anonymous-bind LDAP connections only. The authentication configuration utility does not keep the 'Require smart card for login' check box set when Kerberos is also enabled. When the check box is checked and the configuration is saved with the 'Apply' button, the system will correctly require smart card for login. However, on the subsequent run of the authentication configuration utility the check box will be unchecked again and it is necessary to check it again to keep the option switched on. When attempting to perform PKINIT pre-authentication, if the client has more than one possible candidate certificate the client may fail to select the certificate and key to use. This usually occurs if certificate selection is configured to use the value of the keyUsage extension, or if any of the candidate certificates does not contain a subjectAltName extension. Consequently, the client attempts to perform pre-authentication using a different (usually password-based) mechanism. After installing certmonger, the system message bus daemon needs to be signaled to reload its configuration to allow the certmonger service to start properly. To work around this issue, send the dbus-daemon process a SIGHUP signal, or, alternatively, reboot the system.

Commands:
Chapter 2. Installing the Enterprise Contract command line Prerequisites A working Red Hat Trusted Artifact Signer installation on Red Hat OpenShift Container Platform version 4.13 or higher. A workstation with the cosign and oc binary files installed. Access to the OpenShift web console. Procedure Download the ec binary file from the OpenShift cluster. Log in to the OpenShift web console. From the home page, click the ? icon, select Command line tools , go to the ec download section, then click the link for your platform. Open a terminal on your workstation, decompress the binary .gz file, then set the execute bit: Example Move and rename the binary to a location within your USDPATH environment: Example Verification Run the ec version command. The result should be the version of the Enterprise Contract CLI that you just installed.

Commands:
gunzip ec-amd64.gz chmod +x ec-amd64
sudo mv ec-amd64 /usr/local/bin/ec
24.4.6. Using the System Monitor Tool The File Systems tab of the System Monitor tool allows you to view file systems and disk space usage in the graphical user interface. To start the System Monitor tool, either select Applications System Tools System Monitor from the panel, or type gnome-system-monitor at a shell prompt. Then click the File Systems tab to view a list of file systems. Figure 24.4. System Monitor - File Systems For each listed file system, the System Monitor tool displays the source device ( Device ), target mount point ( Directory ), and file system type ( Type ), as well as its size ( Total ) and how much space is free ( Free ), available ( Available ), and used ( Used ).

Commands:
A.9. VDSM Hook Execution before_vm_start scripts can edit the domain XML in order to change VDSM's definition of a virtual machine before it reaches libvirt. Caution must be exercised in doing so. Hook scripts have the potential to disrupt the operation of VDSM, and buggy scripts can result in outages to the Red Hat Virtualization environment. In particular, ensure you never change the UUID of the domain, and do not attempt to remove a device from the domain without sufficient background knowledge. Both before_vdsm_start and after_vdsm_stop hook scripts are run as the root user. Other hook scripts that require root access to the system must be written to use the sudo command for privilege escalation. To support this the /etc/sudoers must be updated to allow the vdsm user to use sudo without reentering a password. This is required as hook scripts are executed non-interactively. Example A.4. Configuring sudo for VDSM Hooks In this example the sudo command will be configured to allow the vdsm user to run the /bin/chown command as root . Log into the virtualization host as root . Open the /etc/sudoers file in a text editor. Add this line to the file: vdsm ALL=(ALL) NOPASSWD: /bin/chown This specifies that the vdsm user has the ability to run the /bin/chown command as the root user. The NOPASSWD parameter indicates that the user will not be prompted to enter their password when calling sudo . Once this configuration change has been made VDSM hooks are able to use the sudo command to run /bin/chown as root . This Python code uses sudo to execute /bin/chown as root on the file /my_file . retcode = subprocess.call( ["/usr/bin/sudo", "/bin/chown", "root", "/my_file"] ) The standard error stream of hook scripts is collected in VDSM's log. This information is used to debug hook scripts.

Commands:
vdsm ALL=(ALL) NOPASSWD: /bin/chown
retcode = subprocess.call( ["/usr/bin/sudo", "/bin/chown", "root", "/my_file"] )
21.2. The z/VM Configuration File This applies only if installing under z/VM. Under z/VM, you can use a configuration file on a CMS-formatted disk. The purpose of the CMS configuration file is to save space in the parameter file by moving the parameters that configure the initial network setup, the DASD, and the FCP specification out of the parameter file (see Section 21.3, "Installation Network Parameters" ). Each line of the CMS configuration file contains a single variable and its associated value, in the following shell-style syntax: variable = value . You must also add the CMSDASD and CMSCONFFILE parameters to the parameter file. These parameters point the installation program to the configuration file: CMSDASD= cmsdasd_address Where cmsdasd_address is the device number of a CMS-formatted disk that contains the configuration file. This is usually the CMS user"s A disk. For example: CMSDASD=191 CMSCONFFILE= configuration_file Where configuration_file is the name of the configuration file. This value must be specified in lower case. It is specified in a Linux file name format: CMS_file_name . CMS_file_type . The CMS file REDHAT CONF is specified as redhat.conf . The CMS file name and the file type can each be from one to eight characters that follow the CMS conventions. For example: CMSCONFFILE=redhat.conf

Commands:
1.10. Red Hat Enterprise Linux-Specific Information This section describes information related to the philosophy of system administration that is specific to Red Hat Enterprise Linux. 1.10.1. Automation Automation of frequently-performed tasks under Red Hat Enterprise Linux requires knowledge of several different types of technologies. First are the commands that control the timing of command or script execution. The cron and at commands are most commonly used in these roles. Incorporating an easy-to-understand yet powerfully flexible time specification system, cron can schedule the execution of commands or scripts for recurring intervals ranging in length from minutes to months. The crontab command is used to manipulate the files controlling the cron daemon that actually schedules each cron job for execution. The at command (and the closely-related command batch ) are more appropriate for scheduling the execution of one-time scripts or commands. These commands implement a rudimentary batch subsystem consisting of multiple queues with varying scheduling priorities. The priorities are known as niceness levels (due to the name of the command -- nice ). Both at and batch are perfect for tasks that must start at a given time but are not time-critical in terms of finishing. are the various scripting languages. These are the "programming languages" that the average system administrator uses to automate manual operations. There are many scripting languages (and each system administrator tends to have a personal favorite), but the following are currently the most common: The bash command shell The perl scripting language The python scripting language Over and above the obvious differences between these languages, the biggest difference is in the way in which these languages interact with other utility programs on a Red Hat Enterprise Linux system. Scripts written with the bash shell tend to make more extensive use of the many small utility programs (for example, to perform character string manipulation), while perl scripts perform more of these types of operations using features built into the language itself. A script written using python can fully exploit the language's object-oriented capabilities, making complex scripts more easily extensible. This means that, in order to truly master shell scripting, you must be familiar with the many utility programs (such as grep and sed ) that are part of Red Hat Enterprise Linux. Learning perl (and python ), on the other hand, tends to be a more "self-contained" process. However, many perl language constructs are based on the syntax of various traditional UNIX utility programs, and as such are familiar to those Red Hat Enterprise Linux system administrators with shell scripting experience.

Commands: