On 18-12-18 19:18, Robbie Harwood wrote:
Kees Bakker <keesb(a)ghs.com> writes:
> On 17-12-18 20:44, Robbie Harwood wrote:
>> Kees Bakker via FreeIPA-users <freeipa-users(a)lists.fedorahosted.org>
>> writes:
>>
>>> Sure I understand that, but this error in /var/log/krb5kdc.log is basically
>>> all I have.
>>> krb5kdc: Server error - while fetching master key K/M for realm GHS.NL
>> What are the permissions on your stash file? Does a checksum match
>> the old replica?
> Where do I find the stash file?
>
> I've copied everything with rsync from the old machine. That should
> have made an exact copy. Well, except for the selinux attributes,
> which hopefully recovered with the .autorelabel. But I'm not 100%
> sure about that.
>
> From other discussions in the past about this krb5kdc error I get the
> impression that the stash file may be stored in LDAP (i.e. dirsrv). If
> that is true, then I need to concentrate on why dirsrv isn't started
> properly.
Oh right, I'm on the freeipa list. Sorry about that.
If dirsrv isn't starting, you need to look at that first. LDAP needs to
be working in order for freeipa to bring up the KDC.
If dirsrv isn't starting, it's likely that krb5 is having some problem
connecting. I'd look at dirsrv's logs to see if anything seems amiss.
dirsrv is starting, but eventually it dies.
KDC starts, I think, but there something funny here. The log
on the new hardware.
Dec 17 13:45:11 alblas systemd: Starting Kerberos 5 KDC...
Dec 17 13:45:11 alblas systemd: Started Kerberos 5 KDC.
But when I diff with the old machine there is always a
message PID not found. This is from the old machine.
Dec 17 13:05:01 alblas systemd: Starting Kerberos 5 KDC...
Dec 17 13:05:02 alblas systemd: PID file /var/run/krb5kdc.pid not readable (yet?) after
start.
Dec 17 13:05:02 alblas systemd: Started Kerberos 5 KDC.
I don't understand how /var/run/krb5kdc.pid can be there at startup. Now
maybe systemd thinks that KDC has started (wild guess). After that
named starts but quickly fails due to dirsrv problems.
Dec 17 13:43:01 alblas named-pkcs11[9684]: loading DynDB instance 'ipa' driver
'/usr/lib64/bind/ldap.so'
Dec 17 13:43:01 alblas named-pkcs11[9684]: bind-dyndb-ldap version 11.1 compiled at
13:38:22 Aug 23 2017, compiler 4.8.5 20150623 (Red Hat 4.8.5-16)
Dec 17 13:43:01 alblas named-pkcs11[9684]: LDAP error: Invalid credentials: bind to LDAP
server failed
Dec 17 13:43:01 alblas named-pkcs11[9684]: couldn't establish connection in LDAP
connection pool: permission denied
Anyway, I want to give it a new attempt. The reason is that I discovered
a clock issue. The new hardware had the clock 1 hour in the future.
Perhaps KDC and/or dirsrv refuses to start when its files have a
timestamp in the future.
If this all fails I intend to follow Flo's advice to setup a replica and move
CA renewal and CRL master to the new replica.
--
Kees