Adam Young wrote:
On 10/26/2010 11:21 PM, Simo Sorce wrote:
So, I have been working on this ipa_uuid plugin as of late and one of
the last tasks was to let it modify the RDN if ipaUniqueID is part of
the DN of an entry we want to create.
Example:
dn: ipauniqueid=autogenerate,cn=hbac,dc=...
cn: foo rule
hbactype: allow
...
'autogenerate' is the magic value that makes the ipa_uuid plugin
generate a uuid and set it on the entry.
The problem is that LDAPCreate, after adding the entry will try to
search it back immediately using the DN we passed in. This search will
fail as the DN that is stored in LDAP is different (it has the
generated uuid instead of 'autogenerate').
So ideas on how to gracefully handle this are welcome.
I discussed of 2 with Rob on IRC but we'd like more inputs (Pavel, that
would be directed at you :-).
1. Ignore the error in calls that pass in a DN containing ipauniqueid
as the RDN and perform a new search.
2. modify LDAPCreate so that we can pass in a filter. If the caller
passes in a filter we use that instead of the DN to search the entry
back.
Simo.
I'm not up to speed on this code. Why do a find right after create?
Normally an add works like this.
* Use the get_dn() class method to create the dn based on the primary
key and the container.
* call add_entry()
* do a get_entry() to retrieve the data we just added to we can show the
user what we did.
In the case of HBAC and netgroups the dn contains the attribute
ipaUniqueId which is something we want to autogenerate. So the dn we
pass the add function isn't going to match the dn that gets written to
the database.
The get_entry() is failing because we are trying to read dn:
ipauniqueid=autogenerate, ... and what got written was dn:
ipauniqueid=1092a93-9as9d-f...
So we need some way of finding the entry we just wrote, whose uniqueid
we don't know (but we know other stuff about it).
rob
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
