United States (change)
Shortcuts: Downloads Fedora Red Hat Network
Issue #10 August 2005
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.
Yes. In Red Hat Enterprise Linux 4 the GNOME desktop is provided with an embedded vnc like service called vino. Vino allows a vnc client to remotely control the logged in users native GNOME desktop and enable desktop sharing. To activate, for the user you want to share his/her desktop, log in, select Applications --> Preferences --> Remote Desktop and check Allow other users to view your desktop checkbox. Hit Close and voila, a remote vnc client can access the current users GNOME desktop by pointing it to display :0 on the machine.
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:
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
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
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.
Not all scripts with start/stop/status options are manageable by chkconfig. The script must adhere to the following requirements:
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
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/.
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.
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.