[Freeipa-devel] Some thoughts about login services

[Simo Sorce]

On Fri, 15 Oct 2010 14:12:22 -0400
Dmitri Pal <dpal at redhat.com> wrote:
> Simo Sorce wrote:

> > I'd go for the last one, may be ugly, but does not undo anything
> > that already works and has the effect of simplifying the UI which
> > is what you are after right now. Of course that also means the UI
> > will have to cope (maybe disabling editing) with any entry that has
> > been nested through the CLI or over LDAP directly.
> >   
> 
> This is where ugliness comes to play.
> 
> > This is assuming the UI work would really be more complex. We have
> > nesting to support for other things already so I am not sure it
> > would really be substantially less work to do the same thing
> > elsewhere, I bet a lot of code could simply be reused.
> >
> >   
> 
> It is not that simple.
[..]

Ok, then I guess removing the possibility is simpler.
Though reading the schema definition I wonder one thing. Why did you
make these objectclasses derive from nestedGroup ?
I would have expected them to be "SUP groupOfNames" and just have the
clients add nestedGroup if they wished to enable them to be nested.
Of course this means nestedGroup needs to be AUXILIARY and not
STRUCTURAL.
Is there any reason to make nestedGroup forcibly structural ?
Having it auxiliary means we can later add it to objects not currently
nestable, although this may also be seen as a liability.

The problem is that if we do not then we are stuck with whatever we
decide I think. Changing a fundamental objectclass once we reach 2.0 is
one of things we tentatively forbid ourselves to do in the name of
compatibility.

Simo.

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