openldap-devel

openldap-devel@openldap.org

1418 discussions

Start a nNew thread

ldap://ldap.openldap.org out of service
by Michael Ströder 26 Apr '08

26 Apr '08

HI! Is the demo server which was running ldap://ldap.openldap.org abandoned forever? Ciao, Michael.

1 0

LDAP transactions
by Howard Chu 24 Apr '08

24 Apr '08

Just thinking aloud right now about what's needed here. Basically all incoming requests participating in a transaction are queued until the Commit is received. Aside from basic parsing/validation, no other processing is performed until then. If an Abort is received, the queued requests are simply discarded. When the Commit request is received, all of the queued requests are performed sequentially by a single thread and the results are gathered. If any individual request fails, any preceding completed requests must be rolled back. Since I'm considering this for both back-bdb and back-ndb, it appears we're going to need some transaction-specific hooks to be added to the BackendInfo structure. 1) start a TXN, get a TXN handle 2) end a TXN: Commit or Abort For back-bdb the tricky part is exposing the updates atomically in the caches. I think the fact that entry caching uses BDB locks helps somewhat; we can keep entry cache items locked until the overall transaction completes. But for Aborts we'll either need to keep a copy of the previous cache info, or just discard it all. For now, discarding it all seems simpler. For back-ndb things are currently easy since this backend does no caching of its own. As such, once the backend issues a Commit or Abort request, there's no further (backend) work to be done. It's tempting to think about this for backglue, but we'd need a cross-database lock manager of some kind for detecting deadlocks. That implies that we really need an LDAP-level lock request, to handle distributed locking, and that the Transaction handling ought to be built on top of that. Currently the Transaction layer says nothing at all about locking, and it's up to the underying LDAP database to take care of it. I guess another approach would just be to have backglue fully serialize all transactions; if only one is outstanding at any time there can be no deadlocks. This brings up a question about whether slapd in general should fully serialize them. I was thinking, at the least, that we should only allow one active transaction per connection, though that was mainly a matter of convenience. Thoughts? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

4 3

delta-syncrepl, Delta-Syncrepl or Delta syncrepl?
by Gavin Henry 18 Apr '08

18 Apr '08

Hi All, How exactly is this written? Cheers.

3 2

syncrepl and schema replication crashes
by manu＠netbsd.org 17 Apr '08

17 Apr '08

I just upgraded to 2.4.8, and I experience a stability problem with synrepl and schema replication. My replicas get cn=schema,cn=config through syncrepl. If the master is restarted, the replicas tend to crash (not always, but very frequently). The problem disapear if I don't replicate cn=schema,cn=config. Below is a log of what happens at master restaty time, and the backtrace I collected in GDB. Any suggestion of what should I try next? Apr 17 22:16:01 khazad-dum slapd[6292]: conn=55 fd=13 closed (connection lost) Apr 17 22:16:02 khazad-dum slapd[6292]: do_syncrep2: rid=222 (-1) Can't contact LDAP server Apr 17 22:16:02 khazad-dum slapd[6292]: do_syncrep2: rid=022 (-1) Can't contact LDAP server Apr 17 22:16:02 khazad-dum slapd[6292]: do_syncrepl: rid=022 retrying Apr 17 22:16:02 khazad-dum slapd[6292]: do_syncrepl: rid=222 retrying Program received signal SIGSEGV, Segmentation fault. [Switching to LWP 1] 0x08098b62 in at_next () (gdb) bt #0 0x08098b62 in at_next () #1 0x080506fe in config_generic () #2 0x0805b4e7 in config_set_vals () #3 0x0805bc9f in config_parse_add () #4 0x080579d8 in config_modify_add () #5 0x0805820e in config_modify_internal () #6 0x080585d0 in config_back_modify () #7 0x080af683 in syncrepl_entry () #8 0x080abd18 in do_syncrep2 () #9 0x080acf32 in do_syncrepl () #10 0x08063c25 in connection_read_thread () #11 0xbdbbbd61 in ldap_int_thread_pool_wrapper () from /usr/pkg/lib/libldap_r-2.4.so.2 #12 0xbd95a17d in pthread_create () from /usr/lib/libpthread.so.0 -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu(a)netbsd.org

2 1

Creating entries on the fly, destroying them when operation is over
by Davor Ocelic 17 Apr '08

17 Apr '08

Hey folks, In the search callback, I need to check whether an entry exists, and if not, create it based on an another entry used as template (duplicating also eventual tree elements below it, if they exist). For example, if cn=a,cn=TESTVAL1,ou=group,dc,dc doesn't exist, it should be created from cn=a,cn=TEMPLATE,ou=group,dc,dc. The created entry (and the eventual subtree) should not persist and should be dropped after the operation finishes. Questions: 1) What's an elegant way to duplicate an entry in this way where an exact copy should be made, just with a different DN? 2) Since the entry creation is done in search callback, it can't be just "slipped in" like it would be possible in response callback alone, so how do I mark the created entry for removal when the operation is done? Can this be scheduled automatically with entry flags (like REP_ENTRY_MUSTBEFREED), or there would have to be a manual mechanism for deleting entries in response callback? Thanks, -doc

2 2

OpenLDAP Faq-O-Matic: Misleading comment in "Which version of BerkeleyDB should I use?"
by Michael Ströder 17 Apr '08

17 Apr '08

HI! I think this text in http://www.openldap.org/faq/data/cache/44.html needs some correction since recent BDB 4.6 cannot be used with OpenLDAP 2.3: "[..] Versions 4.4, 4.5, and 4.6 are known to work with OpenLDAP 2.3 and newer." I don't know how to edit existing text in the FAQ-O-MATIC. Ciao, Michael.

3 3

Re: RE2.4
by Raphaël Ouazana-Sustowski 16 Apr '08

16 Apr '08

Hi, Le Mar 15 avril 2008 09:25, Gavin Henry a écrit : >> Please test RE2.4 and let me know how things go. > > All passed on i386, Fedora 8 here. Any news on the build machine rebuild > Kurt? > >>>>> Starting test050-syncrepl-multimaster ... running defines.sh Initializing server configurations... Starting producer slapd on TCP/IP port 9011... Using ldapsearch to check that producer slapd is running... Inserting syncprov overlay on producer... Starting consumer slapd on TCP/IP port 9012... Using ldapsearch to check that consumer slapd is running... Configuring syncrepl on consumer... Starting consumer2 slapd on TCP/IP port 9013... Using ldapsearch to check that consumer2 slapd is running... Configuring syncrepl on consumer2... Adding schema and databases on producer... Using ldapadd to populate producer... Waiting 20 seconds for syncrepl to receive changes... Using ldapadd to populate consumer... Waiting 20 seconds for syncrepl to receive changes... Using ldapsearch to check that syncrepl received database changes... Waiting 5 seconds for syncrepl to receive changes... Waiting 5 seconds for syncrepl to receive changes... Waiting 5 seconds for syncrepl to receive changes... Waiting 5 seconds for syncrepl to receive changes... Waiting 5 seconds for syncrepl to receive changes... Waiting 5 seconds for syncrepl to receive changes... ldapsearch failed (32)! >>>>> ./scripts/test050-syncrepl-multimaster failed (exit 32) make[2]: *** [hdb-yes] Erreur 32 make[2]: quittant le répertoire « /tmp/openldap/tests » make[1]: *** [test] Erreur 2 make[1]: quittant le répertoire « /tmp/openldap/tests » make: *** [test] Erreur 2 Regards, Raphaël Ouazana.

3 4

Any plans for 2.4.9?
by Michael Ströder 16 Apr '08

16 Apr '08

HI! Are there any plans when to release 2.4.9? I vaguely remember some interesting fixes and noticed that some things were already back-ported to RE24. Ciao, Michael.

5 14

RE2.4
by Quanah Gibson-Mount 15 Apr '08

15 Apr '08

I've sync'd up RE24 with everything I'm aware of except for: Update of /repo/OpenLDAP/pkg/ldap/servers/slapd/back-bdb Modified Files: referral.c 1.49 -> 1.50 Log Message: ITS#5339: fix referral rewrite, remove pointless default_referral code as I was not sure from the comments if this was really ready for release. Please test RE2.4 and let me know how things go. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

8 8

non-unix help needed: valid filename characters?
by Hallvard B Furuseth 14 Apr '08

14 Apr '08

Which characters one can safely use in filenames on at least the platforms OpenLDAP is ported to: Unix, Windows (cygwin), IBM zOS and MacOS X according to ANNOUNCEMENT? In particular Windows, since that's the most common non-Unix platform. I only know Unix filenames. Googling around I've found a plethora of conflicting info. It's for a naming scheme for back-ldif filenames that will let back-ldif work as a general backend, and hopefully won't conflict with its current names for the config database. ITS#5408. Currently back-ldif takes the RDN and escapes the directory separator as "\hex", which doesn't work on Windows where \ is a directory separator. Some other notes: - Don't need really general filenames. OpenLDAP does in any case assume Unix/Windows/URL-style pathnames: root to the left, leaf to the right, a single directory separator character. - Hopefully the characters "=-{}" can be used, since database config uses those characters. E.g. olcDatabase={-1}frontend,cn=config. ",+" would be nice too, as separators in and between RDNs. - Need some escape character. Howard suggested % as in URL-escaping. First that sounded nice, but on second thought such a filename is not a valid file:// URL component for that file - the '%' must be URL-escaped again to access the file as an URL. Not sure if that's a good argument either way. Full URL-escaping also escapes {} which is unfortunate (see point 1). - For real paranoia, might escape uppercase characters in case-sensitive attribute types too. I won't bother unless someone disagrees, both case-sensitive DNs and the use of back-ldif as a general database are fairly rare. -- Hallvard

2 9

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel