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 > catch? > 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 > back-<bdb,hdb,mdb>). > > - Issues which the tool can only catch if it opens the database, like > attempts > 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/

Le 24/03/15 23:56, Howard Chu a écrit : > 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 catch? >> 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.

Let me disagree. A simple merge sort will do the trick. No need of a database to deal with that, even for a large LDIF. We have done some tests with the tool we use to handle bulkloads at ApacheDS, and that works quite fine, and quite fast enough.