Re: iprop problem

["Henry B. Hotz" <hotz@jpl.nasa.gov>]

On Nov 2, 2006, at 12:08 PM, Juha Jäykkä wrote:

>> As to where you keep the keytab, it's just a matter of how many
>> people do you want to access it?  Your ssh daemon has no business
>> seeing the key for the iprop service and vice versa.
>
> Right, but since ssh daemon runs as root, there's no place I can  
> hide the
> iprop keytab from him. I try not to run daemons as root, but you  
> managed
> to pick one of the three daemons I *do* run as root: heimdal, ssh and
> nfsd.

As you say root can get what it wants.  It's just "wrong" to mix  
unrelated things when you don't have to.  It makes sense to put the  
"host" keys in the default keytab because they identify the machine  
rather than a specific service.  A specific service should in general  
have its own keytab file.  That way it *can* be run as something  
other than root.

>> Did you delete the /var/heimdal/heimdal.log file as part of the
>
> Which log is this, the binary or the text log? Debian keeps the binary
> log (the one replayable by replay_log) in /var/lib/heimdal-kdc/log and
> Heimdal also logs through syslog to someplace in /var/log. I assume  
> you
> mean the former.
>
> If I assume correctly, then yes, I did. If I assume incorrectly,  
> then no,
> I didn't.

I meant the binary log file.

Just something to try:  be explicit about all the file locations in  
the kdc.conf file.  That helped when I had a similar problem.  I  
think there is a bug in iprop that causes this, but I was never able  
to fully trace it down.

>> reset?  A new slave should not have any log file to replay.  It
>> should simply download a complete fresh copy of the DB, and
>> initialize the log file to 24 bytes, containing a no-op with the
>> current DB version number.  In other words, even after a real init, a
>> replay should only consist of a single operation that could fail.
>
> About a second after starting iprop slave, the binary log file is
> 970370 bytes long (and still growing as I write this).
>
> And the non-binary log in /var/log again contains huge numbers of  
> "Entry
> already exists" and "Decrypt integrity failed" -messages.

------------------------------------------------------------------------ 
----
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu