Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!julius.cs.uiuc.edu!apple!agate!shelby!ACK.STANFORD.EDU!pst
From: pst@ACK.STANFORD.EDU (Paul Traina)
Newsgroups: comp.protocols.kerberos
Subject: kadmind run out of rc.local and kprop/kpropd comments
Message-ID: <9009130750.AA02318@ack.Stanford.EDU>
Date: 13 Sep 90 07:50:19 GMT
Sender: daemon@shelby.Stanford.EDU
Organization: The Internet
Lines: 23

Here are two (un)interesting tidbits I found today.

I haven't tracked this one down yet,  but if one attempts to run kadmind
out of /etc/rc.local,  it receives a SIGHUP from some other process.  My
first thought was that this is happening when /etc/rc completes, but this
makes no sense what so ever.  If I'm missing something plainly obvious,
I appologise,  but I'm temporarily stumped.  My un-solution was to simply
have kadmind ignore the hangup signal.  Now everything is peachy.

Tidbit #2 is dealing with kprop/kpropd.  I set up a master server on an RT,
just as usual.  I wanted to install a slave server on a Sun3.  I put the
whole mess together and when I fire off a kprop,  we end up with errors to
the effect that the mutal authentication between kprop/kpropd fails.  Since
kerberos defaults to rcmd.<host> for authentication, yet rlogin/rsh work
properly,  this isn't the problem.  The interesting thing is that if I make
the slave server another RT (or the same rt) things work just fine.  It's not
a byte-ordering problem because I get the same results whether a VAX or a Sun3
are tried as slave servers.  My guess is that we have a word length problem
in the initial ident string sent over before the mutual athentication attempt.
It's easy enough to check,  but I am feeling especially lazy at the moment and
was hoping someone else has already killed this misfeature off.

Paul