"If you choose to install a stash file..."

[Daniel Kahn Gillmor]

At 2007-01-10 14:16, kenh at cmf.nrl.navy.mil said:

> Actually, it shouldn't need a passphrase; the dump files contain the
> encrypted keys not the decrypted ones, and that's what kprop/kpropd
> pass around.

That's good news.  And as usual, i should always read the man page in
more detail first.  from kdb5_util(8):

       When kdb5_util  is run, it  attempts to acquire the  master key
       and open the database.  However, execution continues regardless
       of whether  or not  kdb5_util successfully opens  the database,
       because the database may not exist yet or the stash file may be
       corrupt.

so the stash file isn't necessary for the dump, but it means that any
automated propagation script can't check for corruption of the
database.  I think i can live with that: am i making a mistake?



For other folks who might be trying this, here's the specific error
output i get, which i thought meant that things weren't working (in
fact, the dump file is actually being created):

0 lemur:~/private# kdb5_util dump > testdump
kdb5_util: Cannot find/read stored master key while reading master key
kdb5_util: Warning: proceeding without master key
1 lemur:~/private# 

the 1 in the last line is the return code from kdb5_util.



Continuing on, when using a stash, kdb5_util will create a
$DUMPFILE.dump_ok file, containing a single null byte.  But when run
without a stash, the dump_ok file isn't created, probably because it
couldn't verify that the file isn't corrupt.

Then, kprop refuses to transmit $DUMPFILE without the presence of
$DUMPFILE.dump_ok.  If i fake it out with something like:

   echo -n -e '\000' > $DUMPFILE.dump_ok

Then kprop successfully pushes the db to the secondaries.  How bad is
this workaround?  What are the ways that "kdb5_util dump" could
generate a corrupted dumpfile (which i wouldn't notice)?  how likely
are they to occur?  I have no clear sense on this, so i'd appreciate
commentary from the wiser heads on this list.

>From the above, it's pretty clear to me now why Jeffrey Hutzelman says
MIT used a stash file on the master KDC.



To get stashless krb5 propagation fully functioning, i also had to
remove a check in the initscript (i'm using debian etch) for the
presence of a stashfile.  I also declined to start the KDC service
automatically (removing the link in /etc/rc2.d/), since human
intervention on the command line is needed to get the KDC going.

So: it turns out that there are a lot of minor changes if you try to
go stashless, and a potential for passing a corrupted database to the
secondary domain controllers when using kprop.  But it appears to work
for me.

I'm attaching a bash script designed to run from cron and to do krb5
propagation, even from a stashless master.  I welcome any feedback on
it, and I hope it's useful to others.  Watch out because there are
some weird linefeed characters in it where i check the error output.

it has been tested on a debian etch system, running krb5 1.4.4 (i
know: it's out of date already!)

Regards,

	--dkg