openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

RE: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine)
by philippe.eychart＠informatique.gov.pf 06 Feb '09

06 Feb '09

This is a multi-part message in MIME format. ------=_NextPart_000_00B1_01C987A2.419734D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit and patch could be something like that ... -- pe -----Message d'origine----- De : Philippe EYCHART [mailto:philippe.eychart@informatique.gov.pf] Envoye : jeudi 5 fevrier 2009 11:33 A : h.b.furuseth(a)usit.uio.no; ando(a)sys-net.it Cc : openldap-its(a)openldap.org Objet : RE: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine) And what do you think about : ldap://.nameOfSrvDomainSearch/ ('.' at begining of the hostname to say "use SRV record" of this domain - search domain(s) if only '.') ?... -- pe -----Message d'origine----- De : Hallvard Breien Furuseth [mailto:h.b.furuseth@usit.uio.no] Envoye : mercredi 4 fevrier 2009 05:02 A : Philippe.eychart(a)informatique.gov.pf Cc : openldap-its(a)openldap.org Objet : Re: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine) I'm not quite sure if it's a good idea to move ldap SRV lookup into ldap_initialize(), since ldap:/// is also means "this LDAP server" in referral objects and some slapd backends. Possibly some other syntax should be used to say "use SRV record", e.g. "ldap://./", or another function could work like ldap_initialize() but be more clever. Though a helper function which copies clients/tools/common.c:tool_conn_setup() functionality could in any case be useful. Also note that _ldap._tcp.domain is of limited utility outside Windows-land, because Microsoft annexed it for Active Directory: On a site which has Windows and Active Directory, _ldap._tcp.domain is normally required to refer to Active Directory. Thus if such a site uses another LDAP server for their public LDAP data, they can't _ldap._tcp.domain for that. -- Hallvard ------=_NextPart_000_00B1_01C987A2.419734D0 Content-Type: application/octet-stream; name="open.c.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="open.c.patch" --- openldap-2.4.13/libraries/libldap/open.c 2008-10-31 = 13:23:58.000000000 -1000=0A= +++ openldap-2.4.13/libraries/libldap/open.c 2009-02-05 = 14:34:14.000000000 -1000=0A= @@ -212,19 +212,33 @@=0A= return( ld );=0A= }=0A= =0A= +char *=0A= +url_expand_on_srv_search ( const char *url_in )=0A= +{=0A= + // soon=0A= +=0A= + return LDAP_STRDUP( url_in );=0A= +}=0A= +=0A= =0A= int=0A= -ldap_initialize( LDAP **ldp, LDAP_CONST char *url )=0A= +ldap_initialize( LDAP **ldp, const char *url_in )=0A= {=0A= int rc;=0A= LDAP *ld;=0A= + char *url;=0A= =0A= *ldp =3D NULL;=0A= rc =3D ldap_create(&ld);=0A= if ( rc !=3D LDAP_SUCCESS )=0A= return rc;=0A= =0A= - if (url !=3D NULL) {=0A= + if (url_in !=3D NULL) {=0A= + url =3D url_expand_on_srv_search ( url_in );=0A= + if ( url =3D=3D NULL ) {=0A= + return LDAP_URL_ERR_MEM;=0A= + }=0A= +=0A= rc =3D ldap_set_option(ld, LDAP_OPT_URI, url);=0A= if ( rc !=3D LDAP_SUCCESS ) {=0A= ldap_ld_free(ld, 1, NULL, NULL);=0A= @@ -234,6 +248,7 @@=0A= if (ldap_is_ldapc_url(url))=0A= LDAP_IS_UDP(ld) =3D 1;=0A= #endif=0A= + LDAP_FREE( url );=0A= }=0A= =0A= *ldp =3D ld;=0A= ------=_NextPart_000_00B1_01C987A2.419734D0--

1 0

