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. 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.

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.

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 ?



Freeipa-devel mailing list

Reply via email to