openldap-technical

openldap-technical@openldap.org

1 participants
9868 discussions

extend groupOfURLs
by Carlos Santos 29 May '13

29 May '13

Greetings, I have a dynamic group whose objectclass is groupOfURLs. I want to add a few parameters to the group, such as groupname and others. However, when I go to the schema file and create my own dygroup objectclass, ldap doesn't accept groupOfURLs as dygroup's SUP objectclass. What am I doing wrong and if possible how to fix it? -- Thanks in advance, Carlos Santos

2 1

bind-dyndb-ldap and AttributeType not found
by Brendan Kearney 29 May '13

29 May '13

all, i am trying to load the bind-dyndb-ldap schema into my ldap instance and keep getting an error 'AttributeType not found: "ARecord"'. from what i can tell, the ARecord AttributeType is defined by the cosine schema, which is loaded and present in the ldap instance. I have the dnszone schema loaded too and i am serving static dns entries out of ldap right now. it would seem that the prerequisites for bind-dyndb-ldap are fulfilled, but i cant load the schema. some details: [root@server cn=schema]# slapd -V @(#) $OpenLDAP: slapd 2.4.26 (Jun 27 2012 15:27:46) $ mockbuild@x86-16.phx2.fedoraproject.org:/builddir/build/BUILD/openldap-2.4.26/openldap-2.4.26/build-servers/servers/slapd [root@server schema]# slaptest -v -d9 -f ./dns-dyndb.schema -F ../slapd.d/cn\=config/cn\=schema/ slaptest init: initiated tool. slap_sasl_init: initialized! bdb_back_initialize: initialize BDB backend bdb_back_initialize: Berkeley DB 5.2.36: (September 14, 2011) hdb_back_initialize: initialize HDB backend hdb_back_initialize: Berkeley DB 5.2.36: (September 14, 2011) null_back_initialize: initialize null backend backend_startup_one: starting "cn=config" ./dns-dyndb.schema: line 296 objectclass: AttributeType not found: "ARecord" slaptest: bad configuration directory! Since the cosine schema is loaded, the ARecord AttributeType is available for reference by this schema, but it does not seem to load. am i missing something obvious? can anyone shed light on this? to make sure i was going about this right, i also tried it this way: [root@server openldap]# cat this.out include /etc/openldap/schema/dns-dyndb.schema [root@server openldap]# slaptest -v -d9 -f /etc/openldap/this.out -F /etc/openldap/slapd.d/ slaptest init: initiated tool. slap_sasl_init: initialized! bdb_back_initialize: initialize BDB backend bdb_back_initialize: Berkeley DB 5.2.36: (September 14, 2011) hdb_back_initialize: initialize HDB backend hdb_back_initialize: Berkeley DB 5.2.36: (September 14, 2011) null_back_initialize: initialize null backend backend_startup_one: starting "cn=config" /etc/openldap/schema/dns-dyndb.schema: line 296 objectclass: AttributeType not found: "ARecord" slaptest: bad configuration directory! still got the error...

1 1

Re: ldap query performance issue
by Meike Stone 28 May '13

28 May '13

Hello, because of this, does it make sense in a directory with > 1,000,000 people to index the sex? thanks Meike 2013/5/23 Quanah Gibson-Mount <quanah(a)zimbra.com>: > --On Thursday, May 23, 2013 4:40 PM +0000 Chris Card <ctcard(a)hotmail.com> > wrote: > >> Hi all, >> >> I have an openldap directory with about 7 million DNs, running openldap >> 2.4.31 with a BDB backend (4.6.21), running on CentOS 6.3. >> >> The structure of the directory is like this, with suffix dc=x,dc=y >> >> dc=x,dc=y >> account=a,dc=x,dc=y >> mail=m,account=a,dc=x,dc=y // Users >> .... >> licenceId=l,account=a,dc=x,dc=y // Licences, >> objectclass=licence .... >> group=g,account=a,dc=x,dc=y // Groups >> .... >> // etc. >> >> account=b,dc=x,dc=y >> .... >> >> Most of the DNs in the directory are users or groups, and the number of >> licences is small (<10) for each account. >> >> If I do a query with basedn account=a,dc=x,dc=y and filter >> (objectclass=licence) I see wildly different performance, depending on >> how many users are under account a. For an account with ~30000 users the >> query takes 2 seconds at most, but for an account with ~60000 users the >> query takes 1 minute. >> >> It only appears to be when I filter on objectclass=licence that I see >> that behaviour. If I filter on a different objectclass which matches a >> similar number of objects to the objectclass=licence filter, the >> performance doesn't seem to depend on the number of users. >> >> There is an index on objectclass (of course), but the behaviour I'm >> seeing seems to indicate that for this query, at some point slapd stops >> using the index and just scans all the objects under the account. >> >> Any ideas? > > > Increase the IDL range. This is how I do it: > > --- openldap-2.4.35/servers/slapd/back-bdb/idl.h.orig 2011-02-17 > 16:32:02.598593211 -0800 > +++ openldap-2.4.35/servers/slapd/back-bdb/idl.h 2011-02-17 > 16:32:08.937757993 -0800 > @@ -20,7 +20,7 @@ > /* IDL sizes - likely should be even bigger > * limiting factors: sizeof(ID), thread stack size > */ > -#define BDB_IDL_LOGN 16 /* DB_SIZE is 2^16, UM_SIZE is 2^17 > */ > +#define BDB_IDL_LOGN 17 /* DB_SIZE is 2^16, UM_SIZE is 2^17 > */ > #define BDB_IDL_DB_SIZE (1<<BDB_IDL_LOGN) > #define BDB_IDL_UM_SIZE (1<<(BDB_IDL_LOGN+1)) > #define BDB_IDL_UM_SIZEOF (BDB_IDL_UM_SIZE * sizeof(ID)) > > > --Quanah > > -- > > Quanah Gibson-Mount > Sr. Member of Technical Staff > Zimbra, Inc > A Division of VMware, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration >

2 4

RE: ldap query performance issue
by Chris Card 28 May '13

28 May '13

---------------------------------------- > From: ctcard(a)hotmail.com > To: quanah(a)zimbra.com > Subject: RE: ldap query performance issue > Date: Thu, 23 May 2013 17:37:18 +0000 > > ---------------------------------------- >> Date: Thu, 23 May 2013 10:06:51 -0700 >> From: quanah(a)zimbra.com >> To: ctcard(a)hotmail.com; openldap-technical(a)openldap.org >> Subject: Re: ldap query performance issue >> >> --On Thursday, May 23, 2013 4:40 PM +0000 Chris Card <ctcard(a)hotmail.com> >> wrote: >> >>> Hi all, >>> >>> I have an openldap directory with about 7 million DNs, running openldap >>> 2.4.31 with a BDB backend (4.6.21), running on CentOS 6.3. >>> >>> The structure of the directory is like this, with suffix dc=x,dc=y >>> >>> dc=x,dc=y >>> account=a,dc=x,dc=y >>> mail=m,account=a,dc=x,dc=y // Users >>> .... >>> licenceId=l,account=a,dc=x,dc=y // Licences, >>> objectclass=licence .... >>> group=g,account=a,dc=x,dc=y // Groups >>> .... >>> // etc. >>> >>> account=b,dc=x,dc=y >>> .... >>> >>> Most of the DNs in the directory are users or groups, and the number of >>> licences is small (<10) for each account. >>> >>> If I do a query with basedn account=a,dc=x,dc=y and filter >>> (objectclass=licence) I see wildly different performance, depending on >>> how many users are under account a. For an account with ~30000 users the >>> query takes 2 seconds at most, but for an account with ~60000 users the >>> query takes 1 minute. >>> >>> It only appears to be when I filter on objectclass=licence that I see >>> that behaviour. If I filter on a different objectclass which matches a >>> similar number of objects to the objectclass=licence filter, the >>> performance doesn't seem to depend on the number of users. >>> >>> There is an index on objectclass (of course), but the behaviour I'm >>> seeing seems to indicate that for this query, at some point slapd stops >>> using the index and just scans all the objects under the account. >>> >>> Any ideas? >> >> Increase the IDL range. This is how I do it: >> >> --- openldap-2.4.35/servers/slapd/back-bdb/idl.h.orig 2011-02-17 >> 16:32:02.598593211 -0800 >> +++ openldap-2.4.35/servers/slapd/back-bdb/idl.h 2011-02-17 >> 16:32:08.937757993 -0800 >> @@ -20,7 +20,7 @@ >> /* IDL sizes - likely should be even bigger >> * limiting factors: sizeof(ID), thread stack size >> */ >> -#define BDB_IDL_LOGN 16 /* DB_SIZE is 2^16, UM_SIZE is 2^17 >> */ >> +#define BDB_IDL_LOGN 17 /* DB_SIZE is 2^16, UM_SIZE is 2^17 >> */ >> #define BDB_IDL_DB_SIZE (1<<BDB_IDL_LOGN) >> #define BDB_IDL_UM_SIZE (1<<(BDB_IDL_LOGN+1)) >> #define BDB_IDL_UM_SIZEOF (BDB_IDL_UM_SIZE * sizeof(ID)) > Thanks, that looks like it might be the issue. Unfortunately I only see the issue in production, so patching it might be a pain. I've tried this change, but it made no difference to the performance of the query. Chris

4 6

[lmdb] MDB_BAD_RSLOT for mdb_txn_get()
by Ben Johnson 24 May '13

24 May '13

I'm using the gomdb interface so I'll do my best to translate this to the C calls. I'm performing an mdb_txn_put(), committing the transaction and then later I'm opening a new read-only transaction where I do an mdb_txn_get() and I receive a "MDB_BAD_RSLOT: Invalid reuse of reader locktable slot" error. When I switch the second transaction to not be read-only then the error goes away and it works fine. I checked the LMDB code and on line 1798, it's checking: if (r->mr_pid != env->me_pid || r->mr_txnid != (txnid_t)-1) return MDB_BAD_RSLOT; The r->mr_pid == env->me_pid (I'm only running one process) and the r->mr_txnid is 0 and the txnid_t is 0 (so the txnid_t - 1 is -1). I started going down the rabbit hole to figure this out further but I don't understand the locktable setup entirely. Am I doing something wrong with how I'm creating read-only transactions? Ben Johnson ben(a)skylandlabs.com

2 1

Can I distribute salted-hashed passwords on different machines?
by Marco Pizzoli 23 May '13

23 May '13

Hi all, I think I already know the answer, but I would like to be absolutely sure about it. Could I generate a {SSHA1} hash of a password (to be used for the rootdn account) with the help of slappasswd utility on a system and reuse that salted hash for the very same purpose but on a different operating system? Thanks in advance again Marco

3 2

ldap query performance issue
by Chris Card 23 May '13

23 May '13

Hi all, I have an openldap directory with about 7 million DNs, running openldap 2.4.31 with a BDB backend (4.6.21), running on CentOS 6.3. The structure of the directory is like this, with suffix dc=x,dc=y dc=x,dc=y account=a,dc=x,dc=y mail=m,account=a,dc=x,dc=y // Users .... licenceId=l,account=a,dc=x,dc=y // Licences, objectclass=licence .... group=g,account=a,dc=x,dc=y // Groups .... // etc. account=b,dc=x,dc=y .... Most of the DNs in the directory are users or groups, and the number of licences is small (<10) for each account. If I do a query with basedn account=a,dc=x,dc=y and filter (objectclass=licence) I see wildly different performance, depending on how many users are under account a. For an account with ~30000 users the query takes 2 seconds at most, but for an account with ~60000 users the query takes 1 minute. It only appears to be when I filter on objectclass=licence that I see that behaviour. If I filter on a different objectclass which matches a similar number of objects to the objectclass=licence filter, the performance doesn't seem to depend on the number of users. There is an index on objectclass (of course), but the behaviour I'm seeing seems to indicate that for this query, at some point slapd stops using the index and just scans all the objects under the account. Any ideas? Chris

2 1

Invalid manager attribute when in form 1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB
by Soulier, Marcel 23 May '13

23 May '13

Hi, I am trying to import the following ldif file into openldap and get the error message "manager: value #0 invalid per syntax". test.ldif: dn: cn=test,o=users,dc=example,dc=com objectClass: top objectClass: person cn: test manager: 1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB Console output: adding new entry "cn=test,o=users,dc=example,dc=com" ldap_add: Invalid syntax (21) additional info: manager: value #0 invalid per syntax According to the cosine.schema the value of the manager attribute should have the EQUALITY distinguishedNameMatch, SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 The value "1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB" is taken from the examples provided for DN in rfc2252 and works fine in open-ds. So I would expect it to work in openldap as well. What am I missing? Marcel Marcel.Soulier(a)opitz-consulting.com<mailto:Marcel.Soulier@opitz-consulting.com>

3 4

Deadlock problem on objectClass.bdb
by Maxim Shaposhnik 23 May '13

23 May '13

Hi, I'm faced with the OpenLDAP freeze problem on concurrent item modification. OS type\version is FC17, OpenLDAP 2.4.35. Tried both BerkrleyDB versions 5.2.36 and latest 5.3.21. DB size is about 50K. >From my experiments, LDAP stops responding when the count of locks on objectClass.bdb reaches 3 (when less than 3, seems it resolves OK): 80000573 READ 3 HELD objectClass.bdb page 3 80000573 WRITE 7 HELD objectClass.bdb page 3 800001b6 READ 1 WAIT objectClass.bdb page 3 I also tried different locks detector schemes (different values for set_lk_detect ) without success. What may be a root cause of such situation? This is my full db_stat output: db_stat -CA Default locking region information: 19 Last allocated locker ID 0x7fffffff Current maximum unused locker ID 9 Number of lock modes 200 Initial number of locks allocated 0 Initial number of lockers allocated 200 Initial number of lock objects allocated 3000 Maximum number of locks possible 1500 Maximum number of lockers possible 1500 Maximum number of lock objects possible 200 Current number of locks allocated 15 Current number of lockers allocated 200 Current number of lock objects allocated 40 Number of lock object partitions 2053 Size of object hash table 46 Number of current locks 115 Maximum number of locks at any one time 6 Maximum number of locks in any one bucket 11 Maximum number of locks stolen by for an empty partition 4 Maximum number of locks stolen for any one partition 13 Number of current lockers 15 Maximum number of lockers at any one time 26 Number of current lock objects 74 Maximum number of lock objects at any one time 2 Maximum number of lock objects in any one bucket 0 Maximum number of objects stolen by for an empty partition 0 Maximum number of objects stolen for any one partition 88126 Total number of locks requested 87895 Total number of locks released 0 Total number of locks upgraded 16 Total number of locks downgraded 174 Lock requests not available due to conflicts, for which we waited 153 Lock requests not available due to conflicts, for which we did not wait 11 Number of deadlocks 0 Lock timeout value 0 Number of locks that have timed out 0 Transaction timeout value 0 Number of transactions that have timed out 2MB 504KB Region size 16 The number of partition locks that required waiting (0%) 8 The maximum number of times any partition lock was waited for (0%) 0 The number of object queue operations that required waiting (0%) 1 The number of locker allocations that required waiting (0%) 2 The number of region locks that required waiting (0%) 2 Maximum hash bucket length =-=-=-=-=-=-=-=-=-=-=-=-=-=-=- =-=-=-=-=-=-=-=-=-= Lock REGINFO information: Environment Region type 1 Region ID __db.001 Region name 0x7fc6ffe7f000 Region address 0x7fc6ffe7f0a0 Region allocation head 0x7fc70007f5b0 Region primary address 0 Region maximum allocation 0 Region allocated Region allocations: 2874 allocations, 0 failures, 2750 frees, 7 longest Allocations by power-of-two sizes: 1KB 2869 2KB 0 4KB 1 8KB 0 16KB 0 32KB 0 64KB 2 128KB 0 256KB 1 512KB 0 1024KB 1 REGION_SHARED Region flags =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Lock region parameters: 2 Lock region region mutex [2/59655 0% 25161/140492677707584] <wakeups 0/1> 2053 locker table size 2053 object table size 2099280 obj_off 2316456 locker_off 1 need_dd =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Lock conflict matrix: =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Locks grouped by lockers: Locker Mode Count Status ----------------- Object --------------- e dd=11 locks held 1 write locks 0 pid/thread 23242/140324977571648 flags 10 priority 100 e READ 1 HELD id2entry.bdb handle 0 f dd=10 locks held 1 write locks 0 pid/thread 23242/140324977571648 flags 10 priority 100 f READ 1 HELD dn2id.bdb handle 0 10 dd= 9 locks held 0 write locks 0 pid/thread 23242/140324977571648 flags 0 priority 100 11 dd= 6 locks held 1 write locks 0 pid/thread 23242/140324451448576 flags 10 priority 100 11 READ 1 HELD objectClass.bdb handle 0 12 dd= 5 locks held 1 write locks 0 pid/thread 23242/140324451448576 flags 10 priority 100 12 READ 1 HELD cloudIdeAliases.bdb handle 0 13 dd= 4 locks held 1 write locks 0 pid/thread 23242/140324451448576 flags 10 priority 100 13 READ 1 HELD ou.bdb handle 0 8000019c dd= 8 locks held 0 write locks 0 pid/thread 23242/140324977571648 flags 0 priority 100 8000019d dd= 7 locks held 0 write locks 0 pid/thread 23242/140324451448576 flags 0 priority 100 800001a1 dd= 3 locks held 0 write locks 0 pid/thread 23242/140324443055872 flags 0 priority 100 800001b6 dd= 2 locks held 0 write locks 0 pid/thread 23242/140324332623616 flags 0 priority 100 800001b6 READ 1 WAIT objectClass.bdb page 3 8000045f dd= 1 locks held 1 write locks 1 pid/thread 23242/140324164859648 flags 0 priority 100 8000045f WRITE 1 HELD cloudIdeAliases.bdb page 5337 80000572 dd= 0 locks held 2 write locks 0 pid/thread 23242/140324451448576 flags 0 priority 100 80000572 READ 1 HELD 0x23f140 len: 9 data: 020000000000000000 80000572 READ 1 HELD dn2id.bdb page 10752 80000573 dd= 0 locks held 36 write locks 19 pid/thread 23242/140324451448576 flags 0 priority 100 80000573 READ 1 WAIT cloudIdeAliases.bdb page 5337 80000573 WRITE 1 HELD cloudIdeAliases.bdb page 4604 80000573 READ 1 HELD cloudIdeAliases.bdb page 4604 80000573 WRITE 1 HELD cloudIdeAliases.bdb page 6375 80000573 READ 1 HELD cloudIdeAliases.bdb page 6375 80000573 WRITE 1 HELD cloudIdeAliases.bdb page 200 80000573 READ 1 HELD cloudIdeAliases.bdb page 200 80000573 WRITE 1 HELD cloudIdeAliases.bdb page 1438 80000573 READ 1 HELD cloudIdeAliases.bdb page 1438 80000573 WRITE 1 HELD cloudIdeAliases.bdb page 16 80000573 READ 1 HELD cloudIdeAliases.bdb page 16 80000573 WRITE 1 HELD cloudIdeAliases.bdb page 286 80000573 READ 1 HELD cloudIdeAliases.bdb page 286 80000573 WRITE 1 HELD cloudIdeAliases.bdb page 2308 80000573 READ 1 HELD cloudIdeAliases.bdb page 2308 80000573 WRITE 1 HELD cloudIdeAliases.bdb page 4708 80000573 READ 1 HELD cloudIdeAliases.bdb page 4708 80000573 WRITE 1 HELD cloudIdeAliases.bdb page 123 80000573 READ 1 HELD cloudIdeAliases.bdb page 123 80000573 WRITE 1 HELD cloudIdeAliases.bdb page 540 80000573 READ 1 HELD cloudIdeAliases.bdb page 540 80000573 WRITE 1 HELD cloudIdeAliases.bdb page 4737 80000573 READ 1 HELD cloudIdeAliases.bdb page 4737 80000573 WRITE 1 HELD cloudIdeAliases.bdb page 2806 80000573 READ 1 HELD cloudIdeAliases.bdb page 2806 80000573 WRITE 1 HELD ou.bdb page 271 80000573 READ 1 HELD ou.bdb page 271 80000573 WRITE 7 HELD objectClass.bdb page 3 80000573 READ 3 HELD objectClass.bdb page 3 80000573 WRITE 3 HELD objectClass.bdb page 2 80000573 READ 1 HELD objectClass.bdb page 2 80000573 WRITE 1 HELD dn2id.bdb page 10234 80000573 READ 1 HELD dn2id.bdb page 10234 80000573 WRITE 1 HELD dn2id.bdb page 2 80000573 READ 1 HELD dn2id.bdb page 2 80000573 WRITE 1 HELD dn2id.bdb page 10225 80000573 WRITE 1 HELD dn2id.bdb page 10752 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Locks grouped by object: Locker Mode Count Status ----------------- Object --------------- 80000573 READ 1 HELD cloudIdeAliases.bdb page 4604 80000573 WRITE 1 HELD cloudIdeAliases.bdb page 4604 80000573 READ 1 HELD cloudIdeAliases.bdb page 4708 80000573 WRITE 1 HELD cloudIdeAliases.bdb page 4708 80000573 READ 1 HELD cloudIdeAliases.bdb page 540 80000573 WRITE 1 HELD cloudIdeAliases.bdb page 540 13 READ 1 HELD ou.bdb handle 0 80000573 READ 1 HELD cloudIdeAliases.bdb page 2806 80000573 WRITE 1 HELD cloudIdeAliases.bdb page 2806 80000573 READ 1 HELD cloudIdeAliases.bdb page 4737 80000573 WRITE 1 HELD cloudIdeAliases.bdb page 4737 80000573 READ 1 HELD ou.bdb page 271 80000573 WRITE 1 HELD ou.bdb page 271 80000572 READ 1 HELD dn2id.bdb page 10752 80000573 WRITE 1 HELD dn2id.bdb page 10752 e READ 1 HELD id2entry.bdb handle 0 8000045f WRITE 1 HELD cloudIdeAliases.bdb page 5337 80000573 READ 1 WAIT cloudIdeAliases.bdb page 5337 80000573 READ 1 HELD cloudIdeAliases.bdb page 1438 80000573 WRITE 1 HELD cloudIdeAliases.bdb page 1438 f READ 1 HELD dn2id.bdb handle 0 80000573 READ 1 HELD dn2id.bdb page 2 80000573 WRITE 1 HELD dn2id.bdb page 2 80000572 READ 1 HELD 0x23f140 len: 9 data: 020000000000000000 80000573 READ 1 HELD dn2id.bdb page 10234 80000573 WRITE 1 HELD dn2id.bdb page 10234 80000573 WRITE 1 HELD dn2id.bdb page 10225 80000573 READ 1 HELD cloudIdeAliases.bdb page 123 80000573 WRITE 1 HELD cloudIdeAliases.bdb page 123 12 READ 1 HELD cloudIdeAliases.bdb handle 0 80000573 READ 1 HELD cloudIdeAliases.bdb page 16 80000573 WRITE 1 HELD cloudIdeAliases.bdb page 16 80000573 READ 1 HELD cloudIdeAliases.bdb page 200 80000573 WRITE 1 HELD cloudIdeAliases.bdb page 200 80000573 READ 1 HELD cloudIdeAliases.bdb page 6375 80000573 WRITE 1 HELD cloudIdeAliases.bdb page 6375 80000573 READ 3 HELD objectClass.bdb page 3 80000573 WRITE 7 HELD objectClass.bdb page 3 800001b6 READ 1 WAIT objectClass.bdb page 3 80000573 READ 1 HELD objectClass.bdb page 2 80000573 WRITE 3 HELD objectClass.bdb page 2 11 READ 1 HELD objectClass.bdb handle 0 80000573 READ 1 HELD cloudIdeAliases.bdb page 2308 80000573 WRITE 1 HELD cloudIdeAliases.bdb page 2308 80000573 READ 1 HELD cloudIdeAliases.bdb page 286 80000573 WRITE 1 HELD cloudIdeAliases.bdb page 286

2 3

Syncrepl and selected subtrees
by Marco Pizzoli 23 May '13

23 May '13

Hi all, I would like a hint on how to syncreplicate only a group of subtrees from a master DIT. In example, if I have a BaseDN called "ou=root,dc=my_domain" with 4 subtrees at the first nesting level (ou=subtree1, ou=subtree2, and so on..), how can I configure a slave to syncrepl only subtree1 and subtree3? Graphically: ou=root,dc=my_domain |- ou=subtree1 |- ou=subtree2 |- ou=subtree3 |- ou=subtree4 Of course, I could use a dedicated user with ACL-masqueraded data to her, but what if I couldn't? Is there a way to express this purpose on the "replica" configuration? Thanks in advance Marco

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical