[Freeipa-devel] RFC wrt little snag in LDAPCreate when ipa_uuid manipulates the DN on entry add

[Rob Crittenden]

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