openldap-technical

openldap-technical@openldap.org

24 participants
9804 discussions

contextCSN wanished on 2.3 consumers
by Turbo Fredriksson 18 Jun '12

18 Jun '12

Everything was working yesterday, I had upgraded my provider and two consumers to 2.4.31 and got a Nagios test working - all four consumers (two 2.4.31 and two 2.3.43 which can't/won't be upgraded at this time for various reasons) where all in sync. Their contextCSN mached perfectly. I got in this morning, showed of (with some pride :) the Nagios checks etc to my co workers. Started working on other things and a few minutes later another coworker came in complaining that the Nagios tests showed that the two 2.3 servers where 10 days old! Looking at the contextCSN on all servers showed that they where (suddenly!!) missing from the 2.3 servers. And No one have been fiddeling with the config or the database. Any idea what could have happened and how to fix it? -- ... but you know as soon as Oracle starts waving its wallet at a Company it's time to run - fast. /illumos mailing list

1 0

GCC 4.7
by Turbo Fredriksson 17 Jun '12

17 Jun '12

Has anyone tried compile OpenLDAP with gcc 4.7? Is there any speed increase noticed? Gcc 4.7 'is supposed' to make applications up to 50% faster, so... ? -- ... but you know as soon as Oracle starts waving its wallet at a Company it's time to run - fast. /illumos mailing list

1 0

Re: Problem with slapo-lastbind => segfault
by Mark Goldenstein 16 Jun '12

16 Jun '12

Hello, I'm trying to set up LDAP to track the last login of users via the slapo-lastbind overlay. I'm using the the OpenLDAP package supplied with Ubuntu 10.04 LTS. I've cloned the git repository referenced on openldap.org, switched to the lastbind directory in contrib and then ran make and make install. Then I've copied the lastbind.so* and lastbind.la files to /usr/lib/ldap and adjusted the permissions accordingly. Afterwards, I've added lastbind to cn=module to load the module. However, slapd does not start anymore and I get the following error in syslog: kernel: [2716850.919891] slapd[15422]: segfault at 6 ip 00007f0e1555ba36 sp 00007fff70b26118 error 4 in libc-2.11.1.so[7f0e15435000+17a000] Am I doing something wrong? Best regards, Mark

2 2

Monitoring 2.3.43?
by Turbo Fredriksson 16 Jun '12

16 Jun '12

First of: I know it's old, we ARE going to upgrade at the next service interval in a few weeks! But in the meantime, is there any way to know/figure out if the master and it's slave(s) are in sync? One idea, of using a special object which is written to every x minute and then checked for consistency came up... Of course it's not a nice solution, but it is A solution... The reason for this is that yesterday our secondary LDAP server (the primary read server) stopped returning queries (might be a file lock or open filehandles problem - exact reason unknown for the moment). And for some reason, the primary LDAP server (the one we use for writes, the sync master) had an old version of the database - we THINK it happened at the last power failure in that serverroom. It brought up an old version (bdb problems possibly). So the failover to the master worked, but it was to old. And i didn't manage to do a recover on the failed bdb database. Luckily we had a SECOND replica in another city (which was in sync with the changes we did just a few hours earlier), so I did a dump of that database and loaded the primary replica (the one that failed/hung/crashed) with that. But the fact that the replica master and the slaves where out of sync worries us a little. This will be fixed correctly with an upgrade, but until then we would like to have at least _some_ way of checking the status of the sync... Any ideas for a quick hack? -- ... but you know as soon as Oracle starts waving its wallet at a Company it's time to run - fast. /illumos mailing list

6 10

Access Log: dynamic configuration problems.
by Francesco Belli 15 Jun '12

15 Jun '12

