[Freeipa-devel] DESIGN: Recover DNA Ranges

[Sumit Bose]

On Wed, Feb 27, 2013 at 09:50:21AM -0500, Rob Crittenden wrote:
> Sumit Bose wrote:
> >On Mon, Feb 25, 2013 at 03:12:19PM +0100, Martin Kosek wrote:
> >>On 02/25/2013 03:09 PM, Rob Crittenden wrote:
> >>>Martin Kosek wrote:
> >>...
> >>>>4) What does "NOTE: We will need to be clear that this range has nothing to do
> >>>>with Trust ranges." actually mean? AFAIU, IPA should have all local ranges
> >>>>covered with a local "idrange" range(s).
> >>>
> >>>IPA ranges is completely separate from DNA ranges. You can set/modify all the
> >>>local ranges you want and it won't affect the UIDs getting assigned.
> >>>
> >>>>If it does not have it covered, it could happen that for example a new trust
> >>>>would overlap with this user-defined local range and we would have colliding
> >>>>POSIX IDs...
> >>>
> >>>Hmm, that's a good point.
> >>>
> >>>>IMO, dnarange-set and dnanextrange-set should at first check if the range is
> >>>>covered with some local idrange and only then allowed setting the new range.
> >>>
> >>>I can do that as well, but again, the local ranges don't really affect the ids
> >>>we hand out via DNA.
> >>>
> >>>rob
> >>
> >>You are right, that DNA plugin is really not aware of the idranges we set in
> >>IPA. But the idrange is still a safeguard for our POSIX IDs to not overlap with
> >>trust ranges and I think we should respect that with ipa-replica-manage.
> >>
> >>I wonder if there was not even a plan to increase cooperation between our
> >>idranges and DNA plugin, maybe Sumit or Alexander knows more.
> >
> >If I understand the use case and design properly, it is about
> >re-arranging the sub-ranges each replica can use from the original
> >range, which was given/created at installation time and which is also
> >stored as idrange in
> >DOMAIN.NAME_id_range,cn=ranges,cn=etc,dc=domain,dc=name with
> >objectclass=ipaDomainIDRange.
> >
> >If the re-arrangement does not result in IDs which are outside of this
> >range give by the ipaDomainIDRange object, no conflicts with idranges
> >used by trusted domain will occur, because it is one of the task of the
> >idrange objects to avoid those conflicts.
> >
> >If the original given range is exhausted completely and a completely new
> >DNA range must be created, it should be checked with ipa idrange-find
> >that the new range is not used and a new ipaDomainIDRange object which
> >reserves the local range should be added.
> >
> >There are https://fedorahosted.org/freeipa/ticket/591 which can be used
> >to track the coordinated creation of DNA and id-range.
> >
> 
> Honestly, I was going to skip the range stuff altogether and just
> focus on the DNA ranges.
> 
> I'm primarily interested in saving any range from a server that is
> going to be deleted. I can save that in the on-base attribute of any
> existing servers. Where I run into trouble is if all the on-base are
> populated, then we'd lose range. So I need to alert the user
> somehow.

If it is only about moving existing DNA range it is fine, because this
means that DNA will not give ID which are outside of the idrange of the
IPA domain which is created at installation or during upgrade to v3.
> 
> This leads to wanting to be able to add that back in so I came up
> with the idea of letting users manage the DNA range directly. It may
> be possible to check the DOMAIN ranges as well but that bumps the
> complexity up considerably.

But it looks like dnarange-set and dnanextrange-set can also be used to
not only move existing DNA ranges but to create new DNA ranges which
will lead to ID which are not in the idrange of the IPA domain but might
be in an idrange which is used by a trusted domain. So I think a check
and a warning are desirable.

bye,
Sumit

> 
> rob