Re: [Freeipa-devel] RFC wrt little snag in LDAPCreate when ipa_uuid manipulates the DN on entry add
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? ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] RFC wrt little snag in LDAPCreate when ipa_uuid manipulates the DN on entry add
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
Re: [Freeipa-devel] RFC wrt little snag in LDAPCreate when ipa_uuid manipulates the DN on entry add
Simo Sorce wrote: On Wed, 27 Oct 2010 09:35:17 -0400 Adam Youngayo...@redhat.com wrote: I'm not up to speed on this code. Why do a find right after create? I guess to pick up all attributes added automatically by DS, not sure why it just is. Simo. Yes, that's exactly it. We have other autogenerated values (uid, gid) so we fetch the entry to be sure we are representing things as they are. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] RFC wrt little snag in LDAPCreate when ipa_uuid manipulates the DN on entry add
Rob Crittenden wrote: Simo Sorce wrote: On Wed, 27 Oct 2010 09:35:17 -0400 Adam Youngayo...@redhat.com wrote: I'm not up to speed on this code. Why do a find right after create? I guess to pick up all attributes added automatically by DS, not sure why it just is. Simo. Yes, that's exactly it. We have other autogenerated values (uid, gid) so we fetch the entry to be sure we are representing things as they are. One enhancement we have discussed adding to 389 is a control sent with update operations - the control response would contain the values of generated attributes, to remove the need to immediately perform a search to get attributes such as uniqueid, uid, gid, createTimestamp, etc. Is this something IPA would be interested in? There has already been some discussion (a long time ago) on the 389 lists. afaik there is no LDAP proposed standard feature for this. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] RFC wrt little snag in LDAPCreate when ipa_uuid manipulates the DN on entry add
On Wed, 27 Oct 2010 14:52:17 -0600 Rich Megginson rmegg...@redhat.com wrote: Rob Crittenden wrote: Simo Sorce wrote: On Wed, 27 Oct 2010 09:35:17 -0400 Adam Youngayo...@redhat.com wrote: I'm not up to speed on this code. Why do a find right after create? I guess to pick up all attributes added automatically by DS, not sure why it just is. Simo. Yes, that's exactly it. We have other autogenerated values (uid, gid) so we fetch the entry to be sure we are representing things as they are. One enhancement we have discussed adding to 389 is a control sent with update operations - the control response would contain the values of generated attributes, to remove the need to immediately perform a search to get attributes such as uniqueid, uid, gid, createTimestamp, etc. Is this something IPA would be interested in? There has already been some discussion (a long time ago) on the 389 lists. afaik there is no LDAP proposed standard feature for this. Looks like an interesting thing. It would also help esp. in the case we change the DN under users noses. But the patch Pavel sent seem to deal well with the current contingency. Still I would mark it as a nice to have. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
