openldap-technical

openldap-technical@openldap.org

9 participants
9902 discussions

Syncrepl initial sync provider sends entries in wrong order
by Γ. Μηλιώτης 29 Sep '16

29 Sep '16

Hello everyone, I'm wondering if a syncrepl behaviour I'm seeing is correct. My consumer is 4.4.42 and my provider 4.4.40. I'm using refreshOnly replication and when I first create the database entry on the consumer the whole process stops after 5-6 records. I have tested the syncuser and its searches against the provider return >9000 results. So it's not a limit or auth issue. I have matched the schemas on both servers successfully. I believe the issue is that the provider is sending the records in an incorrect order. I get a record with an entryCSN in 20151001 and then a record with an entryCSN before that. So, if I understand it, operating correctly, the consumer complains the record is too old and ignores it, stopping replication. The contextCSN of the provider is in the 2016* range, the consumer's is stuck in 2015* range and the log spams "too old". I'm using the -c rid=XXX option to run slapd and deleting the DB between tests. Shouldn't the provider send the entries in a entryCSN-ascending order during the initial sync? Thanks for any insight you can provide. --GM

1 0

N-Way replication
by rammohan ganapavarapu 28 Sep '16

28 Sep '16

Hi, I have n-way replication setup in ldap version 2.4.43 and i have basic technical question, do we have to specify nth server details in replication config? lets say i have server1 server2 and server3 and i wanted to setup n-way replication among these servers Part of my config looks like this # Global section serverID 1 ldap://server1 serverID 2 ldap://server2 serverID 3 ldap://server3 # database section # syncrepl directive syncrepl rid=001 provider=ldap://server1 syncrepl rid=002 provider=ldap://server2 syncrepl rid=003 provider=ldap://server3 mirrormode on So if i include the nth server itlsef in the replication provider doesn't it try to replicate it self and get it into loop condition? Please advice Thanks, Ram

1 0

Re: Fwd: Using lmdb as a pure in memory store
by Howard Chu 22 Sep '16

22 Sep '16

Russell Haley wrote: > Thanks so much for your response and thanks for the link. I've been > pouring over that documentation off and on. > > The developer currently doing the prototyping has said he ran into an > issue where the use of a very large key value caused the system to > slow down (he didn't give specifics and I didn't have time to ask). He > said it was a sparsely populated record set of about 100,00 rows but > he specifically used a large value for the key as we hope to support > UInt64 for keys (I don't know why, apparently we're indexing > sub-atomic particles?). I saw a setting for MDB_MAXKEYSIZE which was > 0 for computed, but I don't know what that means on an ARM (v6 - 32 > bit) system. Would you have any idea what would cause the performance > hit he was referring too? At a guess, you're slowing down because you're using 64bit values on a 32bit processor and once you exceed the range of a 32bit integer you need twice as many memory accesses to fetch/compare keys. Anyway, if you're using MDB_INTEGERKEY (which you should be, in this case) then you'll never get anywhere near the max keysize. > Sorry if my questions are weird, I'm trying to learn C and embedded > development through osmosis. > > Anyway, on a personal note, I was thoroughly happy to get lmdb working > in Lua through > > https://github.com/shmul/lightningmdb > > and can't wait to try his Mule Round-Robin Database tool > > https://github.com/shmul/mule > > Awesome stuff. > > Russ > > > On Thu, Sep 22, 2016 at 4:25 PM, Howard Chu <hyc(a)symas.com> wrote: >> Russell Haley wrote: >>> >>> Hello, >>> >>> I wasn't fully subscribed when I sent this so I'll send it again. >>> >>> Any input or reference hints would be great. I love reading manuals. :) >> >> >> http://lmdb.tech/doc/ >>> >>> >>> Russ >>> >>> >>> ---------- Forwarded message ---------- >>> From: Russell Haley <russ.haley(a)gmail.com> >>> Date: Tue, Sep 20, 2016 at 4:52 PM >>> Subject: Using lmdb as a pure in memory store >>> To: openldap-technical(a)openldap.org >>> >>> >>> Hi there, >>> >>> We are currently evaluating in memory key value stores for ~100,000 - >>> 200,000 records in an embedded system. I suggested lmdb but it is >>> being discounted for some reasons I thought I'd validate: >>> >>> 1) It is currently thought that a on disk file is REQUIRED for the >>> system. Does MDB_NOSYNC turn off the disk caching? Can it be run as a >>> pure in-memory database? Could the file not just be mapped to a >>> memdisk? >> >> >> A file is required. Whether the file is on-disk or not is irrelevant. It can >> of course be on a RAMdisk (or, in Linux, a tmpfs), which would then make it >> pure in-memory. >> >> MDB_NOSYNC turns off syncing, that's why it is named that. >> >>> 2) Because these values can come very fast, that the use of a lock >>> file would cause delay and too much wear on the nand based disk (SSD). >> >> >> No. That's not how the lock file is used. >> >>> I see a no locking option ( MDB_NOLOCK) that would stop a lock file >>> being written. >> >> >> This option should only be used if you're implementing your own lock >> manager. Hint - no matter what approach you use, any other lock manager you >> use will be slower than LMDB's. >> >>> Again, another option would be mapping the lock file to >>> a memdisk to handle that? >> >> >> Yes. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: Fwd: Using lmdb as a pure in memory store
by Howard Chu 22 Sep '16

