Problem with database replication

[Jeremy Hunt]

Hi Jurgen,

My apologies, I wrote a detailed email to you yesterday suggesting I 
think it is your principal file that is corrupt. But I did not hit send.

Check the permissions on principal* (assuming your principal file is 
called principal).

Assuming that is okay check the integrity of the principal file by using 
kadmin.local -q listprincs. or kdb5_util dump to check its readability.

Now stop your kdc on the slave. save the principal files somewhere, and 
try and kdb5_util create and then load the master database with 
kdb5_util. Assuming that all works restart the kdc process and reinstate 
your cron job for propagation.

Assuming that all works, you might want to investigate why the principal 
database was corrupted.

Trawling through you krb5kdc.log and system logs might help.

Good Luck,

Jeremy

Benjamin Kaduk wrote:
> On Thu, 26 Sep 2013, Jürgen Obermeyer wrote:
>
>> Hi Jeremy!
>>
>> Thank you for your long answer! You're right; the information given are
>> insufficient - it was very late yesterday ... so I'll try to do 
>> better now:
>>
>> Master: Debian stable (Wheezy) with krb5-kdc version 
>> 1.10.1+dfsg-5+deb7u1.
>>
>> Slave: Debian testing (Jessie) with krb-kdc version 1.11.3+dfsg-3.
>
> I don't beleve there should be a difference in the dump format between 
> those two versions.
>
>>> You can dump individual principals to a dump file and try to load them
>>> on the slave to see if they are the cause of the problem.
>>
>> I did this with several single entries, but also without success. The 
>> kdb5_util process never returns ... I have to kill it with CTRL-C.
>
> I am confused.  Can anything at all be loaded from a dump file? 
> Earlier it sounded like trying to load the full database did load a 
> few principals before hanging, but now it sounds like attempting to 
> load any single principal is hanging.
> If any attempt at all to load anything on the slave is failing, that 
> is probably some form of corruption on the slave.  It might be useful 
> to be able to analyze that corrupt state, so I would recommend 
> bringing up a new machine from scratch to serve as the slave in that 
> location, while leaving the old machine around for analysis.
>
> -Ben Kaduk
>
>
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos