[Dovecot] symlink() failure in 1.2 managesieve

[Stephan Bosch]

Bruce A. Mallett schreef:
> I've been simultaneously learning about dovecot and experimenting with
> the 1.2.alpha4.  To start I built an rpm under CentOS 5.2 from:
>   dovecot-1.2.alpha4.tar.gz
>   dovecot-1.2-managesieve-0.11.2.tar.gz
>   dovecot-1.2.alpha4-managesieve-0.11.2.diff.gz
>   dovecot-1.2-sieve-0.1.2.tar.gz
> 
> and then setup with mysql to use virtual users.  Mail-wise, it all
> works.  :)
Good.

> Where I'm having trouble is with the managesieve part.  I find that when
> I activate a sieve script I get a symlink() failure message in
> /var/log/maillog similar to this:
> 
> Dec  2 05:12:47 hostname dovecot: MANAGESIEVE(account at hostname.com):
> sieve-storage: Creating symlink() hostname.com/account//.dovecot.sieve
> to /usr/local/virtual/hostname.com/account/sieve/Test.sieve failed: No
> such file or directory
The default path for the active symlink is ~/.dovecot.sieve, just like 
for the LDA sieve plugin. Judging from the above log error, your $HOME 
is set to 'hostname.com/account/', which is a relative path by itself 
(more on this below).

> I began to chase this first by inserting i_info() calls into various
> points of the managesieve build and later by attaching to the process
> with gdb.  I can see that in sieve_storage_script_activate() the
> storage->active_path member is incomplete (i.e., is not a full, absolute
> path name) and the cwd is "/tmp", thus the symlink() call fails.
Enabling mail_debug in the config file would have shown this without too 
much effort. If your problem persists, you should post this information.

> Based on what I've been reading in the documentation, shouldn't the
> system have resolved the "home" area for the mail to be the same as what
> is determined for the virtual user mail area?  Using the README in the
> alpha4 package I've found that I can get it to work by adding the
> following after the "protocol manageseive {}" section:
Given that the default path is ~/.dovecot.sieve, something is 
substituted all right, but it is not a full path.

> plugin {
>   sieve=/usr/local/virtual/%d/%n/.dovecot.sieve
>   sieve_storage=/usr/local/virtual/%d/%n/sieve
> }
Yes, this avoids the substitution of $HOME and therefore works. If  you 
would set mail_location to maildir:~/ it would probably present a error 
for your mail similar to the one reported for the ManageSieve symlink.

> While that helps, I'm a little confused as to why I need to do this.   I
> believe that the documentation states that the sieve defaults to
> .dovecot.sieve under the MAIL_LOCATION directory.  So it is not clear to
> me if I am doing something wrong, if there is an oversight in the
> software and/or documentation (or perhaps my reading of it), or is it
> really necessary to specify the same information multiple times?
No, only the sieve storage directory does that by default. The active 
symlink is stored in ~/ by default to match the behavior of the LDA 
Sieve plugin. If $HOME is not set correctly, this will not work. If 
$HOME is set correctly, you should be able to use ~/ in all paths 
(including mail_location) thus avoiding specifying the root of your mail 
store multiple times.

> -bash-3.2# grep -v '^ *\(#.*\)\?$' /etc/dovecot/dovecot-mysql.conf
> driver = mysql
> connect = host=/var/lib/mysql/mysql.sock dbname=postfix user=postfix
> password=postfix
> default_pass_scheme = MD5-CRYPT
> user_query = \
>   SELECT maildir as home, 150 AS uid, 12 AS gid FROM mailbox WHERE
> username = '%u'
> password_query = select password from mailbox where username='%u'
>  
Are you sure that the maildir column of the mailbox table contains fully 
specified paths to the user's home directories? That is the only thing I 
can imagine right now to be the cause of your problem. You use the 
maildir value directly as home, and if this value is a relative path you 
should prepend it with the part that is missing (by the looks of it 
'/usr/local/virtual' in your case). I do keep the option open that there 
is a bug somewhere, but please check this first.

I agree that the documentation needs work. I'll give it a look regarding 
your particular question.

Regards,

-- 
Stephan Bosch
stephan at rename-it.nl