openldap-technical

openldap-technical@openldap.org

4 participants
9898 discussions

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

[Q] can I replicate several branches to the same slave from one master?
by Zeus Panchenko 29 Jun '17

29 Jun '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 hi, please advise I need to replicate not all but some branches from one master to one slave not sure how much correct I have done that, but here what I have: slave starts successfully, records appear on slave as expected, services successfully use data as expected ... but the replication fails (fragments of log files are bellow) on master I see: consumer state is newer than provider on slave: LDAP_RES_SEARCH_RESULT (53) Server is unwilling to perform so ... what is wrong here? branches to replicate: ou=People,dc=example ou=clusterX,ou=Sendmail,dc=example to be used by 3 services on the slave 1. email (smtp auth and imap4/pop3 auth) object dn sample: uid=ja@foo.bar,authorizedService=mail@foo.bar,uid=johnd,ou=People,dc=example 2. jabber object dn sample: uid=aj@foo.bar,authorizedService=xmpp@foo.bar,uid=johnd,ou=People,dc=example 3. sendmail configuration (here is the detailed diagram https://github.com/z-eos/umi/wiki/DB-topology) ====================================================================== here is the configuration layout: - ---[ master configuration quotation start ]--------------------------- ... access to dn.children="dc=example" by dn.exact="uid=replABC,ou=repl,dc=example" read by * break # syncprov specific indexing index entryCSN eq index entryUUID eq overlay syncprov syncprov-checkpoint 50 10 syncprov-sessionlog 100 overlay accesslog logdb cn=example-accesslog logops writes logold (objectclass=*) index default eq ### Accesslog DB database mdb maxsize 1073741824 suffix cn=example-accesslog rootdn "cn=root,cn=example-accesslog" rootpw *** directory "/var/db/openldap-data/example-accesslog" index default eq index entryCSN,objectClass,reqEnd,reqResult,reqStart overlay syncprov syncprov-nopresent TRUE syncprov-reloadhint TRUE ... - ---[ master configuration quotation end ]--------------------------- - ---[ slave configuration quotation start ]---------------------------- syncrepl rid=123 provider=ldap://master.example:389 starttls=critical searchbase="dc=example" bindmethod=simple binddn="uid=replABC,ou=repl,dc=example" credentials="***" filter="(|(&(objectClass=authorizedServiceObject)(objectClass=mailutilsAccount)(authorizedService=mail(a)foo.bar)))" attrs="cn,entry,entryCSN,entryUUID,o,uid,uidNumber,gidNumber,gecos,homeDirectory,loginShell,userPassword,creatorsName,createTimestamp,modifiersName,modifyTimestamp,mail,rfc822MailMember,sn,authorizedService,mu-mailBox" 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 syncrepl rid=123 provider=ldap://master.example:389 starttls=critical searchbase="dc=example" bindmethod=simple binddn="uid=replABC,ou=repl,dc=example" credentials="***" filter="(&(objectClass=authorizedServiceObject)(authorizedService=xmpp(a)foo.bar))" 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 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 ]---------------------------- ====================================================================== here are logs - ---[ master slapd.log quotation start ]------------------------------- Jun 26 22:54:25 master slapd[75509]: conn=55585 fd=19 ACCEPT from IP=192.168.0.1:54127 (IP=192.168.0.254:389) Jun 26 22:54:25 master slapd[75509]: conn=55585 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Jun 26 22:54:25 master slapd[75509]: conn=55585 op=0 STARTTLS Jun 26 22:54:25 master slapd[75509]: conn=55586 fd=20 ACCEPT from IP=192.168.0.1:57184 (IP=192.168.0.254:389) Jun 26 22:54:25 master slapd[75509]: conn=55585 op=0 RESULT oid= err=0 text= Jun 26 22:54:25 master slapd[75509]: conn=55586 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Jun 26 22:54:25 master slapd[75509]: conn=55586 op=0 STARTTLS Jun 26 22:54:25 master slapd[75509]: conn=55586 op=0 RESULT oid= err=0 text= Jun 26 22:54:25 master slapd[75509]: conn=55586 fd=20 TLS established tls_ssf=256 ssf=256 Jun 26 22:54:25 master slapd[75509]: conn=55585 fd=19 TLS established tls_ssf=256 ssf=256 Jun 26 22:54:25 master slapd[75509]: conn=55586 op=1 BIND dn="uid=replABC,ou=repl,dc=example" method=128 Jun 26 22:54:25 master slapd[75509]: conn=55586 op=1 BIND dn="uid=replABC,ou=repl,dc=example" mech=SIMPLE ssf=0 Jun 26 22:54:25 master slapd[75509]: conn=55586 op=1 RESULT tag=97 err=0 text= Jun 26 22:54:25 master slapd[75509]: conn=55585 op=1 BIND dn="uid=replABC,ou=repl,dc=example" method=128 Jun 26 22:54:25 master slapd[75509]: conn=55585 op=1 BIND dn="uid=replABC,ou=repl,dc=example" mech=SIMPLE ssf=0 Jun 26 22:54:25 master slapd[75509]: conn=55585 op=1 RESULT tag=97 err=0 text= Jun 26 22:54:25 master slapd[75509]: conn=55586 op=2 SRCH base="cn=example-accesslog" scope=2 deref=0 filter="(&(objectClass=auditWriteObject)(reqResult=0))" Jun 26 22:54:25 master slapd[75509]: conn=55586 op=2 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN Jun 26 22:54:25 master slapd[75509]: conn=55585 op=2 SRCH base="cn=example-accesslog" scope=2 deref=0 filter="(&(objectClass=auditWriteObject)(reqResult=0))" Jun 26 22:54:25 master slapd[75509]: conn=55585 op=2 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN Jun 26 22:54:25 master slapd[75509]: conn=55586 op=2 SEARCH RESULT tag=101 err=53 nentries=0 text=consumer state is newer than provider! Jun 26 22:54:25 master slapd[75509]: conn=55585 op=2 SEARCH RESULT tag=101 err=53 nentries=0 text=consumer state is newer than provider! Jun 26 22:54:25 master slapd[75509]: conn=55586 op=3 UNBIND Jun 26 22:54:25 master slapd[75509]: conn=55586 fd=20 closed Jun 26 22:54:25 master slapd[75509]: conn=55585 op=3 UNBIND Jun 26 22:54:25 master slapd[75509]: conn=55585 fd=19 closed Jun 26 22:54:31 master slapd[75509]: conn=55587 fd=19 ACCEPT from IP=192.168.0.1:58488 (IP=192.168.0.254:389) Jun 26 22:54:31 master slapd[75509]: conn=55587 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Jun 26 22:54:31 master slapd[75509]: conn=55587 op=0 STARTTLS Jun 26 22:54:31 master slapd[75509]: conn=55587 op=0 RESULT oid= err=0 text= Jun 26 22:54:31 master slapd[75509]: conn=55587 fd=19 TLS established tls_ssf=256 ssf=256 Jun 26 22:54:31 master slapd[75509]: conn=55587 op=1 BIND dn="uid=replABC,ou=repl,dc=example" method=128 Jun 26 22:54:31 master slapd[75509]: conn=55587 op=1 BIND dn="uid=replABC,ou=repl,dc=example" mech=SIMPLE ssf=0 Jun 26 22:54:31 master slapd[75509]: conn=55587 op=1 RESULT tag=97 err=0 text= Jun 26 22:54:31 master slapd[75509]: conn=55587 op=2 SRCH base="cn=example-accesslog" scope=2 deref=0 filter="(&(objectClass=auditWriteObject)(reqResult=0))" Jun 26 22:54:31 master slapd[75509]: conn=55587 op=2 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN Jun 26 22:54:31 master slapd[75509]: conn=55587 op=2 SEARCH RESULT tag=101 err=53 nentries=0 text=consumer state is newer than provider! Jun 26 22:54:31 master slapd[75509]: conn=55587 op=3 UNBIND Jun 26 22:54:31 master slapd[75509]: conn=55587 fd=19 closed - ---[ master slapd.log quotation end ]------------------------------- - ---[ slave slapd.log quotation start ]-------------------------------- Jun 26 21:41:44 ABC slapd[67186]: @(#) $OpenLDAP: slapd 2.4.44 (Feb 7 2017 01:19:39) $ root@foo.bar:/usr/ports/net/openldap24-server/work/openldap-2.4.44/servers/slapd Jun 26 21:41:44 ABC slapd[67187]: slapd starting Jun 26 21:41:44 ABC slapd[67187]: conn=1000 fd=14 ACCEPT from IP=127.0.0.1:32266 (IP=127.0.0.1:389) Jun 26 21:41:44 ABC slapd[67187]: conn=1001 op=0 BIND dn="" method=128 Jun 26 21:41:44 ABC slapd[67187]: conn=1002 fd=17 ACCEPT from IP=127.0.0.1:35827 (IP=127.0.0.1:389) Jun 26 21:41:44 ABC slapd[67187]: conn=1000 op=0 BIND dn="" method=128 Jun 26 21:41:44 ABC slapd[67187]: conn=1001 op=0 RESULT tag=97 err=0 text= Jun 26 21:41:44 ABC slapd[67187]: conn=1001 fd=16 ACCEPT from IP=127.0.0.1:37048 (IP=127.0.0.1:389) Jun 26 21:41:44 ABC slapd[67187]: conn=1002 op=0 BIND dn="" method=128 Jun 26 21:41:44 ABC slapd[67187]: conn=1000 op=0 RESULT tag=97 err=0 text= Jun 26 21:41:44 ABC slapd[67187]: conn=1002 op=0 RESULT tag=97 err=0 text= Jun 26 21:41:45 ABC slapd[67187]: do_syncrep2: rid=123 LDAP_RES_SEARCH_RESULT (53) Server is unwilling to perform Jun 26 21:41:45 ABC slapd[67187]: do_syncrep2: rid=123 (53) Server is unwilling to perform Jun 26 21:41:45 ABC slapd[67187]: do_syncrepl: rid=123 rc -2 retrying Jun 26 21:41:45 ABC slapd[67187]: do_syncrep2: rid=123 LDAP_RES_SEARCH_RESULT (53) Server is unwilling to perform Jun 26 21:41:45 ABC slapd[67187]: do_syncrep2: rid=123 (53) Server is unwilling to perform Jun 26 21:41:45 ABC slapd[67187]: do_syncrepl: rid=123 rc -2 retrying Jun 26 21:41:45 ABC slapd[67187]: do_syncrep2: rid=123 LDAP_RES_SEARCH_RESULT (53) Server is unwilling to perform Jun 26 21:41:45 ABC slapd[67187]: do_syncrep2: rid=123 (53) Server is unwilling to perform Jun 26 21:41:45 ABC slapd[67187]: do_syncrepl: rid=123 rc -2 retrying Jun 26 21:42:43 ABC slapd[67187]: conn=1003 fd=9 ACCEPT from IP=127.0.0.1:37489 (IP=127.0.0.1:389) Jun 26 21:42:43 ABC slapd[67187]: conn=1003 op=0 BIND dn="" method=128 - ---[ slave slapd.log quotation end ]-------------------------------- - -- Zeus V. Panchenko jid:zeus@im.ibs.dn.ua IT Dpt., I.B.S. LLC GMT+2 (EET) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQYIXL6FUmD7SUfqoOveOk+D/ejKgUCWVGE9gAKCRCveOk+D/ej Kp1JAJ9tFikqgeCHlzUXfQrcTQuHlAqNKwCdEMnIM6uOFRCNBN6oHmh4AyQ6j1U= =Xn/Y -----END PGP SIGNATURE-----

