openldap-bugs

openldap-bugs@openldap.org

1 participants
20959 discussions

Re: AW: Documentation error in "ppolicy.schema" (ITS#4984)
by hyc＠symas.com 24 May '07

24 May '07

The text in this schema file comes directly from the IETF draft. It should not be changed unless the draft itself has changed. This ITS should be closed. arnim.rupp(a)lhsystems.com wrote: > hi Gavin, > > i think the sentence is ok, just in the wrong place. just move this sentence: > > # This attribute is not set > # due to any actions specified by this document, it is typically set by > # a password administrator after resetting a user's password. > > from "5.2.13 pwdMustChange" to "5.3.7 pwdReset". > > regards > arnim rupp > > --- > Arnim Rupp > > Lufthansa Systems Infratec GmbH > Middleware Competence Center > FRA AI/A-AM > > Am Weiher 24 > 65451 Kelsterbach > Germany > > Raum/Room: 4.U1.07 LIC A > > Tel: +49-69-696-94944 > Fax: +49-69-696-93932 > > Email: arnim.rupp(a)lhsystems.com > Internet: www.lhsystems.com > > Sitz der Gesellschaft/Corporate Headquarters: > Lufthansa Systems Infratec GmbH, Kelsterbach > > Registereintragung/Registration: > Amtsgericht Darmstadt HRB 83851 > > Vorsitzender des Aufsichtsrates/ > Chairman of the Supervisory Board: > Dr. Gunter Küchler > > Geschäftsführung/Management: > Dr. Hannes Pfister > > > > >> -----Ursprüngliche Nachricht----- >> Von: Gavin Henry [mailto:openldap-its@OpenLDAP.org] >> Gesendet: Donnerstag, 24. Mai 2007 16:01 >> An: RUPP, ARNIM >> Cc: openldap-its(a)OpenLDAP.org >> Betreff: Re: Documentation error in "ppolicy.schema" (ITS#4984) >> >> Hi, >> >> Thank for your documentation report. >> >> How would you like it to be worded? >> >> Can you provide an example sentance? >> >> Thanks, >> >> Gavin. >> > > > -- -- 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

AW: Documentation error in "ppolicy.schema" (ITS#4984)
by arnim.rupp＠lhsystems.com 24 May '07

24 May '07

hi Gavin, i think the sentence is ok, just in the wrong place. just move this sentence: # This attribute is not set # due to any actions specified by this document, it is typically set by # a password administrator after resetting a user's password. from "5.2.13 pwdMustChange" to "5.3.7 pwdReset". regards arnim rupp --- Arnim Rupp Lufthansa Systems Infratec GmbH Middleware Competence Center FRA AI/A-AM Am Weiher 24 65451 Kelsterbach Germany Raum/Room: 4.U1.07 LIC A Tel: +49-69-696-94944 Fax: +49-69-696-93932 Email: arnim.rupp(a)lhsystems.com Internet: www.lhsystems.com Sitz der Gesellschaft/Corporate Headquarters: Lufthansa Systems Infratec GmbH, Kelsterbach Registereintragung/Registration: Amtsgericht Darmstadt HRB 83851 Vorsitzender des Aufsichtsrates/ Chairman of the Supervisory Board: Dr. Gunter Küchler Geschäftsführung/Management: Dr. Hannes Pfister > -----Ursprüngliche Nachricht----- > Von: Gavin Henry [mailto:openldap-its@OpenLDAP.org] > Gesendet: Donnerstag, 24. Mai 2007 16:01 > An: RUPP, ARNIM > Cc: openldap-its(a)OpenLDAP.org > Betreff: Re: Documentation error in "ppolicy.schema" (ITS#4984) > > Hi, > > Thank for your documentation report. > > How would you like it to be worded? > > Can you provide an example sentance? > > Thanks, > > Gavin. >

1 0

(ITS#4984) Documentation error in "ppolicy.schema"
by arnim.rupp＠lhsystems.com 24 May '07

24 May '07

Full_Name: arnim rupp Version: 2.3.35 OS: linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (87.106.39.109) hello, there's some wrong documentation in ./servers/slapd/schema/ppolicy.schema in the "chapter" #5.2.13 pwdMustChange is the sentence: # This attribute is not set # due to any actions specified by this document, it is typically set by # a password administrator after resetting a user's password. this doesn't make any sense there since no admin would change a server-wide setting after reseting a users password. instead it is missing in the chapter "#5.3.7 pwdReset". without this sentence it sounds like openldap automatically sets pwdReset (like good old netscape LDAP does). regards arnim

1 0

Re: (ITS#4951) [contrib] RADIUS password module fixes
by richton＠nbcs.rutgers.edu 24 May '07

24 May '07

On Tue, 22 May 2007, Pierangelo Masarati wrote: > If that's an issue, I have no problem in explicitly setting that pointer > to NULL. I got some more dbx time on this, and it looks like that's a workaround for something that shouldn't be happening/needs to be fixed anyway. config_filename is always NULL at dlopen() time, just as it should be. Calling lock(&libradius_mutex) apparently overwrites config_filename, and explicitly initializing to NULL somehow stops this from happening. I can't see anything wrong with radius.c (as in HEAD), though; if anybody can weigh in on this, it'd be much appreciated. I suppose it could still be a compiler or a libthread bug, but I'm still missing a smoking gun here.

1 0

Re: (ITS#4981) Try -lpthread before -pthread
by kurt＠OpenLDAP.org 24 May '07

24 May '07

On May 23, 2007, at 10:16 PM, rra(a)stanford.edu wrote: > libtool does not pass -pthread through Our libtool does. But gcc might not do the right thing with it. In that case, it's a gcc bug which should be reported to the gcc folks. I believe using -lpthread over -pthread will cause more problems than its worth. That is, the problems caused by the missing link on some platforms is not nearly as bad as the caused by using -lc instead of -lc_r on other platforms. -- Kurt

1 0

Re: (ITS#4982) link libldap_r explicitly with the threading libraries
by h.b.furuseth＠usit.uio.no 24 May '07

24 May '07

rra(a)stanford.edu writes: > This issue, ITS#4982, is that no threading flags (not -pthread, not > -lpthread, not anything) are passed into the final link line of libldap_r, > as near as I can tell. Right. grepping make >& make.out shows no thread switch in the command line which builds libldap_r.so. Adding the ITS#4982 patch (and not ITS#4981), I got 4 '-pthread's in a row, which should be enough:-) -- Regards, Hallvard

1 0

Re: (ITS#4982) link libldap_r explicitly with the threading libraries
by rra＠stanford.edu 24 May '07

24 May '07

Kurt Zeilenga <kurt(a)OpenLDAP.org> writes: > libtool should properly handle -pthread. If it doesn't, that should be > fixed instead of kludging things up with -lpthread. -pthread tells gcc > to do the right thing. The right thing might not be to link in > -lpthread. (On some versions of FreeBSD, the right think is -lc_r.) > -pthread also might do more than link in a library. > As OpenLDAP includes its own copy of libtool, a local fix can be > provided until the upstream fixes it right. I think the above was meant for ITS #4981? This issue, ITS#4982, is that no threading flags (not -pthread, not -lpthread, not anything) are passed into the final link line of libldap_r, as near as I can tell. It's possible that I'm reading the makefile wrong and this has been fixed in some other way since the Debian patch had been applied, but libraries/libldap_r/Makefile.in contains: UNIX_LINK_LIBS = $(LDAP_LIBLBER_LA) $(AC_LIBS) $(SECURITY_LIBS) and build/lib-shared.mk has: $(LIBRARY): version.lo $(LTLINK_LIB) -o $@ $(OBJS) version.lo $(LINK_LIBS) including only LINK_LIBS, and not the regular LIBS variable (which is what includes LTHREAD_LIBS via XXXLIBS). It could be that I'm missing some contribution to LTLINK_LIB handled by the threading macros, though. -- Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>

1 0

Re: (ITS#4982) link libldap_r explicitly with the threading libraries
by kurt＠OpenLDAP.org 24 May '07

24 May '07

libtool should properly handle -pthread. If it doesn't, that should be fixed instead of kludging things up with -lpthread. -pthread tells gcc to do the right thing. The right thing might not be to link in - lpthread. (On some versions of FreeBSD, the right think is -lc_r.) -pthread also might do more than link in a library. As OpenLDAP includes its own copy of libtool, a local fix can be provided until the upstream fixes it right. -- Kurt On May 24, 2007, at 1:25 AM, rra(a)stanford.edu wrote: > Hallvard B Furuseth <h.b.furuseth(a)usit.uio.no> writes: >> Hallvard B Furuseth writes: > >>> Is this the second half of the Debian patch you posted in >>> ITS#4981 - so >>> it'd be wrong to apply one one of these patches? > >> Sorry, "wrong to apply _only_ one of". > >> (I.e. does ITS#4981 introduce breakage which ITS#4982 fixes?) Maybe >> everything worked well before we switched to libtool... > > No, they should be independent, I think. I believe that the > rationale for > 4982 is still correct; if you use pthread functions, you need to > explicitly link against the library to avoid getting unversioned > references. Unversioned references will *normally* not cause a > problem, > so they're a bit of a time bomb. They keep working fine right up > until > the library makes an incompatible change in the data structures, > and then > they break. > > -- > Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/ > ~eagle/> > >

1 0

Re: (ITS#4982) link libldap_r explicitly with the threading libraries
by rra＠stanford.edu 24 May '07

24 May '07

Hallvard B Furuseth <h.b.furuseth(a)usit.uio.no> writes: > Hallvard B Furuseth writes: >> Is this the second half of the Debian patch you posted in ITS#4981 - so >> it'd be wrong to apply one one of these patches? > Sorry, "wrong to apply _only_ one of". > (I.e. does ITS#4981 introduce breakage which ITS#4982 fixes?) Maybe > everything worked well before we switched to libtool... No, they should be independent, I think. I believe that the rationale for 4982 is still correct; if you use pthread functions, you need to explicitly link against the library to avoid getting unversioned references. Unversioned references will *normally* not cause a problem, so they're a bit of a time bomb. They keep working fine right up until the library makes an incompatible change in the data structures, and then they break. -- Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>

1 0

Re: (ITS#4982) link libldap_r explicitly with the threading libraries
by h.b.furuseth＠usit.uio.no 24 May '07

24 May '07

Hallvard B Furuseth writes: > Is this the second half of the Debian patch you posted in ITS#4981 - so > it'd be wrong to apply one one of these patches? Sorry, "wrong to apply _only_ one of". (I.e. does ITS#4981 introduce breakage which ITS#4982 fixes?) Maybe everything worked well before we switched to libtool... -- Regards, Hallvard

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