openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

(ITS#5091) Odds of attribute mapping in slapo-rwm
by ando＠sys-net.it 14 Aug '07

14 Aug '07

Full_Name: Pierangelo Masarati Version: HEAD/re23 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando If an attribute is mapped onto another, say rwm-map attribute foo bar and both attributes "foo" and "bar" are present in the underlying database, there might be cases (like requesting "*") where both are returned, and "bar" is mapped into "foo" while "foo" remains "foo", but they appear in the result as separate attributes. I guess the cleanest solution would be to merge the two attribute sets into a single occurrence of "foo". I didn't check yet, but I expect a similar issue to be present with respect to objectClass; in this case, the same value might appear twice. p.

1 0

Re: (ITS#5061) client/tools: Password Policy control handling
by ando＠sys-net.it 13 Aug '07

13 Aug '07

quanah(a)zimbra.com wrote: > Pierangelo noted I missed common.c, which has many of the same issues > around it as ldapmodify.c. I can back out the commits I made earlier > today, or the backporting can be done for those two... I think it would be > nice to have the functionality into 2.3. I've already patched ldapmodify.c (keeping as low a profile as possible); most of the work is now in common.c, but I can try to keep the same low profile and see where I get. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5061) client/tools: Password Policy control handling
by quanah＠zimbra.com 13 Aug '07

13 Aug '07

--On August 13, 2007 7:13:03 PM +0000 quanah(a)zimbra.com wrote: > > > --On August 13, 2007 7:08:32 PM +0000 kurt(a)OpenLDAP.org wrote: > >> Given the ppolicy change backport for everything else was straight >> forward for >> every other command, and committed, seems reasonable to keep it. >> Ando and/or >> I likely can do a quick backport for ldapmodify.c. > > Sounds good. :) Pierangelo noted I missed common.c, which has many of the same issues around it as ldapmodify.c. I can back out the commits I made earlier today, or the backporting can be done for those two... I think it would be nice to have the functionality into 2.3. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5061) client/tools: Password Policy control handling
by quanah＠zimbra.com 13 Aug '07

13 Aug '07

--On August 13, 2007 7:08:32 PM +0000 kurt(a)OpenLDAP.org wrote: > Given the ppolicy change backport for everything else was straight > forward for > every other command, and committed, seems reasonable to keep it. > Ando and/or > I likely can do a quick backport for ldapmodify.c. Sounds good. :) --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5061) client/tools: Password Policy control handling
by kurt＠OpenLDAP.org 13 Aug '07

13 Aug '07

Given the ppolicy change backport for everything else was straight forward for every other command, and committed, seems reasonable to keep it. Ando and/or I likely can do a quick backport for ldapmodify.c. -- Kurt

1 0

Re: (ITS#5061) client/tools: Password Policy control handling
by kurt＠OpenLDAP.org 13 Aug '07

13 Aug '07

On Aug 13, 2007, at 6:06 PM, quanah(a)zimbra.com wrote: > --On July 23, 2007 6:51:35 PM +0000 kurt(a)OpenLDAP.org wrote: > >> Full_Name: Kurt Zeilenga >> Version: 2.3 >> OS: Mac OS X >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (130.129.101.249) >> Submitted by: kurt >> >> >> 2.3 (and 2.4) client tools only send the password policy control >> with the >> Bind requests. However, the control is not only valid with most >> every >> request, but useful to send with every request. HEAD has been >> updated >> to send, when -e ppolicy is selected, the control with every >> request, and >> to print the control details on return. While this could be >> viewed as a >> new feature by some it could abe viewed as a bug fix by others. >> Given >> this change scope is quite narrow (should only effect -e ppolicy >> users), >> I recommend it inclusion in the next patch release of 2.3. > > Hi Kurt, > > I've been working on this for the 2.3 release, however there is a > problem > when it comes to ldapmodify. Pierangelo made the change around > controls to > the ldapmodify code around revision 1.172. However, when 2.3 was > branched > (after revision 1.175), this new code was excluded by you. So, the > question I have now, is should this code now be pulled into 2.3? > It is > quite a bit of change. > > --Quanah If 2.3 wasn't quite frozen, I'd say just suck in the new tools... But given 2.3 is very much frozen, and the change scope isn't as narrow as I thought it would be, seems more appropriate just to leave this out. Oh well. Another reason to push 2.4beta out, I guess. -- Kurt

1 0

Re: (ITS#5061) client/tools: Password Policy control handling
by quanah＠zimbra.com 13 Aug '07

13 Aug '07

--On July 23, 2007 6:51:35 PM +0000 kurt(a)OpenLDAP.org wrote: > Full_Name: Kurt Zeilenga > Version: 2.3 > OS: Mac OS X > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (130.129.101.249) > Submitted by: kurt > > > 2.3 (and 2.4) client tools only send the password policy control with the > Bind requests. However, the control is not only valid with most every > request, but useful to send with every request. HEAD has been updated > to send, when -e ppolicy is selected, the control with every request, and > to print the control details on return. While this could be viewed as a > new feature by some it could abe viewed as a bug fix by others. Given > this change scope is quite narrow (should only effect -e ppolicy users), > I recommend it inclusion in the next patch release of 2.3. Hi Kurt, I've been working on this for the 2.3 release, however there is a problem when it comes to ldapmodify. Pierangelo made the change around controls to the ldapmodify code around revision 1.172. However, when 2.3 was branched (after revision 1.175), this new code was excluded by you. So, the question I have now, is should this code now be pulled into 2.3? It is quite a bit of change. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5090) Error with attribute "jpegPhoto"
by ando＠sys-net.it 13 Aug '07

13 Aug '07

nicolas.sandraz(a)gmail.com wrote: Fixed in HEAD & re23; please test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5090) Error with attribute "jpegPhoto"
by ando＠sys-net.it 13 Aug '07

13 Aug '07

Howard Chu wrote: > ando(a)sys-net.it wrote: >> marg(a)rz.tu-clausthal.de wrote: >>> Oh, and that special syntax is a function of ldapadd/ldapmodify, not >>> some standard way of importing images - so using it with slapadd >>> won't work. > > Not true. Both slapadd and ldapadd use the same LDIF reading routines; > they have since 2.3 was first released. All valid LDIF is accepted > identically by both programs. > >> well, that's a SHOULD in RFC2849, so it is indeed a standard way of >> importing values (works with any value) using LDIF. The fact it doesn't >> work with slapadd should be seen as a limitation of that tool, which it >> is not intended for use with arbitrary LDIF but rather with LDIF >> produced by slapcat. Well, I need to take both my claims back; I was writing jpegPhoto: <file///... while the right syntax (still with the missing ":") is jpegPhoto:< file///... and the error is still there in 2.3. I'll fix it in a moment. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5090) Error with attribute "jpegPhoto"
by hyc＠symas.com 13 Aug '07

13 Aug '07

ando(a)sys-net.it wrote: > marg(a)rz.tu-clausthal.de wrote: >> Oh, and that special syntax is a function of ldapadd/ldapmodify, not >> some standard way of importing images - so using it with slapadd won't work. Not true. Both slapadd and ldapadd use the same LDIF reading routines; they have since 2.3 was first released. All valid LDIF is accepted identically by both programs. > well, that's a SHOULD in RFC2849, so it is indeed a standard way of > importing values (works with any value) using LDIF. The fact it doesn't > work with slapadd should be seen as a limitation of that tool, which it > is not intended for use with arbitrary LDIF but rather with LDIF > produced by slapcat. -- -- Howard Chu Chief Architect, 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