Kolab2 Server Troubleshooting - LDAP

From Kolab Wiki

Jump to: navigation, search
This page applies to Kolab 2.

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
Starting the server might echo [OK] even though the slapd process failed on startup.

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/
You can restart slurpd using
/etc/init.d/slurpd restart

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
and the run the server in debugging mode with
/usr/lib/openldap/slapd -u ldap -g ldap -h 'ldaps:// ldap://' -d 256

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
and kolabconf simply needs to be run without prefix like this
kolabconf

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.

coffre-fort ignifuge

Back

Back to the troubleshooting index Black And White Bedding Zebra Print Bedding Zebra Bedding Damask Bedding Purple Bedding Animal Print Bedding Beach Bedding

Personal tools