openldap-technical March 2012

openldap-technical@openldap.org

96 participants
116 discussions

RE: OPENLDAP SYNCREPL
by Quanah Gibson-Mount 15 Mar '12

15 Mar '12

--On Wednesday, March 14, 2012 4:25 PM -0400 "Borresen, John - 0442 - MITLL" <john.borresen(a)ll.mit.edu> wrote: > Saw a post of yours from a while back, so I backed up the consumer's dbase > and moved the directory out of the way, then ran slapadd and brought slapd > up on the consumer. Yes, when you go to reload a server, you must delete the existing DB. > Things look more in-sync with each other than they did. > > Question: I noticed that there are seven "reqStart" entries in the > cn=accesslog on the Provider machine. They were there when I was testing > and beating my head against the wall. Should they be deleted manually > since I used slapcat/slapadd? Or does it matter? It doesn't matter. The point of syncrepl is it is intelligent enough to ignore data it's already replicated. --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

Scaling LDAP
by Gaurav Gugnani 15 Mar '12

15 Mar '12

Hi All, First of all thks for helping me out with the issues on openLDAP. Well today, my query is pretty generic and lot many people working on LDAP would face such an issues. We are using openldap 2.4.26 with BDB as backend. We've installed the setup on linux machine of 64 bit with 4GB ram. Now, currently we have some 10K records in it and its working perfectly fine. Our systems is running under replication - syncrepl. However, in near future we can foresee some million of records to turn up. So, Can any one please advise - What are the different Scaling options available with LDAP? I need to do some research and test our cases. Please suggest. Thanks and Regards, Gaurav Gugnani

3 3

RE: OPENLDAP SYNCREPL
by Quanah Gibson-Mount 14 Mar '12

14 Mar '12

--On Wednesday, March 14, 2012 2:44 PM -0400 "Borresen, John - 0442 - MITLL" <john.borresen(a)ll.mit.edu> wrote: > Quanah; Pesonally, I use a specific replicator ID for replication that has full read to all data on the master, and make that the first ACL. Then I don't have to worry whether or not the other ACLs interfere. At this point, if you haven't, I'd wipe out the replicas DB and make it do a fresh sync, so you can confirm it is working properly, OR slapcat the master, and use the appropriate flags to slapadd to reload it, and then ensure the replica keeps up to date. If you're using the replica as-is, where you've had an invalid configuration for days, I fully expect the data on the replica to be in an odd state. Make sure nothing is using the replica if you choose to reload it in either method. --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 2

RE: OPENLDAP SYNCREPL
by Quanah Gibson-Mount 14 Mar '12

14 Mar '12

--On Tuesday, March 13, 2012 3:38 PM -0400 "Borresen, John - 0442 - MITLL" <john.borresen(a)ll.mit.edu> wrote: > Maybe it's just that it is near the end of the day...but, first here is my > ldif to add the provider to my cn=accesslog: Look at the example LDIF I provided you. Clearly your base DN of the entry you are trying to add is invalid. --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 4

test060-mt-hot failed for bdb (SunOS 5.10, SPARC)
by Claus Assmann 14 Mar '12

14 Mar '12

test060-mt-hot fails from time to time on SunOS 5.10 (SPARC). Is that a known problem? I can make the logs available (maybe on a webserver); they are large, so I don't want to send them to the list. >>>>> Starting test060-mt-hot for bdb... running defines.sh Running slapadd to build slapd database... 4f5a412b bdb_db_open: warning - no DB_CONFIG file found in directory /obj.SunOS.5.10.sun4/openldap/work/src/tests/testrun/db.1.a: (2). Expect poor performance for suffix "dc=example,dc=com". _#################### 100.00% eta none elapsed none fast! Closing DB... Running slapindex to index slapd database... Starting slapd on TCP/IP port 9011... /obj.SunOS.5.10.sun4/openldap/work/src/tests/../servers/slapd/slapd -s0 -f /obj.SunOS.5.10.sun4/openldap/work/src/tests/testrun/slapd.1.conf -h ldap://localhost:9011/ -d stats Testing basic monitor search... Monitor searches Testing basic mt-hot search: 1 threads (1 x 50000) loops... ./progs/slapd-mtread -H ldap://localhost:9011/ -D cn=Manager,dc=example,dc=com -w secret -e cn=Monitor -m 1 -L 1 -l 50000 Testing basic mt-hot search: 5 threads (1 x 10000) loops... ./progs/slapd-mtread -H ldap://localhost:9011/ -D cn=Manager,dc=example,dc=com -w secret -e cn=Monitor -m 5 -L 1 -l 10000 Testing basic mt-hot search: 100 threads (5 x 100) loops... ./progs/slapd-mtread -H ldap://localhost:9011/ -D cn=Manager,dc=example,dc=com -w secret -e cn=Monitor -m 100 -L 5 -l 100 Random searches Testing random mt-hot search: 1 threads (1 x 50000) loops... ./progs/slapd-mtread -H ldap://localhost:9011/ -D cn=Manager,dc=example,dc=com -w secret -e dc=example,dc=com -f (objectclass=*) -m 1 -L 1 -l 50000 Testing random mt-hot search: 5 threads (1 x 10000) loops... ./progs/slapd-mtread -H ldap://localhost:9011/ -D cn=Manager,dc=example,dc=com -w secret -e dc=example,dc=com -f (objectclass=*) -m 5 -L 1 -l 10000 Testing random mt-hot search: 100 threads (5 x 100) loops... ./progs/slapd-mtread -H ldap://localhost:9011/ -D cn=Manager,dc=example,dc=com -w secret -e dc=example,dc=com -f (objectclass=*) -m 100 -L 5 -l 100 Multiple threads and connection searches Testing basic mt-hot search: 5 threads 5 conns (1 x 10000) loops... ./progs/slapd-mtread -H ldap://localhost:9011/ -D cn=Manager,dc=example,dc=com -w secret -e cn=Monitor -c 5 -m 5 -L 1 -l 10000 slapd-mtread failed (1)! >>>>> test060-mt-hot failed for bdb (exit 1)

