[389-users] 389-console LDIF export question

[Rich Megginson]

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 
>>> done).
>>> 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
>
> regards
> mIke
>
>
>>
>>>
>>> thanks for any hint.
>>> regards
>>>
>>> Mike
>>>
>>> -- 
>>> 389 users mailing list
>>> 389-users at lists.fedoraproject.org
>>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>>
>