Kolab 3.3

389 Directory Server

Schema Import

When populating the Kolab schema, the setup-kolab script tries to restart the 389-ds service which might fail as:

Setup is now going to set up the 389 Directory Server. This may take a little
while (during which period there is no output and no progress indication).
 * Stopping 389 Directory Server Admin (apache2) ...
 [ ok ]
 * Stopping 389 Directory Server: instance slapd-gentoo-kolab33 ...
 * start-stop-daemon: no matching processes found
 [ ok ]
 * Starting 389 Directory Server: instance slapd-gentoo-kolab33 ...
 * start-stop-daemon: failed to start `/usr/sbin/ns-slapd'
 [ !! ]
 * ERROR: 389-ds failed to start
Please supply a Cyrus Administrator password. This password is used by Kolab to
execute administrative tasks in Cyrus IMAP. You may also need the password
yourself to troubleshoot Cyrus IMAP and/or perform other administrative tasks
against Cyrus IMAP directly.
Cyrus Administrator password [EIV4X7hnCl_fxFp]: 

Before you proceed, make sure that the 389-ds service was properly restarted in order to make the newly added Kolab schemas take effect:

$ killall ns-slapd
$ /etc/init.d/389-ds restart
 * Starting 389 Directory Server: instance slapd-your-fqdn ...                                                              [ ok ]

If the Kolab3 schemas are not in use, you might get error similar to this:

Traceback (most recent call last):
  File "/usr/sbin/setup-kolab", line 42, in <module>
  File "/usr/lib/python2.7/dist-packages/pykolab/setup/__init__.py", line 43, in run
  File "/usr/lib/python2.7/dist-packages/pykolab/setup/components.py", line 170, in execute
  File "/usr/lib/python2.7/dist-packages/pykolab/setup/components.py", line 202, in execute
    components[component_name]['function'](conf.cli_args, kw)
  File "/usr/lib/python2.7/dist-packages/pykolab/setup/setup_ldap.py", line 670, in execute
    auth._auth.ldap.modify_s(dn, modlist)
  File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 357, in modify_s
    return self.result(msgid,all=1,timeout=self.timeout)
  File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 458, in result
    resp_type, resp_data, resp_msgid = self.result2(msgid,all,timeout)
  File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 462, in result2
    resp_type, resp_data, resp_msgid, resp_ctrls = self.result3(msgid,all,timeout)
  File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 469, in result3
  File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 476, in result4
    ldap_result = self._ldap_call(self._l.result4,msgid,all,timeout,add_ctrls,add_intermediates,add_extop)
  File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 99, in _ldap_call
    result = func(*args,**kwargs)
ldap.INVALID_SYNTAX: {'info': 'targetattr "kolabDelegate" does not exist in schema. Please add attributeTypes "kolabDelegate" to schema if necessary. ACL Syntax Error(-5):(targetattr = \\22carLicense || description || displayName || facsimileTelephoneNumber || homePhone || homePostalAddress || initials || jpegPhoto || l || labeledURI || mobile || o || pager || photo || postOfficeBox || postalAddress || postalCode || preferredDeliveryMethod || preferredLanguage || registeredAddress || roomNumber || secretary || seeAlso || st || street || telephoneNumber || telexNumber || title || userCertificate || userPassword || userSMIMECertificate || x500UniqueIdentifier || kolabDelegate || kolabInvitationPolicy || kolabAllowSMTPSender\\22) (version 3.0; acl \\22Enable self write for common attributes\\22; allow (read,compare,search,write)(userdn = \\22ldap:///self\\22);)\n', 'desc': 'Invalid syntax'}

Directory Server Setup

If the setup-kolab fail during setting up the 389 directory server for any reason, you might want to manually run setup-ds-admin.pl using the ini-file created by setup-kolab in /tmp (consult the logfile for the correct filename):

$ setup-ds-admin.pl --debug --silent --file=/tmp/tmpdOJFuU

Now you can re-try setup-kolab but skip the LDAP part:

$ setup-kolab --without-ldap

SSL Issues

If you use SSL, some Kolab API calls from within PHP using Pear::HTTP2_Request might fail because PHP doesn't know about your SSL CA certificates. By adding the following Roundcube option, it will be passed to HTTP2_Request configuration and SSL works also for the API requests with ssl_verify_pear enabled:

// ...
$config["kolab_http_request"] = array("ssl_capath" => "/etc/ssl/certs/");
// ...

PHP's lack of SSL default values seem's to be a known issue but just nobody cares about: https://bugs.php.net/bug.php?id=62050