Patch for Ticket 6344
bwleake at dev-stack.com
Mon Apr 29 02:13:51 EDT 2013
In January of 2009, an enhancement request was filed requesting the
capability to specify which address to listen on for the kdc and kadmin
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
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
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.
More information about the krbdev