openldap-bugs

openldap-bugs@openldap.org

1 participants
21063 discussions

(ITS#4829) slapd-config should create olcDbDirectory
by ghenry＠suretecsystems.com 02 Feb '07

02 Feb '07

Full_Name: Gavin Henry Version: N/A OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Dear All, If we are to suppose that slapd-config is to provide 100% remote configuration, then directories should be created as set in: olcDbDirectory set_lg_dir Questions/Needs: 1. How to handle existing directories on mkdir? 2. Some global cn=config setting to say what cn=config is allowed to do 3. Plus many more I'm sure. Thanks, Gavin. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/

1 0

syncrepl only works as rootdn
by Christopher Cowart 02 Feb '07

02 Feb '07

Hello, I have 3 installations of openldap-server-2.3.33 running on FreeBSD 6.1-REL: ldap-master, ldap1, ldap2. I am using syncrepl to replicate ldap-master to ldap1 and ldap2. The replicated directory is missing entire ou branches in my tree. I have created the following objects in my directory: cn=syncrepl-ldap1,dc=example,dc=com cn=syncrepl-ldap2,dc=example,dc=com I've made the following configurations on the provider: | access to * | by dn.regex="cn=syncrepl-(ldap1|ldap2),dc=example,dc=com" read | by * break | | # More ACLs Follow | | # For Sync Replication | overlay syncprov | syncprov-checkpoint 100 10 | syncprov-sessionlog 100 And on the consumer (ldap1): | # Sync Replication | syncrepl rid=001 | provider=ldaps://ldap-master.example.com/ | type=refreshAndPersist | interval=00:01:00:00 | searchbase="dc=example,dc=com" | scope=sub | schemachecking=off | bindmethod=simple | binddn="cn=syncrepl-ldap1,dc=example,dc=com" | credentials=supersecret Now, when I query: $ ldapsearch -D 'cn=admin,dc=example,dc=com' -Wx -H \ 'ldaps://ldap-master.example.com/' '(ou=*)' ou | grep '^ou' | ou: People | ou: Roaming | ou: Group | ou: Reshall People | ou: Reshall Group | ou: Services | ou: System Accounts | ou: System Groups But: $ ldapsearch -D 'cn=admin,dc=example,dc=com' -Wx -H \ 'ldaps://ldap1.example.com/' '(ou=*)' ou | grep '^ou' | ou: People | ou: Roaming | ou: Group | ou: Reshall People | ou: Reshall Group | ou: Services You'll notice that the "System Accounts" and "System Groups" ou's are not visible in the replicated directory. Odd. Next, I run the query: $ ldapsearch -D 'cn=admin,dc=example,dc=com' -Wx -H \ 'ldaps://ldap-master.example.com/' '(objectClass=*)' ou | grep '^ou' | ou: People | ou: Roaming | ou: Group | ou: Reshall People | ou: Reshall Group | ou: Services | ou: System Accounts | ou: System Groups But the syncrepl process is binding as "cn=syncrepl-ldap1": $ ldapsearch -D 'cn=syncrepl-ldap1,dc=example,dc=com' -Wx -H \ 'ldaps://ldap-master.example.com/' '(objectClass=*)' ou | grep '^ou' | ou: People | ou: Roaming | ou: Group | ou: Reshall People | ou: Reshall Group | ou: Services So, if I configure the consumer to bind as my rootdn (cn=admin), the entire directory gets replicated (as the final ldapsearch's would imply). My question is how do I properly configure the ACLs here? Shouldn't the 'read *' at the beginning of my ACL declarations match? I'm attaching the full list of my ACLs to the message. Thanks for any help or pointers you can offer. -- Chris Cowart Network and Infrastructure Systems Administrator RSSP-IT, UC Berkeley "May all your pushes be popped"

2 1

Re: (ITS#4828) test032-chain failed: comparison failed - chained search didn't succeed
by hyc＠symas.com 01 Feb '07

01 Feb '07

ando(a)sys-net.it wrote: > hyc(a)symas.com wrote: >> Howard Chu wrote: >>> michael.stroeder(a)t-systems.com wrote: >>>> Full_Name: Michael Ströder >>>> Version: HEAD >>>> OS: opensuse Linux 10.2 >>>> URL: ftp://ftp.openldap.org/incoming/ >>>> Submission from: (NULL) (83.124.17.145) >>> Hmm, all tests are passing for me right now. >>> >> Never mind. I just refreshed back-ldap and back-meta and test032 is failing >> for me now too. > > I've recently added some diagnostics messages to proxy failures, to > indicate the reason of returning LDAP_UNAVAILABLE upon failed attempts > to contact the remote target. Apparently, slapo-chain(5) leaves 'round > some sr_text while setting sr_err to LDAP_SUCCESS. I'll check it. Looks fine now, thanks. -- -- Howard Chu Chief Architect, 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#4828) test032-chain failed: comparison failed - chained search didn't succeed
by ando＠sys-net.it 01 Feb '07

01 Feb '07

ando(a)sys-net.it wrote: > I've recently added some diagnostics messages to proxy failures, to > indicate the reason of returning LDAP_UNAVAILABLE upon failed attempts > to contact the remote target. Apparently, slapo-chain(5) leaves 'round > some sr_text while setting sr_err to LDAP_SUCCESS. I'll check it. Fixed in HEAD, please test. BTW, the bug showed up essentially because the output was sort of incorrectly diverted to the file that gets checked. Generally speaking, it might impact re23 as well, although that test is currently succeeding. p.

1 0

Re: (ITS#4828) test032-chain failed: comparison failed - chained search didn't succeed
by ando＠sys-net.it 01 Feb '07

01 Feb '07

hyc(a)symas.com wrote: > Howard Chu wrote: >> michael.stroeder(a)t-systems.com wrote: >>> Full_Name: Michael Ströder >>> Version: HEAD >>> OS: opensuse Linux 10.2 >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (83.124.17.145) >> Hmm, all tests are passing for me right now. >> > Never mind. I just refreshed back-ldap and back-meta and test032 is failing > for me now too. I've recently added some diagnostics messages to proxy failures, to indicate the reason of returning LDAP_UNAVAILABLE upon failed attempts to contact the remote target. Apparently, slapo-chain(5) leaves 'round some sr_text while setting sr_err to LDAP_SUCCESS. I'll check it. p.

1 0

Re: (ITS#4828) test032-chain failed: comparison failed - chained search didn't succeed
by hyc＠symas.com 01 Feb '07

01 Feb '07

Howard Chu wrote: > michael.stroeder(a)t-systems.com wrote: >> Full_Name: Michael Ströder >> Version: HEAD >> OS: opensuse Linux 10.2 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (83.124.17.145) > > Hmm, all tests are passing for me right now. > Never mind. I just refreshed back-ldap and back-meta and test032 is failing for me now too. -- -- Howard Chu Chief Architect, 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#4828) test032-chain failed: comparison failed - chained search didn't succeed
by hyc＠symas.com 01 Feb '07

01 Feb '07

michael.stroeder(a)t-systems.com wrote: > Full_Name: Michael Ströder > Version: HEAD > OS: opensuse Linux 10.2 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (83.124.17.145) Hmm, all tests are passing for me right now. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#4828) test032-chain failed: comparison failed - chained search didn't succeed
by michael.stroeder＠t-systems.com 01 Feb '07

01 Feb '07

Full_Name: Michael Ströder Version: HEAD OS: opensuse Linux 10.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.124.17.145) >>>>> Starting test032-chain ... running defines.sh Running slapadd to build slapd database... Starting first slapd on TCP/IP port 9011... Starting second slapd on TCP/IP port 9012... Using ldapsearch to check that first slapd is running... Using ldapsearch to check that second slapd is running... Testing ldapsearch as anonymous for "dc=example,dc=com" on port 9011... Filtering ldapsearch results... Filtering original ldif used to create database... Comparing filter output... Reading the referral entry ou=Other,dc=example,dc=com as anonymous on port 9011... Filtering ldapsearch results... Filtering original ldif used to create database... Comparing filter output... comparison failed - chained search didn't succeed >>>>> ./scripts/test032-chain failed (exit 1) make[2]: *** [bdb-mod] Error 1 make[2]: Leaving directory `/home/michael/src/openldap-HEAD/ldap/tests' make[1]: *** [test] Error 2 make[1]: Leaving directory `/home/michael/src/openldap-HEAD/ldap/tests' make: *** [test] Error 2

1 0

Re: (ITS#4827) test019-syncreplication-cascade
by kurt＠OpenLDAP.org 01 Feb '07

01 Feb '07

On Feb 1, 2007, at 4:26 AM, hyc(a)symas.com wrote: > Fixed now. Confirmed. Thanks, Kurt

1 0

Re: (ITS#4827) test019-syncreplication-cascade
by hyc＠symas.com 01 Feb '07

01 Feb '07

Fixed now. The fix also triggered another problem along the lines of ITS#4820; test017's comparison failed because the modifiersName attribute wasn't in the same position on the producer and the consumer. I've hacked that problem by always applying the modifiersName update. kurt(a)OpenLDAP.org wrote: > Full_Name: Kurt Zeilenga > Version: HEAD > OS: MacOSX 10.4.8 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (71.80.218.136) > > > Recent builds fail test 18: > Comparing retrieved entries from master and R1 slave... > Comparing retrieved entries from master and R2 slave... > test failed - master and R2 slave databases differ >>>>>> ./scripts/test019-syncreplication-cascade failed (exit 1) > > % diff -u testrun/server[13].flt > --- testrun/server1.flt 2007-01-31 12:31:55.000000000 -0800 > +++ testrun/server3.flt 2007-01-31 12:32:00.000000000 -0800 > @@ -66,6 +66,7 @@ > seeAlso: cn=All Staff,ou=Groups,dc=example,dc=com > userPassword:: Ympvcm4= > homePostalAddress: 19923 Seven Mile Rd. $ South Lyon, MI 49999 > +drink: Iced Tea > description: Hiker, biker > title: Director, Embedded Systems > postalAddress: Info Tech Division $ 535 W. William St. $ Anytown, MI 48103 > @@ -74,8 +75,6 @@ > pager: +1 313 555 4474 > facsimileTelephoneNumber: +1 313 555 2177 > telephoneNumber: +1 313 555 0355 > -drink: Iced Tea > -drink: Mad Dog 20/20 > > dn: cn=Dorothy Stevens,ou=Alumni Association,ou=People,dc=example,dc=com > objectClass: OpenLDAPperson > > > . > -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc Chief Architect, OpenLDAP http://www.openldap.org/project/

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