[Freeipa-devel] another snag with kerberos

[Simo Sorce]

On Thu, 2007-07-19 at 10:44 -0700, Pete Rowley wrote:
> Karl MacMillan wrote:
> > On Thu, 2007-07-19 at 09:55 -0700, Pete Rowley wrote:
> >   
> >
> > In previous discussions I thought we had decided that it would be
> > available if we were willing to assume the testing burden.
> >
> >   
> I don't recall that specifically for this but if we need it it needs to 
> be compiled in e.g. in RHDS 8.0 which almost certainly doesn't right 
> now, it isn't in a plugin, it is core.

I remember this as well, and the deal was that we would test it, but no
official support would be provided in 8.0, it would be provided only as
part of IPA until deemed stable enough to be included officially in RHDS
(maybe in 8.1 ?).

> > Agreed on all 3 points - which is why I suggested it :) I think this is
> > a short-term architectural decision not a long term one.
> >
> >   
> I am pointing out that it isn't so short term and as such we need to go 
> in with eyes wide open.

I am sorry I couldn't chime in before. We need the krb auth in any case,
but the forwardable ticket bit can indeed be skipped for v1 using the
ldapi:// feature.

But we _need_ the RPC layer, for many reasons. One reason is certainly
the fact that we don't want to let people use too much ldap at this
stage or that will mean our ability to change schemas and DIT structure
will be critically restrained. And we absolutely need the flexibility to
change them to grow in v2 and v3.
Also (and this is important imo) we want to support multimaster setups,
and we need a method for one server to talk to another when changes are
made to configuration parameters not stored in ldap. Without an RPC
layer this is going to quickly become a mess of custom developed
assortment of mechanisms.

The RPC layer is not just about the GUI, it is about controlling a
server in many aspects, not only LDAP objects.

So if Kerberos proxying/forwarding is the problem, let's just reduce the
amount of work to address that problem and move on with our RPC stuff.
But cutting RPC out of the picture is going to be more work then not
doing it in the medium term imo.

Simo.