4/15 Another idea. I don't know if it's practical. But is it possible
for each user to provide a yahoo or other address that mail can
be forwarded to during extended downtimes like this?
\_ Certainly, you can add a .forward file. Now if you want something
that well work during downtime... thats not the answer. We are
seriosly considering moving mail to another box so when soda
gets rooted we can spend less time unable to deliver mail.
\_ I think that's best left up to the users. I got no mail thru the
downtime, but i Expected that, and did not care.
\_ So, as a user, what can I do, if anything, to set my
incoming mail to forward to another address _when soda is
down_?
\_ As a user, absolutely nothing. The CSUA doesn't have users,
it has members. As a member, you could write some code that
\_ as a user of the systems, geez, as in, versus a root
staffer who can do things with their mail.
\_ Yes, as a member, you can write code which you can hand
to root and say, check out this neat program I wrote
that lets our members do this cool thing they couldn't
do before. -dans
makes what you are requesting possible. Alternatively, you
could offer the current undergrads assistance with migrating
mail to a host other than soda, though after the amount of
time they just spent on soda, I don't think they're too keen
on taking on another big project right now. -dans
\_ how would this be a big project? The same way sendmail
is setup now, set it up on box B. change MX records.
NFS mount mail from box B. Setup imap/pop on box B
instead of on soda.
\_ The fact that your solution involves NFS mounting mail
with the existing sendmail setup shows that you have no
idea what you're doing. That, or, in the two years
since I last looked at this problem, file locking over
NFS has changed so that it works, and sendmail uses
this shiny new magic (i.e. working) NFS file locking.
-dans
\_ Does this mean sims, eecs, ocf, etc, plus all
the other places that export their mailspools,
all of them have "no idea what [they're] doing" ?
\_ dans and tom: a case of convergent evolution
\_ If the following reasoning is flawed, please point
out the error, and I will admit that my previous
statement was wrong. Of course, all of the
reasoning below goes out the window if NFS now
features a working locking mechanism, a
qualification I made above:
1. Multiple processes cannot safely write to a
classical unix mbox file without a functional
locking mechanism.
2. Modern MTAs, a set I begrudingly include sendmail
in, use multiple processes or threads to speed
mail delivery. As a consequence of this, modern
MTAs cannot safely deliver mail to an mbox file
hosted on a remote NFS server.
3. When a mail client, e.g. pine or mutt, works
directly with an mbox file (vs. through a POP or
IMAP server), it will need to write changes to
the file. If the file is hosted on a remote NFS
server, these writes cannot be performed safely.
Ergo: Working with mail stored in unix mbox file
format via a remote NFS server carries the risk of
corrupting mailboxes and losing mail.
-dans
\_ Sendmail doesn't have to use mbox. However,
this is the same concern a number of us raised
when soda went to nfs mounted homedirs. It
was summarily ignored.
\_ procmail is nfs-safe -- or claims to be
anyways.
\_ That's nice. It's also an additional detail
that adds to the work required to move from
the existing mail setup to your shiny
hypothetical new mail setup. Are you
volunteering your time and services? -dans
\_ possible, but not currently, some sendmail hackery would
do this quite nicely.
\_ Does anyone know if mail is being queued during downtime?
\_ mail is queued for 5 days or until scotch's disks fill.
\_ #f. Normally mail is queued for 5 days (this is a
sendmail default) or until scotch's disks fill, but the
max queue time was increased to prevent mail loss. -dans
\_ How about next time soda is taken offline for a significant amount
of time that everyone gets suitable warning first?
\_ While we're at it, why don't we put a message on the website
asking hackers to kindly inform us one week in advance before
breaking into soda? -dans
\_ What does that have to do with anything? If soda was already
compromised for who-knows-how-long, what's an extra day? And
ssh access could have been stopped while giving people some
time to download their email locally.
\_ As soon as the extent of the compromise was realized we
immediately brought the machine down. I apologize, but I
imagine that when we get hacked the next time we will have
to bring the machine down quickly again.
\_ You're not familiar with UCB campus network policies, are
you. The root staff did what campus policies required and
what any responsibly system administrator would do. There
are more important aspects to running soda than providing
you with continuous, uninterrupted access to your mail.
Now that you know this, perhaps you will set up your
.forward to save a copy locally and automatically forward
a copy to a secondary mail address. Come on, knowing is
half the battle! -dans |
http://csua.com/feed/