The Remote Uptime (RU) Project

History
 
   I started using Unix systems in approximately 1984 at Colorado State University.    At that time, Unix was BSD or SysV.  TCP/IP was new as was networking computers in general.  Needless to say, I found Unix to be really cool.  Just to date myself, in 1984, the Big Computer on Campus was a CDC Cyber, and the primary computer that ran the Computer Science Departement was a Digital VAX 11/750 (not even a 780!).  The computing facilities were HP 9000/300 series workstations/servers with a blazing 16Mhz 68020 CPU and 8 megabytes of memory and HP/IB storage.  Needless to say, these weren't powerful machines.
    When assignments were due, the systems got horribly busy.  The computing system assigned to a paticular class (if only one) got so slow that it literally was seconds between typing a keystroke and seeing it on the screen.  Due to this, the idea of using an idle system from another class became attractive.  I would find a non-busy system, do my editing there, and rcp/rlogin to the primary host, do my compiles and go back to editing.
    As part of this, I found the 'ruptime' command.  It was very handy for figuring out what systems were on the network and how busy those systems were. 
    After I left college, I eventually became a Systems Administrator (SysAdmin).  I liked the 'ruptime' functionality for watching the systems in my environment.  However, as soon as I turned on the ruptime function, I found that the program had a few major flaws:

    Due to the problems above, I ended up turning off rwhod on all of the clients.   However, I still wanted something similar so that I could quickly see system status.

RU is Born
 
Around this time, I asked a co-worker of mine, Dave Farnham,  whether he had a way to implement something similar to ruptime, but without the nasty edges.  Dave spent a weekend (he's a wiz) and came up with an RPC based system that operated in a client-server mode.  By using RPC, the solution was very portable, and easily ported to pretty much everywhere.  The initial version reported only system uptime by using a RPC call from the client to a centralized server that ran a collection daemon written in Perl.  This initial version appeared in the 1994-1995 timeframe.
    Over the next year or two, Dave added history reporting, system load graphing, and availability reporting.  Around this time, Dave decided to leave the company, and went on to another position at another company.
    I then took over the maintenance of the ru source.  Over time, I've added a number of features until I consider it to be a mature, easy to use system status reporting program. 
    I find it very handy to simply type 'ru' periodically to see what is going on in the environment.  ru is very useful for detecting 'just not right' server problems, such as runaway jobs, high loads, etc.

What is RU?
xterm ru display
   
    In the above picture the program 'ru' has been executed against a larger environment of servers.  Immediately, you can see the system name, the system uptime, the load average, and the number of logged in users.  In addition, the coloring of the text shows a number of additional items.  The server 'handies1' has been booted only 14 minutes ago.  It is shown in yellow to attract attention that the server has booted in the last 24 hours. 
    Server 'jaguar' has a * in front of it, which indicates that the system hasn't reported in two minutes.  This actually indicates that the clock on jaguar is out of sync with the master server, and that the system in question is really more than two minutes different than the host system.  If you deploy ru, you need to synronize your system clocks with NTP (or something similar).  It's a good idea to synchronize your clocks for security purposes anyway.
    Below represents many (but not all) of the features of the ru system:
Installation

    Detailed instructions are found in the download tarball.  However, the below represents a simple overview of the installation:
    Note that the current solution is focused towards a particular production environment.  It should be easily possible to redefine flags any way desired with the use of a text editor.

    If you should have questions, see the forums, or contact me at shaw at fmsoft dot com.

Futures
    I'd like to change a few things about how ru works to make it truly no-brainer install-and-manage:


Thanks to SourceForge.net for hosting this project.

SourceForge.net Logo