Project review: Parallel KDC

[Nicolas Williams]

On Sun, Mar 14, 2010 at 12:31:39AM -0500, Ken Raeburn wrote:
> On Mar 13, 2010, at 22:23, Greg Hudson wrote:

> For now, with the current state of the code, I'd suggest the first --
> have the parent send SIGTERM to all the children, then wait for them
> to go away, reconfigure the network, and fork off a new set of child
> processes.

That would be my recommendation as well.  The children should handle
SIGTERM by setting a flag that gets checked at the top of their I/O
loops.

One problem would be: what if a child is stuck waiting for, say, an LDAP
reply?  Answer: all KDB backends that contact remote services should
implement timeouts.

Alternatively...

> > Also, I wasn't around when that support was added, but it feels like a
> > remarkable amount of effort for a regular network daemon to go to,
> > suggesting that our design made a wrong turn somewhere along the line.
> > (I'm not proposing to rip it out at this time, though.)
> 
> Perhaps.  We did get requests for it to continue to DTRT if network
> interfaces were brought up or shut down; we need to reply to UDP
> packets from the local address that the client sent to; and on some
> systems we don't get IP(V6)_PKTINFO to help us with that with a single
> listening socket.  With many "regular" network daemons, only TCP is
> used, or the client may not care about the source address of the
> returned packet.  Or manual restarting may be required.  For a case
> like ours, I'd look to something like named or ntpd; on NetBSD, at
> least, ntpd appears to open a routing socket.

It's probably time to reduce complexity and use IP(V6)_PKTINFO
exclusively.  Systems that do not support IP(V6)_PKTINFO can either not
be supported by MIT krb5, or can be supported subject to the caveat that
krb5kdc must be restarted when the network interfaces configuration
changes.

Nico
--