[Freeipa-devel] DESIGN: Recover DNA Ranges

[Simo Sorce]

On Wed, 2013-02-27 at 15:00 -0500, Rob Crittenden wrote:
> Sumit Bose wrote:
> > On Wed, Feb 27, 2013 at 02:03:24PM -0500, Rob Crittenden wrote:
> >> Sumit Bose wrote:
> >>> 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.
> >
> > Thank you. I would like to suggest a slight edit. Instead of
> >
> > "That doesn't remove our responsibility to not test for overlaps in the
> > idranges though. We will need to verify that the manual configuration
> > changes do not overlap with all ranges in cn=ranges,cn=etc,$SUFFIX."
> >
> > I would say
> >
> > "That doesn't remove our responsibility to not test for overlaps in the
> > idranges though. We will need to verify that the manual configuration
> > changes do
> > * not overlap with ranges from trusted domains
> >    (objectclass=ipatrustedaddomainrange) in cn=ranges,cn=etc,$SUFFIX, or
> >    reject the change otherwise.
> > * overlap completely with ranges from the local IPA domain
> >    (objectclass=ipaDomainIDRange) in cn=ranges,cn=etc,$SUFFIX, or give a
> >    warning otherwise which asks the user to add a new suitable idrange."
> >
> > Codewise the logic could be:
> > - check if the new range is a subset of a local idrange, if yes, all is
> >    fine
> > - if not, check if it overlaps with an idrange of a trusted domain, if
> >    yes, reject
> > - if not, give a warning and ask to add a new idrange for the local
> >    domain
> 
> I took this almost verbatim but I'm more harsh. If the range is outside 
> the local range and not overlapping anything I will still reject it. If 

the local ranges ^^ the admin may have already added additional ones, so
it needs to be plural.

> we're going to go through the trouble of keeping them in sync we should 
> be consistent.

Otherwise good plan.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York