1 0

authenticating users !
by Alex Samad - Yieldbroker 13 Mar '12

13 Mar '12

Hi I have 2 backend db setup {2}bdb -> suffix: ou=external,dc=xyz,dc=com {3)ldap -> uri ldap://msad.xyz.com, suffix: dc=xyz,dc=com Say I have a user dn: cn=alex samad,cn=users, dc=xyz,dc=com I create an ldap alias record dn: uid=alex.samad(a)xyz.com, ou=external,dc=xyz,dc=com objectclass: top, extensibleObject, alias aliasedObjectName: cn=alex samad,cn=users, dc=xyz,dc=com I try and login with this DN "uid=alex.samad(a)xyz.com, ou=external,dc=xyz,dc=com" and it fails, when I logging with " cn=alex samad,cn=users, dc=xyz,dc=com " it works. So can I presume the authentication code doesn't follow ldap alias ? Alex

1 0

how to delete backend DB
by Alex Samad - Yieldbroker 13 Mar '12

13 Mar '12

Hi I am trying to delete a backend DB Currently have dn: olcDatabase={-1}frontend,cn=config dn: olcDatabase={0}config,cn=config dn: olcDatabase={1}monitor,cn=config dn: olcDatabase={2}bdb,cn=config I would like to delete olcDatabase={2}bdb,cn=config I tried ldapdelete -v "olcDatabase={2}bdb,cn=config" note- I have ~/.ldaprc setup with URI & SAS_MECH slapd will not let me do it ? I know I can shut down slapd and remove the file. But I am wondering if there is a "proper" way to do it Thanks Alex

2 3

problem about smooth migration from files to ldap
by huwenfeng 13 Mar '12

13 Mar '12

Hi all: I got a non-technical problem here. I have managed to solved the problem of using OpenLDAP to store user and group infomation and successfully logined into Linux Servers using OpenLDAP. In the Linux Server, i got LOCAL groups named like `devel` and `www`, and LOCAL users belong to these groups. Through the /etc/sudoers file, I give different groups with different privileges. In the OpenLDAP database, i defined my own `devel` and `www` groups. and users in OpenLDAP belongs to their corresponding groups. The problem is , if i add ldap into /etc/nsswitch.conf, then only the first pair of (users/groups) get the right privileges from /etc/sudoers. That means, if I put `ldap` before `files`, only the users login through OpenLDAP can use the privileges defined in /etc/sudoers. But if I put `files` before `ldap` in /etc/nsswitch.conf, then only Local (users/groups) pair got the privileges from /etc/sudoer2. I got a bad solution here: give different names to groups from OpenLDAP, and define new privileges in /etc/sudoers for these groups. and after migration, delete the old local groups and old sudo privileges. But this seems to be not that good a solution. I wonder, what might be the best or right way to migrate from (local user/group) to (ldap user/group) smoothly. Any clue or advice will be greatly appreciated. Thank you In advance.

3 3

OPENLDAP SYNCREPL
by Borresen, John - 0442 - MITLL 13 Mar '12

13 Mar '12

