KDC worker processes project

[Greg Hudson]

On Thu, 2010-09-16 at 15:56 -0400, Nicolas Williams wrote:
> I'm not clear on something.  If you have pktinfo, then the kdc does cope
> with changes in network interfaces, but implicitly.  Whereas if you
> don't have pktinfo then changes in network interfaces have to be
> detected and the KDC has to open/close some sockets.  Correct?  If so,
> +1.

That's correct.  If you have pktinfo support, you don't need the
automatic network reconfig support, so you won't suffer any loss in
functionality from using worker processes.

This applies independently for IPv4 and IPv6.  Platforms which have v6
but not v4 pktinfo will not have any problems with newly created v6
interface addresses, but will (if worker processes are in use) need a
KDC restart to accept UDP packets on newly created v4 interface
addresses.

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

Examining the process table is kind of a portability minefield, isn't
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.

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.