Issue #15 January 2006

Tips & tricks

Red Hat's customer service team receives technical support questions from users all over the world. As they are received, Red Hat technicians add the questions and answers to the Red Hat Knowledgebase on a daily basis. Individuals with a redhat.com login are granted access. Every month, Red Hat Magazine offers a preview into the Red Hat Knowledgebase by highlighting some of the most recent entries.

Tips from RHCEs

Using chattr to Eliminate Command Line Histories

Red Hat uses Bash as its default shell. One of the features of Bash is its ability to keep a running history of commands the user has typed. This could, however, end up being a security problem. If a bad guy were able to compromise a user's home directory, they could view commands the user has executed. In some cases, this could expose improperly used passwords or special privileges available to the user (such as sudo.)

In an environment where security is more important than convenience, you may consider disabling this function. A simple solution would be to use the chattr command to lock out the ability to update the file. As root, access the user's home directory. Type:

rm .bash_history
touch .bash_history
chattr +i .bash_history

The user will still have a command line history, but it will only apply to the current session. When the user logs out, the information will not be saved to the drive. To have this apply to all future users, make the changes in the /etc/skel directory.

How do I disable user access to console programs?

Warning: Backup each file and/or directory before deleting just in case there is a need to revert to the previous configuration.

To disable access by users to console programs, run the following command as root:

