openldap-technical April 2016

openldap-technical@openldap.org

40 participants
56 discussions

Openldap vs 389
by Achilleas Mantzios 19 Apr '16

19 Apr '16

Hello, I have been testing sporadically openldap two years now, including many advanced features, sql, ppolicy, etc we are currently evaluating openldap along with redhat's 389 for enterprise use as RBAC, on which we will built upon our existing infrastructure. We want to have full password policy enabled, in order to meet requirements for passing SOX (Sarbanes Oxley) compliance. 389's documentation is lousy, I haven't tried anything exotic (sql, etc) with it, the reason we are looking at it is because it is favored by kolab.org and likely to come as standard in future kolab versions. So I would like your opinion on this. Pros/Cons to choose openldap or 389 directory server as our long term strategic decision? -- Achilleas Mantzios IT DEV Lead IT DEPT Dynacom Tankers Mgmt

2 2

LMDB: file size increase (due to new free pages) even though write transaction does not add/update items
by Argyrios Kyrtzidis 18 Apr '16

18 Apr '16

Hi, Thank you for making LMDB available. I’m using LMDB on OSX (without MDB_WRITEMAP, so the database file size is relative to the stored data, not the max mapsize). I’ve noticed that write transactions that have a large number of ‘attempted’ updates, but that do not actually make any updates due to MDB_NOOVERWRITE / MDB_NODUPDATA, cause an increase in the database file size, which mdb_stat attributes to an increased number of free pages. This is with latest master of the github mirror. I’m wondering if you have any hints on what I may be doing wrong ? I’d like if possible to avoid the database size increasing if the write pass did not make any updates.

2 5

IP based and FQDN based certificate on same LDAP node
by Prashanth P.Nair 18 Apr '16

18 Apr '16

Hi Currently my LDAP server is having self signed FQDN based SSL certificate .I would like to have IP based SSL certificate for the same node.IS that feasible ? Below certificate issued to FQDN i.e CN=FQN. TLSCACertificateFile /etc/ssl/ldap.pem TLSCertificateKeyFile /etc/ssl/ldap.pem TLSCertificateFile /etc/ssl/ldap.pem Br/Prashanth.

2 1

ldap_sync(3) function usage
by Frank Crow 18 Apr '16

18 Apr '16

I'm wanting to write a client in C/C++ that does a "refresh and persist" sync search on an entry. I'm looking at the ldap_sync(3) man page and that looks like it would do most things that I need. I can't find any example code that is using that interface, so if somebody could point me to any that does, I'd really appreciate it. I do understand that I need to initialize the API with the ldap_sync_initialize() to get an ldap_sync_t structure. The members of the structure seem straightforward enough but I don't understand how I connect my ldap connection (LDAP*) to this API. How does that work?? Also, I don't understand how the different function typedefs work. I mean that I understand that I need four functions: ldap_sync_search_entry_f my_search_entry(...); ldap_sync_search_reference_function_f my_search_reference(...); ldap_sync_search_intermediate_f my_search_intermediate(...); ldap_sync_search_result_f my_search_result(...); But how does the ldap_sync(3) API become aware of those functions? Or... is there an easier way to do what I want? Looks like the ldapsearch command line tool just adds a control to the search (-E sync=rp) and handles the resulting messages as necessary. Should I be trying to do that instead of using ldap_sync(3)? Thanks, -- Frank

2 1

Possible to have IP based and FQDN based certificate on same LDAP node ??
by Prashanth P.Nair 18 Apr '16

18 Apr '16

Hi All Currently my LDAP server is having self signed FQDN based SSL certificate .I would like to have IP based SSL certificate for the same node.IS that feasible ? Below certificate issued to FQDN i.e CN=FQN. TLSCACertificateFile /etc/ssl/ldap.pem TLSCertificateKeyFile /etc/ssl/ldap.pem TLSCertificateFile /etc/ssl/ldap.pem Please advise on the same. Br/Prashanth.P

2 2

Question about MDB_INTEGERKEY flag
by Greg Heinrich 16 Apr '16

16 Apr '16

Hello, sorry for being a noob but I have a question regarding the MDB_INTEGERKEY flag. I am using the LMDB library through Lua wrappers from https://github.com/shmul/lightningmdb. I have an LMDB file which was created with keys that are named "key0", "key1", ... When I open the database with mdb_dbi_open(txn, NULL, MDB_INTEGERKEY, & dbi) and enumerate keys with successive calls to mdb_cursor_get(cursor, &key, &val, MDB_NEXT) the key values that I read are the same as in the LMDB (i.e. "key0", ...). Since I am using the MDB_INTEGERKEY flag I was hoping to read keys as 1,2,3, etc. And I thought I would then be able to retrieve entries doing e.g. mdb_get(txn, dbi, "1", &data). Am I doing anything wrong or is MDB_INTEGERKEY just used to enforce integer keys when putting entries? To give my question some background: what I am trying to achieve is to read entries in my LMDB file in random/arbitrary order. Since I have may 10 million entries or more, I do not want to store keys in memory. I'd rather retrieve entries using an index. Is that possible? Note that I do not have control over the key naming convention so keys could be named anything. Thanks! Greg.

2 1

Q: accesslog and replicated changes
by Ulrich Windl 14 Apr '16

14 Apr '16

Hello! I have configured accesslog to log all changes to an LDAP server, and that seems to work for months. Recently I noticed that that there wee no new entries for more than a week. Usually there are several entries per day, because with password policy every bad login attempt is logged. As we have three multi-master servers, I wonder whether changes made to other servers and replicated to the local server will be logged by accesslog also. Are the password policy updates (which are somewhat special) also replicated to all servers? As a matter of fact, I got some new entries today (as if the system knew I wanted to report the problem today ;-)) But he first entry for this month was stamped "20160413051836.000002Z", so there were no entries for almost two weeks. The server has connections from 9 clients with each client having 1 to 64 connections to the server open (so the server does not seem to be very idle). Can anybody share some insights on that? As we use BDB for accesslog, I had a look yesterday, and the "*.bdb" files had an "old date", while the redo log and the "__db.*" files had a current date. I learned that changes done to a file via mmap() doesn't update the modification time of the file on Linux, so maybe the file date doesn't say much. At least the redo log's timestamp of the main database seems to match that of the acesslog database (which seems good). Regards, Ulrich

3 3

Re: ldapdelete recursive (-r) with syncrepl
by Frank Crow 13 Apr '16

13 Apr '16

OK, thanks for the clarification and correction. Doing so makes the restore process slightly more of pain but, on the bright side, I won't need to worry about SIDs. So that nice. Also on the bright side, working through this I managed to move to delta-syncrepl which appears to be a better solution. And yeah, I will move to mdb if I can get these guys to bite on upgrading. Thanks for all the info and advice, Frank On Wed, Apr 13, 2016 at 12:29 PM, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Wednesday, April 13, 2016 10:20 AM -0700 Quanah Gibson-Mount < > quanah(a)zimbra.com> wrote: > > --On Wednesday, April 13, 2016 1:16 PM -0400 Frank Crow >> <fjcrow2008(a)gmail.com> wrote: >> >> >>> Then just slapcat the data first, do your destructive tests, and then >>>> restore from slapadd. Doing repetitive ldap deletes/adds will just >>>> causes massive database growth. >>>> >>> >>> >>> OK, but I just want to be clear - I'm still not. Does that mean that >>> I need to nuke /var/lib/ldap on every master replica prior to restoring >>> the DIT? >>> >> >> Yes. >> > > Or I should say, depends on what you've done. If all masters are in a > "bad" state (which would be likely given your test scenario), then yes, you > want to reload them all from the same slapcat dump that was taken, so their > DBs are identical after restore. > > > --Quanah > > > -- > > Quanah Gibson-Mount > Platform Architect > Zimbra, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration > A division of Synacor, Inc > -- Frank

1 0

Re: ldapdelete recursive (-r) with syncrepl
by Frank Crow 13 Apr '16

13 Apr '16

> Then just slapcat the data first, do your destructive tests, and then restore from slapadd. Doing repetitive ldap deletes/adds will just causes massive database growth. OK, but I just want to be clear - I'm still not. Does that mean that I need to nuke /var/lib/ldap on every master replica prior to restoring the DIT? Also, another question, if I do that will I have to know the server ID (for "-w -S <SID>") in order to properly reload? I'm asking because then my testers need to know which master is which - and there is no guaranteed order at the moment with our configuration. Thanks, Frank On Wed, Apr 13, 2016 at 11:51 AM, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Wednesday, April 13, 2016 12:29 PM -0400 Frank Crow < > fjcrow2008(a)gmail.com> wrote: > > >> Well, OK. Our formal test procedures (created and executed by a >> separate team) will intentionally do all manner of destructive changes to >> the DIT after taking a snapshot. After which they want to clean and >> reload the entire DIT in order to: 1) be able to run the tests multiple >> times with the same data, and 2) restore the DIT for normal (non-OpenLDAP >> related) testing that does need the DIT intact. >> > > Then just slapcat the data first, do your destructive tests, and then > restore from slapadd. Doing repetitive ldap deletes/adds will just causes > massive database growth. > > During production use, we would not be doing that. For that, I think >> the individual node repair (slapadd/slapcat) would be exactly what we >> need. >> >> >> I took your suggestion and forwarded the list of changes since 2.4.40 >> (with the syncrepl fixes highlighted) to the important people up the >> "flag pole" this morning. I am "fighting the good fight" with them but >> they are hesitant to move without strenuous "encouragement!" ;-) >> > > I guess it just depends on whether or not they consider data loss > acceptable. If they do find it acceptable, by all means, stay on 2.4.40. ;) > > Also not sure which database backend you're using, but I'd strongly advise > back-mdb once you get to 2.4.44. > > > --Quanah > > > -- > > Quanah Gibson-Mount > Platform Architect > Zimbra, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration > A division of Synacor, Inc > -- Frank

2 2

Re: ldapdelete recursive (-r) with syncrepl
by Frank Crow 13 Apr '16

13 Apr '16

Well, OK. Our formal test procedures (created and executed by a separate team) will intentionally do all manner of destructive changes to the DIT after taking a snapshot. After which they want to clean and reload the entire DIT in order to: 1) be able to run the tests multiple times with the same data, and 2) restore the DIT for normal (non-OpenLDAP related) testing that does need the DIT intact. During production use, we would not be doing that. For that, I think the individual node repair (slapadd/slapcat) would be exactly what we need. I took your suggestion and forwarded the list of changes since 2.4.40 (with the syncrepl fixes highlighted) to the important people up the "flag pole" this morning. I am "fighting the good fight" with them but they are hesitant to move without strenuous "encouragement!" ;-) Thanks, Frank On Wed, Apr 13, 2016 at 11:17 AM, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Wednesday, April 13, 2016 11:51 AM -0400 Frank Crow < > fjcrow2008(a)gmail.com> wrote: > > >> I did see that and do know how to do slapadd/slapcat backups. What >> I'm not clear on is how that works with N-Way MMR. Wouldn't I have >> to go and delete the the /var/lib/ldap on every master replica machine >> prior to loading the backup with slapadd? Or is that not necessary? >> > > Is your intent to drop the database and reload it on every master? That > would seem to indicate you've got significant issues with how you manage > your servers. > > You can trivially recover any one given server with the backup from > another MMR node. I.e., say you want to take down node 3... slapcat node1 > or node2, and load that onto node 3... > > Again, more information on what it is you're really trying to do here > would be useful. > > > In any case, I did update my syncrepl to use cn=accesslog and I no longer >> have any issues with bulk operations being propagated to the other master >> replicas. >> > > Good, delta-syncrepl's definitely better. But this doesn't resolve the > many replication problems that still exist in 2.4.40. > > > --Quanah > > -- > > Quanah Gibson-Mount > Platform Architect > Zimbra, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration > A division of Synacor, Inc > -- Frank

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical April 2016