8:21 a.m.
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.
2:32 p.m.
--On September 14, 2007 5:21:28 PM +0200 Bruno Lezoray EMSM
<bruno.lezoray(a)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
6:30 p.m.
Quanah Gibson-Mount wrote:
--On September 14, 2007 5:21:28 PM +0200 Bruno Lezoray EMSM
<bruno.lezoray(a)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
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
2:43 a.m.
Howard Chu wrote:
Quanah Gibson-Mount wrote:
> --On September 14, 2007 5:21:28 PM +0200 Bruno Lezoray EMSM
> <bruno.lezoray(a)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.
6:21 a.m.
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(a)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
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
8:33 a.m.
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(a)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.
2:07 a.m.
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(a)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.
9:27 a.m.
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
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
12:37 a.m.
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.
9:38 a.m.
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.
2:32 a.m.
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.
5913
days inactive
5925
days old
openldap-software@openldap.org
10 comments
3 participants
participants (3)
-
Bruno Lezoray EMSM -
Howard Chu -
Quanah Gibson-Mount