2 3

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

29 Jun '17

--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). 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. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: syncrepl fails after upgrade to openldap 2.4.45
by Quanah Gibson-Mount 29 Jun '17

29 Jun '17

--On Thursday, June 29, 2017 5:07 PM +0100 Andrew Findlay <andrew.findlay(a)skills-1st.co.uk> wrote: > It seems that the CA cert was never referenced in the syncrepl clause, so > it would have dropped back to whatever TLS config was in the LDAP *client* > config file (probably /etc/ldap/ldap.conf). I seem to remember a change in > behaviour of OpenSSL libs a while ago where I was bitten by something > similar. Maybe Juergen's earlier setup used ldap.conf and the new one > is ignoring it? Could be. My specific suggestion to him was to add a line for the CA. Instead, he added a line for the CA and the two additional lines for a cert & key (which would imply certificate authentication). --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

RE: syncrepl fails after upgrade to openldap 2.4.45
by Quanah Gibson-Mount 29 Jun '17

29 Jun '17

--On Monday, June 26, 2017 7:11 AM +0000 Juergen.Sprenger(a)swisscom.com wrote: > Cert authentication works on 2.4.44-r1 without any problem. Now you're switching topics. Your original mail did not include cert authentication, it used simple binds: syncrepl rid=000 provider=ldaps://ldap.dannatu.ch:636 type=refreshAndPersist retry="5 5 300 +" searchbase="dc=dannatu,dc=ch" attrs="*,+" scope=sub bindmethod=simple binddn="cn=Manager,dc=dannatu,dc=ch" credentials=************** Either way, cert authentication AND TLS encrypted syncrepl both work for me with OpenSSL 1.0.2l and OpenLDAP 2.4.45 just fine, so I would have to again guess issues with proper TLS configuration. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

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

