openldap-technical

openldap-technical@openldap.org

14 participants
9796 discussions

Re: mmr pair stops replicating: "consumer state is newer than provider"
by Quanah Gibson-Mount 05 Jul '17

05 Jul '17

--On Thursday, June 29, 2017 1:41 PM -0400 btb <btb(a)bitrate.net> wrote: > > > On 6/29/17 11:15 AM, Quanah Gibson-Mount wrote: >> --On Thursday, June 29, 2017 2:12 AM -0400 btb <btb(a)bitrate.net> wrote: >> >>> i see, thanks. i tested this, and did a modify on each, but didn't see >>> replication resume. emulating the syncrepl connection with a manual >>> search against each master, there do seem to be accesslog entries now, >>> on both masters: >> >> You may have to restart the consumers (I did when I ran into this). > > i did try a restart on both, but they returned to the same state > >> Also, there are 2 sets of CSNs per master that you need to examine -- >> The CSNs in your database root (i.e., dc=example,dc=org) and your >> accesslog root. > > that would be these, right? > > dsa1 cn=accesslog: > 20161019002438.652359Z#000000#000#000000 > 20170521175113.974560Z#000000#002#000000 > 20170530214415.204052Z#000000#001#000000 > > dsa1 dc=example,dc=org: > 20170520031415.276678Z#000000#000#000000 > 20170530214231.171959Z#000000#002#000000 > 20170530214415.204052Z#000000#001#000000 > > dsa2 cn=accesslog: > 20170520031415.276678Z#000000#000#000000 > 20170521175113.974560Z#000000#002#000000 > 20170628034119.327974Z#000000#001#000000 > > dsa2 dc=example,dc=org: > 20170520031415.276678Z#000000#000#000000 > 20170619014933.531051Z#000000#002#000000 > 20170628034119.327974Z#000000#001#000000 > > why are there three per db, and which is suppose to match which? wow, that's a mess. So #000# is serverID 0, which would be for any entries prior to moving to MMR. The fact that you have different values for #000# on dsa1 accesslog vs the other 3 databases is disturbing. It would appear DSA1 is serverID 1, and its CSNs make sense: 20170530214415.204052Z#000000#001#000000 20170530214415.204052Z#000000#001#000000 However, there's someting serious wrong with dsa2 (assuming it is serverID 2): 20170521175113.974560Z#000000#002#000000 20170619014933.531051Z#000000#002#000000 As this implies the primary DB received a write on 2017/06/19 @ 01:49:33, but the accesslog has not recorded this change, as it says the last time there was a write op to the accesslog DB on #002# was 2017/05/21 @ 17:51:13, nearly a month earlier. So it doesn't seem to think you've done a write op directly against serverID 002. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: package OpenLDAP and lmdb
by Howard Chu 04 Jul '17

04 Jul '17

Michael Ströder wrote: > HI! > > What's the recommendation for keeping package builds for OpenLDAP and mdb_* tools in sync? > > Use the OpenLDAP 2.4.x release and build from there? Sure, the latest LMDB release is always included in the latest OpenLDAP 2.4 release. > AFAICS LTB builds are made like this but they use a different prefix and therefore don't > have a collision with packages coming from OS package upstream. > > Ciao, Michael. > > -- -- 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

package OpenLDAP and lmdb
by Michael Ströder 04 Jul '17

04 Jul '17

HI! What's the recommendation for keeping package builds for OpenLDAP and mdb_* tools in sync? Use the OpenLDAP 2.4.x release and build from there? AFAICS LTB builds are made like this but they use a different prefix and therefore don't have a collision with packages coming from OS package upstream. Ciao, Michael.

1 0

Re: [Q] can I replicate several branches to the same slave from one master?
by Quanah Gibson-Mount 03 Jul '17

03 Jul '17

--On Friday, June 30, 2017 9:08 AM +0300 Zeus Panchenko <zeus(a)ibs.dn.ua> wrote: > Quanah Gibson-Mount <quanah(a)symas.com> wrote: >> >> Wouldn't it be simpler to define ACLs on the master that limit what >> the replication identity has access to that matches your filters? >> > > emm ... I was sure I can not do that on the master side ... just I try > do that, I receive full data ... Then likely your ACLs were incorrect? > looks like some more permittive acl works for the replica ... can I > somehow know which acl matched the replica? But I was trying to place > replABC ACLs to the end of the list and still was not able to limit data > according the filter I suggest reading the slapd.access(5) man page and the OpenLDAP Admin guide. As clearly noted in the documentation, ACLs (generally) stop processing on the *first* match. So, depending on your ACLs, adding your ACLS at the end of the list probably meant they were never evaluated. >> I would also note that your stanza limiting what attrs are replicated >> is missing the operational attributes that are necessary for sync >> replication to function, so I would fully expect errors. > > do you mean entryCSN and entryUUID ? Yes, sorry, I missed them at the start of the list of attributes. ;) So that part seems ok. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Deleting old replicas on consumer?
by Prentice Bisbal 30 Jun '17

