[Date Prev][Date Next]
Re: slaptest-ldif -l <ldif> tool or slapadd option
- To: Howard Chu <email@example.com>
- Subject: Re: slaptest-ldif -l <ldif> tool or slapadd option
- From: Mathieu <firstname.lastname@example.org>
- Date: Wed, 25 Mar 2015 00:19:56 +0100
- Cc: Hallvard Breien Furuseth <email@example.com>, openldap <firstname.lastname@example.org>
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=M9jT/Ek2Wcrk8nXv+ZVmDuMA1BxDcf2YdnbB1uOf4zc=; b=cLF1Hj86rCyL9MzlQfxsLfY9/nn/LhHLe08kH6RGM09FaV1bGyX7nsvarbFZIMMLPJ biBeN7PS7knsMWMyo3k75hlgzmSzy7enm/1161SF1r1xvgGxOJdq2pKfsrp11SZQL10v aIurXcPl6norOzB8o0/haTfy1+9Q2hwzeKDMr2ery8tr1rmb6zyEg+n3bNYzTocqGLL9 2b+pODZd5OYXE4AuXVe5JSWDmLPmm5GX8Ko+F7GYuA21Y8jHFsRKEKzFJGPkO6WuB9mU faZ/JQld3qVzUiYPsO/7qkrufRe3lxpwOIO5foKpIo/Xp3NXYoWfKZBekd9WcVTUID4P J+Xg==
- In-reply-to: <5511EB83.email@example.com>
- References: <firstname.lastname@example.org> <5511EB83.email@example.com>
These requirements are definitely too loosely described to be
implemented. But maybe prerequisites could be added to the slapadd
operation, mimicking dynamic dns (rfc2136)?
That way all prerequisites would be sent by the client, and the server
would "just" have too check them before applying the changes. I know
it looks a like as a ldapsearch (to check these prerequisites)
followed by a ldapadd, but if implemented server side it could be done
in an atomic way?
On Tue, Mar 24, 2015 at 11:56 PM, Howard Chu <firstname.lastname@example.org> wrote:
> Hallvard Breien Furuseth wrote:
>> I'd like a slap tool which verifies an LDIF before I try to
>> ldapadd/slapadd it.
>> "slapadd -u -o value-check=yes" is fairly close. What does it fail to
>> I can think of:
>> - Duplicate entries.
> Quite an unrealistic requirement. You need to store the set of entryDNs to
> achieve this, and for a large LDIF you may need an actual database to manage
> this. Might as well just do a normal slapadd.
>> - Missing entries (if the initial DB is expected to be empty).
>> - Child entries before parents (OK for slapadd to at least
>> - Issues which the tool can only catch if it opens the database, like
>> to add already-existing entries. I probably don't want to do that.
>> - Issues which overlays like slapo-unique would reject. Can't do that,
>> since the overlay won't have a non-empty DB to check against and slap
>> tools do not use overlays anyway. Might special-case "unique" though,
>> since the "duplicate entries" check will need uniqueness code anyway.
> -- Howard Chu
> CTO, Symas Corp. http://www.symas.com
> Director, Highland Sun http://highlandsun.com/hyc/
> Chief Architect, OpenLDAP http://www.openldap.org/project/