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 _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel