openldap-bugs October 2009

openldap-bugs@openldap.org

34 participants
223 discussions

(ITS#6332) replication issues
by lmierzwa＠gmail.com 14 Oct '09

14 Oct '09

Full_Name: £ukasz Mierzwa Version: 2.4.18/19 OS: Linux / Freebsd URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (85.232.239.146) I'm using syncrepl with this config on master overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 and on slaves syncrepl rid=100 provider=ldap://ldap-master type=refreshOnly interval=00:00:01:00 retry="60 +" searchbase="<base>" filter="(objectClass=*)" scope=sub schemachecking=off bindmethod=sasl saslmech=DIGEST-MD5 authcid="<replicator login>" credentials="<pass>" starttls=yes I modify data on master using ldapmodify with this ldif: dn: cn=shell,ou=access,<basedn> changetype: modify replace: objectClass objectClass: groupOfNames objectClass: top - replace: cn cn: shell - replace: description description: blablabla note that only description is getting new value, cn and objectClass are being set to the same value as before modification and everything works, slaves are getting changed data, but when I add member attribute (which also is set to the same value as it was) slaves are not seeing any change, logs on slaves are only showing "do_syncrep2: rid=100 LDAP_RES_SEARCH_RESULT" Master is ubuntu 9.04 with openldap 2.4.15 + I tested 2.4.18 from 9.10, same result. Slaves are ubuntu 9.04 (2.4.15 and 2.4.18) and Freebsd 7.0 (2.4.19)

1 0

Re: (ITS#6251) GnuTLS cipher suite failure
by kent＠cpttm.org.mo 13 Oct '09

13 Oct '09

Hi, I am having this issue, but setting the cipher suite to +RSA:+AES-256-CBC:+SHA1 doesn't fix the problem. slapd.conf: TLSCipherSuite +RSA:+AES-256-CBC:+SHA1 TLSCACertificateFile /etc/ldap/ssl/cacert.pem TLSCertificateFile /etc/ldap/ssl/cert.pem TLSCertificateKeyFile /etc/ldap/ssl/key.pem Debug log of slapd: tchingRuleUse: ... supportedFeatures $ supportedApplicationContext ) ) TLS: could not set cipher list +RSA:+AES-256-CBC:+SHA1. main: TLS init def ctx failed: -1 slapd destroy: freeing system resources. slapd stopped. Output of "gnutls-cli -l": ... TLS_RSA_EXPORT_ARCFOUR_40_MD5 0x00, 0x03 SSL 3.0 TLS_RSA_ARCFOUR_SHA1 0x00, 0x05 SSL 3.0 TLS_RSA_ARCFOUR_MD5 0x00, 0x04 SSL 3.0 TLS_RSA_3DES_EDE_CBC_SHA1 0x00, 0x0a SSL 3.0 TLS_RSA_AES_128_CBC_SHA1 0x00, 0x2f SSL 3.0 TLS_RSA_AES_256_CBC_SHA1 0x00, 0x35 SSL 3.0 Certificate types: X.509, OPENPGP Protocols: SSL 3.0, TLS 1.0, TLS 1.1, TLS 1.2 Ciphers: AES 256 CBC, AES 128 CBC, 3DES 168 CBC, DES CBC, ARCFOUR 128, ARCFOUR 4 0, RC2 40, NULL MACs: SHA, MD5, SHA256, SHA384, SHA512, MD2, RIPEMD160, NULL Key exchange algorithms: Anon DH, RSA, RSA EXPORT, DHE RSA, DHE DSS, SRP DSS, SR P RSA, SRP, PSK, DHE PSK Compression: LZO, DEFLATE, NULL -- Kent Tong SME accounting software package for just MOP30. See http://www.cpttm.org.mo/index_c.php?pg=cpttm/department/is/ispu/accsys/inde… for more.

1 0

(ITS#6331) slapd freezing, not accepting further 'write' operations while 'read' operations are unaffected
by j＠telepaths.org 13 Oct '09

13 Oct '09

Full_Name: Jeff Doyle Version: 2.4.17 OS: Debian/Lenny URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (130.94.106.251) Greetings, Occasionally, I will find one of my servers (running Debian/Lenny with back-ported slapd version 2.4.17) in a state where the following occurs: * Write operations will 'freeze' - leaving the requester at a frozen prompt or frozen LDAP-client of some kind (from wherever the write-operation originated). * slapd refuses to 'stop', even though it indicates that its waiting for "0" processes to complete. * Logs do not indicate a segfault nor any poorly terminated processes. * Read operations on same server continue to function normally. Any data that existed before the "freeze" is returned as it should be. Modules used: * accesslog * back_hdb * back_monitor * back_relay * back_rwm * syncprov Servers are all fairly new, and reasonably beefy for their purposes: * 6GB RAM * 2+ GHz CPU, all QuadCore Xeon and all running amd64 kernel (current with Lenny) * Plenty of Disk Space (gigs and gigs) * Servers are SLEEPING (0.00 avg load) slapd is making use of 'tool-threads' with a value of '4' - however changing this value has had no effect - Just a side note. Inform me of any further configs and/or information that you need, and I will provide it promptly. Thanks, Jeff

1 0

(ITS#6330) slapd memory leak
by whm＠stanford.edu 13 Oct '09

13 Oct '09

Full_Name: Bill MacAllister Version: 2.4.18 OS: Debian 5.0 URL: http://www.stanford.edu/~whm/files/slapd/readme.html Submission from: (NULL) (75.26.167.150) We have observed what we believe to be a memory leak in OpenLDAP 2.4.18 in testing while dynlist support. We have a script that randomly expands the member lists of groups defined using dynlist. Running this script for a period of about 24 hours forces the slapd process to swap. It is not clear at all that dynlist is the problem because we were not able to see the problem with our test script until we surrounded each query with a bind/unbind. (At least we didn't wait long enough to see it.) All queries perform GSSAPI binds to the directory. The problem is unaffected by using either the MIT or Heimdal GSSAPI libraries. Our build of OpenLDAP 2.4.18 follows the debian configuration with the exceptions: * Patch for ITS6287 * Patch for ITS6308 * Patch to the index slots * disable support for tcp_wrappers and disable rlookups The details of software versions, build options, slapd configuration, scripts, db_stat output and testing procedures are at http://www.stanford.edu/~whm/files/slapd/readme.html.

1 0

(ITS#6329) memberof overlay doesn't update entryCSN
by msmith＠cbnco.com 13 Oct '09

13 Oct '09

Full_Name: Michael Smith Version: 2.4.18-55.1 OS: SLES11 (SUSE) URL: Submission from: (NULL) (207.164.182.8) Hi, It looks like the memberof overlay doesn't update a user object's entryCSN when a group object is changed. I believe this causes trouble with syncrepl, at least in a multi-master configuration: if one node is down when the group object is changed, it won't know it needs to update the user object when it comes back. I'm a little confused because while the entryCSNs don't change on the server where the group is updated, they do change on the other servers in the replication group. For example, if I add a user to a group on node 2, the user's entryCSN on node 2 might be "20091008032402.932100Z#000000#002#000000": old timestamp, correct server ID. On node 1 the entryCSN might be "20091008032142.915412Z#000000#002#000000": current timestamp, correct server ID. I'm using syncrepl with refreshAndPersist and syncprov. The memberof overlay is using its default configuration. In the stacking order, memberof comes before syncprov, but it behaved the same way in both orders. All nodes are configured with memberof and syncprov. The servers' clocks are in sync (NTP). There was a thread on openldap-software here: http://thread.gmane.org/gmane.network.openldap.general/45790/focus=45808 This is what my configuration looks like on node 1: 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}memberof,olcDatabase={1}hdb,cn=config objectClass: olcOverlayConfig olcOverlay: {1}memberof dn: olcOverlay={1}syncprov,olcDatabase={1}hdb,cn=config objectClass: olcSyncProvConfig olcSpCheckpoint: 100 10 olcSpSessionlog: 1000 olcOverlay: {0}syncprov Node 2 looks the same, but with olcServerID: 2 and provider=ldap://ldap1.dom. Thanks, Mike

1 0

Re: (ITS#6320)
by j＠telepaths.org 12 Oct '09

12 Oct '09

Just to clear up any confusion: * Issue is not resolved * Waiting for a response from you guys Please advise. Jeff

1 0

Re: (ITS#6328) Configure OpenLDAP with BO
by quanah＠zimbra.com 12 Oct '09

12 Oct '09

--On Monday, October 12, 2009 9:04 AM +0000 hervelam(a)hotmail.com wrote: > Full_Name: HervE > Version: 2.2.29 Usage questions need to go to openldap-software(a)openldap.org or openldap-technical(a)openldap.org. I would note you are using an ancient unsupported release as well. I'd advise moving to something newer. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6328) Configure OpenLDAP with BO
by hervelam＠hotmail.com 12 Oct '09

12 Oct '09

Full_Name: HervE Version: 2.2.29 OS: Windows XP URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.41.232.181) I am trying to configure BusinessObjects in order to use OpenLDAP with it. In the LDAP authentification menu in BO, I have to map all the following attributes with the appropriate tags: Mappings of LDAP server attributes Object class: Static Group: Member of static group: Dynamic Group: Dynamic Group Filter: Group description: User object Class: Username: Full name of the user: Email User: User Description: Default LDAP search attributes Default group research attribute: Default user research attribute: Can anyone help me please? Regards, HervE

1 0

Re: (ITS#6320)
by j＠telepaths.org 11 Oct '09

11 Oct '09

OpenLDAP ITS: OK the issue is looking more and more like buggy slapd behavior. I have now narrowed down the issue to an instance where slapd is partially "hung" and will not stop nor restart. This directly correlates to replication breaking because SLAPD is breaking: Oct 11 18:22:08 server1 slapd[10771]: <= bdb_equality_candidates: (uidNumber) not indexed Oct 11 18:22:08 server1 slapd[10771]: <= bdb_equality_candidates: (gidNumber) not indexed Oct 11 18:22:08 server1 slapd[10771]: <= bdb_equality_candidates: (uidNumber) not indexed Oct 11 18:46:41 server1 slapd[10771]: <= bdb_equality_candidates: (uidNumber) not indexed Oct 11 18:48:37 server1 slapd[10771]: <= bdb_equality_candidates: (uidNumber) not indexed Oct 11 18:49:05 server1 slapd[10771]: daemon: shutdown requested and initiated. Oct 11 18:49:05 server1 slapd[10771]: slapd shutdown: waiting for 0 operations/tasks to finish As you can see, the exact time when this occurs doesn't bring anything interesting to the logs. You can see the repeated string of index warnings (not an issue, just haven't indexed this attribute yet) followed by my attempt to restart slapd when I receive a notification indicating there is a replication discrepancy. I have grepped through all of my logs (dmesg, debug, syslog) for anything related to slapd. What you see above is the more interesting of the hits returned. PLEASE help -- the issue is getting more serious now, and by the evidence I've presented, is looking more and more out of my control. You've seen my config - can anyone think of why this would happen? It seems vaguely like a locking issue .... Thanks Jeff

1 0

Re: (ITS#6320)
by j＠telepaths.org 11 Oct '09

11 Oct '09

> FYI .... > > Before going to sleep last night, I left a persistent connection > open to an LDAP server: > > > SyncInfo Received > > SyncInfo Received > > SyncInfo Received > > SyncInfo Received > ldap_result: Can't contact LDAP server (-1) <-- > sometime during the night, the connection breaks. > This turned out to be the Kerberos credentials acquired for this test command had expired. Last night, I ran the same command via Simple Bind before going to sleep. The connection is still alive several hours later. This disproves the theory of firewall-induced timeouts for replication that is achieved outside the current local zone. Jeff

1 0

← Newer
1
...
13
14
15
16
17
18
19
...
23
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs October 2009