principal~.kadm5 & C.

Giuseppe Mazza g.mazza at imperial.ac.uk
Wed Jul 16 11:47:10 EDT 2014


Hi Greg,

Thank you for your very helpful email.

On 16/07/14 15:54, Greg Hudson wrote:
> On 07/16/2014 10:08 AM, Giuseppe Mazza wrote:
> [trying to kprop from krb5 1.4 to krb5 1.12 and it hangs]
>> - I have read your archive. Apparently some people had a similar problem.
>>   It seems to me that they were using two versions of Kerberos that were
>>   too different... Well, it sounds familiar :-)
> 
> I'm not aware of any kprop incompatibilities between 1.4 and 1.12.
> Where in the mail archive did you run across other people having a
> similar problem?

I have download the file below:
http://mailman.mit.edu/pipermail/kerberos.mbox/kerberos.mbox
onto my desktop bee.
I have done the thing below:
------------------------------------------------------------
bee% grep -A 10 principal~ kerberos.mbox | less
...
-rw------- 1 root root 8.0K May  9 19:40 principal~
-rw------- 1 root root 8.0K May  9 19:40 principal~.kadm5
-rw------- 1 root root    0 May  9 19:40 principal~.kadm5.lock
-rw------- 1 root root    0 May  9 19:40 principal~.ok

Kpropd.acl should be configured correctly, as it has the host principals for
both the master and slave on both the master and the slave. The principals
are configured correctly, and their keytabs should be extracted correctly -
After all, it is getting fairly far in the process.

As best as I can figure, this is an issue/incompatibility between the
different Kerberos versions, but if anyone wants to confirm or deny that, I
would very much appreciate it (as I will otherwise try to install a matching
version on the master KDC, after backing up my database, of course). Thanks,
...
------------------------------------------------------------

> 
>> - Any idea how to solve the above problem?
> 
> I don't really know what has gone wrong at this point.  The ubuntu 14.04
> slave received a connection and received 2.2M of dump data.  So, some
> investigative steps:
> 
> * On the master, run "kdb5_util dump somefilename".  Is the result a
> 2.2M file or a larger file?  If it's a larger file, the transfer is
> getting stuck.  If it's a 2.2M file, the database is being transferred
> and the slave is getting stuck processing it.

As you say on the master:
[root at london temp]# du -hs slave_datatrans
2.2M	slave_datatrans

And on the slave:
root at tt-u1404:/var/lib/krb5kdc# du -hs from_master
2.2M	from_master
root at tt-u1404:/var/lib/krb5kdc#
...
-rw-------  1 root root 508K Jul 16 14:36 principal~
...
It is as if it gets started with the db creation, but then it cannot
load the data itself (my wild guess).

> 
> * On the slave, look for kdb5_util processes.  If there is a "kdb5_util
> load" process running, then the slave is stuck loading the dump file.
> If not, then kpropd is stuck in some other fashion.
> 
I have just deleted the previous files *~*  and the file from_master.
Then I have kprop-ed on the master again and I have got on the slave the
output below:


root at tt-u1404:/var/lib/krb5kdc# ps aux | grep kdb5_util
...
root      8939 31.9  0.1   4220  1328 ?        R    16:21   0:07
/usr/sbin/kdb5_util load /var/lib/krb5kdc/from_master
root      8941  0.0  0.0   4680   820 pts/4    S+   16:22   0:00 grep
--color=auto kdb5_util

( There were several instances from my previous attempts in the past days )



> * If there is a kdb5_util load process, strace it ("strace -p pid") to
> find out what system call it is blocking on, or what sequence of system
> calls it is repeating. 

root at tt-u1404:/var/lib/krb5kdc# strace -p 8939
Process 8939 attached

...nothing more


> You could also try installing the libkrb5-dbg
> package and gdb attaching to the process to get a stack trace.
> 
I am going to do the things above, but I need more time.


> 
>> If you think that the two kerberos versions are too different, can you
>> think a different strategy to solve the problem?
> 
> kprop and kpropd are basically a glorified way to "kdb5_util dump" on
> the master and "kdb5_util load" on the slave.  You could try making a
> dump file on the master, transferring it to the slave via scp or
> similar, and loading it on the slave.  You might have the same issues,
> but that would at least help narrow down what's going wrong.  You could
> also run kdb5_util load with -verbose, or even run it under a debugger,
> both of which are much more difficult when kpropd is doing it.
> 

ok I will try those things too.

However what I had already done is to try the commands below:
(each time I have copied the dump files over from the master london to
the slave tt-u1404):

1] it fails (please note the switches -ov -update):
root at tt-u1404:~/foo# kdb5_util load -ov -update  kdb-dump.ov
kdb5_util: KADM5 administration database lock file missing while opening
database

2] it hangs (please note the switches -b6 -update):
root at tt-u1404:~/foo# kdb5_util load -b6 -update  kdb-dump.b6

3] it hangs (please note the switch -recurse):
root at tt-u1404:~/foo# kdb5_util load ~/foo/kdb-dump

where ~/foo/kdb-dump was created with the command below:
[root at london foo]# kdb5_util dump -recurse kdb-dump
[root at london foo]# ls
kdb-dump  kdb-dump.dump_ok


Thank you for your help again,
Giuseppe





More information about the Kerberos mailing list