On Thu, 20 Aug 1998, Curt Sampson wrote:

> 
> All these suggestions are very good, but IMHO, more work than
> they're worth.
[...]

I tried the write-only-media-for-logging thing some time ago.  I tested
the system with a used dot matrix printer.  Maybe the printer was already
on it's last leg.  Regardless, the printer only lasted three days and went
through quit a bit of paper.  A printer with a duty cycle high enough to
actually handle this sort of load long-term would be an expensive
proposition.  We had ~300 active users over some 30 computers (not
counting PCs), which isn't all that big of a site. 

The central log server idea, though, is very practical.  In my last job, I
did just that for authentication logs using a kerberos server.  We didn't
care about any logs but the authentication logs (e.g. we didn't lose sleep
over worrying about a student breaking in and bumping his print quota, so
print logs were just left on a machine with shell accounts).  The kerberos
server was only accesible from the console or through the kerberos daemons
(e.g. didn't run inetd).  For our application (many students logging into
one computer) kerberos was A Good Thing and well worth the learning curve. 
When I'd get one of those dreaded phone calls (one of your users did
something evil) it was *very* nice to be able to look at logs and say with
impunity whether or not that user was on the system at the time.  The
problem we had with kerberos was it didn't log where the user logged in
from, just where they got a ticket (which was always local, since users
never had a ticket on the way in). Point being, I had to rely on a local
wtmp, which was a bad thing, but in practice that never caused me any
grief (thus never got fixed).  Kerberos setup correctly (not allowing
tickets to be checked out by processes other than kinit) was not
pracitical for that site. 

> I think a better way to do this, from a business
> point of view, is to make sure you don't have anything but shell
> users on that machine: mail, www, etc. should all be running on
> other machines that users don't log in to.

This advice is only practical if the users aren't dependant on these
services.  If the users want access to these services (which is most
likely the case), then you'll be inconveniencing them.