Hi all,
According slapcat(1) man:
"The output of slapcat is intended to be used as input to slapadd(8). The output of slapcat cannot generally be used as input to ldapadd(1) or other LDAP clients without first editing the output. This editing would normally include reordering the records into superior first order and removing no-user-modification operational attributes."
So, I've done:
# making normal LDIF using slapcat(1) $ slapcat -l test_backup.ldif
# cleaning the LDIF and dump the results in another file $ egrep -ve '^(entryUUID|creatorsName|structuralObjectClass|createTimestamp|entryCSN|modifiersName|modifyTimestamp): ' \ test_backup.ldif > test_backup_cleaned.ldif
#viewing the differences $ diff -y test_backup.ldif test_backup_cleaned.ldif | less
¿Is it a correct way to "clean" the initial LDIF you can get with slapcat(1)?
And another minor question
¿Can I use the slapcat(1) tool on the fly? man pages say nothing about it.
Hi all,
According slapcat(1) man:
There is no slapcat(1) man page. You probably mean slapcat(8).
"The output of slapcat is intended to be used as input to slapadd(8). The output of slapcat cannot generally be used as input to ldapadd(1) or other LDAP clients without first editing the output. This editing would normally include reordering the records into superior first order and removing no-user-modification operational attributes."
So, I've done:
# making normal LDIF using slapcat(1) $ slapcat -l test_backup.ldif
# cleaning the LDIF and dump the results in another file $ egrep -ve '^(entryUUID|creatorsName|structuralObjectClass|createTimestamp|entryCSN|modifiersName|modifyTimestamp): ' \ test_backup.ldif > test_backup_cleaned.ldif
#viewing the differences $ diff -y test_backup.ldif test_backup_cleaned.ldif | less
¿Is it a correct way to "clean" the initial LDIF you can get with slapcat(1)?
Assuming there are no other operational attributes in your database, yes with respect to eliminating NO-USER-MODIFICATION attrs. There's still no guarantee entries are sorted in superior-first order.
And another minor question
¿Can I use the slapcat(1) tool on the fly? man pages say nothing about it.
According to slapcat(8):
LIMITATIONS For some backend types, your slapd(8) should not be running (at least, not in read-write mode) when you do this to ensure consistency of the database. It is always safe to run slapcat with the slapd-bdb(5), slapd-hdb(5), and slapd-null(5) backends.
so to answer one needs to know what backend you're referring to.
p.
There is no slapcat(1) man page. You probably mean slapcat(8).
Ups! Yes, I mean slapcat(8) ;)
Assuming there are no other operational attributes in your database, yes with respect to eliminating NO-USER-MODIFICATION attrs. There's still no guarantee entries are sorted in superior-first order.
Ok.
And another minor question
¿Can I use the slapcat(1) tool on the fly? man pages say nothing about it.
According to slapcat(8):
LIMITATIONS For some backend types, your slapd(8) should not be running (at least, not in read-write mode) when you do this to ensure consistency of the database. It is always safe to run slapcat with the slapd-bdb(5), slapd-hdb(5), and slapd-null(5) backends.
so to answer one needs to know what backend you're referring to.
Ok. I use bdb backend, so I have to use slapd-bdb(5) as reference. I've not found any word about the possibility or not to make copies "on the fly".
Maybe a simple
$ /usr/bin/ldapsearch -x -b 'dc=mydomain,dc=com' '(objectclass=*)' > backup.ldif
it's more comfortable option. I understand I always can delete the actual database, reinject the LDIF file with ldapadd and when the service is restarted, the ddbb is generated automatically.
For some backend types, your slapd(8) should not be running (at least, not in read-write mode) when you do this to ensure consistency of the database. It is always safe to run slapcat with the slapd-bdb(5), slapd-hdb(5), and slapd-null(5) backends.
so to answer one needs to know what backend you're referring to.
Ok. I use bdb backend, so I have to use slapd-bdb(5) as reference. I've not found any word about the possibility or not to make copies "on the fly".
Please carefully re-read the above text: "IT IS ALWAYS SAFE TO RUN SLAPCAT WITH THE SLAPD-BDB(5) BACKEND".
p.
Jordi Espasa Clofent writes:
# cleaning the LDIF and dump the results in another file $ egrep -ve '^(entryUUID|creatorsName|structuralObjectClass|createTimestamp|entryCSN|modifiersName|modifyTimestamp): ' \ test_backup.ldif > test_backup_cleaned.ldif
Note that long LDIF lines can be split. A line starting with space is a continuation of the previous line. So pass the LDIF file through perl -wp00e 's/\r?\n //g' before doing per-line operations like 'grep' on it.
Should only be relevant in this case for creatorsName or modifiersName if they're longer than something like 'cn=admin,dc=example,dc=com', but it's a good habit to get into anyway.
Jordi Espasa Clofent writes:
# cleaning the LDIF and dump the results in another file $ egrep -ve '^(entryUUID|creatorsName|structuralObjectClass|createTimestamp|entryCSN|modifiersName|modifyTimestamp): ' \ test_backup.ldif > test_backup_cleaned.ldif
Note that long LDIF lines can be split. A line starting with space is a continuation of the previous line. So pass the LDIF file through perl -wp00e 's/\r?\n //g' before doing per-line operations like 'grep' on it.
Should only be relevant in this case for creatorsName or modifiersName if they're longer than something like 'cn=admin,dc=example,dc=com', but it's a good habit to get into anyway.
I wonder whether it makes sense to allow an optional (negated) list of attributes to return.
p.
openldap-technical@openldap.org
-
Hallvard B Furuseth -
Jordi Espasa Clofent -
masarati＠aero.polimi.it