openldap-technical

openldap-technical@openldap.org

13 participants
9794 discussions

OpenLDAP 2.4.15 : CSN too old when using 4-way multimaster
by Adrien Futschik 03 Mar '09

03 Mar '09

Hello everyone, I have been testing n-way multimaster replication with OpenLDAP for a while now (from 2.4.11, to 2.4.15) and just when I though that everything was working perfectly, I dicided to test N-way multimaster not only with 2 masters on different servers, but with 4 ! 2 OpenLDAP instances per server. I have been configuring syncprov and syncrepl accordingly : olcServerID: 1 ldap://163.106.38.90:9011/ olcServerID: 2 ldap://163.106.38.92:9012/ olcServerID: 3 ldap://163.106.38.90:9013/ olcServerID: 4 ldap://163.106.38.92:9014/ olcSyncrepl: {0}rid=011 provider=ldap://163.106.38.90:9011/ binddn="cn=admin,c =fr" bindmethod=simple credentials=secret searchbase="c=fr" type=refreshAndPe rsist retry="5 5 300 12 3600 +" timeout=3 olcSyncrepl: {1}rid=012 provider=ldap://163.106.38.92:9012/ binddn="cn=admin,c =fr" bindmethod=simple credentials=secret searchbase="c=fr" type=refreshAndPe rsist retry="5 5 300 12 3600 +" timeout=3 olcSyncrepl: {2}rid=013 provider=ldap://163.106.38.90:9013/ binddn="cn=admin,c =fr" bindmethod=simple credentials=secret searchbase="c=fr" type=refreshAndPe rsist retry="5 5 300 12 3600 +" timeout=3 olcSyncrepl: {3}rid=014 provider=ldap://163.106.38.92:9014/ binddn="cn=admin,c =fr" bindmethod=simple credentials=secret searchbase="c=fr" type=refreshAndPe rsist retry="5 5 300 12 3600 +" timeout=3 I am starting with all instances synced and I am trying to add entries en all four instances (in //). If I do so, I have a few entries that are not replicated on the others. I am getting this kind of messages : do_syncrep2: cookie=rid=011,sid=002,csn=20090227130003.849482Z#000000#004#000000 do_syncrep2: rid=011 CSN too old, ignoring 20090227130003.849482Z#000000#004#000000 do_syncrep2: cookie=rid=013,sid=002,csn=20090227130003.849482Z#000000#004#000000 do_syncrep2: rid=013 CSN too old, ignoring 20090227130003.849482Z#000000#004#000000 do_syncrep2: cookie=rid=014,sid=002,csn=20090227130003.946474Z#000000#004#000000 Did someone face the same issue ? Here is my configuration : (I am using refreshAndPersist mode for both cn=config and olcDatabase={1}bdb) M1 on IP1 / PORT1 : dn: cn=config objectClass: olcGlobal cn: config structuralObjectClass: olcGlobal creatorsName: cn=config olcServerID: 1 ldap://163.106.38.90:9011/ olcServerID: 2 ldap://163.106.38.92:9012/ olcServerID: 3 ldap://163.106.38.90:9013/ olcServerID: 4 ldap://163.106.38.92:9014/ entryUUID: ef89c876-adb3-4dc7-aa7d-024bbc359c98 createTimestamp: 20090227085748Z entryCSN: 20090227085749.920499Z#000000#004#000000 modifiersName: cn=config modifyTimestamp: 20090227085749Z contextCSN: 20090227085752.833630Z#000000#001#000000 dn: olcDatabase={1}bdb objectClass: olcDatabaseConfig objectClass: olcBdbConfig olcDatabase: {1}bdb olcDbDirectory: ./openldap-data olcSuffix: c=fr olcRootDN: cn=admin,c=fr olcRootPW:: e1NTSEF9WVZNSHJtYTRvUGd4KzFoak9kYWhBcm5NVHJxU1Zmdno= olcSizeLimit: 100 olcSyncrepl: {0}rid=011 provider=ldap://163.106.38.90:9011/ binddn="cn=admin,c =fr" bindmethod=simple credentials=secret searchbase="c=fr" type=refreshAndPe rsist retry="5 5 300 12 3600 +" timeout=3 olcSyncrepl: {1}rid=012 provider=ldap://163.106.38.92:9012/ binddn="cn=admin,c =fr" bindmethod=simple credentials=secret searchbase="c=fr" type=refreshAndPe rsist retry="5 5 300 12 3600 +" timeout=3 olcSyncrepl: {2}rid=013 provider=ldap://163.106.38.90:9013/ binddn="cn=admin,c =fr" bindmethod=simple credentials=secret searchbase="c=fr" type=refreshAndPe rsist retry="5 5 300 12 3600 +" timeout=3 olcSyncrepl: {3}rid=014 provider=ldap://163.106.38.92:9014/ binddn="cn=admin,c =fr" bindmethod=simple credentials=secret searchbase="c=fr" type=refreshAndPe rsist retry="5 5 300 12 3600 +" timeout=3 olcTimeLimit: 600 olcMirrorMode: TRUE olcDbCacheSize: 2000 olcDbCheckpoint: 2000 10 olcDbIndex: default pres,eq olcDbIndex: cn,sn pres,eq,sub olcDbIndex: objectClass,entryCSN,entryUUID eq structuralObjectClass: olcBdbConfig entryUUID: 00c01e5d-69ee-4baa-8e5a-4ef609dfd958 creatorsName: cn=config createTimestamp: 20090227085752Z entryCSN: 20090227085752.729899Z#000000#001#000000 modifiersName: cn=config modifyTimestamp: 20090227085752Z M2 on IP2 / PORT2 : dn: cn=config objectClass: olcGlobal cn: config structuralObjectClass: olcGlobal entryUUID: 8da75037-65e6-4375-8c21-7e5c0194a60b creatorsName: cn=config createTimestamp: 20090227085723Z olcServerID: 1 ldap://163.106.38.90:9011/ olcServerID: 2 ldap://163.106.38.92:9012/ olcServerID: 3 ldap://163.106.38.90:9013/ olcServerID: 4 ldap://163.106.38.92:9014/ entryCSN: 20090227085725.003182Z#000000#002#000000 modifiersName: cn=config modifyTimestamp: 20090227085725Z contextCSN: 20090227085752.833630Z#000000#001#000000 dn: olcDatabase={1}bdb objectClass: olcDatabaseConfig objectClass: olcBdbConfig olcDatabase: {1}bdb olcDbDirectory: ./openldap-data olcSuffix: c=fr olcRootDN: cn=admin,c=fr olcRootPW:: e1NTSEF9WVZNSHJtYTRvUGd4KzFoak9kYWhBcm5NVHJxU1Zmdno= olcSizeLimit: 100 olcSyncrepl: {0}rid=011 provider=ldap://163.106.38.90:9011/ binddn="cn=admin,c =fr" bindmethod=simple credentials=secret searchbase="c=fr" type=refreshAndPe rsist retry="5 5 300 12 3600 +" timeout=3 olcSyncrepl: {1}rid=012 provider=ldap://163.106.38.92:9012/ binddn="cn=admin,c =fr" bindmethod=simple credentials=secret searchbase="c=fr" type=refreshAndPe rsist retry="5 5 300 12 3600 +" timeout=3 olcSyncrepl: {2}rid=013 provider=ldap://163.106.38.90:9013/ binddn="cn=admin,c =fr" bindmethod=simple credentials=secret searchbase="c=fr" type=refreshAndPe rsist retry="5 5 300 12 3600 +" timeout=3 olcSyncrepl: {3}rid=014 provider=ldap://163.106.38.92:9014/ binddn="cn=admin,c =fr" bindmethod=simple credentials=secret searchbase="c=fr" type=refreshAndPe rsist retry="5 5 300 12 3600 +" timeout=3 olcTimeLimit: 600 olcMirrorMode: TRUE olcDbCacheSize: 2000 olcDbCheckpoint: 2000 10 olcDbIndex: default pres,eq olcDbIndex: cn,sn pres,eq,sub olcDbIndex: objectClass,entryCSN,entryUUID eq structuralObjectClass: olcBdbConfig entryUUID: 00c01e5d-69ee-4baa-8e5a-4ef609dfd958 creatorsName: cn=config createTimestamp: 20090227085752Z entryCSN: 20090227085752.729899Z#000000#001#000000 modifiersName: cn=config modifyTimestamp: 20090227085752Z M3 on IP1 / PORT3 : dn: cn=config objectClass: olcGlobal cn: config structuralObjectClass: olcGlobal entryUUID: cf068647-318f-4848-9c72-9c7745a8a4b3 creatorsName: cn=config createTimestamp: 20090227085742Z olcServerID: 1 ldap://163.106.38.90:9011/ olcServerID: 2 ldap://163.106.38.92:9012/ olcServerID: 3 ldap://163.106.38.90:9013/ olcServerID: 4 ldap://163.106.38.92:9014/ entryCSN: 20090227085743.825685Z#000000#003#000000 modifiersName: cn=config modifyTimestamp: 20090227085743Z contextCSN: 20090227085752.833630Z#000000#001#000000 dn: olcDatabase={1}bdb objectClass: olcDatabaseConfig objectClass: olcBdbConfig olcDatabase: {1}bdb olcDbDirectory: ./openldap-data olcSuffix: c=fr olcRootDN: cn=admin,c=fr olcRootPW:: e1NTSEF9WVZNSHJtYTRvUGd4KzFoak9kYWhBcm5NVHJxU1Zmdno= olcSizeLimit: 100 olcSyncrepl: {0}rid=011 provider=ldap://163.106.38.90:9011/ binddn="cn=admin,c =fr" bindmethod=simple credentials=secret searchbase="c=fr" type=refreshAndPe rsist retry="5 5 300 12 3600 +" timeout=3 olcSyncrepl: {1}rid=012 provider=ldap://163.106.38.92:9012/ binddn="cn=admin,c =fr" bindmethod=simple credentials=secret searchbase="c=fr" type=refreshAndPe rsist retry="5 5 300 12 3600 +" timeout=3 olcSyncrepl: {2}rid=013 provider=ldap://163.106.38.90:9013/ binddn="cn=admin,c =fr" bindmethod=simple credentials=secret searchbase="c=fr" type=refreshAndPe rsist retry="5 5 300 12 3600 +" timeout=3 olcSyncrepl: {3}rid=014 provider=ldap://163.106.38.92:9014/ binddn="cn=admin,c =fr" bindmethod=simple credentials=secret searchbase="c=fr" type=refreshAndPe rsist retry="5 5 300 12 3600 +" timeout=3 olcTimeLimit: 600 olcMirrorMode: TRUE olcDbCacheSize: 2000 olcDbCheckpoint: 2000 10 olcDbIndex: default pres,eq olcDbIndex: cn,sn pres,eq,sub olcDbIndex: objectClass,entryCSN,entryUUID eq structuralObjectClass: olcBdbConfig entryUUID: 00c01e5d-69ee-4baa-8e5a-4ef609dfd958 creatorsName: cn=config createTimestamp: 20090227085752Z entryCSN: 20090227085752.729899Z#000000#001#000000 modifiersName: cn=config modifyTimestamp: 20090227085752Z M4 on IP2 / PORT4 : dn: cn=config objectClass: olcGlobal cn: config structuralObjectClass: olcGlobal entryUUID: ef89c876-adb3-4dc7-aa7d-024bbc359c98 creatorsName: cn=config createTimestamp: 20090227085748Z olcServerID: 1 ldap://163.106.38.90:9011/ olcServerID: 2 ldap://163.106.38.92:9012/ olcServerID: 3 ldap://163.106.38.90:9013/ olcServerID: 4 ldap://163.106.38.92:9014/ entryCSN: 20090227085749.920499Z#000000#004#000000 modifiersName: cn=config modifyTimestamp: 20090227085749Z contextCSN: 20090227085752.833630Z#000000#001#000000 dn: olcDatabase={1}bdb objectClass: olcDatabaseConfig objectClass: olcBdbConfig olcDatabase: {1}bdb olcDbDirectory: ./openldap-data olcSuffix: c=fr olcRootDN: cn=admin,c=fr olcRootPW:: e1NTSEF9WVZNSHJtYTRvUGd4KzFoak9kYWhBcm5NVHJxU1Zmdno= olcSizeLimit: 100 olcSyncrepl: {0}rid=011 provider=ldap://163.106.38.90:9011/ binddn="cn=admin,c =fr" bindmethod=simple credentials=secret searchbase="c=fr" type=refreshAndPe rsist retry="5 5 300 12 3600 +" timeout=3 olcSyncrepl: {1}rid=012 provider=ldap://163.106.38.92:9012/ binddn="cn=admin,c =fr" bindmethod=simple credentials=secret searchbase="c=fr" type=refreshAndPe rsist retry="5 5 300 12 3600 +" timeout=3 olcSyncrepl: {2}rid=013 provider=ldap://163.106.38.90:9013/ binddn="cn=admin,c =fr" bindmethod=simple credentials=secret searchbase="c=fr" type=refreshAndPe rsist retry="5 5 300 12 3600 +" timeout=3 olcSyncrepl: {3}rid=014 provider=ldap://163.106.38.92:9014/ binddn="cn=admin,c =fr" bindmethod=simple credentials=secret searchbase="c=fr" type=refreshAndPe rsist retry="5 5 300 12 3600 +" timeout=3 olcTimeLimit: 600 olcMirrorMode: TRUE olcDbCacheSize: 2000 olcDbCheckpoint: 2000 10 olcDbIndex: default pres,eq olcDbIndex: cn,sn pres,eq,sub olcDbIndex: objectClass,entryCSN,entryUUID eq structuralObjectClass: olcBdbConfig entryUUID: 00c01e5d-69ee-4baa-8e5a-4ef609dfd958 creatorsName: cn=config createTimestamp: 20090227085752Z entryCSN: 20090227085752.729899Z#000000#001#000000 modifiersName: cn=config modifyTimestamp: 20090227085752Z I also have to say that if I stop M3 & M4 and try to add entries to M1 & M2, I don't get the "CSN too old" messages and all entries a replicated correctly !!! Is this because Multimaster is limited to 2-3 instances ? The reason why I am trying to build a 4-way master architecture is because I would like to be able to stop one server and perform a slapcat, even if one "physical" server is down... Thanks very much for your consideration & time.. Adrien Futschik

5 8

Is there disadvantage using a single dc?
by AlexanDER Franca 02 Mar '09

02 Mar '09

Hi everyone. Is there any disadvantage using a single dc? I mean, I work at a small company and I'm setting up a small ldap repository, for me is enough to use just a "dc=my_company". But slapd says something about less performance. I think this warning is just about large repositories using just a single dc, what seems to be a bad setup, but I'm not sure. []'s Alexander

3 2

ldappasswd returns "Additional info: password hash failed" in Solaris 10 SPARC
by Marius P. 01 Mar '09

01 Mar '09

Hello, I am trying to change a password for ldap entry using ldappasswd -vx -D "cn=root,dc=test,dc=com" -w foobarr "uid=mariusp,ou=people,dc=test,dc=com" and reply I get is: Result: Other (e.g., implementation specific) error (80) Additional info: password hash failed I am running openldap on Solaris 10 latest on SPARC. It is in testing meaning there is nothing special about its configuration all defaults. Database has two entries just to play with. I haven't bothered to compile it myself so just downloaded openldap 2.4.11 from sunfreeware.com with required prerequisits such as Berkeley DB, SASL, openssl etc. Everything works fine except this weird problem which looks like a bug. Password checking (binding) works fine if I manually change userPassword: attribute no matter what algorithm prefix I use be it SSHA, crypt or MD5. That tells me that it can succesfully check and run those algorithms however something breaks when it tries to change the password like it couldn't hash that supplied password. Wondering if anyone exprienced similar problem and have any comments or findings. Regards, /M.

