openldap-technical July 2013

openldap-technical@openldap.org

68 participants
86 discussions

mdb grows to olcDbMaxsize if searched before syncrepl completes.
by Jancewicz, Russell 11 Jul '13

11 Jul '13

I am experiencing strange behavior when running an mdb database, as compared to the same system configured with hdb. If I conduct any queries while the server is receiving its initial data the server via syncrepl it stops receiving new entries and the data.mdb file balloons to the olcDbMaxsize value. I have tried adjusting configuration settings but regardless this continues to occur is this to be expected with mdb? It should be noted that if I wait for the entire database to replicate I can query the database fine and the size of data.mdb does not change. Furthermore if new changes are propagated down to the replica the issue does not arise. Any help would be appreciated. Please find below configuration ldifs and version information. -Russell J. Jancewicz University of Connecticut Version: @(#) $OpenLDAP: slapd 2.4.35 (Jun 17 2013 12:21:32) $ My olcDatabaseConfig: # {1}mdb, config dn: olcDatabase={1}mdb,cn=config changetype: add objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: mdb olcDbDirectory: /srv/ldap/example.com olcSuffix: dc=example,dc=com olcRootDN: dc=example,dc=com olcRootPW: secret olcDbMaxsize: 4294967296 olcDbNoSync: FALSE olcReadOnly: TRUE olcDbCheckpoint: 512 30 olcDbIndex: default pres,eq olcAccess: to * by dn.exact="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage by * break olcAccess: to * by * none olcSyncrepl: rid=101 provider=ldap://replica0.ldap.example.com starttls=critical bindmethod=simple binddn="dc=example,dc=com" credentials=secret searchbase="dc=example,dc=com" type=refreshAndPersist retry="5 5 300 +" olcSyncrepl: rid=102 provider=ldap://replica1.ldap.example.com starttls=critical bindmethod=simple binddn="dc=example,dc=com" credentials=secret searchbase="dc=example,dc=com" type=refreshAndPersist retry="5 5 300 +" # {1}memberof, {1}hdb, config dn: olcOverlay={0}memberof,olcDatabase={1}mdb,cn=config objectClass: top objectClass: olcOverlayConfig objectClass: olcMemberOf olcOverlay: {0}memberof

1 0

caseIgnoreMatch for Country String
by Maucci, Cyrille 11 Jul '13

11 Jul '13

Hello gurus, When I have this piece of schema included in my slapd.conf file... attributetype ( 1.3.6.1.4.1.11.11.1.1.1.1.402 NAME ( 'TestCountryString' 'TestCountryStringSyn' ) DESC 'Test Country String' EQUALITY caseIgnoreMatch ORDERING caseIgnoreOrderingMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.11 SINGLE-VALUE ) ... my 2.4.32 slapd -Tt complains with this error: line 8 attributetype: AttributeType inappropriate matching rule: "caseIgnoreMatch". My understanding of http://tools.ietf.org/html/rfc4517 is that caseIgnoreMatch is valid for country string: "The caseIgnoreMatch rule compares an assertion value of the Directory String syntax to an attribute value of a syntax (e.g., the Directory String, Printable String, Country String, or Telephone Number syntax) whose corresponding ASN.1 type is DirectoryString or one of its alternative string types. " Could you confirm whether this is a bug in openldap or simply a misunderstanding from me ? Thanks in advance ++Cyrille

2 1

RE: configuring monitor database in SLES11 SP2
by Dieter Klünter 11 Jul '13

11 Jul '13

Hi, Am Wed, 10 Jul 2013 16:09:17 +0200 schrieb "Ulrich Windl" <Ulrich.Windl(a)rz.uni-regensburg.de>: > Hi! > > I wonder how to configure the monitor database with dynamic > configuration in general ,and then specifically for SLES11 SP2 > (possibly slapd isn't configured for that, but I'm not sure). The > docs still describe the slapd.conf-way... first check if back-monitor is statically build in /usr/lib/openldap/slapd -VVV if so, slapadd dn -- Dieter Klünter | Systemberatung http://dkluenter.de GPG Key ID:DA147B05 53°37'09,95"N 10°08'02,42"E -- Dieter Klünter | Systemberatung http://dkluenter.de GPG Key ID:DA147B05 53°37'09,95"N 10°08'02,42"E

2 1

High load times with mdb
by Bill MacAllister 11 Jul '13

11 Jul '13

With the release of Debian 7 (wheezy) I was rebuilding a couple test systems and was surprised to find that the load times I am seeing for populating the mdb database with slapd have gone up dramatically. The load for a master server that was taking about 10 minutes just took 35 minutes. The slave is worse. A normal load time is 20 minutes and it is at 31 minutes now with an eta of about 2.5 hours. These systems are using OpenLDAP 2.4.35. Here are some relevent bits from the configuration. dn: cn=config olcToolThreads: 2 dn: olcDatabase={2}mdb,cn=config olcDbCheckpoint: 1024 5 olcDbEnvFlags: writemap olcDbEnvFlags: nometasync olcDbNoSync: FALSE olcDbMaxSize: 85899345920 The systems are Dell r610s with 16 gbyte of memory. Our database is currently 3.2G on the master server. I have been loading wheezy/2.4.35 databases for weeks now in preparation upgrading the OS and installing the new version of OpenLDAP on our production servers. This is the first time I have seen this. I fiddled with the hardware enough to the point I don't think it is a hardware problem. There is not really much tuning to do with mdb and I would appreciate some suggestions for what to look at next. Bill -- Bill MacAllister Infrastructure Delivery Group, Stanford University

3 5

"No such object" error with translucent overlay and base scope search
by Steve Eckmann 10 Jul '13

10 Jul '13

We found that we get a "No such object" error from the translucent overlay when we do a search like this: ldapsearch -x -H ldaps://localhost -LLL \ -b "cn=John Doe,ou=Users,dc=example,dc=com" -s base \ -D "cn=admin,dc=example,dc=com" -w admin \ '(&)' if there is no entry for "cn=John Doe,ou=Users,dc=example,dc=com" in the local database, whether or not the remote entry exists. It seems like a mistake for the translucent overlay to report an error if the remote entry exists, since it only means that we haven't added any local attributes yet. Is there a way to suppress the error result when the proxied server returns an entry, so we don't have to hack around this weirdness in our client? Thanks. Steve

2 2

RE: unable top add ppolicy_overlay.ldif
by Sotomayor, Vicente (ITD) 10 Jul '13

10 Jul '13

I had a similar error using RH 6 and so I used pwdAttribute: 2.5.4.35 instead of pwdAttribute: userPassword

3 2

configuring monitor database in SLES11 SP2
by Ulrich Windl 10 Jul '13

10 Jul '13

Hi! I wonder how to configure the monitor database with dynamic configuration in general ,and then specifically for SLES11 SP2 (possibly slapd isn't configured for that, but I'm not sure). The docs still describe the slapd.conf-way... Regards, Ulrich

1 0

Need Help on ACL
by pradyumna dash 10 Jul '13

10 Jul '13

Hi, Need a help related to ACL. I need to setup some basic ACL for LDAP, I need Manager only should have access to the entire tree both read and write and only users under ou=operation can have a read only access to the tree. Currently i dont have any ACL in the slapd.conf file. Would be great if you can share the ACL. Please help. Regards, /Pradyumna

2 1

unable top add ppolicy_overlay.ldif
by Michael Roth 09 Jul '13

09 Jul '13

I'm using Ubuntu 12.04 server running OpenLDAP-2.4.28. I'm following this tutorial HERE<http://raerek.blogspot.com/2012/09/openldap-password-policy-on-ubuntu-1204.…> When I get to the step to add the ppolicy_overlay.ldif I get this error: ldapadd -x -D "cn=admin,cn=config" -w secret -f ppolicy_overlay.ldif adding new entry "olcOverlay={1}ppolicy,olcDatabase={1}hdb,cn=config" ldap_add: Other (e.g., implementation specific) error (80) additional info: User Schema load failed for attribute "pwdAttribute". Error code 17: attribute type undefined What could the issue be? future thanks!

1 0

Mirror mode replication breaks at times.
by Pradyumna 08 Jul '13

08 Jul '13

Hi, I have configured mirror mode replication. It's 2 node. Everything works fine but if I don't work on the server or say 30/40 mins or so and then when I try to add or delete any users or groups it don't get replicated to the other node. Am not getting any error in the logs and if I restart the slapd service it's syncs again and giving expected results. The same setup I have in the test environment and its works like a charm the only difference in this setup is that the 2 servers are hosted on 2 different DC geographically separated where as in test they are in same DC. Am using the openldap version which comes by default with RHEL 6.3. If it would have been a version issue then I should have expected the same result in test as well? Please help. Regards, /Pradyumna Sent from my iPhone

4 3

← Newer
1
2
3
4
5
6
7
8
9
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical July 2013