See below the KRB5_TRACE file (domains/realms cleaned up). It could well be
DNS, but other programs (e.g. dig) respond correctly and recognize when the
network comes back up.
Kai
> [18010] 1497006307.510633: Getting initial credentials for
host/jason@MY.REALM
> [18010] 1497006307.510733: Setting
I wonder if your nss stack is somehow caching something about the
network and the name servers and that kstart process is no longer able
to resolve KDCs.
It would be interesting to set KRB5_TRACE to a file, run kstart such
that it is failing and see what specifically is not working.
My bet is on DN
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 origina
On Wed, May 24, 2017 at 11:44:12AM -0700, Russ Allbery wrote:
>
> Kai Wohlfahrt 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. Howe
Control: reassign -1 libkrb5-3
Control: affects -1 kstart
Kai Wohlfahrt 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
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.
6 matches
Mail list logo
