abartlet at samba.org
Tue Aug 30 19:30:11 GMT 2005
On Tue, 2005-08-30 at 22:09 +1000, tridge at samba.org wrote:
> > does this means samba4 will use (the latest'n'gratest) heimdal or it has
> > it's own kerberos server which was drived from heimdal?
> it has a builtin copy of heimdal in source/heimdal/
> We hope that once the upstream heimdal has all the necessary hooks and
> features (which thanks to lha could well be quite soon!) that we could
> also support a build option to use the system heimdal, much like we
> support using the system popt library, but have a builtin one as well
> in case the system one isn't there.
This is quite a long way down the track, due to changes we have made in
bringing Heimdal directly into Samba4. For example, we currently stub
out a number of Heimdal functions and literally replace them with Samba
functions, then relink the result. This means that Heimdal uses Samba's
network interface control code and 'interfaces = ' smb.conf options
(very good), but also means we would need to add an appropriate plugin
interface before we could rely on an external Heimdal (work to be done).
There are a number of places were we need to do this work, like for DNS
lookups and the socket calls to and from the KDC.
> Futher down the track we might also support using an external MIT
> kerberos implementation, if we can get a set of hooks in that make
> this possible. This is much less certain, but would be a good thing to
> support, if we find it is practical. We don't even have a firm idea of
> exactly what those hooks might look like, much less have agreement
> from the MIT people to put them in, although we are much closer to
> knowing what hooks might be needed than we were a few months ago.
My position (which I know others disagree with) is that we should
release Samba4 with the builtin Heimdal, and that once we know both how
it really works in production (including issues we will show up in the
kerberos code, and our interfaces to it), we can start on a real list of
changes required to support other kerberos distributions.
Then starts a massive task of implementing a set of configure checks for
all our assumed behaviours, and the writing of a small glue layer (where
the two development communities have, and cannot change, incompatible
interfaces). However, if the glue layer and #ifdef hell becomes like
samba3's clikrb5.c (but an order of magnitude worse, because we use a
lot more functions), then it will be a failure.
> Having the builtin heimdal has allowed us to make _much_ faster
> progress with the kerberos part of ADS, and has taught us a lot about
> the problem space. That doesn't mean we will only ever support that
We would not have had any hope whatsoever of being at this point without
taking this approach, as we literally were spending our days with either
a 'works on RedHat' or 'can I do this, no, drat, workaround, more glue
please' results. Bringing the code into the tree made a massive
difference with how we were able to progress on this work. It made this
I do hope not to be maintaining a kerberos library and KDC for the rest
of my days, but the timeframe I've discussed with the MIT developers is
in the order of 2 years. I figure it will take at least that long to
both know what we need, and have that in major OS distributions.
> Cheers, Tridge
> PS: Andrew Bartlett owns this part of the code, so if he contradicts
> any of the above, please believe Andrew and not me :-)
Consider yourself milady contradicted ;-)
Andrew Bartlett http://samba.org/~abartlet/
Samba Developer, SuSE Labs, Novell Inc. http://suse.de
Authentication Developer, Samba Team http://samba.org
Student Network Administrator, Hawker College http://hawkerc.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20050831/ae78a892/attachment.bin
More information about the samba-technical