29 Jun '17

--On Tuesday, June 27, 2017 5:35 PM -0400 btb <btb(a)bitrate.net> wrote: > On 6/27/17 10:27 AM, Quanah Gibson-Mount wrote: >> --On Tuesday, June 27, 2017 10:37 AM -0400 btb <btb(a)bitrate.net> wrote: >>> i'm using 2.4.44 on freebsd, built from ports. i can provide any config >>> details etc - i just didn't want to inundate the post with guesses on >>> detail that might not be relevant. >> >> What is your accesslog purge setting? Do you have long periods of time >> with no write activity? > > there are some extended periods of time with no write activity, yes. That's one form of a known issue then with using accesslog (ITS#8100). I've made a suggestion on how it could be fixed, and Howard agreed that would be the correct solution. Just need the fix. :) In the meantime, you can set up a cronjob that does a modify once a day on some object that doesn't really do anything, like if you had: dn: cn=someobject,dc... objectClass: ... cn: someobject description: blah you could have a job that does: dn: cn=someobject,dc... changetype: modify replace: description description: blah So it in effect does nothing, but it keeps an active change in the accesslog alive. Basically what happens with the accesslog empty is that it'll end up generating its own new contextCSN that differs for that server than the one stored in the rootDB, and will be /newer/ than it as well, which is why you get that message. You can also fix the problem simply by doing a modify on each master, and it'll reset the contextCSNs and things will flow (i.e., no need to do a dump/reload, etc). --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: N-Way multi-master configuration
by Quanah Gibson-Mount 29 Jun '17

