openldap-bugs

openldap-bugs@openldap.org

1 participants
20965 discussions

(ITS#7019) attribute auditContext should not get replicated
by michael＠stroeder.com 15 Aug '11

15 Aug '11

Full_Name: Version: 2.4.26 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.163.26.156) It seems that attribute auditContext is replicated to consumers if there's an accesslog DB configured at the provider. IMO this does not make sense since the accesslog DB is not replicated and one might not want to load slapo-accesslog module at all in the consumer's config. In a 2-way MMR setup with accesslog DB attached to both master providers the auditContext contains two values for auditContext and even the same one.

1 0

(ITS#7018) unique URI's host part must be empty
by masarati＠aero.polimi.it 13 Aug '11

13 Aug '11

Full_Name: Pierangelo Masarati Version: master,re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (93.144.24.27) Submitted by: ando If empty "host" part is checked, misconfigurations like in <http://www.openldap.org/lists/openldap-technical/201108/msg00116.html> would be easily detected. A fix is coming. p.

1 0

(ITS#7017) DDS overlay: TTL tolerance has inverse effect
by jvcelak＠redhat.com 11 Aug '11

11 Aug '11

Full_Name: Jan Vcelak Version: master OS: Linux URL: ftp://ftp.openldap.org/incoming/jvcelak-110811-dds-overlay-tolerance.patch Submission from: (NULL) (209.132.186.34) Hi! olcDDStolerance setting of DDS overlay has inverse effect and in fact it is shortening the real TTL of dynamic entries. I have uploaded the patch (against git master). Regards, Jan

1 0

(ITS#7016) slapd.ldif bootstrap fails on olcDatabase=frontend
by andrew.findlay＠skills-1st.co.uk 11 Aug '11

11 Aug '11

Full_Name: Andrew Findlay Version: 2.4.26 OS: OpenSuSE 11.4 URL: ftp://ftp.openldap.org/incoming/ajf-20110811-slapd.ldif Submission from: (NULL) (2a01:348:28c:1:222:68ff:fe15:3346) Using a slapd.ldif (attached) closely based on the example from servers/slapd/slapd.ldif I find that the server will not bootstrap: $ slapadd -F ./config -n 0 -l slapd-try.ldif _#################### 100.00% eta none elapsed none fast! Closing DB... $ slapadd -F ./config -l data.ldif -b dc=example,dc=org slapadd: bad configuration directory! The problem appears to be this entry in the LDIF: dn: olcDatabase=frontend,cn=config objectClass: olcDatabaseConfig olcDatabase: frontend olcAccess: to * by * read If 'frontend' is replaced with '{-1}frontend' in both places then the server works. At the least this needs changing in the example file slapd.ldif, in the manpage slapd-config(5), and in the admin guide. Some explanation as to why it is necessary would be welcome too! (I suspect it is because the cn=config DB has already been instantiated as DB zero, yet the frontend has to come ahead of all other DBs in some list). The error message is not very helpful, and winding up the debugging level just sent me up blind alleys so could the server please say a bit more about just what is bad about the config directory?

1 0

Re: (ITS#7015) slapd.ldif example file not installed
by masarati＠aero.polimi.it 11 Aug '11

11 Aug '11

> Full_Name: Andrew Findlay > Version: 2.4.26 > OS: OpenSuSE 11.4 > URL: > Submission from: (NULL) (2a01:348:28c:1:222:68ff:fe15:3346) > > > slapdconf2.sdf says: > The distribution contains an example configuration file that will > be installed in the {{F: /usr/local/etc/openldap}} directory. > > There is an example file in the source: servers/slapd/slapd.ldif > but it is not installed anywhere. The corresponding slapd.conf example > does get installed, so this one should probably go alongside it. Fixed in master, please test. p.

1 0

(ITS#7015) slapd.ldif example file not installed
by andrew.findlay＠skills-1st.co.uk 11 Aug '11

11 Aug '11

Full_Name: Andrew Findlay Version: 2.4.26 OS: OpenSuSE 11.4 URL: Submission from: (NULL) (2a01:348:28c:1:222:68ff:fe15:3346) slapdconf2.sdf says: The distribution contains an example configuration file that will be installed in the {{F: /usr/local/etc/openldap}} directory. There is an example file in the source: servers/slapd/slapd.ldif but it is not installed anywhere. The corresponding slapd.conf example does get installed, so this one should probably go alongside it.

1 0

Re: (ITS#7008) paged results against ldap-proxy errors with 'cookie is invalid'
by masarati＠aero.polimi.it 11 Aug '11

11 Aug '11

> Sounds like this may be related to ITS#6817. Please try adding a dummy > binddn > to your idassert-bind directive and re-test. First of all, I believe the real problem is that pr should not be used by the client in the first place. However, the cause of the issue might be something slightly different: back-ldap uses a pool of connections for special identities, including anonymous and rootdn; the latter is the case when identity assertion is used. So it seems plausible that although the client uses the same connection for repeated paged results requests, the proxy is using different ones. We already discussed the possibility to specially handle pr in proxies, in order to decouple its use by the client and the remote server. If slapd handles pr in the frontend, a proxy does not need to propagate pr requests to the remote server. Similarly, if a remote server *needs* pr, the client must not necessarily know about it. Something like this has already been implemented in back-meta(5), which can be instructed to silently continue unsolicited pr responses without informing the client about them (I should have ported this to back-ldap(5) as well). If this is the case (need to investigate in detail, yet), a quick fix could be to detect the presence of pr on a request, and bind the cookie to a specific connection until that cookie is gone. One thing that could be tried is to use slapo-sssvlv(5) on top of back-ldap and let it deal with the pr request. p.

1 0

Re: (ITS#7009) TIMEOUT with unexpected results
by masarati＠aero.polimi.it 10 Aug '11

10 Aug '11

> libldap's ldap_result() sets ld_errno to LDAP_TIMEOUT but returns 0, so > ldapsearch (and all tools) are fooled by not actually checking ld_errno > (actually, ldap_get_option(LDAP_OPT_RESULT_CODE)). Fixed in master. Also fixed timelimit (apparently, it was not honored). p.

1 0

Re: (ITS#7009) TIMEOUT with unexpected results
by masarati＠aero.polimi.it 10 Aug '11

10 Aug '11

> Full_Name: Bjoern Jacke > Version: 2.4.23 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (193.159.216.39) > > > When TIMEOUT is set and happend to occur there is nothing that shows that > we > timed out. For example if you do a large/slow LDAP search using ldapsearch > and > then stop the conversation between slapd and ldapsearch by "killall -STOP > slapd" > then ldapsearch will terminate after TIMEOUT seconds and it will return > the > number of records that it got so far and exit with return code 0 and not > error > message. I'd expect that after TIMEOUT occuring that we get a warning and > a > return code != 0 libldap's ldap_result() sets ld_errno to LDAP_TIMEOUT but returns 0, so ldapsearch (and all tools) are fooled by not actually checking ld_errno (actually, ldap_get_option(LDAP_OPT_RESULT_CODE)). p.

1 0

Re: (ITS#7007) sync: inconsistent directory when starting with emtpy node
by steffo76＠gmx.de 10 Aug '11

10 Aug '11

I'm sorry, in the meantime I found out that the binddn I used didn't have full access so the empty node couldn't get all attributes and then the broken directory got replicated back to the initial node. It was just a configuration problem on my part. Sorry again.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs