[Freeipa-devel] DESIGN: Recover DNA Ranges

[Rob Crittenden]

Sumit Bose wrote:
> 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.

That is an excellent point. I've updated the design.

rob