On Mon, 2006-10-16 at 00:50 +0300, Timo Sirainen wrote:

On Mon, 2006-10-16 at 10:47 +1300, Fintec wrote:

...

Our server is an CentOS4.4 box and we use the atrpms built RPMs for installing dovecot. I am wanting to use the sieve plug-in so I've followed the dovecot wiki instructions, downloaded the files from CVS, but I'm not sure what configure options to use. When I try without any options I get:

dovecot-config not found from /usr/src/dovecot-sieve, use --with-dovecot=PATH to give path to compiled Dovecot sources

I tried using "./configure --with-dovecot=/usr/libexec/dovecot" but get the same problem.

You'll need to have Dovecot sources somewhere, and you must have run at least "configure" script for them. And preferrably you should also be running Dovecot installed from those sources, since if the binary package was built with different options the Sieve plugin might just crash..

Thanks for the quick reply Timo!

I thought this might be required but just thought I'd ask in case there was some clever way around it. I've successfully compiled and made the cmusieve plug-in - now I'm off to try it!

Will the cmusieve plug-in be included in the official 1.0 release and therefore the RPMs?

For future knowledge I took a look at the atrpms spec file and copied their configure options but I also had to run make in the dovecot sources before the required "dovecot-config" file was created.

Thanks, Gavin

On Mon, 2006-10-16 at 11:37 +1300, Fintec wrote:

On Mon, 2006-10-16 at 00:50 +0300, Timo Sirainen wrote:

...

On Mon, 2006-10-16 at 10:47 +1300, Fintec wrote:

...

Our server is an CentOS4.4 box and we use the atrpms built RPMs for installing dovecot. I am wanting to use the sieve plug-in so I've followed the dovecot wiki instructions, downloaded the files from CVS, but I'm not sure what configure options to use. When I try without any options I get:

dovecot-config not found from /usr/src/dovecot-sieve, use --with-dovecot=PATH to give path to compiled Dovecot sources

I tried using "./configure --with-dovecot=/usr/libexec/dovecot" but get the same problem.

You'll need to have Dovecot sources somewhere, and you must have run at least "configure" script for them. And preferrably you should also be running Dovecot installed from those sources, since if the binary package was built with different options the Sieve plugin might just crash..

Thanks for the quick reply Timo!

I thought this might be required but just thought I'd ask in case there was some clever way around it. I've successfully compiled and made the cmusieve plug-in - now I'm off to try it!

Will the cmusieve plug-in be included in the official 1.0 release and therefore the RPMs?

For future knowledge I took a look at the atrpms spec file and copied their configure options but I also had to run make in the dovecot sources before the required "dovecot-config" file was created.

Thanks, Gavin

Following on from this I have been unable to get the cmusieve plug-in working...

Process: protocol lda {

• compile, make, make install dovecot-sieve from cvs
• cp "sievec" & "sieved" to /usr/libexec/dovecot/
• cp lib90_cmusieve_plugin.a, .la & .so to /usr/lib64/dovecot/
• cd /usr/lib64/dovecot/lda
• ln -s ../lib90_cmusieve_plugin.a .
• Added plug-in info to dovecot.conf:

mail_plugins = cmusieve mail_plugin_dir = /usr/lib64/dovecot/lda }

• restarted dovecot

The trouble is that after adding a ".dovecot.sieve" file to a user home directory neither a .dovecot.sievec or .dovecot.sieve.err file is created and the sieve script doesn't work.

There doe not appear to be anything in the logs, how can I troubleshoot this problem?

Gavin

On Mon, 2006-10-16 at 03:21 +0300, Timo Sirainen wrote:

On Mon, 2006-10-16 at 13:08 +1300, Fintec wrote:

...

Process:

• compile, make, make install dovecot-sieve from cvs
• cp "sievec" & "sieved" to /usr/libexec/dovecot/
• cp lib90_cmusieve_plugin.a, .la & .so to /usr/lib64/dovecot/
• cd /usr/lib64/dovecot/lda
• ln -s ../lib90_cmusieve_plugin.a .

Here's the first problem. .a library is useless as a plugin and you might as well delete it. You'll need the .so file.

Sorry Timo, that was a typo on my part, I did create a symbolic link to lib90_cmusieve_plugin.so not .a.

...

