[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Upgrade a mail server

On Mon, Feb 18, 2002 at 09:21:16PM -0600, Rich Puhek wrote:

> You didn't state if you're an ISP or another institution. 

ISP.    24/7 operation required.

more precisely: it's not my ISP, i'm the senior system admin at an ISP.

> > (*) it involves using semaphore files in each users homedir to
> > indicate whether they are maildir or still mbox, plus
> > procmail/maildrop rules to deliver accordingly, and a pop proxy
> > which chooses whether to connect to the mbox or Maildir capable pop
> > daemon.  when that's done it is possible to safely convert all the
> > mboxes to maildirs
> Yow. That might be overkill. I'd try some testing to determine how
> long the migration process will take. If you're talking about anything
> under 4 hours, you can probably count on running from, say 2AM to 6AM.
> Set your, ahem, pickier users to be transfered first. Safety isn't
> going to be an issue with Maildirs, the only concern I'd have is
> making sure that before you run your script to convert the mboxes you
> have disabled any other process that will touch an mbox. Last
> convertion I did our customer (an ISP with ~3000 users) had accepted a
> maintenance window where POP and SMTP services would be unavailable,
> so I simply made sure sendmail and qpopper were dead, then for good
> measure I believe I changed permissions, ownership, or the directory
> name of /var/spool/mail, just in case.

yes, that's another variation.  if downtime was only 4-6 hours and if i
was willing for users to be unable to fetch mail with POP or IMAP for
that time then i could:

 - configure postfix so that "deferred_transports = local" - this leaves
   ALL local deliveries in the queue until i flush it manually while
   still allowing the mail server to relay outbound mail to other
   servers for my users.


 - create Maildir/ and ~/.conversion_in_progress in each home directory
   before starting the conversion script, and have a procmail or
   maildrop rule which exited with a temporary failure code (EX_TEMPFAIL
   from /usr/include/sysexits.h) if ~/.conversion_in_progress exists.

   this would effectively defer incoming mail only for those users whose
   mailbox hasn't been converted yet.

   the conversion script would "rm -f ~/.conversion_in_progress" as soon
   as the conversion was done.

this solves one major problem - i don't like the idea of having SMTP
down at all...i won't tolerate it and my users certainly wouldn't.

doing this, both sending and fetching mail would work perfectly for
users whose mailbox has already been converted.  users who have yet to
be converted could send mail but not fetch it.

that's not a bad compromise...if the entire job could be done in only a
few hours.

the particular mail server that needs conversion has about 6000 users.
most of whom have very small mailboxes.  some have obscenely large
mailboxes (200MB or more).  last time i checked there was a total of
about 6GB in /var/spool/mail

> If preliminary testing indicates you can do the changeover is a matter
> of very few hours (which wouldn't surprise me with decent hardware), you

that's the key issue.  can the entire system be converted in less than 6

> Here's another angle to consider: perhaps a watchdog script to fire
> off a convertion script as soon as the user logs in (PPP-wise, this
> does assume you're in a dialup-ISP type environment). By the time they
> finish connecting, negotiating, and resolving the POP server IP
> address, most of their mail will be converted. On the downside... not
> sure I trust a script to run that unattended for such a critical
> process.

i've already had this idea.  it has some merit, but it's more
complicated than the one i mentioned in my last message, and certainly
more complicated than the above.  in general, i disapprove of
unneccesary complication - i'm a strong believer in the KISS principle.

> Best of luck when you finally convert. You're on the right track to
> make sure it doesn't end in disaster.

it will happen, but not until i am 100% certain that it's going to work
without a single problem.


craig sanders <cas@taz.net.au>

Fabricati Diem, PVNC.
 -- motto of the Ankh-Morpork City Watch

Reply to: