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

4/15    Has the wall_log moved?
        \- try /var/log/wall.log -- if there's any symlinks you'd like
           for scripts or whatever, put 'em down. --michener
           \_ /usr/local/csua/wall_log
              \_ done

4/15    Will "frm" be back, or does it not exist in the new OS?
        \- "frm" as in mail "frm"? This is a part of elm. If you'd like
           me to compile elm from source and install it, I will -- or
           is the "from" commmand sufficient? --michener
           \_ How about "nfrm"? -!op
        \_ I use the frm command in scripts to check various files that
           incoming mail is sorted to.  Might be able to use from to do the
           same thing, but haven't looked into that yet.  Ideally, I'd like
           to use frm, as my scripts use it, but this is certainly not a
           top priority at the moment, with all the instability. -op
           \_ Certainly it's preferable that things just work without needing
              to change your scripts, but, as an alternative, you could
              probably modify your scripts to use formail. -dans

4/15    Mail off means that mail is being bounced?  Or is it still being
        queued up on scotch?
        \_ Speaking of mail, I think mail for csua should be handled by
           a separate machine that normal people can't interactively use.
           Just a suggestion.
           \_ what about the people who use mutt, won't they be sadened that
              /var/mail is on a nother machine that they can't use their mutt
              to mutt with?
              \_ mutt will have no problem with it.  -tom
              \_ mutt and pine both support imap. -dans
              \_ nfs mount /var/mail onto soda.
                 \_ You don't care very much if your mail mysteriously
                    disappears, do you? -dans
           I knew 6.x isn't good for production from following the
           freebsd-{stable|bugs} lists.
           Oh, and thanks for staying up all night fixing things.  (You
           did, right?)
           \- I think the consensus is that we want to move to a new
              mail machine that is seperate but right now the priority
              is getting mail+ssh working.
        \- Queueing

4/15    install mh, fools
        \- Done.

4/15    Woot!

4/15    First

4/12    Is there something wrong with ssh?  I keep getting kicked off
        while using pine. -jrleek

4/15    So much for "We are Berkeley we must use FreeBSD" :)

4/15    A Linux Soda?  What, no rants from the Linux haters?

4/15    Any chance /csua/tmp/* will be restored soon?
        \_ It will not be restored. That is what "tmp" means.
           \_ Assuming this is written by root, that's too bad.
              it was where I was keeping my root mail archive. --Jon
              \_ I feel your pain.  I was storing all my personal documents in
                 a dumpster and those &^$(#&$@ garbage men threw it out.
                 \_ Well, ultimately, not my loss.  I kept it around
                    for history's sake and the benefit of new root who
                    might have been interested in what came before, but
                    there wasn't much interest in finding a better place
                    for it in the past few years, so guess it's not that
                    interesting.  --Jon
                    \_ Well, we *do* have /csua/tmp around, and we *do* have
                       the space partitioned off for it -- we just haven't
                       copied it yet. We'll do that at some point after getting
                       mail working. -- michener

4/15    IMAP seems to be working now. I don't know if it's on purpose or not.
        Didn't try POP.
        \_ keep waiting

4/15    19:42:14 up 17:58, 27 users,  load average: 0.43, 0.25, 0.14
        ... and counting.  Props to the current undergrads.

Linux soda 2.6.16.5-soda0 #1 SMP Wed Apr 12 18:06:46 PDT 2006 i686 GNU/Linux

Welcome to Macintosh^H^H^H^H^H^H^H^H^HSoda Mark VII,
a dual Xeon 2.8GHz with many hozers.

4/16    After much late night debugging, soda is now correctly accepting
        and sending mail. Spamassassin is working. The queued mail is being
        de-queued.

4/15    Soda is up -- in a testing sort of mode. This time, we're over on
        Debian. A lot of stuff should work as well as it did before on
        FreeBSD 6.1 -- and the stuff that is broken, well, one thing
        at a time. Special thanks to mconst, michener, mikeh, edilaic and
        mrauser -- should start a band, "4 M's and an E"