4 4

BDB Inconsistencies when configuring on RH4 vs RH5
by Mathew Rowley 27 Feb '09

27 Feb '09

When installing 2.4.11 on my RH4 box, it configures fine with db4-4.2.52 installed (with bdb support) ... Making servers/slapd/backends.c Add config ... Add ldif ... Add monitor ... Add bdb ... Add hdb ... Add relay ... Making servers/slapd/overlays/statover.c Add seqmod ... Add syncprov ... Please run "make depend" to build dependencies [root@rsa01 openldap-2.4.11]# rpm -qa | grep db4 db4-4.2.52-7.1 db4-devel-4.2.52-7.1 [root@rsa01 openldap-2.4.11]# cat /etc/redhat-release Red Hat Enterprise Linux ES release 4 (Nahant Update 5) [root@rsa01 openldap-2.4.11]# But when trying to configure on a RH5 system, I get the BDB incompatible error: ... checking for Berkeley DB link (-ldb-4.3)... yes checking for Berkeley DB version match... yes checking for Berkeley DB thread support... yes checking Berkeley DB version for BDB/HDB backends... no configure: error: BDB/HDB: BerkeleyDB version incompatible [root@kdc01 openldap-2.4.11]# rpm -qa | grep db4 db4-utils-4.3.29-9.fc6 db4-devel-4.3.29-9.fc6 db4-4.3.29-9.fc6 [root@kdc01 openldap-2.4.11]# cat /etc/redhat-release Red Hat Enterprise Linux Server release 5.2 (Tikanga) [root@kdc01 openldap-2.4.11]# Is this an error in the configure script? Kind of confused. Thanks for any help. -- MAT

2 2

Running both ldap and ldaps simultaneously
by Bryan Payne 25 Feb '09

25 Feb '09

I'm trying to run both ldap:// and ldaps:// at the same time. Reason being, I can't get phpldapadmin to use ldaps. If I execute the command: /usr/local/openldap/libexec/slapd -u ldap -h ldap:/// ldaps:///, it just listens on 389. If I run, /usr/local/openldap/libexec/slapd -u ldap -h ldaps:/// ldap:///, it just listens on 636. How can I get it to listen on both ports?

4 4

Re: contextCSN
by Guillaume Arteta 25 Feb '09

25 Feb '09

Hello, Sorry for my English google:) I'm put into production 2 openldap masters, and I asked the same question João Alfredo. * So, if the resultt of this search is the same on all master's this mean that all servers are consistents, right ?* Ok, the ldapsearch (ldapsearch-x-h Master1 ... and ldapsearch-x-h master2 ...) displays the same values of contextCSN for server ID, but what it proves that they are synchronized? The question is, why master node, the ldapsearch ContextCSN displays of 2 servers (001 & 002) Can be put in place a monitoring system to test the replication by performing 2 ldapsearchs, if even then synchronized values. Merci ------ Arteta.

3 14

ldapmodify command line tool results in 'deferring operation: too many executing'
by Sean Burford 24 Feb '09

24 Feb '09

Hi, During a recent ldapmodify of 1000 records, I got some "deferring operation: too many executing" messages from OpenLDAP slapd 2.3.39. I am surprised by this, since I thought that since ldapmodify waited for the result of each operation nothing would be queued. Could this be caused by there being too many operations in progress across the entire server? This was the ldapmodify command line: ldapmodify -v -H "ldaps://master.example.com" -x -W -D "uid=person,ou=people,dc=example,dc=com" -c -f file.ldif The ldif only contained OpenLDAPaci attribute deletes that fit this template: dn: cn=host1000.example.com,ou=servers,dc=example,dc=com changetype: modify delete: OpenLDAPaci The ldapmodify output looked normal: delete OpenLDAPaci: modifying entry "cn=host1000.example.com,ou=servers,dc=example,dc=com" modify complete delete OpenLDAPaci: modifying entry "cn=host1001.example.com,ou=servers,dc=example,dc=com" modify complete But the logs show the 'deferring operation: too many executing': Feb 24 08:27:54 server slapd[9433]: conn=19226 op=640 MOD dn="cn= host1000.example.com,ou=servers,dc=example,dc=com" Feb 24 08:27:54 server slapd[9433]: conn=19226 op=640 MOD attr=OpenLDAPaci Feb 24 08:27:54 server slapd[9433]: conn=19226 op=640 RESULT tag=103 err=0 text= Feb 24 08:27:54 server slapd[9433]: connection_input: conn=19226 deferring operation: too many executing Feb 24 08:27:54 server slapd[9433]: conn=19226 op=641 MOD dn="cn= host1001.example.com,ou=servers,dc=example,dc=com" Feb 24 08:27:54 server slapd[9433]: conn=19226 op=641 MOD attr=OpenLDAPaci Feb 24 08:27:54 server slapd[9433]: conn=19226 op=641 RESULT tag=103 err=0 text= -- Thanks, Sean Burford

1 0

How to integrated OpenLDAP proxy to web application
by Duong Pham Tung 23 Feb '09

23 Feb '09

Hi all, I have already installed an OpenLDAP server as a LDAP proxy server. The data source backend of this server is a set of AD servers and other LDAP servers. I also have enabled SASL and Pass-through Authentication feature on this OpenLDAP server. Everything is running properly. Now, I want to deploy an Web Application which will use this OpenLDAP as a backend data source. I have deployed Pass-through authentication via SASL server, but as I understand, I must store information about user on my OpenLDAP server (such as username) and the userPassword field is set to {SASL}user@realm. But this LDAP proxy hasn’t any information about user on itself. So, which solutions can I use to solve user authentication problem without storing any user information on the LDAP Proxy. Thanks and Best regards Dương Phạm Tùng

1 0

Re: Password protection of TLS key
by ghenry＠OpenLDAP.org 20 Feb '09

20 Feb '09

> No really good ideas come to mind. I have a patch for libldap to > explicitly > set a callback to supply the key password, it won't make it into > 2.4.13 but > probably will be in 2.4.14. I will probably add two options to slapd, Hi, Did this make it into 2.4.14? I've checked the CHANGES and can't see anything mentioned re libldap? Thanks. > analogous to the back-bdb options to set the DB encryption key. (One > option to > set the key directly as an argument of the config option, one option > to read > the key from an arbitrary file.) Obviously for automated startup the > plaintext > of the key must be accessible to the slapd somewhere, and that means > it is > also accessible to potential intruders. This is just a fact of life. > You can > make key retrieval more tedious by hiding it behind other layers of > encryption, but ultimately the keys to each of those layers must also > be > accessible, otherwise slapd itself cannot use them. > > There are "clever" schemes to hide startup keys, but they tend to make > > restarts difficult. E.g., store keys on a mountpoint that you remount > some > other filesystem onto after the boot sequence has completed and all > dependent > daemons have started. Keep a file handle open on the new filesystem, > to > prevent it from being dismounted without rebooting the system. It'll > fool a > lot of intruders, but you won't be able to restart individual daemons > without > rebooting the machine. > > > Akke Bengtsson > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

4 3

olcSyncprovConfig not converted for cn=config
by Oliver Liebel 20 Feb '09

20 Feb '09

using openldap 2.4.14 (compiled from openldap.org source-package) i have noticed the following, reproducable behaviour when converting a slapd.conf to slapd.d: olcSyncprovConfig is generated during conversion for the hdb-context, but not for cn=config, although "overlay syncprov" is set for database config tested the conversion several times with slaptest and slapd, with the following simple example-slapd.conf. the result seems always to be the same. --- include /usr/local/etc/openldap/schema/core.schema access to dn.base="" by * read access to dn.base="cn=Subschema" by * read access to * by * read ##################################### database config rootdn cn=config rootpw {SSHA}4PvZLcpQ7s1CyQG+yworyl5DcrFTn78q overlay syncprov ##################################### database hdb suffix "dc=local,dc=site" checkpoint 1024 5 cachesize 10000 rootdn "cn=ldapadmin,dc=local,dc=site" rootpw {SSHA}4PvZLcpQ7s1CyQG+yworyl5DcrFTn78q directory /var/lib/ldap index objectClass eq index entryUUID,entryCSN eq overlay syncprov syncprov-checkpoint 10 1 syncprov-sessionlog 100 --- any ideas? thanks and greetings, oliver

2 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical