openldap-bugs

openldap-bugs@openldap.org

1 participants
20963 discussions

(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

Re: (ITS#6406) back-ldif fails test043-delta-syncrepl
by h.b.furuseth＠usit.uio.no 05 Dec '09

05 Dec '09

Howard Chu writes: >> With back-ndb, I imagine somthing like an SQL 'ORDER BY<reqStart or >> entryCSN>' will do the trick, if it isn't already handled. > > back-ndb also orders by entryID. Thanks, I'll note that for the test. >> Anyway, if I have understood this correctly, this requirement needs to >> be documented, and it looks rather fragile anyway. Only databases >> supporing this use of accesslog. The admin must not slapcat the >> accesslog, rearrange it (maybe he's looking for changes to something >> specific), and then slapadd it back. Not something which would happen >> every day, but there's no reason people _wouldn't_ do it either. LDAP >> defines elements as unordered, after all. > > I thought it was obvious; a "log" is an ordered transcript of events. > If you rearrange the sequence of events then you invalidate it. No, it's not obvious that the order of slapadding entires has any influence on their order returned from search. The LDAP spec doesn't say so, nor man 5 slapd-bdb, nor do the syncprov or accesslog manpages say that they need it. Obviously *something* need to take care of ordering, but as far as the user knows that could be accesslog or syncprov. Actually, the slapo-accesslog(5) suggestion to index reqStart may give a careful reader a hint about how the ordering happens. So anyway, syncprov needs to document that it doesn't ensure this ordering but depends on the admin getting it right. Long-term I'd also like some way for syncprov to catch errors if the admin does get tings like this wrong. E.g. let accesslog require an attribute to be set in the log database which promises ordering. slapd startup would fail if the database doesn't confirm that it can honor this flag, and slapadd of entries out of CSN order would also fail. Unless that breaks what you say about refresh below... anyway, all that will have to wait for RE25 or later. -- Hallvard

1 0

Re: (ITS#6416) back-null + back-ldap + idassert spins or hangs
by hyc＠symas.com 05 Dec '09

05 Dec '09

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD > OS: Linux x86_64 > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > slapd spins when current HEAD's ./run -b null test028-idassert gets to: > "Testing ldapwhoami as bjorn, dn:uid=bjorn,ou=People,o=Example,c=US..." > > Here is slapd.conf for reduced case which hangs with: > ldapwhoami -xH localhost:9011 \ > -D uid=foo,cn=users -w secret -e \!authzid=dn:uid=foo,cn=id > Possibly I've created a loop somewhere but I don't know where: Obviously you've created a loop. Your server is running on localhost:9011 and you've defined a back-ldap pointing to localhost:9011. You run a query that causes a lookup on the back-ldap cn=id database, and in the absence of any rewrite rules to alter that lookup, it will simply loop back on itself trying to search cn=id. This is an invalid config, this ITS is invalid and will be closed. > include schema/core.schema > authz-policy from > > database null > suffix "cn=users" > bind on > > database null > suffix "cn=admin" > bind on > > database ldap > suffix "cn=id" > uri "ldap://localhost:9011/" > idassert-bind binddn="cn=admin" credentials="xyzzy" mode=self > > > slapd creates a bunch of connections to itself (according to loglevel 256) > and then loops, with the log repeating this paragraph: > > ** ld 0x3ad3930 Outstanding Requests: > * msgid 1, origid 1, status InProgress > outstanding referrals 0, parent count 0 > ld 0x3ad3930 request count 1 (abandoned 0) > ** ld 0x3ad3930 Response Queue: > Empty > ld 0x3ad3930 response count 0 > ldap_chkResponseList ld 0x3ad3930 msgid 1 all 1 > ldap_chkResponseList returns ld 0x3ad3930 NULL > ldap_int_select > ldap_result ld 0x3ad3930 msgid 1 > wait4msg ld 0x3ad3930 msgid 1 (timeout 100000 usec) > wait4msg continue ld 0x3ad3930 msgid 1 all 1 > ** ld 0x3ad3930 Connections: > * host: localhost port: 9011 (default) > refcnt: 2 status: Connected > last used: Fri Dec 4 19:48:32 2009 > > > -- -- 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#6406) back-ldif fails test043-delta-syncrepl
by hyc＠symas.com 05 Dec '09

05 Dec '09

h.b.furuseth(a)usit.uio.no wrote: > I wrote: >> This often fails (producer and consumer databases differ): >> SLAPD_DEBUG=0x4105 ./run -b ldif test043-delta-syncrepl >> when configured with --enable-accesslog. > > Apparently syncprov sends changes in the order it gets them from an > accesslog search, so it needs accesslog to return change records ordered > by change CSN. Otherwise the consumer discards changes, complaining: > > do_syncrep2: rid=001 CSN too old, ignoring 20091130202958.564835Z#000000#000#000000 > > This works with hdb/bdb under normal operation: They return entries > ordered by entry ID, which always increases as new entries are added. > It works out since something (syncrepl or accesslog) serializes writes > so change records are added to the log database in the same order as > the changes are applied to the main database. > > With back-ndb, I imagine somthing like an SQL 'ORDER BY<reqStart or > entryCSN>' will do the trick, if it isn't already handled. back-ndb also orders by entryID. > back-ldif does not support this: It returns changes memcmp-ordered > by normalized reqStart. Normalization "<t>.210000Z" -> "<t>.21Z" > makes that value sort after "<t>.219999Z". > Anyway, if I have understood this correctly, this requirement needs to > be documented, and it looks rather fragile anyway. Only databases > supporing this use of accesslog. The admin must not slapcat the > accesslog, rearrange it (maybe he's looking for changes to something > specific), and then slapadd it back. Not something which would happen > every day, but there's no reason people _wouldn't_ do it either. LDAP > defines elements as unordered, after all. I thought it was obvious; a "log" is an ordered transcript of events. If you rearrange the sequence of events then you invalidate it. > What happens if a consumer does a full refresh from a provider without > accesslog, and is also running syncprov with accesslog? Do these > changes end up in the consumer accesslog? I don't suppose the refresh > can send entries by entryCSN order, since there may be children that > were changed before parents. True, the changes will be written out of order. But while a consumer is in refresh mode, it won't be updating its contextCSN. And while the contextCSN doesn't change, the provider won't be sending CSNs in the cookie it sends with any changes. (And the cookie CSN is what matters, not any entryCSN in the entry's attributes.) So any downstream consumer will accept these changes implicitly, since there is no CSN to check. -- -- 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#6416) back-null + back-ldap + idassert spins or hangs
by h.b.furuseth＠usit.uio.no 05 Dec '09

05 Dec '09

h.b.furuseth(a)usit.uio.no writes: > Here is slapd.conf for reduced case which hangs with: > ldapwhoami -xH localhost:9011 \ > -D uid=foo,cn=users -w secret -e \!authzid=dn:uid=foo,cn=id To clarify, that slapd.conf if for a single slapd at port 9011, matching the URI of its own "database ldap". -- Hallvard

1 0

Re: (ITS#6406) back-ldif fails test043-delta-syncrepl
by h.b.furuseth＠usit.uio.no 05 Dec '09

05 Dec '09

I wrote: > This often fails (producer and consumer databases differ): > SLAPD_DEBUG=0x4105 ./run -b ldif test043-delta-syncrepl > when configured with --enable-accesslog. Apparently syncprov sends changes in the order it gets them from an accesslog search, so it needs accesslog to return change records ordered by change CSN. Otherwise the consumer discards changes, complaining: do_syncrep2: rid=001 CSN too old, ignoring 20091130202958.564835Z#000000#000#000000 This works with hdb/bdb under normal operation: They return entries ordered by entry ID, which always increases as new entries are added. It works out since something (syncrepl or accesslog) serializes writes so change records are added to the log database in the same order as the changes are applied to the main database. With back-ndb, I imagine somthing like an SQL 'ORDER BY <reqStart or entryCSN>' will do the trick, if it isn't already handled. back-ldif does not support this: It returns changes memcmp-ordered by normalized reqStart. Normalization "<t>.210000Z" -> "<t>.21Z" makes that value sort after "<t>.219999Z". Anyway, if I have understood this correctly, this requirement needs to be documented, and it looks rather fragile anyway. Only databases supporing this use of accesslog. The admin must not slapcat the accesslog, rearrange it (maybe he's looking for changes to something specific), and then slapadd it back. Not something which would happen every day, but there's no reason people _wouldn't_ do it either. LDAP defines elements as unordered, after all. What happens if a consumer does a full refresh from a provider without accesslog, and is also running syncprov with accesslog? Do these changes end up in the consumer accesslog? I don't suppose the refresh can send entries by entryCSN order, since there may be children that were changed before parents. -- Hallvard

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