Upgrading cyrus

[Jeroen van Meeuwen (Kolab Systems)]

Patrick Goetz wrote:
> On 09/15/2010 02:07 PM, Jeroen van Meeuwen (Kolab Systems) wrote:
> > A spool with 179GB (du -sh, ext3 4k), takes 30 seconds to export and 12
> > seconds to import, noted that this is not the only thing the machine is
> > doing. No raid whatsoever.
> 
> I guess the part I don't understand is why this needs to be done every
> time the process is stopped/started.

Is that considered a blocker?

I feel like I'm repeating myself, but;

1) the export/import on service stop/start is not *mandatory*, I'm not sure 
why you think it *needs* to be done every time the process is stopped/started. 
I think it could aid in solving a problem that has been holding back cyrus 2.3 
for like 5 years now.

2) the intended purpose for the original script as included with RPM packages 
was to not have the user care about all kinds of database format 
changes/updates/upgrades as much

> Presumably because someone might
> have changed the db type in /etc/imapd.conf?
> 

Yes, or, because you have upgraded the machine with a DVD and the database 
formats need to be converted.

Or, you update/upgrade/dist-upgrade online, and the service is restarted 
(that's why it's condrestart and not condreload to rc scripts).

>  > Yes, there is trade-off. There's also trade-up.
>  > Anyone may take their pick.
>  > Maybe this export/import thing is something we can stuff into
>  > /etc/default/cyrus-imapd or /etc/sysconfig/cyrus-imapd?
> 
> On older Debian/Ubuntu systems, the export/import thing would be handled
> by a /etc/init.d/cyrus script.  For Upstart based systems, it would
> presumably be shoehorned into /etc/init/cyrus.conf somehow; or even
> would be an event trigger for the cyrus process.
> 

I know where the command execution would actually be; when I said "stuff it 
in" I meant to say that a variable like CYRUS_IMEXPORT=yes|no in either of 
those files could make the rc script do foo or not do foo.

> How would it make sense to put this in /etc/default/cyrus-imapd, unless
> you mean putting the db types/files here, which makes perfect sense.
> 

rc scripts, whether for SysVInit or upstart, still have the capability to read 
in a file that sets variables sh-style.

FYI, the point becomes moot with the release of Cyrus IMAP 2.4, which includes 
automatic database format and configuration detection and conversion. Any 
solution we come up with lasts for the remainder of the support lifecycle for 
cyrus-2.2 and cyrus-2.3 only.

Kind regards,

-- 
Jeroen van Meeuwen
Senior Engineer, Kolab Systems AG

e: vanmeeuwen at kolabsys.com
t: +316 42 801 403
w: http://www.kolabsys.com

pgp: 9342 BF08