Kolab 3.0 first experience

Dirk Werner dwerner at curiousbits.de
Fri Aug 17 19:45:18 CEST 2012


On 08/17/2012 06:36 PM, Jeroen van Meeuwen wrote:
> On Friday, August 17, 2012 10:45:25 AM Dirk Werner wrote:
>> Hi,
>> since one user has changed the view in the settings panel of
>> roundcubemail, it's not possible anymore to login - the message shown is
>> 'Connection to storage server failed'.
>>
>> The /var/log/kolab/pykolab.log last lines:
>>
>> 2012-08-17 10:05:08,351 pykolab.conf WARNING Option imap/virtual_domains
>> does not exist in config file /etc/kolab/kolab.conf, pulling from defaults
>> 2012-08-17 10:05:11,086 pykolab.conf WARNING Option imap/virtual_domains
>> does not exist in config file /etc/kolab/kolab.conf, pulling from defaults
>> 2012-08-17 10:07:58,149 pykolab.imap WARNING Could not connect to Cyrus
>> IMAP server 'imaps://localhost:993'
>>
>> netstat -anp | grep 993 shows that imaps is running:
>>
>> tcp        0      0 0.0.0.0:993
>> 0.0.0.0:*                   LISTEN      -
>> tcp        0      0 :::993
>>
>> :::*                        LISTEN      -
>>
> But can you connect?
>
> Try using imtest - see imtest --help for options.
>
> For IMAP over port 143 with TLS:
>
> $ imtest -t "" -u cyrus-admin -a cyrus-admin -w $password localhost
Output of
$imtest -t "" -u cyrus-admin -a cyrus-admin -w $password localhost :

S: * OK [CAPABILITY IMAP4rev1 LITERAL+ ID ENABLE STARTTLS LOGINDISABLED]
remote.airwerk.net Cyrus IMAP v2.4.16-Kolab-2.4.16-1.el6.kolab_3.0
server ready
C: S01 STARTTLS
S: S01 OK Begin TLS negotiation now
verify error:num=18:self signed certificate
TLS connection established: TLSv1 with cipher DHE-RSA-AES256-SHA
(256/256 bits)
C: C01 CAPABILITY
S: * CAPABILITY IMAP4rev1 LITERAL+ ID ENABLE ACL RIGHTS=kxte QUOTA
MAILBOX-REFERRALS NAMESPACE UIDPLUS NO_ATOMIC_RENAME UNSELECT CHILDREN
MULTIAPPEND BINARY CATENATE CONDSTORE ESEARCH SORT SORT=MODSEQ
SORT=DISPLAY THREAD=ORDEREDSUBJECT THREAD=REFERENCES ANNOTATEMORE
LIST-EXTENDED WITHIN QRESYNC SCAN XLIST URLAUTH URLAUTH=BINARY
X-NETSCAPE AUTH=PLAIN AUTH=LOGIN SASL-IR IDLE
S: C01 OK Completed
C: A01 AUTHENTICATE PLAIN Y3lydXMtYWRtaW4AY3lydXMtYWRtaW4AYWlyYWRtNjM=
S: A01 OK [CAPABILITY IMAP4rev1 LITERAL+ ID ENABLE ACL RIGHTS=kxte QUOTA
MAILBOX-REFERRALS NAMESPACE UIDPLUS NO_ATOMIC_RENAME UNSELECT CHILDREN
MULTIAPPEND BINARY CATENATE CONDSTORE ESEARCH SORT SORT=MODSEQ
SORT=DISPLAY THREAD=ORDEREDSUBJECT THREAD=REFERENCES ANNOTATEMORE
LIST-EXTENDED WITHIN QRESYNC SCAN XLIST URLAUTH URLAUTH=BINARY
X-NETSCAPE LOGINDISABLED IDLE] Success (tls protection)
SESSIONID=<remote.airwerk.net-2820-1345225236-1>
Authenticated.
Security strength factor: 256
>
> For IMAP over port 993 with SSL:
>
> $ imtest -s -u cyrus-admin -a cyrus-admin -w $password localhost
Output of
$imtest -s -u cyrus-admin -a cyrus-admin -w $password localhost :

verify error:num=18:self signed certificate
TLS connection established: TLSv1 with cipher DHE-RSA-AES256-SHA
(256/256 bits)
S: * OK [CAPABILITY IMAP4rev1 LITERAL+ ID ENABLE AUTH=PLAIN AUTH=LOGIN
SASL-IR] remote.airwerk.net Cyrus IMAP
v2.4.16-Kolab-2.4.16-1.el6.kolab_3.0 server ready
C: A01 AUTHENTICATE PLAIN Y3lydXMtYWRtaW4AY3lydXMtYWRtaW4AYWlyYWRtNjM=
S: A01 OK [CAPABILITY IMAP4rev1 LITERAL+ ID ENABLE ACL RIGHTS=kxte QUOTA
MAILBOX-REFERRALS NAMESPACE UIDPLUS NO_ATOMIC_RENAME UNSELECT CHILDREN
MULTIAPPEND BINARY CATENATE CONDSTORE ESEARCH SORT SORT=MODSEQ
SORT=DISPLAY THREAD=ORDEREDSUBJECT THREAD=REFERENCES ANNOTATEMORE
LIST-EXTENDED WITHIN QRESYNC SCAN XLIST URLAUTH URLAUTH=BINARY
X-NETSCAPE LOGINDISABLED IDLE] Success (tls protection)
SESSIONID=<remote.airwerk.net-2311-1345225337-1>
Authenticated.
Security strength factor: 256
>
>> The /var/log/messages last lines:
>>
>> Aug 17 10:19:26 remote ntpd[1909]: synchronized to 213.239.204.119,
>> stratum 2
>> Aug 17 10:30:01 remote imaps[2764]: unable to open Berkeley db
>> /etc/sasldb2: No such file or directory
>> Aug 17 10:30:01 remote imaps[2764]: unable to open Berkeley db
>> /etc/sasldb2: No such file or directory
>>
> These are a Cyrus SASL upstream dlopen() issue, where the dlopen()'ing of the 
> relevant library apparently immediately attempts to open /etc/sasldb2 even 
> though it is not configured to do so. I believe they are caused by 
> /usr/lib64/libsasldb.so* and are actually supposed to be logged on the debug 
> level as well.




More information about the users mailing list