[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: How to Reset ipropd
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
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" <email@example.com> 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
>> 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
>> though :). All this on redhat AS 3.1 and heimdal was configured with
> 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 firstname.lastname@example.org