• Added plug-in info to dovecot.conf: protocol lda { mail_plugins = cmusieve mail_plugin_dir = /usr/lib64/dovecot/lda }
• restarted dovecot

The trouble is that after adding a ".dovecot.sieve" file to a user home directory neither a .dovecot.sievec or .dovecot.sieve.err file is created and the sieve script doesn't work.

There doe not appear to be anything in the logs, how can I troubleshoot this problem?

This however tells that it doesn't even try to load the plugin. If it can't load it it writes about it to log and dies at startup. Unless you really used the .so file after all in the above step?

Anyway, try setting debug=yes inside the protocol lda {} and see what it writes to log.

After adding debug=yes inside the protocol lda {} all I get in the deliver.log is: ---- snip ----- deliver(user@domain.com): Info: Loading modules from directory: /usr/lib64/dovecot/lda deliver(user@domain.com): Info: Module loaded: /usr/lib64/dovecot/lda/lib90_cmusieve_plugin.so deliver(user@domain.com): Info: maildir: data=/home/vmail/domains/domain.com/user deliver(user@domain.com): Info: maildir: root=/home/vmail/domains/domain.com/user, index=/home/vmail/domains/domain.com/user, control=, inbox= ---- snip ----

There doesn't appear to be any errors in the above, where to from here?

Gavin

On 16.10.2006, at 4.10, Fintec wrote:

...

Anyway, try setting debug=yes inside the protocol lda {} and see
what it writes to log.

After adding debug=yes inside the protocol lda {} all I get in the deliver.log is: ---- snip ----- deliver(user@domain.com): Info: Loading modules from directory: /usr/lib64/dovecot/lda deliver(user@domain.com): Info: Module loaded: /usr/lib64/dovecot/lda/lib90_cmusieve_plugin.so deliver(user@domain.com): Info: maildir: data=/home/vmail/domains/domain.com/user deliver(user@domain.com): Info: maildir: root=/home/vmail/domains/domain.com/user, index=/home/vmail/domains/domain.com/user, control=, inbox= ---- snip ----

I added more debugging a while ago, so I guess you're using rc8 or
older? It would then show all the data that is received from userdb,
such as home directory.

My guess is that your userdb is returning wrong home directory.

On Tue, 2006-10-17 at 09:18 +1300, Fintec wrote:

On Mon, 2006-10-16 at 13:17 +0300, Timo Sirainen wrote:

...

On 16.10.2006, at 4.10, Fintec wrote:

...

...

Anyway, try setting debug=yes inside the protocol lda {} and see
what it writes to log.

After adding debug=yes inside the protocol lda {} all I get in the deliver.log is: ---- snip ----- deliver(user@domain.com): Info: Loading modules from directory: /usr/lib64/dovecot/lda deliver(user@domain.com): Info: Module loaded: /usr/lib64/dovecot/lda/lib90_cmusieve_plugin.so deliver(user@domain.com): Info: maildir: data=/home/vmail/domains/domain.com/user deliver(user@domain.com): Info: maildir: root=/home/vmail/domains/domain.com/user, index=/home/vmail/domains/domain.com/user, control=, inbox= ---- snip ----

I added more debugging a while ago, so I guess you're using rc8 or
older? It would then show all the data that is received from userdb,
such as home directory.

My guess is that your userdb is returning wrong home directory.

Yes, that's correct I was using RC8. I've update to RC10 now so the debug logging provides a lot more info. As expected dovecot is returning the wrong home directory for the user because of my virtual user LDAP setup.

In LDAP I have homeDirectory defined as "/home/vmail/domains" and mailbox defined as "domain.com/user". Hence be default_mail_env = maildir:/home/vmail/domains/%d/%n.

Deliver is working correctly, it is only the cmusieve plug-in that is not concatenating the homeDirectory and mailbox LDAP fields. Is there some way to correct this without changing my LDAP structure?

Gavin

The problem comes down to my dovecot-ldap.conf file. The home directory for a user can be defined in the user attributes, i.e: user_attrs = homeDirectory=home

Is there anyway to combine two ldap fields to define home? What I require is: user_attrs = homeDirectory/mailbox=home Where "homeDirectory" and "mailbox" are my LDAP field names.

I have tried using the homeDirectory/%d/%n but these variables only appear to work within user_filter.

