openldap-bugs December 2009

openldap-bugs@openldap.org

28 participants
133 discussions

Re: (ITS#6421) simple filter with no brackets breaks slapo-dynlist(5)
by masarati＠aero.polimi.it 07 Dec '09

07 Dec '09

> masarati(a)aero.polimi.it writes: >> When a memberURL contains a simple filter with no brackets, like >> >> ldap:///ou=People,dc=example,dc=com???objectClass=person >> slapo-dynlist(5) is unable to build the composite filter needed >> for the related internal search. >> >> A fix is coming. > > Are you sure that's a good idea to fix? > > It's not a valid LDAP filter, even though OpenLDAP accepts it in > many places. That we accept it from users in tools is fair enough, > but I'm not sure it's a good idea to accept them on the server side. > > Makes them one step closer to interoperability problems if they > reach other servers that do not slap on the necessary parens. Well, the fact is that memberURL is stored in the data. As soon as we accept that value, we need to deal with it. The current behavior of slapo-dynlist(5) consists in ignoring it (the resulting filter cannot be parsed). We should rather reject values like this when written in the database, but this would probably break other applications. So I believe the fix is better than silently ignoring these values. p.

1 0

Re: (ITS#6421) simple filter with no brackets breaks slapo-dynlist(5)
by h.b.furuseth＠usit.uio.no 07 Dec '09

07 Dec '09

masarati(a)aero.polimi.it writes: > When a memberURL contains a simple filter with no brackets, like > > ldap:///ou=People,dc=example,dc=com???objectClass=person > slapo-dynlist(5) is unable to build the composite filter needed > for the related internal search. > > A fix is coming. Are you sure that's a good idea to fix? It's not a valid LDAP filter, even though OpenLDAP accepts it in many places. That we accept it from users in tools is fair enough, but I'm not sure it's a good idea to accept them on the server side. Makes them one step closer to interoperability problems if they reach other servers that do not slap on the necessary parens. -- Hallvard

1 0

(ITS#6421) simple filter with no brackets breaks slapo-dynlist(5)
by masarati＠aero.polimi.it 07 Dec '09

07 Dec '09

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (93.149.38.247) Submitted by: ando When a memberURL contains a simple filter with no brackets, like ldap:///ou=People,dc=example,dc=com???objectClass=person slapo-dynlist(5) is unable to build the composite filter needed for the related internal search. A fix is coming. p.

1 0

Re: (ITS#6419) bindconf parser doesn't apply tls-defaults as documented
by quanah＠zimbra.com 07 Dec '09

07 Dec '09

--On Monday, December 07, 2009 2:24 PM +0000 rhafer(a)suse.de wrote: > ------------------------------------ > olcSyncrepl: {0}rid=1 provider="ldap://master/" searchbase="dc=test" > type="refreshAndPersist" starttls=critical bindmethod="simple" > binddn="uid=syncrepl,dc=test" credentials="XXXXXX" > ------------------------------------ > > Question is if this is a bug in the documentation or in the code. I think > it's the latter. Howard believes this is fixed in head with servers/slapd/config.c 1.508 -> 1.509. Can you please test and let us know the result? Thanks! --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6420) test058-syncrepl-asymmetric may not clean up
by h.b.furuseth＠usit.uio.no 07 Dec '09

07 Dec '09

Full_Name: Hallvard B Furuseth Version: RE24 OS: Linux URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard test058-syncrepl-asymmetric can leave slapd processes behind on failure. It tries to kill them with the command 'KILL' instead of 'kill'. Fixed in rev 1.4 in HEAD.

1 0

(ITS#6419) bindconf parser doesn't apply tls-defaults as documented
by rhafer＠suse.de 07 Dec '09

07 Dec '09

Full_Name: Ralf Haferkamp Version: 2.4.20, HEAD OS: any URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (92.252.43.63) The bindconf parse is used in a few places where remote connection to other server are to be configured (syncrepl, back-ldap, ...). The documented behavior is (from the syncrepl section in slapd-config(5)): "The tls_reqcert setting defaults to "demand" and the other TLS settings default to the same as the main slapd TLS settings." This does however only seem to work if at least one of the "tls_" appears in the bindconfig. E.g. the following syncrepl config doesn't have any "tls_" setting and should, according to the man-page work as if "tls_reqcert=demand" was set. However the actual behavior is like "tls_reqcert=never". ------------------------------------ olcSyncrepl: {0}rid=1 provider="ldap://master/" searchbase="dc=test" type="refreshAndPersist" starttls=critical bindmethod="simple" binddn="uid=syncrepl,dc=test" credentials="XXXXXX" ------------------------------------ Question is if this is a bug in the documentation or in the code. I think it's the latter.

1 0

Re: (ITS#5810) $BACKEND selections in make test
by h.b.furuseth＠usit.uio.no 06 Dec '09

06 Dec '09

All tests now check for backends they do _not_ support, not for which ones they do support. They note why backends get exluded. ./run -b ndb all" accordingly runs the following tests which it didn't before. If any of that was intentional, ndb needs to be re-excluded. test006-acls test018-syncreplication-persist test019-syncreplication-cascade test023-refint test033-glue-syncrepl test040-subtree-rename test041-aci test043-delta-syncrepl test045-syncreplication-proxied test054-syncreplication-parallel-load test055-valregex test057-memberof-refint test058-syncrepl-asymmetric Beyond that, I seem to have confused this ITS with an "add support for back-ldif and back-null" ITS, so I'll continue that way. back-ldif passes the tests I can run here. back-null now fails 6 tests. Need to look closer to figure out if any failures are bugs (or doc bugs), which is kind of the point of the exercise. -- Hallvard

1 0

(ITS#6418) back-meta pseudorootdn generates broken idassert-bind
by h.b.furuseth＠usit.uio.no 06 Dec '09

06 Dec '09

Full_Name: Hallvard B Furuseth Version: HEAD, 6. Dec 2009 or later OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard 'cd tests; make regressions' fails because pseudorootdn in back-meta generates a broken idassert-bind. testrun/slapd.3.log complains line 55: "pseudorootdn", "pseudorootpw" are no longer supported; use "idassert-bind" and "idassert-authzFrom" instead. line 55: "idassert-bind <args>": SIMPLE needs "binddn" and "credentials". Line 55 in testrun/slapd.3.conf is: pseudorootdn "cn=manager,dc=example,dc=com" Also it looks like the slapd-meta(5) manpage should copy the 1st slapd.log complaint, instead of or in addition to the current text.

1 0

Re: (ITS#6417) Mirrormode documentation slightly misleading
by hyc＠symas.com 06 Dec '09

06 Dec '09

apm(a)mutex.dk wrote: > Full_Name: Peter Mogensen > Version: 2.4.20 > OS: any > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (95.166.36.16) > > > All of the examples about mirrormode in the admin guide tells you to set > ServerID to "1" and "2". > The extended form (ServerID<N> <URL>) is only mentioned for N-way multimaster. > > However, IF you also setup mirrormode for cn=config, The mirrormode examples don't talk about mirroring cn=config. > you need to specify > ServerID on both servers as: > > ServerID 1 ldap://server1/ > ServerID 2 ldap://server2/ > > ... so the config is the same on both server. Else your replica will not receive > all updates and servers will think changes they made them self are made by > others. > A user might be able to figure this out be thinking about what mirroring > cn=config actually requires, but it would probably some time if this is > mentioned in section 18.3.4 of the admin guide. It should be obvious that if you replicate cn=config, you will wind up with the identical configuration on the consumer as on the provider. If your configuration is not already appropriate for both the consumer and the provider then it will of course not work correctly. -- -- 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#6417) Mirrormode documentation slightly misleading
by apm＠mutex.dk 06 Dec '09

06 Dec '09

Full_Name: Peter Mogensen Version: 2.4.20 OS: any URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (95.166.36.16) All of the examples about mirrormode in the admin guide tells you to set ServerID to "1" and "2". The extended form (ServerID <N> <URL>) is only mentioned for N-way multimaster. However, IF you also setup mirrormode for cn=config, you need to specify ServerID on both servers as: ServerID 1 ldap://server1/ ServerID 2 ldap://server2/ ... so the config is the same on both server. Else your replica will not receive all updates and servers will think changes they made them self are made by others. A user might be able to figure this out be thinking about what mirroring cn=config actually requires, but it would probably some time if this is mentioned in section 18.3.4 of the admin guide.

1 0

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