Hi, Jerry/et al -
On 4 Oct 2007, at 20:47, Jerry Yeager wrote:
Have you considered sending out a message to each user to the
effect that on some day, darned-early a.m. the system will be
offline for 30 minutes for maintenance (no incoming email will be
lost, etc., etc.).
We have around 20,000 users at our site and need to keep downtime of
the e-mail service to an absolute minimum. The quietest time is at
around 4:00am ... when I am sound asleep in bed, and plan to stay
that way! :-)
Seriously... I'm not new to timing and managing software upgrades:
I've been doing it for around 19 years here now.
But what I _am_ new to is Dovecot. Not knowing the software well
yet, my questions are in an attempt to find the best way to flip it
to a new configuration or version with minimal/no disruption to
connected users.
Scenario 1: Change to dovecot.conf
If I make a change to dovecot.conf am I right in thinking I can simply send a HUP signal to the main dovecot process to get it to re- read the configuration file and act on its revised content?
Yes, this is correct.
Good...
Scenario 2: Altered SSL Certificates
I need to replace our current certificates and have prepared new files containing the replacement certificate and private key. Am I right in thinking that I can simply modify dovecot.conf to point at the new files and send a HUP signal to dovecot? Specifically, will new connections use the revised certificates, and existing connections continue to work OK without interruption?
Ehh not really, the auth child processes can be killed and new ones
started. See your next scenario question.
...So here you're saying that although the "dovecot" master process
re-reads the configuration file, it doing so has no effect on the
existing authenticator child processes? And is it these processes
that are dealing with the SSL connection? ... I'd have thought it was
either the "imap-login" or "imap" processes?
Scenario 3: Software Upgrade
I build a particular version of Dovecot into the tree /usr/local/ dovecot-A.B.C and then have a symlink called "dovecot" pointing at the this directory. To upgrade I can then build the new version into /usr/local/dovecot-X.Y.Z and test.
To actually switch over the live service to the new X.Y.Z version do I need to:
a) Totally shut down the old A.B.C version of Dovecot, thereby breaking all open connections for users? or
b) Assuming I am using "shutdown_clients = no" can I just kill the master "dovecot" process and then start up the new version?
See the preface, do the update when you typically have few folks
using the system -- which gives you fewer complaints from users
should things break on their end.
Yes... However the dovecot.conf configuration file includes a comment
which says this:
# Should all IMAP and POP3 processes be killed when Dovecot master
process
# shuts down. Setting this to "no" means that Dovecot can be upgraded
without
# forcing existing client connections to close (although that could
also be
# a problem if the upgrade is eg. because of a security fix). This
however
# means that after master process has died, the client processes
can't write
# to log files anymore.
#shutdown_clients = yes
This implies it *is* possible to upgrade the software without
breaking existing live connections. I'm trying to get confirmation
of this along with any side-effects -- for example the comment seems
to warn that pre-existing connections will no longer be able to write
to the logfiles after the changeover?
Cheers, Mike B-)
-- The Computing Service, University of York, Heslington, York Yo10 5DD, UK Tel:+44-1904-433811 FAX:+44-1904-433740
- Unsolicited commercial e-mail is NOT welcome at this e-mail address. *