openldap-technical

openldap-technical@openldap.org

5 participants
9899 discussions

slap_timestamp with microsecond granularity?
by Paul B. Henson 29 Apr '14

29 Apr '14

Reviewing current time handling code, while lutil_parsetime understands and can parse a generalized time that includes fractions of a second, there doesn't seem to be any code that can generate a generalized time string including fractions of a second, in particular to microsecond resolution (to match a struct timeval time)? I'd like to enhance the current password policy module to use microsecond resolution for the pwdFailureTime attribute, as the current 1 second resolution makes it less than ideal for account lockouts. Currently, it is using slap_timestamp to generate the generalized time to store, which only provides a generalized time with 1 second granularity. On initial review, it looks like simply storing a generalized time with microsecond resolution in the pwdFailureTime attribute is all that is required to enhance the ppolicy module for better account lockout support, because as previously mentioned lutil_parsetime already understands and can parse fractional seconds. I don't see any other code that would need to be modified so far. The question is how to generate the needed format? One option would be to enhance one way or another the existing generic support, perhaps adding a slap_timestamp_usec function? Another would be to just add a call to gettimeofday() next to the current call to time() in the ppolicy code, generate the generalized time string with slap_timestamp, and then mash the fractional seconds into it. Ideally I'd like to get this enhancement to ppolicy accepted into the code base, so I'd appreciate some feedback as to what implementation would be preferred for this. Thanks...

4 5

LMDB data corruption/alignment issues on ARM
by Martin Lucina 29 Apr '14

29 Apr '14

Hi, I've just spent about two days chasing down a bug in my application using LMDB, where if I ran the code on an ARM (and ARM only) platform, data returned from mdb_get() would appear to be corrupted. The symtomps were quite bizarre, I'm including them here in case someone else sees something similar; you can skip to the conclusion if you're in a hurry: a) data written by an application process using mdb_put() appeared correct and consistent b) the same data read by a different application process using mdb_cursor_get() would appear consistent when examined with a live GDB on the target c) however, when actually running the application code, even under GDB, some data would mysteriously be corrupted d) single-stepping through one case of corruption lead me to a single LDR instruction which appeared to load bogus data from memory. GDB showed the same data (at the exact same memory address) as correct, i.e. not corrupted. e) the problem only occured on ARM and was always reproducible. Much experimenting and googling later I found [1], the upshot of which is that on some ARM platforms unaligned word accesses to data using LDR produce *bogus* data. No exception, nothing, just silent data corruption. My question is: Given that I'm storing C structs directly in LMDB, I need to get at least word-aligned pointers back from LMDB in order to be able to access the data safely. I've not found anything in the documentation or the source about being able to tweak alignment of key and data values; I *think* that all I need is an option where LMDB would guarantee a minimum word (4 byte in this case) alignment of data. How hard would this be to implement? Would you consider such a feature? The only workaround I can think of is explicitly copying all data I get back from LMDB into aligned struct pointers; for obvious performance reasons I don't want to do that. Martin [1] http://stackoverflow.com/questions/21488501/strange-pointer-arithmetic See the second answer, and the link to the ARM documentation for the LDR instruction.

2 4

ppolicy module limited to catching 1 login failure per second?
by Paul B. Henson 29 Apr '14

29 Apr '14

We're testing the ppolicy module for the purposes of enabling account lockout on our ldap infrastructure. During initial testing, I noticed that it didn't seem to be catching all of the failed logins, and then realized that the pwdFailureTime attribute in which they are stored seems to have a granularity of only 1 second? So, if there are 100 failed logins in 1 second, for the purposes of account lockout, the password policy module only records them all as 1 failed login? Such that if you had a pwdMaxFailure set to 100, an intruder would actually be able to get in 10000 password guess attempts before the account was actually locked out? Am I misunderstanding something here? Is there anyway to get pwdFailureTime to use microsecond granularity like entryCSN? Thanks...

2 2

import new schema via ldapmodify
by Nikos Voutsinas 26 Apr '14

26 Apr '14

Hello all, While practising with the cn=config, I tried to import a new schema to an Openldap 2.4.39 server by using the ldapmodify cmd. Can someone please enlighten me on why the 1st ldif works but not the 2nd one? The "{4}", which is the only difference between the 1st and the 2nd ldif, is the index of the next available object under cn=schema,cn=config 1st (works) ============= dn: cn={4}eduPerson,cn=schema,cn=config changetype: add objectClass: olcSchemaConfig cn: eduPerson dn: cn={4}eduPerson,cn=schema,cn=config changetype: modify add: olcAttributeTypes olcAttributeTypes: ( 1.3.6.1.4.1.5923.1.1.1.1 NAME 'eduPersonAffiliation' DESC 'eduPerson per Internet2 and EDUCAUSE' EQUALITY caseIgnoreMatch SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' ) - add: olcObjectClasses olcObjectClasses: ( 1.3.6.1.4.1.5923.1.1.2 NAME 'eduPerson' AUXILIARY MAY ( eduPersonAffiliation ) ) - ============= 2nd (doesn't work) ============= dn: cn=eduPerson,cn=schema,cn=config changetype: add objectClass: olcSchemaConfig cn: eduPerson dn: cn=eduPerson,cn=schema,cn=config changetype: modify add: olcAttributeTypes olcAttributeTypes: ( 1.3.6.1.4.1.5923.1.1.1.1 NAME 'eduPersonAffiliation' DESC 'eduPerson per Internet2 and EDUCAUSE' EQUALITY caseIgnoreMatch SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' ) - add: olcObjectClasses olcObjectClasses: ( 1.3.6.1.4.1.5923.1.1.2 NAME 'eduPerson' AUXILIARY MAY ( eduPersonAffiliation ) ) - ============= The command used, looks like this: ldapmodify -h localhost -p 389 -D cn=admin,cn=config -x -W -f <filename> Thanks, Nikos

1 0

How can i setup acl on openldap(ubuntu 12.04)
by Tian Zhiying 25 Apr '14

25 Apr '14

Hi My server is ubuntu 12.04 64bit, install openldap via apt-get, now i want to setup acl,how can i quickly to setup it. Before i use centos 5, slapd.conf on /etc/openldap dir, but slapd.conf is not on /etc/ldap dir at ubuntu 12.04. Tian Zhiying

2 1

Re: LMDB: fast writes: removing the write mutex ?
by Simon Majou 25 Apr '14

25 Apr '14

MDB_NOLOCK doesn't fit, from the doc : #MDB_NOLOCK Don't do any locking. If concurrent access is anticipated, the caller must manage all concurrency itself. I still want the concurrency managed on reads. On Fri, Apr 25, 2014 at 3:06 PM, Hallvard Breien Furuseth <hbf(a)mail.uio.no>wrote: > I wrote: > >> On 13. april 2014 18:04, Simon Majou wrote: >> (...) >> >> In that case, how can I disable the write lock ? >>> Would commenting LOCK_MUTEX_W() & UNLOCK_MUTEX_W() make the trick ? >>> >> >> You could use MDB_NOTLS in LMDB 0.9.7 or later, but then you must >> synchronize threads yourself which does not sound like what you >> want. Also, then you must not write when there are too old readers. >> > > Oops, I meant MDB_NOLOCK. MDB_NOTLS is about readers. > > > > -- Best regards, Simon

1 0

failed bind after password update
by Emmanuel Dreyfus 25 Apr '14

25 Apr '14

Hi After heartbeat we force password resets and we observe an odd behavior: after a password is changed, a replica will fail bind just as if the password was wrong (LDAP_INVALID_CREDENTIALS), while another replica will accept it. slapcat show idential userPassword hashes everywhere: master, bad replica and good replica. Destroying the replica data and resyncrhonizing it fixes the problem. Is there some kind of bind cache somewhere? This is OpenLDAP 2.4.33 -- Emmanuel Dreyfus manu(a)netbsd.org

1 0

slapcat -F failing to backup
by Mike_Mcarthur＠kaltire.com 24 Apr '14

24 Apr '14

Hello; I am running an older version of openldap and having issues in our production environment. We would backup our openldap db by running slapcat -F /etc/openldap/slapd.d/ Recently htat backup fails and causes issues with our ldap db. [root@l900pldp01v ~]# slapcat -F /etc/openldap/slapd.d/ ch_calloc of 1 elems of 800000008 bytes failed slapcat: ../../../servers/slapd/ch_malloc.c:107: ch_calloc: Assertion `0' failed. Aborted When I run this same command in our test system the backups succeed. Any ideas on what the error is talking about? Thank you Mike M

2 2

[LMDB] Access violation
by Alain 23 Apr '14

23 Apr '14

Hi, We've now started to receive regular access violation after running our application for about 30-45 minutes of heavy processing. We are at commit 5bda356 and running under Windows 2k8 R2 Datacenter, service pack 1 Here's what I found from the log file produced by the Java JVM about crashing. The issue happens after our application call db_put. It occurs in mdb_xcursor_init0 (inlined within mdb_cursor_init) at: if (txn->mt_dbs[dbi].md_flags & MDB_DUPSORT) { mdb_tassert(txn, mx != NULL); mc->mc_xcursor = mx; mdb_xcursor_init0(mc); mdb_xcursor_init0(MDB_cursor *mc) { MDB_xcursor *mx = mc->mc_xcursor; mx->mx_cursor.mc_xcursor = NULL; <------here or: 0000000180008A9C: 4D 89 4B 10 mov qword ptr [r11+10h],r9 //mc->mc_xcursor = mx; (6736) 0000000180008AA0: 49 89 59 10 mov qword ptr [r9+10h],rbx //mx->mx_cursor.mc_xcursor = NULL; (6651) Looking at the register it is clear that cursor_init is called with a dbi of zero and a null mx pointer. >From the stack I was able to trace the call to mdb_cursor_init to come from mdb_page_alloc at: if (op == MDB_FIRST) { /* 1st iteration */ /* Prepare to fetch more and coalesce */ oldest = mdb_find_oldest(txn); last = env->me_pglast; mdb_cursor_init(&m2, txn, FREE_DBI, NULL); <-----here the question then is why and how we can have had dupsort turned on for FREE_DBI so that init cursor could have triggered this code. I am working on publishing a change to the above line to disregard FREE_DBI, but that looks like a patch that doesn't address the cause of this issue: if (dbi && txn->mt_dbs[dbi].md_flags & MDB_DUPSORT) { I'm at a real lost how DUPSORT can ever be turned on for FREE_DBI and if that's now a symptom a another problem. Thanks for you help and insight Alain

1 0

SAML Identity Provider for OpenLDAP
by Marc Patermann 23 Apr '14

23 Apr '14

Hi, I searching for proven "extention" to use my OpenLDAP directory data with an SAML identity provider. I found LemonLDAP:NG and OpenAM as possible candidates. Howtos and success stories are welcome! Marc

4 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