[rancid] How to extend Rancid. Basics.

JM jm+rancid at roth.lu
Sun Aug 2 12:49:24 UTC 2015

Alan McKinnon <alan.mckinnon <at> gmail.com> writes:

> > 
> > Don't get me wrong. It's great that the "modern method" to use rancid is
> > more modular (also less code duplication like with copying scripts etc.). It
> > could however be interesting to have some abstract configuration file where
> > you just tell it what to do, what to expect as a return, what to treat as
> > error. Much like "expect" in itself, but simpler, because in that case you'd
> > need to be a TCL guru. I'm thinking more along the lines of an INI file or
> > something =D
> I'm not sure I understand this paragraph. What is it that you want to
> configure?

As far as that section goes, I was just wondering why there has to be code
for what could be considered configuration/definition in a format everyone
is able to use.

Maybe we should take a step back and get a look at the big picture. What do
we want rancid to do? Login, issue commands, get some replies, filter what's
deemed useful, and then logout again.

What could a simple definition in an abstract langugage (INI file, JSON,
...) look like?



## metadata

# login prompts
userprompt=User Name:
# command prompt (regex)
# enable mode required/exists
# this could even be generalized to any other special modes
# or even issued as a simple cmd[] below

## now tell it what to do

# command after successful login (commprompt seen)
cmd[1]=show configuration
# how to find out when previous command has sent all output?
# filters on output
filter[1][1]=s/password (.*)/x/

cmd[2]=show version
#end[2]=commprompt (default)

cmd[3]=show dir

# instead of using special "enable" statement above, just do it manually here
# then do more stuff

end[5]=Connection closed.


More information about the Rancid-discuss mailing list