openldap-technical

openldap-technical@openldap.org

21 participants
9802 discussions

Multiple CSN use
by Emmanuel BILLOT 13 Oct '13

13 Oct '13

Hi, I read a thread about multiple CSN. If a server have to replicate multiple parts from several servers, it must have multiplace CSN. Now we use multiple database for having multiple CSN (one subordinate per remote server), but this thread seems to talk about multiple CSN using with one database. What should be a simple conf example to use multiple CSN values ? I didn't find any doc about using multiple CSN with "correctly used SIDs". http://www.openldap.org/lists/openldap-technical/201011/msg00153.html "But the SIDs will only be used correctly if the URLs in the ServerID directive match the actual URLs given to the slapd -h option." Regards,

2 1

contextCSN format
by Emmanuel BILLOT 13 Oct '13

13 Oct '13

Hi, When using refreshonly replication, i cannot see any rid or sid info on the consumer contextCSN Oct 13 21:39:24 seshat-test slapd[5053]: do_syncrep2: cookie=rid=003,sid=003,csn=20131013024923.410481Z#000000#000#000000 Oct 13 21:39:24 seshat-test slapd[5053]: slap_queue_csn: queing 0x8765080 20131013024923.410481Z#000000#000#000000 Oct 13 21:39:24 seshat-test slapd[5053]: slap_graduate_commit_csn: removing 0x8761170 20131013024923.410481Z#000000#000#000000 Whereas ServerID is set on provider. What could explain this ?

1 0

memberof overlay results in unexpected slapd death?
by Paul B. Henson 12 Oct '13

12 Oct '13

Our LDAP infrastructure is currently running 2.4.35, and consists of two read/write masters configured in mirror mode behind the load balancer, with three additional read-only slaves using syncrepl. We recently decided to add the memberof overlay to our configuration, due to an application that did not support querying the groups for members. I updated our configuration to load the module, and add the overlay, and proceeded to rip through all of our groups removing and then re-adding the members in order to populate the memberOf attribute on the user objects. While doing so, there were errors logged on all of the servers: Oct 10 04:26:09 fosse slapd[9944]: conn=75373 op=184748: memberof_value_modify DN="uid=tdnguyen1,ou=user,dc=cs upomona,dc=edu" delete memberOf="uid=classes,ou=group,dc=csupomona,dc=edu" failed err=16 This was expected, as the memberOf attribute did not exist in our current directory. However, what was unexpected was that the slapd processes started to mysteriously die while I was trying to repopulate the groups. No log messages, or any other indication of the failure, just attribute delete errors: Oct 10 04:29:39 filmore slapd[25526]: conn=-1 op=0: memberof_value_modify DN="uid=rfu,ou=user,dc=csupomona,dc=edu" delete memberOf="uid=mhr31806,ou=group,dc=csupomona,dc=edu" failed err=16 Oct 10 04:29:39 filmore slapd[25526]: conn=-1 op=0: memberof_value_modify DN="uid=rfu,ou=user,dc=csupomona,dc=edu" delete memberOf="uid=mhr_classes,ou=group,dc=csupomona,dc=edu" failed err=16 Then the process was gone. It was definitely related to mass group updates, they would run for hours with no problems under general use, but as soon as I started churning group members, bam, one or two of them would go away. I ended up backing out the modification, dumping the database, removing all of the memberOf attributes, and reloading it. I will try to duplicate this in a test environment with debugging enabled and see if I can get a better idea what's going on, but I was just curious if anyone had seen anything like this or knew of any underlying issues with the memberof overlay. Thanks much.

3 6

mysterious glue record with empty dn
by Paul B. Henson 11 Oct '13

11 Oct '13

While I was trying to recover my directory from an aborted attempt to implement the memberof overlay, I ended up dumping the database with slapcat and then reloading it with slapadd after removing the now invalid MEMBEROF attributes that lingered after the overlay was disabled. Strangely, on some of my servers, a glue object with an empty DN showed up in the slapcat output: dn: objectClass: glue structuralObjectClass: glue entryUUID: 411f0301-e857-4228-a22d-c5d1451d4496 creatorsName: cn=ldaproot,dc=csupomona,dc=edu createTimestamp: 20131007210011Z entryCSN: 20131007210011.273579Z#000000#000#000000 modifyTimestamp: 20131007210011Z modifiersName: cn=idmgmt,ou=user,ou=service,dc=csupomona,dc=edu slapadd refused to load the input file with this record at the top, I ended up deleting it and then it seemed to load fine. I'm not sure where this record came from? From what I could research, it seems glue records are created when you delete part of the hierarchy that is in between the top and some lower record? I don't think I did that, plus I don't see why it would have an empty DN? This must have something to do with my attempt to implement the memberof overlay, as I have never seen it before. Any thoughts? Thanks.

2 2

memberof overlay replicating memberOf attribute?
by Paul B. Henson 11 Oct '13

11 Oct '13

Based on the documentation, my understanding was that the memberof overlay maintained the memberOf attribute locally, and this attribute was not replicated? While I was recently working on implementing the memberof overlay, I noticed that after I had enabled it on one server, before enabling it on another, the memberOf attribute seemed to be replicated from the server on which the overlay was enabled to the one on which it was not: Oct 7 18:30:18 filmore slapd[28994]: UNKNOWN attributeDescription "MEMBEROF" inserted. Oct 7 18:30:18 fosse slapd[3047]: UNKNOWN attributeDescription "MEMBEROF" inserted. Oct 10 16:23:08 pip-dev slapd[7030]: slapd starting Oct 10 16:23:08 pip-dev slapd[7030]: UNKNOWN attributeDescription "MEMBEROF" inserted. This seems contrary to the documentation and I found it confusing. Am I missing something? Thanks.

2 2

unixUserPassword and userPassword
by jupiter 11 Oct '13

11 Oct '13

Hi, I am migrating user account entries from an old openldap AD to openldap BDB. Both LDAP client authentications are implemented in Linux, the former in CentOS 5, and the latter in CentOS 6. But the major problem is that the old openldap AD uses encrypted password in "unixUserPassword:" while the openldap BDB uses base64 "userPassword::". The option for solution I could think of are: (a) Convert the encrypted password from unixUserPassword format to userPasswor, then I can use ldapmodify to change userPassword. Is it possible? If it is, appreciate more details. (b) Change LDAP client authentication to use unixUserPassword. I haven't found any document to configure Linux client authentication to use unixUserPassword. In fact, I could not find any document regarding details of uing unixUserPassword. Any suggestions, tips and advice are very much appreciated. Thank you. Kind regards, jupiter Sorry for asking a non-dev question, but I could not find any solution from openldap document, nor from Internet searching. Thank you and appreciate any advice. Kind regards, jupiter

2 4

sasl/plain with hashed password not working
by btb 10 Oct '13

10 Oct '13

i've enabled the plain sasl mech, and testing with ldapwhoami works, but only if the userpassword is left as plaintext. if hashing [ssha] is used, it fails. a simple bind succeeds. what am i doing wrong? >ldapwhoami -H 'ldap://dsa4.example.com/' -Y 'plain' -U 'flash' -w 'xxxxxxxx' SASL/PLAIN authentication started ldap_sasl_interactive_bind_s: Invalid credentials (49) additional info: SASL(-13): user not found: Password verification failed 524b7989 daemon: activity on 1 descriptor 524b7989 daemon: activity on:524b7989 524b7989 slap_listener_activate(7): 524b7989 daemon: epoll: listen=7 busy 524b7989 daemon: epoll: listen=8 active_threads=0 tvp=NULL 524b7989 >>> slap_listener(ldap:///) 524b7989 daemon: activity on 1 descriptor 524b7989 daemon: activity on:524b7989 524b7989 daemon: epoll: listen=7 active_threads=0 tvp=NULL 524b7989 daemon: epoll: listen=8 active_threads=0 tvp=NULL 524b7989 daemon: listen=7, new connection on 16 524b7989 daemon: added 16r (active) listener=(nil) 524b7989 daemon: activity on 1 descriptor 524b7989 daemon: activity on:524b7989 524b7989 daemon: epoll: listen=7 active_threads=0 tvp=NULL 524b7989 daemon: epoll: listen=8 active_threads=0 tvp=NULL 524b7989 conn=1014 fd=16 ACCEPT from IP=192.168.1.81:35171 (IP=0.0.0.0:389) 524b7989 daemon: activity on 1 descriptor 524b7989 daemon: activity on:524b7989 16r524b7989 524b7989 daemon: read active on 16 524b7989 daemon: epoll: listen=7 active_threads=0 tvp=NULL 524b7989 daemon: epoll: listen=8 active_threads=0 tvp=NULL 524b7989 connection_get(16) 524b7989 connection_get(16): got connid=1014 524b7989 connection_read(16): checking for input on id=1014 ber_get_next ldap_read: want=8, got=8 0000: 30 22 02 01 01 60 1d 02 0"...`.. ldap_read: want=28, got=28 0000: 01 03 04 00 a3 16 04 05 50 4c 41 49 4e 04 0d 00 ........PLAIN... 0010: 66 6c 61 73 68 00 74 69 67 67 65 72 flash.xxxxxxx ber_get_next: tag 0x30 len 34 contents: ber_dump: buf=0x7f1580103750 ptr=0x7f1580103750 end=0x7f1580103772 len=34 0000: 02 01 01 60 1d 02 01 03 04 00 a3 16 04 05 50 4c ...`..........PL 0010: 41 49 4e 04 0d 00 66 6c 61 73 68 00 74 69 67 67 AIN...flash.xxxx 0020: 65 72 xxxxxx 524b7989 op tag 0x60, time 1380678025 ber_get_next ldap_read: want=8 error=Resource temporarily unavailable 524b7989 conn=1014 op=0 do_bind 524b7989 daemon: activity on 1 descriptor ber_scanf fmt ({imt) ber: ber_dump: buf=0x7f1580103750 ptr=0x7f1580103753 end=0x7f1580103772 len=31 0000: 60 1d 02 01 03 04 00 a3 16 04 05 50 4c 41 49 4e `..........PLAIN 0010: 04 0d 00 66 6c 61 73 68 00 74 69 67 67 65 72 ...flash.xxxxxxxx ber_scanf fmt ({m) ber: ber_dump: buf=0x7f1580103750 ptr=0x7f158010375a end=0x7f1580103772 len=24 0000: 00 16 04 05 50 4c 41 49 4e 04 0d 00 66 6c 61 73 ....PLAIN...flas 0010: 68 00 74 69 67 67 65 72 h.xxxxxxxxx ber_scanf fmt (m) ber: ber_dump: buf=0x7f1580103750 ptr=0x7f1580103763 end=0x7f1580103772 len=15 0000: 00 0d 00 66 6c 61 73 68 00 74 69 67 67 65 72 ...flash.xxxxxxx ber_scanf fmt (}}) ber: ber_dump: buf=0x7f1580103750 ptr=0x7f1580103772 end=0x7f1580103772 len=0 524b7989 >>> dnPrettyNormal: <> 524b7989 <<< dnPrettyNormal: <>, <> 524b7989 conn=1014 op=0 BIND dn="" method=163 524b7989 do_bind: dn () SASL mech PLAIN 524b7989 ==> sasl_bind: dn="" mech=PLAIN datalen=13 524b7989 SASL Canonicalize [conn=1014]: authcid="flash" 524b7989 slap_sasl_getdn: conn 1014 id=flash [len=5] => ldap_dn2bv(16) <= ldap_dn2bv(uid=flash,cn=PLAIN,cn=auth)=0 524b7989 slap_sasl_getdn: u:id converted to uid=flash,cn=PLAIN,cn=auth 524b7989 >>> dnNormalize: <uid=flash,cn=PLAIN,cn=auth> => ldap_bv2dn(uid=flash,cn=PLAIN,cn=auth,0) <= ldap_bv2dn(uid=flash,cn=PLAIN,cn=auth)=0 => ldap_dn2bv(272) <= ldap_dn2bv(uid=flash,cn=plain,cn=auth)=0 524b7989 <<< dnNormalize: <uid=flash,cn=plain,cn=auth> 524b7989 ==>slap_sasl2dn: converting SASL name uid=flash,cn=plain,cn=auth to a DN 524b7989 ==> rewrite_context_apply [depth=1] string='uid=flash,cn=plain,cn=auth' 524b7989 ==> rewrite_rule_apply rule='uid=([^,]*),cn=digest-md5,cn=auth' string='uid=flash,cn=plain,cn=auth' [1 pass(es)] 524b7989 ==> rewrite_rule_apply rule='uid=([^,]*),cn=plain,cn=auth' string='uid=flash,cn=plain,cn=auth' [1 pass(es)] 524b7989 ==> rewrite_context_apply [depth=1] res={0,'uid=flash,ou=people,ou=accounts,dc=example,dc=com'} 524b7989 [rw] authid: "uid=flash,cn=plain,cn=auth" -> "uid=flash,ou=people,ou=accounts,dc=example,dc=com" 524b7989 slap_parseURI: parsing uid=flash,ou=people,ou=accounts,dc=example,dc=com ldap_url_parse_ext(uid=flash,ou=people,ou=accounts,dc=example,dc=com) 524b7989 >>> dnNormalize: <uid=flash,ou=people,ou=accounts,dc=example,dc=com> => ldap_bv2dn(uid=flash,ou=people,ou=accounts,dc=example,dc=com,0) <= ldap_bv2dn(uid=flash,ou=people,ou=accounts,dc=example,dc=com)=0 => ldap_dn2bv(272) <= ldap_dn2bv(uid=flash,ou=people,ou=accounts,dc=example,dc=com)=0 524b7989 <<< dnNormalize: <uid=flash,ou=people,ou=accounts,dc=example,dc=com> 524b7989 <==slap_sasl2dn: Converted SASL name to uid=flash,ou=people,ou=accounts,dc=example,dc=com 524b7989 slap_sasl_getdn: dn:id converted to uid=flash,ou=people,ou=accounts,dc=example,dc=com 524b7989 SASL Canonicalize [conn=1014]: slapAuthcDN="uid=flash,ou=people,ou=accounts,dc=example,dc=com" 524b7989 SASL Canonicalize [conn=1014]: authcid="flash" 524b7989 slap_sasl_getdn: conn 1014 id=flash [len=5] => ldap_dn2bv(16) <= ldap_dn2bv(uid=flash,cn=PLAIN,cn=auth)=0 524b7989 slap_sasl_getdn: u:id converted to uid=flash,cn=PLAIN,cn=auth 524b7989 >>> dnNormalize: <uid=flash,cn=PLAIN,cn=auth> => ldap_bv2dn(uid=flash,cn=PLAIN,cn=auth,0) <= ldap_bv2dn(uid=flash,cn=PLAIN,cn=auth)=0 => ldap_dn2bv(272) <= ldap_dn2bv(uid=flash,cn=plain,cn=auth)=0 524b7989 <<< dnNormalize: <uid=flash,cn=plain,cn=auth> 524b7989 ==>slap_sasl2dn: converting SASL name uid=flash,cn=plain,cn=auth to a DN 524b7989 ==> rewrite_context_apply [depth=1] string='uid=flash,cn=plain,cn=auth' 524b7989 ==> rewrite_rule_apply rule='uid=([^,]*),cn=digest-md5,cn=auth' string='uid=flash,cn=plain,cn=auth' [1 pass(es)] 524b7989 ==> rewrite_rule_apply rule='uid=([^,]*),cn=plain,cn=auth' string='uid=flash,cn=plain,cn=auth' [1 pass(es)] 524b7989 ==> rewrite_context_apply [depth=1] res={0,'uid=flash,ou=people,ou=accounts,dc=example,dc=com'} 524b7989 [rw] authid: "uid=flash,cn=plain,cn=auth" -> "uid=flash,ou=people,ou=accounts,dc=example,dc=com" 524b7989 slap_parseURI: parsing uid=flash,ou=people,ou=accounts,dc=example,dc=com ldap_url_parse_ext(uid=flash,ou=people,ou=accounts,dc=example,dc=com) 524b7989 >>> dnNormalize: <uid=flash,ou=people,ou=accounts,dc=example,dc=com> => ldap_bv2dn(uid=flash,ou=people,ou=accounts,dc=example,dc=com,0) <= ldap_bv2dn(uid=flash,ou=people,ou=accounts,dc=example,dc=com)=0 => ldap_dn2bv(272) <= ldap_dn2bv(uid=flash,ou=people,ou=accounts,dc=example,dc=com)=0 524b7989 <<< dnNormalize: <uid=flash,ou=people,ou=accounts,dc=example,dc=com> 524b7989 <==slap_sasl2dn: Converted SASL name to uid=flash,ou=people,ou=accounts,dc=example,dc=com 524b7989 slap_sasl_getdn: dn:id converted to uid=flash,ou=people,ou=accounts,dc=example,dc=com 524b7989 SASL Canonicalize [conn=1014]: slapAuthcDN="uid=flash,ou=people,ou=accounts,dc=example,dc=com" 524b7989 => mdb_search 524b7989 mdb_dn2entry("uid=flash,ou=people,ou=accounts,dc=example,dc=com") 524b7989 => mdb_dn2id("uid=flash,ou=people,ou=accounts,dc=example,dc=com") 524b7989 <= mdb_dn2id: got id=0x2c 524b7989 => mdb_entry_decode: 524b7989 <= mdb_entry_decode 524b7989 => access_allowed: auth access to "uid=flash,ou=people,ou=accounts,dc=example,dc=com" "entry" requested 524b7989 => dn: [2] uid=flash,ou=people,ou=accounts,dc=example,dc=com 524b7989 => acl_get: [2] matched 524b7989 => acl_get: [2] attr entry 524b7989 => acl_mask: access to entry "uid=flash,ou=people,ou=accounts,dc=example,dc=com", attr "entry" requested 524b7989 => acl_mask: to all values by "", (=0) 524b7989 <= check a_dn_pat: self 524b7989 <= check a_dn_pat: users 524b7989 <= check a_dn_pat: anonymous 524b7989 <= acl_mask: [3] applying auth(=xd) (stop) 524b7989 <= acl_mask: [3] mask: auth(=xd) 524b7989 => slap_access_allowed: auth access granted by auth(=xd) 524b7989 => access_allowed: auth access granted by auth(=xd) 524b7989 base_candidates: base: "uid=flash,ou=people,ou=accounts,dc=example,dc=com" (0x0000002c) 524b7989 => test_filter 524b7989 daemon: activity on:524b7989 PRESENT 524b7989 => access_allowed: auth access to "uid=flash,ou=people,ou=accounts,dc=example,dc=com" "objectClass" requested 524b7989 => dn: [2] uid=flash,ou=people,ou=accounts,dc=example,dc=com 524b7989 => acl_get: [2] matched 524b7989 => acl_get: [2] attr objectClass 524b7989 => acl_mask: access to entry "uid=flash,ou=people,ou=accounts,dc=example,dc=com", attr "objectClass" requested 524b7989 => acl_mask: to all values by "", (=0) 524b7989 <= check a_dn_pat: self 524b7989 <= check a_dn_pat: users 524b7989 <= check a_dn_pat: anonymous 524b7989 <= acl_mask: [3] applying auth(=xd) (stop) 524b7989 <= acl_mask: [3] mask: auth(=xd) 524b7989 => slap_access_allowed: auth access granted by auth(=xd) 524b7989 => access_allowed: auth access granted by auth(=xd) 524b7989 <= test_filter 6 524b7989 => access_allowed: auth access to "uid=flash,ou=people,ou=accounts,dc=example,dc=com" "userPassword" requested 524b7989 => acl_get: [1] attr userPassword 524b7989 => acl_mask: access to entry "uid=flash,ou=people,ou=accounts,dc=example,dc=com", attr "userPassword" requested 524b7989 => acl_mask: to all values by "", (=0) 524b7989 <= check a_dn_pat: anonymous 524b7989 <= acl_mask: [1] applying auth(=xd) (stop) 524b7989 <= acl_mask: [1] mask: auth(=xd) 524b7989 => slap_access_allowed: auth access granted by auth(=xd) 524b7989 => access_allowed: auth access granted by auth(=xd) 524b7989 slap_ap_lookup: str2ad(cmusaslsecretPLAIN): attribute type undefined 524b7989 send_ldap_result: conn=1014 op=0 p=3 524b7989 send_ldap_result: err=0 matched="" text="" 524b7989 SASL [conn=1014] Failure: Password verification failed 524b7989 send_ldap_result: conn=1014 op=0 p=3 524b7989 send_ldap_result: err=49 matched="" text="SASL(-13): user not found: Password verification failed" 524b7989 send_ldap_response: msgid=1 tag=97 err=49 ber_flush2: 69 bytes to sd 16 0000: 30 43 02 01 01 61 3e 0a 01 31 04 00 04 37 53 41 0C...a>..1...7SA 0010: 53 4c 28 2d 31 33 29 3a 20 75 73 65 72 20 6e 6f SL(-13): user no 0020: 74 20 66 6f 75 6e 64 3a 20 50 61 73 73 77 6f 72 t found: Passwor 0030: 64 20 76 65 72 69 66 69 63 61 74 69 6f 6e 20 66 d verification f 0040: 61 69 6c 65 64 ailed ldap_write: want=69, written=69 0000: 30 43 02 01 01 61 3e 0a 01 31 04 00 04 37 53 41 0C...a>..1...7SA 0010: 53 4c 28 2d 31 33 29 3a 20 75 73 65 72 20 6e 6f SL(-13): user no 0020: 74 20 66 6f 75 6e 64 3a 20 50 61 73 73 77 6f 72 t found: Passwor 0030: 64 20 76 65 72 69 66 69 63 61 74 69 6f 6e 20 66 d verification f 0040: 61 69 6c 65 64 ailed 524b7989 conn=1014 op=0 RESULT tag=97 err=49 text=SASL(-13): user not found: Password verification failed 524b7989 <== slap_sasl_bind: rc=49 524b7989 524b7989 daemon: epoll: listen=7 active_threads=0 tvp=NULL 524b7989 daemon: epoll: listen=8 active_threads=0 tvp=NULL 524b7989 daemon: activity on 1 descriptor 524b7989 daemon: activity on:524b7989 16r524b7989 524b7989 daemon: read active on 16 524b7989 daemon: epoll: listen=7 active_threads=0 tvp=NULL 524b7989 daemon: epoll: listen=8 active_threads=0 tvp=NULL 524b7989 connection_get(16) 524b7989 connection_get(16): got connid=1014 524b7989 connection_read(16): checking for input on id=1014 ber_get_next ldap_read: want=8, got=7 0000: 30 05 02 01 02 42 00 0....B. ber_get_next: tag 0x30 len 5 contents: ber_dump: buf=0x7f1584117620 ptr=0x7f1584117620 end=0x7f1584117625 len=5 0000: 02 01 02 42 00 ...B. 524b7989 op tag 0x42, time 1380678025 ber_get_next ldap_read: want=8, got=0 524b7989 ber_get_next on fd 16 failed errno=0 (Success) 524b7989 connection_read(16): input error=-2 id=1014, closing. 524b7989 connection_closing: readying conn=1014 sd=16 for close 524b7989 daemon: activity on 1 descriptor 524b7989 daemon: activity on:524b7989 524b7989 daemon: epoll: listen=7 active_threads=0 tvp=NULL 524b7989 connection_close: deferring conn=1014 sd=16 524b7989 daemon: epoll: listen=8 active_threads=0 tvp=NULL 524b7989 conn=1014 op=1 do_unbind 524b7989 conn=1014 op=1 UNBIND 524b7989 connection_resched: attempting closing conn=1014 sd=16 524b7989 connection_close: conn=1014 sd=16 524b7989 daemon: removing 16 524b7989 conn=1014 fd=16 closed

4 7

slapcat backup with empty DNs
by Samir Cury 10 Oct '13

10 Oct '13

Dear all, The problem I'm having is simple, although I didn't find much eplanations for it, once I try to backup the database with : slapcat -v -l ldap-backup5.ldif It works nicely, except that _all_ entries have : dn: structuralObjectClass: organizationalUnit dn: objectClass: organizationalRole cn: Manager dn: structuralObjectClass: inetOrgPerson entryUUID: e8ef2300-f04c-10fb-9b02-a54a91b9c30b (empty DNs) Although the information is still there, if I ldapsearch one of the entities it comes easily : ldapsearch -x -LLL '(uid=samir)' dn: cn=Samir Cury,ou=abc,ou=def,dc=org,dc=edu cn: Samir Cury Siqueira objectClass: inetOrgPerson is this problem obvious to any of you? The only similar case I found in the history was :http://www.openldap.org/lists/openldap-technical/201201/msg00160.html Which doesn't have a clear outcome. Any hint on where to look at? Thanks, Samir ==== Aditional information - just in case ==== My setup is a 1 Master 1 Slave of slapd 2.3.43. Relevant information is that after the master's hardware died, few days later the slave started to misbehave and probably got the DB corrupted. slapd_db_recover seems to have fixed it as now it is working just fine, log messages from before the error / recovery : #slapcat -v -l ldap-backup.ldif bdb_db_open: unclean shutdown detected; attempting recovery. bdb_db_open: Recovery skipped in read-only mode. Run manual recovery if errors are encountered. #slapd_db_recover -v -h /var/lib/ldap Finding last valid log LSN: file: 2 offset 6078834 Recovery starting from [2][6065934] Recovery complete at Wed Oct 9 16:42:55 2013 Maximum transaction ID 8000c207 Recovery checkpoint [2][6091589] -- slapcat now has no warnings/errors -- I suspect slightly of this as I've read that corrupted databases can cause such effects, but the ldapsearch with full DNs makes me think that it didn't happen. ==== / Aditional information ====

2 1

another CSN too old N-WAY master
by Lanfeust troy 10 Oct '13

10 Oct '13

hi all, sometimes my server a not in sync. because server ignoring entry: do_syncrep2: rid=102 CSN too old, ignoring 20130923090023.266239Z#000000#002#000000 @(#) $OpenLDAP: slapd 2.4.33 (....) 4 server host1 and host 2: only one database c=fr ( contain an ou=apps-ext ) host3 and host 4: tow database: first ou=apps-ext (glued with c=fr ). writable by host1,2,3,4 second c=fr writable only by host1,2 ldap-int1 and ldap-int2 cn=config also into syncrepl mirrorMode ldap-ext1 and ldap-ext2 cn=config also into syncrepl mirrorMode Configuration: grep serverID /etc/openldap/slapd.d/* /etc/openldap/slapd.d/cn=config.ldif:olcServerID: 1 ldaps://ldap-int1.dom.fr /etc/openldap/slapd.d/cn=config.ldif:olcServerID: 2 ldaps://ldap-int2.dom.fr /etc/openldap/slapd.d/cn=config.ldif:olcServerID: 3 ldaps:// ldap-ext1.vlandata.dom.fr /etc/openldap/slapd.d/cn=config.ldif:olcServerID: 4 ldaps:// ldap-ext2.vlandata.dom.fr syncrepl: ldap-int1 and ldap-int2 cn=config also into syncrepl olcSyncrepl: {0}rid=101 provider=ldaps://ldap-int1.dom.frbinddn="uid=syncrepl ,ou=system,ou=dom,o=domgroup,c=fr" bindmethod=simple credentials=XXXXXX sea rchbase="c=fr" tls_reqcert=never type=refreshAndPersist interval=00:00:00:10 retry="5 5 300 +" timeout=1 olcSyncrepl: {1}rid=102 provider=ldaps://ldap-int2.cdoms.frbinddn="uid=syncrepl ,ou=system,ou=dom,o=domgroup,c=fr" bindmethod=simple credentials=XXXXXX sea rchbase="c=fr" tls_reqcert=never type=refreshAndPersist interval=00:00:00:10 retry="5 5 300 +" timeout=1 olcSyncrepl: {2}rid=103 provider=ldaps://ldap-ext2.vlandata.dom.frbinddn="uid =syncrepl,ou=system,ou=dom,o=domgroup,c=fr" bindmethod=simple credentials=XX XXXX tls_reqcert=never searchbase="o=apps-ext,c=fr" type=refreshAndPersist r etry="5 5 300 +" timeout=1 olcSyncrepl: {3}rid=104 provider=ldaps://ldap-ext1.vlandata.dom.frbinddn="uid =syncrepl,ou=system,ou=dom,o=domgroup,c=fr" bindmethod=simple credentials=XXX XXXX searchbase="o=apps-ext,c=fr" tls_reqcert=never type=refreshAndPersist r etry="5 5 300 +" timeout=1 syncrepl host3 and host4: database apps-ext: olcSyncrepl: {0}rid=303 provider=ldaps://ldap-ext1.vlandata.dom.frbinddn="uid =syncrepl,ou=system,ou=dom,o=domgroup,c=fr" bindmethod=simple credentials=XXX XXXX searchbase="o=apps-ext,c=fr" tls_reqcert=never type=refreshAndPersist r etry="5 5 300 +" timeout=1 olcSyncrepl: {1}rid=304 provider=ldaps://ldap-ext2.vlandata.dom.frbinddn="uid =syncrepl,ou=system,ou=dom,o=domgroup,c=fr" bindmethod=simple credentials=XXX XXX searchbase="o=apps-ext,c=fr" tls_reqcert=never type=refreshAndPersist r etry="5 5 300 +" timeout=1 database c=fr: olcSyncrepl: {0}rid=201 provider=ldaps://ldap-int1.dom.frbinddn="uid=syncrepl ,ou=system,ou=dom,o=domgroup,c=fr" bindmethod=simple credentials=XXXXXX sea rchbase="c=fr" tls_reqcert=never type=refreshOnly interval=00:00:00:10 retry= "5 5 300 +" timeout=1 olcSyncrepl: {1}rid=202 provider=ldaps://ldap-int2.dom.frbinddn="uid=syncrepl ,ou=system,ou=dom,o=domgroup,c=fr" bindmethod=simple credentials=XXXXX tls _reqcert=never searchbase="c=fr" type=refreshOnly interval=00:00:00:10 retry= "5 5 300 +" timeout=1 log message into ldap-int1: ep 23 09:00:26 ldap-int1 slapd[30481]: do_syncrep2: rid=104 LDAP_RES_INTERMEDIATE - NEW_COOKIE Sep 23 09:00:26 ldap-int1 slapd[30481]: do_syncrep2: rid=104 NEW_COOKIE: rid=104,sid=003,csn=20130304121522.188962Z#000000#000#000000;20130920094938.821063Z#000000#001#000000;20130923081114.470856Z#000000#002#000000;20130920094950.036431Z#000000#003#000000;20130912174047.679980Z#000000#004#000000;20130304131428.455916Z#000000#00b#000000;20130304125618.164164Z#000000#00c#000000 Sep 23 09:00:26 ldap-int1 slapd[30481]: do_syncrep2: rid=104 LDAP_RES_INTERMEDIATE - NEW_COOKIE Sep 23 09:00:26 ldap-int1 slapd[30481]: do_syncrep2: rid=104 NEW_COOKIE: rid=104,sid=003,csn=20130304121522.188962Z#000000#000#000000;20130920094938.821063Z#000000#001#000000;20130923090023.733719Z#000000#002#000000;20130920094950.036431Z#000000#003#000000;20130912174047.679980Z#000000#004#000000;20130304131428.455916Z#000000#00b#000000;20130304125618.164164Z#000000#00c#000000 Sep 23 09:00:26 ldap-int1 slapd[30481]: slap_queue_csn: queing 0x7f3787471a90 20130923090023.733719Z#000000#002#000000 Sep 23 09:00:26 ldap-int1 slapd[30481]: slap_graduate_commit_csn: removing 0x7f37873baa10 20130923090023.733719Z#000000#002#000000 Sep 23 09:00:27 ldap-int1 slapd[30481]: syncprov_matchops: skipping original sid 002 Sep 23 09:00:27 ldap-int1 slapd[30481]: slap_graduate_commit_csn: removing 0x7f37803e9320 20130923090023.225026Z#000000#002#000000 Sep 23 09:00:27 ldap-int1 slapd[30481]: syncrepl_entry: rid=102 be_add cn=502257-dt-global-gridded-adt-ref,ou=affectations,ou=console,o=apps,c=fr (0) Sep 23 09:00:27 ldap-int1 slapd[30481]: do_syncrep2: rid=102 cookie=rid=102,sid=002,csn=20130923090023.266239Z#000000#002#000000 Sep 23 09:00:27 ldap-int1 slapd[30481]: do_syncrep2: rid=102 CSN too old, ignoring 20130923090023.266239Z#000000#002#000000 (cn=502257-dt-med-gridded-sla-ref,ou=affectations,ou=console,o=apps,c=fr) Sep 23 09:00:27 ldap-int1 slapd[30481]: do_syncrep2: rid=102 cookie=rid=102,sid=002,csn=20130923090023.278474Z#000000#002#000000 Sep 23 09:00:27 ldap-int1 slapd[30481]: do_syncrep2: rid=102 CSN too old, ignoring 20130923090023.278474Z#000000#002#000000 (cn=502257-dt-blacksea-alongtrack-sla-ref,ou=affectations,ou=console,o=apps,c=fr) time sync host1 ntpq> lpeers remote refid st t when poll reach delay offset jitter ============================================================================== *date.dom.fr 145.238.203.10 3 u 676 1024 377 1.592 0.284 0.018 +date2.dom.fr 145.238.203.10 3 u 295 1024 377 2.681 -0.410 0.326 host2 ntpq> lpeers remote refid st t when poll reach delay offset jitter ============================================================================== *date.dom.fr 145.238.203.10 3 u 954 1024 377 1.028 1.012 0.343 +date2.dom.fr 145.238.203.10 3 u 413 1024 377 2.171 0.098 0.606 does somebody see what is wrong . thanks

