Re: [Dovecot] problems with shared mailboxes and other general issues

2010-06-11 Thread Timo Sirainen
On to, 2010-06-10 at 16:32 -0700, Tom Lieuallen wrote:
  Jun 09 15:57:53 IMAP(tom2): Info: acl: initializing backend with
  data: vfile Jun 09 15:57:53 IMAP(tom2): Info: acl: acl username =
  tom2 Jun 09 15:57:53 IMAP(tom2): Info: acl: owner = 1 Jun 09
  15:57:53 dovecot: Error: child 6000 (imap) killed with signal 11
  (core dumps disabled)

Maybe http://hg.dovecot.org/dovecot-2.0/rev/f37d19f1c0a3 fixes it.

 So, you'd recommend using maildir instead of mbox for shared mailboxes? 
   I don't understand how that would work if my default namespace is 
 using mbox.

Don't go mixing mboxes and maildirs, that'll just cause more trouble.




Re: [Dovecot] problems with shared mailboxes and other general issues

2010-06-10 Thread Tom Lieuallen



acl_shared_dict = file:/private/dovecot/var/etc/shared-mailboxes

The '../var/etc' directory is something like 755.  I have to create
the file first and make it 666.


That should work.


When it is updated, ownership  permissions are changed such that
the user giving acl permissions then owns the file and it's 600.


That shouldn't happen. It should preserve the original file
permissions. If the file doesn't exist, it should get parent
directory's permissions and use them. Wonder if the problem is the
parent dir's permissions?

It's of course also possible that there is a bug. It would speed
things up a bit if you could try this with latest v2.0 nightly
snapshot if it's still broken:
http://dovecot.org/nightly/dovecot-latest.tar.gz


I tried setting it back to 644 afterward, so other users could read
it, but they tried setting a lock in that dir as well.


Yes, lock files are created every time the file is updated (it's
recreated every time).


If users need to set locks, then the directory will need to be writable 
by everyone.



I tried this:

acl_shared_dict =
file:/private/dovecot/var/etc/shared-list/shared-mailboxes-%u


That just won't work (or at least do anything useful). Each user
would have his own file, and no one else would see it.


My second choice was to use sqlite for this acl_shared_dict, but,
even though I compiled dovecot with sqlite support and 'ldd' shows
that '../libexec/dict' is linked against sqlite libraries, when I
tried this config:

acl_shared_dict = sqlite:/private/dovecot/etc/acl-shared-dict.conf

I get this, and dovecot fails to start up.

EUnknown dict module: sqlite


Right. This is because typically all except file backend goes through
dict process, and you need to use proxy backend to do that. See for
example quota dict configuration.


I'll see if that helps.


On a related note, I thought I'd increase debugging to see if that
helped out any.  When I change 'mail_debug' to 'yes', as soon as I
issue the imap login command, it logs some stuff, then kicks me
out.

Jun 09 15:57:53 IMAP(tom2): Info: acl: initializing backend with
data: vfile Jun 09 15:57:53 IMAP(tom2): Info: acl: acl username =
tom2 Jun 09 15:57:53 IMAP(tom2): Info: acl: owner = 1 Jun 09
15:57:53 dovecot: Error: child 6000 (imap) killed with signal 11
(core dumps disabled)


Signal 11 means a crash. It's always a bug. A gdb backtrace would be
helpful in fixing it. See http://dovecot.org/bugreport.html


I'll see if I can generate a gdb backtrace.  I did figure out that this 
only happens when I have the 'mail_plugins = acl imap_acl' in the 
'protocol imap' section and only with mail_debug.  When that combination 
is not in play, I don't get the crash.



I have been frustrated by the shared namespace documentation.  I've
been through it again and again, but haven't found the answers I've
been looking for.


I guess it's not ideal yet, but I don't yet have any ideas how to
improve it. Maybe once you get it working, you could suggest
something?


I'll try.  I think the documentation makes perfect sense for those who 
have it working, but not for those fumbling in the dark :-)  I'll 
have to find my way out of this dark room before I can help illuminate 
it for anyone else. ;-)



namespace shared { location =
mbox:%%h/mail/shared:INDEX=%%h/mail/shared/.imap


Don't set the :INDEX directory that way. It probably won't break
anything, but it's confusing. Root level mailbox indexes share the
indexes with the originating user, but non-root level mailboxes are
added under shared/.imap/ directory rather than shared/sub/.imap/
directory.

Although .. the whole idea of using mail/shared here doesn't really
seem right. You want users to be able to share only mailboxes under
shared/ and show them as shared/user/.. without the additional
shared? I don't think I've tried that kind of a setup before. Maybe
it should work .. maybe it does work and isn't the problem. But try
removing that first and see if it's actually the cause of your
problem.

Also I'm not sure if I ever tried using mbox for shared mailboxes,
but I think it should work..


k.  I'm still trying to understand that; sorry.  Yes, I was thinking of 
separating out the shared folders into a subdirectory.  I was thinking 
that the folder would need special permissions so that others could 
write to it.  Perhaps maildir solves all of these issues.


So, you'd recommend using maildir instead of mbox for shared mailboxes? 
 I don't understand how that would work if my default namespace is 
using mbox.


Would I end up with yet another namespace for maildir use?  The person 
who is sharing the mailbox will need to access that shared mailbox 
somehow, and I assume *not* using the shared namespace, as it is their 
own mailbox.


So, would it be accessed as something like 'MAILDIR/mailfolder' by that 
user (assuming 'MAILDIR' is the namespace), and 
'shared/shareuser/mailfolder' by the others?


thank you

Tom Lieuallen


[Dovecot] problems with shared mailboxes and other general issues

2010-06-09 Thread Tom Lieuallen
I'm also having beginner's troubles with shared mailboxes with dovecot 
1.2.11.


I've used the TestInstallation instructions for connecting to the imap 
port via openssl and issuing the setacl/getacl commands.  Those appear 
to be fine.


I'm having real difficulty with the acl_shared_dict configuration.  I'd 
prefer to just use a flat file, as I don't anticipate using shared 
folders very frequently.  I don't need a database and would greatly 
prefer not to have a dependency on our database service.  So, with this 
setting:


acl_shared_dict = file:/private/dovecot/var/etc/shared-mailboxes

The '../var/etc' directory is something like 755.  I have to create the 
file first and make it 666.  When it is updated, ownership  permissions 
are changed such that the user giving acl permissions then owns the file 
and it's 600.  I tried setting it back to 644 afterward, so other users 
could read it, but they tried setting a lock in that dir as well.


I tried this:

acl_shared_dict = 
file:/private/dovecot/var/etc/shared-list/shared-mailboxes-%u


Then I made shared-list have '1777' permissions.  Permissions-wise, this 
will now work, including locks, but I'm guessing this is just plain 
wrong and I still can't verify access.


My second choice was to use sqlite for this acl_shared_dict, but, even 
though I compiled dovecot with sqlite support and 'ldd' shows that 
'../libexec/dict' is linked against sqlite libraries, when I tried this 
config:


acl_shared_dict = sqlite:/private/dovecot/etc/acl-shared-dict.conf

I get this, and dovecot fails to start up.

EUnknown dict module: sqlite


I question whether I can use sqlite for acl_shared_dict.

Furthermore, in this vein, I don't really know what the shared namespace 
should even look like.  I've been trying the imap commands LIST and 
MYRIGHTS to verify access, but there are simply no examples.  I'd rather 
expect this to work:


x myrights shared/fromuser/folder

but all I get is mailbox doesn't exist.  I know 'shared' is the 
namespace, but I just don't know how it should really be referred to.


Personally, I can live without the acl_shared_dict (from what I 
understand).  I don't need to see the shared path for subscription, I'd 
just manually add the folder path to the .subscriptions file for the 
handful of users that need it.  I just don't think it's working, though.


On a related note, I thought I'd increase debugging to see if that 
helped out any.  When I change 'mail_debug' to 'yes', as soon as I issue 
the imap login command, it logs some stuff, then kicks me out.


Jun 09 15:57:53 IMAP(tom2): Info: acl: initializing backend with data: vfile
Jun 09 15:57:53 IMAP(tom2): Info: acl: acl username = tom2
Jun 09 15:57:53 IMAP(tom2): Info: acl: owner = 1
Jun 09 15:57:53 dovecot: Error: child 6000 (imap) killed with signal 11 
(core dumps disabled)


I would assume this error is causing my problems, but for all I know, it 
could be a side-effect of verbose debugging -- to just terminate.  I see 
nothing about that in the docs, though.  imap works fine without verbose 
logging, so I'm baffled.


I have been frustrated by the shared namespace documentation.  I've been 
through it again and again, but haven't found the answers I've been 
looking for.


Here is the relevant configuration:


namespace shared {
   location = mbox:%%h/mail/shared:INDEX=%%h/mail/shared/.imap
   # everything else defaults
}

protocol imap {
  mail_plugins = quota imap_quota acl imap_acl
}

protocol lda {
  mail_plugins = acl
}

plugin {
 acl = vfile
 acl_shared_dict = 
file:/private/dovecot/var/etc/shared-list/shared-mailboxes-%u

}


Re: [Dovecot] problems with shared mailboxes and other general issues

2010-06-09 Thread Timo Sirainen
On 10.6.2010, at 1.16, Tom Lieuallen wrote:

 I'm having real difficulty with the acl_shared_dict configuration.  I'd 
 prefer to just use a flat file, as I don't anticipate using shared folders 
 very frequently.  I don't need a database and would greatly prefer not to 
 have a dependency on our database service.  So, with this setting:
 
 acl_shared_dict = file:/private/dovecot/var/etc/shared-mailboxes
 
 The '../var/etc' directory is something like 755.  I have to create the file 
 first and make it 666.

That should work.

 When it is updated, ownership  permissions are changed such that the user 
 giving acl permissions then owns the file and it's 600.

That shouldn't happen. It should preserve the original file permissions. If the 
file doesn't exist, it should get parent directory's permissions and use them. 
Wonder if the problem is the parent dir's permissions?

It's of course also possible that there is a bug. It would speed things up a 
bit if you could try this with latest v2.0 nightly snapshot if it's still 
broken: http://dovecot.org/nightly/dovecot-latest.tar.gz

 I tried setting it back to 644 afterward, so other users could read it, but 
 they tried setting a lock in that dir as well.

Yes, lock files are created every time the file is updated (it's recreated 
every time).

 I tried this:
 
 acl_shared_dict = 
 file:/private/dovecot/var/etc/shared-list/shared-mailboxes-%u

That just won't work (or at least do anything useful). Each user would have his 
own file, and no one else would see it.

 My second choice was to use sqlite for this acl_shared_dict, but, even though 
 I compiled dovecot with sqlite support and 'ldd' shows that '../libexec/dict' 
 is linked against sqlite libraries, when I tried this config:
 
 acl_shared_dict = sqlite:/private/dovecot/etc/acl-shared-dict.conf
 
 I get this, and dovecot fails to start up.
 
 EUnknown dict module: sqlite

Right. This is because typically all except file backend goes through dict 
process, and you need to use proxy backend to do that. See for example quota 
dict configuration.

 Furthermore, in this vein, I don't really know what the shared namespace 
 should even look like.  I've been trying the imap commands LIST and MYRIGHTS 
 to verify access, but there are simply no examples.  I'd rather expect this 
 to work:
 
 x myrights shared/fromuser/folder
 
 but all I get is mailbox doesn't exist.  I know 'shared' is the namespace, 
 but I just don't know how it should really be referred to.

That should work.. The important thing (in your setup that uses %h) is that 
fromuser's userdb lookup returns the expected home directory for the user. So 
the username should be the same as what the user logs in with.

 Personally, I can live without the acl_shared_dict (from what I understand).  
 I don't need to see the shared path for subscription, I'd just manually add 
 the folder path to the .subscriptions file for the handful of users that need 
 it.  I just don't think it's working, though.

That should work, yes.

 On a related note, I thought I'd increase debugging to see if that helped out 
 any.  When I change 'mail_debug' to 'yes', as soon as I issue the imap login 
 command, it logs some stuff, then kicks me out.
 
 Jun 09 15:57:53 IMAP(tom2): Info: acl: initializing backend with data: vfile
 Jun 09 15:57:53 IMAP(tom2): Info: acl: acl username = tom2
 Jun 09 15:57:53 IMAP(tom2): Info: acl: owner = 1
 Jun 09 15:57:53 dovecot: Error: child 6000 (imap) killed with signal 11 (core 
 dumps disabled)

Signal 11 means a crash. It's always a bug. A gdb backtrace would be helpful in 
fixing it. See http://dovecot.org/bugreport.html

 I have been frustrated by the shared namespace documentation.  I've been 
 through it again and again, but haven't found the answers I've been looking 
 for.

I guess it's not ideal yet, but I don't yet have any ideas how to improve it. 
Maybe once you get it working, you could suggest something?

 namespace shared {
   location = mbox:%%h/mail/shared:INDEX=%%h/mail/shared/.imap

Don't set the :INDEX directory that way. It probably won't break anything, but 
it's confusing. Root level mailbox indexes share the indexes with the 
originating user, but non-root level mailboxes are added under shared/.imap/ 
directory rather than shared/sub/.imap/ directory.

Although .. the whole idea of using mail/shared here doesn't really seem right. 
You want users to be able to share only mailboxes under shared/ and show them 
as shared/user/.. without the additional shared? I don't think I've tried that 
kind of a setup before. Maybe it should work .. maybe it does work and isn't 
the problem. But try removing that first and see if it's actually the cause of 
your problem.

Also I'm not sure if I ever tried using mbox for shared mailboxes, but I think 
it should work..