Mailing List Archive

Sat, Aug 24, 2002 at 05:53:49PM -0500, rancid:
> Forgive the newbie. Implementation and general satisfaction meets
> expectations.... However, I would like to know how to customize the commmands
> set used by do-diffs. (I attempted to sort through archives, but ugh.)
> --
> sig=$header

there isnt such a facility built-in at the moment. we have been discussing
how to add this though. so, its coming at some point.

>> Forgive the newbie. Implementation and general satisfaction meets
>> expectations.... However, I would like to know how to customize the
>> commmands set used by do-diffs. (I attempted to sort through
>> archives, but ugh.)

heas> there isnt such a facility built-in at the moment. we have been
heas> discussing how to add this though. so, its coming at some
heas> point.

As someone who just upgraded to rancid-2.2.2 thereby unintentionally
clobbering my modifications to bin/rancid's list of router commands of
interest, let me voice my support for such a facility. I see that
"make install" preserved my modified bin/env file with the new one
ending up in bin/env.new -- it would be terrific if the command set
was in a file which would be similarly preserved across an upgrade.

Thanks.
Jay B.




--
Jay Borkenhagen jayb at braeburn.org

Thu, Aug 29, 2002 at 11:42:08AM -0400, Jay Borkenhagen:
> >> Forgive the newbie. Implementation and general satisfaction meets
> >> expectations.... However, I would like to know how to customize the
> >> commmands set used by do-diffs. (I attempted to sort through
> >> archives, but ugh.)
>
> heas> there isnt such a facility built-in at the moment. we have been
> heas> discussing how to add this though. so, its coming at some
> heas> point.
>
> As someone who just upgraded to rancid-2.2.2 thereby unintentionally
> clobbering my modifications to bin/rancid's list of router commands of
> interest, let me voice my support for such a facility. I see that
> "make install" preserved my modified bin/env file with the new one
> ending up in bin/env.new -- it would be terrific if the command set
> was in a file which would be similarly preserved across an upgrade.
>

the idea we've been kicking around is to have a file (a default file
included with the dist and perhaps a "file.local") which defines a
device "type".

for a given type, you could set which commands you wanted collected and
what function (including home-grown external scripts) to use to filter
the output. this "type" is then used as the type in the router.db file,
eg: cisco or cisco_osr, where cisco_sla might have additional (or
fewer) commands for your OSRs.