[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Command-line options for kdc

Andrew Bartlett <abartlet@samba.org> writes:

> In working towards a libkdc with a real server context structure, I'm
> trying to design a solution that I hope would be acceptable upstream.
> Server configuration is one area that is a real pain to handle in
> merging, so I'm trying to get this 'right'.
> In terms of the current code, the command line options table assumes
> static variables, and while I can work around this to then fill in
> variables on my 'config' structure, I want to make sure I have to.  (And
> would hate to do work to find that a cleanup of this area was actually
> the preferred option :-)
> That is, I notice that many of the command line options (such as --
> enable-http and --kerberos4) are also available as krb5.conf/kdc.conf
> parameters.  Is this a historical oddity, a feature that some sites use,
> or is it in actual usage that the krb5.conf parameters are the ones
> unused, and the command line is critical?
> What I'm hoping is that I can reduce the number of command line
> parameters, and then just kludge around the remainder.
> Any comments?

Most opptions are there to support both testing (command line options) and
static server configuration (configuration file).

I've not given it much though, but the kdc should avoid using non-static
configration parameters (request code shouldn't change the value of them),
also each request should have their own krb5_context that is passed down to
support a threaded KDC. Many backends and encryption layers blocking, so
processing each request in a separate threads is almost a must.

Having to modify the configration file just to test a feature seems clumsy,
but you are right, all static configuration should be collected in one
place/structure, and it should be possible to init it from command line,
configuration file, and the HDB backend. The later since the propagation of
configuration options should be automatic.


PGP signature