openldap-bugs

openldap-bugs@openldap.org

1 participants
20963 discussions

Re: (ITS#6435) Hidden schema elements
by michael＠stroeder.com 21 Dec '09

21 Dec '09

rein(a)OpenLDAP.org wrote: > Full_Name: Rein Tollevik > Version: CVS HEAD > OS: Irrelevant > URL: > Submission from: (NULL) (2a01:600:0:1:21c:23ff:feab:61cd) > Submitted by: rein > > Some of the operational attributes defined in the slapd source are hidden from > the clients unless slapd is compiled with LDAP_DEVEL enabled. Still, some of > these elements are used in the database (as in the authz* and monitor related > attributes). Yes, see also: http://www.openldap.org/its/index.cgi?findid=5573 http://www.openldap.org/its/index.cgi?findid=5574 http://www.openldap.org/its/index.cgi?findid=5576 IIRC also a bunch of attribute types used in back-config which makes back-config almost unusable with a stock schema aware client. The standard answer by Kurt and others is that as along as an experimental OID with .666 is used a schema description should be hidden. I strongly disagree with that though. > This causes my schema-aware application to complain when it sees > (or worse tries to modify) these attributes. (Sigh!) I also had to add several work-arounds to web2ldap regarding this. > A patch that adds a new optional define that can be used to disable the schema > hiding without enabling LDAP_DEVEL is coming. Looking forward to this being committed. > A better fix would be to not hide those schema elements that is actually > being used.. Amen. Ciao, Michael.

1 0

Re: (ITS#6435) Hidden schema elements
by Kurt＠OpenLDAP.org 21 Dec '09

21 Dec '09

On Dec 21, 2009, at 8:09 AM, rein(a)OpenLDAP.org wrote: > Full_Name: Rein Tollevik > Version: CVS HEAD > OS: Irrelevant > URL:=20 > Submission from: (NULL) (2a01:600:0:1:21c:23ff:feab:61cd) > Submitted by: rein >=20 >=20 > Some of the operational attributes defined in the slapd source are = hidden from > the clients unless slapd is compiled with LDAP_DEVEL enabled. Yes, it has long been our practice not to publish schema elements which = are not yet well standardized. This would include any element which = carries a OpenLDAP.666 OID. The idea being that use of such attributes should be limited to early = adopters and such. > Still, some of > these elements are used in the database (as in the authz* and monitor = related > attributes). This causes my schema-aware application to complain when = it sees > (or worse tries to modify) these attributes. >=20 > A patch that adds a new optional define that can be used to disable = the schema > hiding without enabling LDAP_DEVEL is coming. A better fix would be = to not hide > those schema elements that is actually being used.. It may be that the particular schema elements simply shouldn't be behind = LDAP_DEVEL any longer, possibly because a permanent OID has yet to be = assigned to now production code. >=20 > Rein >=20

1 0

Re: Re : ITS#6434
by masarati＠aero.polimi.it 21 Dec '09

21 Dec '09

KISTER RAPHAEL wrote: > Hello, > > I make a test with servers/slapd/overlays/rwm.c version 1.124. It works fine. Thank you very much for your help. I've re-fixed the problem in a different way; please re-test. Thanks, p.

1 0

Re: (ITS#6435) Hidden schema elements
by masarati＠aero.polimi.it 21 Dec '09

21 Dec '09

rein(a)OpenLDAP.org wrote: > A better fix would be to not hide > those schema elements that is actually being used.. As far as I can tell, OpenLDAP's policy with respect to hiding schema definitions consists in un-hiding only those that are documented in standards track documents, or are for internal use and thus documented internally (e.g. back-config related). So the "right" fix would be to work at formalizing and submitting documents to stardards track. p.

1 0

(ITS#6435) Hidden schema elements
by rein＠OpenLDAP.org 21 Dec '09

21 Dec '09

Full_Name: Rein Tollevik Version: CVS HEAD OS: Irrelevant URL: Submission from: (NULL) (2a01:600:0:1:21c:23ff:feab:61cd) Submitted by: rein Some of the operational attributes defined in the slapd source are hidden from the clients unless slapd is compiled with LDAP_DEVEL enabled. Still, some of these elements are used in the database (as in the authz* and monitor related attributes). This causes my schema-aware application to complain when it sees (or worse tries to modify) these attributes. A patch that adds a new optional define that can be used to disable the schema hiding without enabling LDAP_DEVEL is coming. A better fix would be to not hide those schema elements that is actually being used.. Rein

1 0

Re : ITS#6434
by kraph＠yahoo.com 21 Dec '09

21 Dec '09

Hello,=0A=0AI=A0make a test=A0with servers/slapd/overlays/rwm.c=A0version= =A0=A01.124. It works fine. Thank you very much for your help.=0A=0ABest re= gards,=0A=A0Raphael KISTER=0A=0A=0A=0A----- Message d'origine ----=0ADe : P= ierangelo Masarati <masarati(a)aero.polimi.it>=0A=C0 : KISTER RAPHAEL <kraph@= yahoo.com>; openldap-its(a)openldap.org=0AEnvoy=E9 le : Lun 21 D=E9cembre 200= 9, 13 h 08 min 31 s=0AObjet=A0: ITS#6434=0A=0AThe problem has been fixed in= HEAD (servers/slapd/overlays/rwm.c 1.122 -> 1.223); please test and report= .=A0 Thanks, p.=0A=0A=0A=0A

1 0

ITS#6434
by masarati＠aero.polimi.it 21 Dec '09

21 Dec '09

The problem has been fixed in HEAD (servers/slapd/overlays/rwm.c 1.122 -> 1.223); please test and report. Thanks, p.

1 0

(ITS#6434) Problem with rewrite overlay
by kraph＠yahoo.com 21 Dec '09

21 Dec '09

Full_Name: Raphaël KISTER Version: 2.4.20 OS: Linux CentOS 5.4 URL: http://www.raphael-kister.fr/openldap_its Submission from: (NULL) (88.184.63.204) I would like to use OpenLDAP as an Active Directory Proxy. I configure ldap backend and i rewrite some attributes and objectclass. When i test my configuration file, i get this error : config error processing olcOverlay={0}rwm,olcDatabase={2}ldap,cn=config: <olcRwmMap> handler exited with 1 slaptest: bad configuration directory! This is an extract of my config file : database ldap suffix dc=CNC,dc=LOCAL rootdn "cn=admin,cn=config" uri ldap://192.168.44.88:389 lastmod off acl-authcDN cn=admin,cn=config acl-passwd secret idassert-bind bindmethod="simple" binddn="CN=srv_ldap,OU=Services-account,OU=Administration,dc=CNC,dc=LOCAL" credentials="Azerty00" mode="legacy" overlay rwm #rwm-suffixmassage dc=CNC,dc=LOCAL rwm-map objectclass inetOrgPerson user rwm-map attribute uid sAMAccountName rwm-map attribute cn cn rwm-map attribute displayName displayName rwm-map attribute givenName givenName rwm-map attribute sn sn rwm-map attribute mail mail rwm-map attribute userPassword userPassword rwm-map attribute *

1 0

(ITS#6433) patch for the sha2 module: hash methods for passwords generation
by cdelfosse＠mandriva.com 21 Dec '09

21 Dec '09

Full_Name: Cédric Delfosse Version: HEAD OS: Mandriva Linux URL: ftp://ftp.openldap.org/incoming/cedric-delfosse-091221.patch Submission from: (NULL) (62.212.120.90) Hello, this patch allows to use the {SHA256}, {SHA384} and {SHA512} password schemes (provided by the sha2 module) with LDAP Password Modify Extended Operations. This patch contains the required hash methods. This patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Mandriva. Mandriva has not assigned rights and/or interest in this work to any party. I, Cédric Delfosse am authorized by Mandriva, my employer, to release this work under the following terms. Mandriva hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice. Regards, Cédric

1 0

Re: (ITS#6432) PATCH: MozNSS crypto (tls_m.c) - support InitContext, improved PEM support
by hyc＠symas.com 18 Dec '09

18 Dec '09

rmeggins(a)redhat.com wrote: > You are right, Howard. It works as you described. I'm not sure what > happened in my testing. Mea culpa. > > This is a new patch with the SetURL changes backed out. > > ftp://ftp.openldap.org/incoming/openldap-2.4.20-tls_m_c-InitContext-PEM-200… OK. Another question - you're only using NSS_InitContext() for client initialization. Any particular reason not to always use it? Also in tlsm_ctx_free() is it safe to pass a NULL to NSS_ShutdownContext()? I think these two lines should be enclosed in "if (c->tc_initctx) {}" -- -- 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