On Wed, 2014-06-18 at 11:39 +0200, thierry bordaz wrote: > On 06/17/2014 09:42 PM, Simo Sorce wrote: > > On Tue, 2014-06-17 at 21:36 +0200, thierry bordaz wrote: > >> On 06/17/2014 09:29 PM, Simo Sorce wrote: > >>> On Tue, 2014-06-17 at 15:23 -0400, Rob Crittenden wrote: > >>>> Simo Sorce wrote: > >>>>> On Tue, 2014-06-17 at 17:59 +0200, thierry bordaz wrote: > >>>>>> * ipa stageuser-add <login> --from-delete > >>>>>> > >>>>>> It moves a deleted entry to staging container where > >>>>>> > >>>>>> uidNumber: <unchanged, so it is preserved from the > >>>>>> prevous active account> > >>>>>> gidNumber: <unchanged, so it is preserved from the > >>>>>> prevous active account> > >>>>>> ipaUniqueID: autogenerate (reset to autogenerate) > >>>>> Why are you resetting the unique id ? > >>>> Read back a few in the thread. I suggested, perhaps incorrectly, that > >>>> given that there should be no more references to the user once they go > >>>> into deleted or staged, it may be ok to reset this value. > >>> Well, let me reiterate, the deleted bucket is for those environments > >>> where they have a mandate (regulation, law, policy, etc..) to never > >>> delete users and reinstate users if they are deleted. > >>> So all uniquely identifying information should be preserved in case the > >>> object is revived. This means we need to do our best to preserve all > >>> these attributes if we can. > >> This is what is done when an Active user is deleted. > >> uidNumber/gidNumber/ipaUniqueID are preserved. > >> When activating a user, currently UUID plugin prevents to set a value. > >> Should it be relaxed.. I feel not. It is a sensitive info and > >> provisioning system should not define it. > > Why is it sensitive ? A ipaUniqueID is not really sensitive, it just > > needs to be unique. > > Ok. I believed it was :-) > > I have a concern, if a provisioning system is free to define this value, > I wonder if it can create problem for replication. > For example a provisioning system creates two staging entries on > different servers but with the same ipaUniqueID value.
A provisioning system should never have to contact 2 different servers, what would be the point ? And then on top of that generate the same UUID ? Well don't do that, fix your provisioning tool. > If the entries are activated at the same time, the ADDs operation > (activation) will not be replicated because the attribute uniqueness > plugin will reject it. Right, don't do that. > This case existed before if two IPA uuid plugins generated identical > value on different replica. But the probability was less than if the > provisioning system is free to set it. Sure, but who cares ? I mean there are *many* ways to whose a system, the provisioning system can simply create 2 users accounts with the same name on 2 servers and get them activated at the same time and you get the same issue as uid is also unique. Just fix the malfunctioning provisioning system. > >> When undelete a user (move Delete->Staging), ipaUniqueID can be > >> preserved but as the purpose of Staging entry is to become active I > >> thought it would be better to wipe the value also at this time. > > I understand that (and I noted before that I think deleted->staged is a > > bad idea IMO :-) ), but you are wiping it only as a workaround, because > > the plugin prevents you from adding it. Would have you wiped it if it > > were not the case ? And if so, why ? > > That is correct. I thought to wipe it because the plugin rejected values > others than 'autogenerate'. > > To relax the control that rejects values other than 'autogenerate', I > need to modify the plugin. Should it be done under an other ticket or > can it be part of this RFE ? I think it can be part of this RFE, should we use the Relax Control for this ? I think it may still valuable to enforce the rule in non-staging cases. Simo. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel