Am Sun, 2 Mar 2014 21:39:15 +0000 schrieb "Robson, Alan" alan.robson@viasat.com:
Thank you very much,
Using "" as the second suffix worked.
Is there a solution that will work for additional DITs too, for example if I wanted 6 of them ?
A directory information tree requires a tree design. The elements of such tree must have a common relation, that is a name. Thus the naming context of a DIT is the common base of all objects of this tree. If you want to integrate arbitrary names into a single tree structure, than you have to rewrite this names to fit into the tree structure. Rewriting may be done by attaching back-relay (slapd-relay(5)) as a subordinate database to a superiour database.
-Dieter
I saw that when I set the suffix = "" for two DITs, slapd complained that...
<suffix> namingContext "" already served by a preceding sql database serving namingContext ""
Thanks again for such a fast and accurate response
Alan
-----Original Message----- From: openldap-technical-bounces@OpenLDAP.org [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of Dieter Klünter Sent: Sunday, March 02, 2014 12:32 AM To: openldap-technical@openldap.org Subject: Re: back-sql mysql and multiple DITs
Am Sun, 2 Mar 2014 05:55:30 +0000 schrieb "Robson, Alan" alan.robson@viasat.com:
Hi,
I have tried to set up a single instance of slapd serving information from two DITs that have been defined in separate mysql databases. I can comment out the database entries for either DIT, and everything works for the other DIT. But it won't support the two DITs simultaneously (it seems random which DIT will return results and which returns "no such object" when I restart slapd with both DITs configured). All the odbc stuff for both backends seems fine, isql runs and of course either database can be accessed through ldapsearch if it is the only one slapd serves.
I can even run two instances of slapd, one with each DIT and successfully query them separately with ldapsearch, but I'd prefer one instance with the two DITs if possible. Could you please help me get this running, or is it just the law that only one sql backend can be used per server ?
Many thanks
Alan
Slaptest says (when both DITs are defined in one slapd.conf)...
WARNING: No dynamic config support for database sql. WARNING: No dynamic config support for database sql. config file testing succeeded
slapd.conf (with both backends/DITs) is:
# $OpenLDAP$ # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # loglevel 64
moduleload /usr/lib64/openldap/back_sql.la include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/farm.schema
# Define global ACLs to disable default read access. # Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap://root.openldap.org
#pidfile /usr/local/var/slapd.pid #pidfile /var/run/openldap/slapd.pid #argsfile /usr/local/var/slapd.args
###################################################################### # # sql database definitions ###################################################################### #
database sql suffix "dc=server,dc=farm" rootdn "cn=root,dc=server,dc=farm" rootpw *********** dbname openldap dbuser openldap dbpasswd *************** subtree_cond "ldap_entries.dn LIKE CONCAT('%',?)" insentry_stmt "INSERT INTO ldap_entries (dn,oc_map_id,parent,keyval) VALUES (?,?,?,?)" has_ldapinfo_dn_ru no
database sql suffix "dc=lab,dc=farm" rootdn "cn=root,dc=lab,dc=farm" rootpw ********** dbname lab dbuser ldap dbpasswd ******** subtree_cond "ldap_entries.dn LIKE CONCAT('%',?)" insentry_stmt "INSERT INTO ldap_entries (dn,oc_map_id,parent,keyval) VALUES (?,?,?,?)" has_ldapinfo_dn_ru no
There are some solutions
- define NULL values for suffix, that is suffix ""
- attach 1 sql database to a subordinate relay database with additional rwm modul and a suffixmassage rule.
-Dieter
-- Dieter Klünter | Systemberatung https://urldefense.proofpoint.com/v1/url?u=http://sys4.de/&k=OWT%2FB14AE... GPG Key ID: E9ED159B 53°37'09,95"N 10°08'02,42"E