(ITS#5927) assertion error when using pcache
by mhardin＠symas.com 06 Feb '09

06 Feb '09

Full_Name: Matthew Hardin Version: 2.4.13 OS: Red Hat Enterprise Linux 4 i686 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (74.38.114.185) Hi All, We have an LDAP server that is proxying for Active Directory. Periodically slapd throws an assertion: slapd: [....]/ldap24/servers/slapd/schema_init.c:524: octetStringIndexer: Assertion `i > 0' failed. /etc/init.d/solserver: line 192: 6620 Aborted (core dumped) "$EXEC_DIR/$PROC" $ARGS -h "$HOST_LIST" $EXTRA_SLAPD_ARGS Howard Chu's examination of the core file showed that the remote AD server returned a member attribute with no values. This is only legal in LDAP when a client sets the attrsonly flag in its search request, and that flag was not set here. The indexer rightly asserts because pcache handed it an attribute with nothing to index. I'm not sure what the correct thing to do might be here, but it should not take down the slapd. Thanks, -Matt

1 0

Re: Docs: admin guide describes log levels inconsistently (ITS#5904)
by jclarke＠linagora.com 05 Feb '09

05 Feb '09

ando(a)sys-net.it wrote: > gavin.henry(a)gmail.com wrote: >> Ok, but wouldn't that detail be best served staying in the man page? I >> mean, what "user" will want to enter hex for loglevels? > > Actually, I wonder what user would use the decimal notation. I > introduced the hexadecimal because I find it a little more intuitive in > terms of bitwise (then I decided to move to string-based :) After giving many training sessions, I can assure you many "doing their best" users trust the decimal notation. Their managers, trying to help analyze problems, also. I know one such guy, head of infrastructure for a multinational company, with little or no background in IT, who speaks fluently in decimal OpenLDAP log levels :) Also, specifying "255" is much shorter than "Trace Packets Args Conns BER Filter Config Args". Thus, I feel it's still useful to find decimal notations in the guide. At least, to understand existing configs. On the same basis, hex could be useful. Jonathan

1 0

RE: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine)
by philippe.eychart＠informatique.gov.pf 05 Feb '09

05 Feb '09

And what do you think about : ldap://.nameOfSrvDomainSearch/ ('.' at begining of the hostname to say "use SRV record" of this domain - search domain(s) if only '.') ?... -- pe -----Message d'origine----- De : Hallvard Breien Furuseth [mailto:h.b.furuseth@usit.uio.no] Envoye : mercredi 4 fevrier 2009 05:02 A : Philippe.eychart(a)informatique.gov.pf Cc : openldap-its(a)openldap.org Objet : Re: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine) I'm not quite sure if it's a good idea to move ldap SRV lookup into ldap_initialize(), since ldap:/// is also means "this LDAP server" in referral objects and some slapd backends. Possibly some other syntax should be used to say "use SRV record", e.g. "ldap://./", or another function could work like ldap_initialize() but be more clever. Though a helper function which copies clients/tools/common.c:tool_conn_setup() functionality could in any case be useful. Also note that _ldap._tcp.domain is of limited utility outside Windows-land, because Microsoft annexed it for Active Directory: On a site which has Windows and Active Directory, _ldap._tcp.domain is normally required to refer to Active Directory. Thus if such a site uses another LDAP server for their public LDAP data, they can't _ldap._tcp.domain for that. -- Hallvard

1 0

Re: ITS#5925
by hyc＠symas.com 05 Feb '09

05 Feb '09

Pierangelo Masarati wrote: > Howard Chu wrote: >> ando(a)sys-net.it wrote: >>> If it works, then we still have an issue: operations for "o=1,o=2" will >>> probably be intercepted by the back-bdb. However, I understand that >>> since the first database is glued, it wants to know whom it's glued to. >> A fix is in HEAD. It will allow this scenario to succeed, but it will >> also allow completely broken subordinate configs to be dynamically >> created in cn=config. (configs read from slapd.conf/slapd.d will still >> be error checked appropriately.) As such, it needs a bit more thought. > > Need ldap-txn, don't we? I guess that could help. We haven't figured out yet how to propagate TXNs in syncrepl though. -- -- 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#5925
by hyc＠symas.com 05 Feb '09

05 Feb '09

ando(a)sys-net.it wrote: > If it works, then we still have an issue: operations for "o=1,o=2" will > probably be intercepted by the back-bdb. However, I understand that > since the first database is glued, it wants to know whom it's glued to. A fix is in HEAD. It will allow this scenario to succeed, but it will also allow completely broken subordinate configs to be dynamically created in cn=config. (configs read from slapd.conf/slapd.d will still be error checked appropriately.) As such, it needs a bit more thought. -- -- 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#5925
by ando＠sys-net.it 05 Feb '09

05 Feb '09

Howard Chu wrote: > ando(a)sys-net.it wrote: >> If it works, then we still have an issue: operations for "o=1,o=2" will >> probably be intercepted by the back-bdb. However, I understand that >> since the first database is glued, it wants to know whom it's glued to. > > A fix is in HEAD. It will allow this scenario to succeed, but it will > also allow completely broken subordinate configs to be dynamically > created in cn=config. (configs read from slapd.conf/slapd.d will still > be error checked appropriately.) As such, it needs a bit more thought. Need ldap-txn, don't we? 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#5792) structuralObjectClass modification w/ relax not conformant to draft-zeilenga-ldap-relax
by ando＠sys-net.it 05 Feb '09

05 Feb '09

This is now fixed in HEAD: modifications to the objectClass attribute that change the structural objectClass are automatically reflected by in the structuralObjectClass attribute. What's missing right now is that structuralObjectClass should no longer be manageable (I believe). test037 also needs to be cleaned up. 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

ITS#5925
by ando＠sys-net.it 05 Feb '09

05 Feb '09

Does it work if you change the order of the databases? I mean: +++ original dn: olcDatabase={2}ldap,cn=config olcSuffix: o=1,o=2 olcSubordinate: TRUE [...] dn: olcDatabase={3}bdb,cn=config olcSuffix: o=2 [...] +++ original +++ modified dn: olcDatabase={2}bdb,cn=config olcSuffix: o=2 [...] dn: olcDatabase={3}ldap,cn=config olcSuffix: o=1,o=2 olcSubordinate: TRUE [...] +++ modified If it works, then we still have an issue: operations for "o=1,o=2" will probably be intercepted by the back-bdb. However, I understand that since the first database is glued, it wants to know whom it's glued to. 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#5924
by ando＠sys-net.it 05 Feb '09

05 Feb '09

Should be fixed in HEAD; 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

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