openldap-software January 2010

openldap-software@openldap.org

35 participants
33 discussions

searching for attributes without index in 2.4.19 with bdb 4.5
by Christoph Herrmann 09 Feb '10

09 Feb '10

Hello, after upgrading from openldap-2.3.39 with bdb-4.2.52 to openldap 2.4.19 with bdb-4.5 searching for attributes without index is about three times slower. (same machine, same data, all data fit in DB cache) Are there any known problems or magic tuning options we have missed? regards Christoph &:-) -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Michel Lepert Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196

1 1

Re: Question about contextCSN's
by Ryan Steele 03 Feb '10

03 Feb '10

Rein Tollevik wrote: > Ryan Steele wrote: >> I'm replicating both the config and backend databases between two >> boxes. Everything seems fine, but for some reason >> when I query them both for the contextCSN, the config database returns >> only one while the backend database returns two, >> as seen below: > > The contextCSN attribute with any given sid is added to a database only > after the server with that serverID modifies the database. The count of > contextCSN values in a database does not need to reflect the number of > master servers that could modify it, and it have no relation to the > values in other databases. > > In your example, all modifications to cn=config was probably made on the > first server (assuming it have serverID 1 that is). The example db have > been modified by both. > > Rein Thanks a lot for clarifying; I didn't realize that the contextCSN for each SID was added to a given database only after being modified by that SID. And yes, I do understand that the different databases (e.g., backend and config) will have different contextCSN's reflecting the last time they were written to, but my question was mostly about the same database on different nodes. Namely, I thought that verifying whether replication was complete was done by comparing the contextCSN's for the same database on each node (SID) in the replication group. That is, if replication is working, each server to whom the given database is being replicated should have the same contextCSN for that database, to verify that each received the same last write operation. I'm not quite sure how to interpret that though, given the results I'm seeing in my master-master pair. Should the contextCSN's in the backend database for both SID 001 and SID 002 match? E.g.: contextCSN: 20100126210305.876171Z#000000#001#000000 contextCSN: 20100126210305.876171Z#000000#002#000000 Or should both nodes agree about the timestamps for each SID independently? E.g.: ### ldap1 contextCSN: 20100126210305.876171Z#000000#001#000000 contextCSN: 20091018205321.288716Z#000000#002#000000 ### ldap2 contextCSN: 20100126210305.876171Z#000000#001#000000 contextCSN: 20091018205321.288716Z#000000#002#000000 It would intuitively seem to me that each node (SID) to whom the database is being replicated should have the same contextCSN, so that one could verify the replication status by looking at the attribute values for each SID on one node, instead of querying each node to see if the timestamp for each individual SID matched on every node. But, which is correct? Thanks again for the insight. Respectfully, Ryan

3 3

dynlist overlay and ldapsearch
by ben thielsen 03 Feb '10

03 Feb '10

hi- i'm using the dynlist overlay and am not getting back the search results i expected. i'm using 2.4.11 courtesy of debian. here is my overlay config: >ldapsearch -xWLLLD 'cn=admin,cn=config' -b 'cn=config' "(objectclass=olcdynamiclist)" dn: olcOverlay={5}dynlist,olcDatabase={2}bdb,cn=config objectClass: olcOverlayConfig objectClass: olcDynamicList olcOverlay: {5}dynlist olcDLattrSet: {0}groupOfNames memberURL member olcDLattrSet: {1}mailGroup labeledURI here is the entry in question: >ldapsearch -xWLLLD 'cn=admin,dc=groundnoise,dc=net' -s base -b 'cn=abuse,ou=distribution_groups,ou=all_domains,ou=domains,ou=mail,dc=groundnoise,dc=net' dn: cn=abuse,ou=distribution_groups,ou=all_domains,ou=domains,ou=mail,dc=groun dnoise,dc=net objectClass: mailGroup objectClass: top objectClass: extensibleObject cn: abuse member: cn=postmaster,ou=distribution_groups,ou=all_domains,ou=domains,ou=mail ,dc=groundnoise,dc=net labeledURI: ldap:///ou=domains,ou=mail,dc=groundnoise,dc=net?host?sub?(objectC lass=mailDomain) host: phone.dipswitch.net host: luna.mpls.mn.us host: groundnoise.net host: thielsen.org host: sjva1991.org host: dipswitch.net host: bitrate.net searched for another way: >ldapsearch -xWLLLD 'cn=admin,dc=groundnoise,dc=net' '(&(objectclass=mailgroup)(cn=abuse))' host dn: cn=abuse,ou=distribution_groups,ou=all_domains,ou=domains,ou=mail,dc=groun dnoise,dc=net host: phone.dipswitch.net host: luna.mpls.mn.us host: groundnoise.net host: thielsen.org host: sjva1991.org host: dipswitch.net host: bitrate.net however, the results from this search are missing that entry: >ldapsearch -xWLLLD 'cn=admin,dc=groundnoise,dc=net' '(host=dipswitch.net)' dn dn: host=dipswitch.net,ou=domains,ou=mail,dc=groundnoise,dc=net or another search: ldapsearch -xvWD 'cn=admin,dc=groundnoise,dc=net' '(&(objectclass=mailgroup)(host=*))' host ldap_initialize( <DEFAULT> ) Enter LDAP Password: filter: (&(objectclass=mailgroup)(host=*)) requesting: host # extended LDIF # # LDAPv3 # base <dc=groundnoise, dc=net> (default) with scope subtree # filter: (&(objectclass=mailgroup)(host=*)) # requesting: host # # search result search: 2 result: 0 Success # numResponses: 1 if i remove the labeledURI attribute and populate with static entries, things appear to work as expected: here's the entry: >ldapsearch -xWLLLD 'cn=admin,dc=groundnoise,dc=net' '(&(objectclass=mailgroup)(cn=abuse))' dn: cn=abuse,ou=distribution_groups,ou=all_domains,ou=domains,ou=mail,dc=groun dnoise,dc=net objectClass: mailGroup objectClass: top objectClass: extensibleObject cn: abuse member: cn=postmaster,ou=distribution_groups,ou=all_domains,ou=domains,ou=mail ,dc=groundnoise,dc=net host: foo host: bar host: com host: net host: org and a search: >ldapsearch -xWLLLD 'cn=admin,dc=groundnoise,dc=net' '(host=foo)' dn dn: cn=abuse,ou=distribution_groups,ou=all_domains,ou=domains,ou=mail,dc=groun dnoise,dc=net what am i doing wrong? thanks -ben

3 3

Need some help with OpenLDAP rights
by Guenter Knauf 31 Jan '10

31 Jan '10

Hi all, I have a relatively simple requirement to grant some OpenLDAP rights .... my OpenLDAP directory looks like that: root \ ou=managers ou=webprojects \ ou=groups ou=users now I need to grant full rights for users (InetOrgPerson) in ou=managers to ou=webprojects so that they can create/modify/delete users and groups in ou=groups,ou=webprojects and ou=users,ou=webprojects, also I would like to have users be able to modify their own entries. For a start I tried some settings in slapd.conf, f.e.: access to dn.base="" by * read access to dn.base="cn=Subschema" by * read access to dn.base="ou=webprojects" by users write access to * by self write by users read by anonymous auth >From my (most likely wrong) understanding this would mean that every user should be able to create/modify/delete every entry in and below ou=webprojects; but unfortunately this seems not the case. Instead I get all other sorts of whoes like 'error: need stronger encryption' when I try to login via non-ssl connection etc. I really dont need ssl since in my case the manager users will always only login via web application on localhost, so nothing goes over the wire. Can please someone tell about the proper access rules for my requirements? thanks, Günter. -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser

2 1

startup error after converting to slapd-config
by Gerard Ranke 29 Jan '10

29 Jan '10

Dear all, We run openLDAP 2.4.21 on one master plus 7 slaves. Some time ago ( I believe we were on 2.4.19 at the time ), I converted one of the slaves to slapd-config from slapd.conf to get myself acquainted with it, and that went without problems. Now, if I try the conversion with slaptest -f slapd.conf -F slapd.d, the conversion works ok, but slapd won't start, and gives this error: Jan 18 15:30:20 7E:example-slave slapd[1741992]: _sasl_plugin_load failed on sasl_auxprop_plug_init for plugin: ldapdb Jan 18 15:30:20 7U:example-slave slapd[1741992]: olcSyncrepl: value #0: <olcSyncrepl> invalid URL Jan 18 15:30:20 7U:example-slave slapd[1741992]: config error processing olcDatabase={1}hdb,cn=config: <olcSyncrepl> invalid URL Jan 18 15:30:20 7U:example-slave slapd[1741992]: slapd stopped. Jan 18 15:30:20 7U:example-slave slapd[1741992]: connections_destroy: nothing to destroy. I noticed that the olcSyncrepl in olcDatabase={1}hdb,cn=config changed from: olcSyncrepl: rid=001 provider=ldap://masterldap.example.com:389 bindmethod=simple timeout =0 network-timeout=0 binddn="cn=syncuser,dc=example,dc=com" credentials="xxxxxxxxx " starttls=critical filter="(objectClass=*)" searchbase="dc=example,dc=com" scope= sub attrs="*,+" schemachecking=off type=refreshAndPersist retry="5 5 10 +" for the older openldap version, to: olcSyncrepl: rid=001 provider=ldap://masterldap.example.com:389 uri="" bindmethod=simple timeout=0 network-timeout=0 binddn="cn=syncuser,dc=example,dc=com" credentials="xxxxxxxxx" starttls=critical tls_cert="/usr/ssl/certs/examplewildcard.cert " tls_key="/usr/ssl/certs/examplewildcard.key" tls_cacert="/usr /ssl/certs/cacert_root.crt" tls_reqcert=demand tls_crlcheck=none filter="(obj ectClass=*)" searchbase="dc=example,dc=com" scope=sub attrs="*,+" schemachecking=o ff type=refreshAndPersist retry="5 5 10 +" for 2.4.21. Notice the ' uri="" ' in the last version. Fortunately, if I remove the empty uri assignment from the ldif file, slapd starts normally. But I still wondered if I have missed something, so if anyone can explain what happened, I would be very grateful. Best regards, gerard

2 2

fw: using the perl backend
by Brett ＠Google 28 Jan '10

28 Jan '10

Hello, I am trying to find a way to drive a perl backend to receive changes from a master. Assume we have something like : include /usr/local/openldap/etc/openldap/schema/core.schema include /usr/local/openldap/etc/openldap/schema/cosine.schema include /usr/local/openldap/etc/openldap/schema/inetorgperson.schema pidfile /data/openldap/run/slapd_log.pid argsfile /data/openldap/run/slapd_log.args database perl suffix "dc=example,dc=com" rootdn "cn=admin, dc=example, dc=com" rootpw <mypass> # log example module perlModulePath /usr/local/perl-lib perlModule MyPerlModule loglevel 256 Which is pretty straightforward. In the ye olde days of 2.3.x there was slurp, you could point a slurp at the above slap instance, and you could perform custom perl code when changes were pushed incrementally to it by slurp replication. It would appear that since syncrepl, as responsibility for replication replication has moved from the server to the client, having a somewhat "dumb" client now is not so easy. It would appear out of the box that there is no (trivial) way with syncrepl to push delta changes after a given epoch, towards a perl backend under 2.4.x ? Slurp used to be able to push add/modify/delete operations, to a perl or shell backend which could then "snoop" for interesting information. Doing the same for syncrepl would seem to require maintainance of a full syncrepl state (or replica), in order for a perl/shell backend to snoop for interesting changes. Anyone got any thoughts on this ? Is there a way of getting syncrepl to emit simple add/modify/delete changes (ala slurp-like) to a perl backend, without the prerequisite present search ? Or maybe the perl backend in question would need to "fake" or pass through syncrepl searches and responses, well enough to force syncrepl to either always perform the prerequisite change, and/or perhaps only call the add/modify/delete in the perl backend for leaf objects or other objects of interest, maybe given a particular time epoch or starting date/time ? Being able to call a perl (threaded) or shell backend (unthreaded) for changes is a useful ability which seems to have apparently been lost in the upgrade from 2.3.x to 2.4.x ?? The 2.4.x series seems to require a perl backend to require knowledge of syncrepl, even if it's pushing to a perl backend on another server via a "standalone ldap proxy". Cheers Brett

4 4

Syncrepl Problem after repeatedly reboot
by HRZ Konten 28 Jan '10

28 Jan '10

Hallo all, we have 2 OpenLDAP 2.4.17 with N-Way Replication on Debian Lenny. Config dn: olcDatabase={0}config objectClass: olcDatabaseConfig olcDatabase: {0}config olcRootPW:: xxxxxxxxxxxxxxxxx structuralObjectClass: olcDatabaseConfig entryUUID: 446a8178-95f7-102e-8e9a-95c863b9a1ce creatorsName: cn=config createTimestamp: 20100115075644Z olcSyncrepl: {0}rid=001 provider=ldaps://xxxxxxxxxxxxxxxx:636/ bindd n="cn=config" bindmethod=simple credentials=xxxxxxxxxxxxxxxxxxx searchbase="cn=confi g" type=refreshAndPersist retry="5 5 300 +" schemachecking="on" timeout=3 olcSyncrepl: {1}rid=002 provider=xxxxxxxxxxxxxxxxxxxxxxxxxxx:636/ bindd n="cn=config" bindmethod=simple credentials=xxxxxxxxxxxxxxxx searchbase="cn=confi g" type=refreshAndPersist retry="5 5 300 +" schemachecking="on" timeout=3 olcMirrorMode: TRUE entryCSN: 20100115075655.626787Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20100115075655Z We reboot one of the nodes a couple of times at the time as the other node made ~ 60 000 adds. After 12 hours there is still some difference between both nodes: root@ldap1:~# ldapsearch -D "cn=manager,dc=xxx" -W -x -b "dc=xxx" courseOfStudy=* | grep courseOfStudy | wc -l Enter LDAP Password: 61125 root@ldap2:~# ldapsearch -D "cn=manager,dc=xxx" -W -x -b "dc=xxx" courseOfStudy=* | grep courseOfStudy | wc -l Enter LDAP Password: 47366 The contextCSN is equal on both nodes: ldap1: ldapsearch -xLLLH ldaps://ldap1:636 -s base -b "dc=xxx" contextCSN -W -D "cn=manager,xxx" Result: contextCSN: 20100121183644.034011Z#000000#000#000000 ldap2: ldapsearch -xLLLH ldaps://ldap2:636 -s base -b "dc=uxxx" contextCSN -W -D "cn=manager,xxx" Result: contextCSN: 20100121183644.034011Z#000000#000#000000 Is there an easy way to force a new replication on the second node? I will really appreciate your help...

3 2

Re: Syncrepl Problem after repeatedly reboot
by HRZ Konten 28 Jan '10

28 Jan '10

Am 28.01.2010 13:00, schrieb openldap-software-request(a)OpenLDAP.org: >> Is there any other way to check that? Then if I don't know that they are >> > out of synchow could I start the rebuild of the second node... >> > To check the database content just slapcat both directories and do a > diff. > Thank you, Dieter! The simple solutions are the best, I wonder why I hadn't the same idea :) > My multimaster tests of early 2.4 versions(2.4.11 + 2.4.12) had > similar effects. While a node was down, heavy modifications, that is > modify, delete and add operations, where made. But only the added > objects where synchronised but not the modified and deleted > objects. It seems to me that there is something missed in the syncrepl if after crash only adds are provided > claim not to use n-way synchronisation. In most cases it is only bad > directory design that leads to a request for multimaster systems. > One-way synchronisation in combination with chaining is has the same > effects as multimaster but is much more reliable. > Yes, maybe. We use Heartbeat to switch the Service-IP between the masters, that's why we have always exactly one primary and one secondary. The N-Way or MirrorMode in that case is usefull because we don't have to switch between different master-slave configs for ldap, but keeping two identical configs .... Regards Irina

1 0

Re: Syncrepl Problem after repeatedly reboot
by HRZ Konten 27 Jan '10

27 Jan '10

>> Is there an easy way to force a new replication on the second node? >> > I will really appreciate your help... >> > Just delete the database on the second node and setup a new node. > Well, that is rather a worst case scenario, but if this is the only was to get them synced... This situation is a little bit strange, then it says if the contextCSN is equal then the systems are synced. In my case I had equal contextCSN and diefferent number of entries and no error message in the logs. How could I be sure that my both nodes are synced? Is there any other way to check that? Then if I don't know that they are out of synchow could I start the rebuild of the second node...

2 1

Question about contextCSN's
by Ryan Steele 27 Jan '10

27 Jan '10

I'm replicating both the config and backend databases between two boxes. Everything seems fine, but for some reason when I query them both for the contextCSN, the config database returns only one while the backend database returns two, as seen below: ## ldap1 replication config olcDatabase={0}config.ldif:olcSyncrepl: {0}rid=001 provider=ldap://ldap1.example.com binddn="cn=admin,cn=co olcDatabase={0}config.ldif- nfig" bindmethod=simple credentials="SECRET" searchbase="cn=config" type olcDatabase={0}config.ldif- =refreshAndPersist retry="5 10 300 15" timeout=1 olcDatabase={0}config.ldif:olcSyncrepl: {1}rid=002 provider=ldap://ldap2.example.com binddn="cn=admin,cn=co olcDatabase={0}config.ldif- nfig" bindmethod=simple credentials="SECRET" searchbase="cn=config" type olcDatabase={0}config.ldif- =refreshAndPersist retry="5 10 300 15" timeout=1 olcDatabase={1}hdb.ldif:olcSyncrepl: {0}rid=003 provider=ldap://ldap1.example.com binddn="cn=admin,dc=exa olcDatabase={1}hdb.ldif- mple,dc=com" bindmethod=simple credentials="SECRET" searchbase="dc=example, olcDatabase={1}hdb.ldif- dc=com" type=refreshAndPersist retry="5 10 300 15" timeout=1 olcDatabase={1}hdb.ldif:olcSyncrepl: {1}rid=004 provider=ldap://ldap2.example.com binddn="cn=admin,dc=exa olcDatabase={1}hdb.ldif- mple,dc=com" bindmethod=simple credentials="SECRET" searchbase="dc=example, olcDatabase={1}hdb.ldif- dc=com" type=refreshAndPersist retry="5 10 300 15" timeout=1 ## ldap2 replication config olcDatabase={0}config.ldif:olcSyncrepl: {0}rid=001 provider=ldap://ldap1.example.com binddn="cn=admin,cn=co olcDatabase={0}config.ldif- nfig" bindmethod=simple credentials="SECRET" searchbase="cn=config" type olcDatabase={0}config.ldif- =refreshAndPersist retry="5 10 300 15" timeout=1 olcDatabase={0}config.ldif:olcSyncrepl: {1}rid=002 provider=ldap://ldap2.example.com binddn="cn=admin,cn=co olcDatabase={0}config.ldif- nfig" bindmethod=simple credentials="SECRET" searchbase="cn=config" type olcDatabase={0}config.ldif- =refreshAndPersist retry="5 10 300 15" timeout=1 olcDatabase={1}hdb.ldif:olcSyncrepl: {0}rid=003 provider=ldap://ldap1.example.com binddn="cn=admin,dc=exa olcDatabase={1}hdb.ldif- mple,dc=com" bindmethod=simple credentials="SECRET" searchbase="dc=example, olcDatabase={1}hdb.ldif- dc=com" type=refreshAndPersist retry="5 10 300 15" timeout=1 olcDatabase={1}hdb.ldif:olcSyncrepl: {1}rid=004 provider=ldap://ldap2.example.com binddn="cn=admin,dc=exa olcDatabase={1}hdb.ldif- mple,dc=com" bindmethod=simple credentials="SECRET" searchbase="dc=example, olcDatabase={1}hdb.ldif- dc=com" type=refreshAndPersist retry="5 10 300 15" timeout=1 ## Query root@ldap1:~# ldapsearch -x -H ldap://localhost -D 'cn=admin,cn=config' -y /etc/ldap.secret -b 'cn=config' -s base -LL contextCSN; ldapsearch -x -H ldap://localhost -D 'cn=admin,dc=example,dc=com' -y /etc/ldap.secret -b 'dc=example,dc=com' -s base -LL contextCSN version: 1 dn: cn=config contextCSN: 20091012205437.323661Z#000000#001#000000 version: 1 dn: dc=example,dc=com contextCSN: 20100126210305.876171Z#000000#001#000000 contextCSN: 20091018205321.288716Z#000000#002#000000 I checked the documentation, but didn't see anything that clarified this behavior. I've also checked the logs, and there are no replication failures in them. So what is the reason for this? The only difference I can see between the config and backend is that the backend database has two overlays (autogroup and syncprov) and the config db has only one (syncprov), but that may just be an irrelevant coincidence. I would be most appreciative if somebody could shed some light on this for me. Thanks! Respectfully, Ryan

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-software January 2010