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