Richard Megginson wrote:
----- Original Message -----
> David,
>
> Thank you so much for the 3 replies. They are VERY illuminating and helpful
> for me to now press ahead and better address my own particular needs based
> on our “requirements”. What I now intend to do is to perform, at regular
> intervals, db2bak to a specific directory. as i would like to convert the
> bak db to ldif, it doesn’t appear there is a relatively easy way to do this…
You can use the dbscan tool to convert the id2entry.db4 file in the backup to an
"ldif-ish" format.
dbscan -f /path/to/backup/id2entry.db4 > db.ldif-ish
I say "ldif-ish" because it mostly looks like ldif, except the formatting is
off.
The biggest issue is that the full DN is not stored as the "dn:" attribute in
the ldif. Instead, it is the RDN of the entry, and at runtime, the entryrdn.db4 index is
used to construct the full DN. I think there may be operational attributes like entrydn
in the dbscan output that you might be able to use for the dn. Otherwise, you'll also
have to dbscan -f /path/to/entryrdn.db4 and parse the output to perform your own mapping
of rdn + parentid to the full DN.
We may want to implement a utility to get full DN
from entryid... (or
rdn + parentid)
> either i’d have to mockup a new config dir to reference the bak db as the
> real db so db2ldif will work
That also might work.
> or i would have to create a new slapd instance
> and then configure it for schema and such to be identical to the real
> instance on the server and then db2bak with the output being the bak
> instance so i can run db2ldif on on the bak db. Bummer.
>
> nonetheless, i do appreciate your timely responses and the education i gained
> from them.
>
> /mrg
>
> On May 14, 2014, at 5:49 PM, David Boreham <david_list(a)boreham.org> wrote:
>
>> On 5/14/2014 3:11 PM, Michael Gettes wrote:
>>> of course, you can have yet another ldap server lying around not being
>>> used by apps and it’s purpose is to dump
>>> the store periodically, but that may not be part of you what want to
>>> achieve with disparate locations and such.
>> This is a useful approach if your servers are subject to heavy load,
>> specifically heavy load that generates disk I/O.
>> Backing up from a replica that is not serving client load can allow you to
>> decouple the I/O load related to the backup from I/O activity related to
>> client requests. With the use of SSDs (which have very high concurrent
>> throughput vs disks) these days, this is less of an issue however.
>>
>> --
>> 389 users mailing list
>> 389-users(a)lists.fedoraproject.org
>>
https://admin.fedoraproject.org/mailman/listinfo/389-users
> --
> 389 users mailing list
> 389-users(a)lists.fedoraproject.org
>
https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users