Thanks for looking into this. Having tried the ifconfig method, k5start correctly detects the new link. However, unplugging the ethernet cable, running k5start, and then plugging it back in shows the error (i.e. continued errors even after I can run kinit/k5start in another terminal).
The original method I used to reproduce the issue was to comment out `/etc/systemd/network/50-wired.network` (my only network configuration file) and then restart systemd-networkd + systemd-resolved. To re-enable the network, I un-commented the lines and restarted the same services. That was the method suggested here https://lists.freedesktop.org/archives/systemd-devel/2015-September/034327.html I have a block of the style `MY.REALM = {kdc = xyz.fqdn}` in my krb5.conf, is that what you meant by locating KDCs? Not sure how helpful this link is, but perhaps it is an issue like this: https://sourceware.org/bugzilla/show_bug.cgi?id=3675 Best wishes, Kai On Thu, 1 Jun 2017 at 05:03 Benjamin Kaduk <ka...@mit.edu> wrote: > On Wed, May 24, 2017 at 11:44:12AM -0700, Russ Allbery wrote: > > > > Kai Wohlfahrt <kai.scor...@gmail.com> writes: > > > > > Package: kstart > > > Version: 4.2-1 > > > Severity: important > > > Tags: upstream > > > > > Dear Maintainer, > > > > > The k5start program repeats attempts to contact the KDC server if it is > > > unavailable. However, it continues to fail if a new network is > > > available. > > > > > Steps to reproduce: > > > - Disable network interface > > > - Run k5start (e.g. k5start -f /etc/krb5.keytab -K 10 -u host/jason -k > test.tkt) > > > - Enable network interface > > > > > I expect to see the error below repeated until the network comes back > > > up, and then it should stop: > > > > > k5start: error getting credentials: Cannot contact any KDC for realm ' > MY.REALM.NAME' > > > > > Instead, I continue to get errors until I stop the k5start > > > process. Starting it again after the network is available shows no > > > errors and gets the ticket correctly. > > > > k5start just calls krb5_get_init_creds_*, so if something is being > > inappropriately cached, this would be a bug in the underlying Kerberos > > library (rather than in kstart). Reassigning accordingly. > > I could not reproduce this behavior using any of 'ifconfig <iface> > down', adding loopback routes to all configured KDCs, or modifying > the profile (KRB5_CONFIG pointing to a custom path) to use > inaccessible KDC addresses as a way of making the KDC inaccessible. > The 'ifconfig <iface> down' method requires manual intervention to > restore a default route after bringing the interface back up, > though. > > (Code inspection also did not find a place where such caching would > occur, though of course there are probably some places I didn't > look.) > > Kai, can you confirm that you can reproduce and that have proper > network connectivity (DNS resolution, ping, etc.) during the case > where k5start continues to be unable to contact any KDCs? > > Also, is krb5.conf or DNS being used to locate KDCs (not that this > appears to matter). > > -Ben >
