[15609] in Kerberos_V5_Development
Re: Project review: Parallel KDC
daemon@ATHENA.MIT.EDU (Nicolas Williams)
Wed Mar 17 14:31:46 2010
Date: Wed, 17 Mar 2010 13:29:43 -0500
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: Ken Raeburn <raeburn@mit.edu>
Message-ID: <20100317182943.GR14993@Sun.COM>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <51218867-25D2-4BA5-86BB-6AFDD934E8E9@mit.edu>
Cc: "krbdev@mit.edu" <krbdev@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
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
--
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
