Bug#369882: cyrus-doc-2.2 upgrade issues

[Henrique de Moraes Holschuh]

On Fri, 16 Jun 2006, Ross Boylan wrote:
> switched all of them, or some of them (remarks below seem to imply the
> latter)?

$ cat /usr/lib/cyrus/cyrus-db-types.active
DBENGINE BerkeleyDB3.2
DUPLICATE db3_nosync
MBOX skiplist
SEEN skiplist
SUBS flat
TLS db3_nosync

> It sounds as if it could auto-detect the type of db in use and spare us
> all some trouble.  Though I guess even then one would need to specify
> the format when the db's were first created.

Use upstream default unless overriden, override only at first install if
upgrading from 2.1.  Ask user first if he is sure and if he made a backup
beforehand, and remember to run the berkeley DB upgrade utils on all BDBs.

> If 2.1 and 2.2 on Debian use different bdb formats wouldn't that require
> conversion of all bdb databases on upgrade?  Since the 2 reported

Yes.

> successful upgrades (earlier messages in this bugreport) did not mention
> doing such a thing, that suggests the bdb format is the same for cyrus
> 2.1 and 2.2 on Debian.  Or am I missing something?

Cyrus might be doing it by itself, I didn't check, so I don't have answers
on this one.

> I can't see anything in the docs about how a user would byte-compile a
> script in their homedir. (Well, uploading it to the sealed server
> compiles it, but then the script is in the server, not the home
> directory).
[...]
> Are you referring to any files other than .sieve?
> If .sieve in home directories is not compiled there is a performance
> penalty, and possibly a late discovery of syntax errors penalty, but I
> don't see how this would lead to anything terrible.

Well, if CMU changed Cyrus in 2.2 to deal with that extra external
interface, no, there is no harm.  As I said, I am just not aware of it.

> This sounds as if it involves messing with stuff in directories that
> cyrus manages.  I think that's what one is doing if following the

Yes.  Which is why I consider placing sieve files anywhere else than inside
Cyrus' spool/admin directories a bad mistake.  But as I said, it might well
have nowadays an extra external interface (user .sieve files?), in which
case you are not messing with internal stuff.  I am just not aware there is
such a thing.

> The phrase "(outside of home directories)" in the upstream advice is
> obscure to me, but I think it means that the operation works on the
> scripts in the server, not in the home directories.

Probably, in which case it really needs to be clarified :-)

> Does this mean you recommend against enabling sieveusehomedir, against
> doing the command line starting with masssievec above, or something
> else?

It means that, UNLESS Cyrus now has an external interface for "sieve files
on user homes *where they can be freely modified by the user*", it is an
extremely bad idea to have those files anywhere outside the Cyrus black
box.

> all the databases that can be configured (I count 8).  I suppose each

This is new for 2.2/2.3, I only dealt with the ones in 2.1 directly.

> database listed in imapd.conf may correspond to 1 or more physical files
> because their is one database per user or per mailbox, or because the
> concept is implemented using several different databases, or because the
> database itself uses several different files.

A database can have files scattered on two places: where cyrus wants it, AND
where the database backend wants it.  For berkeley DB (all versions), this
is the db enviornment inside /var/lib/cyrus/db, plus wherever cyrus is
placing the database.  They go in /var/lib/cyrus for global ones, and inside
the mailboxes admin hierarchy (which is not the same as the spool in 2.1)
for per-mailbox ones.

> earlier version, it just recompiles.  If Cyrus did something like that
> there'd be no need for manual (re)compilation of scripts on upgrade.

Correct.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh