This bug has been fixed by adding the missing directory at install. rpm is in 3/updates/testing
1. changed group nobody to nogroup
2. added Systemd directoy, %{_sysconfdir}/system/%{groupname}.wants
I have tested the updated package and the setup-kolab script now works flawless and the dirsrv instance starts every time the system is booted.

How to test:

Install kolab. It will pull all needed deps.
Give the box a real FQDN such as vbox.xyz.com
Then as root start the script: setup-kolab ( use option -d9 so you can see what's happening)
put in the infomation it asks you. 
after completion, reboot and then do a "systemctl" and see if the instance loaded such as vbox@dirserv

CC: (none) => thomas
Assignee: thomas => qa-bugs

The setup-kolab fails after asking for the kolab password.
The fqdn of the vb guest is i3v.hodgins.homeip.net. Forward and reverse
dns do match.

Kolab Service password [L0vMpMTNvTxlCgS]: 
Confirm Kolab Service password: 
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 405, in execute
    auth._auth.ldap.add_s(dn, ldif)
  File "/usr/lib/python2.7/site-packages/ldap/ldapobject.py", line 194, in add_s
    msgid = self.add(dn,modlist)
  File "/usr/lib/python2.7/site-packages/ldap/ldapobject.py", line 191, in add
    return self.add_ext(dn,modlist,None,None)
  File "/usr/lib/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/lib/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"}

[root@i3v ~]# host i3v.hodgins.homeip.net
i3v.hodgins.homeip.net has address 192.168.10.113
[root@i3v ~]# host 192.168.10.113
113.10.168.192.in-addr.arpa domain name pointer i3v.hodgins.homeip.net.

CC: (none) => davidwhodgins

Note that openldap-servers did not get installed, so likely just a missing
requires.

On another vb guest (x3v.hodgins.homeip.net), I tried
urpmi openldap-servers kolab
then running setup-kolab. It fails at the same point, so it looks like
it's trying to access the ldap server, before it's been started.

openldap-servers is not needed and it may be a conflict.
the 389-ds is the ldap server.
I have on a working installation:
# rpm -qa |grep ldap
kolab-ldap-3.0.0-6.mga3
openldap-clients-2.4.33-7.mga3
ldapjdk-4.18-13.mga3
mozldap-6.0.7-2.mga3
postfix-ldap-2.9.6-4.mga3
perl-ldap-0.490.0-4.mga3
python-ldap-2.4.10-2.mga3
openldap-2.4.33-7.mga3
lib64kldap4-4.10.2-4.mga3
mozldap-tools-6.0.7-2.mga3
php-ldap-5.4.16-1.mga3
lib64ldap2.4_2-2.4.33-7.mga3
kio4-ldap-4.10.2-4.mga3

I didn't start any servers, the setup-kolab script should take care of it.

Dave:
As mentioned in Bug #10139, I just did a fresh install of a 32bit (to check if this may has a problem) on my vbox, run the setup-script, and added users through the kolab-webadmin interface and then sent e-mail through the roundcube web interface.

There must be run time conflicts between setup-kolab, and
some of the other packages I've tested recently, or had
chosen to install.

Either I've got packages that shouldn't be installed with
389-ds-base, or packages that should not be installed before
trying to install 389-ds-base.

I can revert the vb guest to what I had after a clean install
plus updates, or would you prefer that I use what I have to
try and track down which packages are causing the conflicts?

If you don't mind and have some time, track down the conflict, so we can add it to the rpm

I forgot to tell you, you may need to 
# setenforce 0
I didn't have to because selinux is disabled (not working) in all of my mga3
http://docs.kolab.org/en-US/Kolab_Groupware/3.0/html/Community_Installation_Guide/chap-Community_Installation_Guide-Preparing_the_System.html#sect-Community_Installation_Guide-Preparing_the_System-SELinux

Created attachment 4228 [details]
list of packages installed, where kolab where setup-kolab fails

Not using selinux. I've been digging through this, and can't figure out (yet),
why it works on a clean install, but is failing when installing to my standard
testing install.

The attached file contans the list of package installed when I install kolab
on the installation where setup-kolab fails.

Created attachment 4229 [details]
list of package installed with kolab, where setup-kolab does work.

Both of the attachments were made with Mageia 3 i586 installs, under vb.

I've tried installing all of the packages that were in the working install,
but missing from the non-working install, then installing kolab, and also
tried removing all of the packages in the non-working install, that are
missing from the working install, and then installing kolab, as well as
doing both the installing and removing, with no change.

My guess at this point, is that it's a package that is in both, but due to
configuration changes, I've made previously, as part of previous testing,
the config is not compatible with the setup-kolab script.  I normally only
revert the snapshot, if needed to test a poc for a bug.

I'm running out of ideas on how to debug this, and as I think it's unlikely
that anyone other than a qa tester would have these old config files, and be
installing this package, I'm inclined to leave this, and just test the package
on a clean install.

Opinion?

If you had it installed before and did a setup-kolab script, you have to remove the incident, which according to the kolab folks doesn't always happen completely.
There is a remove script for it, 
remove-ds.pl <instance>
but then again, it may not always work.
Since the way I understand you, you did an upgrade of a working installation, you cannot run "setup-kolab" again. It would not work.
There were no bug reports from anybody else. I think we are fine.

Thomas, it's difficult to know what is being updated here, there are two bugs which seem closely related. This and bug 10139.

Could you list rpms and srpms please.

Fedora fixed it by upgrading to 1.3.1.5
Will do the same

(In reply to Thomas Spuhler from comment #16)
> Fedora fixed it by upgrading to 1.3.1.5
> Will do the same

Ooops, wrong bug #

The updated RPMS are:
389-ds-base-1.3.0.2-2.1.mga4.src.rpm
389-ds-base-1.3.0.2-2.1.mga4.x86_64.rpm
389-ds-base-devel-1.3.0.2-2.1.mga4.xxx.rpm
389-ds-base-libs-1.3.0.2-2.1.mga4.xxx.rpm

Once all of the issues with this package are fixed, it'll need a full advisory describing the fixes.  You can use this one as a starting point:
https://bugs.mageia.org/show_bug.cgi?id=10889#c5

CC: (none) => luigiwalser

Assigning back to Thomas until this is ready.

CC: (none) => qa-bugs
Assignee: qa-bugs => thomas

Advisory:
========================

Updated 389-ds-base packages fix problem of wrong default group nobody (from upstream) as well as the 389-ds server not starting after a reboot:

Updated packages in core/updates_testing:
========================
389-ds-base-1.3.0.5-2.2.mga3
389-ds-base-libs-1.3.0.5-2.2.mga3
389-ds-base-devel-1.3.0.5-2.2.mga3

from 389-ds-base-1.3.0.5-2.2.mga3.src.rpm

These packages are fixing Bug # 10889 - 389-ds-base new security issue CVE-2013-2219
as well.

Thanks Thomas.  I guess that means the issues in this bug are fixed.

Assigning to QA.

Advisory:
========================

Updated 389-ds-base packages fix security vulnerability:

It was discovered that the 389 Directory Server did not honor defined
attribute access controls when evaluating search filter expressions. A
remote attacker (with permission to query the Directory Server) could use
this flaw to determine the values of restricted attributes via a series of
search queries with filter conditions that used restricted attributes
(CVE-2013-2219).

Additionally, problems of wrong default group nobody (from upstream) as well
as the 389-ds server not starting after a reboot have been fixed (mga#10138).

References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-2219
https://rhn.redhat.com/errata/RHSA-2013-1119.html
https://bugs.mageia.org/show_bug.cgi?id=10138
https://bugs.mageia.org/show_bug.cgi?id=10889
========================

Updated packages in core/updates_testing:
========================
389-ds-base-1.3.0.5-2.2.mga3
389-ds-base-libs-1.3.0.5-2.2.mga3
389-ds-base-devel-1.3.0.5-2.2.mga3

from 389-ds-base-1.3.0.5-2.2.mga3.src.rpm

CC: qa-bugs => (none)
Assignee: thomas => qa-bugs
Whiteboard: feedback => (none)

I realize now, my prior problem was due to comment 1. I was running
setup-kolab, which is from the kolab-cli package.

Running setup-ds.pl, I chose the express setup, but it's failing.

Choose a setup type [2]: 1
The group 'nobody' is invalid.

So it looks like the script needs to be fixed too.

The advisory 10138.adv has been uploaded to svn, but will need to
be updated, once the script has been fixed.

Whiteboard: (none) => feedback

/usr/lib/dirsrv/perl/SetupDialogs.pm:                    $username = "nobody";
/usr/lib/dirsrv/perl/SetupDialogs.pm:                    $groupname = "nobody";

Also looks like the id nobody will have to be added to the group nogroup,
which is not the case presently.

Thanks Dave for detecting this. I never  did just a setup of the dirsrv by itself.
I always used the setup-kolab script because kolab is what I wanted.
I put a patch in for the 389-ds-base that should have taken care of this defaultgroup.
It seems, it's not working and may be an upstream bug. In anycase, one can manually change it to nogroup during the setup.
It did run it that way on my VM and the script completes.

This bug is now fixed in subrel 3.(needed to add "autoreconf -if" to make the patch active)
The bug is no part of this report, I suggest to process this report for what it has been filed for, but no to push it into updates.
Let's open a new bug report for the nogroup/nobody problem and after approving the fix, push it into updates

We already have two bugs for this update, we don't need three.  The nobody issue is already mentioned in the advisory.

Updating package subrel in the advisory.

Advisory:
========================

Updated 389-ds-base packages fix security vulnerability:

It was discovered that the 389 Directory Server did not honor defined
attribute access controls when evaluating search filter expressions. A
remote attacker (with permission to query the Directory Server) could use
this flaw to determine the values of restricted attributes via a series of
search queries with filter conditions that used restricted attributes
(CVE-2013-2219).

Additionally, problems of wrong default group nobody (from upstream) as well
as the 389-ds server not starting after a reboot have been fixed (mga#10138).

References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-2219
https://rhn.redhat.com/errata/RHSA-2013-1119.html
https://bugs.mageia.org/show_bug.cgi?id=10138
https://bugs.mageia.org/show_bug.cgi?id=10889
========================

Updated packages in core/updates_testing:
========================
389-ds-base-1.3.0.5-2.3.mga3
389-ds-base-libs-1.3.0.5-2.3.mga3
389-ds-base-devel-1.3.0.5-2.3.mga3

from 389-ds-base-1.3.0.5-2.3.mga3.src.rpm

Whiteboard: feedback => (none)

setup-ds.pl still fails due to
Could not open LDIF file "/root/tmp/ldifFZ06xM.ldif", errno 13 (Permission denied)

Whiteboard: (none) => feedback

Dave:
I run the same setup-ds.pl script on my VM and it completed fine. I can attach the log.

Created attachment 4268 [details]
log from the setup-ds.pl script

This update is like a good game of ping-pong.

Since Thomas has responded, I've removed the feedback marker.  Dave, the ball's back in your court now :o)

Whiteboard: feedback => (none)

Testing again shortly

A new security issue affecting this has been announced.  I'll post the details in Bug 10889 and assign this back to Thomas until it's been addressed.

CC: (none) => qa-bugs
Assignee: qa-bugs => thomas

This has been fixed by upgrading to version 1.3.0.8
See Bug # 10889 for details
Re-assigning it back to qa-bugs@ml.mageia.org

Assignee: thomas => qa-bugs

Advisory:
========================

Updated 389-ds-base packages fix security vulnerability:

It was discovered that the 389 Directory Server did not honor defined
attribute access controls when evaluating search filter expressions. A
remote attacker (with permission to query the Directory Server) could use
this flaw to determine the values of restricted attributes via a series of
search queries with filter conditions that used restricted attributes
(CVE-2013-2219).

It was discovered that the 389 Directory Server did not properly handle the
receipt of certain MOD operations with a bogus Distinguished Name (DN). A
remote, unauthenticated attacker could use this flaw to cause the 389
Directory Server to crash (CVE-2013-4283).

Additionally, problems of wrong default group nobody (from upstream) as well
as the 389-ds server not starting after a reboot have been fixed (mga#10138).

References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-2219
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-4283
https://rhn.redhat.com/errata/RHSA-2013-1119.html
https://rhn.redhat.com/errata/RHSA-2013-1182.html
https://bugs.mageia.org/show_bug.cgi?id=10138
https://bugs.mageia.org/show_bug.cgi?id=10889
========================

Updated packages in core/updates_testing:
========================
389-ds-base-1.3.0.8-1.mga3
389-ds-base-libs-1.3.0.8-1.mga3
389-ds-base-devel-1.3.0.8-1.mga3

from 389-ds-base-1.3.0.8-1.mga3.src.rpm

whoops, make it plural...

Advisory:
========================

Updated 389-ds-base packages fix security vulnerabilities:

It was discovered that the 389 Directory Server did not honor defined
attribute access controls when evaluating search filter expressions. A
remote attacker (with permission to query the Directory Server) could use
this flaw to determine the values of restricted attributes via a series of
search queries with filter conditions that used restricted attributes
(CVE-2013-2219).

It was discovered that the 389 Directory Server did not properly handle the
receipt of certain MOD operations with a bogus Distinguished Name (DN). A
remote, unauthenticated attacker could use this flaw to cause the 389
Directory Server to crash (CVE-2013-4283).

Additionally, problems of wrong default group nobody (from upstream) as well
as the 389-ds server not starting after a reboot have been fixed (mga#10138).

References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-2219
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-4283
https://rhn.redhat.com/errata/RHSA-2013-1119.html
https://rhn.redhat.com/errata/RHSA-2013-1182.html
https://bugs.mageia.org/show_bug.cgi?id=10138
https://bugs.mageia.org/show_bug.cgi?id=10889
========================

Updated packages in core/updates_testing:
========================
389-ds-base-1.3.0.8-1.mga3
389-ds-base-libs-1.3.0.8-1.mga3
389-ds-base-devel-1.3.0.8-1.mga3

from 389-ds-base-1.3.0.8-1.mga3.src.rpm

Testing mga3 64

There is a traceback due to missing selinux but it does appear to complete successfully. It would be nice if this could be patched in a future update.

Directory Manager DN [cn=Directory Manager]: 
Password: 
Password (confirm): 
Traceback (most recent call last):
  File "/sbin/semanage", line 25, in <module>
    import seobject
  File "/usr/lib64/python2.7/site-packages/seobject.py", line 24, in <module>
    import pwd, grp, string, selinux, tempfile, os, re, sys, stat
ImportError: No module named selinux
Traceback (most recent call last):
  File "/sbin/semanage", line 25, in <module>
    import seobject
  File "/usr/lib64/python2.7/site-packages/seobject.py", line 24, in <module>
    import pwd, grp, string, selinux, tempfile, os, re, sys, stat
ImportError: No module named selinux
Your new DS instance 'mega' was successfully created.
Exiting . . .

It does start afterwards.

# systemctl start dirsrv@mega
# systemctl status dirsrv@mega
dirsrv@mega.service - 389 Directory Server mega.
          Loaded: loaded (/usr/lib/systemd/system/dirsrv@.service; static)
          Active: active (running) since Fri, 2013-08-30 09:36:48 BST; 4min 35s ago
         Process: 30700 ExecStart=/usr/sbin/ns-slapd -D /etc/dirsrv/slapd-%i -i /var/run/dirsrv/slapd-%i.pid -w /var/run/dirsrv/slapd-%i.startpid (code=exited, status=0/SUCCESS)
        Main PID: 30701 (ns-slapd)
          CGroup: name=systemd:/system/dirsrv@.service/mega
                  â 30701 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-mega -i /var/run/dirsrv/slapd-mega.pid -w /var/run/dirsrv/slapd-mega.st...

systemd[1]: Starting 389 Directory Server mega....
systemd[1]: Started 389 Directory Server mega..
systemd[1]: Started 389 Directory Server mega..


The dirsrv-snmp fails, not sure if that is expected, could you comment on this Thomas please?

# systemctl status dirsrv-snmp.service
dirsrv-snmp.service - 389 Directory Server SNMP Subagent.
          Loaded: loaded (/usr/lib/systemd/system/dirsrv-snmp.service; enabled)
          Active: failed (Result: exit-code) since Fri, 2013-08-30 09:41:05 BST; 34s ago
         Process: 31219 ExecStart=/usr/sbin/ldap-agent /etc/dirsrv/config/ldap-agent.conf (code=exited, status=1/FAILURE)
          CGroup: name=systemd:/system/dirsrv-snmp.service

systemd[1]: Starting 389 Directory Server SNMP Subagent....
ldap-agent[31219]: ldap-agent: No server instances defined in config file
systemd[1]: Failed to start 389 Directory Server SNMP Subagent..
systemd[1]: Unit dirsrv-snmp.service entered failed state

Can see it's started, looking in /var/log/dirsrv/slapd-<machine name>/errors
the last line is..
slapd started.  Listening on All Interfaces port 389 for LDAP requests

Checking with netstat to see it listening..
# netstat -pant | grep 389
tcp        0      0 :::389    :::*     LISTEN   30701/ns-slapd

Testing mga3 32

As above, plus..

# ldapsearch -x -h localhost -s base -b ""  "objectclass=*"

Shows lots of information \o/

Thomas, before validating could you comment on the dirsrv-snmp failing to start please. Is this expected or an issue?

Whiteboard: (none) => has_procedure mga3-32-ok mga3-64-ok

Advisory updated with details from comment 36

The failing dirsrv-snmp has not been a problem so far. I believe, it's a configuration issue. But it's certainly not a regression.
The upstream wiki isn't very clear: 
http://directory.fedoraproject.org/wiki/SELinux_Policy

OK, Validating then. Thanks Thomas.

Could sysadmin please push from 3 core/updates_testing to updates

Thanks!

Keywords: (none) => validated_update
Whiteboard: has_procedure mga3-32-ok mga3-64-ok feedback => has_procedure mga3-32-ok mga3-64-ok
CC: (none) => sysadmin-bugs

(In reply to Thomas Spuhler from comment #41)
> The failing dirsrv-snmp has not been a problem so far. I believe, it's a
> configuration issue. But it's certainly not a regression.
> The upstream wiki isn't very clear: 
> http://directory.fedoraproject.org/wiki/SELinux_Policy

I just looke further into this. I added the instance in 
/etc/dirsrv/config/ldap-agent.conf

and the server now runs.
It has to be done manually after the setup of the instance has been completed.

It might be worth making a Mageia Wiki page about all of the 389 stuff.

Update pushed:
http://advisories.mageia.org/MGASA-2013-0263.html

Status: ASSIGNED => RESOLVED
CC: (none) => tmb
Resolution: (none) => FIXED