openldap-bugs

openldap-bugs@openldap.org

21001 discussions

Re: (ITS#5551) assertion causes application failure
by ghenry＠OpenLDAP.org 12 Jun '08

12 Jun '08

> Is there debug output you would like from me? See http://www.openldap.org/faq/data/cache/59.html -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

Re: (ITS#5540) Normalization assertion in attr.c
by h.b.furuseth＠usit.uio.no 12 Jun '08

12 Jun '08

hyc(a)symas.com writes: >>> monitorContext, readOnly and the olc* attributes are defined by OpenLDAP >>> (their OIDs start with 1.3.6.1.4.1.4203) and can be modified if we feel >>> like it. Personally I prefer attrs to have the matching rules they can >>> have unless there is a reason not to, but I didn't write these modules >>> so I don't know if there _is_ a reason not to. > > For the config attributes, I just assumed no one needs to search on > them (so no filter capability needed) and for single-valued > attributes, there's no need to consider modifies... Oh, good. No reason not to add matching rules then:-) I search for one config attrs or another once in a while. Mostly for olcSuffix and with presence filters, but it'd be nice if e.g. (olcAccess:caseIgnoreSubstringsMatch:=*userPassword*) worked. Also some day I'll want to use assertion controls as a check on modify operations someday. Still, I'm not proposing to add more work than necessary to this ITS. Get it right first, then think of "nice to have"-features if/when anyone bothers. -- Hallvard

1 0

Re: (ITS#5553) Inconsistent sasl.c logging format
by h.b.furuseth＠usit.uio.no 12 Jun '08

12 Jun '08

hyc(a)symas.com writes: >> Would it be reasonable to change the 6 debug statements in sasl.c to >> use the first format? > > I don't see any reason not to. I do: Currently that format is more or less reserved for loglevel stats/stats2, and is useful when grepping a more chatty log for stats. Though it could certainly be useful to normalize log formats a little. -- Hallvard

1 0

Re: (ITS#5540) Normalization assertion in attr.c
by hyc＠symas.com 12 Jun '08

12 Jun '08

unix.gurus(a)gmail.com wrote: >>> namingContexts >>> configContext >>> dynamicSubtrees >>> >>> These attributes do not have equality matching rules, but probably >>> should. I add 'EQUALITY distinguishedNameMatch' to them in >>> schema_prep.c. >> No, that breaks the definitions in the RFCs they come from. (See their >> DESC strings.) I don't know why they lack EQUALITY rules, maybe we just >> forgot when we defined them, but that's the way it is. Same with >> supportedControl. configContext is OpenLDAP-specific. It is also single-valued, so it seemed to me it did not need an EQ rule. > Ok, so we should not define nvals for them? No normalizer, therefore, cannot provide nval... >> monitorContext, readOnly and the olc* attributes are defined by OpenLDAP >> (their OIDs start with 1.3.6.1.4.1.4203) and can be modified if we feel >> like it. Personally I prefer attrs to have the matching rules they can >> have unless there is a reason not to, but I didn't write these modules >> so I don't know if there _is_ a reason not to. For the config attributes, I just assumed no one needs to search on them (so no filter capability needed) and for single-valued attributes, there's no need to consider modifies... -- -- 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#5553) Inconsistent sasl.c logging format
by hyc＠symas.com 12 Jun '08

12 Jun '08

unix.gurus(a)gmail.com wrote: > Full_Name: Sean Burford > Version: 2.4.8 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (72.14.227.1) > > > Most connection logs are of the format: > conn=\d+ fd=\d+ MSG > > sasl.c Debug logs are of the format: > SASL .*[conn=\d+]: MSG > > Would it be reasonable to change the 6 debug statements in sasl.c to use the > first format? I don't see any reason not to. > > This is not an important issue, just a small inconsistency. -- -- 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#5553) Inconsistent sasl.c logging format
by unix.gurus＠gmail.com 12 Jun '08

12 Jun '08

Full_Name: Sean Burford Version: 2.4.8 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (72.14.227.1) Most connection logs are of the format: conn=\d+ fd=\d+ MSG sasl.c Debug logs are of the format: SASL .*[conn=\d+]: MSG Would it be reasonable to change the 6 debug statements in sasl.c to use the first format? This is not an important issue, just a small inconsistency.

1 0

(ITS#5552) Ppolicy overlay doesn't accept unquoted DN for "olcPpolicyDefault"
by ralf＠OpenLDAP.org 12 Jun '08

12 Jun '08

Full_Name: Ralf Haferkamp Version: HEAD, RE24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.189.171) Submitted by: ralf Adding an unquoted DN (containing white spaces) to olcPpolicyDefault results in the following error: ldap_modify: Constraint violation (19) additional info: <olcPPolicyDefault> extra cruft after <policyDN> Fix is on the way to CVS.

1 0

Re: (ITS#5550) Unable to do scp from and to server ldap
by hyc＠symas.com 12 Jun '08

12 Jun '08

karim.bourenane(a)orange-ftgroup.com wrote: > Full_Name: Bourenane > Version: Openldap-server-2.3.41 / and clien > OS: FreeBSD 7 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (57.250.229.136) > > > Hi All > > My server running fine, with ldap and ldaps. > Is i do a command SCP from any server to user i have : > > server# scp kbourena@ldap-rain:/home/kbourena/toto.txt . > Password: > unknown user 1206 > server# > > On ldap-rain scp is not OpenLDAP software. Since you already said your server is running fine, this is clearly not an OpenLDAP software issue, and therefore does not belong in the OpenLDAP ITS. This ITS will be closed. -- -- 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#5462) Allow setting of RANDOM_FILE for gnutls
by pogma＠thewrittenword.com 12 Jun '08

12 Jun '08

On Tue, Jun 10, 2008 at 12:50:22PM -0700, Howard Chu wrote: > pogma(a)thewrittenword.com wrote: >> Full_Name: Peter O'Gorman >> Version: 2.4.8 >> OS: multiple >> URL: ftp://ftp.openldap.org/incoming/the-written-word-080410.patch >> Submission from: (NULL) (24.76.165.223) >> >> >> gcrypt-1.4.x and later allow the egd socket path to be set. This patch allows >> the conf file option to work when building openldap with gnutls on systems that >> do not have a /dev/random. > > Hm, this patch is a silent no-op if the gcrypt function is missing. > Currently the randfile option is already documented as being ignored by > GNUtls. I would prefer that the behavior is absolutely consistent - either > the feature always works or is always ignored. Perhaps we should require > gcrypt 1.4 or newer? Requiring gcrypt-1.4.x or newer is ok with us. Peter -- Peter O'Gorman pogma(a)thewrittenword.com

1 0

Re: (ITS#5551) assertion causes application failure
by aej＠WPI.EDU 12 Jun '08

12 Jun '08

I ran the thing again to get a trace back, and went to attach the code and found a free() which was at the wrong location. I think I caused the problem. I still don't know what's happening with ldap on the mail server, but my application bug was not related after all.

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