All, I've read and re-read (not to mentioned googled) configuring SyncRepl in OpenLDAP dynamic configuration (cn=config)--v2.4.23. Missing something somewhere. Current logging is set to "256" on both Provider and Consumer. On my Master/Provider LDAP server seeing the following: slapd shutdown: waiting for 0 operations/tasks to finish slapd shutdown: initiated bdb_modify: dc=group42,dc=ldap bdb_dn2entry("dc=group42,dc=ldap") bdb_modify_internal: 0x00000001: dc=group42,dc=ldap bdb_modify_internal: replace contextCSN => entry_encode(0x00000001): dc=group42,dc=ldap <= entry_encode(0x00000001): dc=group42,dc=ldap bdb_modify: updated id=00000001 dn="dc=group42,dc=ldap" send_ldap_result: conn=-1 op=0 p=0 send_ldap_result: err=0 matched="" text="" ====> bdb_cache_release_all ====> bdb_cache_release_all slapd destroy: freeing system resources. On my Consumer/Slave Server I am seeing the following: slapd destroy: freeing system resources. syncinfo_free: rid=001 slapd stopped. tail: /var/log/slapd: file truncated do_syncrep2: rid=001 got search entry without Sync State control do_syncrepl: rid=001 rc -1 retrying do_syncrep2: rid=001 got search entry without Sync State control do_syncrepl: rid=001 rc -1 retrying do_syncrep2: rid=001 got search entry without Sync State control do_syncrepl: rid=001 rc -1 retrying do_syncrep2: rid=001 got search entry without Sync State control do_syncrepl: rid=001 rc -1 retrying do_syncrep2: rid=001 got search entry without Sync State control do_syncrepl: rid=001 rc -1 retrying do_syncrep2: rid=001 got search entry without Sync State control do_syncrepl: rid=001 rc -1 retrying do_syncrep2: rid=001 got search entry without Sync State control do_syncrepl: rid=001 rc -1 retrying do_syncrep2: rid=001 got search entry without Sync State control do_syncrepl: rid=001 rc -1 retrying do_syncrep2: rid=001 got search entry without Sync State control do_syncrepl: rid=001 rc -1 retrying do_syncrep2: rid=001 got search entry without Sync State control do_syncrepl: rid=001 rc -1 retrying >From my readings, I understand that the "Sync State Control" error normally indicates that my provider is not set up correctly. As far as I can tell, my modules are correctly loaded and the overlays are loaded to the appropriate database (my case, bdb) to be replicated. The following is from the Provider/Master LDAP Server: My olcDatabase-{1}bdb.ldif (truncated): # more olcDatabase={1}bdb.ldif dn: olcDatabase={1}bdb objectClass: olcDatabaseConfig objectClass: olcBdbConfig olcSuffix: dc=group42,dc=ldap olcAddContentAcl: FALSE olcLastMod: TRUE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcRootDN: cn=ldapadmin,dc=group42,dc=ldap olcRootPW:: ******* olcSyncUseSubentry: FALSE olcMonitoring: TRUE olcDbDirectory: /var/lib/ldap_db/openldap-data olcDbCacheSize: 1000 ... olcDbNoSync: FALSE olcDbDirtyRead: FALSE olcDbIDLcacheSize: 0 olcDbIndex: objectClass eq olcDbIndex: sn eq,sub olcDbIndex: mail eq,sub olcDbIndex: departmentNumber eq olcDbIndex: cn,uid eq,sub olcDbIndex: uidNumber eq olcDbIndex: entryCSN eq olcDbIndex: entryUUID eq olcDbIndex: ipHostNumber eq olcDbIndex: gidNumber,memberUID eq olcDbLinearIndex: FALSE olcDbMode: 0600 olcDbShmKey: 0 olcDbCacheFree: 1 olcDbDNcacheSize: 0 structuralObjectClass: olcBdbConfig entryUUID: 101e6d86-dd1c-4eaa-a26e-d7e201a727f8 creatorsName: cn=config createTimestamp: 20111219143532Z olcDbSearchStack: 32 olcAccess: {0} to attrs=userPassword,shadowLastChange by self write by anonymo us auth by * none olcAccess: {1} to * by * read olcDatabase: {1}bdb entryCSN: 20120313143637.046410Z#000000#001#000000 modifiersName: cn=config modifyTimestamp: 20120313143637Z # ll olcDatabase={1}bdb total 16 -rw------- 1 ldap ldap 453 Mar 12 10:50 olcOverlay={0}syncprov.ldif -rw------- 1 ldap ldap 505 Feb 29 11:16 olcOverlay={1}accesslog.ldif The olcOverlay={0}syncrpov.ldif # more olcDatabase={1}bdb/olcOverlay={0}syncprov.ldif dn: olcOverlay={0}syncprov objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {0}syncprov olcSpNoPresent: TRUE structuralObjectClass: olcSyncProvConfig entryUUID: 8572b589-f594-44a6-91fe-0de741afbcca creatorsName: cn=admin,cn=config createTimestamp: 20120224171809Z olcSpReloadHint: TRUE olcSpCheckpoint: 1000 60 entryCSN: 20120312145000.123929Z#000000#001#000000 modifiersName: cn=admin,cn=config modifyTimestamp: 20120312145000Z The olcOverlay={1}accesslog.ldif: # more olcDatabase={1}bdb/olcOverlay={1}accesslog.ldif dn: olcOverlay={1}accesslog objectClass: olcOverlayConfig objectClass: olcAccessLogConfig olcOverlay: {1}accesslog olcAccessLogDB: cn=accesslog olcAccessLogOps: writes olcAccessLogPurge: 07+00:00 01+00:00 olcAccessLogSuccess: TRUE structuralObjectClass: olcAccessLogConfig entryUUID: eea1e438-6385-4660-807b-bb270eb4843a creatorsName: cn=admin,cn=config createTimestamp: 20120229161649Z entryCSN: 20120229161649.880441Z#000000#000#000000 modifiersName: cn=admin,cn=config modifyTimestamp: 20120229161649Z ***The following is on the Consumer/Slave Server*** The olcDatabase={2}bdb.ldif (truncated): # more olcDatabase={2}bdb.ldif dn: olcDatabase={2}bdb objectClass: olcDatabaseConfig objectClass: olcBdbConfig olcSuffix: dc=group42,dc=ldap olcAddContentAcl: FALSE olcLastMod: TRUE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcRootDN: cn=ldapadmin,dc=group42,dc=ldap olcRootPW:: ********* olcMonitoring: TRUE olcDbDirectory: /var/lib/ldap_db/openldap-data olcDbCacheSize: 1000 ... olcDbNoSync: FALSE olcDbDirtyRead: FALSE olcDbIDLcacheSize: 0 olcDbIndex: objectClass eq olcDbIndex: cn,uid eq,sub olcDbIndex: sn eq,sub olcDbIndex: mail eq,sub olcDbIndex: departmentNumber eq olcDbIndex: entryCSN eq olcDbIndex: entryUUID eq olcDbIndex: uidNumber eq olcDbIndex: gidNumber eq olcDbLinearIndex: FALSE olcDbMode: 0600 olcDbSearchStack: 16 olcAccess: {0} to attrs=userPassword,shadowLastChange by self write by anonymo us auth by * none olcAccess: {1} to * by * read olcDbShmKey: 0 olcDbCacheFree: 1 olcDbDNcacheSize: 0 structuralObjectClass: olcBdbConfig entryUUID: e6971058-e0f0-4160-aaca-a18b24d22008 creatorsName: cn=config createTimestamp: 20120229205835Z olcDatabase: {2}bdb olcUpdateRef: ldaps://gp42-admin2.group42.ldap:636 olcMirrorMode: TRUE olcSyncrepl: {0}rid=1 provider=ldaps://gp42-admin2.group42.ldap:636 bindmethod =simple binddn="cn=ldapadmin,dc=group42,dc=ldap" credentials=******* interva l=01:00:00:00 searchbase="dc=group42,dc=ldap" logbase="cn=accesslog" schemach ecking=on type=refreshAndPersist retry="60 +" filter="(objectClass=*)" attrs= "*,+" syncdata=accesslog starttls=no tls_cacertdir=/usr/local/openldap-2.4.23 /etc/openldap/cacerts entryCSN: 20120313150609.224840Z#000000#000#000000 modifiersName: cn=admin,cn=config modifyTimestamp: 20120313150609Z Not sure what I am missing, nor where I am missing it. Any assistance would be helpful. Dave Borresen Solaris/Linux Systems Administrator Surveillance Systems Group MIT Lincoln Laboratory 244 Wood Street Lexington, MA 02420 P: 781-981-2954 F: 781-981-5344 john.borresen(a)ll.mit.edu

