See also bug 10139 (mga3). It may affect cauldron too. Mga4 is failing in a similar manner. It is missing a require on 389-ds and later gets stuck here.. Please supply a Kolab Service account password. This account is used by various services such as Postfix, and Roundcube, as anonymous binds to the LDAP server will not be allowed. Kolab Service password [0fKfT5AjF3hfYro]: It doesn't end in an error, just seems to gets stuck there. Uninstalling and removing lots of leftover directories and then reinstalling with 389-ds it then fails in the same way as mga3 does in bug 10139 comment 41 Please supply a Kolab Service account password. This account is used by various services such as Postfix, and Roundcube, as anonymous binds to the LDAP server will not be allowed. Kolab Service password [rMLO9CwCebd8JDF]: Traceback (most recent call last): File "/usr/sbin/setup-kolab", line 42, in <module> setup.run() File "/usr/lib/python2.7/site-packages/pykolab/setup/__init__.py", line 43, in run components.execute('_'.join(to_execute)) File "/usr/lib/python2.7/site-packages/pykolab/setup/components.py", line 170, in execute execute(component) File "/usr/lib/python2.7/site-packages/pykolab/setup/components.py", line 202, in execute components[component_name]['function'](conf.cli_args, kw) File "/usr/lib/python2.7/site-packages/pykolab/setup/setup_ldap.py", line 559, in execute auth._auth.ldap.modify_s(dn, modlist) File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 357, in modify_s return self.result(msgid,all=1,timeout=self.timeout) File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 458, in result resp_type, resp_data, resp_msgid = self.result2(msgid,all,timeout) File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 462, in result2 resp_type, resp_data, resp_msgid, resp_ctrls = self.result3(msgid,all,timeout) File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 469, in result3 resp_ctrl_classes=resp_ctrl_classes File "/usr/lib64/python2.7/site-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/lib64/python2.7/site-packages/ldap/ldapobject.py", line 99, in _ldap_call result = func(*args,**kwargs) ldap.INVALID_SYNTAX: {'info': 'targetattr "kolabAllowSMTPRecipient" does not exist in schema. Please add attributeTypes "kolabAllowSMTPRecipient" to schema if necessary. ACL Syntax Error(-5):(targetattr = \\22homePhone || preferredDeliveryMethod || jpegPhoto || postalAddress || carLicense || userPassword || mobile || kolabAllowSMTPRecipient || displayName || kolabDelegate || description || labeledURI || homePostalAddress || postOfficeBox || registeredAddress || postalCode || photo || title || street || kolabInvitationPolicy || pager || o || l || initials || kolabAllowSMTPSender || telephoneNumber || preferredLanguage || facsimileTelephoneNumber\\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'} Reproducible: Steps to Reproduce:
# urpme -a --auto-orphans 389-ds pykolab pykolab-telemetry pykolab-xml kolab-cli kolab-saslauthd kolab-server postfix-kolab wallace # rm -rf /var/lib/dirsrv/ # rm -rf /usr/share/kolab/ # rm -rf /usr/share/dirsrv/ # rm -rf /etc/sysconfig/dirsrv-mega # rm -rf /etc/kolab/ # rm -rf /etc/dirsrv/ /var/log/kolab/pykolab.log is empty /var/log/dirsrv/slapd-mega/errors shows.. [23/Sep/2014:16:35:30 +0100] - 389-Directory/1.3.2.22 B2014.226.1525 starting up [23/Sep/2014:16:35:30 +0100] - Db home directory is not set. Possibly nsslapd-directory (optionally nsslapd-db-home-directory) is missing in the config file. [23/Sep/2014:16:35:30 +0100] - I'm resizing my cache now...cache was 1658855424 and is now 8000000 [23/Sep/2014:16:35:31 +0100] - slapd started. Listening on All Interfaces port 389 for LDAP requests [23/Sep/2014:16:35:35 +0100] - slapd shutting down - signaling operation threads - op stack size 1 max work q size 1 max work q stack size 1 [23/Sep/2014:16:35:35 +0100] - slapd shutting down - waiting for 29 threads to terminate [23/Sep/2014:16:35:35 +0100] - slapd shutting down - closing down internal subsystems and plugins [23/Sep/2014:16:35:35 +0100] - Waiting for 4 database threads to stop [23/Sep/2014:16:35:35 +0100] - All database threads now stopped [23/Sep/2014:16:35:35 +0100] - slapd shutting down - freed 1 work q stack objects - freed 1 op stack objects [23/Sep/2014:16:35:35 +0100] - slapd stopped. [23/Sep/2014:16:35:36 +0100] - 389-Directory/1.3.2.22 B2014.226.1525 starting up [23/Sep/2014:16:35:36 +0100] - slapd started. Listening on All Interfaces port 389 for LDAP requests [23/Sep/2014:16:36:06 +0100] NSACLPlugin - __aclp__init_targetattr: targetattr "kolabAllowSMTPRecipient" does not exist in schema. Please add attributeTypes "kolabAllowSMTPRecipient" to schema if necessary. [23/Sep/2014:16:36:06 +0100] NSACLPlugin - ACL Syntax Error(-5):(targetattr = \22homePhone || preferredDeliveryMethod || jpegPhoto || postalAddress || carLicense || userPassword || mobile || kolabAllowSMTPRecipient || displayName || kolabDelegate || description || labeledURI || homePostalAddress || postOfficeBox || registeredAddress || postalCode || photo || title || street || kolabInvitationPolicy || pager || o || l || initials || kolabAllowSMTPSender || telephoneNumber || preferredLanguage || facsimileTelephoneNumber\22) (version 3.0;acl \22Enable self write for common attributes\22;allow (read,compare,search,write)(userdn = \22ldap:///self\22);) Appears to show a missing attribute in the schema for kolabAllowSMTPRecipient. This is the same error as mga3 also.
I will do a new install and test it. But be aware all e-mails you are getting are from my own kolab server, running on mga4.
You probably need to install it on a clean system then Thomas to see the issue. I assure you I'm not telling lies :P
Claire: I think you are making one BIG mistake. Before you start "setup-kolab" you first need to get yourself a full pot of coffee (or tea if you live in England). I wnet back on my VM to a virtual installation of mga4, did all upgrades and then added updates_testing to the sources. I then did urpmi kolab I then gave the box a FQDN (and rebooted) I then typed setup-kolab -d9 (d9=all possible debug information) I provided all answers to the questions and after completion, I used firefox and opened localhost/kolab-webadmin I then logged in and created users. No hickups at all. I am going to attached all outputs and screenshots of the WEB site. I replaced the password with "xxxxx" Thomas
Created attachment 5440 [details] Install kolab
Created attachment 5441 [details] setup the server
Created attachment 5442 [details] login screen
Created attachment 5443 [details] logged in screen
Comment on attachment 5441 [details] setup the server 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). This means on my VM 15+ minutes
If you're counting not manually installing 389-ds as a mistake then probably so yes. It is missing as a require. This bug is for Mageia 4 though and AFAIK this is not in updates_testing for mga4. All I'm doing is installing the list of packages from the pykolab srpm which you gave on the other bug and running setup-kolab. Hard to make a mistake there really :) # urpmi pykolab pykolab-telemetry pykolab-xml kolab-cli kolab-saslauthd kolab-server postfix-kolab wallace # setup-kolab It may be some slapd leftovers from the original failed setup (due to missing 389-ds) which is causing the setup to fail at the later stage I suppose. I'll install a clean VM and manually install 389-ds and try there.
You seem to be using 'urpmi kolab' to install Thomas but this isn't mentioned in the list of rpms you gave for pykolab See https://bugs.mageia.org/show_bug.cgi?id=10139#c4
Right, it's making more sense now. pykolab and the related packages aren't actually kolab and don't require kolab, so kolab itself (a different srpm) isn't being installed, even though the setup-kolab tool is. That's what has caused the confusion. Wish we'd done this earlier.
light dawns... It works fine :) I'll make a procedure page on the wiki for this for next time. It was not obvious though that installing all the pykolab packages and running the setup-kolab tool isn't sufficient, as it's missing the essential part which is kolab itself. I'd assumed that was kolab-server, but apparently not! It helps us greatly if you can give a test procedure usually Thomas, would have saved 2 months in fact :D Closing this one as invalid then. I'll have another go with mga3 later.
Status: NEW => RESOLVEDResolution: (none) => INVALID
Claire: We could of course add a requires "kolab" but I hate circular dependencies. Fedora (=upstream for 389-ds) does it similar for the 389 directory server. It uses 389-ds as a task package that pulls in all other 389-ds-... packages. Upstream did it similar for kolab using a bunch of task packages. Very sorry for the misunderstanding. One shouldn't assume the other person knows it.