Hi all,
i want to implement a specific openldap configuration with 3 instances: 1st is a master 2nd is a syncrepl replica "and" slurpd master 3rd is a slurpd replica The reason why i want to implement this configuration is that i have firewall restrictions: Only the 2nd instance can establish TCP connections on 1st and 3rd instances. TCP connections in the other direction is forbidden >:o .
The 1st instance sends updates correctly to the 2nd instance. But the 2nd instance doesn't generate replication log. So, i send nothing to the 3rd instance.
Here is an extract of my 2nd instance configuration: database bdb suffix "o=test" rootdn "cn=root DN, o=test" # Cleartext passwords, especially for the rootdn, should # be avoid. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. rootpw {SSHA}JDqRrNmZbCiInNsubLessizYPdmcwhgf # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /usr/products/freeware/openldap/var/openldap-slapd-pivot # # Changelog is check every 64 KB written or every 15 min # checkpoint 64 15
# password hash algorithm password-hash {SSHA}
# # Set the entry cache size to 50000. # cachesize 50000 # Indexes to maintain index objectClass,entryCSN,entryUUID eq index uid pres,eq,sub index mail pres,eq,sub index cn pres,eq,sub index sn pres,eq,sub
# # Slurpd master replication parameters # replica uri=ldaps://localhost:1636/ binddn="cn=Replicator, o=test" bindmethod=simple credentials=secret
replogfile /usr/products/freeware/openldap/var/replication/replication_pivot.log
# # SyncREPL slave replication parameters # syncrepl rid=3 provider=ldaps://10.1.1.69:636 #type=refreshOnly type=refreshAndPersist #interval=01:00:00:00 searchbase="o=test" filter="(objectClass=*)" scope=sub #attrs="cn,sn,ou,telephoneNumber,title,l" schemachecking=off bindmethod=simple binddn="cn=root DN, o=test" credentials=secret
So, my questions : Can this architecture work ? If yes, do you have a idea to solve the issue ? If no, is there a solution according to the restriction ?
Rgds, Bruno.
--On September 14, 2007 5:21:28 PM +0200 Bruno Lezoray EMSM bruno.lezoray@wh-ces.gmessaging.net wrote:
Hi all,
i want to implement a specific openldap configuration with 3 instances: 1st is a master 2nd is a syncrepl replica "and" slurpd master 3rd is a slurpd replica
Set up a pushed-base syncrepl instead of using slurpd. Slurpd is deprecated, and fully removed from OpenLDAP 2.4.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Quanah Gibson-Mount wrote:
--On September 14, 2007 5:21:28 PM +0200 Bruno Lezoray EMSM bruno.lezoray@wh-ces.gmessaging.net wrote:
Hi all,
i want to implement a specific openldap configuration with 3 instances: 1st is a master 2nd is a syncrepl replica "and" slurpd master 3rd is a slurpd replica
Set up a pushed-base syncrepl instead of using slurpd. Slurpd is deprecated, and fully removed from OpenLDAP 2.4.
In OpenLDAP 2.3 this will require one more slapd process (while eliminating the slurpd process).
1 provider 2 regular consumer 2A back-ldap consumer 3 external replica
None of the existing (1, 2, or 3) servers' configurations need any changes. (Except, you can remove the "replica" directives from your "slurpd master" since they don't do any good, and aren't needed anyway.)
The back-ldap consumer would be set up something like:
database ldap suffix "dc=example,dc=com" rootdn "cn=Whoever" uri ldap://localhost:9013/ <---- URL of external replica
acl-bind bindmethod=simple binddn="cn=Monitor" <---- updatedn of external replica credentials=monitor <---- password for updatedn
# the usual consumer config... syncrepl rid=1 provider=ldap://localhost:9011/ binddn="cn=Manager,dc=example,dc=com" bindmethod=simple credentials=secret searchbase="dc=example,dc=com" filter="(objectClass=*)" schemachecking=off scope=sub type=refreshOnly interval=00:00:00:10 retry="5 5 300 5"
Howard Chu wrote:
Quanah Gibson-Mount wrote:
--On September 14, 2007 5:21:28 PM +0200 Bruno Lezoray EMSM bruno.lezoray@wh-ces.gmessaging.net wrote:
Hi all,
i want to implement a specific openldap configuration with 3 instances: 1st is a master 2nd is a syncrepl replica "and" slurpd master 3rd is a slurpd replica
Set up a pushed-base syncrepl instead of using slurpd. Slurpd is deprecated, and fully removed from OpenLDAP 2.4.
In OpenLDAP 2.3 this will require one more slapd process (while eliminating the slurpd process).
1 provider 2 regular consumer 2A back-ldap consumer 3 external replica
None of the existing (1, 2, or 3) servers' configurations need any changes. (Except, you can remove the "replica" directives from your "slurpd master" since they don't do any good, and aren't needed anyway.)
The back-ldap consumer would be set up something like:
database ldap suffix "dc=example,dc=com" rootdn "cn=Whoever" uri ldap://localhost:9013/ <---- URL of external replica
acl-bind bindmethod=simple binddn="cn=Monitor" <---- updatedn of external replica credentials=monitor <---- password for updatedn
# the usual consumer config... syncrepl rid=1 provider=ldap://localhost:9011/ binddn="cn=Manager,dc=example,dc=com" bindmethod=simple credentials=secret searchbase="dc=example,dc=com" filter="(objectClass=*)" schemachecking=off scope=sub type=refreshOnly interval=00:00:00:10 retry="5 5 300 5"
Ok. On the backldap instance, i have this configuration: database ldap suffix "o=test" rootdn "cn=root DN, o=test" rootpw {SSHA}JDqRrNmZbCiInNsubLessizYPdmcwhgf uri ldaps://10.1.1.69:1636/ acl-bind bindmethod=simple binddn="cn=root DN, o=test" credentials=secret syncrepl rid=1 provider=ldaps://localhost:636/ binddn="cn=root DN,o=test" bindmethod=simple credentials=secret searchbase="o=test" filter="(objectClass=*)" schemachecking=off scope=sub type=refreshOnly interval=00:00:00:10 retry="5 5 300 5"
And on the external replica, i have : database bdb suffix "o=test" rootdn "cn=root DN, o=test" rootpw {SSHA}JDqRrNmZbCiInNsubLessizYPdmcwhgf directory /usr/products/freeware/openldap/var/openldap-slapd-sym checkpoint 64 15
password-hash {SSHA}
cachesize 50000 index objectClass,entryCSN,entryUUID eq index uid pres,eq,sub index mail pres,eq,sub index cn pres,eq,sub index sn pres,eq,sub
But, the backldap failed to query the external replica. I have the following error: Sep 17 11:23:24 test-ldap backldap[28913]: [ID 702911 local4.debug] @(#) $OpenLDAP: slapd 2.3.32 (Sep 13 2007 17:58:03) $ Sep 17 11:23:25 test-ldap backldap[28914]: [ID 100111 local4.debug] slapd starting Sep 17 11:23:25 test-ldap backldap[28914]: [ID 608079 local4.debug] do_syncrep2: rid 001got search entry without control Sep 17 11:23:30 test-ldap backldap[28914]: [ID 608079 local4.debug] do_syncrep2: rid 001got search entry without control
For information, i use release 2.3.32 on Solaris 9/10.
Rgds, Bruno.
Bruno Lezoray EMSM wrote:
Howard Chu wrote:
Quanah Gibson-Mount wrote:
--On September 14, 2007 5:21:28 PM +0200 Bruno Lezoray EMSM bruno.lezoray@wh-ces.gmessaging.net wrote:
Hi all,
i want to implement a specific openldap configuration with 3 instances: 1st is a master 2nd is a syncrepl replica "and" slurpd master 3rd is a slurpd replica
Set up a pushed-base syncrepl instead of using slurpd. Slurpd is deprecated, and fully removed from OpenLDAP 2.4.
In OpenLDAP 2.3 this will require one more slapd process (while eliminating the slurpd process).
1 provider 2 regular consumer 2A back-ldap consumer 3 external replica
None of the existing (1, 2, or 3) servers' configurations need any changes. (Except, you can remove the "replica" directives from your "slurpd master" since they don't do any good, and aren't needed anyway.)
The back-ldap consumer would be set up something like:
database ldap suffix "dc=example,dc=com" rootdn "cn=Whoever" uri ldap://localhost:9013/ <---- URL of external replica
acl-bind bindmethod=simple binddn="cn=Monitor" <---- updatedn of external replica credentials=monitor <---- password for updatedn
# the usual consumer config... syncrepl rid=1 provider=ldap://localhost:9011/ binddn="cn=Manager,dc=example,dc=com" bindmethod=simple credentials=secret searchbase="dc=example,dc=com" filter="(objectClass=*)" schemachecking=off scope=sub type=refreshOnly interval=00:00:00:10 retry="5 5 300 5"
Ok. On the backldap instance, i have this configuration: database ldap suffix "o=test" rootdn "cn=root DN, o=test" rootpw {SSHA}JDqRrNmZbCiInNsubLessizYPdmcwhgf uri ldaps://10.1.1.69:1636/
Is that really the URI of the external replica?
acl-bind bindmethod=simple binddn="cn=root DN, o=test" credentials=secret syncrepl rid=1 provider=ldaps://localhost:636/
Is that really the URI of the syncrepl master?
binddn="cn=root DN,o=test" bindmethod=simple credentials=secret searchbase="o=test" filter="(objectClass=*)" schemachecking=off scope=sub type=refreshOnly interval=00:00:00:10 retry="5 5 300 5"And on the external replica, i have : database bdb suffix "o=test" rootdn "cn=root DN, o=test" rootpw {SSHA}JDqRrNmZbCiInNsubLessizYPdmcwhgf directory /usr/products/freeware/openldap/var/openldap-slapd-sym checkpoint 64 15
You're missing the updateDN directive. And since this is supposed to be a replica, it shouldn't be generating password-hashes by itself, it should just be taking exactly what the master generated.
password-hash {SSHA}
cachesize 50000 index objectClass,entryCSN,entryUUID eq index uid pres,eq,sub index mail pres,eq,sub index cn pres,eq,sub index sn pres,eq,sub
But, the backldap failed to query the external replica. I have the following error: Sep 17 11:23:24 test-ldap backldap[28913]: [ID 702911 local4.debug] @(#) $OpenLDAP: slapd 2.3.32 (Sep 13 2007 17:58:03) $ Sep 17 11:23:25 test-ldap backldap[28914]: [ID 100111 local4.debug] slapd starting Sep 17 11:23:25 test-ldap backldap[28914]: [ID 608079 local4.debug] do_syncrep2: rid 001got search entry without control Sep 17 11:23:30 test-ldap backldap[28914]: [ID 608079 local4.debug] do_syncrep2: rid 001got search entry without control
For information, i use release 2.3.32 on Solaris 9/10.
Obsolete, update to 2.3.38...
Howard Chu wrote:
Bruno Lezoray EMSM wrote:
Howard Chu wrote:
Quanah Gibson-Mount wrote:
--On September 14, 2007 5:21:28 PM +0200 Bruno Lezoray EMSM bruno.lezoray@wh-ces.gmessaging.net wrote:
Hi all,
i want to implement a specific openldap configuration with 3 instances: 1st is a master 2nd is a syncrepl replica "and" slurpd master 3rd is a slurpd replica
Set up a pushed-base syncrepl instead of using slurpd. Slurpd is deprecated, and fully removed from OpenLDAP 2.4.
In OpenLDAP 2.3 this will require one more slapd process (while eliminating the slurpd process).
1 provider 2 regular consumer 2A back-ldap consumer 3 external replica
None of the existing (1, 2, or 3) servers' configurations need any changes. (Except, you can remove the "replica" directives from your "slurpd master" since they don't do any good, and aren't needed anyway.)
The back-ldap consumer would be set up something like:
database ldap suffix "dc=example,dc=com" rootdn "cn=Whoever" uri ldap://localhost:9013/ <---- URL of external replica
acl-bind bindmethod=simple binddn="cn=Monitor" <---- updatedn of external replica credentials=monitor <---- password for updatedn
# the usual consumer config... syncrepl rid=1 provider=ldap://localhost:9011/ binddn="cn=Manager,dc=example,dc=com" bindmethod=simple credentials=secret searchbase="dc=example,dc=com" filter="(objectClass=*)" schemachecking=off scope=sub type=refreshOnly interval=00:00:00:10 retry="5 5 300 5"
Ok. On the backldap instance, i have this configuration: database ldap suffix "o=test" rootdn "cn=root DN, o=test" rootpw {SSHA}JDqRrNmZbCiInNsubLessizYPdmcwhgf uri ldaps://10.1.1.69:1636/
Is that really the URI of the external replica?
Yes
acl-bind bindmethod=simple binddn="cn=root DN, o=test" credentials=secret syncrepl rid=1 provider=ldaps://localhost:636/
Is that really the URI of the syncrepl master?
No, it was a mistake. Sorry.
binddn="cn=root DN,o=test" bindmethod=simple credentials=secret searchbase="o=test" filter="(objectClass=*)" schemachecking=off scope=sub type=refreshOnly interval=00:00:00:10 retry="5 5 300 5"And on the external replica, i have : database bdb suffix "o=test" rootdn "cn=root DN, o=test" rootpw {SSHA}JDqRrNmZbCiInNsubLessizYPdmcwhgf directory /usr/products/freeware/openldap/var/openldap-slapd-sym checkpoint 64 15
You're missing the updateDN directive. And since this is supposed to be a replica, it shouldn't be generating password-hashes by itself, it should just be taking exactly what the master generated.
Exactly.
So, i don't need a regular consumer, except if i want to have a local database.
Thanks for your help, Howard.
Rgds, Bruno.
Howard Chu wrote:
Bruno Lezoray EMSM wrote:
Howard Chu wrote:
Quanah Gibson-Mount wrote:
--On September 14, 2007 5:21:28 PM +0200 Bruno Lezoray EMSM bruno.lezoray@wh-ces.gmessaging.net wrote:
Hi all,
i want to implement a specific openldap configuration with 3 instances: 1st is a master 2nd is a syncrepl replica "and" slurpd master 3rd is a slurpd replica
Set up a pushed-base syncrepl instead of using slurpd. Slurpd is deprecated, and fully removed from OpenLDAP 2.4.
In OpenLDAP 2.3 this will require one more slapd process (while eliminating the slurpd process).
1 provider 2 regular consumer 2A back-ldap consumer 3 external replica
To follow with the same restrictions:
Only the 2nd instance can establish TCP connections on 1st and 3rd instances. TCP connections in the other direction is forbidden >:o .
Is it possible to configure the different instances to enable replication in the both direction ? 1 <-> 2 <-> 3
Rgds, Bruno.
Bruno Lezoray EMSM wrote:
Howard Chu wrote:
In OpenLDAP 2.3 this will require one more slapd process (while eliminating the slurpd process).
1 provider 2 regular consumer 2A back-ldap consumer 3 external replica
To follow with the same restrictions:
Only the 2nd instance can establish TCP connections on 1st and 3rd instances. TCP connections in the other direction is forbidden >:o .
That was obvious, given your firewall setup.
Is it possible to configure the different instances to enable replication in the both direction ? 1 <-> 2 <-> 3
Of course, but that would be a bad idea. Think about what you're doing. The reason you put a *read-only* replica outside the firewall is because it resides on an untrusted network. If you start accepting changes from it, it's like punching a hole in your firewall and letting the outside world in.
Howard Chu wrote:
Bruno Lezoray EMSM wrote:
Howard Chu wrote:
In OpenLDAP 2.3 this will require one more slapd process (while eliminating the slurpd process).
1 provider 2 regular consumer 2A back-ldap consumer 3 external replica
To follow with the same restrictions:
Only the 2nd instance can establish TCP connections on 1st and 3rd instances. TCP connections in the other direction is forbidden >:o .
That was obvious, given your firewall setup.
Is it possible to configure the different instances to enable replication in the both direction ? 1 <-> 2 <-> 3
Of course, but that would be a bad idea. Think about what you're doing. The reason you put a *read-only* replica outside the firewall is because it resides on an untrusted network. If you start accepting changes from it, it's like punching a hole in your firewall and letting the outside world in.
It's not a untrusted network. instance 1 and 3 are in a DMZ with restricted access by firewalls several levels of firewalls. I don't know the complete details of the architecture but i am confident in it (i have no other choice).
For the moment, instance 3 can't accept modification except with the bind DN of the updatedn parameter. Which solution can i have ? - setup 2 masters and 2 back-ldap that synchronize each one in a direction ? - another solution
Rgds, Bruno.
Howard Chu wrote:
Bruno Lezoray EMSM wrote:
Howard Chu wrote:
In OpenLDAP 2.3 this will require one more slapd process (while eliminating the slurpd process).
1 provider 2 regular consumer 2A back-ldap consumer 3 external replica
To follow with the same restrictions:
Only the 2nd instance can establish TCP connections on 1st and 3rd instances. TCP connections in the other direction is forbidden >:o .
That was obvious, given your firewall setup.
Is it possible to configure the different instances to enable replication in the both direction ? 1 <-> 2 <-> 3
Of course, but that would be a bad idea. Think about what you're doing. The reason you put a *read-only* replica outside the firewall is because it resides on an untrusted network. If you start accepting changes from it, it's like punching a hole in your firewall and letting the outside world in.
I have a problem on the operational platform with the initial configuration 1 -> 2 -> 3. It looks linked to the ppolicy overlay that is available on all instances (it changes nothing if i disable it on the instances 2 and 3). I have the following error in the logs of the 3rd instance: Sep 25 17:58:29 ora-sym-rec01 RR15[20537]: [ID 249368 local5.debug] conn=0 op=166 MOD dn="ou=24458949618350,ou=partenaires,o=xxxxxxx,c=fr" Sep 25 17:58:29 ora-sym-rec01 RR15[20537]: [ID 396994 local5.debug] conn=0 op=166 MOD attr=objectClass ou refPartner dateCreation structuralObjectClass entryUUID creatorsName createTimestamp groupeFonctionnel accesApplication dateValidite description entryCSN modifiersName modifyTimestamp hasSubordinates objectClass ou refPartner structuralObjectClass entryUUID creatorsName createTimestamp groupeFonctionnel dateValidite dateCreation description entryCSN Sep 25 17:58:29 ora-sym-rec01 RR15[20537]: [ID 588225 local5.debug] conn=0 op=166 RESULT tag=103 err=16 text=modify/delete: hasSubordinates: no such attribute
The entry on the 3rd instance contains before the modification: dn: ou=24458949618350,ou=partenaires,o=xxxxxxx,c=fr structuralObjectClass: organizationalUnitPartenaireXXX entryUUID: c79b095c-eb70-102b-8d76-f115de4b6614 creatorsName: createTimestamp: 20070830181549Z entryCSN: 20070913110815Z#000002#00#000000 modifiersName: cn=PBP,ou=appli,o=xxxxxxx,c=fr modifyTimestamp: 20070913110815Z entryDN: ou=24458949618350,ou=partenaires,o=xxxxxxx,c=fr subschemaSubentry: cn=Subschema hasSubordinates: TRUE
objectClass: top objectClass: organizationalUnit objectClass: organizationalUnitPartenaireXXX ou: 24458949618350 refPartner: 24458949618350 dateCreation: 20070425083800Z groupeFonctionnel: MMBR_RES accesApplication: bandeau dateValidite: 20071231000000Z description: EDC
I don't understand why it refuse to change the hasSubordinates attribute. Any idea ?
Rgds, Bruno.
Bruno Lezoray EMSM wrote:
Howard Chu wrote:
Bruno Lezoray EMSM wrote:
Howard Chu wrote:
In OpenLDAP 2.3 this will require one more slapd process (while eliminating the slurpd process).
1 provider 2 regular consumer 2A back-ldap consumer 3 external replica
To follow with the same restrictions:
Only the 2nd instance can establish TCP connections on 1st and 3rd instances. TCP connections in the other direction is forbidden >:o .
That was obvious, given your firewall setup.
Is it possible to configure the different instances to enable replication in the both direction ? 1 <-> 2 <-> 3
Of course, but that would be a bad idea. Think about what you're doing. The reason you put a *read-only* replica outside the firewall is because it resides on an untrusted network. If you start accepting changes from it, it's like punching a hole in your firewall and letting the outside world in.
I have a problem on the operational platform with the initial configuration 1 -> 2 -> 3. It looks linked to the ppolicy overlay that is available on all instances (it changes nothing if i disable it on the instances 2 and 3). I have the following error in the logs of the 3rd instance: Sep 25 17:58:29 ora-sym-rec01 RR15[20537]: [ID 249368 local5.debug] conn=0 op=166 MOD dn="ou=24458949618350,ou=partenaires,o=xxxxxxx,c=fr" Sep 25 17:58:29 ora-sym-rec01 RR15[20537]: [ID 396994 local5.debug] conn=0 op=166 MOD attr=objectClass ou refPartner dateCreation structuralObjectClass entryUUID creatorsName createTimestamp groupeFonctionnel accesApplication dateValidite description entryCSN modifiersName modifyTimestamp hasSubordinates objectClass ou refPartner structuralObjectClass entryUUID creatorsName createTimestamp groupeFonctionnel dateValidite dateCreation description entryCSN Sep 25 17:58:29 ora-sym-rec01 RR15[20537]: [ID 588225 local5.debug] conn=0 op=166 RESULT tag=103 err=16 text=modify/delete: hasSubordinates: no such attribute
The entry on the 3rd instance contains before the modification: dn: ou=24458949618350,ou=partenaires,o=xxxxxxx,c=fr structuralObjectClass: organizationalUnitPartenaireXXX entryUUID: c79b095c-eb70-102b-8d76-f115de4b6614 creatorsName: createTimestamp: 20070830181549Z entryCSN: 20070913110815Z#000002#00#000000 modifiersName: cn=PBP,ou=appli,o=xxxxxxx,c=fr modifyTimestamp: 20070913110815Z entryDN: ou=24458949618350,ou=partenaires,o=xxxxxxx,c=fr subschemaSubentry: cn=Subschema hasSubordinates: TRUE
objectClass: top objectClass: organizationalUnit objectClass: organizationalUnitPartenaireXXX ou: 24458949618350 refPartner: 24458949618350 dateCreation: 20070425083800Z groupeFonctionnel: MMBR_RES accesApplication: bandeau dateValidite: 20071231000000Z description: EDC
I don't understand why it refuse to change the hasSubordinates attribute. Any idea ?
Rgds, Bruno
After some investigations, it doesn't seem to be linked to ppolicy. SyncREPL tries to delete the internal attribute hasSubordinates on the replica. I tried to limit the attribute list with the syncrepl parameter attrs="*,entryUUID,entryCSN,contextCSN" but it's only used for looking modified entries. When it obtains the list, it looks up each entry with the attribute list "*, +".
Few questions: - is it possible to disable the schema checking on the replica ? - is it possible to limit the list of attributes to updates ?
Rgds, Bruno.
openldap-software@openldap.org
-
Bruno Lezoray EMSM -
Howard Chu -
Quanah Gibson-Mount