29 Jun '17

--On Wednesday, June 28, 2017 11:25 PM +0100 Dave Lambley <dave.lambley(a)gmail.com> wrote: > What is the reason the documentation suggests "type=refreshOnly" for > data, but not for config? Should I expect any problems using > "type=refreshAndPersist" for data? The admin guide is simply giving information on how things can be done. It is not making recommendations on how things should be done. It is generally thought that people read through the pros and cons of different replication strategies and develop an understanding of what is likely best for them. I would note that running MMR with 2.4.31 is generally suicidal. I strongly advise upgrading to a current release. Please read the list of fixes in the 5 years since 2.4.31 was released: <http://www.openldap.org/software/release/changes.html> --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

N-Way multi-master configuration
by Dave Lambley 28 Jun '17

28 Jun '17

We are using OpenLDAP 2.4.31 under Ubuntu 14.04, doing four way multi master replication. When I initially configured it, I set the data (as opposed to config) replication to be "type=refreshOnly", as described here, http://www.openldap.org/doc/admin24/replication.html#N-Way%20Multi-Master That didn't work well, we lost insertions and and memory usage of some servers steadily over the two weeks I left it. Switching the replication to "type=refreshAndPersist" resolved both problems. What is the reason the documentation suggests "type=refreshOnly" for data, but not for config? Should I expect any problems using "type=refreshAndPersist" for data? Best regards, Dave Lambley

1 0

redMod with single colon
by Michael Ströder 28 Jun '17

28 Jun '17

HI! I have several accesslog entries with 'reqMod' containing a single colon. :-/ Example (excerpt): [..] reqMod: aeTicketId:- IAM-31 reqMod:: Og== reqMod: aeTicketId:+ IAM-201 reqMod: member:- uid=foo1,cn=ae,ou=ae-dir reqMod: member:- uid=foo2,cn=ae,ou=ae-dir reqMod:: Og== reqMod: member:+ uid=foo1,cn=ae,ou=ae-dir reqMod: member:+ uid=foo2,cn=ae,ou=ae-dir reqMod: member:+ uid=foo3,cn=ae,ou=ae-dir reqMod: memberUid:- foo1 reqMod: memberUid:- foo2 reqMod:: Og== reqMod: memberUid:+ foo1 reqMod: memberUid:+ foo2 reqMod: memberUid:+ foo3 [..] (before you ask: An account foo3 added to Æ-DIR user group with hybrid group schema compatible to RFC2307 and RFC2307bis.) Under which circumstances is slapo-accesslog writing a single colon? Currently I cannot easily reproduce it and I don't know what was so special about this particular modify operation (sent by web2ldap). Ciao, Michael.

2 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