Upgrading cyrus

[Patrick Goetz]

On 08/14/2010 08:12 PM, Benjamin Seidenberg wrote:
> The main thing that has yet to be done is work on an automated upgrade
> path from existing 2.2 installations to the 2.3 packages. If you want to
> test these packages, please let us know about how your upgrade process
> went - what worked, what didn't and how you fixed any problems you
> encountered.
>

 > On 09/01/2010 03:20 PM, Patrick Goetz wrote:
 >> I'm guessing that most people who are upgrading a mail server are
 >> upgrading the hardware, too.
 >
 > Please provide a basis for that assertation. I think that that's
 > probably true for large installations, but for many small
 > businesses/organizations it is not.


Hi -

I never responded to this. Although I *think* most people will want to 
upgrade their hardware at the same time that they upgrade their mail 
server software (hardware is cheap after all, and labor is expensive) I 
suppose I could be wrong about this.  But in any case I didn't think 
about the case of murder installs.

(Thinking out loud) since cyrus uses the filesystem as the message 
database, it seems to me that upgrading from one version of cyrus to 
another really just boils down to upgrading the Berkeley DB files 
/var/lib/cyrus from libdbN to libdb(N+K).

To this end, it would be helpful to have some documentation on what 
these files are/do.  Appended below is an email exchange I had with 
someone back in 2004 about this.  I thought maybe this would now be more 
thoroughly documented in the Cyrus wiki, but it looks like the Cyrus web 
pages have been updated and now I can't even find the Wiki any more -- 
anyone have any idea what happened to this?



-------- Original Message --------
Subject: RE: Cyrus 2.1.15 database files
Date: Sat, 17 Jan 2004 01:05:38 -0600
From: Michael Sims <michaels at crye-leike.com>
To: Patrick Goetz <pgoetz at mail.utexas.edu>


I'm about to do a migration of an existing mail store from one machine 
to another.  I'm keeping the same database types for each database, but 
the Berkeley DB version is different on the new server so I made some 
notes on which files I plan on transferring and my (educated) guesses at 
what their purpose is, and how much trouble I'm going to have with it 
after transferring:

------------------

/var/imap/

   db/
     -Contains the BDB environment.  Probably safe to let cyrus recreate
this,
     not sure, need to test.  If not, ctl_cyrusdb -r should fix any problems

   db.backup1/
     -Contains backup of BDB environment.  Not worried about it.

   db.backup2/
     -Contains backup of BDB environment.  Not worried about it.

   deliver.db (SKIPLIST)
     -Used for duplicate delivery supression
     -Copy file straight over, any inconsistencies should be fixed with
      ctl_cyrusdb -r

   log/
     -Empty, not worried about it

   mailboxes.db (SKIPLIST)
     -Main mailbox list database
     -Export with ctl_mboxlist -d > mailbox.txt
     -Import with ctl_mboxlist -u < mailbox.txt

   msg/
     -Empty, not worried about it

   proc/
     -Created at run time, not worried about it

   quota/
     -Flat files, copy straight over, any inconsistencies will be fixed with
     quota -f

   server.pem
     -SSL key, will probably need to be recreated

   socket/
     -Created at run time, not worried about it

   tls_sessions.db (DB3)
     -Cached SSL sessions.  Don't need to transfer it.

   user/m/michaels

     michaels.seen (SKIPLIST)
       -Seen database
       -Copy straight over, hopefully ctl_cyrusdb -r will fix any
inconsistencies
     michaels.sub
       -IMAP subscriptions
       -Flat file, should copy straight over without incident

/var/spool/imap

   stage./
     -Temp directory, not really critical, don't copy it over

   m/user/michaels/

     cyrus.cache
     cyrus.header
     cyrus.index
       -Should be fine.  Can be recreated with reconstruct if necessary.

------------------

Anyway, there it is, FWIW.  I can't recall from your previous post whether
you've tried to run ctl_cyrusdb -r or not, but if you haven't you might want
to try it.

As I said, I normally wouldn't share information when I'm so uncertain of
it's validity, but I figured since you weren't getting any answers this was
better than nothing...

___________________________________________
Michael Sims
Project Analyst - Information Technology
Crye-Leike Realtors
Office: (901)758-5648  Pager: (901)769-3722
___________________________________________