openldap-software

openldap-software@openldap.org

2719 discussions

Replication problem using synrepl with TLS (Starttls)
by Germain Maurice 02 Feb '10

02 Feb '10

Hi everybody, I use replication between my openldap provider and an openldap consumer, i use syncrepl over TLS connection. I managed to make it working... but now, it doesn't want to work. I just have done a reboot on the consumer and the replication does not want to work again. Here is the log line i get : slap_client_connect: URI=ldaps://provider.mydomain.net DN="cn=syncrepl,dc=mydomain.net" ldap_sasl_bind_s failed (-1) My openldap servers use cn=config directives, on my consumer i have this : olcSyncrepl: {0}rid=000 provider=*ldap://provider.mydomain.net* searchbase=dc=mydomain.net bindmethod=simple binddn=cn=syncrepl,dc=mydomain.net credentials=XXXXX retry="60 +" type=refreshOnly interval=00:00:10:00 starttls=yes tls_cert=/etc/ssl/certs/ca-cert.pem tls_cacert=/etc/ssl/certs/ca-cert.pem tls_key=/etc/ssl/private/ca-key.pem If you want see more of my configuration have a look to my blog : http://erralt.wordpress.com/2010/01/19/openldap-syncrepl-via-tls-ssl/ Any idea on this error ? ldap_sasl_bind_s failed (-1) Thank you Best regards -- Germain Maurice Administrateur Système Tel : +33.(0)1.42.43.64.13 **linkfluence news & events** 2009 excellence award nominee from ESOMAR 2009 marketing research silver award from semo & marketing magazine (France) 2009 european excellence award recipient (PR evaluation, wahlradar.de, joint project with Publicis Consultants)

1 0

TLS Replication on Ubuntu 9.04
by anjan.prasad＠wipro.com 01 Feb '10

01 Feb '10

Hi, I have configured Multi Master replication on top of that I have configured starttls replication. Intially when I configured and restarted the Slave Open LDAP server, the replication worked fine only for the first time. After that I am getting the below error in the log message slapd[6602]: slap_client_connect: URI=ldap://*****/ DN="cn=admin,dc=**,dc=**,dc=**" ldap_sasl_bind_s failed (49) When I try to do the ldapsearch using -ZZ it fails. Previously without replication configured as a standalone the ldapsearch was working fine with -ZZ and also with ldaps Now after replication configured, I get the below error. ldapsearch -LLL -x -W -D 'cn=admin,dc=**,dc=**,dc=**' -H ldap://<ldapURL> -ZZ '(uid=john)' Enter LDAP Password: ldap_bind: Invalid credentials (49) Any help with this regard will be great help. Thanks & Regards, Anjan Please do not print this email unless it is absolutely necessary. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com

1 0

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 29 Jan '10

29 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 28 Jan '10

28 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 28 Jan '10

28 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

trouble with openldap >2.4.16
by Brett ＠Google 26 Jan '10

26 Jan '10

Hello, I am having trouble with Segfaults on Solaris Sparc, it seems like the sporadic error that some people have coming up during testing, but not others. Oddly, this only happens for me on an older not-patched box myunhappyserver, and NOT a more recently patched box myhappyserver (same slapd/bdb binaries and libraries) The "new" box (happily runs all openldap versions i have tried, up to and including the stable version based on 2.4.19) is : SunOS myhappyserver 5.10 Generic_141414-07 sun4v sparc SUNW,Sun-Fire-T200 The "old" box (segfaults even on simple start sometimes - but very occasionally it will run for awhile before it segfaults) is : SunOS myunhappyserver 5.10 Generic_127111-11 sun4v sparc SUNW,Sun-Fire-T200 >From adb on "myunhappyserver" i get (in response to "adb slapd core_qgpro01_slapd_404_404_1260924086_4710") : ::status debugging core file of slapd (64-bit) from myunhappyserver file: slapd initial argv: /usr/local/openldap/libexec/slapd -f /usr/local/openldap/etc/openldap/slapd_who threading model: multi-threaded using native lwps status: process terminated by SIGSEGV (Segmentation Fault) ::regs %g0 = 0x0000000000000000 %l0 = 0x000000010050ef48 %g1 = 0x000000010551e0d8 %l1 = 0x0000000105522440 %g2 = 0x0000000105551220 %l2 = 0x000000010050f020 %g3 = 0x0000000000000000 %l3 = 0x00000001001225e0 %g4 = 0x0000000000000000 %l4 = 0x0000000100122610 %g5 = 0x0000000000000008 %l5 = 0x0000000000000000 %g6 = 0x0000000000000000 %l6 = 0x00000001001bbdf8 avl_dup_error %g7 = 0xffffffff7e802200 %l7 = 0x0000000105522440 %o0 = 0x0000000000000000 %i0 = 0x000000010551d110 %o1 = 0xffffffffffffffff %i1 = 0x0000000000000000 %o2 = 0x0000000105551220 %i2 = 0x000000010050ef40 %o3 = 0xffffffff00000001 %i3 = 0x0000000105522440 %o4 = 0x0000000000000000 %i4 = 0x000000010050ef60 %o5 = 0x00000000ffffffff %i5 = 0x000000010050eef0 %o6 = 0xffffffff6c27e4f1 %i6 = 0xffffffff6c27e6d1 %o7 = 0x0000000100122bd8 hdb_cache_find_parent+0x124 %i7 = 0x00000001001233a8 hdb_cache_find_id+0x13c %ccr = 0x44 xcc=nZvc icc=nZvc %y = 0x0000000000000000 %pc = 0x0000000100122c8c hdb_cache_find_parent+0x1d8 %npc = 0x0000000100122c90 hdb_cache_find_parent+0x1dc %sp = 0xffffffff6c27e4f1 %fp = 0xffffffff6c27e6d1 %asi = 0x82 %fprs = 0x07 If i can do any more useful things with adb or the like, please provide some example and i'll run it. The ldd for slapd on the "new" server returns : -bash-3.00$ ldd /usr/local/openldap/libexec/slapd libdb-4.8.so => /usr/local/openldap/lib/libdb-4.8.so librt.so.1 => /lib/64/librt.so.1 libperl.so => /usr/local/lib/perl5/5.10.1/sun4-solaris-thread-multi-64/CORE/libperl.so libm.so.2 => /lib/64/libm.so.2 libpthread.so.1 => /lib/64/libpthread.so.1 libicuuc.so.3 => /usr/lib/64/libicuuc.so.3 libicudata.so.3 => /usr/lib/64/libicudata.so.3 libsasl2.so.2 => /usr/local/openldap/lib/libsasl2.so.2 libdl.so.1 => /lib/64/libdl.so.1 libssl.so.0.9.7 => /usr/sfw/lib/sparcv9/libssl.so.0.9.7 libcrypto.so.0.9.7 => /usr/sfw/lib/sparcv9/libcrypto.so.0.9.7 libresolv.so.2 => /lib/64/libresolv.so.2 libgen.so.1 => /lib/64/libgen.so.1 libnsl.so.1 => /lib/64/libnsl.so.1 libsocket.so.1 => /lib/64/libsocket.so.1 libc.so.1 => /lib/64/libc.so.1 libaio.so.1 => /lib/64/libaio.so.1 libmd.so.1 => /lib/64/libmd.so.1 libCrun.so.1 => /usr/lib/64/libCrun.so.1 libmp.so.2 => /lib/64/libmp.so.2 libscf.so.1 => /lib/64/libscf.so.1 libdoor.so.1 => /lib/64/libdoor.so.1 libuutil.so.1 => /lib/64/libuutil.so.1 libssl_extra.so.0.9.7 => /usr/sfw/lib/sparcv9/libssl_extra.so.0.9.7 libcrypto_extra.so.0.9.7 => /usr/sfw/lib/sparcv9/libcrypto_extra.so.0.9.7 /platform/SUNW,Sun-Fire-T200/lib/sparcv9/libc_psr.so.1 /platform/SUNW,Sun-Fire-T200/lib/sparcv9/libmd_psr.so.1 The ldd for slapd on the "old" server adds (which would appear to be harmless) : libgss.so.1 => /usr/lib/64/libgss.so.1 libcmd.so.1 => /lib/64/libcmd.so.1 All compiled libraries are 64 bit, linked against the 64 bit solaris libraries. I am using the same libraries for berkeley 4.8, on all servers. Cheers Brett

3 3

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-software