Patch for Ticket 6344

[bwleake]

In January of 2009, an enhancement request was filed requesting the 
capability to specify which address to listen on for the kdc and kadmin 
daemons.
http://krbdev.mit.edu/rt/Ticket/Display.html?id=6344

I've recently run into a similar issue where running multiple realms on 
a single server would have been useful.  I've attempted to patch 
lib/apputils/net-server.c, and add related code to the kdc and kadmin 
daemons to allow binding on a single address with "-l" so that multiple 
daemons can be run on different addresses on the same server.  A first 
draft of the patch is up at github.com/pwillred/krb5, under the "listen" 
branch.  The code appears to work as intended, when the "-l" option is 
omitted from kadmin and krb5kdc, both daemons function as before the 
patch.

I am somewhat concerned that running two kdc or kadmin daemons 
concurrently could result in incorrect or undesired behavior. The kdc 
database itself appears to have a fairly robust locking system already 
in place.  Also, the server logs appear to be set up so that the pid of 
the kdc or kadmin server is recorded, and log messages are properly 
interleaved.  The replay cache also appears to be robust when used by 
two daemons, but I am much less confident in this assessment.  What 
other concurrency issues with running two servers side by side would 
need to be addressed for a successful patch?

My ability to test this patch is limited to Linux systems.  
getaddrinfo() is the only new call in the code, I believe it is being 
used in a POSIX compliant manner, and should be portable to other recent 
operating systems enumerated under 
http://k5wiki.kerberos.org/wiki/Supported_platforms.

Additionally, I'm unsure if this change would need to go through the 
project planning process for 1.12 or 1.13.  I'd imagine that since this 
is a change to the options passed into kadmin and krb5kdc, it would need 
to gain approval first.  I'm happy to help write up any documentation or 
other prose that is needed for a proper proposal, if a developer already 
familiar with the process is willing to provide some guidance.

Thanks,
Brian Leake