murder and cross-backend mailbox sharing

2009-06-09 Thread Paolo Cravero
Hi.
I have a setup with 1 frontend, 1 murder, 2 backends. I am playing with 
cross-backend mailbox sharing, one of the features we value most.

Problem. While I can access shared mailboxes that reside on the same backend 
just fine, with Thunderbird (1.5/linux) I can see shared folders on other 
backends, but when I subscribe nothing is subscribed.

Thunderbird always connects to the frontend machine. All cyrus servers have 
the same Invoca RPMs (v2.3.14-Invoca-RPM-2.3.14-2). Authentication via PAM 
LDAP, if that matters.

I use virtdomains but all accounts are under the same @domain . ACL are 
anyone lrs.

Summarizing: I can access shared mailboxes on the same backend, but on 
different backends they cannot be subscribed,

Something I should look for?

TIA,
Paolo

Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html


Re: murder and cross-backend mailbox sharing

2009-06-09 Thread Michael Menge

Hi,

Quoting Paolo Cravero pcrav...@as2594.net:


Hi.
I have a setup with 1 frontend, 1 murder, 2 backends. I am playing with
cross-backend mailbox sharing, one of the features we value most.

Problem. While I can access shared mailboxes that reside on the same backend
just fine, with Thunderbird (1.5/linux) I can see shared folders on other
backends, but when I subscribe nothing is subscribed.



The subscibtion is managed on the backend of the user. Cyrus checks if the
Folder you whant to subscrib exists. This Check is done only on the backend.

You have to use allowallsubscribe: 1


Allow subscription to nonexistent mailboxes.  This option is typi-
cally  used  on backend servers in a Murder so that users can sub-
scribe to mailboxes that don't  reside  on  their  home  server.
This  option  can  also  be  used as a workaround for IMAP clients
which don't play well with nonexistent or  unselectable  mailboxes
(eg.  Microsoft Outlook).





M.MengeTel.: (49) 7071/29-70316
Universität Tübingen   Fax.: (49) 7071/29-5912
Zentrum für Datenverarbeitung  mail:  
michael.me...@zdv.uni-tuebingen.de

Wächterstraße 76
72074 Tübingen

smime.p7s
Description: S/MIME krytographische Unterschrift

Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html

Re: murder and cross-backend mailbox sharing

2009-06-09 Thread Simon Matter
 Hi.
 I have a setup with 1 frontend, 1 murder, 2 backends. I am playing with
 cross-backend mailbox sharing, one of the features we value most.

 Problem. While I can access shared mailboxes that reside on the same
 backend
 just fine, with Thunderbird (1.5/linux) I can see shared folders on other
 backends, but when I subscribe nothing is subscribed.

 Thunderbird always connects to the frontend machine. All cyrus servers
 have
 the same Invoca RPMs (v2.3.14-Invoca-RPM-2.3.14-2). Authentication via PAM
 LDAP, if that matters.

 I use virtdomains but all accounts are under the same @domain . ACL are
 anyone lrs.

I'm not sure it's related but you really should upgrade to the 2.3.14-6
package. 2.3.14 has a bug which is patched in the 2.3.14-6 RPM.

Regards,
Simon



Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html


Re: murder and cross-backend mailbox sharing

2009-06-09 Thread Paolo Cravero
Simon Matter wrote:

 I'm not sure it's related but you really should upgrade to the 2.3.14-6
 package. 2.3.14 has a bug which is patched in the 2.3.14-6 RPM.

Thank you Simon. I'm in the staging phase, so still looking for features 
rather than bugs :) BTW, thank you for providing those wonderful RPMs.

Anyway Michael pointed out the missing configuration parameter. Now x-backend 
sharing works and I've also seen in the log why autocreate and murder don't 
work well together. Will post a reply in the proper thread I opened on June 5th.

Paolo


Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html


Re: Migrate from 2.2. to 2.3 with ldap

2009-06-09 Thread Marc Patermann
Hi,

Marc Patermann schrieb:

 I'm a bit stuck. I want to migrate from 2.2.12 to a recent 2.3.x server.
