openldap-software October 2009

openldap-software@openldap.org

44 participants
45 discussions

TLSProtocolMin 3.0 not accepted in 2.4.18
by ml+openldap＠esmtp.org 14 Oct '09

14 Oct '09

A dotted number is not accepted for TLSProtocolMin, e.g., TLSProtocolMin 3.0 However, it seems is should be, hence below is a patch: when looking for a number, make sure that not just the first character is a digit, but the entire string can be parsed as such. Note: IMHO this might not be the right fix, but "it works". The right fix might be to check for ARG_INT before trying to parse it as an integer. But that's too much of a change and I'm not that familiar with the code. Index: bconfig.c =================================================================== retrieving revision 1.3 diff -u -r1.3 bconfig.c --- bconfig.c 5 Oct 2009 16:22:10 -0000 1.3 +++ bconfig.c 7 Oct 2009 21:45:28 -0000 @@ -3626,13 +3626,8 @@ } ch_free( c->value_string ); c->cleanup = config_tls_cleanup; - if ( isdigit( (unsigned char)c->argv[1][0] ) ) { - if ( lutil_atoi( &i, c->argv[1] ) != 0 ) { - Debug(LDAP_DEBUG_ANY, "%s: " - "unable to parse %s \"%s\"\n", - c->log, c->argv[0], c->argv[1] ); - return 1; - } + if ( isdigit( (unsigned char)c->argv[1][0] ) && + lutil_atoi( &i, c->argv[1] ) == 0 ) { return(ldap_pvt_tls_set_option(slap_tls_ld, flag, &i)); } else { return(ldap_int_tls_config(slap_tls_ld, flag, c->argv[1]));

1 0

slapd 2.4.12 acl problem with multiple groups
by Tobias Florek 13 Oct '09

13 Oct '09

hi, I have a problem with acls on openldap. one defined group does not match any of its members. specifically, when i add an entry in ou=people,dc=... as member of cn=studadm,ou=group,dc=... (uid=florek) it works and i get in slapd's log (shortened): slapd[29022]: => access_allowed: add access to "ou=people,DC=mathematik,DC=hu-berlin,DC=de" "children" requested slapd[29022]: => dn: [1] cn=krbcontainer,ou=kerberos,DC=mathematik,DC=hu-berlin,DC=de slapd[29022]: => dn: [6] ou=autofs,DC=mathematik,DC=hu-berlin,DC=de slapd[29022]: => dn: [7] ou=group,DC=mathematik,DC=hu-berlin,DC=de slapd[29022]: => dn: [8] ou=people,DC=mathematik,DC=hu-berlin,DC=de slapd[29022]: => acl_get: [8] matched slapd[29022]: => acl_get: [8] attr children slapd[29022]: => acl_mask: access to entry "ou=people,DC=mathematik,DC=hu-berlin,DC=de", attr "children" requested slapd[29022]: => acl_mask: to all values by "uid=florek,ou=people,DC=mathematik,DC=hu-berlin,DC=de", (=0) slapd[29022]: <= check a_group_pat: cn=adm,ou=group,DC=mathematik,DC=hu-berlin,DC=de slapd[29022]: => bdb_entry_get: found entry: "cn=adm,ou=group,DC=mathematik,DC=hu-berlin,DC=de" slapd[29022]: <= check a_group_pat: cn=studadm,ou=group,DC=mathematik,DC=hu-berlin,DC=de slapd[29022]: => bdb_entry_get: found entry: "cn=studadm,ou=group,DC=mathematik,DC=hu-berlin,DC=de" slapd[29022]: <= acl_mask: [2] applying manage(=mwrscxd) (stop) slapd[29022]: <= acl_mask: [2] mask: manage(=mwrscxd) slapd[29022]: => slap_access_allowed: add access granted by manage(=mwrscxd) slapd[29022]: => access_allowed: add access granted by manage(=mwrscxd) [...] as member of cn=adm,ou=group,dc=... (uid=musch) it does not and i get: slapd[29022]: => access_allowed: add access to "ou=people,DC=mathematik,DC=hu-berlin,DC=de" "children" requested slapd[29022]: => dn: [1] cn=krbcontainer,ou=kerberos,DC=mathematik,DC=hu-berlin,DC=de slapd[29022]: => dn: [6] ou=autofs,DC=mathematik,DC=hu-berlin,DC=de slapd[29022]: => dn: [7] ou=group,DC=mathematik,DC=hu-berlin,DC=de slapd[29022]: => dn: [8] ou=people,DC=mathematik,DC=hu-berlin,DC=de slapd[29022]: => acl_get: [8] matched slapd[29022]: => acl_get: [8] attr children slapd[29022]: => acl_mask: access to entry "ou=people,DC=mathematik,DC=hu-berlin,DC=de", attr "children" requested slapd[29022]: => acl_mask: to all values by "uid=musch,ou=people,DC=mathematik,DC=hu-berlin,DC=de", (=0) slapd[29022]: <= check a_group_pat: cn=adm,ou=group,DC=mathematik,DC=hu-berlin,DC=de slapd[29022]: => bdb_entry_get: found entry: "cn=adm,ou=group,DC=mathematik,DC=hu-berlin,DC=de" slapd[29022]: <= check a_group_pat: cn=studadm,ou=group,DC=mathematik,DC=hu-berlin,DC=de slapd[29022]: => bdb_entry_get: found entry: "cn=studadm,ou=group,DC=mathematik,DC=hu-berlin,DC=de" slapd[29022]: <= check a_peername_path: 141.20.50.0%255.255.254.0 slapd[29022]: <= check a_peername_path: 141.20.52.0%255.255.252.0 slapd[29022]: <= acl_mask: [4] applying read(=rscxd) (stop) slapd[29022]: <= acl_mask: [4] mask: read(=rscxd) slapd[29022]: => slap_access_allowed: add access denied by read(=rscxd) slapd[29022]: => access_allowed: no more rules i am using openldap 2.4.12 from sles11 (rpm-version 2.4.12-7.18.1) with the following acls (added linebreaks to ease reading) (attribute olcAccess in olcDatabase={1}hdb,cn=config) {0} to dn.subtree="cn=krbContainer,ou=kerberos,DC=mathematik,DC=hu-berlin,DC=de" by dn.base="cn=kdc,ou=kerberos,DC=mathematik,DC=hu-berlin,DC=de" read by dn="cn=kadmin,ou=kerberos,DC=mathematik,DC=hu-berlin,DC=de" manage by * none {1} to attrs=userPassword,userPKCS12 by self write by * auth {2} to attrs=shadowLastChange by self write by * read {3} to attrs=uidNumber,gidNumber,homeDirectory by group="cn=adm,ou=group,dc=mathematik,dc=hu-berlin,dc=de" manage by group="cn=studadm,ou=group,dc=mathematik,dc=hu-berlin,dc=de" manage by peername.ip=141.20.50.0%255.255.254.0 read by peername.ip=141.20.52.0%255.255.252.0 read by * none {4} to attrs=sambaNTPassword,sambaLMPassword by * none {5} to dn.subtree="ou=autofs,DC=mathematik,DC=hu-berlin,DC=de" by group="cn=adm,ou=group,dc=mathematik,dc=hu-berlin,dc=de" manage by group="cn=studadm,ou=group,dc=mathematik,dc=hu-berlin,dc=de" manage by peername.ip=141.20.50.0%255.255.254.0 read by peername.ip=141.20.52.0%255.255.252.0 read by * none {6} to dn.subtree="ou=group,DC=mathematik,DC=hu-berlin,DC=de" by group="cn=adm,ou=group,dc=mathematik,dc=hu-berlin,dc=de" manage by group="cn=studadm,ou=group,dc=mathematik,dc=hu-berlin,dc=de" manage by peername.ip=141.20.50.0%255.255.254.0 read by peername.ip=141.20.52.0%255.255.252.0 read by * none {7} to dn.subtree="ou=people,DC=mathematik,DC=hu-berlin,DC=de" by group="cn=adm,ou=group,dc=mathematik,dc=hu-berlin,dc=de" manage by group="cn=studadm,ou=group,dc=mathematik,dc=hu-berlin,dc=de" manage by peername.ip=141.20.50.0%255.255.254.0 read by peername.ip=141.20.52.0%255.255.252.0 read by * none {8} to dn.subtree="ou=ethers,DC=mathematik,DC=hu-berlin,DC=de" by group="cn=adm,ou=group,dc=mathematik,dc=hu-berlin,dc=de" manage by group="cn=studadm,ou=group,dc=mathematik,dc=hu-berlin,dc=de" manage by peername.ip=141.20.50.0%255.255.254.0 read by peername.ip=141.20.52.0%255.255.252.0 read by * none {9} to * by * read groups are defined as follows: dn: cn=studadm,ou=group,DC=mathematik,DC=hu-berlin,DC=de gidNumber: 1300 memberUid: petrov memberUid: florek description: studentische Administratoren der Rechentechnik cn: studadm member: uid=petrov,ou=people,DC=mathematik,DC=hu-berlin,DC=de member: uid=florek,ou=people,DC=mathematik,DC=hu-berlin,DC=de objectClass: top objectClass: posixGroup objectClass: namedObject objectClass: groupOfNames dn: cn=adm,ou=group,DC=mathematik,DC=hu-berlin,DC=de cn: adm gidNumber: 1303 memberUid: gehne memberUid: rmielke memberUid: musch description: Administratoren der Rechentechnik member: uid=gehne,ou=people,DC=mathematik,DC=hu-berlin.de member: uid=rmielke,ou=people,DC=mathematik,DC=hu-berlin.de member: uid=musch,ou=people,DC=mathematik,DC=hu-berlin.de objectClass: top objectClass: posixGroup objectClass: namedObject objectClass: groupOfNames and users like this: dn: uid=musch,ou=people,DC=mathematik,DC=hu-berlin,DC=de uid: musch uidNumber: 3001 gidNumber: 3000 cn: Andre Musch objectClass: top objectClass: account objectClass: posixAccount loginShell: /bin/bash homeDirectory: /home_s/musch dn: uid=florek,ou=people,DC=mathematik,DC=hu-berlin,DC=de uid: florek uidNumber: 32839 gidNumber: 32003 cn: Tobias Florek homeDirectory: /u/florek objectClass: top objectClass: account objectClass: posixAccount loginShell: /bin/zsh any ideas? Tobias Florek

1 0

openldap service stop cause database corruption
by Antonini Gabriele 12 Oct '09

12 Oct '09

Hello, I'm running openldap 2.3.43 on CentOS 5.3 machine (1 Xeon @2.33GHz, 1.5GB RAM). My LDAP directory contains about 158000 entry (users) loaded from a massive ldif add. I'm using hdb database and I defined a couple of additional indexes to default configuration. Very often (not every time) I stop the service and restart I recive this message: hdb_db_open: unclean shutdown detected; attempting recovery. hdb_db_open: Recovery skipped in read-only mode. Run manual recovery if errors are encountered. After I recive this message I can't contact ldap server and I have to run slapd_db_recover (that takes long time) to recover db. This is a test environment and at this time there is no activity on the server (no read/write operations). This is DB_CONFIG file content (/var/lib/ldap/DB_CONFIG): # $OpenLDAP: pkg/ldap/servers/slapd/DB_CONFIG,v 1.1.2.4 2007/12/18 11:51:46 ghenry Exp $ # Example DB_CONFIG file for use with slapd(8) BDB/HDB databases. # # See the Oracle Berkeley DB documentation # <http://www.oracle.com/technology/documentation/berkeley-db/db/ref/env/db_co…> # for detail description of DB_CONFIG syntax and semantics. # # Hints can also be found in the OpenLDAP Software FAQ # <http://www.openldap.org/faq/index.cgi?file=2> # in particular: # <http://www.openldap.org/faq/index.cgi?file=1075> # Note: most DB_CONFIG settings will take effect only upon rebuilding # the DB environment. # one 0.25 GB cache # set_cachesize 0 268435456 1 set_cachesize 0 629145600 1 # Data Directory #set_data_dir db # Transaction Log settings set_lg_regionmax 262144 #EXP set_lg_bsize 2097152 #set_lg_dir logs # Note: special DB_CONFIG flags are no longer needed for "quick" # slapadd(8) or slapindex(8) access (see their -q option). I tried to reduce lg_buffer_size to force the server write log file more often to avoid possible "lost transaction" but this isn't working. Any ideas about the cause of these db corruptios? Thanks a lot, Gabriele

6 9

How do I change the log level
by Matt Burkhardt 10 Oct '09

10 Oct '09

This may be a really dump question - but I want to change the log level to just stats or to none. However, I'm using the new cn=config style and all of the documentation mentions changing the slapd.conf file. How would I change it? Thanks, Matt Burkhardt mlb(a)imparisystems.com http://www.imparisystems.com 502 Fairview Avenue Frederick, MD 21701 work (301) 682-7901 cell (301) 802-3235

3 3

syncrepl and the memberof overlay
by Michael Smith 09 Oct '09

09 Oct '09

Hi, Has anyone tried using the memberof overlay with syncrepl? I'm using openldap 2.4.12-7.18.1 on SLES11. I'd like to do multi-master replication for availability. Most user/group updates will happen only on one node, but password changes could happen anywhere. A couple of our apps like to see the memberOf attributes. My first thought was that I'd probably only need to run the overlay on one master. Does that sound about right? At first glance it seems that when memberof modifies user entries, it doesn't update the entryCSN. I'm not sure but I think this might cause some grief for syncrepl. If I add "testuser1" and "testgroup1" on ldap1, with testuser1 as a member of testgroup1, this is what I get on ldap1: ------- dn: dc=dom entryCSN: 20091005145613.859492Z#000000#000#000000 contextCSN: 20091005184427.691751Z#000000#000#000000 contextCSN: 20091006133430.568898Z#000000#001#000000 contextCSN: 20091005194750.632855Z#000000#002#000000 dn: uid=testuser1,ou=people,dc=dom entryCSN: 20091006133430.564578Z#000000#001#000000 memberOf: cn=testgroup1,ou=group,dc=dom dn: cn=testgroup1,ou=group,dc=dom member: uid=testuser1,ou=people,dc=dom entryCSN: 20091006133430.568898Z#000000#001#000000 ------- testuser1's entryCSN is earlier than testgroup1's, but memberof would have modified testuser1 AFTER testgroup1. This is what shows up on ldap2: ------- dn: dc=dom entryCSN: 20091005145613.859492Z#000000#000#000000 contextCSN: 20091006133430.568898Z#000000#001#000000 dn: uid=testuser1,ou=people,dc=dom entryCSN: 20091006133430.564578Z#000000#001#000000 dn: cn=testgroup1,ou=group,dc=dom member: uid=testuser1,ou=people,dc=dom entryCSN: 20091006133430.568898Z#000000#001#000000 ------- Configuration of ldap1: ------- dn: cn=config # ... olcServerID: 1 dn: olcDatabase={1}hdb,cn=config # ... olcAccess: {0}to attrs=userPassword by self write by dn.subtree="ou=service,dc=dom" read by * auth olcAccess: {1}to attrs=shadowLastChange by self write by * read olcAccess: {2}to attrs=userPKCS12 by self read by * none olcAccess: {3}to * by * read olcDbIndex: objectclass eq olcDbIndex: entryUUID eq olcDbIndex: entryCSN eq olcLimits: {0}dn.subtree="ou=service,dc=dom" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited olcSyncrepl: {0}rid=002 provider=ldap://ldap2.dom binddn="cn=repluser,ou=service,dc=dom" bindmethod=simple credentials=xxxxxx searchbase="dc=dom" attrs="*,+" type=refreshAndPersist schemachecking=off tls_cacert=/etc/openldap/ssl/ca.crt tls_reqcert=demand interval=00:00:05:00 retry="60 +" olcMirrorMode: TRUE dn: olcOverlay={0}syncprov,olcDatabase={1}hdb,cn=config objectClass: olcSyncProvConfig olcSpCheckpoint: 100 10 olcSpSessionlog: 1000 olcOverlay: {0}syncprov dn: olcOverlay={1}memberof,olcDatabase={1}hdb,cn=config objectClass: olcOverlayConfig olcOverlay: {1}memberof ------- Configuration of ldap2: ------- dn: cn=config # ... olcServerID: 2 dn: olcDatabase={1}hdb,cn=config # ... olcAccess: {0}to attrs=userPassword by self write by dn.subtree="ou=service,dc=dom" read by * auth olcAccess: {1}to attrs=shadowLastChange by self write by * read olcAccess: {2}to attrs=userPKCS12 by self read by * none olcAccess: {3}to * by * read olcDbIndex: objectclass eq olcDbIndex: entryUUID eq olcDbIndex: entryCSN eq olcLimits: {0}dn.subtree="ou=service,dc=dom" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited olcSyncrepl: {0}rid=001 provider=ldap://ldap1.dom binddn="cn=repluser,ou=service,dc=dom" bindmethod=simple credentials=xxxxxx searchbase="dc=dom" attrs="*,+" type=refreshAndPersist schemachecking=off tls_cacert=/etc/openldap/ssl/ca.crt tls_reqcert=demand interval=00:00:05:00 retry="60 +" olcMirrorMode: TRUE dn: olcOverlay={0}syncprov,olcDatabase={1}hdb,cn=config objectClass: olcSyncProvConfig olcSpCheckpoint: 100 10 olcSpSessionlog: 1000 olcOverlay: {0}syncprov ------- Here's the log from ldap1. I have the loglevel set to "stats sync": ------- conn=23 op=11 ADD dn="uid=testuser1,ou=people,dc=dom" slap_queue_csn: queing 0x7f4d125ec2c0 20091006133430.564578Z#000000#001#000000 conn=23 op=11 RESULT tag=105 err=0 text= syncprov_sendresp: cookie=rid=001,sid=002,csn=20091006133430.564578Z#000000#001#000000 slap_graduate_commit_csn: removing 0x7f4d1bca6b60 20091006133430.564578Z#000000#001#000000 conn=23 op=12 ADD dn="cn=testgroup1,ou=group,dc=dom" slap_queue_csn: queing 0x7f4d13dee2c0 20091006133430.568898Z#000000#001#000000 syncprov_sendresp: cookie=rid=001,sid=002,csn=20091006133430.568898Z#000000#001#000000 slap_graduate_commit_csn: removing 0x7f4d1be955b0 20091006133430.568898Z#000000#001#000000 conn=23 op=12 RESULT tag=105 err=0 text= syncprov_sendresp: cookie=rid=001,sid=002,csn=20091006133430.568898Z#000000#001#000000 do_syncrep2: cookie=rid=002,sid=001 syncrepl_entry: rid=002 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) dn_callback : entries have identical CSN cn=testgroup1,ou=group,dc=dom 20091006133430.568898Z#000000#001#000000 syncrepl_entry: rid=002 be_search (0) syncrepl_entry: rid=002 cn=testgroup1,ou=group,dc=dom syncrepl_entry: rid=002 entry unchanged, ignored (cn=testgroup1,ou=group,dc=dom) conn=23 op=13 UNBIND conn=23 fd=29 closed ------- And here's the log on ldap2. There's a "CSN too old" error at the bottom. ------- do_syncrep2: cookie=rid=001,sid=002,csn=20091006133430.564578Z#000000#001#000000 syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=001 be_search (0) syncrepl_entry: rid=001 uid=testuser1,ou=people,dc=dom slap_queue_csn: queing 0x7fece57d0860 20091006133430.564578Z#000000#001#000000 slap_graduate_commit_csn: removing 0x7fece57d2480 20091006133430.564578Z#000000#001#000000 syncrepl_entry: rid=001 be_add (0) slap_queue_csn: queing 0x7fece57d0860 20091006133430.564578Z#000000#001#000000 slap_graduate_commit_csn: removing 0x7fece57d4460 20091006133430.564578Z#000000#001#000000 do_syncrep2: cookie=rid=001,sid=002,csn=20091006133430.568898Z#000000#001#000000 syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=001 be_search (0) syncrepl_entry: rid=001 cn=testgroup1,ou=group,dc=dom slap_queue_csn: queing 0x7fece57d2480 20091006133430.568898Z#000000#001#000000 slap_graduate_commit_csn: removing 0x7fece57d0850 20091006133430.568898Z#000000#001#000000 syncrepl_entry: rid=001 be_add (0) slap_queue_csn: queing 0x7fece57d2480 20091006133430.568898Z#000000#001#000000 syncprov_sendresp: cookie=rid=002,sid=001 slap_graduate_commit_csn: removing 0x7fece57cea20 20091006133430.568898Z#000000#001#000000 do_syncrep2: cookie=rid=001,sid=002,csn=20091006133430.568898Z#000000#001#000000 do_syncrep2: rid=001 CSN too old, ignoring 20091006133430.568898Z#000000#001#000000 ------- Thanks, Mike

2 3

OpenLdap performance and Berkeley DB version
by Evgeniy 09 Oct '09

09 Oct '09

Hello. What has better performance , when using with OpenLdap 2.4.19 - Berkeley DB 4.5.20 or 4.7.25 ? Small DB (5-20 Mb), but many parallel read/write requests to it. -- ---______________________________________________--- Evgeniy

3 3

Fast massive ldif load
by iz1ksw iz1ksw 09 Oct '09

09 Oct '09

Hello, What is the fastest way (in terms of openldap settings) to perform a massive load (~200MB ldif file) of data into openldap directory? During load operation, no read/update operations will be performed, only simple load. I start the process from command line: ldapadd -xvc -D "cn=Manager,dc=progettotrio,dc=it" -W -f 20090910152733_output.ldif Thanks, iz1ksw

5 6

ch_malloc of 0 bytes failed
by Edgar Fuß 08 Oct '09

08 Oct '09

This afternoon, one of our slapds died with "ch_malloc of 0 bytes failed". Is there any known issue with 2.4.15 that can lead to this behaviour? In case it matters, the server in question operates as a syncrepl consumer with updateref and the chain overlay. The last messages (all within the same second) are: do_syncrep2: cookie=rid=001,csn=20091008134919.158418Z#000000#000#000000 syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) syncrepl_entry: rid=001 be_search (0) syncrepl_entry: rid=001 uid=<censored> slap_queue_csn: queing 0xfd1d980 20091008134919.158418Z#000000#000#000000 slap_graduate_commit_csn: removing 0xfd1f780 20091008134919.158418Z#000000#000#000000 syncrepl_entry: rid=001 be_modrdn (0) slap_queue_csn: queing 0xfd1d980 20091008134919.158418Z#000000#000#000000 ch_malloc of 0 bytes failed Restarting slapd simply worked. Thanks for any help.

1 0

problem with security ppolicy
by Evgeniy 08 Oct '09

08 Oct '09

hello OpenLdap 2.4.18. Attribute "pwdAccountLockedTime" is set, but auth is still Ok . Why ? On Ldap 2.3 it works normal - user don't auth after this date. # date Tue Sep 22 21:24:44 MSD 2009 ldapsearch -h localhost -x -b 'ou=SrpUsers,dc=company,dc=com' -D "cn=admin,dc=company,dc=com" -w password "cn=_1*" + | grep pwdAccountLockedTime pwdAccountLockedTime: 20090922153148Z but slapauth -v -f /usr/local/etc/openldap/slapd.conf -U _125363 -X u:_125363 bdb_db_open: warning - no DB_CONFIG file found in directory /usr/local/var/accesslog-data: (2). Expect poor performance for suffix "cn=accesslog". bdb_db_open: warning - no DB_CONFIG file found in directory /usr/local/var/openldap-data: (2). Expect poor performance for suffix "dc=company,dc=com". ID: <_125363> authcDN: <uid=_125363,cn=auth> authzDN: <uid=_125363,cn=auth> authorization OK How I can resolve problem with non-working "pwdAccountLockedTime" ? -- ---______________________________________________--- Evgeniy

3 9

slapd hangs on startup
by Peter Mogensen 07 Oct '09

07 Oct '09

Hi, This issue has been bugging me for a while, but I can't find anything about it when googling. I have a slapd 2.3.x server which has been taking longer and longer to start. Lately it has ben 45 min. for a restart. With strace you can just see it waiting for a futex: Process 22740 attached - interrupt to quit futex(0x56274bd8, FUTEX_WAIT, 22742, NULL ... then suddenly it starts to listen and answer queries. Now, I hoped my planed upgrade to 2.4.x would solve that, but alas! I now have a running setup with 2.4.17 compiled with OpenSSL in mirrormode, mirroring cn=config and the primary database with TLS (with client certs and SASL EXTERNAL), running on Linux 2.6.18 on a "vserver". And it still hangs on startup. I would suspect that it has something to do with the vserver. One explanation would be if slapd tried to connect to it self via TCP, since the kernel just DROP packets to 127.0.0.1. Another explantion would be that It can't gather enough entropy, but my 2.3..x setup didn't use TLS and I have checked the /dev/random /dev/urandom are world readable. Looking at debug output at server-1 I see things like: ber_flush2 failed errno=11 reason="Resource temporarily unavailable" and: connection_write(17): waking output for id=2 connection_get(17): got connid=2 connection_write(17): waking output for id=2 connection_get(17): got connid=2 connection_write(17): waking output for id=2 connection_get(17): got connid=2 connection_write(17): waking output for id=2 ber_flush2: 933 bytes to sd 17 send_search_entry: conn 2 ber write failed. connection_close: conn=2 sd=17 connection_read(17): no connection! connection_read(17): no connection! connection_read(17): no connection! connection_read(17): no connection! Where sd 17 seems to be the last of 4 syncrepl connections. lsof tells me: slapd 25704 root 14u IPv4 852048 TCP s01:40400->s02:ldaps (ESTABLISHED) slapd 25704 root 15u IPv4 852057 TCP s01:40401->s02:ldaps (ESTABLISHED) slapd 25704 root 16u IPv4 852169 TCP s01:ldaps->s02:48705 (ESTABLISHED) But the last (sd 17) seems to be closed again. It seems syncrepl tried to get startet, (the other server is empty, since the database has just been loaded with slapdadd -w on server-1) But it only mamanges to syncrepl the first 5 entries or so. slapd -d 16384 output is: slapd starting do_syncrep2: rid=004 LDAP_RES_INTERMEDIATE - REFRESH_DELETE do_syncrep2: rid=002 LDAP_RES_INTERMEDIATE - REFRESH_DELETE send_search_entry: conn 2 ber write failed. connection_read(17): no connection! connection_read(17): no connection! connection_read(17): no connection! send_search_entry: conn 3 ber write failed. connection_write(17): no connection! send_search_entry: conn 4 ber write failed. connection_write(17): no connection! send_search_entry: conn 5 ber write failed. connection_write(17): no connection! .... What can slapd be waiting for? /Peter

3 8

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-software October 2009