openldap-bugs February 2009

openldap-bugs@openldap.org

47 participants
298 discussions

Re: (ITS#5948) jitterbug
by hyc＠symas.com 16 Feb '09

16 Feb '09

Testing followups hyc(a)OpenLDAP.org wrote: > Full_Name: me > Version: 1.0 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (76.91.220.157) > > > Checking new patches in jitterbug > -- -- 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#5948) test its
by hyc＠OpenLDAP.org 16 Feb '09

16 Feb '09

Full_Name: me Version: 1.0 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.91.220.157) Checking new patches in jitterbug

1 0

(ITS#5947) Contect CSN corruption
by quanah＠OpenLDAP.org 16 Feb '09

16 Feb '09

Full_Name: Quanah Gibson-Mount Version: 2.4.14 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) The contextCSN can get corrupted at times in 2.4.14 and previous releases. This is currently fixed in HEAD.

1 0

Re: (ITS#5756) 2.4 slapo-pcache only caches first lookup for certain templates
by toby＠inf.ed.ac.uk 16 Feb '09

16 Feb '09

On 13 Feb 2009, at 22:01, Howard Chu wrote: > toby(a)inf.ed.ac.uk wrote: > >> This looks a little strange to me... >> >> (gdb) p f2->f_choice >> Cannot access memory at address 0x39 >> (gdb) up >> #1 0x08155862 in tavl_insert (root=0x8afe590, data=0x8aefb88, >> fcmp=0x81399b0<pcache_query_cmp>, fdup=0x8154700<avl_dup_error>) >> at tavl.c:82 >> 82 cmp = fcmp( data, p->avl_data ); >> (gdb) p p->avl_data >> $1 = (void *) 0x8af62e0 >> (gdb) > > It appears you've compiled with debug and optimization, can you > please compile without optimization and try to reproduce this? Sure, will do. Cheers Toby -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

1 0

(ITS#5946) mirror mode cannot be set to FALSE when it may not be set to TRUE
by jclarke＠linagora.com 16 Feb '09

16 Feb '09

Full_Name: Jonathan Clarke Version: RE24 OS: URL: http://milopita.phillipoux.net/jonathan-clarke-20090216-bconfig.patch Submission from: (NULL) (213.41.243.192) Dear all, The value checking of "mirror mode" configuration boolean disallows setting mirror mode if the database is not a shadow. However, it also refuses setting mirror mode to "FALSE" in the same condition. Unless this is deliberate, may I suggest the above patch which allows setting mirror mode to FALSE anytime? Regards, Jonathan

1 0

Re: (ITS#5942) URI matching of "self" in add_syncrepl is incomplete
by jclarke＠linagora.com 16 Feb '09

16 Feb '09

On 14.02.2009 01:51, Howard Chu wrote: > Jonathan Clarke wrote: >> On 13.02.2009 01:23, Howard Chu wrote: >>> If you want a setup similar to test049, follow what it does. If you >>> want to something else, do otherwise. >> I am following what test049 does. Only difference is test049 starts >> slapd with "-h $URI1" (with URI1="ldap://localhost:9011/") and I start >> slapd with no -h option or a slightly different URI. This is quite >> common, I believe. > > And the slapd(8) manpage clearly states that with no -h option, it > defaults to "ldap:///". If the default suits your purpose, use it. If > not, then specify the URL you want explicitly. Yes, it's quite common to > start slapd with no -h option, because it suits the general case. This > discussion is not about the general case. > >> If you patch the test as follows, it fails: > > Obviously you should not do that. > >>> There are valid reasons to point a syncrepl consumer at the same slapd >>> (e.g., proxy syncrepl, automatic local backup/mirroring, rewriting a >>> subtree of a main database, etc.). Using the exhaustive matching that >>> serverID uses would preclude those cases from working. >> I see. I understand you don't want to break existing functionality. >> However, I still feel this is a bug, or at least that you need to "hack" >> the setup to get things working as expected. > > The docs state that "syncrepl provider" is the LDAP URI of the master > server. If you're not putting in the same URI as the master is using, > that's a config error, not a bug. Understood. Nothing is broken, and we have worked around this issue using explicit listeners to slapd -h. This behaviour did surprise me, considering the behaviour of serverID matching. May I suggest that a note of warning is included in the admin guide? For example: http://milopita.phillipoux.net/jonathan-clarke-20090216.patch >> Would I be right in assuming that in all the "valid reasons to point a >> syncrepl consumer at the same slapd" you mention, the syncrepl consumer >> uses a different base DN than the base DN of the database that the >> syncrepl consumer is configured on? If so, maybe the exhaustive matching >> that serverID uses could be used, if and only if those two base DNs are >> different? > > That sounds reasonable. Will think about it a bit more. Certainly if the > two base DNs are the same, it will cause a loop... Indeed. For what it's worth, while testing on cn=config, I noticed this having various consequences including: 1) cn=config becoming read-only (shadow) and updates returning a referral. 2) in a MMR setup, some updates not being replicated to all N servers. Regards, Jonathan

1 0

Re: (ITS#5760) attribute hiding in rwm overlay
by brett.maxfield＠gmail.com 14 Feb '09

14 Feb '09

--0016e6520602e44cff0462e14152 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Sat, Feb 14, 2009 at 11:17 PM, Pierangelo Masarati <ando(a)sys-net.it>wrote: > The missing operational attrs are my fault: I erroneously tested back-meta > with slapo-rwm's mapping, instead of the native one (which may make sense, > but not in your case). This issue should now be fixed in HEAD. > > Note that entryDN and subschemaSubentry are not leaked by slapd-meta(5): > they're actually generated by the frontend. This should be prevented now. > Please re-test. Yep all looks good now, using either the meta backend, or the ldap + rwm overlay. Good work :) --0016e6520602e44cff0462e14152 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On Sat, Feb 14, 2009 at 11:17 PM, Pierangelo Mas= arati <<a href=3D"mailto:ando@sys-net.it">ando@sys-net= .it</a>> wrote: <blockquote class=3D"gmail_quote" style=3D"bor= der-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-= left: 1ex;"> The missing operational attrs are my fault: I erroneously tested back-meta = with slapo-rwm's mapping, instead of the native one (which may make sen= se, but not in your case).  This issue should now be fixed in HEAD.<br= > Note that entryDN and subschemaSubentry are not leaked by slapd-meta(5): th= ey're actually generated by the frontend.  This should be prevente= d now.  Please re-test.</blockquote><div> Yep all looks good now, u= sing either the meta backend, or the ldap + rwm overlay. Good work :) </div></div> --0016e6520602e44cff0462e14152--

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: > Yes, sorry i was originally using meta backend & switched to ldap. Although > openldap seems to accept the DN component, but happily ignore it. Well, AFAIK it complains. You'll get a warning, unless anything worse happens: if your DN contains a comma (","), parsing would (correctly) fail. > Here the correct spelling is "organisation", i forgot to type it "wrong" for > openldap :P You know, Oscar Wilde wrote that US and UK (and the Commonwealth, I presume) have lots in common, except language :) > Just tried, the fix works perfectly with database meta, overlay rwm, and > rwm-map : (snip) > However, there is also a similar problem with database meta, and map : > > database meta > suffix "c=AU" > uri "ldap://127.0.0.1 <http://127.0.0.1:390/c=AU>:390/c=AU" > (snip) > When i run the above i get : > > ldapsearch -H ldap://127.0.0.1 <http://127.0.0.1:390/c=AU>: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 > entryDN: cn=test00496,ou=support,o=openldap,c=AU > subschemaSubentry: cn=Subschema > > # search result > search: 2 > result: 0 Success > > # numResponses: 2 > # numEntries: 1 > > Which is not (yet) showing the user attributes, and is leaking some > un-requested operational attributes. The missing operational attrs are my fault: I erroneously tested back-meta with slapo-rwm's mapping, instead of the native one (which may make sense, but not in your case). This issue should now be fixed in HEAD. Note that entryDN and subschemaSubentry are not leaked by slapd-meta(5): they're actually generated by the frontend. This should be prevented now. Please re-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

Re: (ITS#5760) attribute hiding in rwm overlay
by brett.maxfield＠gmail.com 14 Feb '09

14 Feb '09

--0016e648d4747104c80462dfbb05 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Sat, Feb 14, 2009 at 7:40 PM, Pierangelo Masarati <ando(a)sys-net.it>wrote: > 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. > Yes, sorry i was originally using meta backend & switched to ldap. Although openldap seems to accept the DN component, but happily ignore it. 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. Ditto with the typing error. Here the correct spelling is "organisation", i forgot to type it "wrong" for openldap :P 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. > Just tried, the fix works perfectly with database meta, overlay rwm, and rwm-map : database ldap suffix "c=AU" uri "ldap://127.0.0.1 <http://127.0.0.1:390/c=AU>:390/c=AU" overlay rwm rwm-map attribute cn * rwm-map attribute sn * rwm-map attribute givenName * rwm-map attribute createTimestamp * rwm-map attribute modifyTimestamp * rwm-map attribute * rwm-map objectclass inetOrgPerson * rwm-map objectclass organizationalUnit * rwm-map objectclass organization * rwm-map objectclass country * rwm-map objectclass * Eg : ldapsearch -H ldap://127.0.0.1 <http://127.0.0.1:390/c=AU>: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 objectClass: inetOrgPerson cn: test00496 givenName: test00496 sn: test00496lname createTimestamp: 20090213130450Z modifyTimestamp: 20090213130450Z # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 However, there is also a similar problem with database meta, and map : database meta suffix "c=AU" uri "ldap://127.0.0.1 <http://127.0.0.1:390/c=AU>:390/c=AU" map attribute cn * map attribute sn * map attribute givenName * map attribute * map objectclass inetOrgPerson * map objectclass organizationalUnit * map objectclass organization * map objectclass country * map objectclass * When i run the above i get : ldapsearch -H ldap://127.0.0.1 <http://127.0.0.1:390/c=AU>: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 entryDN: cn=test00496,ou=support,o=openldap,c=AU subschemaSubentry: cn=Subschema # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 Which is not (yet) showing the user attributes, and is leaking some un-requested operational attributes. Cheers Brett --0016e648d4747104c80462dfbb05 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On Sat, Feb 14, 2009 at 7:40 PM, Pierangelo Masa= rati <<a href=3D"mailto:ando@sys-net.it" target=3D"_bl= ank">ando(a)sys-net.it</a>> wrote: <blockquote class=3D"gmail_qu= ote" style=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0p= t 0.8ex; padding-left: 1ex;"> <div><a href=3D"mailto:brett.maxfield@gmail.com" target=3D"_blank">brett.ma= xfield(a)gmail.com</a> wrote: </div><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb= (204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> --0016e65206024a6d9d0462d5c0d0 Content-Type: text/plain; charset=3DISO-8859-1 Content-Transfer-Encoding: 7bit<div> I have re-tested with recent RE24 and this still happens. Assuming the config (database meta, and map instead of rwm-map shows simila= r problem) : database        ldap suffix          "c=3DAU" uri             "ldap://<a href=3D"http:= //127.0.0.1:390/c=3DAU" target=3D"_blank">127.0.0.1:390/c=3DAU</a>"<br= > </div></blockquote> You messed things up a little bit: back-ldap does not allow the DN part of = the URI.<div></div></blockquote><div> Yes, sorry i was originally using = meta backend & switched to ldap. Although openldap seems to accept the = DN component, but happily ignore it. <blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, = 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> 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 * </blockquote> </div><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid= rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> s/organisationalUnit/organizationalUnit/: this raises a warning.</blockquot= e><div> Ditto with the typing error. Here the correct spelling is= "organisation", i forgot to type it "wrong" for openld= ap :P <blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(2= 04, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Probably * an= d + (or *,+) should be expanded to the list of user or administrative attributes (respectively) by meta/rwm first, specifically<br= > those that are allowed by "map attribute" lines, before being han= ded to the real directory (helpful to performance if the backend directory has many<br= > 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. </blockquote> </div><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid= rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Well, if you don't request any attribute, those that are mapped appear.=  I've modified slapo-rwm to pass thru special attribute names (&q= uot;*", "+", "1.1") in order to defer their mappin= g when results are returned. This looks simpler than detecting whether non-= mapped attrs are filtered and, in tat case, replace "*" by the ma= pped 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.<div>= </div></blockquote><div> Just tried, the fix works perfectly with databa= se meta, overlay rwm, and rwm-map : database       ldap suffix  =         "c=3DAU" uri &= nbsp;           "lda= p://<a href=3D"http://127.0.0.1:390/c=3DAU" target=3D"_blank">127.0.0.1</a>= :390/c=3DAU" overlay rwm rwm-map attribute cn * rwm-map attribute sn * rwm-map attribute givenName * rwm-map attribut= e createTimestamp * rwm-map attribute modifyTimestamp * rwm-map attri= bute * rwm-map objectclass inetOrgPerson * rwm-map objectclass or= ganizationalUnit * rwm-map objectclass organization * rwm-map objectclass country * rwm-= map objectclass * Eg : ldapsearch -H ldap://<a href=3D"http:/= /127.0.0.1:390/c=3DAU" target=3D"_blank">127.0.0.1</a>:391 -x -b 'cn=3D= test00496,ou=3Dsupport,o=3Dopenldap,c=3DAU' '(objectclass=3D*)'= '*' '+' # extended LDIF # # LDAPv3 # base <cn=3Dtest00496,ou=3Dsupport,= o=3Dopenldap,c=3DAU> with scope subtree # filter: (objectclass=3D*)<b= r># requesting: * + # # test00496, support, openldap, AU dn: c= n=3Dtest00496,ou=3Dsupport,o=3Dopenldap,c=3DAU objectClass: inetOrgPerson cn: test00496 givenName: test00496 sn: = test00496lname createTimestamp: 20090213130450Z modifyTimestamp: 2009= 0213130450Z # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 </div></div>However, there = is also a similar problem with database meta, and map : database&nbs= p;       meta suffix   &nbs= p;      "c=3DAU" uri  &nbsp= ;          "ldap://<a hre= f=3D"http://127.0.0.1:390/c=3DAU" target=3D"_blank">127.0.0.1</a>:390/c=3DA= U" map attribute cn * map attribute sn * map attribute givenName *<b= r>map attribute * map objectclass inetOrgPerson * map objectclass= organizationalUnit * map objectclass organization * map objectclass = country * map objectclass * When i run the above i get : ldapsearch -H = ldap://<a href=3D"http://127.0.0.1:390/c=3DAU" target=3D"_blank">127.0.0.1<= /a>:391 -x -b 'cn=3Dtest00496,ou=3Dsupport,o=3Dopenldap,c=3DAU' &#3= 9;(objectclass=3D*)' '*' '+' # extended LDIF # # LDAPv3 # base <cn=3Dtest00496,ou=3Dsupport,= o=3Dopenldap,c=3DAU> with scope subtree # filter: (objectclass=3D*)<b= r># requesting: * + # # test00496, support, openldap, AU dn: c= n=3Dtest00496,ou=3Dsupport,o=3Dopenldap,c=3DAU entryDN: cn=3Dtest00496,ou=3Dsupport,o=3Dopenldap,c=3DAU subschemaSubent= ry: cn=3DSubschema # search result search: 2 result: 0 Success= # numResponses: 2 # numEntries: 1 Which is not (yet) show= ing the user attributes, and is leaking some un-requested operational attri= butes. Cheers Brett --0016e648d4747104c80462dfbb05--

1 0

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

14 Feb '09

I note there remains an inconsistency: if you request a specific operational attribute, it is not returned unless explicitly allowed by the mapping. However, if you request all operational attributes using "+", you get all. This occurs because when returning search entries, operational attributes are ignored. I think that we should either: - consistently ignore operational attributes when mapping; or - treat them like other attributes. The latter seems more appropriate to me, since mapping operational attributes could be useful when interacting with other implementations. In any case, the behavior should be consistent. It is up to system administrators to use it appropriately. 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

← Newer
1
...
9
10
11
12
13
14
15
...
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