openldap-bugs February 2009

openldap-bugs@openldap.org

47 participants
298 discussions

Re: (ITS#5945) --enable-backends=auto support
by michael＠stroeder.com 14 Feb '09

14 Feb '09

Kurt(a)OpenLDAP.org wrote: > On Feb 13, 2009, at 6:42 PM, hyc(a)symas.com wrote: > >> Perhaps a decent alternative would be just to read a set of --enable >> switches >> from ~/.openldap_config or somesuch. I.e., have a file of defaults... > > I think I prefer the current situation to such... And I already > have ./config.status --r > > But on new checkouts, I normally just do --enable-backends --enable- > overlays, wait for breakage, and then add disable flags as needed. > Unforunately, it sometimes takes a few tries. > > So, in short, I concur that doing more here is likely not worth the > effort. +1 Ciao, Michael.

1 0

Re: (ITS#5760) attribute hiding in rwm overlay
by ando＠sys-net.it 14 Feb '09

14 Feb '09

brett.maxfield(a)gmail.com wrote: > --0016e65206024a6d9d0462d5c0d0 > Content-Type: text/plain; charset=ISO-8859-1 > Content-Transfer-Encoding: 7bit > > I have re-tested with recent RE24 and this still happens. > > Assuming the config (database meta, and map instead of rwm-map shows similar > problem) : > > database ldap > suffix "c=AU" > uri "ldap://127.0.0.1:390/c=AU" You messed things up a little bit: back-ldap does not allow the DN part of the URI. > overlay rwm > > rwm-map attribute cn * > rwm-map attribute sn * > rwm-map attribute givenName * > rwm-map attribute * > > rwm-map objectclass inetOrgPerson * > rwm-map objectclass organisationalUnit * s/organisationalUnit/organizationalUnit/: this raises a warning. > rwm-map objectclass organization * > rwm-map objectclass country * > rwm-map objectclass * > > I have a standard LDAP with standard inetOrgPerson style schemas on ldap:// > 127.0.0.1:390/c=AU with some dummy data, and when i query the source > directory i get sensible results: > > suse:/usr/local/etc/openldap # ldapsearch -H ldap://127.0.0.1:390 -x -b > 'cn=test00496,ou=support,o=openldap,c=AU' '(objectclass=*)' '*' > # extended LDIF > # > # LDAPv3 > # base <cn=test00496,ou=support,o=openldap,c=AU> with scope subtree > # filter: (objectclass=*) > # requesting: * > # > > # test00496, support, openldap, AU > dn: cn=test00496,ou=support,o=openldap,c=AU > objectClass: inetOrgPerson > cn: test00496 > givenName: test00496 > uid: test00496 > sn: test00496lname > displayName: test00496 test00496lname > userPassword:: bm92ZWxs > > # search result > search: 2 > result: 0 Success > > # numResponses: 2 > # numEntries: 1 > > When i query the meta directory, i get no attributes (* or + or *,+, in the > requested attributes all return no attributes as below) : > > ldapsearch -H ldap://127.0.0.1:391 -x -b > 'cn=test00496,ou=support,o=openldap,c=AU' '(objectclass=*)' '*' > # extended LDIF > # > # LDAPv3 > # base <cn=test00496,ou=support,o=openldap,c=AU> with scope subtree > # filter: (objectclass=*) > # requesting: * > # > > # test00496, support, openldap, AU > dn: cn=test00496,ou=support,o=openldap,c=AU > > # search result > search: 2 > result: 0 Success > > # numResponses: 2 > # numEntries: 1 > > But if i query the meta directory explicitly for some attributes (no * +), > it works, i get : > > ldapsearch -H ldap://127.0.0.1:391 -x -b > 'cn=test00496,ou=support,o=openldap,c=AU' '(objectclass=*)' cn sn firstName > # extended LDIF > # > # LDAPv3 > # base <cn=test00496,ou=support,o=openldap,c=AU> with scope subtree > # filter: (objectclass=*) > # requesting: cn sn firstName > # > > # test00496, support, openldap, AU > dn: cn=test00496,ou=support,o=openldap,c=AU > cn: test00496 > sn: test00496lname > > # search result > search: 2 > result: 0 Success > > # numResponses: 2 > # numEntries: 1 > > So i conclude then that the default attribute lists of *, +, or *,+ are > somehow being lost by backend meta or overlay rwm ? > > Probably * and + (or *,+) should be expanded to the list of user or > administrative attributes (respectively) by meta/rwm first, specifically > those that are allowed by "map attribute" lines, before being handed to the > real directory (helpful to performance if the backend directory has many > attributes, that the meta directory is not interested in). > > This is also why attributes don't appear in a GUI browser for me, if i am > using a GUI browser, as they commonly use *,+ as their default. Well, if you don't request any attribute, those that are mapped appear. I've modified slapo-rwm to pass thru special attribute names ("*", "+", "1.1") in order to defer their mapping when results are returned. This looks simpler than detecting whether non-mapped attrs are filtered and, in tat case, replace "*" by the mapped attributes, although the latter could be an optimization. A fix is in HEAD (affecting back-meta and slapo-rwm independently). Please test. Unfortunately it seems to be too late for OpenLDAP 2.4.14. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine)
by ando＠sys-net.it 14 Feb '09

14 Feb '09

philippe.eychart(a)informatique.gov.pf wrote: > This is a multi-part message in MIME format. > > ------=_NextPart_000_00C2_01C98DEA.AA80EF10 > Content-Type: text/plain; > charset="iso-8859-1" > Content-Transfer-Encoding: 7bit > > As I leave one week for a security formation ISO 27001 (and in case it would > persuade me to make never more programming ;), here is the current state > (not finished) of the patch You should upload patches to ftp.openldap.org and post a link to them, otherwise mailers screw them up as below. Please follow instructions at <http://www.openldap.org/devel/contributing.html#submitting>. p. (only the modified function - cf "Followup 19"). > In fact, 2 more options must be validated there : > 1/- ... // if (x-dnssrv == ".") then $hostname is (must be) the search > SRV-domain (or the default domain, if $hostname=="") ... > 2/- // in all cases, if (*port != '\0') then : result = $(grep "$port" $(the > result of the SRV search)) ... > -- > PE > > ------=_NextPart_000_00C2_01C98DEA.AA80EF10 > Content-Type: application/octet-stream; > name="open.c.url_expand.patch" > Content-Transfer-Encoding: quoted-printable > Content-Disposition: attachment; > filename="open.c.url_expand.patch" > > --- openldap-2.4.13/libraries/libldap/open.c 2008-10-31 = > 23:23:58.000000000 +0000=0A= > +++ openldap-2.4.13/libraries/libldap/open.c 2009-02-14 = > 00:31:27.000000000 +0000=0A= > @@ -212,19 +212,164 @@=0A= > return( ld );=0A= > }=0A= > =0A= > +int=0A= > +url_expand_on_srv_search ( char ***result, LDAP_CONST char *url_in, = > char *domain )=0A= > +{ int rc =3D 0;=0A= > + char *scheme, *hostname, *port, *opt;=0A= > +=0A= > + // Syntax validation ...=0A= > + if ( (scheme =3D (char *)LDAP_STRDUP( url_in )) =3D=3D NULL )=0A= > + return -1; // memory error ...=0A= > +=0A= > + hostname =3D (char *)strchrnul( scheme, '/' ); *hostname++ =3D '\0';=0A= > + if ( *hostname++ !=3D '/' )=0A= > + return -1; // syntax error ...=0A= > + =0A= > + opt =3D (char *)strchrnul( hostname, '/' ); if ( *opt ) *opt++ =3D = > '\0';=0A= > + port =3D (char *)strchrnul( hostname, ':' ); if ( *port ) *port++ =3D = > '\0';=0A= > +=0A= > + if ( *hostname && !strcmp ( domain, "." )=3D=3D0 ) // if (x-dnssrv = > =3D=3D ".") then $hostname is the search SRV-domain (or default domain, = > if $hostname=3D=3D"") ...=0A= > + return -1; // syntax error ...=0A= > +=0A= > + // So now, we can search the server name(s) of the _ldap._tcp.$domain = > service ...=0A= > + // if ( *port !=3D '\0') then : grep the result of SRV RR search with = > $port ...=0A= > +=0A= > + // Coming soon ...=0A= > +if ( (*result =3D ldap_str2charray( "ldap1.gov.pf ldap2.gov.pf = > ldap3.gov.pf", " " )) !=3D NULL ) rc =3D 3; // line to delete ...=0A= > +=0A= > + // Search is finished : so now, add initial scheme and opt to result = > hostport(s) ...=0A= > + if ( *result !=3D NULL ) {=0A= > + size_t plus =3D strlen( scheme ) + strlen ( opt ) + 4;=0A= > + for ( rc=3D0; (char *)((*result)[rc]) !=3D NULL; ) {=0A= > + (*result)[rc] =3D (char *)LDAP_REALLOC ( (char *)((*result)[rc]), = > strlen ( (char *)((*result)[rc]) ) + plus ); =0A= > + { // do a : memcpy ( &((char *)((*result)[rc]))[strlen( scheme ) + = > 2], *result[rc], strlen( (char *)((*result)[rc]) ) + 1 );=0A= > + char *n =3D &((char *)((*result)[rc]))[strlen( scheme ) + 2];=0A= > + char *s =3D (char *)((*result)[rc]);=0A= > + char *e =3D s + (strlen( (char *)((*result)[rc]) ) + 1);=0A= > + for ( n +=3D e - s; e >=3D s; ) *n-- =3D *e--;=0A= > + }=0A= > + memcpy ( &((char *)((*result)[rc]))[strlen( scheme )], "//", 2 );=0A= > + memcpy ( (char *)((*result)[rc]), scheme, strlen( scheme ) );=0A= > + strcat ( (char *)((*result)[rc]), "?" ); strcat ( (char = > *)((*result)[rc]), opt );=0A= > + rc++;=0A= > + }=0A= > + } else rc =3D 0;=0A= > +=0A= > + LDAP_FREE ( scheme );=0A= > + return rc;=0A= > +}=0A= > +=0A= > +char *=0A= > +expand_dnssrv_definitions ( LDAP_CONST char *url_in )=0A= > +{=0A= > ...=0A= > =0A= > > ------=_NextPart_000_00C2_01C98DEA.AA80EF10-- > > 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5945) --enable-backends=auto support
by Kurt＠OpenLDAP.org 13 Feb '09

13 Feb '09

On Feb 13, 2009, at 6:42 PM, hyc(a)symas.com wrote: > Perhaps a decent alternative would be just to read a set of --enable > switches > from ~/.openldap_config or somesuch. I.e., have a file of defaults... I think I prefer the current situation to such... And I already have ./config.status --r But on new checkouts, I normally just do --enable-backends --enable- overlays, wait for breakage, and then add disable flags as needed. Unforunately, it sometimes takes a few tries. So, in short, I concur that doing more here is likely not worth the effort. -- Kurt

1 0

Re: (ITS#5945) --enable-backends=auto support
by hyc＠symas.com 13 Feb '09

13 Feb '09

Howard Chu wrote: > Kurt Zeilenga wrote: >> I just noting that for testing, it kind of nice to just be able to do >> ./configure --enable-backends=auto --enable-overlays=auto >> make >> make test >> >> To test everything that available on the box. > > Note that there's no need for an "auto" for overlays - all of the core > overlays are self-contained with no external dependencies, and that should > always be the case. > > I agree that "testing everything available" would be nice, because I > frequently forget to --enable-slapi or various other switches. But I don't > think --enable-everything will suit either. > Perhaps a decent alternative would be just to read a set of --enable switches from ~/.openldap_config or somesuch. I.e., have a file of defaults... -- -- 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#5945) --enable-backends=auto support
by hyc＠symas.com 13 Feb '09

13 Feb '09

Kurt Zeilenga wrote: > I just noting that for testing, it kind of nice to just be able to do > ./configure --enable-backends=auto --enable-overlays=auto > make > make test > > To test everything that available on the box. Note that there's no need for an "auto" for overlays - all of the core overlays are self-contained with no external dependencies, and that should always be the case. I agree that "testing everything available" would be nice, because I frequently forget to --enable-slapi or various other switches. But I don't think --enable-everything will suit either. -- -- 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#5945) --enable-backends=auto support
by Kurt＠OpenLDAP.org 13 Feb '09

13 Feb '09

On Feb 13, 2009, at 5:55 PM, hyc(a)symas.com wrote: > quanah(a)OpenLDAP.org wrote: >> Full_Name: Quanah Gibson-Mount >> Version: 2.4.13 >> OS: NA >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (75.111.29.239) >> >> >> It would be handy to allow --enable-backends to have auto support >> so that all >> available backends can be selected. The current behavior is "yes", >> which means >> that if you don't have the requisites for a given backend, >> configure stops. > > Accommodating this request would make other things much more > inconvenient. > > Currently the backends and overlay options toggle between "no | yes > | mod" > where "yes" means "yes+static" and "mod" means "yes+dynamic". An > "auto" option > here doesn't allow you to select static vs dynamic. We could have auto => yes+static and automod => yes+dyanmic. But that might be too cumbersome as well. > Adding "auto" would revert > us back to OpenLDAP 2.0's behavior, where every backend required two > enable > switches "--enable-bdb" and "--enable-bdb-mod=static" (or dynamic) > which IMO > was far too cumbersome. > > > Likewise it would require rewriting most of the backends' detection > tests in > configure.in, which currently use AC_MSG_ERROR when a prereq isn't > found. All > of those would have to be turned into warnings/bailouts in the > "auto" case, > instead of aborting the configure run. There's still a lot of old auto tests in configure.in, even for new things like ndb. :-) > > > IMO, seems like more effort than it's worth. possibly. I just noting that for testing, it kind of nice to just be able to do ./configure --enable-backends=auto --enable-overlays=auto make make test To test everything that available on the box. > > -- > -- 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#5945) --enable-backends=auto support
by hyc＠symas.com 13 Feb '09

13 Feb '09

quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.13 > OS: NA > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.29.239) > > > It would be handy to allow --enable-backends to have auto support so that all > available backends can be selected. The current behavior is "yes", which means > that if you don't have the requisites for a given backend, configure stops. Accommodating this request would make other things much more inconvenient. Currently the backends and overlay options toggle between "no | yes | mod" where "yes" means "yes+static" and "mod" means "yes+dynamic". An "auto" option here doesn't allow you to select static vs dynamic. Adding "auto" would revert us back to OpenLDAP 2.0's behavior, where every backend required two enable switches "--enable-bdb" and "--enable-bdb-mod=static" (or dynamic) which IMO was far too cumbersome. Likewise it would require rewriting most of the backends' detection tests in configure.in, which currently use AC_MSG_ERROR when a prereq isn't found. All of those would have to be turned into warnings/bailouts in the "auto" case, instead of aborting the configure run. IMO, seems like more effort than it's worth. -- -- 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#5945) --enable-backends=auto support
by quanah＠OpenLDAP.org 13 Feb '09

13 Feb '09

Full_Name: Quanah Gibson-Mount Version: 2.4.13 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) It would be handy to allow --enable-backends to have auto support so that all available backends can be selected. The current behavior is "yes", which means that if you don't have the requisites for a given backend, configure stops.

1 0

Re: (ITS#5942) URI matching of "self" in add_syncrepl is incomplete
by hyc＠symas.com 13 Feb '09

13 Feb '09

jclarke(a)linagora.com wrote: > This is a multi-part message in MIME format. Please do not send HTML/MIME emails here. > On 13.02.2009 14:29, jclarke(a)linagora.com wrote: > I am following what test049 does. > Oops, sorry, I've been mixing 049 and 050 in my head. My bad, this isn't > a problem for test049 indeed. > > Although I am curious as to why test049 creates a syncrepl consumer > targeted at itself? Can't quite get my head around it yet, but will keep > thinking, with regard to multimaster. Very simple. Once the real consumer connects to the master and replicates, it will acquire whatever config was on the master. If the master doesn't have a consumer pointed at itself, then once the consumer acquires the master's configuration, the consumer's syncrepl config will disappear, and replication will stop. -- -- 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

← Newer
1
...
10
11
12
13
14
15
16
...
30
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 February 2009