openldap-bugs April 2009

openldap-bugs@openldap.org

49 participants
141 discussions

Re: (ITS#5382) JLDAP
by rarpit＠novell.com 24 Apr '09

24 Apr '09

--=__PartF5DD40B7.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable hi Jim, We have fixed the issue . We will be checking the same . Thanks for = identifying the issue . =20 regards Arpit=20 =20 --=__PartF5DD40B7.0__= Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Description: HTML <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-15= "> <META content=3D"MSHTML 6.00.2900.3492" name=3DGENERATOR></HEAD> <BODY style=3D"MARGIN: 4px 4px 1px; FONT: 10pt Segoe UI"> <DIV>hi Jim,</DIV> <DIV>    We have fixed the issue . We will be checking the = same . Thanks for identifying the issue .</DIV> <DIV> </DIV> <DIV>regards</DIV> <DIV>Arpit </DIV> <DIV> </DIV></BODY></HTML> --=__PartF5DD40B7.0__=--

1 0

Re: (ITS#5389) Contribution: JLDAP support for password policy response control
by rarpit＠novell.com 24 Apr '09

24 Apr '09

--=__Part133BA653.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable hi Raymond , =20 This is just for my understanding . Is Password Policy response is a = standard ? What is the requirement of this particular feature to be = present in JLDAP? What is this feature and how it can be used ?=20 We can take it in if this is a standard but if this is not a standard = than we cannot take this in as this will make the code bulkier.=20 =20 regards, Arpit=20 --=__Part133BA653.0__= Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Description: HTML <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-15= "> <META content=3D"MSHTML 6.00.2900.3492" name=3DGENERATOR></HEAD> <BODY style=3D"MARGIN: 4px 4px 1px; FONT: 10pt Segoe UI"> <DIV>hi Raymond ,</DIV> <DIV> </DIV> <DIV>   This is just for my understanding . Is Password Policy = response is a standard ? What is the requirement of this particular = feature to be present in JLDAP? What is this feature and how it can be = used ? </DIV> <DIV>   We can take it in if this is a standard but if this is = not a standard than we cannot take this in as this will make the code = bulkier. </DIV> <DIV> </DIV> <DIV>regards,<BR>Arpit </DIV></BODY></HTML> --=__Part133BA653.0__=--

1 0

Re: (ITS#6071) LDAP server becomes unresponsive
by carsten.rieck＠trustcenter.de 24 Apr '09

24 Apr '09

Hello, the update to OpenLDAP 2.4.16 has solved my problem with the unresponsive server. Quanah, thank you very much for your help. From my point of view, the ITS can be closed. Best regards, Carsten -- Dr. Carsten T. Rieck Development TC TrustCenter GmbH Sonninstrasse 24-28, 20097 Hamburg, Germany Tel.: +49-(0)40-808026-0, Fax: -126 Geschaeftsfuehrung/Managing Directors: Robert Steinkrauss , Dr. Sabine Kockskaemper , HRB 96168 Email: carsten.rieck(a)trustcenter.de www.trustcenter.de This email may contain confidential and privileged material for the sole use of the intended recipient. Any review or distribution by others is strictly prohibited. If you are not the intended recipient please contact the sender and delete all copies.

1 0

Re: (ITS#6072) slapo-collect: dnLength != dnDepth
by daniel＠pluta.biz 23 Apr '09

23 Apr '09

Michael Ströder schrieb: > daniel(a)pluta.biz wrote: >> I could not find a suitable api-call to determine a DN's depth. > > How about using ldap_bv2dn() and count the DN components? > >> So I've used >> posix regexp and uploaded that quick&dirty hacked patch right here: > > I guess reg ex splitting won't work for arbitrary DN strings. > > Ciao, Michael. I finaly managed to upload the patch under "incoming/collect.c.patch" Instead of using posix regexp I've used the ldap_bv2dn() based methode recommended by you. I would appreciate your revise. This patch does not include slapo-collect's schema-patch that I've filed some minutes ago (see: ITS#6075) Thanks!

1 0

(ITS#6075) slapo-collect: olcCollectInfo: no equality matching rule
by daniel＠pluta.biz 23 Apr '09

23 Apr '09

Full_Name: Daniel Pluta Version: 2.4.16 OS: Linux URL: ftp://ftp.openldap.org/incoming/daniel-pluta-090423.patch Submission from: (NULL) (91.12.202.8) It's impossible to delete one value from the multi-valued olcCollectInfo in case there are more than 1 olcCollectInfo values configured... Error: "olcCollectInfo: no equality matching rule" I've uploaded a small patch here: ftp://ftp.openldap.org/incoming/daniel-pluta-090423.patch I'm not sure whether ORDERING and SUBSTRINGMATCH are neccessary, optional or even wrong(?). Perhab's they can (have to?) be omitted - please see below... Index: ldap/servers/slapd/overlays/collect.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/overlays/collect.c,v retrieving revision 1.5.2.8 diff -u -r1.5.2.8 collect.c --- ldap/servers/slapd/overlays/collect.c 22 Jan 2009 00:01:12 -0000 1.5.2.8 +++ ldap/servers/slapd/overlays/collect.c 23 Apr 2009 20:00:02 -0000 @@ -230,6 +230,9 @@ ARG_MAGIC, collect_cf, "( OLcfgOvAt:19.1 NAME 'olcCollectInfo' " "DESC 'DN of entry and attribute to distribute' " + "EQUALITY caseIgnoreMatch " + "ORDERING caseIgnoreOrderingMatch " + "SUBSTR caseIgnoreSubstringsMatch " "SYNTAX OMsDirectoryString )", NULL, NULL }, { NULL, NULL, 0, 0, 0, ARG_IGNORED } };

1 0

Re: (ITS#6073) ftp.openldap.org "no space left on device"?
by daniel＠pluta.biz 23 Apr '09

23 Apr '09

Status update: it has been fixed - proved by me with: ftp> put daniel-pluta-090423.patch local: daniel-pluta-090423.patch remote: daniel-pluta-090423.patch 227 Entering Passive Mode (204,152,186,57,229,234) 150 Opening BINARY mode data connection for 'daniel-pluta-090423.patch'. 226 Transfer complete (unique file name:daniel-pluta-090423.patch). 735 bytes sent in 0.00 secs (413.2 kB/s) Thanks for addressing/solving this issue. Kurt Zeilenga schrieb: > This problem as been addressed. > > -- Kurt > > On Apr 22, 2009, at 7:45 AM, daniel(a)pluta.biz wrote: > >> Full_Name: Daniel Pluta >> Version: HEAD >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (2001:4ca0:0:f000:78be:f928:4392:2caf) >> >> >> ~/build/pkg$ ftp -p 204.152.186.57 >> Connected to 204.152.186.57. >> 220- OpenLDAP FTP Service >> 220 boole.openldap.org FTP server (Version 6.00LS) ready. >> Name (204.152.186.57:d): anonymous >> 331 Guest login ok, send your email address as password. >> Password: >> 230- Copyright 1998-2009, The OpenLDAP Foundation, All Rights Reserved. >> 230- COPYING RESTRICTIONS APPLY, see: >> 230- ftp://ftp.openldap.org/COPYRIGHT >> 230- ftp://ftp.openldap.org/LICENSE >> 230 Guest login ok, access restrictions apply. >> Remote system type is UNIX. >> Using binary mode to transfer files. >> ftp> cd incoming >> 250 CWD command successful. >> ftp> put collect.c.patch >> local: collect.c.patch remote: collect.c.patch >> 227 Entering Passive Mode (204,152,186,57,240,13) >> 150 Opening BINARY mode data connection for 'collect.c.patch.3'. >> 452 Error writing to file: No space left on device. >> 1833 bytes sent in 0.00 secs (1361.2 kB/s) >> ftp> >

1 0

Re: (ITS#6074) SEGV in pthread_mutex_lock()
by richton＠nbcs.rutgers.edu 23 Apr '09

23 Apr '09

backtrace: https://www.nbcs.rutgers.edu/~richton/openldap-its6074-bt.txt

1 0

(ITS#6074) SEGV in pthread_mutex_lock()
by richton＠nbcs.rutgers.edu 23 Apr '09

23 Apr '09

Full_Name: Aaron Richton Version: 2.4.16 OS: Solaris 9 URL: Submission from: (NULL) (128.6.31.135) Still going through the logs to see what slapd was doing at the time, but my expectation is "Nothing Particularly Exciting" -- this was under production load, I wasn't poking it with a stick or anything. URI with backtrace to follow...

1 0

Re: (ITS#6072) slapo-collect: dnLength != dnDepth
by daniel＠pluta.biz 23 Apr '09

23 Apr '09

Michael Ströder wrote: >> I could not find a suitable api-call to determine a DN's depth. >> > How about using ldap_bv2dn() and count the DN components? > >> So I've used >> posix regexp and uploaded that quick&dirty hacked patch right here: >> > I guess reg ex splitting won't work for arbitrary DN strings. > Hi Michael, after I've had a quick look into "ldap_bv2dn()" you might be right... ;-) Before I'll try to upload the patch again (see ITS#6073) I'll update my code to include your suggestion. Many thanks for your advice! Cheers Daniel

1 0

Re: (ITS#6072) slapo-collect: dnLength != dnDepth
by daniel＠pluta.biz 23 Apr '09

23 Apr '09

Hallvard B Furuseth wrote: >> DNs should be ordered accoring their in-DIT depth and not accoring their >> bv_len: >> > Does that matter, as long as (child, parent) are ordered correctly? > What is the bug you are fixing? > it's regarding the mentioned "*limited* overlapping feature" within the insert_ordered()-function's comment: cite: "... this means longer dn's (i.e. more specific dn's) will be found first when searching..." But, longer DNs do not neccessarily are more specific: ou=openldap,o=rockz,c=it dc=abcdefghijklmnopqrstuvwxyz,dc=com (even longer but not more specific) BTW: the use of insert_ordered() possibly cause some kind of strange (randomized) deletion of a collect_info config attribute's value in this overlay just in the case: c->type == LDAP_MOD_DELETE combined with c->valx > 1 I've noticed this behaviour during testing of my own (chaotic-)test-overlay but had no time to investigate in deep. In my opinion the effect depends on the order of ldapadds of additional DNs and the effective resulting order produced by insert_ordered in combination with "c->valx"... I would file another ITS in case I'm sure that this impressive effect is not cause by my "chaotic" component. ;-)

1 0

← Newer
1
2
3
4
5
6
7
...
15
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 April 2009