[j-nsp] Config archive subtleties
p.mayers at imperial.ac.uk
Thu Aug 8 03:40:45 EDT 2013
On 08/07/2013 08:25 PM, Phil Shafer wrote:
>> 7 aug 2013 kl. 18:03 skrev Phil Mayers <p.mayers at imperial.ac.uk>:
>> Recently this fell apart on us, as the SSH key on the server changed and the archival
>> transfers started to silently fail.
> Ick. Silence is deadly. This (and the other issues) is now PR 910647.
>> All of which has me wondering if the feature is more trouble than it's worth.
> We definitely should be making it more robust and stable, but to
> me the value of catching each commit as a distinct delta is a win.
> It should also have the commit time, user, and commit comment, if
> given. Having this in a repo means one can ask questions like "who
> has changed config in my network since last Friday?" or "when did
> this statement get added in the first place?".
Agreed; preserving the separate commits and metadata is a big win, IMO,
and I really like the feature. It was surprising and disappointing to
find it had hung up!
(To the many people who suggested RANCID - thanks, but we already have a
config backup system. The question was specifically about strategies to
integrate the JunOS commit archive feature with such systems *given* the
failure modes I noted. This is a somewhat non-trivial problem to solve
in the general case; sure you can have a scheduled "fetch hourly"
belt&braces job, but that is both racy and discards data in some failure
> What else can we do to make this more worthwhile?
Trigger a chassis minor alarm if archive has failed for >X minutes?
(Configurable, of course). The PR may say that, but I can't see it yet ;o)
More information about the juniper-nsp