openldap-devel

openldap-devel@openldap.org

1416 discussions

git repo?
by Volker Lendecke 29 Mar '11

29 Mar '11

Hi! Being excited about the git repo, I had to try it: $ git clone git://git.OpenLDAP.org/module.git Initialized empty Git repository in /data/vlendec/git/module/.git/ fatal: The remote end hung up unexpectedly $ Is it possible that something is not set up right yet? Thanks, Volker

2 1

Re: openldap.git branch master updated. cf49e43f86de16f1cc84ab44f6d4fa3c7e18902f
by Hallvard B Furuseth 29 Mar '11

29 Mar '11

> commit cf49e43f86de16f1cc84ab44f6d4fa3c7e18902f > Merge: cd1f718 0adef98 > Author: Kurt Zeilenga <kurt(a)OpenLDAP.org> > Date: Mon Mar 28 18:42:22 2011 -0700 > > Merge branch 'master' of ssh://git-master.openldap.org/~git/git/openldap We'll need better messages for merges, this doesn't say much. -- Hallvard

3 5

RE 24 testing call (OL 2.4.25)
by Quanah Gibson-Mount 28 Mar '11

28 Mar '11

A few small fixes have been applied to the RE24 branch for a 2.4.25 release. Please test and report. Thanks! --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

5 5

Re: commit: ldap/build crupdate
by Hallvard B Furuseth 25 Mar '11

25 Mar '11

kurt(a)OpenLDAP.org writes: > Removed Files: > crupdate 1.12 -> NONE > Remove from CVS (now in openldap-etc.git) No big deal, but I think such changes belong in Git only. Might as well leave the frozen CVS repo in a working state, e.g. if we find we need to use it for one more release or want to play around with it to verify the transition to Git. -- Hallvard

1 0

authTimestamp and relax rules control
by Michael Ströder 19 Mar '11

19 Mar '11

HI! I'm using slapo-lastbind with 2.4.24 found under contrib/ which writes the operational attribute authTimestamp to an entry. Now I have a use-case where a LDAP client (connector continously pumping data from another non-OpenLDAP directory server) should write this attribute to the OpenLDAP server. But even when using the relax rules control this does not seem to be allowed. Section 3.6. of draft-zeilenga-ldap-relax-03 says: The subsections of this section discuss modification of various operational attributes where their NO-USER-MODIFICATION constraint may be relaxed. Future documents may specify where NO-USER-MODIFICATION constraints on other operational attribute may be relaxed. In absence of a document detailing that the NO-USER-MODIFICATION constraint on a particular operational attribute may be relaxed, implementors SHOULD assume relaxation of the constraint is not appropriate for that attribute. Hmm, since there's no formal spec for authTimestamp I'm lost here? Ciao, Michael.

2 2

Release testing
by Howard Chu 18 Mar '11

18 Mar '11

Since fermat.openldap.org which was to be the core of our build farm has been down almost from the time the machine arrived, we haven't been able to set up the automated builds we had envisioned. It's clear now that nobody tested RE24 on Windows before we released 2.4.24. Anybody willing to take responsibility for Windows testing in the future? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

Generalize olcHidden -> olcLabel
by Hallvard B Furuseth 17 Mar '11

17 Mar '11

I'd like a simple way to manipulate an off-line database while slapd is running, e.g. to slapadd it from scratch and activate it when done. Here is one suggestion: Make olcHidden a dynamic attribute computed from an attribute olcLabel="some text" + a startup option -L "label to activate,...". Updates to olcHidden could fail or update olcLabel for backwards compatibility, depending on configuration. Then to rebuild database X off-line, maybe with a different config: - Copy ldapadd X's config to a new database Y, except set olcLabel = "offline" and olcDbDirectory = "<new dir>". - Set olcReadOnly=TRUE in X's config, so we won't lose any changes. - Slapcat <X> | slapadd -L offline - Set X's olcDbDirectory="<new dir>" and olcReadOnly=FALSE, to pick up the changes and resume normal operation. This doesn't cover all cases of reconfiguring a database, e.g. we can't modify a global option like olcIndexIntLen this way. But it's a start. Also instead of pointing X's olcDbDirectory at Y's directory, one might want to atomically hide database X and un-hide Y, by removing Y's label and then labelling X. That works if one can have two active databases with the same suffix where the former hides the latter. (Maybe the hidden database would be treated as if it had olcHidden.) Slapd does not currently accept that at startup, but does if one starts with olcHidden=TRUE in the first database and then removes olcHidden. That should probably be cleaned up anyway. The olcHidden machinery has some bugs, I'll ITS them after exploring abit. -- Hallvard

2 2

back-mdb notes
by Howard Chu 16 Mar '11

16 Mar '11

Thought this was an interesting read: http://www.varnish-cache.org/trac/wiki/ArchitectNotes Too bad he talks about his approach being "2006 era" programming. In fact the single-level store is 1964-era, from Multics. http://en.wikipedia.org/wiki/Single_level_store I guess they'll have to tweak Henry Spencer's quote ("Those who do not understand UNIX are condemned to reinvent it, poorly.") to Multics instead... I've been working on a new "in-memory" B-tree library that operates on an mmap'd file. It is a copy-on-write design; it supports MVCC and is immune to corruption and requires no recovery procedure. It is not an append-only design, since that requires explicit compaction, and also is not amenable to mmap usage. Also the append-only approach requires total serialization of write operations, which would be quite poor for throughput. The current approach simply reserves space for two root node pointers and flip flops between them. So, multiple writes may be outstanding at once, but commits are of course serialized; each commit causes the currently unused root node pointer to become the currently valid root node pointer. Transaction aborts are pretty much free; there's nothing to rollback. Read transactions begin by snapshotting the current root pointer and then can run without any interference from any other operations. Public commits have been waiting for our official transition to git, but since that's been going nowhere I will probably start publishing on github.com in the next couple of weeks. (With St. Patrick's Day right around the corner it may have to wait a bit.) Unfortunately I realized that not all application-level caching can be eliminated - with the hierarchical DB approach, we don't store full entry DNs in the DB so they still need to be generated in main memory, and they probably should be cached. But that's a detail to be addressed later; it may well be that the cost of always constructing them on the fly (no caching) is acceptable. This backend should perform much better in all aspects (memory, CPU, and I/O usage) than the current BerkeleyDB code. It eliminates two levels of caching, entries pulled from the DB require zero decoding, readers require no locks, writes require no write-ahead-logging overhead. There are only two configurable parameters (the pathname to the DB file, and the size) so this will be far simpler for admins. Potential downside - on a 32 bit machine with only 2GB of addressable memory the maximum usable DB size is around 1.6GB. On a 64 bit machine, I doubt the limits will pose any problem. ("64 bits should be enough for anyone...") re: configuring the size of the DB file - this is most likely not a value that can be changed on an existing DB. I.e., if you configure a DB and find that you need to grow it later, you will probably need to slapcat/slapadd it again. At DB creation time the file is mmap'd with address NULL so that the OS picks the address, and the address is recorded in the DB. On subsequent opens the file is mmap'd at the recorded address. If the size is changed, and the process' address space is already full of other mappings, it may not be possible to simply grow the mapping at its current address. Since the DB records contain actual memory pointers based on the region address, any change in the mapping address would render the DB unusable. If this restriction turns out to be too impractical, we may have to resort to just storing array offsets, but that will then imply a decoding phase and the re-introduction of entry caching, which I really really want to avoid. -- -- 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 6

slapo-chain back-config vs. slapd.conf
by Ralf Haferkamp 11 Mar '11

11 Mar '11

While trying to implement back-config delete support for slapo-chain I stumbled across some inconsistencies in slapo-chain's configuration routines. When using slapd.conf it is not possible to configure some settings for slapo-chain's underlying back-ldap database. E.g. things like chain "-sizelimit", "-restrict", "-limits" are just rejected. OTOH when using cn=config slapd will accept all these settings just fine and writes them to the database. They don't have any effect however. It would be nice if cn=config and slapd.conf behaved more consistent here. Either by both rejecting general database options (everything that's not a specific back-ldap option) for the underlying back-ldap databases or by correctly applying them. I tend to think the latter approach could make sense. It would e.g. allow to define different size and timelimits for chained operations or would allow to setup a chain-overlay that only chains read operations (by setting olcReadOnly on the underlying LDAP database). I have already starting implementing parts of this. But if people think it does not make much sense it would still be early enough to dump the code and forget about it :). Ralf

1 0

AttributeDescriptions, OpenLDAP 2.5
by Howard Chu 10 Mar '11

10 Mar '11

I plan to replace all AttributeDescription pointer references with array references instead. It makes back-mdb a lot more portable, and it also saves us 4 bytes for every attribute on 64 bit machines. At a microscopic level it imposes some extra overhead on each reference (instead of a direct pointer deref, you have to do pointer+offset arithmetic) but on modern CPUs simple address offsets like this come for free anyway. A change of this nature will necessarily touch the majority of slapd code as well as 3rd party overlays. Making this switch will mean that patches for RE24 will almost always be incompatible with patches for HEAD/RE25. Very likely the same change should be made for the rest of the common data types in slapd. (E.g., ObjectClasses, AttributeTypes, Syntaxes, etc.) But since AttributeDescriptions are used in every Entry these will have the most impact on slapd's memory footprint, the others are inconsequential. -- -- 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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel