I think I was not clear in my original post. Let me clarify.

I have a master KDC running Heimdal 7.1. In its database is a principal called "fprefect" which, as far as I can tell, acts like a normal principal. I can do "get fprefect" and the output looks normal. If I point to this master and do a "kinit fprefect" I get a TGT.

However, if I bring up a new slave KDC (no database, no transaction log) that points to this master, the KDC _appears_ to get the entire database from the master, except that the principal "fprefect" is missing. This happens if the slave KDC runs 7.1 or if it runs 1.5.2. (There are some strange messages in the iprop log on the 1.5.2 slave; see my original e-mail for details.)

I don't know how this principal got into this strange state on the master, and I don't know how to replicate this issue.

It makes me think that the database on the master is corrupted in some subtle way.

I am hoping that someone can tell me some way to query or examine the database on the master to get some information that might throw some light on why this particular principal behaves this way.

Adam Lewenberg


On 6/15/2018 3:29 PM, Adam Lewenberg wrote:


On 6/15/2018 3:04 PM, Viktor Dukhovni wrote:


On Jun 15, 2018, at 5:31 PM, Adam Lewenberg <ada...@stanford.edu> wrote:

PROBLEM: Some of the principals will not replicate.

Well updates to the principal are not replicating...

If I go on the master and change the password of one of these problematic principals, I
see this in the replica's logs:

That's a "modify" not a "create" and modify requires the object
to already be there.  The iprop log is "sparse", recording only
the modified data when doing "modify", so the principal can't
be created just from the latest "modify" record.

QUESTION: What could be a reason for this principal not to replicate?

You need to stop the slaves, blow away their database and logs,
and replicate the full database from scratch.

I did this. On three different slaves. The problematic principals do not appear in the slave's database. To be clear: even after initial replication (starting from nothing on the slave) some of the principal's do not appear in the slave's database.

This (or something much like it) appears in the initial replication on three separate 1.5.2 slaves:

2018-06-15T17:45:12 ipropd-slave started at version: 0
2018-06-15T17:45:12 receive complete database
2018-06-15T17:45:47 receive complete database, version 114134
2018-06-15T17:46:44 replaying entry 114135
2018-06-15T17:46:44 replaying entry 114136
2018-06-15T17:46:44 replaying entry 114137
2018-06-15T17:46:44 replaying entry 114138

... many lines like this until ...

2018-06-15T17:46:45 replaying entry 131686
2018-06-15T17:46:45 replaying entry 131687
2018-06-15T17:46:45 replaying entry 131688
2018-06-15T17:46:45 replaying entry 131689
2018-06-15T17:46:45 Ignoring command 8
2018-06-15T17:50:03 replaying entry 131690
2018-06-15T17:50:03 Ignoring command 8
2018-06-15T17:50:03 replaying entry 131691
2018-06-15T17:50:03 Ignoring command 8
2018-06-15T17:50:03 replaying entry 131692
2018-06-15T17:50:03 Ignoring command 8
2018-06-15T17:51:03 replaying entry 131693
2018-06-15T17:51:03 Ignoring command 8
2018-06-15T17:56:52 replaying entry 131694
2018-06-15T17:56:52 Ignoring command 8
2018-06-15T18:00:03 replaying entry 131695
2018-06-15T18:00:03 Ignoring command 8

... more lines much like until ...

2018-06-15T20:16:57 Ignoring command 8
2018-06-15T20:18:53 replaying entry 131814
2018-06-15T20:18:53 kadm5_log_replay: 131814. Lost entry entry, Database out of sync ?: No such entry in the database (36150275)
2018-06-15T20:18:53 Ignoring command 8
2018-06-15T20:19:23 Ignoring command 8
2018-06-15T20:20:02 replaying entry 131815




Reply via email to