Short of creating & defining a new combined field in my LDAP structure does anyone have any ideas as to how I could achieve the above?

Gavin

On Mon, Oct 16, 2006 at 12:50:48AM +0300, Timo Sirainen wrote:

On Mon, 2006-10-16 at 10:47 +1300, Fintec wrote:

...

Our server is an CentOS4.4 box and we use the atrpms built RPMs for installing dovecot. I am wanting to use the sieve plug-in so I've followed the dovecot wiki instructions, downloaded the files from CVS, but I'm not sure what configure options to use. When I try without any options I get:

dovecot-config not found from /usr/src/dovecot-sieve, use --with-dovecot=PATH to give path to compiled Dovecot sources

I tried using "./configure --with-dovecot=/usr/libexec/dovecot" but get the same problem.

You'll need to have Dovecot sources somewhere, and you must have run at least "configure" script for them. And preferrably you should also be running Dovecot installed from those sources, since if the binary package was built with different options the Sieve plugin might just crash..

There is already a request & patch to add that to the packages:

http://bugzilla.atrpms.net/show_bug.cgi?id=904

There are two paths:

a) Like the patch above, build both in one sweep b) Have the main dovecot tarball install files (headers, dovecot-config etc) for developing against dovecot.

The advantage of a) is that it can be done right away. The advantages of b) are longer-term: It decouples the builds of dovecot vs sieve, and thus allows to have a faster (or different) development cycle for sieve, e.g. a) implies rebuilding all dovecot packages for any change in the sieve sources.

And if another extension/plugin requires dovecot's development files and lives external to dovecot it will require the same handling making b) even more worth while.

There is also

c) Upstream (Timo) doesn't yet want to see dovecot-sieve distributed in packages because he considers it not ready yet and will merge the dovecot-sieve sources into dovecot proper when he things it's ready.

:)

Axel.Thimm at ATrpms.net

On Mon, Oct 16, 2006 at 12:57:50PM +1300, Fintec wrote:

On Mon, 2006-10-16 at 00:52 +0200, Axel Thimm wrote:

...

On Mon, Oct 16, 2006 at 12:50:48AM +0300, Timo Sirainen wrote:

...

On Mon, 2006-10-16 at 10:47 +1300, Fintec wrote:

...

Our server is an CentOS4.4 box and we use the atrpms built RPMs for installing dovecot. I am wanting to use the sieve plug-in so I've followed the dovecot wiki instructions, downloaded the files from CVS, but I'm not sure what configure options to use. When I try without any options I get:

dovecot-config not found from /usr/src/dovecot-sieve, use --with-dovecot=PATH to give path to compiled Dovecot sources

I tried using "./configure --with-dovecot=/usr/libexec/dovecot" but get the same problem.

You'll need to have Dovecot sources somewhere, and you must have run at least "configure" script for them. And preferrably you should also be running Dovecot installed from those sources, since if the binary package was built with different options the Sieve plugin might just crash..

There is already a request & patch to add that to the packages:

http://bugzilla.atrpms.net/show_bug.cgi?id=904

There are two paths:

a) Like the patch above, build both in one sweep b) Have the main dovecot tarball install files (headers, dovecot-config etc) for developing against dovecot.

The advantage of a) is that it can be done right away. The advantages of b) are longer-term: It decouples the builds of dovecot vs sieve, and thus allows to have a faster (or different) development cycle for sieve, e.g. a) implies rebuilding all dovecot packages for any change in the sieve sources.

And if another extension/plugin requires dovecot's development files and lives external to dovecot it will require the same handling making b) even more worth while.

There is also

c) Upstream (Timo) doesn't yet want to see dovecot-sieve distributed in packages because he considers it not ready yet and will merge the dovecot-sieve sources into dovecot proper when he things it's ready.

:)

I can see the advantages & disadvantages of both and my opinion is that option b) would be better for now. When Timo is happy that the cmuseive plug-in code is stable then it could be built automatically with dovecot.

I haven't been able to get the cmusieve plug-in working yet so I'm keen for either a) or b)! :)

Thanks go to Angel Marin

http://atrpms.net/name/dovecot-sieve/ http://bugzilla.atrpms.net/show_bug.cgi?id=904

-- Axel.Thimm at ATrpms.net