Hello everybody, I'm using OpenLdap version 2.4.24 (4 Oct 2011) on a RedHat 6 machine. I use dynamic configuration and I'm having some problems setting up accesslog overlay. I didn't change the following file in etc/openldap/slapd.d/cn=config/ : olcDatabase={-1}frontend.ldif olcDatabase={0}config.ldif olcDatabase={1}monitor.ldif I moved olcDatabase={2}bdb.ldif to olcDatabase={3}bdb.ldif, in this way it is loaded after the access log database that is defined in the new olcDatabase={2}bdb.ldif Here there are the two configuration files: ######### olcDatabase={2}bdb.ldif ############### dn: olcDatabase={2}bdb objectClass: olcDatabaseConfig objectClass: olcBdbConfig olcDatabase: {2}bdb olcDbDirectory: /var/lib/ldap/accesslog/ olcSuffix: cn=accesslog olcAccess: {0}to dn.subtree="cn=accesslog" by dn.exact="uid=manager,ou=Users,dc=domain,dc=com" manage by dn.exact="cn=config" read olcLastMod: TRUE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcRootDN: cn=accesslog olcSizeLimit: unlimited olcTimeLimit: unlimited olcMonitoring: TRUE olcDbCacheSize: 10000 olcDbCheckpoint: 64 5 olcDbNoSync: FALSE olcDbDirtyRead: FALSE olcDbIDLcacheSize: 10000 olcDbIndex: entryCSN eq olcDbIndex: objectClass eq olcDbIndex: reqEnd eq olcDbIndex: reqResult eq olcDbIndex: reqStart eq olcDbLinearIndex: FALSE olcDbMode: 0600 olcDbSearchStack: 16 olcDbShmKey: 0 olcDbCacheFree: 1 olcDbDNcacheSize: 0 ######### olcDatabase={3}bdb.ldif ############### dn: olcDatabase={3}bdb objectClass: olcDatabaseConfig objectClass: olcBdbConfig olcDatabase: {3}bdb olcSuffix: dc=domain,dc=com olcAddContentAcl: FALSE olcLastMod: TRUE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcRootDN: cn=Manager, dc=domain,dc=com olcRootPW: pippopippo olcSyncUseSubentry: FALSE olcMonitoring: TRUE olcDbDirectory: /var/lib/ldap olcDbCacheSize: 1000 olcDbCheckpoint: 1024 15 olcDbNoSync: FALSE olcDbDirtyRead: FALSE olcDbIDLcacheSize: 0 olcDbIndex: objectClass pres,eq olcDbIndex: cn pres,eq,sub olcDbIndex: uid pres,eq,sub olcDbIndex: uidNumber pres,eq olcDbIndex: gidNumber pres,eq olcDbIndex: mail pres,eq,sub olcDbIndex: ou pres,eq,sub olcDbIndex: loginShell pres,eq olcDbIndex: sn pres,eq,sub olcDbIndex: givenName pres,eq,sub olcDbIndex: memberUid pres,eq,sub olcDbIndex: nisMapName pres,eq,sub olcDbIndex: nisMapEntry pres,eq,sub olcDbIndex: entryCSN eq olcDbIndex: entryUUID eq olcDbLinearIndex: FALSE olcDbMode: 0600 olcDbSearchStack: 16 olcDbShmKey: 0 olcDbCacheFree: 1 olcDbDNcacheSize: 0 structuralObjectClass: olcBdbConfig entryUUID: 9ef24df8-376a-1031-947f-692d47ac0213 creatorsName: cn=config createTimestamp: 20120521082800Z entryCSN: 20120521082800.652940Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20120521082800Z olcOverlay: syncprov olcSpCheckpoint: 50 10 olcSpSessionlog: 100 olcOverlay: accesslog olcAccessLogDB: cn=accesslog olcAccessLogOps: writes olcAccessLogSuccess: TRUE olcAccessLogPurge: 07+00:00 01+00:00 When I run slapd -d 1 I obtain the following error that makes slapd to terminate: backend_startup_one: starting "cn=accesslog" bdb_db_open: warning - no DB_CONFIG file found in directory /var/lib/ldap/accesslog/: (2). Expect poor performance for suffix "cn=accesslog". bdb_db_open: database "cn=accesslog": dbenv_open(/var/lib/ldap/accesslog/). backend_startup_one: starting "dc=domain,dc=com" bdb_db_open: warning - no DB_CONFIG file found in directory /var/lib/ldap: (2). Expect poor performance for suffix "dc=domain,dc=com". bdb_db_open: database "dc=domain,dc=com": dbenv_open(/var/lib/ldap). accesslog: "logdb <suffix>" missing or invalid. backend_startup_one (type=bdb, suffix="dc=domain,dc=com"): bi_db_open failed! (1) slapd shutdown: initiated It seems that for some reason slapd doesn't like the olcAccessLogDB directive specified in olcDatabase={3}bdb.ldif. I tried some other configuration (I think that this is the more correct) but the problem is always there. Thanks for any help, Francesco

2 1

Re: syncrepl, version compatibility, partial sync
by Quanah Gibson-Mount 14 Jun '12

14 Jun '12

--On Thursday, June 14, 2012 11:00 AM -0700 Ryan Lovett <relovett(a)gmail.com> wrote: > > On Thu, Jun 14, 2012 at 10:55 AM, Quanah Gibson-Mount <quanah(a)zimbra.com> > wrote: > > > --On Thursday, June 14, 2012 10:31 AM -0700 Ryan Lovett > <relovett(a)gmail.com> wrote: > > Are there any known syncrepl compatibility issues between different 2.4.x > versions? We have a master slapd running 2.4.9 and a consumer running > 2.4.21 and are having a syncrepl problem and only some of the data is > being synced. The consumer slapd logs messsages of the form: > > > a) Always run the same versions everywhere > > b) Both of those versions are out of date, and have known issues with > syncrepl. > > c) Upgrade to 2.4.31. > > > > > > I see, thanks for your feedback. We had been hoping we could rely on our > vendor's (Ubuntu LTS; 8.04 and 10.04) releases. I'll build from source. a) Please keep replies on the list b) Read <http://www.openldap.org/faq/data/cache/1456.html> from Debian c) Link to OpenSSL when you build your own d) Read <http://www.openldap.org/software/release/changes.html> --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 1

Re: syncrepl, version compatibility, partial sync
by Quanah Gibson-Mount 14 Jun '12

14 Jun '12

