Network-wide Mail Spool?

Glenn R. Stone gs26 at prism.gatech.EDU
Thu Nov 8 08:15:58 AEST 1990


In <KARL.90Nov7120404 at giza.cis.ohio-state.edu> karl_kleinpaste at cis.ohio-state.edu writes:

>fpb at ittc.wec.com writes:
>   Well lets see a fast scan if man pages and related things lists as items
>   which (on SunOS) specifically reference /var/spool/mail/ :

>Any reason why one couldn't place symlinks:

>	cd /usr/spool/mail
>	foreach i (*)
>		mv $i ~{$i}/.newmail
>		ln -s ~{$i}/.newmail $i
>	end
>	chmod 555 /usr/spool/mail	# to prevent removal of the links.

>That's a serious question; I've been debating this for a while.  We'd
>like users' mail not to occupy space in a public filesystem, but
>rather take up space under the area where quotas are enforced.

This assumes quotas are in the kernel.... That's not so on quite a few
machines.... Sequents, R/S 6000's, Sun folks who haven't upgraded....
On a Sun with 4.x, the symlink is a legit way to do things, especially since
nasty things happen when /var fills up... but, on the other hand, it's
not a good idea on a non-quota machine, since equally nasty things happen
when users' home partitions fill up and they try to use a shell with
history or some such..... (this assumes some bozo mailer is bombing
your machine whilst you're abed asnooze, and others are trying to finish
that project at 4am...)

This also assumes that people aren't going to break things by chmodding
.newmail to something funky, or that the mail delivery program runs setuid
 root (which it does on USG).... 

Something else to consider..... I have a cluster of machines, and 
my users (read: bosses) want to be able to get mail on whatever machine 
they log into..... any way you try to go about this, a symlink will
get shot in the foot.

In a nutshell, I think the call on whether to symlink or not is 
highly system-dependent, and therefore should be left up to the
individual S/A..... who should only do so after careful study of
the system config. and TFM (and p'raps the net at large.... which
is exactly what's going on here).

-- Glenn R. Stone
glenns at eas.gatech.edu



More information about the Comp.unix.admin mailing list