Description of problem: pykolab needs patch to deleted some none existent roundcubemail plugins Otherwise, if roundcubemail logs are enabled, the logs get filled. Version-Release number of selected component (if applicable): mga3 . This bug report is filed so it doesn't get forgotten to be pushed to upgrades after the mga3 release. How reproducible: Steps to Reproduce: 1. 2. 3. Reproducible: Steps to Reproduce:
Status: NEW => ASSIGNED
Assignee: bugsquad => thomas
This bug has now been resolved. In addition, I also patched the setup script to correct the location of the file /etc/sasl2/smtpd.conf. This will enable outgoing mail from a mailprogram such as Thunderbird or Roundcubemail to send mail on port 587 (using saslauth). I have tested the program as it is now in updates_testing and the patch seems to have fixed the problems. In order to test it, do a fresh install, setup a mailserver through the browser (http://localhost/kolab-webadmin) log-in with user cn=Directory Manager password: use the password you entered when you run setup-kolab add a a couple users and then add them in Thunderbird or better/easier, use Roundcubemail, then the users you created are already there. http://localhost/roundcubemail If you can send e-mail, the smtpd.conf is correct. Watch the roundcube logs for the original error reported here.
CC: (none) => thomasAssignee: thomas => qa-bugs
I forgot one thing, you need to change the port in amavis.conf to 10024 (from 10025). BTW I just did a fresh install mageia3 32bit, added this two updates and run the setup-kolab script. The system runs as expected.
Can you list rpms and srpms please Thomas
Here is the list of the RPMS: pykolab-0.5.12-1.2.mga3.src.rpm pykolab-0.5.12-1.2.mga3.noarch.rpm pykolab-telemetry-0.5.12-1.2.mga3.noarch.rpm pykolab-xml-0.5.12-1.2.mga3.noarch.rpm kolab-cli-0.5.12-1.2.mga3.noarch.rpm kolab-saslauthd-0.5.12-1.2.mga3.noarch.rpm kolab-server-0.5.12-1.2.mga3.noarch.rpm postfix-kolab-0.5.12-1.2.mga3.noarch.rpm wallace-0.5.12-1.2.mga3.noarch.rpm
(In reply to claire robinson from comment #3) > Can you list rpms and srpms please Thomas We can get the rpm/srpm list now from http://mageia.madb.org/tools/listRpmsForQaBug/bugnum/10139%3Fapplication%3D0 Link is from the lists colum on http://mageia.madb.org/tools/updates/application/0
CC: (none) => davidwhodgins
Thanks Thomas. It's usually possible Dave, assuming it's clear what is being updated and why. That's why we have an updates policy. https://wiki.mageia.org/en/Updates_policy#Maintainer_.28or_any_interested_packager.29 If we want to encourage new members to join the team then information needs to be readily available and not just possible to find.
Bug 10891 created for unrelated file conflicts between python-pyasn1 and pyasn1 Installation failed: file /usr/lib/python2.7/site-packages/pyasn1/__init__.py from install of python-pyasn1-0.1.6-5.mga3.x86_64 conflicts with file from package pyasn1-0.1.4-2.mga3.noarch file /usr/lib/python2.7/site-packages/pyasn1/codec/ber/decoder.py from install of python-pyasn1-0.1.6-5.mga3.x86_64 conflicts with file from package pyasn1-0.1.4-2.mga3.noarch file /usr/lib/python2.7/site-packages/pyasn1/codec/ber/encoder.py from install of python-pyasn1-0.1.6-5.mga3.x86_64 conflicts with file from package pyasn1-0.1.4-2.mga3.noarch file /usr/lib/python2.7/site-packages/pyasn1/debug.py from install of python-pyasn1-0.1.6-5.mga3.x86_64 conflicts with file from package pyasn1-0.1.4-2.mga3.noarch file /usr/lib/python2.7/site-packages/pyasn1/type/base.py from install of python-pyasn1-0.1.6-5.mga3.x86_64 conflicts with file from package pyasn1-0.1.4-2.mga3.noarch postfix is needed by postfix-kolab-0.5.12-1.2.mga3.noarch pykolab = 0.5.12-1.2.mga3 is needed by postfix-kolab-0.5.12-1.2.mga3.noarch kolab-cli = 0.5.12-1.2.mga3 is needed by pykolab-telemetry-0.5.12-1.2.mga3.noarch pykolab = 0.5.12-1.2.mga3 is needed by kolab-saslauthd-0.5.12-1.2.mga3.noarch pykolab = 0.5.12-1.2.mga3 is needed by kolab-server-0.5.12-1.2.mga3.noarch pykolab = 0.5.12-1.2.mga3 is needed by wallace-0.5.12-1.2.mga3.noarch pykolab-xml = 0.5.12-1.2.mga3 is needed by wallace-0.5.12-1.2.mga3.noarch Workaround is to uninstall pyasn1 (used by gajim)
It seems to be missing the kolab-n user/group Thomas Preparing... ########################################################################################################## 1/13: python-pyasn1 ########################################################################################################## 2/13: python-pyasn1-modules ########################################################################################################## 3/13: kolab-cli ########################################################################################################## 4/13: pykolab warning: user kolab-n does not exist - using root ####################################################################################################warning: group kolab-n does not exist - using root #####warning: group kolab-n does not exist - using root
I wonder what went wrong. I just checked on a pretty much virgin vbox installation. I used userdrake to check about user and group kolab-n (and kolab-e) They were not there. I then installed pykolab (both ways, before and after the patch) by using urpmi pykolab. There were no error messages and after the instalaltion, both, user and group kolab-n (and kolab-r) were there.
I does it every time here, with both versions. x86_64 btw. # grep kolab /etc/{passwd,group} /etc/passwd:kolab:x:455:455:system user for kolab:/var/lib/kolab:/bin/false /etc/group:kolab:x:455:apache,postfix,ldap # rpm -qa | grep kolab lib64kolabxml0-0.8.4-1.mga3 pykolab-0.5.12-1.2.mga3 kolab-cli-0.5.12-1.2.mga3 lib64kolab0-0.4.2-4.mga3
I get: # grep kolab /etc/{passwd,group} /etc/passwd:kolab:x:412:412:Kolab System Account:/var/lib/kolab:/sbin/nologin /etc/passwd:kolab-n:x:413:413:Kolab System Account (N):/var/lib/kolab-n:/sbin/nologin /etc/passwd:kolab-r:x:414:414:Kolab System Account (R):/var/lib/kolab-r:/sbin/nologin /etc/group:kolab:x:412:apache,kolab-n /etc/group:kolab-n:x:413: /etc/group:kolab-r:x:414: # rpm -qa | grep kolab lib64kolabxml0-0.8.4-1.mga3 lib64kolab0-0.4.2-4.mga3 kolab-cli-0.5.12-1.2.mga3 pykolab-0.5.12-1.2.mga3
Whiteboard: (none) => feedback
It's possible they are there from previous installs Thomas
Looks like you're setting a specific userid/groupid Thomas, 412, 413, 414 3 %global kolab_user kolab 4 %global kolab_user_id 412 5 %global kolab_group kolab 6 %global kolab_group_id 412 7 8 %global kolabn_user kolab-n 9 %global kolabn_user_id 413 10 %global kolabn_group kolab-n 11 %global kolabn_group_id 413 12 13 %global kolabr_user kolab-r 14 %global kolabr_user_id 414 15 %global kolabr_group kolab-r 16 %global kolabr_group_id 414 On my system those are already in use.. # grep 412 /etc/{passwd,group} /etc/passwd:mediatomb:x:482:412:system user for mediatomb:/var/lib/mediatomb:/bin/false /etc/group:mediatomb:x:412: # grep 413 /etc/{passwd,group} /etc/passwd:postgrey:x:483:413:system user for postgrey:/var/lib/postgrey:/bin/false /etc/group:postgrey:x:413: # grep 414 /etc/{passwd,group} /etc/group:postdrop:x:414:postfix
This is probably the problem in your setup. The numbers I use were the ones from upstream. I haven't seen any complaint on the kolab mailinglist about this. I have for postfix # grep postfix /etc/{passwd,group} /etc/passwd:postfix:x:410:410:system user for postfix:/var/spool/postfix:/bin/false /etc/group:mail:x:12:postfix /etc/group:postfix:x:410: /etc/group:postdrop:x:409:postfix
We don't use fixed GID/UID though. The problem is the package I'm afraid.
Indeed, Claire is right. Thomas, please fix the package to follow the system services policy and use the appropriate macros to add the needed user accounts: https://wiki.mageia.org/en/System_Service_policy
Reassigning to Thomas until the fixes are done.
Assignee: qa-bugs => thomas
I am very hesitant to change this in mga3. kolab-webadmin is using the same hardcoded numbers and making a change could screw up the complete system. David, if you want do make the change, I wouldn't mind, but I think we are better off by not making such a big change.
I haven't forgotten this. But there is still an issue with the Wallace component of the package. If e-mails have Umlauts or other non ASCII characters, Wallace chokes and throws a python exception. Upstream is working on it.
This package has blocked all e-mails that contain special characters used in French, German, Scandinavian and other languages. (including a lot of e-mails from the mageia mailing lists. Upstream has no provided a patch and it has been applied. I have been using the patched package in updates_testing for 24 hours and it solved this problem. I haven't detected any regressions. The software in now ready to test. It can be tested by: without the patch, send an e-mail to yourself containing German Umlauts or French special characters. It will get stuck in the wallace component. as root, type mailq and you can see the problem getting stuck at port 10026 Upgrade (and to be sure, reboot) type as root postsuper -r ALL and then restart postfix to speed up the process. again type mailq to see how the messages pass through. BTW, run clamd as root not as clamav user, it's not working, by commenting out "User clamav" in /etc/clamav.conf)
Priority: Normal => HighAssignee: thomas => qa-bugsSeverity: normal => major
Was this fixed to follow the system service policy Thomas? If not then it's unlikely to be working at all.
if you mean comment 13, no. If someone else more knowledgeable would step in to rewrite those %posts I would appreciate it. Otherwise we have a package mailserver that is frankly unusable.
CC: (none) => stormiSource RPM: pykolab => pykolab-0.5.14-1.1.mga3.src.rpm
Assigning back to Thomas until the user issues are corrected. You can ask for help on the dev list if need be (probably more likely to get help if you ask after Mageia 4 is done). Also, you have two versions in SOURCES/sha1.lst right now.
CC: (none) => qa-bugsAssignee: qa-bugs => thomas
(In reply to claire robinson from comment #15) > We don't use fixed GID/UID though. The problem is the package I'm afraid. This has now been fixed with Philippe's help (thanks) New packages are in updates testing Here is the list of the RPMS: pykolab-0.5.14-1.2.mga3.src.rpm pykolab-0.5.14-1.2.mga3.noarch.rpm pykolab-telemetry-0.5.14-1.2.mga3.noarch.rpm pykolab-xml-0.5.14-1.2.mga3.noarch.rpm kolab-cli-0.5.14-1.2.mga3.noarch.rpm kolab-saslauthd-0.5.14-1.2.mga3.noarch.rpm kolab-server-0.5.14-1.2.mga3.noarch.rpm postfix-kolab-0.5.14-1.2.mga3.noarch.rpm wallace-0.5.14-1.2.mga3.noarch.rpm assigning it to qa-bugs@ml.mageia.org
Assignee: thomas => qa-bugs
Forgot to mention, I tested them: 1. Upgrade from existing, working installation. All worked fine and I was still able to use all features. 2. From mga3 vanilla installation I did all updates and then installed the pykolab packages from updates testing. I then turned the updates_testing source off and installed the rest by urpmi kolab I then set the hostname to a FQDN I then set-up the kolab suite doing as root setup-kolab -d9 (-d9 in order to see the logs) the I used the web-interface http://localhost/kolab-webadmin logged in as: cn=Directory Manager Password: the one you gave during the setup. After that I used Thunderbird and sent e-mails to those two clients I setup in the kolab-webadmin interface. After that, I used roundcubemail and sent e-mails from there (http://localhost/roundcubemail. BTW, the port an amavisd needs to be set to 1024 in order to work.
Whiteboard: feedback => (none)
The packages still experience the Umlaut problem. It needs to be updated to version 0.5.16 as it was done in mga4. I like to have taht update tested for a couple more weeks. This also will fix the hard coded UID and GID
Assigning back to you until then Thomas. Please reassign when you're ready. Thanks
I have now had version 0.5.16 in daily use (from mga4 updates_testing) for about 5 weeks and it works quite reliably. I have updated the packages here to version 0.5.16 (same as in mga4). The following packages are now in updates_testing: pykolab-0.5.16-1.mga3.src.rpm pykolab-0.5.16-1.mga3.noarch.rpm pykolab-telemetry-0.5.16-1.mga3.noarch.rpm pykolab-xml-0.5.16-1.mga3.noarch.rpm kolab-cli-0.5.16-1.mga3.noarch.rpm kolab-saslauthd-0.5.16-1.mga3.noarch.rpm kolab-server-0.5.16-1.mga3.noarch.rpm postfix-kolab-0.5.16-1.mga3.noarch.rpm wallace-0.5.16-1.mga3.noarch.rpm assigned back to QA
Testing mga3 64 ** tl;dr; Appears to be missing a require on 389-ds and setup-kolab ends with a traceback unable to connect to ldap. Adding 'feedback' marker. setup-kolab failed with a traceback below after accepting the 'standard root dn'.. Traceback (most recent call last): File "/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 247, in execute setup_ds_admin, UnboundLocalError: local variable 'setup_ds_admin' referenced before assignment This seems to refer to 389-ds, the questions seem relevant, but it is not required by the package. Installed 389-ds and 389-ds-base, which brought in the rest of the 389-* packages too. After this I ran setup-kolab again with '-d 9' option to get some debugging info and this time it proceeds further, so there is a missing require for 389-ds-something. It then showed an error, but continued anyway to the next step.. 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). 2014-06-23 15:34:42,597 pykolab.setup INFO Setting up 389 Directory Server 2014-06-23 15:34:43,204 pykolab.setup DEBUG [9974]: Setup DS stdout: 2014-06-23 15:34:43,209 pykolab.setup DEBUG [9974]: Creating directory server . . . Error: the server already exists at '/etc/dirsrv/slapd-mga364' Please remove it first if you really want to recreate it, or use a different ServerIdentifier to create another instance. Error: Could not create directory server instance 'mga364'. Exiting . . . Log file is '/tmp/setupLY6a0N.log' Killed setup-kolab to try and get a clean environment. Removed all related packages and deleted any leftovers. # urpme -a pykolab pykolab-telemetry pykolab-xml kolab-cli kolab-saslauthd kolab-server postfix-kolab wallace 389-ds-base 389-ds # rm -rf /etc/kolab/ # rm -rf /usr/share/kolab/ # rm -rf /etc/dirsrv/ # rm -rf /var/lib/dirsrv # rm -rf /usr/share/dirsrv/ Reinstalled and tried again.. # urpmi pykolab pykolab-telemetry pykolab-xml kolab-cli kolab-saslauthd kolab-server postfix-kolab wallace 389-ds-base 389-ds # setup-kolab Fails again with.. 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 [IFYUQ8euqynZJ60]: Confirm Kolab Service password: Traceback (most recent call last): File "/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 405, in execute auth._auth.ldap.add_s(dn, ldif) File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 194, in add_s msgid = self.add(dn,modlist) File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 191, in add return self.add_ext(dn,modlist,None,None) File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 176, in add_ext return self._ldap_call(self._l.add_ext,dn,modlist,RequestControlTuples(serverctrls),RequestControlTuples(clientctrls)) File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 99, in _ldap_call result = func(*args,**kwargs) ldap.SERVER_DOWN: {'desc': "Can't contact LDAP server"}
Removed everything again, with --auto-orphans this time too. Removed the dir's mentioned before. Tidied up some other leftovers I found too. # rm -rf /usr/lib64/dirsrv/ # rm -rf /var/log/dirsrv/ # rm -f /etc/sysconfig/dirsrv-mga364 Reinstalled and ran setup-kolab again. Different traceback this time.. Kolab Service password [oMI8fRYFzhrv89i]: Confirm Kolab Service password: Traceback (most recent call last): File "/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'} Relevant part from /var/log/dirsrv/slapd-mga364/errors [23/Jun/2014:16:40:12 +0100] - 389-Directory/1.3.0.9 B2014.073.2050 starting up [23/Jun/2014:16:40:12 +0100] - slapd started. Listening on All Interfaces port 389 for LDAP requests [23/Jun/2014:16:40:30 +0100] NSACLPlugin - __aclp__init_targetattr: targetattr "kolabAllowSMTPRecipient" does not exist in schema. Please add attributeTypes "kolabAllowSMTPRecipient" to schema if necessary. [23/Jun/2014:16:40:30 +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);)
A re-install doesn't work. You first need to remove all 389-ds instances on your box and mmysql. This links tells you how. Scroll all the way down.
You didn't give the link Thomas. I removed all 389-* and kolab packages and manually deleted all dirsrv or kolab directories I found, as shown above. The error seems to be about something being missing from the ldap schema, also there seems to be a missing require/suggest on 389-ds
here is the link http://en.opensuse.org/SDB:Kolab#Reset_a_broken_Installation_to_do_a_re-install urpmi 389-ds should pull-in all what is needed for the 389-ds The setup is that you install urpmi kolab and it should pull in all requirements. Let me trying to set it up on my vbox. I have a mga4 installed
It didn't :) Please see comment 29 and comment 30 Thomas.
Also this update is for mga3 so testing in mga4 is not really valid.
I found a missing dep, pykolab-xml, when wallace didn't start, even as the kolab setup process went fine. I installed a brand new mga3 system with all updates. I then added updates_testing and installed kolab and added manually pykolab-xml. The setup-process went as it should w/o any errors. I will attached a file that shows the messages. I have now added pykolab-xml as a dep to wallace as it's done by upstream. The updated packages are now in updates_testing: pykolab-0.5.16-1.1.mga3.src.rpm pykolab-0.5.16-1.1.mga3.noarch.rpm pykolab-telemetry-0.5.16-1.1.mga3.noarch.rpm pykolab-xml-0.5.16-1.1.mga3.noarch.rpm kolab-cli-0.5.16-1.1.mga3.noarch.rpm kolab-saslauthd-0.5.16-1.1.mga3.noarch.rpm kolab-server-0.5.16-1.1.mga5.noarch.rpm postfix-kolab-0.5.16-1.1.mga3.noarch.rpm wallace-0.5.16-1.1.mga3.noarch.rpm
Created attachment 5213 [details] setup-kolab this is the setup log
Removing feedback marker, the packages in comment 36 have not been tested yet.
CC: (none) => remiWhiteboard: feedback => (none)
Procedure in comment 25.
Whiteboard: (none) => has_procedure
Testing again mga3 64, sorry for the delay Thomas.
setup-kolab fails, accepting all the default passwords, it ends in the same place as comment 30. In fact a little earlier as it didn't ask to confirm the password. I'll add the 'feedback' marker again for now. =============== <snip> 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 [2DrhHt6LJ_Im6wi]: Traceback (most recent call last): File "/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'}
Whiteboard: has_procedure => has_procedure feedback
I think you invested far to much time in this already. mg3 will reach end of life by November of this year. There are no bug reports except by myself. I suspect nobody ever used it on mga3. I propose to close this bug as will not fix. If you agree, I will close it.
Completely your choice Thomas. It might be worth testing it in mga4 first to ensure it's an mga3 only problem.
mga4 appears to be missing require on 389-ds. I'll create a new bug for mga4. Once installed it seems to get stuck at the same place, but doesn't error. 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]:
bug 14151 created for mga4 which appears to have the same issues.
bug 14151 closed as invalid. I'll check mga3 again later. There has been some confusion here. The pykolab packages, including kolab-server, are not actually kolab itself. Despite setup-kolab tool being installed with these packages it's not actually possible unless the 'kolab' package is also installed. I'll create a wiki page for this as it is confusing when approached from this angle. It's probably best to test in a VM and take a snapshot before you begin so it is easy to roll back when done. It needs a FQDN, so check with '# hostname'. It will be just 'localhost' if you haven't altered it. Change it to something else temporarily, or if you have a domain name use that. # hostname testmachine.testdomain.com You can make it permanent in /etc/hosts if you like. For future reference, install kolab with simply.. # urpmi kolab This installs kolab itself and the pykolab packages and 389-ds etc. Run the setup with.. # setup-kolab Make a note of the Directory Manager password as you'll need it later. Most other passwords you can accept the defaults except maybe the mysql one which you will likely already have configured. After it's finished visit http://localhost/kolab-webadmin and follow the instructions here: https://docs.kolab.org/installation-guide/first-login.html Create the first user, filling in the various info in the tabs, including password and role then log in at http://localhost/roundcubemail and check the calendar etc views work ok. You'll not be able to send email without a proper domain or possibly adding an external one such as gmail, but not explored that option.
Whiteboard: has_procedure feedback => has_procedure
Testing mga3 32 After installing kolab and the pykolab packages from updates_testing and then running setup-kolab \o/ I'm unable to log into kolab-webadmin as "cn=Directory Manager". It says Incorrect username or password. I found some debugging info here https://docs.kolab.org/administrator-guide/verifying-the-installation.html#authentication-failures # service kolab-saslauthd status Redirecting to /bin/systemctl status kolab-saslauthd.service kolab-saslauthd.service - Kolab Groupware SASL Authentication Daemon. Loaded: loaded (/usr/lib/systemd/system/kolab-saslauthd.service; enabled) Active: active (running) since Wed, 2014-09-24 15:53:38 BST; 24s ago # service kolabd status Redirecting to /bin/systemctl status kolabd.service kolabd.service - Kolab Groupware Server. Loaded: loaded (/usr/lib/systemd/system/kolabd.service; enabled) Active: active (running) since Wed, 2014-09-24 15:53:41 BST; 31s ago # systemctl status dirsrv@mga332.service dirsrv@mga332.service - 389 Directory Server mga332. Loaded: loaded (/usr/lib/systemd/system/dirsrv@.service; enabled) Active: active (running) since Wed, 2014-09-24 15:50:59 BST; 6min ago # testsaslauthd -u cyrus-admin -p uUKlK5SL1Cv3egM 0: OK "Success." # kolab list-mailboxes # kolab lm # I've saved a VM snapshot just before running setup-kolab and rolled back several times to try using different passwords and timezones but no luck so far. /var/log/kolab/pykolab.log shows.. 2014-09-24 15:53:42,276 pykolab.conf WARNING Option ldap/modifytimestamp_format does not exist in config file /etc/kolab/kolab.conf, pulling from defaults 2014-09-24 15:53:42,279 pykolab.conf WARNING Option does not exist in defaults. 2014-09-24 15:53:48,900 pykolab.conf WARNING Option imap/virtual_domains does not exist in config file /etc/kolab/kolab.conf, pulling from defaults 2014-09-24 15:56:38,009 pykolab.conf WARNING Option imap/virtual_domains does not exist in config file /etc/kolab/kolab.conf, pulling from defaults 2014-09-24 15:56:41,971 pykolab.conf WARNING Option imap/virtual_domains does not exist in config file /etc/kolab/kolab.conf, pulling from defaults 2014-09-24 15:57:46,974 pykolab.conf WARNING Option imap/virtual_domains does not exist in config file /etc/kolab/kolab.conf, pulling from defaults 2014-09-24 15:57:51,181 pykolab.conf WARNING Option imap/virtual_domains does not exist in config file /etc/kolab/kolab.conf, pulling from defaults
Thomas if you still want to close this as wontfix you can do. Mga4 is working and there are still issues with mga3. I'll add 'feedback' and you can choose what you want to do.
I am going to close this as wont fix. There are no other bug reports for pykolab in mga3 and the EOL is in November this year. The package works in mga4.
Status: ASSIGNED => RESOLVEDResolution: (none) => WONTFIX