System Maintenence <sysmaint(_at_)area51(_dot_)dicksonstreet(_dot_)com> writes:
I am currently maintaining several linux servers with full internet
services, and suddenly, quite without warning, one of them (2.0.0 kernel -
slackware dist.) started bouncing back mail with errors like -
procmail: Enforcing stricter permissions on "/var/spool/mail/ntsnwa"
procmail: Lock failure on "/var/spool/mail/ntsnwa.lock"
procmail: Error while writing to "/var/spool/mail/ntsnwa"
550 <ntsnwa(_at_)dreamland(_dot_)dicksonstreet(_dot_)com>... Can't create
output: Error 0
It would seem that this would either entail a bad permission on a file in
/var/spool/mail or sendmail (or procmail) is not running with the correct
permissions (as root?)
What are the permissions of /var/spool/mail and the procmail binary?
Also, is /var/spool/mail local? (If it isn't then that's probably part
of the problem. Delivering mail to an NFS mounted partition is
generally a bad idea, though there are exceptions.) As a wild guess I
would say that you are NFS mounting /var/spool/mail and someone told
the server to stop giving root privileges to client machines. If this
is the case then I would suggest you change your sendmail setup so that
all mail delivery takes place on the server, with the NFS clients
either using a "nullclient" configuration (forward all mail to the
server) or a mailhub configuration (forward local mail to the server,
deliver offsite mail directly)... unless you have a good reason for
doing otherwise. Like every other decision in system administration,
there are expections.
BTW: if you do choose to deliver to an NFS mounted partition, keep in
mind that Linux *does not support* kernel locking (fcntl/lockf/flock)
across NFS, so you *MUST* be sure that dotlocking works. Seeing "lock
failure" messages would mean that you're open to corrupted mailboxes.
Here is an example entry from /var/spool/mail -
-rw-rw---- 1 ntsnwa mail 0 Apr 2 13:24 ntsnwa
^^^^^^^^^^ is this not correct? I have another box on the same network and
they 'appear' the same.
Whether the above permission are correct depends on what permissions
procmail runs with. If procmail is setuid root then the above are
almost certainly wrong.
...
Telnet'ing in yields -
220 dreamland.dicksonstreet.com ESMTP Sendmail 8.8.3/8.8.3; Wed,2 Apr1997 21:0
Hmm, I suggest you upgrade to 8.8.5, or if you haven't already, at the
very least remove the '9' flag from any mailers that have it (local and
prog have it by default), as there's a remotely exploitable security
hole in it's implementation.
Philip Guenther