In our environment we have a UCS-Slave server (IMAP, Postfix eg.), that is connected to the UCS-DC via VPN. Users used to login via IMAP or webinterface. Every now an then, users complain that they could not connect to that server, while the VPN connection isn’t active.
The DC slaves local LDAP is running, and every other daemon seems to be up, except replication fails (of course).
What daemons have to run on such a DC-slave, to make sure that users still can login, even if the VPN connection stalls?
well, that depends on which service they fail to log in with. You only said that they “cannot connect to that server”. What does that actually mean? Does e.g. Thunderbird show an error message? Can they not open the web interface in their browser? Is logging in to Windows what fails? What’s the actual error message?
In thunderbird it’s something like “Password is incorrect”. In OX GUI they just can’t see their mails in mail-module anymore. (I don’t want to force this szenario in productive environment, therefore I don’t have the exact error code.)
Afaik the authentification to the imap server is against the ldap, isn’t it?
okay, thanks. So the users can reach the server, but the server doesn’t seem to be able to reach its LDAP server, which I find somewhat strange. A DC Slave brings its own LDAP server just for situations such as the connection to the DC Master being unavailable. Therefore the applications on the DC Slave should be configured to contact the DC Slave itself.
There are several possibilities that come to mind:
The DNS settings require contacting the DC Master.
The IMAP server is configured to query LDAP server on the DC Master.
The firewall settings only allow connections to the LDAP server on the DC Slave via the VPN interface or something like that.
I consider 2 to be unlikely (BTW: did you install OX from the App Center, or is this a manual installation?).
Can you please verify that 1 isn’t the case? On your DC Slave /etc/resolv.conf should only include the IP of the DC Slave itself, not of the DC Master.
Please also verify that 3 isn’t the case. A starting point would be to disconnect the VPN and look through iptables -L -nv.
I don’t see any parts in cyrus’s configuration querying dcmaster
There are no specific firewall settings; except that the mandatory ports for the ucs-replication are open
we don’t have any NFS shares
and 6. Unfortunately it’s not a dovecot system ;( it’s a cyrus.
Having Cyrus here brings me to ask: what about cyrus-sasl? Because that is, what the imap users authenticate, isn’t it? I am asking this, because, stopping cyrus-sasl leads to the same error message.
oh, a Cyrus system? You should really migrate that to Dovecot. I seem to remember from the Univention summit a couple of weeks ago Univention announcing they’d drop support for Cyrus in the upcoming 4.3 release due in March. This may mean that you won’t even be able to upgrade existing systems with Cyrus to 4.3 (though don’t quote me on that — my memory of the exact wording in their announcement is somewhat fuzzy).
Back to the original problem. What’s the output of the following commands:
root@groupware:~# grep uri /etc/pam_ldap.conf
uri ldap://groupware.some.thing:7389
On cyrus, yes, I know! We’d really like get rid of it. There has been an issue migrating shared folders in our test environment, prevents us form dovecot-migration.
yeah, all of those files look OK to me (assuming that groupware.some.thing is your DC Slave).
The problem might be Kerberos in this case (via PAM: pam_krb5.so). What does the following show:
ucr search --brief '^kerberos'
grep -ri $(ucr get ldap/master) /etc
My guess is that /etc/krb5.conf is configured to connect to your DC Master. In order to have your local server provide Kerberos, you may have to install the "Active Directory compatible domain controllerand re-configure Kerberos to usegroupware.some.thing` as the KDC (via UCR variables).
So, it is not enough/possible to just set the ucr variable kerberos/kpasswdserver to groupware.some.thing? I am asking, because we still have a samba4 based NT4 Domain in our environment. Means, that we don’t have an active directory compatible domain controller.
Oink, that’s… Huh… Well… I actually cannot answer that as I don’t know how Kerberos works wrt. an NT-style domain. I highly suggest you migrate your setup to an AD domain — not just due to Kerberos, but also because the upcoming 4.3 release will drop support for NT-style domains, too, if I remember correctly. What’s stopping you, if I may ask?
I see. However, you won’t be able to keep using your NT-style domain indefinitely, and problems such as this one make it all the more urgent.
About your idmap issue: do the files have correct owners & groups at the moment? If so you could look into using getfacl before the migration for dumping the ACLs & owner information into a text file and using setfacl after the migration for restoring the owner. That might work as getfacl stores the user/group names instead of their numeric IDs. if the IDs change but the names stay stable during the migration, using the information from getfacl afterwards should work.
I actually cannot answer that as I don’t know how Kerberos works wrt. an NT-style domain. I highly suggest you migrate your setup to an AD domain — not just due to Kerberos, but also because the upcoming 4.3 release will drop support for NT-style domains, too, if I remember correctly. What’s stopping you, if I may ask?