3 6

Re: olcTLSVerifyClient: demand not taking effect
by Peter Wood 13 Mar '12

13 Mar '12

On Mon, Mar 12, 2012 at 9:41 PM, Quanah Gibson-Mount <quanah(a)zimbra.com>wrote: > --On Monday, March 12, 2012 6:52 PM -0700 Peter Wood < > peterwood.sd(a)gmail.com> wrote: > > Hi, >> >> >> I setup openldap-2.4.23 server >> > > Why? I'd suggest you start with the current release, 2.4.30. You may > also want to look at <http://www.openldap.org/its/**index.cgi/?findid=7197<http://www.openldap.org/its/index.cgi/?findid=7197> > > > > That's the openldap version in centos6.2 repo. In production I try to stick with stock versions. Also I tried all variations of olcTLSVerifyClient: [demand|hard|true] with the same result. I don't think StartTLS is enabled. I'm wondering if just setting olcTLSCACertificateFile, olcTLSCertificateFile and olcTLSCertificateKeyFile is enough to get StartTLS enabled. It's very frustrating. I'd hate to go to ldaps just because I can't get StartTLS working. Is there anything else I have to set on the server to get StartTLS working? Thanks Peter

6 6

← Newer
1
...
5
6
7
8
9
10
11
12
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical March 2012