[Freeipa-devel] User life Cycle: referential integrity

[thierry bordaz]

On 06/04/2014 06:02 PM, Simo Sorce wrote:
> On Wed, 2014-06-04 at 17:46 +0200, thierry bordaz wrote:
>> Hello,
>>
>>          I am looking at the appropriate way to configure DS
>>          referential integrity and I am hitting some issues about its
>>          scoping and which attributes need to be preserved.
>>          
>>          
>>          User A  and B are both  Active. User A refers user B for
>>          example 'owner: <DN user B in Active container>'.
>>          If entry A is deleted (user-del), it keeps 'owner: <DN user B
>>          in Active container>'. Do we really want to preserve such
>>          attributes (owner, member, seeAlso...) in case the user is
>>          coming back (user-undel) ?
> No, when a user is deleted all references to it in the rest of the tree
> should be removed. the entries "it" references can stay I guess, the
> user is deleted so no harm should come from it having dangling DNs in
> its attributes.
Actually it was my concern. If users A then B are moved Active->Delete 
(user-del), then the reference to B in the 'Active' container is not 
removed by RI. If for any reason user A returns to Active (user-undel), 
it contains dangling DN unless it is checked/removed.
>>          If it makes sense we may achieve this if we extends RI to both
>>          'Active' and 'Delete' container.
> Nope, makes no sense.
>
>>          If we prefer to remove such attributes, then 'user-del' is a
>>          MODRDN followed by some MODs or a ADD-DEL where the Delete
>>          entry is rebuilt from the 'Active' entry.
> Delete must be a modrdn, we cannot delete the entry and re-add it.
ok great :)
>>          This is a similar problem when using 'stageuser-add <id>
>>          --from-delete', the references may become invalid (unless RI
>>          also covers Staging).
> There should be no references in either staged or delete users, or they
> should be adjusted when the user is unstaged/undeleted.
>
>>          An option would be to accept to have invalid references in
>>          'staging' and 'delete', but when the entry is
>>          stageuser-activate/user-undel the reference are checked and
>>          removed if invalid. Here invalid means, the referred entry
>>          does not exist or is not 'Active'.
> Yup, this sounds right, when you "activate" the user references need to
> be checked and adjusted accordingly.
Which attributes need to be checked/adjusted ? those configured in RI ? 
attributes with DN syntax ?

thierry
>
> Simo.
>