openldap-technical

openldap-technical@openldap.org

7 participants
9864 discussions

more too old cmp -1 output in the log
by Daniel Jung 09 Oct '14

09 Oct '14

Running on 2.4.39 centos 6.4 in MMR setup ( 4 servers ). 001 is the provider that was being written to at the time. The log is from 001. Could you advise whether my understanding of the log is correct? synrepl consumer on serverID=001 is polling syncrepl provider on serverID=001 and 003 and gets the CSN that is older that its own. We were doing a lot of writes during this time and there were cmp -1 104480 or simiar entries in the log. I had similar issue in the past while running 2.4.37 and it crashed slapd at that time but it didnt this time. The CSN were all synced at the end without any issue. Could you advise what could be causing this? Oct 8 20:36:50 servername slapd[58097]: srs csn 20141008181030.452659Z#000000#001#000000 Oct 8 20:36:50 servername slapd[58097]: log csn 20140723214017.586869Z#000000#001#000000 Oct 8 20:36:50 servername slapd[58097]: cmp -1, too old Oct 8 20:36:50 servername slapd[58097]: log csn 20140723214017.847644Z#000000#001#000000 Oct 8 20:36:50 servername slapd[58097]: cmp -1, too old Oct 8 20:36:50 servername slapd[58097]: log csn 20140723214122.276227Z#000000#001#000000 Oct 8 20:36:50 servername slapd[58097]: cmp -1, too old Oct 8 20:36:50 servername slapd[58097]: log csn 20140723214515.997173Z#000000#001#000000 Oct 8 20:36:50 servername slapd[58097]: cmp -1, too old Oct 8 20:36:50 servername slapd[58097]: log csn 20140723214734.650752Z#000000#001#000000 Oct 8 20:36:50 servername slapd[58097]: log csn 20140723220152.569135Z#000000#003#000000 Oct 8 20:36:50 servername slapd[58097]: cmp -1, too old Oct 8 20:36:50 servername slapd[58097]: log csn 20140723220328.184724Z#000000#001#000000 Oct 8 20:36:50 servername slapd[58097]: cmp -1, too old Oct 8 20:36:50 servername slapd[58097]: log csn 20140723222016.864642Z#000000#001#000000 Oct 8 20:36:50 servername slapd[58097]: cmp -1, too old Oct 8 20:36:50 servername slapd[58097]: log csn 20140723232832.307038Z#000000#003#000000 Oct 8 20:36:50 servername slapd[58097]: cmp -1, too old Oct 8 20:36:50 servername slapd[58097]: log csn 20140723232958.001298Z#000000#003#000000

2 3

syncrepl and LDAP_BUSY on LDBM by ITS#7904
by Леонид Юрьев 08 Oct '14

08 Oct '14

Hi all, We got a trouble with 2.4.40 syncrepl in the the multi-master mode. I think is too complex for analyse, and so not yet testcase is ready. But I noticed a change in ITS#7904 and the impact of LDAP_BUSY upon syncrepl. http://www.openldap.org/devel/gitweb.cgi?p=openldap.git&a=search&h=refs%2Ft… For instance, I assume that in case the LDAP_BUSY returned from ldap_sync_search(), then a syncrepl-connection would be closed and reestablished. Let see around the line 1554 of server/slapd/syncrepl.c and below. https://github.com/leo-yuriev/openldap-lmdb-challenge/blob/master/servers/s… Also, nowadays it is no repeatable read txn-isolation during the search and transfer data over a network. Does it influence upon syncrepl or not? Could anybody dispel my doubts? Leonid.

2 2

Map NFShomedirectory to new value
by Frans Lanting - IT Admin 08 Oct '14

08 Oct '14

Hi Folks, We are using an external OpenLDAP to authenticate users on a FreeBSD server and would like to re-map the NFSHomeDirectory to a different location. Currently that value looks like: /afs/home.example.com/users/t/jsmith We'd like to map it to something along the lines of: /users/jsmith If anyone could please point me in the right direction of how to do this, I'd be much appreciated. Cheers, Dan

4 3

Re: OpenLDAP, SASL and TLS
by Kristof Takacs 08 Oct '14

08 Oct '14

I use the following version: - OpenLDAP (2.4.35), but I have tried 2.4.39 as well - Cyrus SASL (2.1.26) - OpenSSL (1.0.1h) - Heimdal ( I beleive 1.5.2) Thanks, Kris On Mon, Oct 6, 2014 at 1:30 PM, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Monday, October 06, 2014 2:27 PM -0400 Kristof Takacs < > kristof.takacs(a)gmail.com> wrote: > > > I use the following open source libraries: >> - OpenLDAP >> - Cyrus SASL >> - OpenSSL >> - Heimdal >> > > It is always critical to list the versions of software you are using. > Please do so. > > --Quanah > > > -- > > Quanah Gibson-Mount > Server Architect > Zimbra, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration >

3 8

Re: Problem adding olcModuleLoad
by Daniel Jung 07 Oct '14

07 Oct '14

sorry isnt module name memberof? On Mon, Oct 6, 2014 at 7:45 PM, Daniel Jung <mimianddaniel(a)gmail.com> wrote: > sorry isnt module name memberof? > > On Mon, Oct 6, 2014 at 6:39 PM, Howard Chu <hyc(a)symas.com> wrote: > >> Daniel Jung wrote: >> >>> running 2.4.39 >>> >>> # module{0}, config >>> dn: cn=module{0},cn=config >>> objectClass: olcModuleList >>> cn: module{0} >>> olcModuleLoad: {0}syncprov.la <http://syncprov.la> >>> olcModuleLoad: {1}auditlog.la <http://auditlog.la> >>> >>> ldif: >>> dn: cn=module{0},cn=config >>> changetype: modify >>> add: olcModuleLoad >>> olcModuleLoad: memberof >>> >>> using ldapmodify >>> modifying entry "cn=module{0},cn=config" >>> ldap_modify: Other (e.g., implementation specific) error (80) >>> additional info: <olcModuleLoad> handler exited with 1 >>> >>> What am i missing here? >>> >> >> You're missing a valid module name. >> >> -- >> -- Howard Chu >> CTO, Symas Corp. http://www.symas.com >> Director, Highland Sun http://highlandsun.com/hyc/ >> Chief Architect, OpenLDAP http://www.openldap.org/project/ >> > >

3 4

Problem with Index creation
by Joaquin Estrada 07 Oct '14

07 Oct '14

Hi folks. I am having a problem with index creation and am wondering if anyone here has seen this or knows what may be happening. We recently deployed a new proxy server product in our environment and have been working with the vendor to resolve some problems. This device connects to our existing LDAP server environment though a new database we added, per the vendor¹s requirements. One of the problems I am seeing is that, since the addition of this device, we are getting a lot of of the ³<= bdb_equality_cadidates: (uniqueMember) not indexed² messages showing up in the slapd log files. In order to resolve this, I¹ve attempted to create a new equality index on this attribute however no matter what I do, slapindex will not create an index! The following steps were done: 1. Shut down Slapd 2. Modify the slapd.conf file and add the ³index uniqueMember eq² entry to the current list of indexes. 3. Save the slapd.conf file. 4. Navigate to the current path for the database files and delete all existing index ³bdb² files. 5. Run a slapindex f (location of slapd) -b (suffix of database to reindex) I¹ve done this several times, once without deleting the current index files and then a few others after I¹ve deleted the current index files. The slapindex tool will recreate all of the indexes except the ³uniqueMember² index. I do not see an index file for this, and of course starting slapd back up results in the same messages in the log. So, what could be causing this? Is it possible that the vendor is using a filter improperly? If there is no data in the uniqueMember attribute for any of the records would it prevent slapindex from creating an index file? Any help would be appreciated!

1 0

Problem adding olcModuleLoad
by Daniel Jung 07 Oct '14

07 Oct '14

running 2.4.39 # module{0}, config dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModuleLoad: {0}syncprov.la olcModuleLoad: {1}auditlog.la ldif: dn: cn=module{0},cn=config changetype: modify add: olcModuleLoad olcModuleLoad: memberof using ldapmodify modifying entry "cn=module{0},cn=config" ldap_modify: Other (e.g., implementation specific) error (80) additional info: <olcModuleLoad> handler exited with 1 What am i missing here? Thanks

2 1

Re: Issues with Master / Slave and ppolicy
by Raul Hernandez 06 Oct '14

06 Oct '14

Hello Quanah, You are right. Here is my slave configuration: dn: cn=module,cn=config changetype: add objectClass: olcModuleList cn: module olcModulePath: /usr/lib/ldap olcModuleLoad: syncprov olcModuleLoad: back_ldap dn: olcOverlay=syncprov,olcDatabase={1}hdb,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov dn: olcDatabase={1}hdb,cn=config changetype: modify add: olcSyncRepl olcSyncRepl: rid=001 provider=ldap://example.com binddn="cn=syncReplUser,dc=example,dc=com" bindmethod=simple credentials=PASSWD searchbase="dc=example,dc=com" type=refreshAndPersist scope=sub retry="5 10 10 +" timeout=1 sizelimit=unlimited schemachecking=on - add: olcUpdateRef olcUpdateRef: ldap://example.com dn: olcOverlay=chain,olcDatabase={-1}frontend,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcChainConfig olcOverlay: chain olcChainReturnError: TRUE dn: olcDatabase=ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config changetype: add objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: ldap olcDbURI: ldap://example.com olcDbRebindAsUser: TRUE olcDbIDAssertBind: bindmethod=simple binddn="cn=syncReplUser,dc=example,dc=com" credentials=123456. mode=self flags=prescriptive,proxy-authz-non-critical dn: cn=module,cn=config changetype: add objectClass: olcModuleList cn: module olcModulePath: /usr/lib/ldap olcModuleLoad: ppolicy dn: olcOverlay=ppolicy,olcDatabase={1}hdb,cn=config objectClass: olcOverlayConfig objectClass: olcPPolicyConfig olcOverlay: ppolicy olcPPolicyDefault: cn=default,ou=Policies,dc=example,dc=com olcPPolicyHashCleartext: FALSE olcPPolicyUseLockout: FALSE olcPPolicyForwardUpdates: TRUE On Mon, Oct 6, 2014 at 1:20 PM, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Monday, October 06, 2014 2:12 PM -0430 Raul Hernandez < > hernandezr(a)gmail.com> wrote: > > > I've been searching on the Internet how to solve this issue without any >> luck. Can someone point me to the right direction? >> > > You've left out the sync replication configuration for the slave. > > --Quanah > > -- > > Quanah Gibson-Mount > Server Architect > Zimbra, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration >

1 0

LMDB Crash-consistency
by Howard Chu 06 Oct '14

06 Oct '14

Just an fyi... As you would know from reading the LMDB design papers ( http://symas.com/mdb/#pubs ) LMDB is crash-proof by design. A Symas client already confirmed this in their own crash testing last year https://symas.com/carrier-grade-stability-and-performance/ and it has again been verified by a research group at the University of Wisconsin. Their findings are being presented at the Usenix OSDI conference this week, and you can read the paper here https://www.usenix.org/conference/osdi14/technical-sessions/presentation/pi… They report on a single "vulnerability" in LMDB, in which LMDB depends on the atomicity of a single sector 106-byte write for its transaction commit semantics. Their claim is that not all storage devices may guarantee the atomicity of such a write. While I myself filed an ITS on this very topic a year ago, http://www.openldap.org/its/index.cgi/Incoming?id=7668 the reality is that all storage devices made in the past 20+ years actually do guarantee atomicity of single-sector writes. You would have to rewind back to 30 years at least, to find a HDD where this is not true. The UWisc researchers' point is that we cannot say what behaviors will be exported by up--and-coming nonvolatile RAM mechanisms (e.g. MRAM or PCRAM); if they offer byte-addressability instead of sector-addressability then there's a potential for these writes to become non-atomic in the future. At any rate, this issue has zero relevance today, and we are monitoring all of the upcoming NVRAM technologies closely for future developments. The other takeaway from these reports is how critically unreliable many other popular systems are. If you use any of the other projects that were included in this research, you owe it to yourself to rethink that usage, or raise discussions with their developers on how they plan to address their many weaknesses. As an interesting footnote, BerkeleyDB was included in the original testing, and while it was in their preliminary results http://wisdom.cs.wisc.edu/workshops/spring-14/talks/Thanu.pdf it is now conspicuously absent from the final paper. Regardless, the OpenLDAP Project is deprecating use of BerkeleyDB for multiple reasons. Again, if you're still using BDB you need to take a moment to re-evaluate your project. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Issues with Master / Slave and ppolicy
by Raul Hernandez 06 Oct '14

06 Oct '14

Hello! I've implemented in our testing lab, 2 openldap master servers (both configured as mirror mode); 1 HA server with HAproxy (to grant load balancing and tcp proxying to both masters), and 1 openldap slave which synchronizes its data from the masters through the HA server. All writes sent to the slave (add/edit ous and users), are forwarded to the masters. It work as is supposed to. I've also implemented the ppolicy overlay on this architecture, with "olcPPolicyForwardUpdates" set to TRUE on the slave. All authentication failures made on the slave, are sent to the masters so they can manage the policy. Here is the issue: On the slave, after a few write operations, its database misses its base (objectClass: dcObject). On the master, after an ldapsearch to its base I get the following: # example.com dn: dc=example,dc=com objectClass: top objectClass: dcObject objectClass: organization o: Example dc: example # admin, example.com dn: cn=admin,dc=example,dc=com objectClass: simpleSecurityObject objectClass: organizationalRole cn: admin description: LDAP administrator userPassword:: e1NTSEF9V1poc1UwK3VIV0FtMXRMMm1XdE9xU0Y4M3NHY05Qd28= # Test, example.com dn: ou=Test,dc=example,dc=com objectClass: organizationalUnit objectClass: top ou: Test On the slave, after an ldapsearch to its base, I get the following: # Test, example.com dn: ou=Test,dc=example,dc=com objectClass: organizationalUnit objectClass: top ou: Test I can still fetch objects, and make modifications to them from the slave; but tools like PHPLDAPADMIN, which constructs the tree from "dcObject", shows the following message: "This base cannot be created with PLA." All this servers are Debian SID, with slapd 2.4.39. I've been searching on the Internet how to solve this issue without any luck. Can someone point me to the right direction?

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical