openldap-technical

openldap-technical@openldap.org

5 participants
9899 discussions

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 15 Apr '16

15 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

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

13 Apr '16

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? 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. Thanks, Frank On Wed, Apr 13, 2016 at 2:15 AM, Michael Ströder <michael(a)stroeder.com> wrote: > Please stay on the list so others can answer and learn as well. > > > Frank Crow wrote: > > OK, if I do a backup with slapcat, I still would want to wipe the > existing > > contents of the DIT first, right? > > That's why I wrote... > > > On Tue, Apr 12, 2016 at 5:47 PM, Michael Ströder <michael(a)stroeder.com> > > wrote: > > > >> Frank Crow wrote: > >>> I'm trying to create backup and restore scripts using LDAP command line > >>> tools. > >> > >> For various reasons backup and restore should be done with command-line > >> tools > >> slapcat and slapadd which operate directly on the database files. > >> > >> And yes, with recent backend modules like back-mdb and back-hdb you can > do > >> hot > >> backup while slapd is running. > >> > >> Of course, before a restore you have to stop slapd and remove the DB > files. > > ^^^^^^^^^^^^^^^^^^^ > ...to remove the database files. > > >> After using slapadd you should check whether ownership/permissions are > >> still > >> correct. > > Please read the responses carefully. > > Ciao, Michael. > > -- Frank

2 1

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

13 Apr '16

Well, I can strongly suggest that we upgrade past that but I know that I'll get push back on it. I'll change the syncrepl to use refreshAndPersist. Thanks, Frank On Tue, Apr 12, 2016 at 7:04 PM, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Tuesday, April 12, 2016 7:33 PM -0400 Frank Crow < > fjcrow2008(a)gmail.com> wrote: > > >> OpenLDAP 2.4.40 >> > > Upgrade. There are serious MMR issues in that release. > > > Syncrepl configuration: >> >> olcSyncUseSubentry: FALSE >> olcSyncrepl: {0}rid=101 provider=ldap://server1 >> searchbase="o=xxx,dc=yyy, >> dc=zzz" type=refreshOnly bindmethod=sasl saslmech=EXTERNAL >> > > I strongly advise against using refreshOnly. There's virtually no > instance where that is the correct option. > > > --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

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

13 Apr '16

OpenLDAP 2.4.40 Syncrepl configuration: olcSyncUseSubentry: FALSE > olcSyncrepl: {0}rid=101 provider=ldap://server1 searchbase="o=xxx,dc=yyy, > dc=zzz" type=refreshOnly bindmethod=sasl saslmech=EXTERNAL > tls_cert=/etc/openldap/certs/xxxxx.crt > tls_key=/etc/openldap/certs/xxxxx.key > tls_cacert=/etc/openldap/certs/cacert.pem interval=00:00:00:10 > retry="5 10 10 10 30 +" timeout=1 starttls=critical > olcSyncrepl: {1}rid=102 provider=ldap://server2 > searchbase="o=xxx,dc=yyyy, > dc=zzz" type=refreshOnly bindmethod=sasl saslmech=EXTERNAL > tls_cert=/etc/openldap/certs/ldapadmin.crt > tls_key=/etc/openldap/certs/xxxxx.key > tls_cacert=/etc/openldap/certs/cacert.pem interval=00:00:00:10 > retry="5 10 10 10 30 +" timeout=1 starttls=critical > olcMirrorMode: TRUE BTW, I just tried addinging: dn: olcOverly={3}syncprov,olcDatabase={2},cn=config > changetype: modify > replace: olcSpCheckpoint > olcSpCheckpoint: 1024 > - > add: olcSpSessionlog > olcSpSessionlog: 1024 > - > add: olcSpReloadhint > olcSpReloadhint: TRUE And that seemed to fix it! Maybe it was just the checkpoint being "1 1" that was messing it up? Or maybe I needed the session log. I realize that this is the deprecated approach. I probably put in cn=changelog instead if there's a good reason to do so. -Frank On Tue, Apr 12, 2016 at 6:26 PM, Frank Crow <fjcrow2008(a)gmail.com> wrote: > OK, if I do a backup with slapcat, I still would want to wipe the existing > contents of the DIT first, right? > > Also, I just tried doing a list of deleted uid entries using "ldapdelete > -ZZ -f /file.ldif" and although the command did not complain, not all of > the entries in the file.ldif were deleted from all replicas. I really > think there is something wrong with my configuration! I suppose that I'll > try cn=changelog next. > > Thanks, > Frank > > > On Tue, Apr 12, 2016 at 5:47 PM, Michael Ströder <michael(a)stroeder.com> > wrote: > >> Frank Crow wrote: >> > I'm trying to create backup and restore scripts using LDAP command line >> > tools. >> >> For various reasons backup and restore should be done with command-line >> tools >> slapcat and slapadd which operate directly on the database files. >> >> And yes, with recent backend modules like back-mdb and back-hdb you can >> do hot >> backup while slapd is running. >> >> Of course, before a restore you have to stop slapd and remove the DB >> files. >> After using slapadd you should check whether ownership/permissions are >> still >> correct. >> >> Ciao, Michael. >> >> > > > -- > Frank > -- Frank

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