KDC worker processes project

[Nicolas Williams]

On Thu, Sep 16, 2010 at 05:06:01PM -0400, Greg Hudson wrote:
> On Thu, 2010-09-16 at 15:56 -0400, Nicolas Williams wrote:
> > Why can't you test by starting the KDC and then confirming that all the
> > expected processes exist, with the right parent/child hierarchy?
> 
> I hadn't thought about that sort of test; I was thinking more along the
> lines of ensuring that both worker processes could accept UDP packets
> and TCP connections in parallel.

You could use debug messages to test the TCP case fairly easily: have N
processes/threads connect()-but-write-nothing to the KDC's TCP port,
then check that more than one KDC process wrote a debug message about
accepting connections.

But yes, I agree, this appears to be best unit tested.

> Examining the process table is kind of a portability minefield, isn't
> it?

You could just have the KDC processes write debug messages about it.

> > How will the number of processes be configured?  What's the default?
> > (Twice the number of CPUs seems like a reasonable default to me.)
> 
> With the -w command line option to krb5kdc.  Getting it from the profile
> wouldn't be too difficult if that's important.

Seems desirable.

> The default is not to use worker processes.  If you don't have KDC load
> issues and anything goes wrong, you're going to have an easier time
> diagnosing it if the KDC didn't aggressively parallelize in order to
> take advantage of system resources.

KDCs are typically run on systems dedicated for that purpose.
Aggressively using available CPU resources seems like a very desirable
default.  Though you might want to be more conservative than I was (say,
the number of CPUs minus 1).

Nico
--