KDC won't start after fresh install

[Roland C. Dowdeswell]

On Thu, Sep 05, 2013 at 09:09:24AM -0400, Benjamin Kaduk wrote:
>

> This failure mode does not ring any bells right away, but I would 
> double-check that you saw the "Caution" note about cases where "the 
> system's network hostname is assigned to the localhost address 127.0.0.1."
> I think I have seen krb5 clients get confused when there is both an IPv4 
> and an IPv6 local address line, or some iteration thereof.  Are you 
> intending to use IPv6 on the machine?

This reminds me a of bug that I saw in 1.3.something where in each
protocol a single failure would stop the setting up of further
sockets but the KDC would continue to run---just listening a little
less than one would hope.

Looks like the issue still exists in the setup code by quick read
of loop_setup_network() which calls setup_udp_pktinfo_ports(),
setup_tcp_listener_ports(), and setup_rpc_listener_ports() ignoring
the return code.  setup_tcp_listener_ports() simply returns an
error on the first error that it encounters.  This may lead to
results which are sometimes a little less intuitive than one might
hope.

For your example, we see in setup_udp_port_1() the error that you
encountered in a loop over the configured ports.  This error will
short-circuit this functions logic and hence it tries only 88 but
not 750.  setup_udp_port_1() is called at the tail of setup_udp_port()
and the error is returned.  setup_udp_port() is called via
foreach_localaddr().  foreach_localaddr() will stop processing if
its pass1 function pointer (passed in) returns non-zero but, in
this case, it will return success.  And so, the KDC will short-circuit
the setting up of UDP sockets upon the first error that it encounters
and then continue to run leaving any other UDP sockets that you
may have expected to be configured unconfigured.

In any case, the logic in loop_setup_network() and almost all of
the functions that it calls are completely wrong.  The KDC should
either (a) fail to run returning an error code if it can't configure
all of the ports that it wants to configure, or (b) configure
everything that it possibly can and write some complaints in the
log.  What it does now, i.e. non-deterministically (from the point
of view of someone not reading the code, at least) selecting a
subset of listening ports any time that there is an error, is less
than desireable.

--
    Roland Dowdeswell                      http://Imrryr.ORG/~elric/