rm -f /etc/security/console.apps/*

In environments where the console is otherwise secured (BIOS and boot loader passwords are set, [Ctrl]-[Alt]-[Delete] is disabled, the power and reset switches are disabled, and so forth), it is advisable not to allow any user at the console to run poweroff, halt, and reboot, which are accessible from the console by default.

To remove these abilities, run the following commands as root:

rm -f /etc/security/console.apps/poweroff
rm -f /etc/security/console.apps/halt
rm -f /etc/security/console.apps/reboot

Why does an IBM pSeries, using the pcnet32 driver on the built-in network interface, sometimes hang or the network services fail to respond on Red Hat Enterprise Linux 4?

Release Found: Red Hat Enterprise Linux 4

Symptom:
When under heavy load, an IBM pSeries installed with Red Hat Enterprise Linux 4 will appear to hang and the network fail to respond to incoming traffic. The built-in network interface uses the pcnet32 driver. The command ethtool -S eth0 reports large numbers of rx_dropped, rx_over_errors, and rx_fifo_errors in the network interface statistics.

Solution:
Both Red Hat and IBM are working on finding the cause and resolving this issue in a future update. In the meantime, this workaround can be implemented:

Testing has shown that increasing the receive and transmit ring size to the maximum value of 256 avoids this problem. To increase the ring sizes, edit the file /etc/sysconfig/network-scripts/ifcfg-[ifname] and add the line:

ETHTOOL_OPTS="-G rx 256 tx 256"

Repeat this for each of the pcnet32-based network devices and execute the command /sbin/service network restart or restart the system.

Why does my system with more than 8 processors hang during boot under 32-bit Red Hat Enterprise Linux 4, Update 1 or 2?

The 32-bit version of Red Hat Enterprise Linux 4 supports up to 32 processors, but systems with more than eight processors need a specific boot parameter or they will hang at boot. Using the option apic=bigsmp at the boot: prompt during install will correct the problem:

boot: linux apic=bigsmp <any additional boot parameters>

This will allow the install to complete but it won't permanently add the option to the kernel boot line. Follow the procedure outlined in the CPU upgrade section below to make the addition permanent.

If a system is upgraded to more than eight processors but had fewer than eight when originally installed, it will also hang during boot. To add the necessary apic=bigsmp boot parameter, follow these steps:

  1. Press a key, if prompted, to enter the GRUB menu during the boot sequence
  2. Press a key, if prompted, to stop the automatic boot countdown
  3. Highlight the kernel to boot from and press the 'e' key
  4. Find the line that starts with 'kernel' and press the 'e' key again
  5. Move to the end of the line and add the option apic=bigsmp
  6. Press enter to save changes
  7. Press the 'b' key to boot with the new boot parameter

Once the system has booted, edit the /etc/grub.conf file and add apic=bigsmp to the end of each kernel line. The option will now be used every time the system boots.

How do I install Red Hat Enterprise Linux 4 Update 2 on a Stratus ftServer system?

The 32-bit version of Red Hat Enterprise Linux 4 supports up to 32 processors, but systems with more than eight processors need a specific boot parameter or they will hang at boot. Using the option apic=bigsmp at the boot: prompt during install will correct the problem:

boot: linux apic=bigsmp <any additional boot parameters>

This will allow the install to complete but it won't permanently add the option to the kernel boot line. Follow the procedure outlined in the CPU upgrade section below to make the addition permanent.

If a system is upgraded to more than eight processors but had fewer than eight when originally installed, it will also hang during boot. To add the necessary apic=bigsmp boot parameter, follow these steps:

  1. Press a key, if prompted, to enter the GRUB menu during the boot sequence
  2. Press a key, if prompted, to stop the automatic boot countdown
  3. Highlight the kernel to boot from and press the 'e' key
  4. Find the line that starts with 'kernel' and press the 'e' key again
  5. Move to the end of the line and add the option apic=bigsmp
  6. Press enter to save changes
  7. Press the 'b' key to boot with the new boot parameter

Once the system has booted, edit the /etc/grub.conf file and add apic=bigsmp to the end of each kernel line. The option will now be used every time the system boots.

How can I make my NFS client mount a share automatically at the next reboot?

To make these mount points permanent changes perm, edit /etc/fstab and modify the following line to match your configuration.

remoteserver:/export            /mnt/remoteserver                 nfs   defaults        0 0

At the next boot the the export from the remote server should be mounted automatically.

Replace the word "default" with any advanced NFS mounting options that may be necessary when mounting the remote server.

How do I specify which version of the NFS protocol to use when mounting ?

You can specify the version of NFS to use at the command line when mounting with the option vers=n Where n is 2,3 or 4.

For example, to mount the NFS shared directory /test from server.example.com using NFS version 3 you should use the command:

mount -t nfs -o vers=3 server.example.com:/test /mnt/server1

Not all versions of Red Hat Enterprise Linux support mounting all versions of NFS. See the related FAQ articles for more details.

How do I re-enable a failed service in Cluster Suite?

If a Red Hat Cluster Suite service goes out of hand or dies unexpectedly (e.g. killed outside of Cluster Suite using "kill "), there are times when the service could no longer be restarted and would be marked as failed. When this happens, the service could no longer be re-enabled with clusvcadm -e <service>.

There are several ways to recover from this. In Red Hat Enterprise Linux 3, perform the following procedure:

  1. Stop clumanager on all nodes with service clumanager stop.
  2. Re-initialize the quorum with shutil -i.
  3. Start clumanager on all nodes with service clumanager start.

In Red Hat Enterprise Linux 4, the procedure is slightly different:

  1. Stop rgmanager on all nodes with service rgmanager stop.
  2. Start clumanager on all nodes with service rgmanager start.
  3. Disable the service using clusvcadm -d <service>. The logs would show some error messages stating that disabling the service has failed. Ignore this.
  4. Enable the service using clusvcadm -e <service>.

The disadvantage of both procedures outlined above is that the entire cluster is effectively halted and restarted. If multiple services are running, that could mean stopping all of them for the sake of one service that failed.

The third procedure is a workaround when everything else fails. In this procedure, the service script is used to trick Cluster Suite into thinking that it still has control of the service. For example, if the cluster is running the HTTP service called web using the script /etc/init.d/httpd and that service has failed. The procedure is as follows:

  1. Start httpd again by executing /etc/init.d/httpd start.
  2. Disable the service using clusvcadm -d web.
  3. Enable the service using clusvcadm -e web.

This procedure is desirable since it only affects the failed service without stopping the entire cluster. Note however that this procedure is not guaranteed to work on all Cluster systems. It is a workaround.

Why does df show bigger disk usage than du?

There are some instances where df would output a bigger disk usage than du. The most common instance is when a process has opened a huge file and that same file is deleted with rm. Technically, the file still exists because a process still has an open file descriptor associated with that file. An example is presented below.

First, a 200Mb file called bigfile is created and is opened using the vi editor:

[root@localhost ~]# ls -lh bigfile
-rw-r--r--  1 root root 200M Dec 22 14:53 bigfile
[root@localhost ~]# lsof|grep bigfile
vi        23824    root    3r      REG        3,2 209715200    2052534 /root/bigfile
vi        23824    root    4u      REG        3,2      4096    2052542 /root/.bigfile.swp

At this point, both df and du would have the same output:

[root@localhost ~]# df -h /
Filesystem            Size  Used Avail Use% Mounted on
/dev/hda2              19G  8.8G  8.4G  51% /
[root@localhost ~]# du -sh /
8.8G	/

Now the discrepancy in output shows once bigfile is deleted:

[root@localhost ~]# rm -f bigfile
[root@localhost ~]# df -h /
Filesystem            Size  Used Avail Use% Mounted on
/dev/hda2              19G  8.8G  8.4G  51% /
[root@localhost ~]# du -sh /
8.6G	/

Killing the vi process that has opened bigfile resolves the discrepancy:

[root@localhost ~]# kill 23824
[root@localhost ~]# df -h /
Filesystem            Size  Used Avail Use% Mounted on
/dev/hda2              19G  8.6G  8.6G  50% /
[root@localhost ~]# du -sh
8.6G	/

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 © 2004 by Red Hat, Inc.