[389-users] 389-console LDIF export question
rmeggins at redhat.com
Thu Jun 27 18:52:29 UTC 2013
On 06/27/2013 12:32 PM, Michael Lang wrote:
> On 06/27/2013 06:13 PM, Rich Megginson wrote:
>> On 06/27/2013 04:57 AM, Michael Lang wrote:
>>> Dear all,
>>> I would like to clarify how the procedure to "export -> LDIF"
>>> through the 389-console GUI is done (or how if reproduce should be
>>> As far as I've understood the exports on the server itself is done
>>> through creating a appropriate entry in cn=export,cn=task,cn=config
>>> For "remote" machines using the GUI this isn't valid as the
>>> nsFilename attribute requires a local write able location. What I've
>>> seen through looking at the
>>> LDAP protocol queries done during an export-to-ldif on console
>>> machine task is a query to the schema listing all attributeTypes
>>> which are then sent as attribute-retrieve-list in the ldap search.
>>> At least that's how I was able to reproduce the same LDIF from
>>> GUI-Console export and manually. Is this correct and should this be
>>> done in that way ? (I've noticed also the "Warning: If you don't
>>> have permissions" statement when using the LDIF export in the
>>> Console which more-or-less ack's my approach)
>> Right. There is no way to do a database export to LDIF to a remote
>> file on a remote machine.
>> Are you trying to figure out a way to generate an LDIF file using
>> ldapsearch that looks exactly like a database export LDIF file? Why?
> reason for that, I might not have "file based" access on the server
> itself but need to do backup's of the database which are not "setup
> specific" (with setup specific I mean without the right database
> configurations I might not be able to import the content).
> in this special case why I started to look into the ldif create, I had
> database backups but ran into a situation where my directory console
> was showing content but ldapsearch (and other tools/applications)
> where not getting any content at all. It was a strange situation and
> restoring the database trough restore didn't help where droping the
> databases and importing and LDIF was working (I still had another
> server running with the content). As mentioned above for the machines
> I have under complete access this shouldn't be the issue, but I also
> have other machines where I might be forced to do this through the
> LDAP protocol.
That particular case sounds like you were missing the "aci" attribute
which is an operational attribute.
In general, if you want "everything"(1), you can do a search like this:
ldapsearch -b dc=your,dc=suffix
'(|(objectclass=*)(objectclass=ldapsubentry))' \* $OPERATIONAL_ATTRS
where $OPERATIONAL_ATTRS is a list of operational attributes you can get
from the schema. You'll definitely want "aci" in that list.
If you know python, python-ldap has a nice schema parser.
(1) This still won't get you everything - specifically, you won't get
deleted entries and other replication metadata - If you think you need
that information, add (objectclass=nsTombstone) to the search filter above.
> thanks for your response
>>> thanks for any hint.
>>> 389 users mailing list
>>> 389-users at lists.fedoraproject.org
More information about the 389-users