How to view KVNO on slave

[Mike]

On 07/10/2023 17:27, Russ Allbery wrote:
> Mike via Kerberos <kerberos at mit.edu> writes:
> 
>> I'm surmising that the issue might be that the service principle may not
>> have replicated corerctly to the slave server, which is used by the
>> Apache host.  I can see the ticket details on the master using
>> kadmin.local and getprinc and I can see the keytab info using ktutil.
>> My question is this: How does one view the KVNO in the Slave DB?  I
>> imaine it's probably available via kdb5_util dump but unfortunatly I
>> have not found any documents explaining the fields in the dump.
> 
> You can use kadmin.local on the slave the same way that you use it on the
> master, I'm fairly sure.  It's been a while since I've done this, but I'm
> pretty sure the database is the same and the tool doesn't have any idea
> whether you're running it on a master or a slave.
> 
> I would expect you to get replication errors if there was a replication
> problem.  If you're only doing incremental replication and you think
> something may have gone wrong, you can always do a full replication, which
> guarantees that the slave is identical to the master.
> 

Hi Russ,

Thanks for the info.  You were indeed correct, kadmin.local can be used 
on the slave DB.  It's not installed by default on Debian, at least, as 
it comes as part of the kadmin package.  I installed it and saw that the 
KVNO is up to date.

I eventually happened upon the answer in the kdc.log on the master.  It 
was a DNS mix up.  The web server has two DNS names 
server.zone.example.com and server.example.com.  The service principal 
was HTTP/server.zone.example.com and the log was complaining about not 
being able to find a service principal for HTTP/server.example.com.  So 
I created one, added it to the keytab and things started working again!

It was simple in the end, trouble is I'd been concentrating on the 
logging of the slave server and the web server neither of which recorded 
anything helpful.

The only weird thing is that it also (I later found out) affected 
another web server in the same way but has been working for years.  It 
wasn't until I rekeyed the service principal that the problem seemed to 
arise.  I guess that part will remain a mystery.  It is now fixed 
however and I thank you again for your assistance.

Kind regards,
Mike.