This bug was fixed in the package krb5 - 1.15-1ubuntu0.1
---------------
krb5 (1.15-1ubuntu0.1) zesty; urgency=medium
* Pulled in Debian fixes from Sam Hartman for:
- kinit fails for OTP user when using kdc discovery via DNS
(LP: #1683237)
- KDC/kadmind explicit wildcard listener addresses do not use pktinfo
(LP: #1688121)
- KDC/kadmind may fail to start on IPv4-only systems (LP: #1688310)
-- Andreas Hasenack <andr...@canonical.com> Fri, 05 May 2017 14:05:38
+0000
** Changed in: krb5 (Ubuntu Zesty)
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to krb5 in Ubuntu.
https://bugs.launchpad.net/bugs/1688310
Title:
KDC/kadmind may fail to start on IPv4-only systems
Status in krb5 package in Ubuntu:
Fix Released
Status in krb5 source package in Zesty:
Fix Released
Status in krb5 package in Debian:
Fix Released
Bug description:
This is fixed in artful in krb5 1.15-2
- upstream: http://krbdev.mit.edu/rt/Ticket/Display.html?id=8531
- debian: conflated into
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=860767
- debian patch: 0011-Fix-KDC-kadmind-startup-on-some-IPv4-only-systems.patch
[Impact]
getaddrinfo() called on a wildcard address might return the IPv6 "::1"
address. On machines without IPv6 support, binding to it will most likely fail
and the kdc/kadmin services won't start.
The provided patch is applied upstream and in Debian testing.
[Test Case]
Steps to reproduce the problem on zesty:
a) install krb5-kdc krb5-admin-server
$ sudo apt install krb5-kdc krb5-admin-server
when prompted, use EXAMPLE.ORG (all caps) as the default realm
when prompted, use the IP of this machine for the KDC and the Admin servers
b) configure a new realm called EXAMPLE.ORG
$ sudo krb5_newrealm
use any password of your liking when prompted
c) confirm the kdc and admin services are running.
$ ps faxw|grep -E "(krb5kdc|kadmind)"|grep -v grep
4275 ? Ss 0:00 /usr/sbin/krb5kdc -P /var/run/krb5-kdc.pid
4306 ? Ss 0:00 /usr/sbin/kadmind -nofork
d) create a principal and obtain a ticket to confirm kerberos is working
properly:
$ sudo kadmin.local addprinc -pw ubuntu +requires_preauth ubuntu
$ kinit
Password for ubu...@example.org:
$ klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: ubu...@example.org
Valid starting Expires Service principal
05/04/2017 14:20:17 05/05/2017 00:20:17 krbtgt/example....@example.org
renew until 05/05/2017 14:20:13
e) Confirm the kerberos services are bound to IPv6 local sockets:
$ sudo netstat -anp|grep -E "^(tcp|udp)6.*(krb5kdc|kadmind)"
tcp6 0 0 :::88 :::* LISTEN
1078/krb5kdc
tcp6 0 0 :::749 :::* LISTEN
1065/kadmind
tcp6 0 0 :::464 :::* LISTEN
1065/kadmind
udp6 0 0 :::88 :::*
1078/krb5kdc
udp6 0 0 :::464 :::*
1065/kadmind
udp6 0 0 :::750 :::*
1078/krb5kdc
f) configure the system to not support IPv6. There are probably many ways to
do this, but the one sure way is to reboot it with ipv6.disable=1 in the kernel
command line:
e.1) edit /etc/default/grub
e.2) add "ipv6.disable=1" to GRUB_CMDLINE_LINUX and save
e.3) run sudo update-grub
e.4) reboot
f) Confirm the kdc and admin services are NOT running:
$ ps faxw|grep -E "(krb5kdc|kadmind)"|grep -v grep
$
g) /var/log/auth.log will contain the reason:
$ sudo grep -E "(kadmind|krb5kdc).*Failed" /var/log/auth.log
May 4 14:11:54 22-96 krb5kdc[1087]: Failed setting up a UDP socket (for
::.750)
May 4 14:11:54 22-96 kadmind[1085]: Failed setting up a UDP socket (for
::.464)
May 4 14:15:36 22-96 krb5kdc[1510]: Failed setting up a UDP socket (for
::.750)
May 4 14:16:36 22-96 krb5kdc[1652]: Failed setting up a UDP socket (for
::.750)
May 4 14:25:54 22-96 kadmind[1085]: Failed setting up a UDP socket (for
::.464)
May 4 14:25:54 22-96 krb5kdc[1079]: Failed setting up a UDP socket (for
::.750)
With the updated packages, krb5-kdc and krb5-admin-server will startup
just fine in the same conditions.
[Regression Potential]
We now tolerate a EAFNOSUPPORT error as long as at least one socket was bound
to correctly. Maybe there could be a scenario when this one bound socket is
useless, or unexpected: in that case, bailing out because of the EAFNOSUPPORT
error could be seen as a more robust approach because it's immediately visible,
instead of silently listening on the useless socket.
That being said, I believe single stack systems (only IPv4, or only
IPv6) take an extra configuration effort and most systems are dual
stack. Zesty certainly is, out of the box.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/krb5/+bug/1688310/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
