Command-line options for kdc

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Command-line options for kdc

Andrew Bartlett
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?

Andrew Bartlett
--
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Student Network Administrator, Hawker College  http://hawkerc.net

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Command-line options for kdc

Love Hörnquist Åstrand

Andrew Bartlett <[hidden email]> 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.

Love


attachment0 (487 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Command-line options for kdc

Johan Danielsson
In reply to this post by Andrew Bartlett
Andrew Bartlett <[hidden email]> writes:

> 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.

Moving the static state into a structure seems like the way to move.
Like Love said, you probably want a context with global state
(options, the krb5_context, and possibly some more). You then need
state for each call, that probably should contain most of what is now
passed along as parameters, this would include the raw request buffer,
addresses, options for each request (which we don't have now - I would
for instance like to see the possibility to add more logging for
certain principals or hosts). The logging system should probably be
improved also. I suppose you do your own logging as well?

/Johan