openldap-bugs

openldap-bugs@openldap.org

1 participants
21509 discussions

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

(ITS#5679) Translucent search
by julien＠famille-garnier.com 03 Sep '08

03 Sep '08

Full_Name: Julien Version: 2.4.11 OS: Linux ldap1 2.6.18-6-xen-686 #1 SMP URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.49.133.163) It seems to be impossible to search local and remote together : a search request against one local attribute work correctly and return result 1 (ldapsearch "(local=*)") a search on a remote atttribute works fine and return result 2 (ldapsearch "(remote=*)") Finaly, a search with the local and remote attribute (ldapsearch "($(local=*)(remote=*))") only return results as the search on the local attribute and doesn't take the remote attribute. The respons is the same as result 1 In slapd.conf : translucent_local local translucent_remote remote Thanks Juju

1 0

(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

Full_Name: Michael Gwin Version: 2.3.30 OS: linux (debian etch x86_64) URL: Submission from: (NULL) (195.85.247.248) Hi, Replication of our ldap database often stops working, with pending changes stacking up and not getting processed by slurpd. /var/lib/ldap/replog (as configured in slapd.conf by the "replog" directive) fills up with entries, and slurpd doesn't pick up on them. Whilst trying to debug the issue, I noticed there were consecutive blank lines seperating entries in the replication log (both /var/lib/ldap/replog and /var/spool/slurpd/replica/slurpd.replog). Running slurpd in one shot mode on either of these files would result in any entries before the consecutive blank lines being processed, but not the entries following them. After reducing each set of consecutive blank lines to one blank line, slurpd processes all entries correctly. The replicas are set up in slapd.conf as follows: 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 NB. - the "attrs" directive of the second replica is one line in slapd.conf. - some of the (confidential) values have been changed. version info: - openldap 2.3.30 on all hosts (debian package: slapd-2.3.30-5+etch1) - all hosts are running debian etch x86_64 Not all entries are seperated by multiple blank lines. I don't know if it's ok in theory for slapd to write multiple blank lines to /var/lib/ldap/replog, but slurpd should handle them properly, or if slapd shouldn't be writing them at all. How to reproduce: Insert consecutive blank lines between two entries in a replication log, and run slurpd in one-shot mode on it. Processing stops when the consecutive blank lines are encountered.

1 0

Re: (ITS#5661) contextCSN gets corrupted on the stand by mirror
by ando＠sys-net.it 02 Sep '08

02 Sep '08

ali.pouya(a)free.fr wrote: > I made a new directory with only one contextCSN (SID=002) as you recommended, > and reproduced the contextCSN corruption problem several times. > > Example1 : > contextCSN:: 0L0NojA5MDIxMjU5NDkuNzMwMjg1WiMwMDAwMDAjMDAyIzAwMDAwMA== > > The four corrupted bytes at the beginning are : D0 BD 02 A2 (hex) > > Example2 : > contextCSN:: 4I54oTA5MDIxNTE5MTYuMjYzNDIxWiMwMDAwMDAjMDAyIzAwMDAwMA== > > The four corrupted bytes at the beginning are : E0 8E 78 A1 (hex) > > > I insist on the fact that the problem heppens ONLY if I use TWO syncrepl > directives as recommended in the Admin Guide. > If I use only ONE syncrepl directive, I don't reproduce the problem and the > mirrors get synchronized correctly (whichever mirror side I use for writing). > Also the problem happens on the stand by mirror only when therer are write > operations on the active mirror (> 1000 writes per minute). > > I do not understand the interest of using TWO syncrepl directives for > mirrormode. Well, going back to your initial posting, I think you are somehow correct. Rather than not seeing the point of having two syncrepl statements (of which only one is supposed to be active), I see it as an inconsistent and potentially dangerous configuration. In fact, the only advantage of having two syncrepl statements is related to being able to share the same configuration among two symmetric servers (mirror mode, multimaster, ...), using the serverID directive to determine what is the "right" one. But in that case, you'd need to have multiple serverID directives as well, with the URI field set. I set up a test system with your configuration, and loaded it very heavily, while running the server that's supposed to screw up under valgrind. I haven't seen any issue yet, though. 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:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs