Kolab2 Server Troubleshooting - LDAP
From Kolab Wiki
Contents |
Is the LDAP server running?
After starting the server with
/kolab/bin/openpkg rc openldap start
listing the open network sockets and searching for port 389
netstat -l -n -p | grep 389
should listen the active slapd process:
tcp 0 0 0.0.0.0:389 0.0.0.0:* LISTEN 25491/slapd
| Distribution specific information (This information might apply if you run Kolab natively on non-OpenPKG distributions) |
| Gentoo |
|---|
| The server needs to be started with /etc/init.d/slapd start |
Can you bind to the LDAP server?
After adding a user with the mail address newuser@mydomain.com, the password mypassword, the first name test and the last name test via the kolab webadmin, the following search should succeed if you execute it on the same machine that your LDAP server is running on (the LDAP directory is assumed to have the basedn of dc=mydomain,dc=com):
/kolab/bin/ldapsearch -b dc=mydomain,dc=com -s base -D 'cn=test test,dc=mydomain,dc=com' -h 127.0.0.1 -x -w 'mypassword'
# extended LDIF # # LDAPv3 # base <dc=mydomain,dc=com> with scope baseObject # filter: (objectclass=*) # requesting: ALL # # mydomain.com dn: dc=mydomain,dc=com dc: mydomain objectClass: top objectClass: domain # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1
If this fails there is something wrong with the LDAP setup.
| Distribution specific information (This information might apply if you run Kolab natively on non-OpenPKG distributions) |
| Gentoo |
|---|
| The ldapsearch command should be in your default path so you have to run the search command in the following way: ldapsearch -b dc=mydomain,dc=com -s base -D 'cn=test test,dc=mydomain,dc=com' -h 127.0.0.1 -x -w 'mypassword' |
Does the replication system work?
Once you add a new user to kolab by writing the entry to LDAP (either via the webadmin frontend or by any other means), this change should get propagated to the kolabd process. This happens via standard ldap replication. The slapd server informs slurpd about the new entry and slurpd is configured to connect to port 9999 for replicating entries. There will be a dummy replication listener on port 9999 that is controlled by the kolab server. This way the kolab server can automatically create the imap mailboxes once it is informed about the new LDAP entry. If this replication is broken the mailbox will be missing and you will not be able to log into the new account (at least not until you restart kolabd which would also trigger the mailbox creation).
In order to check if replaction works you can intercept the messages on port 9999 with tcpdump:
tcpdump -i lo port 9999
If you have tcpdump running and add a new user to LDAP you should see traffic shortly afterwards. If you don't, then something is wrong with slurpd.
Check if slurpd is running:
ps aux | grep slurpd root 8839 0.0 0.0 12692 1560 ? Ss 11:07 0:00 /kolab/libexec/openldap/slurpd
If everything looks ok but still nothing happens, you might need to clean out the /kolab/var/openldap/openldap-slurp/replica/ directory
rm -rf /kolab/var/openldap/openldap-slurp/replica/
and restart the openldap service
/kolab/bin/openpkg rc openldap restart
| Distribution specific information (This information might apply if you run Kolab natively on non-OpenPKG distributions) |
| Gentoo |
|---|
| The slurpd data directory lies at /var/lib/openldap-slurp/ |
Running the LDAP server in debugging mode
If everything else fails, you might wish to run the LDAP server with debugging enabled. Ensure that LDAP is not running:
/kolab/bin/openpkg rc openldap stop
Now you can start the server manually in debugging mode:
/kolab/libexec/openldap/slapd -h 'ldaps:// ldap://' -d 256
This should help you to identify the source of the problems.
| Distribution specific information (This information might apply if you run Kolab natively on non-OpenPKG distributions) |
| Gentoo |
|---|
| Stop the LDAP service using /etc/init.d/slapd stop |
Increasing the log output of the LDAP server
You can get the same amount of debugging output from the slapd process by increasing the loglevel in the slapd configuration. Add the following to the slapd.conf template at /kolab/etc/kolab/templates/slapd.conf.template (see man slapd.conf for details):
loglevel 255
Run
/kolab/sbin/kolabconf
after modifying the template to get the modifications written into /kolab/etc/openldap/slapd.conf. The LDAP specific log file can be found at /kolab/var/openldap/openldap.log
| Distribution specific information (This information might apply if you run Kolab natively on non-OpenPKG distributions) |
| Gentoo |
|---|
| The configuration template can be found at /etc/kolab/templates/slapd.conf.template |
Distribution specific hints
This information might apply if you run Kolab natively on non-OpenPKG distributions.
Gentoo
Data directory permissions
The ownership of the LDAP database files might not be ok. Check that the files in the /var/lib/openldap-data directory are owned by the ldap user:
ls -la /var/lib/openldap-data/ total 2155 drwx------ 2 ldap ldap 616 Jul 21 23:11 . drwxr-xr-x 19 root root 488 Jul 21 23:11 .. -rw-r--r-- 1 root root 0 Jul 21 23:11 .keep -rw-r--r-- 1 root root 95 Jul 21 23:11 .version-tag -rw-r----- 1 ldap ldap 425 Jul 21 18:13 DB_CONFIG -rw------- 1 ldap ldap 16384 Jul 21 18:12 __db.001 -rw------- 1 ldap ldap 278528 Jul 21 18:12 __db.002 -rw------- 1 ldap ldap 98304 Jul 21 18:12 __db.003 ...
If this is not the case, fix it with
chown -R ldap\: /var/lib/openldap-data
Sympthom refint
A slaptest gives you following:
overlay "refint" not found slaptest: bad configuration file!
The actual /etc/openldap/slapd.conf is wrong. Check it against /etc/kolab/templates/slapd.conf.template - if you are running an update do it manually.
Sympthom bdb version 4.3
A slaptest gives you following:
bdb(dc=XXX,dc=XXX): Program version 4.3 doesn't match environment version
openldap-2.3.35-r1 depends on db-4.2.* - emerge it. Apache-2.2.4-r11 depends on db-4.3.* so you need both versions installed (db is slotted).
Sympthom AuthnProviderAlias
/etc/init.d/apache start results in following output:
* Apache2 has detected a syntax error in your configuration files: Syntax error on line 23 of /etc/apache2/modules.d/000_kolab.conf: Invalid command '<AuthnProviderAlias', perhaps misspelled or defined by a module not included in the server configuration
The modul mod_authn_alias is missing. How to add this modul is written und the Upgrade instructions to 2.1.
Email Account is not being removed
You deleted an email account and you see that the kolabDeleteFlag is set but the account is not being removed.
Try the following:
/kolab/etc/rc kolabd stop
Login to cyradm an remove the account manually:
/kolab/bin/cyradm localhost -u manager
dm user/username@hostname.tld
/kolab/etc/rc kolabd start
My problem persists
None of the above hints did help you to solve your problem?
Please check your options for getting support and reporting problems.
Back
Back to the troubleshooting index
