Usage of rwho, rwhod and rwhod++

This page describes usage, deployment and advantages of the rwho/rwhod system.

First: This page assumes that you are familiar with standard UNIX/Linux installations and of course also UNIX commands. The usage of rwho/rwhod is only useful if you administer a lot of computers. So using this is more or less senseless on a standalone workstation.

What is this for?

With rwhod its possible to do some simple form of remote monitoring of computers. Think of having a lot workstations, potential physically located in different rooms. This system allows you to lookup: uptime, load and logged in users. For retrieving informations exists the standard UNIX commands:

rwho: See who is logged in on which computer. (Sample output)
With who this information can be obtained on the local host.
ruptime: A list of monitored computers with uptime (time since last reboot), how many users are logged in and the load averages for the past 1, 5, and 15 minutes. (Sample output)
The equivalent for getting this information for the local computer is uptime.

The traditional system with rwhod:

Every computer runs a rwhod and uses broadcasts (on the configured subnet) to spread informations about itself. So other computers with rwhod-daemon may listen to this information-packets and can maintain a list of 'active' computers.
So the rwhod-daemon is both a producer and a consumer of information. The list of 'active' computers is traditionally maintained in /var/spool/rwho or /var/rwho.
This system works well in small-sized networks. Unfortunately this configuration implies some not-so-well features:

Security: It's obvious that the rwhod-port (e.g. Port 513/UDP) must be accessible at least in local network for every computer. Otherwise no information could reach the daemon.
Data protection: Since information about every computer is broadcasted over the net, everyone in the subnet could potentially catch this information. Normally this is harmless but on the other side this can be a unwanted side-effect when information about the network is distributed to non-authorized persons.
Network traffic: The system of broadcasting is nice with a few computers because it works almost out of the box. Just start the daemon and it will begin to send and gather information.
The disadvantage from this is that network traffic increases with every computer taking part in the system.
Other problems are different subnets. With broadcasting it's almost not possible to reach computers that are located in different subnets. There are existing different solutions for this problems, one of it is presented here.

The system with rwhod++:

Basically the rwhod++-daemon is a direct replacement for the rwhod-daemon. Difference is that it now queries each host on the network instead of using broadcasts. So the produced files are still in the same format accessable by rwho and ruptime. (For implementation details please see the README file in the tgz-archive.)
The usual scenario is to setup only one daemon and distribute the gathered information with a standard network filesystem (e.g. NFS). The rwhod++-daemon gathers informations by querying two specialized daemons on each computer in the network.
So on every host the rusersd and the rstatd service must be available. Normally these daemons are distributed with the operating system, so under Linux you only have to install the package(s). (They are often called rusersd and rstatd, sometimes rpc.rusersd resp. rpc.rstatd.)
You can test your setup with the command rpcinfo -p <hostname>. There should be some output about these two services.
NOTE: Since these services are SunRPC based it's necessary to allow that the portmapper is running and accessable. When this rpcinfo command does not produce any output or just prints an error message than the portmapper is potentially unreachable.

Although this daemon does not broadcast to reach other computers it needs some other source of information about hosts. There are two options: NIS-netgroup or a plain file. The NIS (a.k.a YP) netgroup has the advantage of being centrally managed but can also be more complicated. So a plain (ascii) file with every host in the network (line by line) is also sufficient.
What else is needed?

A spooling directory. You can use /var/spool/rwho (the default). Be aware that network traffic can be very high when exporting this directory. So if there are many computers accessing this directory you should apply some caching or tuning. This can range from some special exporting/mounting parameters for this directory, copying all files periodically to a more specialized fileserver or using of cache files with preformated output (see README).
A maintained list with valid hosts. Do not forget to update this list periodically.
Also hostnames of damaged resp. permanently disconnected computers must be manually deleted from the spooling directory.
On each client that should access the spooling directory it's necessary to link or mount in /var/spool/rwho to the server spooling directory. So that all client programs may find the correct files in the usual place.

Now for testing the server: Write the hostname of a to be monitored computer in a file and start the server with this (absolute) filename as argument. Now the server should start querying the remote host and created whod.<hostname> files should appear in the spooling dir.

So this rwhod++ system has some advantages over the traditional system. The subnet-, network traffic problem and mostly the data protection and security problems are solved.
Some disadvantages are unfortunately coming along:

This system brings more dependence to the network.
This means: With the former system every host was independent and maintained his own list of hosts. Now it's necessary to use the global maintained list.
The content of the spooling directory is endian specific to the server.
This means: If you have a heterogeneous network with more than one processor architecture (like: i386 and PowerPC) than you will have a problem with the byteorder. The files produced with the PowerPC-server are not readable by computers with an intel-chip (i386 arch) inside.
This is solvable e.g. with some adapted tools.

Other

This rwhod++ is only one possible replacement for the traditional rwhod system. There are a lot of other systems on market that fits the purpose of monitoring and even more. This ranges from security scanners like nessus, some gnome or kde developments or big solutions like IBM Tivoli.

Last edited: 19. Juni 2005 by Sebastian Kolbe