Issue #21 July 2006

Tips & tricks

Red Hat's customer service and support teams receive technical support questions from users all over the world. Red Hat technicians add the questions and answers to Red Hat Knowledgebase on a daily basis. Access to Red Hat Knowledgebase is free. Every month, Red Hat Magazine offers a preview into the Red Hat Knowledgebase by highlighting some of the most recent entries.

Tips from RHCEs

Sharing a hot spare device in software RAID

Have you ever wondered if you could share a hot spare device between two software RAID arrays? You can share a hot spare device if you put mdadm in daemon mode and have it poll your RAID arrays.

Let's assume that you have two RAID 1 arrays with one hot spare configured in this manner:

/dev/md0 RAID1
--
/dev/sda1
/dev/sdb1

/dev/md1 RAID1
--
/dev/sdc1
/dev/sdd1
/dev/sde1 (Hot Spare)

This setup shows /dev/md0 with two devices, and /dev/md1 with three devices, with /dev/sde1 as a hot spare. In this scenario, you want to share /dev/sde1 with /dev/md0 if it should need it. To do that, you must configure the /etc/mdadm.conf file and define a spare-group name.

In /etc/mdadm.conf, start off by listing all of the devices:

echo "DEVICE /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1"

>> /etc/mdadm.conf

Scan the RAID arrays for the current details, and add it to the file:

mdadm -D -s >> /etc/mdadm.conf

/etc/mdadm.conf should now contain something like the following:

# Caution, the ARRAY and UUID should be on the same line.

DEVICE /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1
ARRAY /dev/md0 level=raid1 num-devices=2
UUID=29bc861f:6f1c72b0:162f7a88:1db03ffe
devices=/dev/sda1,/dev/sdb1
ARRAY /dev/md1 level=raid1 num-devices=2
UUID=aee2ae4c:ec7e4bab:51aefe40:9b54af78
devices=/dev/sdc1,/dev/sdd1,/dev/sde1

At this point, you need to create a spare-group entry for each array. The name does not matter, as long as it is the same for each array that you want to share the hot spare device(s).

Here, we choose "shared" as the name of the spare-group, and add an entry for each ARRAY in the /etc/mdadm.conf file:

# Caution, the ARRAY and UUID should be on the same line.

DEVICE /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1
ARRAY /dev/md0 level=raid1 num-devices=2
UUID=29bc861f:6f1c72b0:162f7a88:1db03ffe
devices=/dev/sda1,/dev/sdb1
spare-group=shared
ARRAY /dev/md1 level=raid1 num-devices=2
UUID=aee2ae4c:ec7e4bab:51aefe40:9b54af78
devices=/dev/sdc1,/dev/sdd1,/dev/sde1
spare-group=shared

Once the configuration file is ready, mdadm can run in daemon mode and poll the devices. If mdadm determines that a device has failed, it will look for an array in the same spare-group that contains all of the standard devices plus a hot spare device. If it finds any, it will move the hot spare to the array that needs it. In our case, if /dev/md0 were to lose a device, it would look at /dev/md1 and find the two devices of the array plus a hot spare, and it will move the hot spare device to /dev/md0 and begin the rebuild process.

Run mdadm in daemon mode and have it monitor and scan the arrays:

mdadm -F -s -m root@localhost -f

The default poll time is 60 seconds, but can be changed using the -d option (e.g., -d 300 would poll every five minutes).

Now test out this feature by failing and removing a device from /dev/md0:

mdadm /dev/md0 -f /dev/sda1 -r /dev/sda1

The next time that mdadm polls the devices, it should determine that /dev/md1 has a spare device, and it should move /dev/sde1 to /dev/md0 and rebuild the array. You can then add in /dev/sda1 and it will become your hot spare device:

mdadm /dev/md0 -a /dev/sda1

How do I enable HTTP V1.1 pipelining under Mozilla Firefox?

The technique used here enables the HTTP V1.1 Pipelining ability which is disabled by default. Since most web servers can now handle V1.1 connections and it is a negotiated ability, it should not cause any problems. Note that this does not change the maximum number of parallel connections (which is a de-facto standard of 4) it merely enables the ability to preserve those connections and make multiple requests using them rather than the setup/fetch/destroy for each item.

  1. Type "about:config" into the address bar and hit return. Scroll down and look for the following entries:
    • network.http.pipelining
    • network.http.proxy.pipelining
    • network.http.pipelining.maxrequests
  2. Alter the entries as follows:
    • Set "network.http.pipelining" to "true"
    • Set "network.http.proxy.pipelining" to "true"
    • Set "network.http.pipelining.maxrequests" to some number like 30. This means it will make 30 requests at once.
  3. Lastly right-click anywhere and select New-> Integer. Name it "nglayout.initialpaint.delay" and set its value to "0". This value is the amount of time the browser waits before it acts on information it recieves.

How do I set up arp control for LVS?

Under Red Hat® Enterprise Linux® 4, arp responses on the various interfaces can be controlled via /etc/sysctl.conf parameters which can be take the following values

arp_ignore - INTEGER
        Define different modes for sending replies in response to
        received ARP requests that resolve local target IP addresses:
        0 - (default): reply for any local target IP address, configured on any interface
        1 - reply only if the target IP address is local address
        configured on the incoming interface
        2 - reply only if the target IP address is local address
        configured on the incoming interface and both with the
        sender's IP address are part from same subnet on this interface
        3 - do not reply for local addresses configured with scope host, only resolutions 
         for global and link addresses are replied
        4-7 - reserved
        8 - do not reply for all local addresses

        The max value from conf/{all,interface}/arp_ignore is used
        when ARP request is received on the {interface} 



arp_announce - INTEGER
        Define different restriction levels for announcing the local
        source IP address from IP packets in ARP requests sent on
        interface:
        0 - (default) Use any local address, configured on any interface
        1 - Try to avoid local addresses that are not in the target's
        subnet for this interface. This mode is useful when target
        hosts reachable via this interface require the source IP
        address in ARP requests to be part of their logical network
        configured on the receiving interface. When we generate the
        request we will check all our subnets that include the
        target IP and will preserve the source address if it is from
        such subnet. If there is no such subnet we select source
        address according to the rules for level 2.
        2 - Always use the best local address for this target.
        In this mode we ignore the source address in the IP packet
        and try to select local address that we prefer for talks with
        the target host. Such local address is selected by looking
        for primary IP addresses on all our subnets on the outgoing
        interface that include the target IP address. If no suitable
        local address is found we select the first local address
        we have on the outgoing interface or on all other interfaces,
        with the hope we will receive reply for our request and
        even sometimes no matter the source IP address we announce.

        The max value from conf/{all,interface}/arp_announce is used.

        Increasing the restriction level gives more chance for
        receiving answer from the resolved target while decreasing
        the level announces more valid sender's information.

A typical LVS setup may look like,

net.ipv4.conf.lo.arp_ignore = 1
net.ipv4.conf.lo.arp_announce = 2

How do I recover a bzip2 file?

In order to recover a bzip2 file, follow these steps:

  1. Test the integrity of the bzip2 file by typing the following command:
    bzip2 -t [filename]
    
  2. If the input is corrupted, run the command:
    
     bzip2recover [filename]
    
  3. Lastly, run:
    bzip2 -dc rec*file.bz2 > [recovered_data]
    

How do I add a login banner in gdm for Red Hat Enterprise Linux 3?

Release Found: Red Hat Enterprise Linux 3

Limitation: This article is applicable only to the Gnome desktop.

Solution:

There are times when companies or government agencies need to have a logon banner. To make a welcome banner pop up in runlevel 5 (graphical mode), use the following steps:

  1. Make a backup of the /etc/X11/gdm/PreSession/Default file:
    cp /etc/X11/gdm/PreSession/Default /etc/X11/gdm/PreSession/Default.orig
    
  2. Edit the file using a text editor:
    vi /etc/X11/gdm/PreSession/Default
    
  3. Add the commands given below after the PATH directive:
    # Login banner
    /usr/bin/gdialog --yesno "Standard Disclaimer Text"  
    if ( test 1 -eq $? );then
    # To avoid staring at a blank screen for next 10 second,
    # and to miss the date with xsession-error dialog
    gdialog --infobox "Loggin Out in 10secs" 1 20 &
    sleep 10
    exit 1
    fi
    
  4. To test, log out and log back in. The banner should appear upon logging in.

For further information on gdialog, please refer to the man pages:

man gdialog

What are the basics to configure Red Hat Enterprise Linux as a router to perform Network Address Translation (NAT) using iptables?

Limitation:
This is applicable for Red Hat Enterprise Linux 3 and above.

There are a few ways to set up a Linux machine to route. Here is a relatively straight forward and common method. This method requires that the system use iptables for Network Address Translation (NAT).

To enable packet forwarding:

  echo "1" > /proc/sys/net/ipv4/ip_forward

To make this permanent, set the variable net.ipv4.ip_forward = 1 in the /etc/sysctl.conf file. For example:

 
  # Controls IP packet forwarding
    net.ipv4.ip_forward = 1

Next, have iptables handle Network Address Translation:

  /sbin/iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

where eth0 is "outside" or in public connection. Iptables ruleset should be tuned to be more restrictive. Do not forget to save iptables settings with:

service iptables save

See additional articles in the Knowledgebase for additional iptables configuration and tips.

To view the routing table use:

  netstat -rn

To view iptables ruleset use:

  iptables -L

Is the 64-bit x86-64 GDB rpm able to generate a successful 32-bit core file using gcore in Red Hat Enterprise Linux 4 Update 3?

No. The 64-bit x86-64 GDB rpm provided in the distribution (Red Hat Enterprise Linux 4 Update 3) is not currently capable of creating successful core files for 32-bit applications when using GDB's gcore command. It's capable, however, of reading 32-bit core files.

Note: Considerations are in place to address this limitation in a future Red Hat Enterprise Linux 4 update.

How do I change the default idle timeout for autofs?

The default timeout for autofs is 300 seconds (5 minutes). After five minutes of inactivity, a filesystem that is mounted will be automatically unmounted. This is a typical safe value. If it needs to be changed, then a different value can be given in the /etc/auto.master. This value is given in seconds.

For example, the following line indicates the directory is not to be unmounted until 1 minute of inactivity has passed:

/misc  /etc/auto.misc --timeout=60

Setting the option --timeout to 0 disables unmounting completely.

Warning: In some situations, disabling unmounting may have adverse side effects. Consider the server's memory and network resources when setting this option.

How do I fix the GNOME panel if it stops showing the window selection after minimizing applications in Red Hat Enterprise Linux 4?

Release Found: Red Hat Enterprise Linux 4

Symptom:
After the system completely boots and a user is logged in, the system displays the message:

The "Windows List" applets appears to have died unexpectedly.

Do you want to reload this applet?

If you choose not to reload it at this time you can always add it by
right clicking on the panel and clicking the "Add to Panel" submenu.

No Yes

Clicking "Yes" reloads the applet and the panel performs normally. Clicking "No" breaks the functionality of the panel and when applications are minimized, the windows selector disappears from the desktop and panel.

Solution:
If the panel has been removed from the desktop, right-click on the existing (main) panel and select "New Panel." A blank panel should now appear. In the new panel, right-click and select "Add to Panel..."

The Add to the Panel selector appears. Choose the "Window Selector, Switch between open windows" option. Click the Add button. This should correct the stated problem.

Tip: To prevent this from occurring on future logins, try removing the file .gnome2/session from the users home directory. This file should be replaced the next time GNOME starts. However, it is recommended that the file is backed up before removing it.

cp .gnome2/session .gnome2/session.bak
rm .gnome2/session

Feedback on the tip is welcome. The problem is intermittent and the solution has worked on several test systems.

The information provided in this article is for your information only. The origin of this information may be internal or external to Red Hat. While Red Hat attempts to verify the validity of this information before it is posted, Red Hat makes no express or implied claims to its validity.

This article is protected by the Open Publication License, V1.0 or later. Copyright © 2006 by Red Hat, Inc.