Using a non-empty suffix

[gilran]

Hello.

I wrote about this issue in the administrators forum, and noone replied. This got me to thinking that the issue I'm presenting might not be an administration issue, but a feature request.

I am using zimbra on a Fedora system. My ldap server, that now contains users information, dns, zimbra configuration, and many other things, is on a Linux-From-Scratch based system (using openldap-2.3.27).

I merged my old directory and zimbra's directory myself. This forced me to change the ldap bdb suffix to "", instead of my domain.

I wish to have a non-empty suffix (for example "dc=example,dc=com"). To have this, I need to preform one of 2 options:
1. Split "cn=zimbra" and "dc=example,dc=com" to different bdbs. This will create an authentication problem, having that zimbra would be able to authenticate to only one of the two.
2. Put zimbra somewhere under my suffix. I was thinking about something like "cn=zimbra,ou=services,dc=example,dc=com". The porblem with this is that I failed to find where the suffix of "cn=zimbra" is defined.

Does anyone knows how to do one of those?

Thanks,
Gil Ran.

[quanah]

The first thing you should do is upgrade, given the age of OpenLDAP 2.3.27. Secondly, why specifically do you want to avoid using the "" base? Zimbra uses it so it can fit multiple domains easily.

[gilran]

hi.

First, upgrading openldap can be good, but it won't give me a solution.

About your question, why do I want to avoid "" base:

Lets say that my suffix (before using zimbra) was "dc=mydomain,dc=example,dc=com". If I use "" as suffix I must have the objects "dc=com" and "dc=example,dc=com" in my directory. This is what I wish to avoid. I don't really manage these object, they would exist only as placeholders. I do not want objects in my directory that I don't manage.

This is not a critical issue. It just seems better, in directory managment perspective, to have only the objects you really need. In this case, if I have a single domain (which I have), I want to maintain the zimbra tree under this domain. If I have multiple domains, I want to maintain each domain in its own bdb, and have another bdb for the zimbra internals.

To make a long story short, is it possible? Configuration hack? Code hack?

Thanks,
Gil Ran.

[quanah]

I guess the main issue here is that you are wanting to manage something that really is managed by Zimbra. Yes, Zimbra uses an LDAP server for things, but really it should be approached as a closed box. Our entire install & upgrade process relies on things being configured the way Zimbra expects it to be configured, and that is true for all the pieces, not just LDAP. If you want to run your own LDAP servers, that's cool. But if you try to wedge the Zimbra pieces into them as well, you will simply run into problems down the road. We make schema modifications, layout changes in our admin tree, etc. We expect to be able to bind in a certain way. This especially is relevant the more I work on the 5.0 release, as I'm tightening up a number of things in the LDAP layer. Also, by running your own version of OpenLDAP, you run the (very serious) risk of encountering bugs that are already handled in the Zimbra release. For example, there is an indexing bug with slapadd/slapindex -q that is fixed in the upcoming 4.5.7 Zimbra release that you would hit. Zimbra's replication will be moving to delta-syncrepl, which requires at least OpenLDAP 2.3.34. etc. As I'm part of the OpenLDAP engineering team with the OpenLDAP foundation, I spend a bit of time pulling in fixes specific for Zimbra. Unless you are willing to dedicate a lot of time to doing this sort of work, you really are better off simply using what Zimbra ships. I expect that one could hack things to work in the manner you are wanting, but it would break as soon as you went to upgrade, causing all manner of pain.

[gilran]

Thanks for your through out reply.
I have two mottoes here:
1. I do not want to keep separate user database for each service, i.e. for LDAP, for Kerberos, for Zimbra, for Apache, for... you get the idea. That's why I push everything into LDAP.
2. I did not like the way Zimbra clustering works. From what I've saw, if you have two Zimbras then each user has to be either on zimbra1 or zimbra2 (at least that's what is written in zimbra ldap tree - which zimbra user belongs to). I.e. if one of the zimbras is down, then half of the users do not have mail access. That's why I've decided to configure zimbra to use external LDAP and MySQL (for user accounts data, not for logging). This way I currently have two zimbra boxes that actually does not hold any user data, and I can add more zimbra "processors" in a drop-in way. Also, such setup allows me to cluster my LDAP and MySQL without worrying about zimbra configs. And I do not need any of zimbra sync/whatever features.
My first question in the thread is actually the only thing that stops up to start massive testing of this setup. But as I've said, we can live with it, it just would be less clean.

IMHO such service-oriented cluster/failvoer approach is more robust and very suitable for enterprises. I.e. there are "database" services, "directory" services and other higher level services such as HTTP or mail that use them.