[rancid] (no subject)

[Gerhard Mourani]

Hello,

I'm using Rancid 3.0 to check FortiGate configuration changes and it is
working except that I receive every time when the script is running, the
following diff.

- set password ENC
ttKtc1dKyMz19Q6J7FQ6TLuM4ijBajn0gOgs8OvSaaExqFScZf1ngJTXpyHOrg8gdkcZLYKnTAWNGooEasQAYgnzwTq1siZvMrE37H1tQaBhDvenHB94CP7W+Esp/82LBKVA57xuaAVpehH0WCeFLIjdogE+N8yBfcmObOqBYewbTt9xRL/MG+XwQqtjHeyGC5tsrw==
+ set password ENC
Ig68IRG3Y25jMaueDr6VTnROaGLp2DbwMKjK7AzIkDserF+TDqcdSOKof+vGSfBL52TPZGNN/JXsC6SRIZcBrPm2yE3ciRgkX9FxoNmN2WieUBr8GEaEdwD4HpHFe31D13Sc+k9tHLczdXOCYnGVFXMZNH2zaa6ZIzSIQuYPPaWBltJolkCcdEHQoUjQ4tB8imTGmw==

Thanks,

[Alex DEKKER]

I wonder, given the sheer number of threads discussing the topic of
cycling/incrementing output in RANCID emails, might some mechanism for
either a) automatically detecting cycling/incrementing output or b)
making it easier to get RANCID to ignore it be a worthy target for
development?

alexd

[Howard Jones]

Post by Alex DEKKER
I wonder, given the sheer number of threads discussing the topic of
cycling/incrementing output in RANCID emails, might some mechanism for
either a) automatically detecting cycling/incrementing output or b)
making it easier to get RANCID to ignore it be a worthy target for
development?

With RANCID 3, adding an additional config type (e.g. 'ignore') to
rancid.types.conf to implement (b) should make the effort a bit more
central for the vendor types that use that file (anything with more than
a 'script' line, as far as I can see).

Even a document describing the data and control flow through the various
components of RANCID would make it easier for someone to help themselves
though. For example, it wasn't clear to me for a while that actually,
the *rancid script doesn't really interact with the device at all - just
squirts a canned list of commands, and then tries to make sense of all
the output afterwards.

Howie

[heasley]

Post by Howard Jones

Post by Alex DEKKER
I wonder, given the sheer number of threads discussing the topic of
cycling/incrementing output in RANCID emails, might some mechanism for
either a) automatically detecting cycling/incrementing output or b)
making it easier to get RANCID to ignore it be a worthy target for
development?

With RANCID 3, adding an additional config type (e.g. 'ignore') to
rancid.types.conf to implement (b) should make the effort a bit more
central for the vendor types that use that file (anything with more than
a 'script' line, as far as I can see).

can you provide an outline of what you mean?

Post by Howard Jones
Even a document describing the data and control flow through the various
components of RANCID would make it easier for someone to help themselves
though. For example, it wasn't clear to me for a while that actually,
the *rancid script doesn't really interact with the device at all - just
squirts a canned list of commands, and then tries to make sense of all
the output afterwards.

ack.

[Alan McKinnon]

Post by Howard Jones
Even a document describing the data and control flow through the various
components of RANCID would make it easier for someone to help themselves
though. For example, it wasn't clear to me for a while that actually,
the *rancid script doesn't really interact with the device at all - just
squirts a canned list of commands, and then tries to make sense of all
the output afterwards.

ack.

I have a reasonable skeleton "How Rancid works: A doc for sysadmins"
article hanging around. Maybe I should grab it from my wiki and post it
here for review.

[heasley]

Post by Alex DEKKER
I wonder, given the sheer number of threads discussing the topic of
cycling/incrementing output in RANCID emails, might some mechanism for
either a) automatically detecting cycling/incrementing output or b)
making it easier to get RANCID to ignore it be a worthy target for
development?

suggestions how to do that? it can't be too greedy; its possible for
things to cycle due to a bug, h/w failure, or intrusion, which should
not be ignored.

[Daniel Schmidt]

File of regex to cross reference? Granted, Regex is not much easier than
modifying Perl to copy whatever the last guy did. Maybe a "howto modify
Rancid" doc so lazy @$$ people like me fix their own problems instead of
asking if somebody else has already done it.

Post by heasley

Post by Alex DEKKER
I wonder, given the sheer number of threads discussing the topic of
cycling/incrementing output in RANCID emails, might some mechanism for
either a) automatically detecting cycling/incrementing output or b)
making it easier to get RANCID to ignore it be a worthy target for
development?

suggestions how to do that? it can't be too greedy; its possible for
things to cycle due to a bug, h/w failure, or intrusion, which should
not be ignored.
_______________________________________________
Rancid-discuss mailing list
http://www.shrubbery.net/mailman/listinfo/rancid-discuss

E-Mail to and from me, in connection with the transaction
of public business, is subject to the Wyoming Public Records
Act and may be disclosed to third parties.

[Alan McKinnon]

Or just move rancid to git?

Alex's original post was about finding a way for rancid to detect
"cycling/incrementing output" and just deal with it somehow. I think we
can all agree this is a bad idea, not least because it involves
intelligent magic code that doesn't exist. And also because removing
unwanted output requires knowing what the output *means* to decide if
it's worthless or not. Code can't do that and any attempt to do so will
be very error-prone.

Bit the original problem remains - all serious rancid users seem to
gather a large collection of tweaks and patches. Some are generally
useful and haven't made it into the release yet, other patches scratch
someone's itch but are unlikely to ship by default (eg prompt detection
and banners).

So if people patch rancid locally (and this does seem to be the best
method overall), why not make it as easy as possible for sysadmins to do
so? Git is ideal for this. Maintaining your own branch in cvs/svn and
synced with upstream is not especially pleasant, in git it is rather
trivial. Plus you get the ability to cherry pick other's patches if they
use git.

Post by Daniel Schmidt
File of regex to cross reference? Granted, Regex is not much easier
than modifying Perl to copy whatever the last guy did. Maybe a "howto
instead of asking if somebody else has already done it.

Post by Alex DEKKER
I wonder, given the sheer number of threads discussing the topic of
cycling/incrementing output in RANCID emails, might some mechanism for
either a) automatically detecting cycling/incrementing output or b)
making it easier to get RANCID to ignore it be a worthy target for
development?

suggestions how to do that? it can't be too greedy; its possible for
things to cycle due to a bug, h/w failure, or intrusion, which should
not be ignored.
_______________________________________________
Rancid-discuss mailing list
http://www.shrubbery.net/mailman/listinfo/rancid-discuss
E-Mail to and from me, in connection with the transaction
of public business, is subject to the Wyoming Public Records
Act and may be disclosed to third parties.
_______________________________________________
Rancid-discuss mailing list
http://www.shrubbery.net/mailman/listinfo/rancid-discuss

[heasley]

Post by Gerhard Mourani
Hello,
I'm using Rancid 3.0 to check FortiGate configuration changes and it is
working except that I receive every time when the script is running, the
following diff.
- set password ENC
ttKtc1dKyMz19Q6J7FQ6TLuM4ijBajn0gOgs8OvSaaExqFScZf1ngJTXpyHOrg8gdkcZLYKnTAWNGooEasQAYgnzwTq1siZvMrE37H1tQaBhDvenHB94CP7W+Esp/82LBKVA57xuaAVpehH0WCeFLIjdogE+N8yBfcmObOqBYewbTt9xRL/MG+XwQqtjHeyGC5tsrw==
+ set password ENC
Ig68IRG3Y25jMaueDr6VTnROaGLp2DbwMKjK7AzIkDserF+TDqcdSOKof+vGSfBL52TPZGNN/JXsC6SRIZcBrPm2yE3ciRgkX9FxoNmN2WieUBr8GEaEdwD4HpHFe31D13Sc+k9tHLczdXOCYnGVFXMZNH2zaa6ZIzSIQuYPPaWBltJolkCcdEHQoUjQ4tB8imTGmw==

this should fix that.

Index: bin/fnrancid.in
===================================================================
--- bin/fnrancid.in (revision 2837)
+++ bin/fnrancid.in (working copy)
@@ -225,7 +225,7 @@
}
}
# filter cycling password encryption
- if (/^\s*(set [^\s]*)\s(Enc\s[^\s]+)(.*)/i && $filter_pwds > 0 ) {
+ if (/^\s*(set [^\s]*)\s(enc\s[^\s]+)(.*)/i && $filter_pwds > 0 ) {
ProcessHistory("ENC","","","#$1 ENC <removed> $3\n");
next;
}