Description of problem: ... restarting the KDC Unexpected error - see ipaserver-install.log for details: Command '/sbin/service krb5kdc restart' returned non-zero exit status 1 /var/log/krb5kdc.log: krb5kdc: Address already in use - Cannot bind server socket to port 750 address 192.168.122.251 lsof +M -n shows|grep rpcbind shows: rpcbind 1423 rpc 6u IPv4 3003 UDP *:sunrpc[portmapper] rpcbind 1423 rpc 7u IPv4 3007 UDP *:kerberos-iv rpcbind 1423 rpc 8u IPv4 3008 TCP *:sunrpc[portmapper] (LISTEN) If udp transport (tpi_clts) is defined in /etc/netconfig, rpcbind will bind on startup to a random UDP port in reserved range 600-1024, in addition to its standard port 111 (Ccing rpcbind owner to comment) As luck would have it, that port turns out to be 750 (krb4 port) frequently when running ipa-server-install at first boot in appliance http://ovirt.org/ Workaround is to disable UDP transports in /etc/netconfig in kickstart %post: sed -i -e 's/^\(udp\)/#\1/' /etc/netconfig Version-Release number of selected component (if applicable): ipa-server-1.0.0-6.fc9 How reproducible: sporadic, when rpcbind gets the right PID libtirpc-0.1.7/src/bindresvport.c:122 port = (getpid() % NPORTS) + STARTPORT; Steps to Reproduce: 1. while /bin/true; do service rpcbind restart >/dev/null; port=$(lsof +M -nPi UDP|grep ^rpcbind|grep -v portmapper|cut -d: -f2); echo -n "$port"; if [[ "$port" == "750 " ]]; then echo KABOOM; exit; fi; done 2. ipa-server-install 3. Actual results: ipa-server-install fails Expected results: Well, ideally rpcbind won't take random port in 600-1024... but ipa-server-install should check all ports it needs are free in a pre-installation check Additional info: backtrace where the 2nd UDP port is bound: #0 bindresvport_sa (sd=10, sa=0xbfc16fb8) at bindresvport.c:132 #1 0x0014eb24 in bindresvport (sd=10, sin=0x0) at bindresvport.c:59 #2 0x0015d60a in svc_tli_create (fd=10, nconf=0x0, bindaddr=0x0, sendsz=0, recvsz=0) at svc_generic.c:224 #3 0xb8014eb6 in create_rmtcall_fd (nconf=0xb832e940) at rpcb_svc_com.c:515 #4 0xb80117f7 in init_transport (nconf=0xb832e940) at rpcbind.c:645 #5 0xb8011c8d in main (argc=2, argv=0xbfc173a4) at rpcbind.c:182
SteveD: is 600-1024 range coming from: http://sunsolve.sun.com/search/document.do?assetkey=1-22-00142-1 What is that 2nd UDP port used for?
Raising severity b/c this can happen on any reboot, preventing krb5kdc service to start! Workaround could be to avoid using krb4 port by specifying: [kdcdefaults] kdc_ports = 88 in /var/kerberos/krb5kdc/kdc.conf Could an option to disable krb4 be added to ipa-server-install and /usr/share/ipa/kdc.conf.template modified accordingly?
Given the fact MIT is finally dropping krb4 in 1.7 anyway, I think we should really remove any krb4 compat feature from IPA. So +1 for me.
Per IPA weekly meeting, reassigning to Simo.
Would it be possible to post instructions on how to reproduce this problem as well as pointers to the software needed...
Steve, the only software needed is a krb5kdc instance, anyway this bug report made us aware that we were still listening for kerberos 4 requests, something we never really wanted to support anyway. So we are fixing this by simply stopping listening on that port at all.
simplest way to reproduce is to run Steps to Reproduce: 1. sooner or later rpcbind will pick port 750 (when it gets the right pid) then yum install krb5-server and service krb5kdc start
Bug verified. Bug closed Test: I have a small perl program to listen on 750. and then I run ipa-server-install. The installation runs through the end without any problem while the perl still listen on port 750. Therefore it proves the port 750 has been discard by the errata new bits. the perl script as below #/usr/bin/perl use IO::Socket; my $sock = new IO::Socket::INET ( LocalHost => 'localhost', LocalPort => '750', Proto => 'tcp', Listen => 1, Reuse => 1, ) or die "Could not create socket: $!\n" unless $sock; print "listen on 750"; my $new_sock = $sock->accept(); while(<$new_sock>) { print $_; } close($sock);
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2008-0643.html