openldap-technical

openldap-technical@openldap.org

5 participants
9991 discussions

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

Syncrepl master/master on RedHat4 Update 5 - wheres library?
by Mathew Rowley 19 Feb '09

19 Feb '09

I am trying to test the master/master replication architecture. When following the documentation from: http://www.openldap.org/doc/admin24/replication.html it shows: olcModulePath: /usr/local/libexec/openldap olcModuleLoad: syncprov.la When looking on my system, that file, nor the directory exists. I then looked into the slapd.conf file to see where the other libraries were: # modulepath /usr/sbin/openldap # moduleload back_bdb.la Again that directory, nor the module exist. I then thought there may be some option in the source that needs to be enabled to build the syncprov library, but I found nothing. I do see that there is a patch for syncrepl-uuid¹ which would make me think that the package is being built with syncrepl capability. How do I move forward? Do I need that library loaded? I did find this: https://bugzilla.redhat.com/show_bug.cgi?id=466937 which states: syncprov is compiled statically into slapd daemon to keep backward compatibility, I forgot to remove it from the config file. Does that mean the library is loaded by default, and doesn¹t explicitly need to be set to load? Thanks for any help. -- MAT

2 1

N-way multimaster replication with 2 masters
by Adrien Futschik 19 Feb '09

19 Feb '09

Hy again ! Still testing n-way multimaster replication with 2 masters. I encountered a situation where my two masters where out of sync. Here is the deal : I have M1(serverID=1) & M2(serverID=2) synced and I am performing adds/modify to both M1 & M2. 1) I stop M2 and make a backup of it with slapcat. 2) I then restart M2. 3) I continue to make updates on M1 & M2. 4) I then stop (kill -INT PID) M2 5) I continue to make updates on M1 6) I then delete all *.bdb etc.. files from M2 7) I use the LDIF backup(see 1)) to restore M2 and then restart it. 8) restart M2 9) all entries modified/added during phase 5) are successfuly replicated to M2, but all entries modified/added on M2 dunring phase 3) are not replicated on M2. This is because those entries have an entryCSN menchening that theses entries where last modified/created on M2 (ex: entryCSN: 20090219091852.789559Z#000000#002#000000) So M1 doesn't send them back to M2 even though they aren't present on M2. The trick I used to force M1 to send these entries to M2 is to change the serverID of M2. In fact, it is like setting up a whole new master. So I changed cn=config olcServerID from M1 before restarting M2 (before 8)) and I modify /appli/projects/m2/openldap_2.4.14/conf/slapd.d/cn=config.ldif also This is the only way I found to make sure that M1 & M2 are really the same again. Any other suggestions ? I didn't found anything in the documentation about that, maybe I missed-it. Adrien

1 0

N-way multimaster error code 53 - shadow context
by Adrien Futschik 19 Feb '09

19 Feb '09

Hy ! it's me again :) I am still testing n-way multi master replication with OpenLDAP 2.4.14. I don't know why I could modify my olcSyncrepl attribute from my data bdb. I am binding with cn=config, and I can modify the olcSyncrepl attribute from olcDatabase={0}config, but not from olcDatabase={1}bdb ! I am getting this error : 08:57:25: Failed to update entry olcDatabase={1}bdb, cn=config Reason: [LDAP: error code 53 - shadow context; no update referral] This appends on both masters. Is this supposed to be like that ? I have configured cn=config to replicate, this should work right ? Adrien

2 3

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical