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@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users