30 Jun '17

If I delete a replication consumer, do I need to delete any replication-related data for that consumer's replication on the producer? If so, how? Prentice

1 0

Re: [Q] can I replicate several branches to the same slave from one master?
by Quanah Gibson-Mount 30 Jun '17

30 Jun '17

--On Tuesday, June 27, 2017 2:04 AM -2100 Zeus Panchenko <zeus(a)ibs.dn.ua> wrote: > syncrepl rid=123 > provider=ldap://master.example:389 > starttls=critical > searchbase="ou=ABC,ou=Sendmail,dc=example" > bindmethod=simple > binddn="uid=replABC,ou=repl,dc=example" > credentials="***" > tls_cacert=/usr/local/etc/openldap/ssl/ca.crt > tls_cert=/usr/local/etc/openldap/ssl/ABC.crt > tls_key=/usr/local/etc/openldap/ssl/ABC.key > tls_reqcert=try > type=refreshAndPersist > retry="60 +" > logbase="cn=example-accesslog" > logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" > syncdata=accesslog > - ---[ slave configuration quotation end ]---------------------------- Wouldn't it be simpler to define ACLs on the master that limit what the replication identity has access to that matches your filters? I would also note that your stanza limiting what attrs are replicated is missing the operational attributes that are necessary for sync replication to function, so I would fully expect errors. As Andrew already noted (and you later fixed), syncrepl RIDs are required to be unique, as documented in the man page. Given that OpenLDAP functions off of CSN values, partial replication is tricky, as the master can then have a contextCSN that does not correspond to anything in a partially replicated database, depending on how you slice it. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: [Q] can I replicate several branches to the same slave from one master?
by Quanah Gibson-Mount 30 Jun '17

30 Jun '17

--On Friday, June 30, 2017 12:48 AM +0300 Zeus Panchenko <zeus(a)ibs.dn.ua> wrote: > ---[ slave slapd.log quotation start ]-------------------------------- > Jun 29 22:45:30 ABC slapd[12593]: do_syncrep2: rid=000 > LDAP_RES_SEARCH_RESULT (53) Server is unwilling to perform Jun 29 > 22:45:30 ABC slapd[12593]: do_syncrep2: rid=000 (53) Server is unwilling > to perform Jun 29 22:45:30 ABC slapd[12593]: do_syncrepl: rid=000 rc -2 > retrying ---[ slave slapd.log quotation end > ]-------------------------------- And what does the master say? --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: Catch-22: Need to change olcRootDN
by Quanah Gibson-Mount 30 Jun '17

30 Jun '17

--On Thursday, June 29, 2017 7:27 PM -0400 Prentice Bisbal <pbisbal(a)pppl.gov> wrote: > Thanks. One more related question: are special rules needed for the > config information, like an ACL just for cn=config so the ldapadmins can > make changes w/o needing a rootDN? You can certainly add an olcAccess rule to the cn=config db that allows DNs from outside of cn=config to make modifications. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Catch-22: Need to change olcRootDN
by Quanah Gibson-Mount 30 Jun '17

30 Jun '17

--On Thursday, June 29, 2017 7:08 PM -0400 Prentice Bisbal <pbisbal(a)pppl.gov> wrote: > Actually, let me expand that question. I need to make changes to > everything in cn=config after switching to dynamic configuration. Is it > possible to do that without starting from scratch with a new slapd.conf > file. I deleted the slapd.conf I was working with because I didn't need > it anymore, and I was afraid a coworker not familiar with the dynamic > config would try to make changes to slapd.conf, and expect them to work. Use slapcat to export it. Use slapadd to import. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Catch-22: Need to change olcRootDN
by Prentice Bisbal 30 Jun '17

30 Jun '17

I got myself into a bit a of a Catch-22. I need to change the RootDN, but I don't have permission to. How does one change the root DN using dynamic configuration? Prentice

1 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical