System-Fehlerdiagnose: KDC Erreichbarkeit

(I posted this here before, but was asked to move it to an own topic, because of the different underlying conditions.)

We have a similar problem. Sorry if this is the wrong place for our problem, but maybe the problems are related. Our domain consists of four UCS systems:

  • ucs-master
  • ucs-slave
  • ucs-backup
  • ucs-ext

All of them are showing

Die folgenden KDCs waren nicht erreichbar: tcp ucs-*

So ucs-master show, ucs-slave and so on.

host -t srv _kerberos._tcp.$(ucr get domainname) shows all of them on all systems.

kinit --password-file=/etc/machine.secret $(hostname)\$@$(ucr get kerberos/realm) seems to work on all systems, at least klist shows issued tickets afterwards.

echo -ne "server $(ucr get ldap/master)\nprereq yxdomain $(hostname -f)\nsend\n" | nsupdate -d -g -t15 also looks like it works correctly.

When I run tcpdump -i eth0 tcp port 88 and run system diagnostics again, it shows connections to all systems except the one where I’m running it, for which it reports KDC unreachable. When I run tcpdump -i lo tcp port 88 it shows connections to localhost. Any idea?

Edit: I just solved my problem by adding ucs-slave to the /etc/hosts using:
ucr set hosts/static/"localhost ucs-slave"

My /etc/hosts before the change:       localhost ucs-slave ucs-slave

::1             localhost ip6-localhost ip6-loopback
fe00::0         ip6-localnet
ff00::0         ip6-mcastprefix
ff02::1         ip6-allnodes
ff02::2         ip6-allrouters

I don’t fully understand why it works now, though.


even though you’ve found a workaround, can you please show the output of lsof -PniTCP:88 from both ucs-slave and ucs-master?

Kind regards,


samba   23392 root   24u  IPv6 2290188      0t0  TCP [::1]:88 (LISTEN)
samba   23392 root   34u  IPv4 2290192      0t0  TCP (LISTEN)
samba   23392 root   38u  IPv4 2290196      0t0  TCP (LISTEN)


samba   1263 root   24u  IPv6  18348      0t0  TCP [::1]:88 (LISTEN)
samba   1263 root   34u  IPv4  18352      0t0  TCP (LISTEN)
samba   1263 root   38u  IPv4  18356      0t0  TCP (LISTEN)


This seems wrong to me. I know other systems such as Ubuntu or Debian tend to set up with the desired host name, but on UCS systems this is usually not the case. I’ve just verified with three different systems (one a newly set-up 4.2, the others long-lived systems originally set up in the 3.0 days and upgrade since), and neither of them contains such an entry.

What UCR variables have you set for static entries (see ucr search --brief hosts/static on both systems)?

Kind regards,

ucs-master:~# ucr search --brief hosts/static
hosts/static/.*: <empty>
hosts/static/ localhost ucs-master
hosts/static/ ucs-master
ucs-slave:~# ucr search --brief hosts/static
hosts/static/.*: <empty>
hosts/static/ localhost ucs-slave
hosts/static/ ucs-slave

I don’t remember setting, but I have two other UCS systems not affected by the problem, that have hosts/static/ set.


I still suggest you remove both entries (hosts/static/ and hosts/static/, reboot the server and run the system diagnostics again. One of the reasons is that having DNS consistent across the whole UCS domain is an important basis for it working well. That includes that host names resolve identically no matter on which host you query it on (e.g. should always resolve to, no matter if you’re currently on ucs-master or on ucs-slave itself) and which method is used (contacting a DNS server directly or using glibc's stub resolver via functions such as gethostbyname).

Kind regards,

Thanks, I removed both entries on all systems and rebooted them. System diagnostics still does not report any problem.

On the other domain there is an ucs-master and an ucs-backup.

root@ucs-master:~# cat /etc/hosts
...       localhost ucs-master       localhost localhost_sync ucs-master

localhost_sync seems to have something to do with Open XChange according to Google. Should I also remove both entries here?


why is there still an entry for on your ucs-master if the entries have UCR variables have really been unset? That doesn’t really make sense… Please post the output of grep -Fr /etc; it should give us some clues.

I need to mention that my OX test installation does contain static host entries for, too. I haven’t found out where and when they’re set, though; neither the package installation files in /var/lib/dpkg/info nor the domain join scripts in /usr/lib/univention-install do anything with… Very strange.

What’s even stranger is that I can reproduce the “KDC not reachable” issue on that machine as well. Removing the entry doesn’t solve the issue for me. I’ll have to look into this some more.

Kind regards,

Hi mosu,

why is there still an entry for on your ucs-master if the entries have UCR variables have really been unset? That doesn’t really make sense…

My previous post was about a totally different domain. Sorry for not making it clear enough.

I do not have the “KDC not reachable” issue on this other domain.

Edit: Suddenly I have the same problem in the other domain…

Maybe this is the same false positive/bug in the check that Stefan Gomann mentioned in this post:

KDC check fails due to “Record Mark” option in network package