[rancid] How to extend Rancid. Basics.

[Alan McKinnon]

On 02/08/2015 14:49, JM wrote:
> 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.

"filter what is deemed useful" is where it all breaks down. There are
not a few of these, there are HUNDREDS of them for each device. Again,
blame the vendors for forcing us to resort to the worst possible
solution - manually parse free-form text output to derive information.

And we haven't even touched yet on the bits where stuff needs to be
redacted. "show run" dumps plenty secrets to the output - encryption
keys, community strings, passwords, hashes, certificates, private keys
and who knows what else, all of which has to be manually examined and a
regex written.

And it's not just "write stuff to output", it's "write stuff to output
in such a way that it is consistently ordered to not continually upset
CVS with noise that isn't a real change". See the ACL handling for the
best example of why this is vital.

It very quickly explodes out of control if you attempt to do it any
other way than how it is done.

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


At heart, it would be a lookup pair. I'm only concentrating on the
output text mangling as everything else is easy, .ini key-value pairs
will suffice.

You'd have a regex on the left (no other descriptive language comes
close to a regex) and an action on the right. The trouble is, that
action can only be a code snippet, and this opens a world of hurt.

I'm glad you've opened this topic as I've tried to find ways to solve
it, and like you I figure there must be an easier way. But every time a
good solution trips up on real life requirements...

If you have a viable and well-thought out idea, I'm all ears. I've
looked for years and haven't found one. But it won't be the first time I
overlook something :-)
> 
> 
> --------------------------------------------------
> 
> [router1]
> 
> ## metadata
> 
> connectmethod=ssh
> username=x
> password=y
> passphrase=z
> # login prompts
> userprompt=User Name:
> passprompt=Password:
> # command prompt (regex)
> commprompt=/>\s*$/
> # enable mode required/exists
> # this could even be generalized to any other special modes
> # or even issued as a simple cmd[] below
> enable=1
> enablecommand=enable
> enableprompt=/#\s*$/
> 
> ## 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?
> (default=commprompt)
> end[1]=commprompt
> # filters on output
> filter[1][1]=s/password (.*)/x/
> filter[1][2]=s/bla/blubb/
> 
> cmd[2]=show version
> #end[2]=commprompt (default)
> 
> cmd[3]=show dir
> 
> # instead of using special "enable" statement above, just do it manually here
> cmd[4]=enable
> end[4]=/#\s*/
> # then do more stuff
> 
> cmd[5]=exit
> end[5]=Connection closed.
> 
> --------------------------------------------------
> 
> 
> 
> _______________________________________________
> Rancid-discuss mailing list
> Rancid-discuss at shrubbery.net
> http://www.shrubbery.net/mailman/listinfo/rancid-discuss
> 


-- 
Alan McKinnon
alan.mckinnon at gmail.com