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.

How can I configure a system as an NFS server which sits behind a firewall with NFS clients outside of the firewall?

by Bradford Hinson

Symptom:
NFS relies on portmap to assign the ports on which it will listen. One side effect of this is that the ports are randomly assigned, so each time NFS is restarted the ports will change. This can make it difficult to run an NFS server behind a firewall which only allows access to specific ports on the system.

Solution:
The first step is to assign a permanent port number to each of the NFS services (rquotad, mountd, statd, and lockd). While they can use any unused ports greater than 1024, it is recommended that you first consult the file /etc/services to find a valid unused port range. The following examples use the range 10000-10005.

The majority of the ports are configured through the file /etc/sysconfig/nfs. You will need to create this file if it does not exist. It should look similar to the following example:

# NFS port numbers
STATD_PORT=10002
STATD_OUTGOING_PORT=10003
MOUNTD_PORT=10004
RQUOTAD_PORT=10005

The lockd service is configured differently from the others because it is compiled as a kernel module. To set the port which lockd uses, add a line similar to the following to the end of /etc/modprobe.conf:

options lockd nlm_tcpport=10000 nlm_udpport=10001

In order for the changes to take effect, the module must be reloaded if it is already in use. You can use the commands rmmod and modprobe to reload the lockd module; however if there are module dependencies currently in use, a system restart may be required.

After these configuration changes, you can view the port assignments with the rpcinfo -p <hostname> command:

   program vers proto   port
    100000    2   tcp    111  portmapper
    100000    2   udp    111  portmapper
    100021    1   udp  10001  nlockmgr
    100021    3   udp  10001  nlockmgr
    100021    4   udp  10001  nlockmgr
    100021    1   tcp  10000  nlockmgr
    100021    3   tcp  10000  nlockmgr
    100021    4   tcp  10000  nlockmgr
    100024    1   udp  10002  status
    100024    1   tcp  10002  status
    100011    1   udp  10005  rquotad
    100011    2   udp  10005  rquotad
    100011    1   tcp  10005  rquotad
    100011    2   tcp  10005  rquotad
    100003    2   udp   2049  nfs
    100003    3   udp   2049  nfs
    100003    4   udp   2049  nfs
    100003    2   tcp   2049  nfs
    100003    3   tcp   2049  nfs
    100003    4   tcp   2049  nfs
    100005    1   udp  10004  mountd
    100005    1   tcp  10004  mountd
    100005    2   udp  10004  mountd
    100005    2   tcp  10004  mountd
    100005    3   udp  10004  mountd
    100005    3   tcp  10004  mountd

At this point, the ports will remain the same when NFS is restarted. The following is a list of ports which need to be opened on the firewall:

• 111: portmap (tcp/udp)
• 2049: nfs (tcp/udp)
• 10000: example lockd (tcp)
• 10001: example lockd (udp)
• 10002: example statd/status (tcp/udp)
• 10003: example statd/status outgoing (tcp/udp)
• 10004: example mountd (tcp/udp)
• 10005: example rquotad (tcp/udp)

You can now open these ports on the firewall to allow remote clients to mount a share on the server. If you are using iptables, the following commands can be used to add inbound/outbound rules to allow access to these ports. Note that this is only an example, as your specific firewall rules may differ:

iptables -A INPUT -p tcp -m tcp --dport 111 -j ACCEPT
iptables -A INPUT -p udp -m udp --dport 111 -j ACCEPT
iptables -A INPUT -p tcp -m tcp --dport 2049 -j ACCEPT
iptables -A INPUT -p udp -m udp --dport 2049 -j ACCEPT
iptables -A INPUT -p tcp -m tcp --dport 10000 -j ACCEPT
iptables -A INPUT -p udp -m udp --dport 10001 -j ACCEPT
iptables -A INPUT -p tcp -m tcp --dport 10002:10005 -j ACCEPT
iptables -A INPUT -p udp -m udp --dport 10002:10005 -j ACCEPT
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -j REJECT --reject-with icmp-port-unreachable
iptables -A OUTPUT -p tcp -m tcp --dport 111 -j ACCEPT
iptables -A OUTPUT -p udp -m udp --dport 111 -j ACCEPT
iptables -A OUTPUT -p tcp -m tcp --dport 2049 -j ACCEPT
iptables -A OUTPUT -p udp -m udp --dport 2049 -j ACCEPT
iptables -A OUTPUT -p tcp -m tcp --dport 10000 -j ACCEPT
iptables -A OUTPUT -p udp -m udp --dport 10001 -j ACCEPT
iptables -A OUTPUT -p tcp -m tcp --dport 10002:10005 -j ACCEPT
iptables -A OUTPUT -p udp -m udp --dport 10002:10005 -j ACCEPT
iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -j REJECT --reject-with icmp-port-unreachable

How do I disable the Synaptics Touchpad while I am typing at the keyboard?

by Michael Kearey

The Synaptics package includes a program called syndaemon. It disables the touchpad while the keyboard is being used. The touchpad will be re-enabled after keyboard use has stopped after a short delay.

To start the daemon open a shell prompt, and issue the following command:

