openldap-technical January 2016

openldap-technical@openldap.org

39 participants
44 discussions

LMBD questions (stat & copy)
by Bruno Freudensprung 14 Jan '16

14 Jan '16

Hi, I am trying to detect MDB_MAP_FULL based on mdb_stat(txn, dbi, &stat) results and I am wondering if I am on the right track or doing things correctly. I have a small and simple test program (http://pastebin.com/SPCYgWMC) exhibiting the following behavior (consistent between Windows 7 64-bit and Ubuntu 15.10 64-bit - latest version of lmdb cloned and recompiled on Linux): * Inserting 20990 key value pairs in a database is OK when using one transaction. Just before commiting the write transaction, mdb_stat(txn, dbi, &stat) shows that the total number of pages (253) is very close the the number of pages of the map (256). Indeed, adding another entry leads to MDB_MAP_FULL. To put it shortly, this scenario looks OK (I am assuming there might be 3 "internal-purpose" pages not shown by mdb_stat) and can be tested by setting the stat_test variable to 0 at line 20 of the test program. * Inserting same 20990 key value pairs in a database fails (MDB_MAP_FULL encountered at 19357) when using two consecutive write transactions. Just before MDB_MAP_FULL, mdb_stat(txn, dbi, &stat) shows that the total number of pages (232) is "quite far" from the the number of pages of the map (256), leading my MDB_MAP_FULL detection heuristic to fail. It means that only 92% of the total amount of data can be sucessfully added to the database. Other scenarii (with same key/value lengths though) stop at 85% only. This can be tested by setting the stat_test variable to 1 (line 20). By "total number of pages" I mean ms_branch_pages + ms_leaf_pages + ms_overflow_pages. Do you think I am on a wrong track? (maybe mdb_stat does not show 24 "internal-purpose" pages in the second case? or I am forgetting something?). One last remark: it seems that mdb_env_copy(db, copy_dir) is possible during a write transaction on Windows (like stated in the documentation), but not on Linux (the test program seems to be stopped on a mutex at line 62). This can be tested by changing the copy_test variable to 1 at line 19. Is it expected given my program? Best regards, Bruno.

2 7

slapd dies
by BÖSCH Christian 14 Jan '16

14 Jan '16

hi, i have two openldap servers 2.4.43 on freebsd 10.2 with multimaster replication. if i add on one node a dynamicobject, the other node dies immediatly. has anybody an idea? regards,chris --- added this: dn: uid=vkw-guest,ou=people,o=abc.net sn: VKW Guest objectClass: organizationalPerson objectClass: person objectClass: dynamicObject objectClass: inetLocalMailRecipient objectClass: inetOrgPerson objectClass: top uid: vkw-guest cn: VKW Guest the log says: Jan 13 13:08:40 openldap2 slapd[75017]: daemon: activity on 1 descriptor Jan 13 13:08:40 openldap2 slapd[75017]: daemon: activity on: Jan 13 13:08:40 openldap2 slapd[75017]: 30r Jan 13 13:08:40 openldap2 slapd[75017]: Jan 13 13:08:40 openldap2 slapd[75017]: daemon: read activity on 30 Jan 13 13:08:40 openldap2 slapd[75017]: daemon: select: listen=6 active_threads=0 tvp=zero Jan 13 13:08:40 openldap2 slapd[75017]: daemon: select: listen=7 active_threads=0 tvp=zero Jan 13 13:08:40 openldap2 slapd[75017]: daemon: select: listen=8 active_threads=0 tvp=zero Jan 13 13:08:40 openldap2 slapd[75017]: daemon: select: listen=9 active_threads=0 tvp=zero Jan 13 13:08:40 openldap2 slapd[75017]: daemon: select: listen=10 active_threads=0 tvp=zero Jan 13 13:08:40 openldap2 slapd[75017]: connection_get(30) Jan 13 13:08:40 openldap2 slapd[75017]: connection_get(30): got connid=0 Jan 13 13:08:40 openldap2 slapd[75017]: =>do_syncrepl rid=021 Jan 13 13:08:40 openldap2 slapd[75017]: =>do_syncrep2 rid=021 Jan 13 13:08:40 openldap2 slapd[75017]: do_syncrep2: rid=021 cookie=rid=021,sid=001,csn=20160113120840.025550Z#000000#001#000000 Jan 13 13:08:40 openldap2 slapd[75017]: syncrepl_message_to_entry: rid=021 DN: uid=vkw-guest,ou=people,o=abc.net, UUID: 2074bc1e-4e3a-1035-92a1-ed72d2e7074a Jan 13 13:08:40 openldap2 slapd[75017]: >>> dnPrettyNormal: <uid=vkw-guest,ou=people,o=abc.net> Jan 13 13:08:40 openldap2 slapd[75017]: <<< dnPrettyNormal: <uid=vkw-guest,ou=people,o=abc.net>, <uid=vkw-guest,ou=people,o=abc.net> Jan 13 13:08:40 openldap2 slapd[75017]: >>> dnPretty: <cn=admin,o=xyz.net> Jan 13 13:08:40 openldap2 slapd[75017]: <<< dnPretty: <cn=admin,o=xyz.net> Jan 13 13:08:40 openldap2 slapd[75017]: >>> dnNormalize: <cn=admin,o=xyz.net> Jan 13 13:08:40 openldap2 slapd[75017]: <<< dnNormalize: <cn=admin,o=xyz.net> Jan 13 13:08:40 openldap2 slapd[75017]: >>> dnPretty: <cn=admin,o=xyz.net> Jan 13 13:08:40 openldap2 slapd[75017]: <<< dnPretty: <cn=admin,o=xyz.net> Jan 13 13:08:40 openldap2 slapd[75017]: >>> dnNormalize: <cn=admin,o=xyz.net> Jan 13 13:08:40 openldap2 slapd[75017]: <<< dnNormalize: <cn=admin,o=xyz.net> Jan 13 13:08:40 openldap2 slapd[75017]: >>> dnPretty: <uid=vkw-guest,ou=people,o=abc.net> Jan 13 13:08:40 openldap2 slapd[75017]: <<< dnPretty: <uid=vkw-guest,ou=people,o=abc.net> Jan 13 13:08:40 openldap2 slapd[75017]: >>> dnNormalize: <uid=vkw-guest,ou=people,o=abc.net> Jan 13 13:08:40 openldap2 slapd[75017]: <<< dnNormalize: <uid=vkw-guest,ou=people,o=abc.net> Jan 13 13:08:40 openldap2 slapd[75017]: >>> dnPretty: <cn=Subschema> Jan 13 13:08:40 openldap2 slapd[75017]: <<< dnPretty: <cn=Subschema> Jan 13 13:08:40 openldap2 slapd[75017]: >>> dnNormalize: <cn=Subschema> Jan 13 13:08:40 openldap2 slapd[75017]: <<< dnNormalize: <cn=subschema> Jan 13 13:08:40 openldap2 slapd[75017]: syncrepl_entry: rid=021 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Jan 13 13:08:40 openldap2 slapd[75017]: => mdb_search Jan 13 13:08:40 openldap2 slapd[75017]: mdb_dn2entry("o=abc.net") Jan 13 13:08:40 openldap2 slapd[75017]: => mdb_dn2id("o=abc.net") Jan 13 13:08:40 openldap2 slapd[75017]: <= mdb_dn2id: got id=0x1 Jan 13 13:08:40 openldap2 slapd[75017]: => mdb_entry_decode: Jan 13 13:08:40 openldap2 slapd[75017]: <= mdb_entry_decode Jan 13 13:08:40 openldap2 slapd[75017]: => access_allowed: search access to "o=abc.net" "entry" requested Jan 13 13:08:40 openldap2 slapd[75017]: <= root access granted Jan 13 13:08:40 openldap2 slapd[75017]: => access_allowed: search access granted by manage(=mwrscxd) Jan 13 13:08:40 openldap2 slapd[75017]: search_candidates: base="o=abc.net" (0x00000001) scope=2 Jan 13 13:08:40 openldap2 slapd[75017]: => mdb_filter_candidates Jan 13 13:08:40 openldap2 slapd[75017]: EQUALITY Jan 13 13:08:40 openldap2 slapd[75017]: => mdb_equality_candidates (entryUUID) Jan 13 13:08:40 openldap2 slapd[75017]: => key_read Jan 13 13:08:40 openldap2 slapd[75017]: mdb_idl_fetch_key: [5ec43656] Jan 13 13:08:40 openldap2 slapd[75017]: <= mdb_index_read: failed (-30798) Jan 13 13:08:40 openldap2 slapd[75017]: <= mdb_equality_candidates: id=0, first=0, last=0 Jan 13 13:08:40 openldap2 slapd[75017]: <= mdb_filter_candidates: id=0 first=0 last=0 Jan 13 13:08:40 openldap2 slapd[75017]: mdb_search_candidates: id=0 first=0 last=0 Jan 13 13:08:40 openldap2 slapd[75017]: mdb_search: no candidates Jan 13 13:08:40 openldap2 slapd[75017]: send_ldap_result: conn=-1 op=0 p=0 Jan 13 13:08:40 openldap2 slapd[75017]: send_ldap_result: err=0 matched="" text="" Jan 13 13:08:40 openldap2 slapd[75017]: syncrepl_entry: rid=021 be_search (0) Jan 13 13:08:40 openldap2 slapd[75017]: syncrepl_entry: rid=021 uid=vkw-guest,ou=people,o=abc.net Jan 13 13:08:40 openldap2 slapd[75017]: slap_queue_csn: queueing 0x846348780 20160113120840.025550Z#000000#001#000000 Jan 13 13:08:40 openldap2 slapd[75017]: ==> unique_add <uid=vkw-guest,ou=people,o=abc.net> Jan 13 13:08:40 openldap2 slapd[75017]: => access_allowed: manage access to "uid=vkw-guest,ou=people,o=abc.net" "entry" requested Jan 13 13:08:40 openldap2 slapd[75017]: <= root access granted Jan 13 13:08:40 openldap2 slapd[75017]: => access_allowed: manage access granted by manage(=mwrscxd) Jan 13 13:08:40 openldap2 slapd[75017]: unique_add: administrative bypass, skipping Jan 13 13:08:40 openldap2 slapd[75017]: => mdb_entry_get: ndn: "ou=people,o=abc.net" Jan 13 13:08:40 openldap2 slapd[75017]: => mdb_entry_get: oc: "dynamicObject", at: "(null)" Jan 13 13:08:40 openldap2 slapd[75017]: mdb_dn2entry("ou=people,o=abc.net") Jan 13 13:08:40 openldap2 slapd[75017]: => mdb_dn2id("ou=people,o=abc.net") Jan 13 13:08:40 openldap2 slapd[75017]: <= mdb_dn2id: got id=0x3 Jan 13 13:08:40 openldap2 slapd[75017]: => mdb_entry_decode: Jan 13 13:08:40 openldap2 slapd[75017]: <= mdb_entry_decode Jan 13 13:08:40 openldap2 slapd[75017]: => mdb_entry_get: found entry: "ou=people,o=abc.net" Jan 13 13:08:40 openldap2 slapd[75017]: <= mdb_entry_get: failed to find objectClass dynamicObject Jan 13 13:08:40 openldap2 slapd[75017]: mdb_entry_get: rc=16

3 4

add sortvals after database loaded?
by Phil Pishioneri 14 Jan '16

14 Jan '16

Environment: slapd: openldap-ltb-2.4.42-1.el6.x86_64 config: slapd.conf (file) database: mdb After a database has been loaded, can the sortvals option be added/changed without having to dump and reload the database? The slapd.conf (and slapd-config) man page doesn't mention any need for a reload, but wanted to verify. -Phil

2 2

Removing olcAccess entry
by Katherine Faella 12 Jan '16

12 Jan '16

For the life of me I can not figure out the syntax for performing this. Here is my snippet of config.ldif: dn: olcDatabase={1}hdb,cn=config objectClass: olcDatabaseConfig objectClass: olcHdbConfig olcDatabase: {1}hdb olcSuffix: dc=sakai,dc=uri,dc=edu olcAccess: {0}to * by peername.ip="131.128.1.0%255.255.255.0" +0 break by peername.ip="131.128.122.0%255.255.255.0" +0 break by peername.ip="158.123 .255.8%255.255.255.248" +0 break by peername.ip="127.0.0.1" +0 break olcAccess: {1}to * by dn.regex="^URIEduauthid=.+,dc=sakai,dc=uri,dc=edu$$" read by * auth olcAddContentAcl: FALSE olcLastMod: TRUE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcRootDN: cn=Manager,dc=sakai,dc=uri,dc=edu ..... I need to remove the olcAccess {0} as we need to access this server from new ips. We are using a firewall to protect the server going forward. I have created the file removeips containing: dn: olcDatabase={1}hdb,cn=config changetype: modify delete: olcAccess olcAccess: {1} Running the command ldapmodify -W -x -h antons.uri.edu -D "cn=admin,cn=config" -f /root/ldapscripts/removeips gives me: modifying entry "olcDatabase={1}hdb,cn=config" ldap_modify: No such attribute (16) additional info: modify/delete: olcAccess: no such attribute What am I doing wrong? Thanks, Kathy -- Katherine Faella tel: (401) 874-4469 Senior Technical Programmer kmf(a)uri.edu University of Rhode Island University Computing Systems(UCS) 210 Flagg Road Kingston, Rhode Island

4 4

lmdb VL32 high virtual address usage
by Jeremiah Morrill 11 Jan '16

11 Jan '16

This sort of coincides with ITS issue 8347 I just reported. With ldmb VL32, I’ve noticed that it can eat up a lot of memory space. Sometimes ~500mb for an 800mb db after reading every record, one by one using the same readonly transaction/cursor. I found that modifying MDB_ERPAGE_SIZE from 16384 to 256 brought virtual memory usage down substantially (~30megs). I have not noticed any adverse effects from this change or MDB_MAP_FULL. The mapped address spaces to seem to get deallocated on the close of the environment, not the transaction, which sounds like its being cached in the env->me_rpages for reasons explained in mdb_rpage_get comments. Is the mem map cache supposed to be this aggressive by design, or just because this area of the code is so new...or simply a usage error on my part? If it’s by design, could there be a consideration to make MDB_ERPAGE_SIZE a #define’able value in the public lmdb.h so one could tweak the behavior? -Jer

2 1

Re: what databases are to be replicated for a slave?
by Jephte Clain 08 Jan '16

08 Jan '16

2015-12-29 20:38 GMT+04:00 Quanah Gibson-Mount <quanah(a)zimbra.com>: > --On Tuesday, December 29, 2015 12:48 PM +0400 Jephte Clain > <jephte.clain(a)univ-reunion.fr> wrote: > > > >>> No. Replicas do not accept writes. Replicas do not have a master >>> configuration for cn=config. Replica's do not have server IDs. >> >> ok I guess I understand. this is the reason why I usually call them >> "slaves", not replicas (but I messed things up and called them replicas >> this time ^^) >> I also have replicas that only replicate data (or a subset of data) for >> some services > > > No. The terms replica and slave are interchangeable. As are master and > provider. Given the very negative connotations of the concept of masters > and slaves, the preferred terms are "provider" instead of "master" and > "replica" instead of "slaves". Aaargh, now I can't help thinking about "providers" whipping "replicas". slapd can be so cruel sometimes :-) And in case you wonder, here in reunion island we have a (relatively) long history of slavery. We even have a day to commemorate abolition of slavery: december 20th > > >> the slaves are there in case of catastrophic failure of both masters (we >> had one of these failure for another service due to a problem with the >> shared storage. No one want to have this kind of emergency...) >> If the master(s) crash, I just have to choose a slave as the new master, >> slapcat the cn=config database, update the provider address, slapadd the >> updated config, and update the loadbalancer settings. this is a bit of >> work but at least we can restore service in a (relatively) small amount >> of time. > > > If they accept writes, they are not slaves/replicas. If you are replicating > cn=config across all the systems, then they must all be masters. Your > general description above sounds like you do not correctly understand how > MMR functions. OK... I finally understand what was bothering you My replicas do _not_ accept writes. Sorry to have let you think so I have two setups: - a "legacy" one, with one master accessible to the applications that can write, and two complete replicas (data + cn=config) behind a loadbalancer for the reads. One of these replicas could become the new master if the needs arise. And there are a bunch of partial replicas (only a subset of data) for some specific services. The reason is on our vmware farm, network access is regularly cut (don't know why, the system guy neither), and these services cannot reconnect on their own... piece of #$*! software :( - a "new" one, with two masters in mirror mode (only one get the writes at anytime thanks to the loadbalancer), and two replicas (only data) which get all the reads. I feel like configuring chaining to be able to write from the replicas, but I have no experience of the benefits of this configuration... I have read the admin guide several times, but I am open to any suggestion to improve my skills > >>> Accesslog is unique to a given master. >> >> Ok that's what I wanted to know for sure >> >> Shouldn't the doc stat this clearly? > > > Please file an ITS noting the docs should be updated on this point. Ok. I may even provide a patch. I'll do it tomorrow. Have a nice day/night (don't know where you live ^^) Regards, Jephté -- Jephté CLAIN | Développeur, Intégrateur d'applications Service Système d'Information Direction des Systèmes d'Information Tél: +262 262 93 86 31 || Gsm: +262 692 29 58 24

2 2

Out of ideas when troubleshooting TLS negotiation failure
by Graham Allan 08 Jan '16

08 Jan '16

This feels like a lame question, but I'm out of ideas, so... I'm moving samba service between a couple of FreeBSD systems (9.3 to 10.2), and I'm stuck on getting samba on the new machine to connect to our openldap server over ssl - frustrating since I've been running samba+ldap for 15 years or so; feel sure I'm missing something basic! The smbd-to-ldap connection works fine with no encryption, but I get errors when using either TLS to port 389 ("Failed to issue the StartTLS instruction: Connect error") or SSL to 636. However I'm pretty certain it's not a certificate or CA validation issue. All my other ldap clients on that server are working as expected, including a simple "ldapsearch -ZZ". Both openssl s_client and gnutls-cli show the ldap server certificate validating. Maximum debugging on the ldap server gave me: connection_read(3): TLS accept failure error=-1 id=1042, closing conn=1042 fd=3 closed (TLS negotiation failure) Running smbd under gbd shows ldap_start_tls_s (ldap_struct, NULL, NULL) in smb_ldap_start_tls is returning -11 (LDAP_CONNECT_ERROR). That doesn't give me any ideas, sadly! Capturing the packet exchange between smbd and slapd, I'm seeing the (smbd) client sends a "decrypt error" (TLS alert code 51) to the ldap server after receiving the certificate, while the working "ldapsearch -ZZ" moves on to client key exchange etc. Besides all my other ldap clients working successfully, I think I'd expect to see a TLS alert more like 42-48 if it were a cert validation problem. I'm not sure where to try looking next for the cause, would welcome any suggestions... Thanks, Graham

3 5

Knowing free mdb space
by Angel L. Mateo 07 Jan '16

07 Jan '16

Hello, I have recently migrated my openldap server from hdb to mdb. In this kind of database you configure the maximal database size with maxsize option. Although I have configure this option with 8GB, more than the double of my actual database size, I would like to know if there is any way to calculate the remaining size. According to [1] you can get the actual size with a du. But my problem is that I'm using zfs with a compressed file system, so du reports the compressed size, not the real one. Is there any way to get this value? Or my real maximum size is 8GB after compression? [1] https://wiki.zimbra.com/wiki/OpenLDAP_Performance_Tuning_8.0 -- Angel L. Mateo Martínez Sección de Telemática Área de Tecnologías de la Información y las Comunicaciones Aplicadas (ATICA) http://www.um.es/atica Tfo: 868887590 Fax: 868888337

4 5

LMDB ITS 8324 WriteMap performance on Windows
by Victor Baybekov 05 Jan '16

05 Jan '16

Hi, Thanks a lot for ITS#8324! For embedded, not server, use case that change adds much convenience. I have tested the master from .NET via P/Invoke and do not see any major slowdown with default options. To insert 10M <int32,int32> pairs inside a single transaction v.0.9.14 takes minimum 3400 msec, latest master takes minimum 3750 msec. This is not scientific, just best result from 10 runs. Sometimes both timings increase to 5000+ msecs. On average slowdown is visible but tolerable - from 2.9 Mops to 2.6 Mops (absolute numbers are still awesome!). With Append and NoSync I could get 3.45 Mops on the same test with master build. However, with WriteMap performance of master drops 3x to 10000 msec or just 1 Mops, while for the v.0.9.14 performance with WriteMap improves to 2350 msec or 4.25 Mops. Is this the cost of convenience or it could be fixed so that WriteMap still "is faster and uses fewer mallocs" as the docs say? Best regards, Victor

3 5

2.4.43 "make test" hanging in "test039-glue-ldap-concurrency" on Solaris 10
by Greg Earle 04 Jan '16

04 Jan '16

Forgive me if this is the wrong place (maybe openldap-build?). I've built OpenLDAP 2.4.43 on Solaris 10 1/13 OK, but when I run the "make test" phase it hangs in the "test039-glue-ldap-concurrency" test: -- >>>>> Starting test039-glue-ldap-concurrency for bdb... running defines.sh Starting slapd on TCP/IP port 9011... Using ldapsearch to check that slapd is running... Using ldapadd to populate the database... Starting slapd on TCP/IP port 9012... Using ldapsearch to check that slapd is running... Using ldapadd to populate the database... Starting slapd on TCP/IP port 9013... Using ldapsearch to check that slapd is running... MONITORDB yes SRCDIR /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/testrun/./testdata DSTDIR /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/testrun pwd /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests Using tester for concurrent server access... PID=16664 - Read(1000): entry="cn=Barbara Jensen,ou=Information Technology Division,ou=People,o=Example,c=US". [... blah blah etc. ...] PID=17066 - Bind(1000): dn="cn=Barbara Jensen,ou=Information Technology Division,ou=People,o=Example,c=US". PID=17080 - Search(500): base="cn=Monitor" scope=sub filter="(objectClass=*)" attrs=cn (more...). PID=17096 - Read(1000): entry="cn=Somewhere,ou=Meta,o=Example,c=US". slapd-bind PID=17066: ldap_sasl_bind_s: Invalid credentials (49) PID=17102 - Bind(1000): dn="cn=Bjorn Jensen,ou=Information Technology Division,ou=People,o=Example,c=US". PID=17112 - Search(500): base="cn=Monitor" scope=sub filter="(objectClass=*)" attrs=cn (more...). PID=17118 - Read(1000): entry="cn=Backend 1,cn=Backends,cn=Monitor". PID=17135 - Bind(1000): base="ou=People,o=Example,c=US", filter="(userPassword=*)" attr="userPassword". PID=17135 - Bind base="ou=People,o=Example,c=US" filter="(userPassword=*)" got 3 values. -- This is the last output I get. "ps" shows several test servers running as well as the test harness clients; "lsof" shows the clients stuck in poll() and doing nothing. They all have ESTABLISHED connections to their servers. -- zorro:1:1014 [/] # truss -p 17118 pollsys(0x0002CEFC, 1, 0x00000000, 0x00000000) (sleeping...) ^C zorro:1:1015 [/] # truss -p 17135 pollsys(0x0002C39C, 1, 0x00000000, 0x00000000) (sleeping...) -- I did a "gcore" and it says it's waiting in ldap_int_select(): -- (dbx) where [1] __pollsys(0x2c39c, 0x1, 0x0, 0x0, 0xfef523f0, 0x0), at 0xfeede7ac [2] _pollsys(0x2c39c, 0x1, 0x0, 0x0, 0x0, 0x2bb00), at 0xfeece490 [3] _poll(0x2c39c, 0x1, 0xffffffff, 0xffbfed8c, 0xff3ec2cc, 0x0), at 0xfee74ccc =>[4] ldap_int_select(ld = 0x289d0, timeout = (nil)), line 1139 in "os-ip.c" [5] wait4msg(ld = 0x289d0, msgid = 3, all = 1, timeout = (nil), result = 0xffbfef30), line 312 in "result.c" [6] ldap_result(ld = 0x289d0, msgid = 3, all = 1, timeout = (nil), result = 0xffbfef30), line 117 in "result.c" [7] ldap_sasl_bind_s(ld = 0x289d0, dn = 0x2ba58 "cn=Barbara Jensen,ou=Information Technology Division,ou=People,o=Example,c=US", mechanism = (nil), cred = 0xffbff080, sctrls = (nil), cctrls = (nil), servercredp = (nil)), line 210 in "sasl.c" -- Why are these things just sitting here instead of completing and exiting? BTW I am using the Solaris robust mutex fix patch (it wouldn't build otherwise) posted a few weeks back. Configured via ./configure --prefix=/opt/openldap --enable-modules --with-ldap-module=dynamic\ --enable-bdb --enable-rlookups --enable-wrappers --enable-dynamic \ --enable-ldap --disable-ipv6 --enable-overlays --with-threads --enable-relay\ --enable-syslog Puzzled in Pasadena, - Greg P.S. Here's the "ps" output if it matters zorro:1:1011 [/] # ps -ax PID TT S TIME COMMAND [...] 4413 pts/5 S 0:00 make test 4414 pts/5 S 0:00 sh -ce cd tests; make test 4415 pts/5 S 0:00 make test 4416 pts/5 S 0:00 make bdb 4418 pts/5 S 0:00 /bin/sh ./run -b bdb all 4429 pts/5 S 0:00 /bin/sh ./scripts/all 13917 pts/5 S 0:00 -sh 13922 pts/5 S 0:00 -csh 16491 pts/5 S 0:00 /bin/sh ./scripts/test039-glue-ldap-concurrency 16502 pts/5 S 0:44 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/servers/slapd/.libs/slapd -s0 -f /usr/local/src/networking/OpenLDAP 16560 pts/5 S 0:05 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/servers/slapd/.libs/slapd -s0 -f /usr/local/src/networking/OpenLDAP 16604 pts/5 S 2:05 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/servers/slapd/.libs/slapd -s0 -f /usr/local/src/networking/OpenLDAP 16649 pts/5 S 0:00 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/progs/.libs/slapd-tester -P ./progs -d /usr/local/src/network 16668 pts/5 S 0:00 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/progs/.libs/slapd-bind -h localhost -p 9013 -l 1000 -L 16674 pts/5 S 0:00 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/progs/.libs/slapd-bind -h localhost -p 9013 -l 1000 -L 16677 pts/5 S 0:00 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/progs/.libs/slapd-modrdn -h localhost -p 9013 -D cn=Man 16680 pts/5 S 0:00 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/progs/.libs/slapd-bind -h localhost -p 9013 -l 1000 -L 16943 pts/5 S 0:00 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/progs/.libs/slapd-modrdn -h localhost -p 9013 -D cn=Man 16957 pts/5 S 0:00 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/progs/.libs/slapd-modify -h localhost -p 9013 -D cn=Man 16959 pts/5 S 0:00 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/progs/.libs/slapd-addel -h localhost -p 9013 -D cn=Mana 16981 pts/5 S 0:00 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/progs/.libs/slapd-bind -h localhost -p 9013 -l 1000 -L 17005 pts/5 S 0:00 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/progs/.libs/slapd-search -h localhost -p 9013 -D cn=Man 17017 pts/5 S 0:00 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/progs/.libs/slapd-read -h localhost -p 9013 -D cn=Manag 17033 pts/5 S 0:00 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/progs/.libs/slapd-bind -h localhost -p 9013 -l 1000 -L 17047 pts/5 S 0:00 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/progs/.libs/slapd-search -h localhost -p 9013 -D cn=Man 17061 pts/5 S 0:00 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/progs/.libs/slapd-read -h localhost -p 9013 -D cn=Manag 17066 pts/5 S 0:00 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/progs/.libs/slapd-bind -h localhost -p 9013 -l 1000 -L 17080 pts/5 S 0:00 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/progs/.libs/slapd-search -h localhost -p 9013 -D cn=Man 17096 pts/5 S 0:00 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/progs/.libs/slapd-read -h localhost -p 9013 -D cn=Manag 17102 pts/5 S 0:00 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/progs/.libs/slapd-bind -h localhost -p 9013 -l 1000 -L 17112 pts/5 S 0:00 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/progs/.libs/slapd-search -h localhost -p 9013 -D cn=Man 17118 pts/5 S 0:00 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/progs/.libs/slapd-read -h localhost -p 9013 -D cn=Manag 17135 pts/5 S 0:00 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/progs/.libs/slapd-bind -h localhost -p 9013 -l 1000 -L

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical January 2016