--On Thursday, June 14, 2012 11:00 AM -0700 Ryan Lovett <relovett(a)gmail.com> wrote: > > On Thu, Jun 14, 2012 at 10:55 AM, Quanah Gibson-Mount <quanah(a)zimbra.com> > wrote: > > > --On Thursday, June 14, 2012 10:31 AM -0700 Ryan Lovett > <relovett(a)gmail.com> wrote: > > Are there any known syncrepl compatibility issues between different 2.4.x > versions? We have a master slapd running 2.4.9 and a consumer running > 2.4.21 and are having a syncrepl problem and only some of the data is > being synced. The consumer slapd logs messsages of the form: > > > a) Always run the same versions everywhere > > b) Both of those versions are out of date, and have known issues with > syncrepl. > > c) Upgrade to 2.4.31. > > > > > > I see, thanks for your feedback. We had been hoping we could rely on our > vendor's (Ubuntu LTS; 8.04 and 10.04) releases. I'll build from source. Please keep replies on-list. Thanks. You may wish to read: <http://www.openldap.org/faq/data/cache/1456.html> written by one of the Debian OpenLDAP maintainers. I also suggest reading: <http://www.openldap.org/software/release/changes.html> Finally, when you go to build it yourself, I highly recommend linking to OpenSSL, rather than GnuTLS. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

2 1

syncrepl, version compatibility, partial sync
by Ryan Lovett 14 Jun '12

14 Jun '12

Are there any known syncrepl compatibility issues between different 2.4.x versions? We have a master slapd running 2.4.9 and a consumer running 2.4.21 and are having a syncrepl problem and only some of the data is being synced. The consumer slapd logs messsages of the form: entries have identical CSN ou=something,dc=something 20120614015145.546743Z#000000#000#000000 and syncrepl_entry: rid=200 entry unchanged, ignored (ou=other,dc=something) syncrepl_message_to_entry: rid=200 mods check (objectClass: value #8 invalid per syntax) do_syncrepl: rid=200 rc 21 retrying (9 retries left) In searching for similar reports we came across various solutions such as making sure the provider URI in the consumer's slapd.conf matches the server's URI at launch. The server was listening on ldap:/// and the consumer was set to connect to ldap://server.name/ though we modified the server to only listen on ldap://server.name/. We also tried stopping both consumer and master, flushing the databases on both, slapadding data back into the master, then starting both instances. The log messages return however just with updated CSN stamps. The consumer is never able to pull down the full data even with refreshAndPersist with sensible retry intervals. Thanks for your time, Ryan

2 1

loglevel expected performance impact
by Berend De Schouwer 14 Jun '12

14 Jun '12

I'm running some 2.4.23 servers, and I've encountered some slowdown on loglevel other than 0. Even 256 (stats; recommended) impacts about a 4x slowdown on queries. Logging is to syslog. Running ldapsearch slows from 0.005-0.010 seconds to about 0.030-0.040 seconds; and that includes loading the binary. That's from localhost to remove potential DNS lookups. I stumbled across this when logging was wrong, and the slowdown was 100x. I'm aware that 2.4.23 isn't the latest version. I'm also quite happy, for now, to run loglevel 0. I'm wondering if this is the expected behaviour, given that it's the recommended configuration. Or should I go dig to find the slowdown? (I did check the indexes, and db_stats, etc. All seems fine.) I apologise for the disclaimer, Berend CONFIDENTIALITY NOTICE The contents of and attachments to this e-mail are intended for the addressee only, and may contain the confidential information of Argility (Proprietary) Limited and/or its subsidiaries. Any review, use or dissemination thereof by anyone other than the intended addressee is prohibited. If you are not the intended addressee please notify the writer immediately and destroy the e-mail. Argility (Proprietary) Limited and its subsidiaries distance themselves from and accept no liability for unauthorised use of their e-mail facilities or e-mails sent other than strictly for business purposes.

3 3

OLC Configuration on RHEL6
by Roger Martinez 12 Jun '12

12 Jun '12

Greetings all, I've only just recently learned about configuring and using LDAP using slapd.conf configuration. Recently, however, I have been asked to configure LDAP on a server running Red Hat Enterprise Linux 6. I've run into a few problems. First of all, when I try to connect via LDAP Browser/Editor to view the cn=config list, it connects but gives me Error 32 - No Such Object. The following is the the cfg file that Ldap Browser/Editor uses to connect to the session: ################################# # # # LDAP Browser v2.8 config file # # # # cn=config all attributes # # # ################################# host=[my server's IP address] port=389 sslport=636 basedn=cn=config version=3 managerdn=cn=Manager,cn=config managerlogin=no autoconnect=no leafindicatortype=int leafindicator=numsubordinates managereferrals=no supportsmovetree=no derefaliases=never sorttree=ascending ldap.attributes.list=* + The managerdn i got from the olcRootDN line in olcDatabase={2}bdb.ldif file. And the rest i got from zytrax.com online book ( http://www.zytrax.com/books/ldap/ch14/cn=config.cfg ) My question is, is there any other configuration or any other additional steps that I need to take after yum install in order to make this LDAP server functional? What have I missed? Any help will be much appreciated! Thank you. -- Roger Martinez Intern incNETWORKS, inc.

3 3

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical