http://bugzilla.opensuse.org/show_bug.cgi?id=1121298 Eric Schirra <ecsos@schirra.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|bnc-team-screening@forge.pr |aj@ajaissle.de |ovo.novell.com | -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1121298 http://bugzilla.opensuse.org/show_bug.cgi?id=1121298#c2 --- Comment #2 from Eric Schirra <ecsos@schirra.net> --- Todays update brakes kolab again. Please fix this bug. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1121298 http://bugzilla.opensuse.org/show_bug.cgi?id=1121298#c4 --- Comment #4 from Eric Schirra <ecsos@schirra.net> --- Request open since three month and no reaction. :-( -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1121298 http://bugzilla.opensuse.org/show_bug.cgi?id=1121298#c6 --- Comment #6 from Eric Schirra <ecsos@schirra.net> --- New version 1.4.1.3 is missing my request. And also rise up error: ERR - slapd_system_isFIPS - Can not access /proc/sys/crypto/fips_enabled - assuming FIPS is OFF 389 is broken ! -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1121298 http://bugzilla.opensuse.org/show_bug.cgi?id=1121298#c8 William Brown <william.brown@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #8 from William Brown <william.brown@suse.com> --- Hi there, It looks like the version of 389-ds in https://build.opensuse.org/package/show/server:Kolab:Extras/389-ds is linked to https://build.opensuse.org/package/show/network:ldap/389-ds . The network:ldap version is building correctly, and able to operate. It given that 389-ds is now in factory, it may not be required for kolab:extras to carry this package. Regardless, it appears to be something in the kolab:extras branch that may be misconfigured or otherwise that causes it to fail to build. Additionally, kolab should *not* be a member of the dirsrv user group, as this would be a break of trust - kolab should contact ldap via the ldapi socket (which is world rw for communication and allows uid/gid mapping) or via ldaps. I'm happy to advise on the setup of this and how to improve it, but at this point I don't believe there is a fault in the 389-ds package. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1121298 http://bugzilla.opensuse.org/show_bug.cgi?id=1121298#c10 --- Comment #10 from William Brown <william.brown@suse.com> --- (In reply to Eric Schirra from comment #9)

Without:

kolab must member of group dirsrv And var/lib/dirsrv must have rights 0775.

kolab does not run.

So it is needed!

This is a bug in kolab then, you do not and should not have to change the folder permissions of 389-ds.

It is debatable whether this is right or wrong. But kolab will not run without these rights. At least not in this old version.

I think we need two version of 389. One normaly and one for kolab.

This also applies to roundcube. With newest roudcube, kolab will not run.

I'm not really comfortable making a second version of 389-ds just to work around a problem in another project. I think that the kolab maintainers need to act on this ...

I have write 10 month ago:

Is the obs-project kolab still alive? When it is, why not use the newest kolab version? The problems with old kolab version rise up.

This is a good observation, if there is an issue in kolab, and it's going unresolved, then it needs to be asked what is happening in that space. Either way, I believe this is no longer an issue in 389-ds, but an issue in kolab. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1121298 http://bugzilla.opensuse.org/show_bug.cgi?id=1121298#c12 William Brown <william.brown@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution|--- |WONTFIX --- Comment #12 from William Brown <william.brown@suse.com> --- (In reply to Eric Schirra from comment #11)

I have now done a little research. You can start multiple instances of the 389-ds. There is then a dse.ldif for each instance under /etc/dirsrv/... In this ldif you can set the following parameters: sslapd-localuser:% ds_user%

Yes it is possible to have different instances, via the dscreate tool. However, you should *never* change the nsslapd-localuser: setting in cn=config post install, you should do it during dscreate via the from-file method. You still should never be changing this value.

If you do not use dirsrv here, but here, for example, kolab, then this requires write access to /var/lib/dirsrv, among other things. This user, kolab, must therefore be in the dirsrv group. Second, the group right from dirsrv to /var/lib/dirsrv must have write rights. Therefore it must change/fix in spec file from 389-ds.

Correct me if I'm wrong. But if i am correct, please correct the right in the spec.

No, you should never need to change the user for directory server. You have not specified why you need to write to /var/lib/dirsrv. You need to explain clearly WHY kolab is attempting to write to this directory, at all, because it's probably a bug in kolab. You should never need to take the actions you are proposing. I'm happy to help you identify the bug in kolab that is causing this, and to discuss, but this is not the venue for it, and directory server is not the problem in this case. I'm closing this issue again, and if you want proper support in the matter, please email the 389 users list (389-users@lists.fedoraproject.org) to help identify what is the problem with kolab that needs resolving. Thanks, -- You are receiving this mail because: You are on the CC list for the bug.