mtpti5iD/redhat-docs_dataset huggingface dataset:
3.11. Enhanced Graphics Power Management Red Hat Enterprise Linux 7 saves power on graphics and display devices by eliminating several sources of unnecessary consumption. LVDS reclocking Low-voltage differential signaling (LVDS) is an system for carrying electronic signals over copper wire. One significant application of the system is to transmit pixel information to liquid crystal display (LCD) screens in notebook computers. All displays have a refresh rate - the rate at which they receive fresh data from a graphics controller and redraw the image on the screen. Typically, the screen receives fresh data sixty times per second (a frequency of 60 Hz). When a screen and graphics controller are linked by LVDS, the LVDS system uses power on every refresh cycle. When idle, the refresh rate of many LCD screens can be dropped to 30 Hz without any noticeable effect (unlike cathode ray tube (CRT) monitors, where a decrease in refresh rate produces a characteristic flicker). The driver for Intel graphics adapters built into the kernel used in Red Hat Enterprise Linux 7 performs this downclocking automatically, and saves around 0.5 W when the screen is idle. Enabling memory self-refresh Synchronous dynamic random access memory (SDRAM) - as used for video memory in graphics adapters - is recharged thousands of times per second so that individual memory cells retain the data that is stored in them. Apart from its main function of managing data as it flows in and out of memory, the memory controller is normally responsible for initiating these refresh cycles. However, SDRAM also has a low-power self-refresh mode. In this mode, the memory uses an internal timer to generate its own refresh cycles, which allows the system to shut down the memory controller without endangering data currently held in memory. The kernel used in Red Hat Enterprise Linux 7 can trigger memory self-refresh in Intel graphics adapters when they are idle, which saves around 0.8 W. GPU clock reduction Typical graphical processing units (GPUs) contain internal clocks that govern various parts of their internal circuitry. The kernel used in Red Hat Enterprise Linux 7 can reduce the frequency of some of the internal clocks in Intel and ATI GPUs. Reducing the number of cycles that GPU components perform in a given time saves the power that they would have consumed in the cycles that they did not have to perform. The kernel automatically reduces the speed of these clocks when the GPU is idle, and increases it when GPU activity increases. Reducing GPU clock cycles can save up to 5 W. GPU powerdown The Intel and ATI graphics drivers in Red Hat Enterprise Linux 7 can detect when no monitor is attached to an adapter and therefore shut down the GPU completely. This feature is especially significant for servers which do not have monitors attached to them regularly.

Commands:
2.3. Documentation for Linux Gurus If you are concerned with the finer points and specifics of the Red Hat Enterprise Linux system, the Reference Guide is a great resource. If you are a long-time Red Hat Enterprise Linux user, you probably already know that one of the best ways to understand a particular program is to read its source code and/or configuration files. A major advantage of Red Hat Enterprise Linux is the availability of the source code for anyone to read. Obviously, not everyone is a programmer, so the source code may not be helpful for you. However, if you have the knowledge and skills necessary to read it, the source code holds all of the answers.

Commands:
10.7. Converting Masters and Clones Only one single active CA generating CRLs can exist within the same topology. Similarly, only one OCSP receiving CRLs can exist within the same topology. As such, there can be any number of clones, but there can only be a single configured master for CA and OCSP. For KRAs and TKSs, there is no configuration difference between masters and clones, but CAs and OCSPs do have some configuration differences. This means that when a master is taken offline - because of a failure or for maintenance or to change the function of the subsystem in the PKI - then the existing master must be reconfigured to be a clone, and one of the clones promoted to be the master. 10.7.1. Converting CA Clones and Masters Stop the master CA if it is still running. Open the existing master CA configuration directory: Edit the CS.cfg file for the master, and change the CRL and maintenance thread settings so that it is set as a clone: Disable control of the database maintenance thread: Disable monitoring database replication changes: Disable maintenance of the CRL cache: Disable CRL generation: Set the CA to redirect CRL requests to the new master: Stop the cloned CA server. Open the cloned CA's configuration directory. Edit the CS.cfg file to configure the clone as the new master. Delete each line which begins with the ca.crl. prefix. Copy each line beginning with the ca.crl. prefix from the former master CA CS.cfg file into the cloned CA's CS.cfg file. Enable control of the database maintenance thread; the default value for a master CA is 600 . Enable monitoring database replication: Enable maintenance of the CRL cache: Enable CRL generation: Disable the redirect settings for CRL generation requests: Start the new master CA server. 10.7.2. Converting OCSP Clones Stop the OCSP master, if it is still running. Open the existing master OCSP configuration directory. Edit the CS.cfg , and reset the OCSP.Responder.store.defStore.refreshInSec parameter to 21600 : Stop the online cloned OCSP server. Open the cloned OCSP responder's configuration directory. Open the CS.cfg file, and delete the OCSP.Responder.store.defStore.refreshInSec parameter or change its value to any non-zero number: Start the new master OCSP responder server.

