openldap-bugs

openldap-bugs@openldap.org

1 participants
21002 discussions

Re: (ITS#5680) pcache not returning cached entries
by ando＠sys-net.it 03 Sep '08

03 Sep '08

Howard Chu wrote: >> Right. I'll fix it. > > Actually... I think the original patch was fine. I meant, checking the > remote server's subschema should be optional... ;) Too late :) well, I don't like too much the idea of having yet another fine-tune parameter in config, but this change could impact users that need to proxy well-configured systems and, say, cache entries with huge member lists or so... so better make diversion from original behavior optional, if the original behavior is safe in sane setups. 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#5681) canonicalize undef objectClass names?
by ando＠sys-net.it 03 Sep '08

03 Sep '08

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando Currently, slapd canonicalizes undef (or proxied) attribute names by making them uppercased. It should do the same with undef objectClass names. A patch is coming. p.

1 0

Re: (ITS#5680) pcache not returning cached entries
by ando＠sys-net.it 03 Sep '08

03 Sep '08

hyc(a)symas.com wrote: >>>> The backend server is a Novell eDirectory and the proxy don't have >>>> information about the complete schema. >>> I suspect the remote server is returning an objectClass that is unknown >>> to the proxy; for example, ndsLoginProperties. So, not ours :) >> I could reproduce the issue by caching an entry with an objectClass not >> known to the proxy :). So the "right" solution consists in fixing the >> proxy's schema. Of course, OpenLDAP could inform the proxy >> administrator with some intelligible message or, even better, try to >> repair itself (e.g. by checking the remote server's subschemaSubentry). >> > Probably not a good idea to do that automagically. Perhaps with a config > switch. Right. I'll fix it. > Also, not a good idea to import miscellaneous foreign schema globally; > we should implement per-database schema instead. I think per-database subschema has been on the todolist since ever or so :) 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#5680) pcache not returning cached entries
by hyc＠symas.com 03 Sep '08

03 Sep '08

ando(a)sys-net.it wrote: > ando(a)sys-net.it wrote: >> quanah(a)zimbra.com wrote: >> >>> test_filter returned LDAP_INVALID_SYNTAX. >> I think the culprit of the issue is here ^^^ >> >> > | dn: cn=blank,o=Example >> > | queryId: c975e84a-0e16-102d-8355-4be7c415200f >> > | queryId: 9b7f1afa-0e17-102d-8bae-452c11e3ff2d >> > | objectClass: inetOrgPerson >> > | objectClass: organizationalPerson >> > | objectClass: person >> > | objectClass: ndsLoginProperties >> > | objectClass: top >> > >>> The backend server is a Novell eDirectory and the proxy don't have >>> information about the complete schema. >> I suspect the remote server is returning an objectClass that is unknown >> to the proxy; for example, ndsLoginProperties. So, not ours :) > > I could reproduce the issue by caching an entry with an objectClass not > known to the proxy :). So the "right" solution consists in fixing the > proxy's schema. Of course, OpenLDAP could inform the proxy > administrator with some intelligible message or, even better, try to > repair itself (e.g. by checking the remote server's subschemaSubentry). > Probably not a good idea to do that automagically. Perhaps with a config switch. Also, not a good idea to import miscellaneous foreign schema globally; we should implement per-database schema instead. -- -- 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#5680) pcache not returning cached entries
by ando＠sys-net.it 03 Sep '08

03 Sep '08

Probably, a more consistent behavior would be to refuse caching queries containing entries that do not pass normalization. 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#5680) pcache not returning cached entries
by ando＠sys-net.it 03 Sep '08

03 Sep '08

ando(a)sys-net.it wrote: > quanah(a)zimbra.com wrote: > >> test_filter returned LDAP_INVALID_SYNTAX. > > I think the culprit of the issue is here ^^^ > > > | dn: cn=blank,o=Example > > | queryId: c975e84a-0e16-102d-8355-4be7c415200f > > | queryId: 9b7f1afa-0e17-102d-8bae-452c11e3ff2d > > | objectClass: inetOrgPerson > > | objectClass: organizationalPerson > > | objectClass: person > > | objectClass: ndsLoginProperties > > | objectClass: top > > >> The backend server is a Novell eDirectory and the proxy don't have >> information about the complete schema. > > I suspect the remote server is returning an objectClass that is unknown > to the proxy; for example, ndsLoginProperties. So, not ours :) I could reproduce the issue by caching an entry with an objectClass not known to the proxy :). So the "right" solution consists in fixing the proxy's schema. Of course, OpenLDAP could inform the proxy administrator with some intelligible message or, even better, try to repair itself (e.g. by checking the remote server's subschemaSubentry). 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#5680) pcache not returning cached entries
by ando＠sys-net.it 03 Sep '08

03 Sep '08

quanah(a)zimbra.com wrote: > test_filter returned LDAP_INVALID_SYNTAX. I think the culprit of the issue is here ^^^ > | dn: cn=blank,o=Example > | queryId: c975e84a-0e16-102d-8355-4be7c415200f > | queryId: 9b7f1afa-0e17-102d-8bae-452c11e3ff2d > | objectClass: inetOrgPerson > | objectClass: organizationalPerson > | objectClass: person > | objectClass: ndsLoginProperties > | objectClass: top > > The backend server is a Novell eDirectory and the proxy don't have > information about the complete schema. I suspect the remote server is returning an objectClass that is unknown to the proxy; for example, ndsLoginProperties. So, not ours :) 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#5680) pcache not returning cached entries
by ando＠sys-net.it 03 Sep '08

03 Sep '08

quanah(a)zimbra.com wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.10 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.29.239) > > > As reported on the Debian bug tracker as bug#497697. Works as intended here (HEAD & re24). I note that in the reported slapd.conf objectClass is not indexed for the proxy database; maybe someone mucked with index statements? 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#5680) pcache not returning cached entries
by quanah＠zimbra.com 03 Sep '08

03 Sep '08

1 0

Re: (ITS#5678) slurpd stops processing the replication log if consecutive blank lines are encountered
by mgwin＠escp-eap.net 03 Sep '08

03 Sep '08

I missed a few lines from the replica definitions in slapd.conf. Not sure if it matters much, but for the sake of completeness, here are the full replica definitions (with some information obfuscated): replogfile /var/lib/ldap/replog replica uri=ldap://host1.domain.tld:389 starttls=critical bindmethod=simple binddn="cn=replicationuser,o=MYORG" credentials=XYZ replica uri=ldaps://host2.domain.tld:636 bindmethod=simple binddn="cn=replicationuser,o=MYORG" credentials=XYZ attrs=account,MYORGGroup,MYORGPerson,organization,organizationalRole,organizationalUnit,posixAccount,posixGroup,simpleSecurityObject,top suffix="ou=ou3,ou=ou1,o=MYORG" suffix="ou=ou4,ou=ou1,o=MYORG" suffix="ou=ou5,ou=ou2,o=MYORG" suffix="ou=ou6,ou=ou2,o=MYORG" suffix="ou=ou7,o=MYORG" suffix="ou=ou8,o=MYORG"

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