openldap-bugs

openldap-bugs@openldap.org

1 participants
21003 discussions

(ITS#7683) Feature request: write TLS prot/cipher to syslog
by michael＠stroeder.com 06 Sep '13

06 Sep '13

Full_Name: Version: HEAD OS: URL: Submission from: (NULL) (79.219.124.115) For debugging which TLS protocol version and cipher suites were actually negotiated with several LDAP clients this information would be written to the syslog message. Current logging: conn=1000 fd=12 TLS established tls_ssf=256 ssf=256 Suggestion: conn=1000 fd=12 TLS established tls_ssf=256 ssf=256 tls_proto=TLSv1.1 tls_cipher=DHE-RSA-AES256-SHA256

1 0

Re: (ITS#7381) Dynamically added chaining configuration stops working after restart
by hyc＠symas.com 06 Sep '13

06 Sep '13

ian(a)uns.ac.rs wrote: > Full_Name: Ivan Nejgebauer > Version: 2.4.32 > OS: CentOS 5 > URL: ftp://ftp.openldap.org/incoming/ivannejgebauer-120905.tgz > Submission from: (NULL) (2001:4170:2000:2:213:d3ff:fecf:b9ea) > > > If a minimal chaining configuration is dynamically added to a consumer server in > a provider/consumer pair running delta-syncrepl, it will stop working when the > consumer is restarted. The configuration is modelled after the one used in > test022 in the OpenLDAP source distribution: Sorry this report was neglected for so long, and thanks for the excellent test case. This is now fixed in git master. > > dn: olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config > objectClass: olcOverlayConfig > objectClass: olcChainConfig > olcOverlay: {0}chain > > dn: olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config > objectClass: olcLDAPConfig > objectClass: olcChainDatabase > olcDatabase: {0}ldap > olcDbIDAssertBind: bindmethod=simple binddn="cn=Manager,dc=example,dc=com" > credentials="secret" mode=self > olcDbURI: "ldap://localhost:6389" > > Scripts and data for replicating the issue are in the referenced archive. Quick > summary: > > # make clean-all master replica > # ./start-master.sh > # ./start-replica.sh > # ./replica-apply.sh pmod-add.ldif # returns referral > # ./replica-conf.sh chain.ldif # adds chaining configuration > # ./replica-apply.sh pmod-add.ldif # chains to master > # ./stop-replica.sh > # ./start-replica.sh > # ./replica-apply.sh pmod-del.ldif # returns referral, but shouldn't > > I have tested both 2.4.32 and git master > (54a111907b48900e1ce5de12a9d87818a334423d). > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#7682) LMDB: [PATCH] mdb_env_copy should retry open() if O_DIRECT fails
by hyc＠symas.com 05 Sep '13

05 Sep '13

sog(a)msg.com.mx wrote: > Full_Name: Salvador Ortiz > Version: 24 > OS: Linux > URL: ftp://ftp.msg.com.mx/pub/varios/0001-In-mdb_env_copy-retry-open-if-O_DIRECT-fails.patch > Submission from: (NULL) (187.162.45.111) > > > If the OS defines O_DIRECT mdb_env_copy unconditionally uses it, but according > to open(2): "Some file systems may not implement the flag and open() will > fail with EINVAL if it is used." > > In this cases mdb_env_copy should retry without the flag. > > The attached patch implements that. > > Thanks, applied. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#7682) LMDB: [PATCH] mdb_env_copy should retry open() if O_DIRECT fails
by sog＠msg.com.mx 05 Sep '13

05 Sep '13

Full_Name: Salvador Ortiz Version: 24 OS: Linux URL: ftp://ftp.msg.com.mx/pub/varios/0001-In-mdb_env_copy-retry-open-if-O_DIRECT-fails.patch Submission from: (NULL) (187.162.45.111) If the OS defines O_DIRECT mdb_env_copy unconditionally uses it, but according to open(2): "Some file systems may not implement the flag and open() will fail with EINVAL if it is used." In this cases mdb_env_copy should retry without the flag. The attached patch implements that.

1 0

Re: (ITS#7681) Bugfix for MDB_SET_RANGE
by hyc＠symas.com 05 Sep '13

05 Sep '13

claude.brisson(a)gmail.com wrote: > Full_Name: Claude Brisson > Version: HEAD > OS: linux 64 > URL: ftp://ftp.openldap.org/incoming/0001-fix-mdb_cursor_set-behaviour-for-MDB_S… > Submission from: (NULL) (84.103.74.195) > > > When no other page was found while provided key is less than found key, > mdb_cursor_get should not return MDB_NOTFOUND. > > The attached patch is a proposal to fix the behaviour of mdb_cursor_set for > MDB_SET_RANGE. Please review that it is correct before integration. Thanks. exactp is always NULL when using SET_RANGE, so that part of the patch is unnecessary. Otherwise looks OK. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#7681) Bugfix for MDB_SET_RANGE
by claude.brisson＠gmail.com 05 Sep '13

05 Sep '13

Full_Name: Claude Brisson Version: HEAD OS: linux 64 URL: ftp://ftp.openldap.org/incoming/0001-fix-mdb_cursor_set-behaviour-for-MDB_S… Submission from: (NULL) (84.103.74.195) When no other page was found while provided key is less than found key, mdb_cursor_get should not return MDB_NOTFOUND. The attached patch is a proposal to fix the behaviour of mdb_cursor_set for MDB_SET_RANGE. Please review that it is correct before integration.

1 0

RE: (ITS#7673)
by Russell.Mosemann＠cune.edu 04 Sep '13

04 Sep '13

Pierangelo Masarati wrote: > Try rwm-drop-unrequested-attrs no (slapo-rwm(5)). That had my hopes up. I didn't think any of those settings applied, because nothing about the query or the results is being rewritten or mapped. In effect, rwm should not be doing anything at all. Everything should pass through the overlay. I set rwm-drop-unrequested-attrs to no, and it made things worse. If I include the filter attributes in the query, nothing is returned, now. If no attributes are specified, all of the allowed attributes are returned, as before. -- Russell Mosemann, Ph.D. Professor of Computer Science

1 0

Re: (ITS#7673)
by pierangelo.masarati＠polimi.it 04 Sep '13

04 Sep '13

On 09/04/2013 10:22 PM, Russell.Mosemann(a)cune.edu wrote: > --_000_B01302EA11DF7D40B2AD9CBEC71B02562C4A3ED5exchange2cunepr_ > Content-Type: text/plain; charset="us-ascii" > Content-Transfer-Encoding: quoted-printable > > The lookup succeeds, and the returned entry is run through the searchEntryD= > N context. It appears that somewhere in or around there all of the attribut= > es are removed except for the requested attributes. That means the ACL filt= > er will fail, if the filter attributes are not requested in the query. If t= > he requested attributes include the filter attributes, the query succeeds, = > but the result only returns the dn without any other attributes. > > If no attributes are requested, all allowed attributes are returned. > > The man page indicates that searchEntryDN should not be applied, because it= > is not defined, and there is no default. Try rwm-drop-unrequested-attrs no (slapo-rwm(5)). p. > > > --_000_B01302EA11DF7D40B2AD9CBEC71B02562C4A3ED5exchange2cunepr_ > Content-Type: text/html; charset="us-ascii" > Content-Transfer-Encoding: quoted-printable > > <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= > osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = > xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= > //www.w3.org/TR/REC-html40"> > <head> > <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= >> > <meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"> > <style></style> > </head> > <body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> > <div class=3D"WordSection1"> > mes New Roman","serif"">The lookup succeeds, and the returne= > d entry is run through the searchEntryDN context. It appears that somewhere= > in or around there all of the attributes are removed except > for the requested attributes. That means the ACL filter will fail, if the = > filter attributes are not requested in the query. If the requested attribut= > es include the filter attributes, the query succeeds, but the result only r= > eturns the dn without any other > attributes.<o:p></o:p> > mes New Roman","serif""><o:p> </o:p> > mes New Roman","serif"">If no attributes are requested, all = > allowed attributes are returned.<o:p></o:p> > mes New Roman","serif""><o:p> </o:p> > mes New Roman","serif"">The man page indicates that searchEn= > tryDN should not be applied, because it is not defined, and there is no def= > ault.<o:p></o:p> > mes New Roman","serif""><o:p> </o:p> > </div> > </body> > </html> > > --_000_B01302EA11DF7D40B2AD9CBEC71B02562C4A3ED5exchange2cunepr_-- > > > > > -- Pierangelo Masarati Associate Professor Dipartimento di Scienze e Tecnologie Aerospaziali Politecnico di Milano

1 0

(ITS#7673)
by Russell.Mosemann＠cune.edu 04 Sep '13

04 Sep '13

--_000_B01302EA11DF7D40B2AD9CBEC71B02562C4A3ED5exchange2cunepr_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The lookup succeeds, and the returned entry is run through the searchEntryD= N context. It appears that somewhere in or around there all of the attribut= es are removed except for the requested attributes. That means the ACL filt= er will fail, if the filter attributes are not requested in the query. If t= he requested attributes include the filter attributes, the query succeeds, = but the result only returns the dn without any other attributes. If no attributes are requested, all allowed attributes are returned. The man page indicates that searchEntryDN should not be applied, because it= is not defined, and there is no default. --_000_B01302EA11DF7D40B2AD9CBEC71B02562C4A3ED5exchange2cunepr_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"> <style></style> </head> <body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> The lookup succeeds, and the returne= d entry is run through the searchEntryDN context. It appears that somewhere= in or around there all of the attributes are removed except for the requested attributes. That means the ACL filter will fail, if the = filter attributes are not requested in the query. If the requested attribut= es include the filter attributes, the query succeeds, but the result only r= eturns the dn without any other attributes.<o:p></o:p> <o:p> </o:p> If no attributes are requested, all = allowed attributes are returned.<o:p></o:p> <o:p> </o:p> The man page indicates that searchEn= tryDN should not be applied, because it is not defined, and there is no def= ault.<o:p></o:p> <o:p> </o:p> </div> </body> </html> --_000_B01302EA11DF7D40B2AD9CBEC71B02562C4A3ED5exchange2cunepr_--

1 0

Re: (ITS#7680) [Patch] Fix typos in manpages
by hyc＠symas.com 03 Sep '13

03 Sep '13

jsynacek(a)redhat.com wrote: > Full_Name: Jan Synacek > Version: master > OS: Linux - Fedora 19 > URL: http://jsynacek.fedorapeople.org/openldap/jsynacek-20130903-0001-Fix-typos-… > Submission from: (NULL) (209.132.186.34) > > > Minor documentation typos in ldapsearch.1 and slapd-passwd.5. > > Thanks, applied to master -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

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