22 Sep '16

Russell Haley wrote: > Hello, > > I wasn't fully subscribed when I sent this so I'll send it again. > > Any input or reference hints would be great. I love reading manuals. :) http://lmdb.tech/doc/ > > Russ > > > ---------- Forwarded message ---------- > From: Russell Haley <russ.haley(a)gmail.com> > Date: Tue, Sep 20, 2016 at 4:52 PM > Subject: Using lmdb as a pure in memory store > To: openldap-technical(a)openldap.org > > > Hi there, > > We are currently evaluating in memory key value stores for ~100,000 - > 200,000 records in an embedded system. I suggested lmdb but it is > being discounted for some reasons I thought I'd validate: > > 1) It is currently thought that a on disk file is REQUIRED for the > system. Does MDB_NOSYNC turn off the disk caching? Can it be run as a > pure in-memory database? Could the file not just be mapped to a > memdisk? A file is required. Whether the file is on-disk or not is irrelevant. It can of course be on a RAMdisk (or, in Linux, a tmpfs), which would then make it pure in-memory. MDB_NOSYNC turns off syncing, that's why it is named that. > 2) Because these values can come very fast, that the use of a lock > file would cause delay and too much wear on the nand based disk (SSD). No. That's not how the lock file is used. > I see a no locking option ( MDB_NOLOCK) that would stop a lock file > being written. This option should only be used if you're implementing your own lock manager. Hint - no matter what approach you use, any other lock manager you use will be slower than LMDB's. > Again, another option would be mapping the lock file to > a memdisk to handle that? Yes. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

Fwd: Using lmdb as a pure in memory store
by Russell Haley 22 Sep '16

22 Sep '16

Hello, I wasn't fully subscribed when I sent this so I'll send it again. Any input or reference hints would be great. I love reading manuals. :) Russ ---------- Forwarded message ---------- From: Russell Haley <russ.haley(a)gmail.com> Date: Tue, Sep 20, 2016 at 4:52 PM Subject: Using lmdb as a pure in memory store To: openldap-technical(a)openldap.org Hi there, We are currently evaluating in memory key value stores for ~100,000 - 200,000 records in an embedded system. I suggested lmdb but it is being discounted for some reasons I thought I'd validate: 1) It is currently thought that a on disk file is REQUIRED for the system. Does MDB_NOSYNC turn off the disk caching? Can it be run as a pure in-memory database? Could the file not just be mapped to a memdisk? 2) Because these values can come very fast, that the use of a lock file would cause delay and too much wear on the nand based disk (SSD). I see a no locking option ( MDB_NOLOCK) that would stop a lock file being written. Again, another option would be mapping the lock file to a memdisk to handle that? Thanks! Russ

1 0

How to move from hdb to mdb
by Nikolas Stylianides 22 Sep '16

22 Sep '16

Hi there. Is there a howto move from hdb to mdb? What we need to do is to transfer our directory from hdb to the mdb. Is there a book to learn about openldap? With the new OLC way of doing things? Can i have hdb and mdb running at the same time? Currently I have done the following: 1. Load the Module back_mdb 2. Created a OlcBackend 3. Created a OlcDatabase Thank you in advance -- Δρ. Νικόλας Στυλιανίδης Ηλεκτρολόγος Μηχανικός και Μηχ. Υπολογιστών Nikolas Stylianides, Dr. Dr. Eng. in Electrical & Computer Engineering Contacts ------------- Mobile Tel.: +35796741315 Email: nstylianides(a)leafnet.com.cy, nstylianides(a)gmail.com Skype: nicostyl Affilication --------------- LEAF NET LTD: Research & Development Open University of Cyprus: Research Associate, APPLIED HEALTH INFORMATICS Master Programme Academic Board Member Tο λακωνίζειν εστί φιλοσοφείν / Μηδέν Άγαν - Χίλων ο Λακεδαιμόνιος: Brevity is the soul of wit - Shakespeare William (Hamlet)

5 7

ACL privilege for MOD_INCREMENT
by Michael Ströder 20 Sep '16

20 Sep '16

HI! Considering to use LDAP write operations with MOD_INCREMENT with pre-read-control for uidNumber/gidNumber generation I'd like to reduce write access to an Integer attribute "nextID" to MOD_INCREMENT. (Uniqueness is achieved with slapo-unique anyway but still I'd like to avoid users messing with this attribute). I suspect the ideal solution results in a feature request for a new privilege "i". ;-) access to attrs=nextID by group=... =ri Or at least avoid that someone sets the value to a lower value. Maybe this can be achieved with slapo-constraint. Any more ideas? Ciao, Michael.

1 0

Re: Does everybody end up writing their own directory management programs?
by Shawn McKinney 20 Sep '16

20 Sep '16

> On Sep 18, 2016, at 2:25 PM, John Lewis <oflameo2(a)gmail.com> wrote: > > Right now I am trying to weigh my options for maintaining my POSIX > accounts on an OpenLDAP tree. > > I learned today that ldap templates in ldapscripts really don't work, so > if I want to go on using ldapscripts, I would have to run ldapmodify > after every account is created to get the gecos configured properly and > have a kerberos principal configured. You could use an IdM product like midPoint to manage the RFC2307ish attributes in the directory. https://wiki.evolveum.com/display/midPoint/LDAP+PosixAccount+and+PosixGroup…

4 3

do_syncrep2: rid=001 (32) No such object
by Fabrizio Monti 19 Sep '16

19 Sep '16

Hi, I have configurated two servers centos 7 with openldap-2.4.40-9, provider and Customer. There's an error in the log file with the syncreply: "do_syncrep2: rid=001 (32) No such object", but I cannot understand where's the mistake; could you help me please? thanks in advance provider's log: *Sep 19 12:31:40 ldap slapd[27741]: daemon: epoll: listen=7 active_threads=0 tvp=zero* *Sep 19 12:31:40 ldap slapd[27741]: daemon: epoll: listen=8 active_threads=0 tvp=zero* *Sep 19 12:31:40 ldap slapd[27741]: daemon: epoll: listen=9 active_threads=0 tvp=zero* *Sep 19 12:31:40 ldap slapd[27741]: daemon: epoll: listen=10 active_threads=0 tvp=zero* *Sep 19 12:31:40 ldap slapd[27741]: daemon: epoll: listen=11 active_threads=0 tvp=zero* *Sep 19 12:31:40 ldap slapd[27741]: =>do_syncrepl rid=001* *Sep 19 12:31:40 ldap slapd[27741]: =>do_syncrep2 rid=001* *Sep 19 12:31:40 ldap slapd[27741]: do_syncrep2: rid=001 LDAP_RES_SEARCH_RESULT* *Sep 19 12:31:40 ldap slapd[27741]: do_syncrep2: rid=001 LDAP_RES_SEARCH_RESULT (32) No such object* *Sep 19 12:31:40 ldap slapd[27741]: do_syncrep2: rid=001 (32) No such object* *Sep 19 12:36:40 ldap slapd[27741]: daemon: epoll: listen=7 active_threads=0 tvp=zero* *Sep 19 12:36:40 ldap slapd[27741]: daemon: epoll: listen=8 active_threads=0 tvp=zero* *Sep 19 12:36:40 ldap slapd[27741]: daemon: epoll: listen=9 active_threads=0 tvp=zero* *Sep 19 12:36:40 ldap slapd[27741]: daemon: epoll: listen=10 active_threads=0 tvp=zero* *Sep 19 12:36:40 ldap slapd[27741]: daemon: epoll: listen=11 active_threads=0 tvp=zero* *Sep 19 12:36:40 ldap slapd[27741]: =>do_syncrepl rid=001* *Sep 19 12:36:40 ldap slapd[27741]: =>do_syncrep2 rid=001* *Sep 19 12:36:40 ldap slapd[27741]: do_syncrep2: rid=001 LDAP_RES_SEARCH_RESULT* *Sep 19 12:36:40 ldap slapd[27741]: do_syncrep2: rid=001 LDAP_RES_SEARCH_RESULT (32) No such object* *Sep 19 12:36:40 ldap slapd[27741]: do_syncrep2: rid=001 (32) No such object* customer's log: *Sep 19 12:41:40 ldap2 slapd[618]: daemon: activity on 1 descriptor* *Sep 19 12:41:40 ldap2 slapd[618]: daemon: activity on:* *Sep 19 12:41:40 ldap2 slapd[618]:* *Sep 19 12:41:40 ldap2 slapd[618]: slap_listener_activate(8):* *Sep 19 12:41:40 ldap2 slapd[618]: daemon: epoll: listen=7 active_threads=0 tvp=NULL* *Sep 19 12:41:40 ldap2 slapd[618]: daemon: epoll: listen=8 busy* *Sep 19 12:41:40 ldap2 slapd[618]: daemon: epoll: listen=9 active_threads=0 tvp=NULL* *Sep 19 12:41:40 ldap2 slapd[618]: daemon: epoll: listen=10 active_threads=0 tvp=NULL* *Sep 19 12:41:40 ldap2 slapd[618]: daemon: epoll: listen=11 active_threads=0 tvp=NULL* *Sep 19 12:41:40 ldap2 slapd[618]: >>> slap_listener(ldap:///)* *Sep 19 12:41:40 ldap2 slapd[618]: daemon: listen=8, new connection on 13* *Sep 19 12:41:40 ldap2 slapd[618]: daemon: added 13r (active) listener=(nil)* *Sep 19 12:41:40 ldap2 slapd[618]: conn=1097 fd=13 ACCEPT from IP=192.168.235.45:57122 <http://192.168.235.45:57122> (IP=0.0.0.0:389 <http://0.0.0.0:389>)* *Sep 19 12:41:40 ldap2 slapd[618]: daemon: activity on 2 descriptors* *Sep 19 12:41:40 ldap2 slapd[618]: daemon: activity on:* *Sep 19 12:41:40 ldap2 slapd[618]: 13r* *Sep 19 12:41:40 ldap2 slapd[618]:* *Sep 19 12:41:40 ldap2 slapd[618]: daemon: read active on 13* *Sep 19 12:41:40 ldap2 slapd[618]: daemon: epoll: listen=7 active_threads=0 tvp=NULL* *Sep 19 12:41:40 ldap2 slapd[618]: daemon: epoll: listen=8 active_threads=0 tvp=NULL* *Sep 19 12:41:40 ldap2 slapd[618]: daemon: epoll: listen=9 active_threads=0 tvp=NULL* *Sep 19 12:41:40 ldap2 slapd[618]: daemon: epoll: listen=10 active_threads=0 tvp=NULL* *Sep 19 12:41:40 ldap2 slapd[618]: daemon: epoll: listen=11 active_threads=0 tvp=NULL* *Sep 19 12:41:40 ldap2 slapd[618]: connection_get(13)* *Sep 19 12:41:40 ldap2 slapd[618]: connection_get(13): got connid=1097* *Sep 19 12:41:40 ldap2 slapd[618]: connection_read(13): checking for input on id=1097* *Sep 19 12:41:40 ldap2 slapd[618]: op tag 0x60, time 1474281700* *Sep 19 12:41:40 ldap2 slapd[618]: conn=1097 op=0 do_bind* *Sep 19 12:41:40 ldap2 slapd[618]: >>> dnPrettyNormal: <cn=manager,dc=mydomain,dc=intra>* *Sep 19 12:41:40 ldap2 slapd[618]: <<< dnPrettyNormal: <cn=manager,dc=mydomain,dc=intra>, <cn=manager,dc=mydomain,dc=intra>* *Sep 19 12:41:40 ldap2 slapd[618]: conn=1097 op=0 BIND dn="cn=manager,dc=mydomain,dc=intra" method=128* *Sep 19 12:41:40 ldap2 slapd[618]: do_bind: version=3 dn="cn=manager,dc=mydomain,dc=intra" method=128* *Sep 19 12:41:40 ldap2 slapd[618]: ==> mdb_bind: dn: cn=manager,dc=mydomain,dc=intra* *Sep 19 12:41:40 ldap2 slapd[618]: conn=1097 op=0 BIND dn="cn=manager,dc=mydomain,dc=intra" mech=SIMPLE ssf=0* *Sep 19 12:41:40 ldap2 slapd[618]: do_bind: v3 bind: "cn=manager,dc=mydomain,dc=intra" to "cn=manager,dc=mydomain,dc=intra"* *Sep 19 12:41:40 ldap2 slapd[618]: send_ldap_result: conn=1097 op=0 p=3* *Sep 19 12:41:40 ldap2 slapd[618]: send_ldap_result: err=0 matched="" text=""* *Sep 19 12:41:40 ldap2 slapd[618]: send_ldap_response: msgid=1 tag=97 err=0* *Sep 19 12:41:40 ldap2 slapd[618]: conn=1097 op=0 RESULT tag=97 err=0 text=* *Sep 19 12:41:40 ldap2 slapd[618]: daemon: activity on 1 descriptor* *Sep 19 12:41:40 ldap2 slapd[618]: daemon: activity on:* *Sep 19 12:41:40 ldap2 slapd[618]:* *Sep 19 12:41:40 ldap2 slapd[618]: daemon: epoll: listen=7 active_threads=0 tvp=NULL* *Sep 19 12:41:40 ldap2 slapd[618]: daemon: epoll: listen=8 active_threads=0 tvp=NULL* *Sep 19 12:41:40 ldap2 slapd[618]: daemon: epoll: listen=9 active_threads=0 tvp=NULL* *Sep 19 12:41:40 ldap2 slapd[618]: daemon: epoll: listen=10 active_threads=0 tvp=NULL* *Sep 19 12:41:40 ldap2 slapd[618]: daemon: epoll: listen=11 active_threads=0 tvp=NULL* *Sep 19 12:41:40 ldap2 slapd[618]: daemon: activity on 1 descriptor* *Sep 19 12:41:40 ldap2 slapd[618]: daemon: activity on:* *Sep 19 12:41:40 ldap2 slapd[618]: 13r* *Sep 19 12:41:40 ldap2 slapd[618]:* *Sep 19 12:41:40 ldap2 slapd[618]: daemon: read active on 13* *Sep 19 12:41:40 ldap2 slapd[618]: daemon: epoll: listen=7 active_threads=0 tvp=NULL* *Sep 19 12:41:40 ldap2 slapd[618]: daemon: epoll: listen=8 active_threads=0 tvp=NULL* *Sep 19 12:41:40 ldap2 slapd[618]: daemon: epoll: listen=9 active_threads=0 tvp=NULL* *Sep 19 12:41:40 ldap2 slapd[618]: daemon: epoll: listen=10 active_threads=0 tvp=NULL* *Sep 19 12:41:40 ldap2 slapd[618]: daemon: epoll: listen=11 active_threads=0 tvp=NULL* *Sep 19 12:41:40 ldap2 slapd[618]: connection_get(13)* *Sep 19 12:41:40 ldap2 slapd[618]: connection_get(13): got connid=1097* *Sep 19 12:41:40 ldap2 slapd[618]: connection_read(13): checking for input on id=1097* *Sep 19 12:41:40 ldap2 slapd[618]: op tag 0x63, time 1474281700* *Sep 19 12:41:40 ldap2 slapd[618]: conn=1097 op=1 do_search* *Sep 19 12:41:40 ldap2 slapd[618]: >>> dnPrettyNormal: <>* *Sep 19 12:41:40 ldap2 slapd[618]: <<< dnPrettyNormal: <>, <>* *Sep 19 12:41:40 ldap2 slapd[618]: SRCH "" 2 0* *Sep 19 12:41:40 ldap2 slapd[618]: 0 0 0* *Sep 19 12:41:40 ldap2 slapd[618]: begin get_filter* *Sep 19 12:41:40 ldap2 slapd[618]: PRESENT* *Sep 19 12:41:40 ldap2 slapd[618]: end get_filter 0* *Sep 19 12:41:40 ldap2 slapd[618]: filter: (objectClass=*)* *Sep 19 12:41:40 ldap2 slapd[618]: => get_ctrls* *Sep 19 12:41:40 ldap2 slapd[618]: => get_ctrls: oid="1.3.6.1.4.1.4203.1.9.1.1" (noncritical)* *Sep 19 12:41:40 ldap2 slapd[618]: => get_ctrls: oid="2.16.840.1.113730.3.4.2" (critical)* *Sep 19 12:41:40 ldap2 slapd[618]: <= get_ctrls: n=2 rc=0 err=""* *Sep 19 12:41:40 ldap2 slapd[618]: attrs:* *Sep 19 12:41:40 ldap2 slapd[618]: reqDN* *Sep 19 12:41:40 ldap2 slapd[618]: reqType* *Sep 19 12:41:40 ldap2 slapd[618]: reqMod* *Sep 19 12:41:40 ldap2 slapd[618]: reqNewRDN* *Sep 19 12:41:40 ldap2 slapd[618]: reqDeleteOldRDN* *Sep 19 12:41:40 ldap2 slapd[618]: reqNewSuperior* *Sep 19 12:41:40 ldap2 slapd[618]: entryCSN* *Sep 19 12:41:40 ldap2 slapd[618]:* *Sep 19 12:41:40 ldap2 slapd[618]: conn=1097 op=1 SRCH base="" scope=2 deref=0 filter="(objectClass=*)"* *Sep 19 12:41:40 ldap2 slapd[618]: conn=1097 op=1 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN* *Sep 19 12:41:40 ldap2 slapd[618]: send_ldap_result: conn=1097 op=1 p=3* *Sep 19 12:41:40 ldap2 slapd[618]: send_ldap_result: err=10 matched="" text=""* *Sep 19 12:41:40 ldap2 slapd[618]: send_ldap_response: msgid=2 tag=101 err=32* *Sep 19 12:41:40 ldap2 slapd[618]: conn=1097 op=1 SEARCH RESULT tag=101 err=32 nentries=0 text=* *Sep 19 12:41:40 ldap2 slapd[618]: daemon: activity on 1 descriptor* *Sep 19 12:41:40 ldap2 slapd[618]: daemon: activity on:* *Sep 19 12:41:40 ldap2 slapd[618]:* *Sep 19 12:41:40 ldap2 slapd[618]: daemon: epoll: listen=7 active_threads=0 tvp=NULL* *Sep 19 12:41:40 ldap2 slapd[618]: daemon: epoll: listen=8 active_threads=0 tvp=NULL* *Sep 19 12:41:40 ldap2 slapd[618]: daemon: epoll: listen=9 active_threads=0 tvp=NULL* *Sep 19 12:41:40 ldap2 slapd[618]: daemon: epoll: listen=10 active_threads=0 tvp=NULL* *Sep 19 12:41:40 ldap2 slapd[618]: daemon: epoll: listen=11 active_threads=0 tvp=NULL* *Sep 19 12:41:40 ldap2 slapd[618]: daemon: activity on 1 descriptor* *Sep 19 12:41:40 ldap2 slapd[618]: daemon: activity on:* *Sep 19 12:41:40 ldap2 slapd[618]: 13r* *Sep 19 12:41:40 ldap2 slapd[618]:* *Sep 19 12:41:40 ldap2 slapd[618]: daemon: read active on 13* *Sep 19 12:41:40 ldap2 slapd[618]: daemon: epoll: listen=7 active_threads=0 tvp=NULL* *Sep 19 12:41:40 ldap2 slapd[618]: daemon: epoll: listen=8 active_threads=0 tvp=NULL* *Sep 19 12:41:40 ldap2 slapd[618]: daemon: epoll: listen=9 active_threads=0 tvp=NULL* *Sep 19 12:41:40 ldap2 slapd[618]: daemon: epoll: listen=10 active_threads=0 tvp=NULL* *Sep 19 12:41:40 ldap2 slapd[618]: daemon: epoll: listen=11 active_threads=0 tvp=NULL* *Sep 19 12:41:40 ldap2 slapd[618]: connection_get(13)* *Sep 19 12:41:40 ldap2 slapd[618]: connection_get(13): got connid=1097* *Sep 19 12:41:40 ldap2 slapd[618]: connection_read(13): checking for input on id=1097* *Sep 19 12:41:40 ldap2 slapd[618]: op tag 0x42, time 1474281700* *Sep 19 12:41:40 ldap2 slapd[618]: ber_get_next on fd 13 failed errno=0 (Success)* *Sep 19 12:41:40 ldap2 slapd[618]: connection_read(13): input error=-2 id=1097, closing.* *Sep 19 12:41:40 ldap2 slapd[618]: connection_closing: readying conn=1097 sd=13 for close* *Sep 19 12:41:40 ldap2 slapd[618]: connection_close: deferring conn=1097 sd=13* *Sep 19 12:41:40 ldap2 slapd[618]: conn=1097 op=2 do_unbind* *Sep 19 12:41:40 ldap2 slapd[618]: conn=1097 op=2 UNBIND* *Sep 19 12:41:40 ldap2 slapd[618]: connection_resched: attempting closing conn=1097 sd=13* *Sep 19 12:41:40 ldap2 slapd[618]: connection_close: conn=1097 sd=13* *Sep 19 12:41:40 ldap2 slapd[618]: daemon: removing 13* *Sep 19 12:41:40 ldap2 slapd[618]: conn=1097 fd=13 closed* *Sep 19 12:41:40 ldap2 slapd[618]: daemon: activity on 1 descriptor* *Sep 19 12:41:40 ldap2 slapd[618]: daemon: activity on:* *Sep 19 12:41:40 ldap2 slapd[618]:* *Sep 19 12:41:40 ldap2 slapd[618]: daemon: epoll: listen=7 active_threads=0 tvp=NULL* *Sep 19 12:41:40 ldap2 slapd[618]: daemon: epoll: listen=8 active_threads=0 tvp=NULL* *Sep 19 12:41:40 ldap2 slapd[618]: daemon: epoll: listen=9 active_threads=0 tvp=NULL* *Sep 19 12:41:40 ldap2 slapd[618]: daemon: epoll: listen=10 active_threads=0 tvp=NULL* *Sep 19 12:41:40 ldap2 slapd[618]: daemon: epoll: listen=11 active_threads=0 tvp=NULL* ldap's provider configuration: *dn: cn=config* *objectClass: olcGlobal* *cn: config* *olcArgsFile: /var/run/openldap/slapd.args* *olcPidFile: /var/run/openldap/slapd.pid* *olcTLSCACertificatePath: /etc/openldap/certs* *structuralObjectClass: olcGlobal* *entryUUID: ba0ed5ae-0ed2-1036-92e8-a5ac34fa70e0* *creatorsName: cn=config* *createTimestamp: 20160914142444Z* *olcTLSCACertificateFile: /etc/openldap/certs/ca-bundle.crt* *olcTLSCertificateFile: /etc/openldap/certs/server.crt* *olcTLSCertificateKeyFile: /etc/openldap/certs/server.key* *olcLogLevel: -1* *entryCSN: 20160919100502.405082Z#000000#000#000000* *modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth* *modifyTimestamp: 20160919100502Z* *dn: cn=module{0},cn=config* *objectClass: olcModuleList* *cn: module{0}* *olcModuleLoad: {0}/usr/lib64/openldap/smbk5pwd.la <http://smbk5pwd.la>* *structuralObjectClass: olcModuleList* *entryUUID: 02be502a-0eda-1036-8732-67bd148453df* *creatorsName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth* *createTimestamp: 20160914151652Z* *entryCSN: 20160914151652.906110Z#000000#000#000000* *modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth* *modifyTimestamp: 20160914151652Z* *dn: cn=module{1},cn=config* *objectClass: olcModuleList* *cn: module{1}* *olcModulePath: /usr/lib64/openldap* *olcModuleLoad: {0}back_mdb* *structuralObjectClass: olcModuleList* *entryUUID: 0500f2f2-0eda-1036-8733-67bd148453df* *creatorsName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth* *createTimestamp: 20160914151656Z* *entryCSN: 20160914151656.698287Z#000000#000#000000* *modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth* *modifyTimestamp: 20160914151656Z* *dn: cn=schema,cn=config* *objectClass: olcSchemaConfig* *cn: schema* *structuralObjectClass: olcSchemaConfig* *entryUUID: ba0ede78-0ed2-1036-92e9-a5ac34fa70e0* *creatorsName: cn=config* *createTimestamp: 20160914142444Z* *entryCSN: 20160914142444.483302Z#000000#000#000000* *modifiersName: cn=config* *modifyTimestamp: 20160914142444Z* *..... schema config ...* *dn: olcDatabase={-1}frontend,cn=config* *objectClass: olcDatabaseConfig* *objectClass: olcFrontendConfig* *olcDatabase: {-1}frontend* *structuralObjectClass: olcDatabaseConfig* *entryUUID: ba0f2752-0ed2-1036-92eb-a5ac34fa70e0* *creatorsName: cn=config* *createTimestamp: 20160914142444Z* *entryCSN: 20160914142444.485167Z#000000#000#000000* *modifiersName: cn=config* *modifyTimestamp: 20160914142444Z* *dn: olcDatabase={0}config,cn=config* *objectClass: olcDatabaseConfig* *olcDatabase: {0}config* *olcAccess: {0}to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=extern* * al,cn=auth" manage by * none* *structuralObjectClass: olcDatabaseConfig* *entryUUID: ba0f2d4c-0ed2-1036-92ec-a5ac34fa70e0* *creatorsName: cn=config* *createTimestamp: 20160914142444Z* *olcRootPW:: e1NTSEF9OTlmV1dNQjNFOVA2T3JqdXhUYlpoUjB0N2FmeUc1bjU=* *entryCSN: 20160914143100.069565Z#000000#000#000000* *modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth* *modifyTimestamp: 20160914143100Z* *dn: olcDatabase={1}monitor,cn=config* *objectClass: olcDatabaseConfig* *olcDatabase: {1}monitor* *olcAccess: {0}to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=extern* * al,cn=auth" read by dn.base="cn=Manager,dc=my-domain,dc=com" read by * none* *structuralObjectClass: olcDatabaseConfig* *entryUUID: ba0f33aa-0ed2-1036-92ed-a5ac34fa70e0* *creatorsName: cn=config* *createTimestamp: 20160914142444Z* *entryCSN: 20160914142444.485484Z#000000#000#000000* *modifiersName: cn=config* *modifyTimestamp: 20160914142444Z* *dn: olcDatabase={2}mdb,cn=config* *objectClass: olcDatabaseConfig* *objectClass: olcMdbConfig* *olcDatabase: {2}mdb* *olcDbDirectory: /var/lib/ldap* *olcDbIndex: objectClass eq,pres* *olcDbIndex: ou,cn,mail,surname,givenname eq,pres,sub* *olcDbIndex: uidNumber,gidNumber,loginShell eq,pres* *olcDbIndex: uid,memberUid eq,pres,sub* *olcDbIndex: nisMapName,nisMapEntry eq,pres,sub* *structuralObjectClass: olcMdbConfig* *entryUUID: ba0f3e18-0ed2-1036-92ee-a5ac34fa70e0* *creatorsName: cn=config* *createTimestamp: 20160914142444Z* *olcRootDN: cn=Manager,dc=mydomain,dc=intra* *olcSuffix: dc=mydomain,dc=intra* *olcRootPW:: e1NTSEF9RFR4TXZOdlFPdURsejg0akd5NkIvWWduMlBDbEIyeng=* *olcSyncrepl: {0}rid=001 provider=ldap://192.168.235.70/ <http://192.168.235.70/> bindmethod=simple bi* * nddn="cn=Manager,dc=mydomain,dc=intra" credentials=viola99 searchbase="dc* * =mydomain,dc=intra" scope=sub schemachecking=off type=refreshOnly retry="* * 30 5 300 3" interval=00:00:05:00 syncdata=accesslog filter="(objectClass=*)* * " searchbase="dc=mydomain,dc=intra"* *entryCSN: 20160919095751.593118Z#000000#000#000000* *modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth* *modifyTimestamp: 20160919095751Z* *dn: olcOverlay={0}smbk5pwd,olcDatabase={2}mdb,cn=config* *objectClass: olcOverlayConfig* *objectClass: olcSmbK5PwdConfig* *olcOverlay: {0}smbk5pwd* *olcSmbK5PwdEnable: samba* *structuralObjectClass: olcSmbK5PwdConfig* *entryUUID: 079a3618-0eda-1036-8734-67bd148453df* *creatorsName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth* *createTimestamp: 20160914151701Z* *entryCSN: 20160914151701.058149Z#000000#000#000000* *modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth* *modifyTimestamp: 20160914151701Z* ldap's customer config: *dn: cn=config* *objectClass: olcGlobal* *cn: config* *olcArgsFile: /var/run/openldap/slapd.args* *olcPidFile: /var/run/openldap/slapd.pid* *olcTLSCACertificatePath: /etc/openldap/certs* *structuralObjectClass: olcGlobal* *entryUUID: b9f29fc8-0df2-1036-8852-c195847901f0* *creatorsName: cn=config* *createTimestamp: 20160913114117Z* *olcTLSCACertificateFile: /etc/openldap/certs/ca-bundle.crt* *olcTLSCertificateFile: /etc/openldap/certs/server.crt* *olcTLSCertificateKeyFile: /etc/openldap/certs/server.key* *olcLogLevel: -1* *entryCSN: 20160919082239.212771Z#000000#000#000000* *modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth* *modifyTimestamp: 20160919082239Z* *dn: cn=module{0},cn=config* *objectClass: olcModuleList* *cn: module{0}* *olcModuleLoad: {0}/usr/lib64/openldap/smbk5pwd.la <http://smbk5pwd.la>* *structuralObjectClass: olcModuleList* *entryUUID: 473085bc-0df3-1036-94a0-ad4331978f4a* *creatorsName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth* *createTimestamp: 20160913114513Z* *entryCSN: 20160913114513.995165Z#000000#000#000000* *modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth* *modifyTimestamp: 20160913114513Z* *dn: cn=module{1},cn=config* *objectClass: olcModuleList* *cn: module{1}* *olcModulePath: /usr/lib64/openldap* *olcModuleLoad: {0}back_mdb* *structuralObjectClass: olcModuleList* *entryUUID: 49b832e4-0df3-1036-94a1-ad4331978f4a* *creatorsName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth* *createTimestamp: 20160913114518Z* *entryCSN: 20160913114518.239776Z#000000#000#000000* *modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth* *modifyTimestamp: 20160913114518Z* *dn: cn=module{2},cn=config* *objectClass: olcModuleList* *cn: module{2}* *olcModulePath: /usr/lib64/openldap* *olcModuleLoad: {0}syncprov.la <http://syncprov.la>* *structuralObjectClass: olcModuleList* *entryUUID: 2788b796-0ed6-1036-9cc5-a32737359a4d* *creatorsName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth* *createTimestamp: 20160914144916Z* *entryCSN: 20160914144916.643685Z#000000#000#000000* *modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth* *modifyTimestamp: 20160914144916Z* *dn: cn=schema,cn=config* *objectClass: olcSchemaConfig* *cn: schema* *structuralObjectClass: olcSchemaConfig* *entryUUID: b9f2b1a2-0df2-1036-8853-c195847901f0* *creatorsName: cn=config* *createTimestamp: 20160913114117Z* *entryCSN: 20160913114117.031222Z#000000#000#000000* *modifiersName: cn=config* *modifyTimestamp: 20160913114117Z* *.....schema config.....* *dn: olcDatabase={-1}frontend,cn=config* *objectClass: olcDatabaseConfig* *objectClass: olcFrontendConfig* *olcDatabase: {-1}frontend* *structuralObjectClass: olcDatabaseConfig* *entryUUID: b9f319d0-0df2-1036-8855-c195847901f0* *creatorsName: cn=config* *createTimestamp: 20160913114117Z* *entryCSN: 20160913114117.033887Z#000000#000#000000* *modifiersName: cn=config* *modifyTimestamp: 20160913114117Z* *dn: olcDatabase={0}config,cn=config* *objectClass: olcDatabaseConfig* *olcDatabase: {0}config* *olcAccess: {0}to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=extern* * al,cn=auth" manage by * none* *structuralObjectClass: olcDatabaseConfig* *entryUUID: b9f32556-0df2-1036-8856-c195847901f0* *creatorsName: cn=config* *createTimestamp: 20160913114117Z* *olcRootPW:: e1NTSEF9OTlmV1dNQjNFOVA2T3JqdXhUYlpoUjB0N2FmeUc1bjU=* *entryCSN: 20160913114223.082994Z#000000#000#000000* *modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth* *modifyTimestamp: 20160913114223Z* *dn: olcDatabase={1}monitor,cn=config* *objectClass: olcDatabaseConfig* *olcDatabase: {1}monitor* *olcAccess: {0}to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=extern* * al,cn=auth" read by dn.base="cn=Manager,dc=my-domain,dc=com" read by * none* *structuralObjectClass: olcDatabaseConfig* *entryUUID: b9f3ec2a-0df2-1036-8857-c195847901f0* *creatorsName: cn=config* *createTimestamp: 20160913114117Z* *entryCSN: 20160913114117.039272Z#000000#000#000000* *modifiersName: cn=config* *modifyTimestamp: 20160913114117Z* *dn: olcDatabase={2}mdb,cn=config* *objectClass: olcDatabaseConfig* *objectClass: olcMdbConfig* *olcDatabase: {2}mdb* *olcDbDirectory: /var/lib/ldap* *olcSuffix: dc=mydomain,dc=intra* *olcDbIndex: objectClass eq,pres* *olcDbIndex: ou,cn,mail,surname,givenname eq,pres,sub* *olcDbIndex: uidNumber,gidNumber,loginShell eq,pres* *olcDbIndex: uid,memberUid eq,pres,sub* *olcDbIndex: nisMapName,nisMapEntry eq,pres,sub* *structuralObjectClass: olcMdbConfig* *entryUUID: b9f53e9a-0df2-1036-8858-c195847901f0* *creatorsName: cn=config* *createTimestamp: 20160913114117Z* *olcRootDN: cn=Manager,dc=mydomain,dc=intra* *olcRootPW:: e1NTSEF9aHRPQUVvdVJMeDUxeGloQTdSdlRGc2hTRmhxcG1HQXc=* *entryCSN: 20160913141458.892233Z#000000#000#000000* *modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth* *modifyTimestamp: 20160913141458Z* *dn: olcOverlay={0}smbk5pwd,olcDatabase={2}mdb,cn=config* *objectClass: olcOverlayConfig* *objectClass: olcSmbK5PwdConfig* *olcOverlay: {0}smbk5pwd* *olcSmbK5PwdEnable: samba* *structuralObjectClass: olcSmbK5PwdConfig* *entryUUID: d61bb9f4-0e0c-1036-9b7b-d9c0303e2769* *creatorsName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth* *createTimestamp: 20160913144811Z* *entryCSN: 20160913144811.191113Z#000000#000#000000* *modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth* *modifyTimestamp: 20160913144811Z* *dn: olcOverlay={1}syncprov,olcDatabase={2}mdb,cn=config* *objectClass: olcOverlayConfig* *objectClass: olcSyncProvConfig* *olcOverlay: {1}syncprov* *olcSpCheckpoint: 100 10* *olcSpSessionlog: 1000* *structuralObjectClass: olcSyncProvConfig* *entryUUID: 4af82a36-0ed6-1036-9cc6-a32737359a4d* *creatorsName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth* *createTimestamp: 20160914145016Z* *entryCSN: 20160914145016.094325Z#000000#000#000000* *modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth* *modifyTimestamp: 20160914145016Z*

2 1

Enable memberOf
by Elias Pereira 18 Sep '16

18 Sep '16

Hello guys, In our infra we using openldap in old style slapd.conf config to centralize users, groups, etc. I like to know how I enable memberOf in openlap old style config? -- Elias Pereira

3 6

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical