Project review: Parallel KDC

Nicolas Williams Nicolas.Williams at
Wed Mar 17 14:29:43 EDT 2010

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

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.


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


More information about the krbdev mailing list