Murder trouble, 2 unified servers authenticating to each other
Michael Leupold
leupold at leunet.de
Sat May 13 20:29:11 EDT 2006
Hi,
I set up 2 servers (2.3.3) today to operate in a murder (both running
unified). They are called master.leunet.lan and slave.leunet.lan. mupdate
seems to be running fine so far, but if one imapd should proxy for the other
it won't work.
Here's what I did:
- created an inbox for a new user on master
- logged onto master using cyradm (authenticating as user)
- created a child mailbox INBOX/test
- logged onto slave using cyradm, checked for mailbox existance (both INBOX
and INBOX/test are there)
Then I issued a "cm INBOX/test2" and got:
createmailbox: Server(s) unavailable to complete operation
The slave imapd's log looks like this:
May 13 20:25:29 slave <error> imap[25582]: Doing a peer verify
May 13 20:25:29 slave <error> imap[25582]: Doing a peer verify
May 13 20:25:29 slave <debug> imap[25582]: received server certificate
May 13 20:25:29 slave <notice> imap[25582]: starttls: TLSv1 with cipher
AES256-SHA (256/256 bits new) no authentication
May 13 20:25:29 slave <notice> imap[25582]: No worthy mechs found
May 13 20:25:29 slave <error> imap[25582]: couldn't authenticate to backend
server: no mechanism available
May 13 20:30:03 slave <debug> imap[25621]: executed
May 13 20:30:03 slave <debug> imap[25621]: accepted connection
May 13 20:30:04 slave <notice> imap[25621]: login: localhost.localdomain
[127.0.0.1] manager plaintext User logged in
The master imapd's log looks like that:
May 14 03:28:44 master <debug> imap[19305]: executed
May 14 03:28:44 master <debug> imap[19305]: accepted connection
May 14 03:28:45 master <debug> imap[19305]: mystore: starting txn 2147483658
May 14 03:28:45 master <debug> imap[19305]: mystore: committing txn 2147483658
May 14 03:28:45 master <notice> imap[19305]: starttls: TLSv1 with cipher
AES256-SHA (256/256 bits new) no authentication
I'm using self-signed certificates and after fiddling a while I entered the ca
certificate into the configuration using tls_ca_file, but actually that
changed nothing. I'm not even sure the problem I have is related to TLS.
I'd really appreciate if someone who knows what's going on could please take a
look at my configuration. Maybe the problem's obvious, but I'm at my wits
end.
Here's goes my configuration.
--------------------------- master ---------------------------
configdirectory: /kolab/var/imapd
partition-default: /kolab/var/imapd/spool
allowusermoves: 0
admins: manager
sasl_pwcheck_method: saslauthd
sasl_mech_list: plain login
sendmail: /kolab/sbin/sendmail
allowanonymouslogin: no
allowplaintext: yes
servername: master.leunet.lan
autocreatequota: 100000
reject8bit: no
munge8bit: no
quotawarn: 80
lmtp_over_quota_perm_failure: 1
timeout: 30
sievedir: /kolab/var/imapd/sieve
lmtpsocket: /kolab/var/kolab/lmtp
allowapop: no
tls_ca_file: /kolab/etc/kolab/cacert.pem
tls_ca_path: /kolab/etc/kolab
tls_cert_file: /kolab/etc/kolab/cert.pem
tls_key_file: /kolab/etc/kolab/key.pem
tls_cipher_list: ALL
sasl_minimum_layer: 0
altnamespace: 0
unixhierarchysep: yes
lmtp_downcase_rcpt: yes
username_tolower: 1
hashimapspool: yes
loginrealms: leunet.lan leunet.lan
ldap_uri: ldap://127.0.0.1:389
ldap_base: dc=leunet,dc=lan
ldap_bind_dn: cn=nobody,cn=internal,dc=leunet,dc=lan
ldap_password: aO0TcJiuIHEu445AFo0HAyivgjosyWxSq+dxgkgE
ldap_time_limit: 15
virtdomains: ldap
mupdate_config: unified
mupdate_server: master.leunet.lan
mupdate_port: 3905
mupdate_authname: manager
mupdate_password: MYPASS
proxyservers: manager
proxy_authname: manager
proxy_passwd: MYPASS
proxy_realm: leunet.lan
postuser: kolab
userprefix: user
sharedprefix: shared
--------------------------- master ---------------------------
--------------------------- slave ---------------------------
configdirectory: /kolab/var/imapd
partition-default: /kolab/var/imapd/spool
allowusermoves: 0
admins: manager
sasl_pwcheck_method: saslauthd
sasl_mech_list: plain login
sendmail: /kolab/sbin/sendmail
allowanonymouslogin: no
allowplaintext: yes
servername: slave.leunet.lan
autocreatequota: 100000
reject8bit: no
munge8bit: no
quotawarn: 80
lmtp_over_quota_perm_failure: 1
timeout: 30
sievedir: /kolab/var/imapd/sieve
lmtpsocket: /kolab/var/kolab/lmtp
allowapop: no
tls_ca_path: /kolab/etc/kolab
tls_ca_file: /kolab/etc/kolab/cacert.pem
tls_cert_file: /kolab/etc/kolab/cert.pem
tls_key_file: /kolab/etc/kolab/key.pem
tls_cipher_list: ALL
sasl_minimum_layer: 0
altnamespace: 0
unixhierarchysep: yes
lmtp_downcase_rcpt: yes
username_tolower: 1
hashimapspool: yes
loginrealms: leunet.lan leunet.lan
ldap_uri: ldap://127.0.0.1
ldap_base: dc=leunet,dc=lan
ldap_bind_dn: cn=nobody,cn=internal,dc=leunet,dc=lan
ldap_password: aO0TcJiuIHEu445AFo0HAyivgjosyWxSq+dxgkgE
ldap_time_limit: 15
virtdomains: ldap
mupdate_config: unified
mupdate_server: master.leunet.lan
mupdate_port: 3905
mupdate_authname: manager
mupdate_password: MYPASS
proxyservers: manager
proxy_authname: manager
proxy_passwd: MYPASS
proxy_realm: leunet.lan
mupdate_workers_max: 2
mupdate_workers_maxspare: 1
mupdate_workers_minspare: 0
mupdate_workers_start: 1
postuser: kolab
userprefix: user
sharedprefix: shared
--------------------------- slave ---------------------------
I also tried some other things that aren't in the config any longer, eg.
adding "master_passwd: MYPASS", adding "master_mechs: PLAIN" or removing the
proxy_realm from the slave's setup. Unfortunately I don't have the slightest
idea what's going on with the authentication.
btw, I know that putting manager as proxyuser and admin is probably not the
best idea, but this setup is only meant for evaluation. The mupdate server is
running on the master as well but it has its own config-directory and
partition.
I'd appreciate anything that could hint me into the right direction. :-)
Kind regards,
Michael
More information about the Info-cyrus
mailing list