Greetings -
Could someone confirm how to perform various upgrades on a live
system running Dovecot please?
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?
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?
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?
Ideally I want existing connections to remain running, but new
connections to start up using the new X.Y.Z version of Dovecot.
The comment for "shutdown_clients" implies this, but also says:
"This however means that after master process has died, the client
processes can't write to log files anymore."
So if I understand this correctly then with "shutdown_clients = no"
in force then the sequence and behaviour is this? ...
1. Old version A.B.C of Dovecot running, clients can log
through the
master "dovecot" process to the logfiles.
2. Kill the old master "dovecot" process, start new X.Y.Z
version up.
3. New connections get served by version X.Y.Z.
Old connections DON'T get killed and can continue, BUT can
no longer
write anything to the logfiles?
With many thanks,
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. *
>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.).> Message: 3 > Date: Thu, 4 Oct 2007 13:57:03 +0100 > From: Mike Brudenell <pmb1 at york.ac.uk> > Subject: [Dovecot] How to upgrade a running Dovecot? > To: Dovecot Mailing List <dovecot at dovecot.org> > Message-ID: <06B4C604-41E3-4061-96B2-C7C719E21D49 at york.ac.uk> > Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed > > Greetings - > > Could someone confirm how to perform various upgrades on a live > system running Dovecot please? > > > 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.> > 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.> 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.> Ideally I want existing connections to remain running, but new > connections to start up using the new X.Y.Z version of Dovecot. > > The comment for "shutdown_clients" implies this, but also says: > > "This however means that after master process has died, the > client > processes can't write to log files anymore." > > So if I understand this correctly then with "shutdown_clients = no" > in force then the sequence and behaviour is this? ... > > 1. Old version A.B.C of Dovecot running, clients can log > through the > master "dovecot" process to the logfiles. > > 2. Kill the old master "dovecot" process, start new X.Y.Z > version up. > > 3. New connections get served by version X.Y.Z. > Old connections DON'T get killed and can continue, BUT can > no longer > write anything to the logfiles? > > > With many thanks, > 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. * > > > > >-------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2447 bytes Desc: not available URL: <http://dovecot.org/pipermail/dovecot/attachments/20071004/d9fb2e50/attachment-0002.bin>
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. *
On Oct 5, 2007, at 12:41 PM, dovecot-request at dovecot.org wrote:> > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 5 Oct 2007 10:25:49 +0100 > From: Mike Brudenell <pmb1 at york.ac.uk> > Subject: Re: [Dovecot] How to upgrade a running Dovecot? > To: Dovecot Mailing List <dovecot at dovecot.org> > Message-ID: <B9A4EC9A-82C0-4250-BC98-606695775041 at york.ac.uk> > Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed > > Hi, Jerry/et al - >Hello Mike, (stuff chomped out)> >>> 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? >Just to be clear about this for myself, (instead of relying on the 'ol saying 'that is how it used to work' -- because I am switching over to 1.1 from 1.0.n your question takes on new relevance for me as well) I tested this and yes it works as before, the new files seem to be used for the new connections (all of the dovecot auth processes are killed on the HUP signal -- dovecot itself just rereads the conf file and new auth listeners are started -- assuming that you use Dovecot for the auth mechanism to Postfix) and existing connections seem to handle things okay. I did find something new (or I have not noticed it before) If you kill (not just restart) the Dovecot process itself and restart it with existing connections (someone was connected to IMAPS when you killed Dovecot) Dovecot will not restart, complaining that port 993 is taken already. This happens regardless of the shutdown_clients = yes/no setting. This may be particular to the new version 1.1, I do not know.> Jerry-------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2447 bytes Desc: not available URL: <http://dovecot.org/pipermail/dovecot/attachments/20071005/91be8d15/attachment-0002.bin>
On Thu, 2007-10-04 at 13:57 +0100, Mike Brudenell wrote:> 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?One problem with SIGHUP is that it kills connections that are currently logging in (sending "* BYE Server is shutting down." to client). Would be nice if one day the login and auth processes simply stop accepting new connections and kill themselves only after the last client has disconnected.> 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?Yes, the SSL files are read by login processes at startup. And SIGHUP restarts login processes. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://dovecot.org/pipermail/dovecot/attachments/20071006/25aa0916/attachment-0002.bin>