It's an iterative process where you tweak your subs and regular
expressions until you get the output you want.
Running rancid-run repeatedly puts strain on your routers though, so use
a short cut:
jrancid -d gives the jlogin command to use
use that and save the output to a file
use the file as input to jrancid -f
Now you can run it as many times as you like without hitting the network
As for writing subs,
add the command to @commandtable with the literal command as a key and a
suitably named sub as the value. The subs all follow this pattern:
# This routine parses "show chassis environment"
sub ShowChassisEnvironment {
print STDERR " In ShowChassisEnvironment: $_" if ($debug);
s/^[a-z]+@//;
ProcessHistory("","","","# $_");
while (<INPUT>) {
tr/\015//d;
last if (/^$prompt/);
<= regex magic goes here
}
return(0);
}
For me the hard part was figuring out how ProcessHistory() works -
specifically what the arguments do. They just mark the output off in
section and classify chunks of output that goes together. Change values
around and runt he code to observe what they do. It's hard to express
briefly in English so I'm not gonna try ;-)
Post by Jason BielUnderstood, but even when in a dev environment, what is the best way to
test changes to file for added commands? For example, I want to add new
commands to jrancid, but I am not 100% sure on the sub routine
configuration for parsing output. I suppose I can make the changes, use
rancid-run, and just keep tweaking until the output in the configs/
directory is what I want
I'm trying to mentally build out a process of adding commands for the
different devices we use without just shotgunning it.
Post by Jason BielWhile I understand the basics of adding additional commands to RANCID,
what is the ideal way to be testing new commands as I am debugging
them? Are most people running a dev RANCID install for testing?
Most definitely :-)
In any kind of real-life scenario, your rancid data in configs/
naturally evolves into a very critical data source. Almost nothing else
out there is capable of documenting real life systems to the extent
rancid can. This is great for your ego, but also means you can't fiddle
with it so much.
I keep 2 dev installs for different purposes and follow the classic
dev/test/debug/deploy strategy.
There's a second reason why this is a good idea - it is very common for
sysadmins to maintain their own little patchset to customize rancid
behaviour (mostly to account for quirks between device models) and then
repatch new releases if your tweaks didn't make it into the codebase. A
dev setup makes this process so much easier.
--
--
Alan McKinnon
_______________________________________________
Rancid-discuss mailing list
http://www.shrubbery.net/mailman/listinfo/rancid-discuss
--
Jason
_______________________________________________
Rancid-discuss mailing list
http://www.shrubbery.net/mailman/listinfo/rancid-discuss
--
Alan McKinnon
***@gmail.com