Does no one use 2.3 with ldap and can point in the right direction?

 Do I not need any ptloader for ldap anymore?
If I not wrong, cyrus 2.3 complains about not being able to connect to 
ptloader, so it seems to be necessary ...


Marc

Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html


Re: Migrate from 2.2. to 2.3 with ldap

2009-06-09 Thread Michael Menge

Hi,

Quoting Marc Patermann hans.mo...@ofd-sth.niedersachsen.de:


Hi,

Marc Patermann schrieb:


I'm a bit stuck. I want to migrate from 2.2.12 to a recent 2.3.x server.

Does no one use 2.3 with ldap and can point in the right direction?



We use Cyrus 2.3 with pam mand pam_ldap, if you don't need
support for group permissions, this works fine without ptloader.

As we don't use group permissions i don't know if this is possible  
without ptloader, or how to make it work.



Do I not need any ptloader for ldap anymore?

If I not wrong, cyrus 2.3 complains about not being able to connect to
ptloader, so it seems to be necessary ...


Marc

Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html






M.MengeTel.: (49) 7071/29-70316
Universität Tübingen   Fax.: (49) 7071/29-5912
Zentrum für Datenverarbeitung  mail:  
michael.me...@zdv.uni-tuebingen.de

Wächterstraße 76
72074 Tübingen

smime.p7s
Description: S/MIME krytographische Unterschrift

Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html

Re: murder and autocreate (I know it is not supported)

2009-06-09 Thread Duncan Gibb
Paolo Cravero wrote:

PC I have read in the docs that the autocreate patch does not work
PC with murder, and I have experienced it too. But...

PC ... if I leave the autocreate ON on backends only, and then
PC simulate an IMAP access or mail delivery right at the backend
PC level, I should not get into troubles, right?

You might be interested in the attached patch, which is something I
cooked up last year for our internal Cyrus builds.  It's a fairly dirty
hack to provide frontends with a way to decide which backend should they
go to for a mailbox that doesn't yet exist.

The basic idea is to catch lookups by proxyd and lmtpproxyd which would
normally return IMAP_MAILBOX_NONEXISTENT and call out to an
administrator-defined helper script (roughly modelled on the way Squid
auth helpers work) which decides whether and where to assume the mailbox
should exist.  Then normal auto* on the backends kicks in...

There are many ways in which this could be improved.  Most obviously
admins shouldn't be required to maintain the helper script across all
the FEs - the decision logic should be at a central location such as the
MUPDATE host.

And it would be good to extend the information passed to the helper (eg
authenticated sender info in the LMTP case), and back (eg a way to set
mailbox ACLs or other config).  The latter would require much better
integration with the UoA patches.  The protocol spoken between the Cyrus
components and the helper app should resemble some sane IMAP-related one...

Ideas and improvements welcome ;-)


Cheers


Duncan

-- 
Duncan Gibb - Technical Director
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk/
t: +44 870 608 0063 ||  m: +44 7977 441 515

#! /bin/sh /usr/share/dpatch/dpatch-run
## 95-automurder-frontend.dpatch by Duncan Gibb duncan.g...@siriusit.co.uk
##
## All lines beginning with `## DP:' are a description of the patch.
## DP: Run a helper application on frontends which can decide whether to 
## DP: pretend mailboxes exist on a backend - and if so on which - in order to 
## DP: trigger autocreate

@DPATCH@

diff -Nrub --exclude '*svn*' --exclude '*~' --exclude debian 
reference/imap/automurder.c editing/imap/automurder.c
--- reference/imap/automurder.c 1970-01-01 01:00:00.0 +0100
+++ editing/imap/automurder.c   2009-05-10 10:01:09.0 +0100
@@ -0,0 +1,259 @@
+/* automurder.c
+ *
+ * Use an external helper to decide which backend should
+ * to assume a non-existant mailbox onto.
+ *
+ * Copyright 2008 Duncan Gibb, Sirius Corporation plc
+ */
+
+#include config.h
+
+#include stdio.h
+#include stdlib.h
+#include string.h
+#include syslog.h
+#include sys/time.h
+#include signal.h
+#include errno.h
+
+#include automurder.h
+#include imap_err.h
+#include libconfig.h
+#include mboxlist.h
+#include xmalloc.h
+
+#define BUFSIZE MAX_MAILBOX_NAME+2
+
+void spawn_helper(void);
+void shutdown_helper(void);
+void fault(void);
+
+static int helper_pid = 0;
+static int qfd, afd;
+static int respawn_count;
+static int fault_count;
+
+static char automurder_last_refused_mbox[BUFSIZE];
+
+void automurder_init(void)
+{
+respawn_count = 0;
+automurder_last_refused_mbox[0] = '\0';
+
+if(config_getswitch(IMAPOPT_AUTOMURDER_HELPER_PREFORK)) {
+spawn_helper();
+}
+}
+
+void automurder_shutdown(void)
+{
+shutdown_helper();
+}
+
+void fault(void)
+{
+if( ++fault_count  
config_getint(IMAPOPT_AUTOMURDER_HELPER_FAULT_TOLLERANCE) ) {
+   syslog(LOG_ERR, automurder helper fault tollerance reached.  
Respawning helper.);
+   shutdown_helper();
+   spawn_helper();
+}
+}
+
+void spawn_helper(void)
+{
+int helper_stdin;
+int helper_stdout;
+int mypipe[2];
+
+if(!config_getswitch(IMAPOPT_AUTOMURDER_FRONTEND))
+   return;
+
+if(!config_getstring(IMAPOPT_AUTOMURDER_HELPER)) {
+   syslog(LOG_ERR, automurder_frontend enabled without configuring helper 
application);
+   return;
+}
+
+if(respawn_count++  config_getint(IMAPOPT_AUTOMURDER_HELPER_MAXRESPAWN)) {
+   return;
+} else if(respawn_count == 
config_getint(IMAPOPT_AUTOMURDER_HELPER_MAXRESPAWN)) {
+   syslog(LOG_ERR, automurder_helper_maxrespawn reached.);
+   return;
+}
+
+if(pipe (mypipe)) {
+   syslog(LOG_ERR, Could not create question pipe for automurder 
helper.);
+   return;
+}
+
+helper_stdin = mypipe[0];
+qfd = mypipe[1];
+
+if(pipe (mypipe)) {
+   syslog(LOG_ERR, Could not create answer pipe for automurder helper.);
+   return;
+}
+
+afd = mypipe[0];
+helper_stdout = mypipe[1];
+
+fcntl( afd, F_SETFL, O_NONBLOCK );
+
+fault_count = 0;
+
+helper_pid=fork();
+
+if(helper_pid == -1) {
+   syslog(LOG_ERR, Could not fork to create automurder helper.);
+   return;
+}
+
+if(helper_pid == 0) {
+   const char *av = NULL;
+   const char *env = NULL;
+
+   dup2( helper_stdin, 0 );
+   dup2( helper_stdout, 1 );
+
+   

Re: murder and autocreate (I know it is not supported)

2009-06-09 Thread Dave McMurtrie
Duncan Gibb wrote:
 Paolo Cravero wrote:
 
 PC I have read in the docs that the autocreate patch does not work
 PC with murder, and I have experienced it too. But...
 
 PC ... if I leave the autocreate ON on backends only, and then
 PC simulate an IMAP access or mail delivery right at the backend
 PC level, I should not get into troubles, right?
 
 You might be interested in the attached patch, which is something I
 cooked up last year for our internal Cyrus builds.  It's a fairly dirty
 hack to provide frontends with a way to decide which backend should they
 go to for a mailbox that doesn't yet exist.

Ken is actually working on some code now that will integrate this 
functionality into Cyrus.  I'm short on details right now (exactly how 
it will work and exactly when it will be done) but I thought it would 
interest you to know that it's being worked on.

Thanks,

Dave
-- 
Dave McMurtrie, SPE
Email Systems Team Leader
Carnegie Mellon University,
Computing Services

Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html


Re: murder and autocreate (I know it is not supported)

2009-06-09 Thread Duncan Gibb
Dave McMurtrie wrote:

DMcM Ken is actually working on some code now that will integrate
DMcM this functionality into Cyrus.  I'm short on details right now
DMcM (exactly how it will work and exactly when it will be done)

I don't think you're allowed to specify both of those ;-)

DMcM but I thought it would interest you to know that it's being
DMcM worked on.

Definitely.  Anything that anyone else could contribute to?  Top of our
list obviously is arbitrary LDAP-based decision making (which we've done
by outsourcing to perl).  Setting ACLs at create time would come next,
and might still get implemented in our patch.

Cheers


Duncan

-- 
Duncan Gibb - Technical Director
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk/ || t: +44 870 608 0063
Debian Cyrus Team - https://alioth.debian.org/projects/pkg-cyrus-imapd/

Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html


libsasl2

2009-06-09 Thread Stephane Kenn
I keep seeing this message in my logs:
Could not find a dlname line in .la file: libsasl2.la
Running FreeBSD 7.2, perl 5-10 and cyrus-sasl 2.1.23, cyrus-imap 2.3.12.
I see the file in /usr/local/lib and here are its content:

# libsasl2.la - a libtool library file
# Generated by ltmain.sh - GNU libtool 1.3.5 (1.385.2.206 2000/05/27 11:12:27)
#
# Please DO NOT delete this file!
# It is necessary for linking the library.

# The name that we can dlopen(3).
dlname=''

# Names of this library.
library_names='libsasl2.so.2.23 libsasl2.so.2.23'

# The name of the static archive.
old_library=''

# Libraries that this one depends upon.
dependency_libs=''

# Version information for libsasl2.
current=2
age=0
revision=23

# Is this an already installed library?
installed=no

# Directory that this library needs to be installed in:
libdir='/usr/local/lib'


This message was sent using IMP, the Internet Messaging Program.



Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html


Re: murder and autocreate (I know it is not supported)

2009-06-09 Thread Bron Gondwana
On Tue, Jun 09, 2009 at 06:30:31PM +0100, Duncan Gibb wrote:
 Dave McMurtrie wrote:
 
 DMcM Ken is actually working on some code now that will integrate
 DMcM this functionality into Cyrus.  I'm short on details right now
 DMcM (exactly how it will work and exactly when it will be done)
 
 I don't think you're allowed to specify both of those ;-)

No, no, you are.  You're just not allowed to specify how 
_correctly_ it will work at the same time :)

Bron ( for some definition of done )

Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html


Re: sasl_pwcheck_method

2009-06-09 Thread Greg A. Woods
At Tue, 09 Jun 2009 01:19:49 +0200, li...@oliver-block.eu wrote:
Subject: Re: Re: sasl_pwcheck_method
 
  Dan White schrieb:
   When authenticating via CRAM-MD5, the pwcheck_method will be ignored. 
   Your chosen pwcheck_method should only be referenced when 
   authenticating 
   via a 'plaintext' authentication mechanism - LOGIN or PLAIN.
 
 Good to know. I must have omitted this part of the manual.:-)
 
 
   The fact 
   that mtest attempted to authenticate via CRAM-MD5 probably means that 
   you are advertising CRAM-MD5 support within imapd.conf.
 
 Actually cyrus seems to do that by his own!? Adding sasl_mech_list: PLAIN 
 LOGIN to imapd.conf stops advertising it.


I've had the following in my template imapd.conf file for years now:

# Use these SASL authentication mechanisms.
#
# Don't use CRAM-MD5 or DIGEST-MD5 if you don't have a local sasldb
# and you start saslauthd with -a getpwent
#
# Don't use OTP or ANONYMOUS unless you really need them -- it causes some
# clients to prefer it, such as cyradm.
#
# Don't put PLAIN before LOGIN -- it buggers Mozilla.
#
sasl_mech_list: LOGIN PLAIN


I'm not sure why Mozilla was confused, or whether current versions would
still be confused, but suffice it to say that no current clients I've
encountered in relatively large user populations have had problems with
the order being LOGIN PLAIN.


-- 
Greg A. Woods

+1 416 218-0098VE3TCP  RoboHack wo...@robohack.ca
Planix, Inc. wo...@planix.com  Secrets of the Weird wo...@weird.com

Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html