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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
