Bug#369882: cyrus-doc-2.2 upgrade issues

[Sven Mueller]

Henrique de Moraes Holschuh wrote on 16/06/2006 23:43:
>>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.

Actually, now I saw the list of affected databases: I just removed the
duplicate_db and the tls_cache_db (or whatever they were called exactly)
just before the upgrade. The tls_cache can be rebuild on-the-fly anyway
and I accepted a few possible duplicates to be delivered (only those
where the first copy arrived before the upgrade and the second after the
upgrade).

>>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.

See above.

>>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.

There is no special code in the sieve parts of cyrus-imapd-2.2 apart
from the one determining the path from which to load the bytecode sieve
scripts. ~user/.sieve needs to be the byte-compiled version of whatever
script the user wants executed. To byte-compile an existing script, use
"/usr/lib/cyrus/bin/sievec <input> <output>". It reports syntax errors
rather nicely.

>>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 :-)

masssievec is not capable of handling scripts in user's homedirs. The
following shell code should work however, if all your user homedirs are
below /home (and are named like the matching user):

#!/bin/sh
cd /home
if [ -e 1*/.sieve.src ]; then
    echo "ERROR: a .sieve.src file was found
    exit 1
else
    for i in *; do
	if [ -r $i/.sieve ]; then
	    mv $i/.sieve $i/.sieve.src
	    if ! /usr/lib/cyrus/bin/sievec \
			$i/.sieve.src \
			$i/.sieve ;\
	    then
		echo "ERROR: $i/sieve.src wasn't compiled"
	    fi
	fi
    done
fi		

>>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.

I second that. The whole idea of Cyrus is to separate System users from
eMail users, so that a user doesn't need to get shell access just to be
able to handle his mail.

Regards,
Sven