syndaemon -d

This starts the program in daemon mode. The daemon will run in the background until the syndaemon process is killed or until the system is shutdown.

More information about the syndaemon program may be found in the syndaemon manual page:

man syndaemon

How do I find out what RPM packages are installed on the system and when they were installed?

by Michael Napolis

There are several different ways to find what packages are installed on the system:

• One way is to check the /root/install.log file. However, the file only lists RPM packages that were installed during the initial installation of the Red Hat Enterprise Linux system.

• To find out what packages are currently installed on the system, there are two ways:

  • Use the graphical tool redhat-logviewer (for Red Hat Enterprise Linux 3) or system-logviewer (for Red Hat Enterprise Linux 4). There is an RPM Packages section in the tool that is updated daily by an automated cron job.

  • Another way is to utilize the rpm command. Use the following command to list the installed RPMs: rpm -qa | less

Both options, however, do not display when the RPM packages were installed. To find out when they were installed, the --last argument is needed in the rpm command above. Use the command below:

rpm -qa --last | grep less

The --last option orders the package listing by install time such that the latest packages are at the top.

How do I use chkconfig to enable a script for a service that accepts start, stop, and status options?

by Demosthenes Mateo

Not all scripts with start/stop/status options are manageable by chkconfig. The script must adhere to the following requirements:

1. The first line indicates what shell is used to run the script
2. The second line is just a blank comment.
3. The third line should be a comment that indicates which runlevels should the service be started by default as well as the start and stop priority levels.
4. The fourth line should be a comment that contains the description for the service. The description may extend up to several (commented) lines as necessary. Use the backslash character (\) if the comment extends to several lines.

Below is an example for the Samba script /etc/init.d/smb:

#!/bin/sh
#
# chkconfig: - 91 35
# description: Starts and stops the Samba smbd and nmbd daemons \
#              used to provide SMB network services.

The start/stop priority levels (91 and 35, respectively, shown above) are important for services that depend on other services. For example, it is required that portmap is started before nfs. If the script does not depend on other services, you may choose to execute it after the system is completely up and running. The easiest way is to call it from /etc/rc.d/rc.local. The command to do that is

echo /etc/init.d/yourscript >> /etc/rc.d/rc.local

Make sure that the script is executable. Issue the command:

chmod 0755 /etc/init.d/yourscript

How do I disable the zeroconf route so that the system will boot without the 169.254.0.0 / 255.255.0.0 route?

by Cynthia Davis

Symptom:

Every time the system boots, the zeroconf route (169.254.0.0) is enabled. You manually disable it by turning off the firewall and remove the route with 169.254.0.0 / 255.255.0.0 using the route command.

Example output of the route with the zeroconf route enables would like similar to the following:

# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.15.50.0      *               255.255.252.0   U     0      0        0 eth0
169.254.0.0     *               255.255.0.0     U     0      0        0 eth0

Solution:

To disable the zeroconf route during system boot, edit the /etc/sysconfig/network file and add the following NOZEROCONF value to the end of the file:

NETWORKING=YES
HOSTNAME=localhost.localdomain
NOZEROCONF=yes

Additional Information:

Find out more about zeroconf at http://www.zeroconf.org/.

What is a defunct or zombie process in ps or top output?

by Rahul Sundaram

A defunct or zombie process, as it is otherwise called, is one which is no longer in effect. It is represented by the "Z" (Zombie) state in a ps output. It is a process which was been killed or exited using exit(2) system call but has not received a wait(2) call from its parent process.

A defunct process does not consume any system resources except for its entry in the process table maintained by the operating system and can be safely ignored. It will be terminated when its parent process completes execution or during system reboot.

How do I enable a script to start and stop a service at different runlevels using chkconfig?

by Joshua Wulf

For a script to interact with chkconfig and the automatic starting and stopping of services at different run levels, it needs two key components.

The first is a commented section that allows the script to be managed by the chkconfig tool. Here is an example:

#!/bin/bash

#
# chkconfig 345 10 90
# description This is where you put a description of your service

In this example, the numbers 345 after the chkconfig directive represent the runlevels that the service will be enabled for by default. In this example the service will be enabled by default for runlevels 3, 4, and 5.

The 10 is the start priority. The lower the number the higher the priority and the sooner a service will be started. The 90 is the stop priority. The lower the number the higher the priority and the sooner a service will be stopped when changing runlevels.

The second essential component is that the script must support being called with the arguments "start" and "stop." The script will be called with "start" as an argument when the service is being started at a given runlevel and "stop" when it is being stopped. Within these functions the script should touch a lock file in the /var/lock/subsys/ folder. If this is not done, the script will automatically start, but will not stop automatically. This should be done in the following manner:

start() {
  ...
  touch /var/lock/subsys/servicename

}

stop() {
  ...
  rm -f /var/lock/subsys/servicename
}

Once you have created a script that conforms to these two requirements, place a copy of it into the /etc/init.d/ directory and execute the command:

chkconfig --add servicename

This will register the service and create the necessary links in the appropriate rcX.d directories. You can now administer this service using chkconfig command.

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.