Bug 14151

# 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 => RESOLVED
Resolution: (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.