Commands:
cd /var/lib/pki/ instance_name /ca/conf
ca.certStatusUpdateInterval=0
ca.listenToCloneModifications=false
ca.crl. IssuingPointId .enableCRLCache=false
ca.crl. IssuingPointId .enableCRLUpdates=false
master.ca.agent.host= new_master_hostname master.ca.agent.port= new_master_port
pki-server stop instance_name
cd /etc/ instance_name
ca.certStatusUpdateInterval=600
ca.listenToCloneModifications=true
ca.crl. IssuingPointId .enableCRLCache=true
ca.crl. IssuingPointId .enableCRLUpdates=true
master.ca.agent.host= hostname master.ca.agent.port= port number
pki-server start instance_name
cd /etc/ instance_name
OCSP.Responder.store.defStore.refreshInSec=21600
pki-server stop instance_name
cd /etc/ instance_name
OCSP.Responder.store.defStore.refreshInSec=15000
pki-server start instance_name
3.5.2. Attaching Users to Groups If you want to add an existing user to the named group, you can make use of the gpasswd command. To remove a user from the named group, run: To set the list of group members, write the user names after the --members option dividing them with commas and no spaces:

Commands:
gpasswd -a username which_group_to_edit
gpasswd -d username which_group_to_edit
gpasswd --members username_1 , username_2 which_group_to_edit
Appendix A. Further Information A.1. SELinux and sVirt Further information on SELinux and sVirt: Main SELinux website: http://www.nsa.gov/research/selinux/index.shtml . SELinux documentation: http://www.nsa.gov/research/selinux/docs.shtml . Main sVirt website: http://selinuxproject.org/page/SVirt . Dan Walsh's blog: http://danwalsh.livejournal.com/ . The unofficial SELinux FAQ: http://www.crypt.gen.nz/selinux/faq.html .

Commands:
2.2.3.3. Edit the /var/yp/securenets File If the /var/yp/securenets file is blank or does not exist (as is the case after a default installation), NIS listens to all networks. One of the first things to do is to put netmask/network pairs in the file so that ypserv only responds to requests from the appropriate network. Below is a sample entry from a /var/yp/securenets file: Warning Never start a NIS server for the first time without creating the /var/yp/securenets file. This technique does not provide protection from an IP spoofing attack, but it does at least place limits on what networks the NIS server services.

Commands:
255.255.255.0 192.168.0.0
18.12.2. Filtering Chains Filtering rules are organized in filter chains. These chains can be thought of as having a tree structure with packet filtering rules as entries in individual chains (branches). Packets start their filter evaluation in the root chain and can then continue their evaluation in other chains, return from those chains back into the root chain or be dropped or accepted by a filtering rule in one of the traversed chains. Libvirt's network filtering system automatically creates individual root chains for every virtual machine's network interface on which the user chooses to activate traffic filtering. The user may write filtering rules that are either directly instantiated in the root chain or may create protocol-specific filtering chains for efficient evaluation of protocol-specific rules. The following chains exist: root mac stp (spanning tree protocol) vlan arp and rarp ipv4 ipv6 Multiple chains evaluating the mac, stp, vlan, arp, rarp, ipv4, or ipv6 protocol can be created using the protocol name only as a prefix in the chain's name. Example 18.3. ARP traffic filtering This example allows chains with names arp-xyz or arp-test to be specified and have their ARP protocol packets evaluated in those chains. The following filter XML shows an example of filtering ARP traffic in the arp chain. The consequence of putting ARP-specific rules in the arp chain, rather than for example in the root chain, is that packets protocols other than ARP do not need to be evaluated by ARP protocol-specific rules. This improves the efficiency of the traffic filtering. However, one must then pay attention to only putting filtering rules for the given protocol into the chain since other rules will not be evaluated. For example, an IPv4 rule will not be evaluated in the ARP chain since IPv4 protocol packets will not traverse the ARP chain.