6 14

Solaris 10 tls:simple binding to OpenLDAP
by Ben Babich 10 Oct '13

10 Oct '13

Folks, I have been fighting along getting some Solaris 10 nodes (both SPARC and x86) to talk via TLS/SSL to our OpenLDAP infrastructure. Without SSL (tls:simple) it binds and functions fine which in my mind rules out most of the usual culprits. As for the certificates, I have verified connectivity with the certificate via openssl s_client -connect <fqdn> -CAfile <cacert> -showcerts but I cannot get the correct version/combination of certutil to setup the appropriate keystore (cert[78].db, key3.db and secmod.db) and make the native SUN ldapsearch or native ldapclient work correctly. Oct 10 10:48:29 solaris1 /usr/lib/nfs/nfsmapid[3668]: [ID 293258 daemon.warning] libsldap: Status: 91 Mesg: createTLSSession: failed to initialize TLS security (security library: bad database.) Oct 10 10:48:29 solaris1 /usr/lib/nfs/nfsmapid[3668]: [ID 292100 daemon.warning] libsldap: could not remove <ldapserver> from servers list Oct 10 10:48:29 solaris1 /usr/lib/nfs/nfsmapid[3668]: [ID 293258 daemon.warning] libsldap: Status: 7 Mesg: Session error no available conn. # certutil -d /var/ldap -L Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI CA certificate CT,, # ldapclient list NS_LDAP_FILE_VERSION= 2.0 NS_LDAP_BINDDN= <masked> NS_LDAP_BINDPASSWD= <masked> NS_LDAP_SERVERS= <masked> NS_LDAP_SEARCH_BASEDN= <masked> NS_LDAP_AUTH= tls:simple NS_LDAP_CACHETTL= 0 NS_LDAP_CREDENTIAL_LEVEL= proxy NS_LDAP_HOST_CERTPATH= /var/ldap # I've tried a few of the older certutil's getting around, including the one from here: along with libraries from openCSW to get it all working http://www.gurulabs.com/downloads/certutil-1.0-sol9-sun4u-local.gz I'm pretty sure its the cert database or something to do with certutill being painful. Any suggestions? Thanks Ben

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical