Re: How to Reset ipropd

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

Well, I guess the log file doesn't always get updated on the slave  
like you'd think, so things may be working better than I thought.

> -rw-------    1 root     other    18767872 2006-03-16 00:31 heimdal.db
> -rw-------    1 root     other          24 2006-03-16 00:30  
> heimdal.log

In the above case the slave log file hasn't been updated, and still  
shows version 2.  The master is at version 3, which includes an extra  
password change.  However kadmin -l get on the slave shows the  
password change *has* been propagated.

Reading the ipropd code, the iprop protocol seems simple enough.  I  
do *not* understand the log file processing though.  In particular I  
do not understand why slaves grow their log files beyond the 24 bytes  
needed to log a version number.

If you dump the DB, delete the log file, and reload the DB that seems  
to create a new 24-byte log file on the master.  However one time I  
did that .../heimdal/sbin/dump_log could not dump the new log file.   
In that case a slave would download a fresh copy of the DB, and  
create its own 24-byte log file, but it did not download any further  
updates.  dump_log likewise could not dump the log file on the  
slave.  Using od I saw nothing significantly different about the non- 
working log file.  (One word was different in a way consistent with a  
different time stamp, but I think the rest of the file appeared  
identical to a working one.  If there's interest I'll see if I can  
find a copy of it.)

On Mar 7, 2006, at 5:58 PM, Henry B. Hotz wrote:

>
> On Mar 7, 2006, at 2:24 PM, Björn Sandell wrote:
>
>> On Tue, 7 Mar 2006 09:07:31 -0800
>> "Henry B. Hotz" <hotz@jpl.nasa.gov> wrote:
>>
>>> I'm seeing a lot more flakiness in iprop for 0.7.2 than I saw in
>>> 0.6.3.  It's possible that I'm causing some of the problems myself,
>>> but I'd like to compare notes.
>>>
>>> Specifically I'm seeing situations where iprop is running, but the
>>> slave db is "frozen" and doesn't update.
>>
>> We're running 0.6.3 and I have never seen that particular failure  
>> mode.
>> It happens that a slave crashes or just hangs though. In our test
>> setup were presently running 0.7.1 master and 0.7.2 client and iprop
>> seem much more stable there (there's a lot less load on the test  
>> setup
>> though :). All this on redhat AS 3.1 and heimdal was configured with
>> '--disable-berkeley-db'.
>
> In production there's a firewall that gets in the way sometimes.   
> I've wound up with multi-gigabyte log files due to some third-order  
> fallout from that.  I don't blame iprod for all of those probelms.
>
> That doesn't apply in my test environment though.  I'm doing a  
> scripted upgrade from 0.6.3 which deletes the log files on both  
> master and slave(s).  Everything seems stable for a while.  Then  
> something happens (sometimes my fault) and it just can't/won't resync.
>
> Anyone have an opinion on deleting the "generation" field as part  
> of the dump/reload?
>
> ---------------------------------------------------------------------- 
> ------
> 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
>
>
>