Commands:
<filter name='no-arp-spoofing' chain='arp' priority='-500'> <uuid>f88f1932-debf-4aa1-9fbe-f10d3aa4bc95</uuid> <rule action='drop' direction='out' priority='300'> <mac match='no' srcmacaddr='USDMAC'/> </rule> <rule action='drop' direction='out' priority='350'> <arp match='no' arpsrcmacaddr='USDMAC'/> </rule> <rule action='drop' direction='out' priority='400'> <arp match='no' arpsrcipaddr='USDIP'/> </rule> <rule action='drop' direction='in' priority='450'> <arp opcode='Reply'/> <arp match='no' arpdstmacaddr='USDMAC'/> </rule> <rule action='drop' direction='in' priority='500'> <arp match='no' arpdstipaddr='USDIP'/> </rule> <rule action='accept' direction='inout' priority='600'> <arp opcode='Request'/> </rule> <rule action='accept' direction='inout' priority='650'> <arp opcode='Reply'/> </rule> <rule action='drop' direction='inout' priority='1000'/> </filter>
Chapter 23. Deploying Insights in Red Hat Virtualization Manager To deploy Red Hat Insights on an existing Red Hat Enterprise Linux (RHEL) system with Red Hat Virtualization Manager installed, complete these tasks: Register the system to the Red Hat Insights application. Enable data collection from the Red Hat Virtualization environment. Register the system to Red Hat Insights Register the system to communicate with the Red Hat Insights service and to view results displayed in the Red Hat Insights console. Enable data collection from the Red Hat Virtualization environment Modify the /etc/ovirt-engine/rhv-log-collector-analyzer/rhv-log-collector-analyzer.conf file to include the following line: View your Insights results in the Insights Console System and infrastructure results can be viewed in the Insights console . The Overview tab provides a dashboard view of current risks to your infrastructure. From this starting point, you can investigate how a specific rule is affecting your system, or take a system-based approach to view all the rule matches that pose a risk to the system. Select Rule hits by severity to view rules by the Total Risk they pose to your infrastructure ( Critical , Important , Moderate , or Low ). Or Select Rule hits by category to see the type of risk they pose to your infrastructure ( Availability , Stability , Performance , or Security ). Search for a specific rule by name, or scroll through the list of rules to see high-level information about risk, systems exposed, and availability of Ansible Playbook to automate remediation. Click on a rule to see a description of the rule, learn more from relevant knowledge base articles, and view a list of systems that are affected. Click on a system to see specific information about detected issues and steps to resolve the issue.

Commands:
insights-client --register
upload-json=True
4.7. Security Enhanced Communication Tools As the size and popularity of the Internet has grown, so has the threat of communication interception. Over the years, tools have been developed to encrypt communications as they are transferred over the network. Red Hat Enterprise Linux ships with two basic tools that use high-level, public-key-cryptography-based encryption algorithms to protect information as it travels over the network. OpenSSH - A free implementation of the SSH protocol for encrypting network communication. Gnu Privacy Guard (GPG) - A free implementation of the PGP (Pretty Good Privacy) encryption application for encrypting data. OpenSSH is a safer way to access a remote machine and replaces older, unencrypted services like telnet and rsh . OpenSSH includes a network service called sshd and three command line client applications: ssh - A secure remote console access client. scp - A secure remote copy command. sftp - A secure pseudo-ftp client that allows interactive file transfer sessions. It is highly recommended that any remote communication with Linux systems occur using the SSH protocol. For more information about OpenSSH, refer to the chapter titled OpenSSH in the System Administrators Guide . For more information about the SSH Protocol, refer to the chapter titled SSH Protocol in the Reference Guide . Important Although the sshd service is inherently secure, the service must be kept up-to-date to prevent security threats. Refer to Chapter 3, Security Updates for more information about this issue. GPG is one way to ensure private email communication. It can be used both to email sensitive data over public networks and to protect sensitive data on hard drives.

Commands:
32.2. Configuring the kdump Service There are three common means of configuring the kdump service: at the first boot, using the Kernel Dump Configuration graphical utility, and doing so manually on the command line. Important A limitation in the current implementation of the Intel IOMMU driver can occasionally prevent the kdump service from capturing the core dump image. To use kdump on Intel architectures reliably, it is advised that the IOMMU support is disabled. Warning It is known that the kdump service does not work reliably on certain combinations of HP Smart Array devices and system boards from the same vendor. Consequent to this, users are strongly advised to test the configuration before using it in production environment, and if necessary, configure kdump to store the kernel crash dump to a remote machine over a network. For more information on how to test the kdump configuration, see Section 32.2.4, "Testing the Configuration" . 32.2.1. Configuring kdump at First Boot When the system boots for the first time, the firstboot application is launched to guide the user through the initial configuration of the freshly installed system. To configure kdump , navigate to the Kdump section and follow the instructions below. Select the Enable kdump? check box to allow the kdump daemon to start at boot time. This will enable the service for runlevels 2 , 3 , 4 , and 5 , and start it for the current session. Similarly, unselecting the check box will disable it for all runlevels and stop the service immediately. Click the up and down arrow buttons to the Kdump Memory field to increase or decrease the value to configure the amount of memory that is reserved for the kdump kernel. Notice that the Usable System Memory field changes accordingly showing you the remaining memory that will be available to the system. Important This section is available only if the system has enough memory. To learn about minimum memory requirements of the Red Hat Enterprise Linux 6 system, read the Required minimums section of the Red Hat Enterprise Linux Technology Capabilities and Limits comparison chart. When the kdump crash recovery is enabled, the minimum memory requirements increase by the amount of memory reserved for it. This value is determined by the user, and defaults to 128 MB plus 64 MB for each TB of physical memory (that is, a total of 192 MB for a system with 1 TB of physical memory). The memory can be attempted up to the maximum of 896 MB if required. This is recommended especially in large environments, for example in systems with a large number of Logical Unit Numbers (LUNs).

Commands:
B.39.2. RHSA-2010:0925 - Important: krb5 security and bug fix update Updated krb5 packages that fix multiple security issues and one bug are now available for Red Hat Enterprise Linux 6. The Red Hat Security Response Team has rated this update as having important security impact. Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) associated with each description below. Kerberos is a network authentication system which allows clients and servers to authenticate to each other using symmetric encryption and a trusted third party, the Key Distribution Center (KDC). CVE-2010-1323 , CVE-2010-1324 , CVE-2010-4020 Multiple checksum validation flaws were discovered in the MIT Kerberos implementation. A remote attacker could use these flaws to tamper with certain Kerberos protocol packets and, possibly, bypass authentication or authorization mechanisms and escalate their privileges. Red Hat would like to thank the MIT Kerberos Team for reporting these issues. Bug Fix BZ# 644825 When attempting to perform PKINIT pre-authentication, if the client had more than one possible candidate certificate the client could fail to select the certificate and key to use. This usually occurred if certificate selection was configured to use the value of the keyUsage extension, or if any of the candidate certificates did not contain a subjectAltName extension. Consequently, the client attempted to perform pre-authentication using a different (usually password-based) mechanism. All krb5 users should upgrade to these updated packages, which contain backported patches to correct these issues. After installing the updated packages, the krb5kdc daemon will be restarted automatically.

Commands:
Chapter 4. Portable build changes 4.1. Portable Linux builds of OpenJDK The portable Linux builds of OpenJDK are available with the FIPS mode. FIPS mode is also available on the RHEL OpenJDK builds. You must install NSS on the portable Linux builds if your system is running in FIPS mode. 4.2. Portable Windows builds of OpenJDK The portable Windows builds of OpenJDK are available with the FIPS mode. You do not need to install NSS on the portable Windows builds if your system is running in FIPS mode.

Commands:
4.8. Virtualization Performance monitoring in KVM guests, BZ# 645365 KVM can now virtualize a performance monitoring unit (vPMU) to allow virtual machines to use performance monitoring. Note that the -cpu flag must be set when using this feature. With this feature, Red Hat virtualization customers running Red Hat Enterprise Linux 6 guests can use the CPU's PMU counter while using the performance tool for profiling. The virtual performance monitoring unit feature allows virtual machine users to identify sources of performance problems in their guests, thereby improving the ability to profile a KVM guest from the host. This feature is a Technology Preview in Red Hat Enterprise Linux 6.4. Package: kernel-2.6.32-358 Dynamic virtual CPU allocation KVM now supports dynamic virtual CPU allocation, also called vCPU hot plug, to dynamically manage capacity and react to unexpected load increases on their platforms during off-peak hours. The virtual CPU hot-plugging feature gives system administrators the ability to dynamically adjust CPU resources in a guest. Because a guest no longer has to be taken offline to adjust the CPU resources, the availability of the guest is increased. This feature is a Technology Preview in Red Hat Enterprise Linux 6.4. Currently, only the vCPU hot-add functionality works. The vCPU hot-unplug feature is not yet implemented. Package: qemu-kvm-0.12.1.2-2.355 System monitoring via SNMP, BZ# 642556 This feature provides KVM support for stable technology that is already used in data center with bare metal systems. SNMP is the standard for monitoring and is extremely well understood as well as computationally efficient. System monitoring via SNMP in Red Hat Enterprise Linux 6 allows the KVM hosts to send SNMP traps on events so that hypervisor events can be communicated to the user via standard SNMP protocol. This feature is provided through the addition of a new package: libvirt-snmp . This feature is a Technology Preview. Package: libvirt-snmp-0.0.2-3 Wire speed requirement in KVM network drivers Virtualization and cloud products that run networking work loads need to run wire speeds. Up until Red Hat Enterprise Linux 6.1, the only way to reach wire speed on a 10 GB Ethernet NIC with a lower CPU utilization was to use PCI device assignment (passthrough), which limits other features like memory overcommit and guest migration The macvtap / vhost zero-copy capabilities allow the user to use those features when high performance is required. This feature improves performance for any Red Hat Enterprise Linux 6.x guest in the VEPA use case. This feature is introduced as a Technology Preview. Package: qemu-kvm-0.12.1.2-2.355

Commands:
2.3. Authentication Sessions The API also provides the ability for authentication session support. An API user sends an initial request with authentication details, then sends all subsequent requests using a session cookie to authenticate. The following procedure demonstrates how to use an authenticated session. Procedure 2.3. Requesting an authenticated session Send a request with the Authorization and Prefer: persistent-auth This returns a response with the following header: Note the JSESSIONID= value. In this example the value is JSESSIONID=5dQja5ubr4yvI2MM2z+LZxrK . Send all subsequent requests with the Prefer: persistent-auth and cookie header with the JSESSIONID= value. The Authorization is no longer needed when using an authenticated session. When the session is no longer required, perform a request to the sever without the Prefer: persistent-auth header.

Commands:
HEAD [base] HTTP/1.1 Host: [host] Authorization: Basic cmhldm1hZG1pbkBibGFjay5xdW1yYW5ldC5jb206MTIzNDU2 Prefer: persistent-auth HTTP/1.1 200 OK
Set-Cookie: JSESSIONID=5dQja5ubr4yvI2MM2z+LZxrK; Path=/ovirt-engine/api; Secure
HEAD [base] HTTP/1.1 Host: [host] Prefer: persistent-auth cookie: JSESSIONID=5dQja5ubr4yvI2MM2z+LZxrK HTTP/1.1 200 OK
HEAD [base] HTTP/1.1 Host: [host] Authorization: Basic cmhldm1hZG1pbkBibGFjay5xdW1yYW5ldC5jb206MTIzNDU2 HTTP/1.1 200 OK