[rancid] How to extend Rancid. Basics.

[Alan McKinnon]

On 01/08/2015 18:46, JM wrote:
> Alan McKinnon <alan.mckinnon <at> gmail.com> writes:
> 
>>
>> On 01/08/2015 13:30, Alex DEKKER wrote:
>>> On 01/08/15 10:48, jm+rancid <at> roth.lu wrote:
>>>> Hi there,
>>>>
>>>> I wanted to extend Rancid with a script to monitor some Checkpoint
>>>> Gaia firewalls.
>>>
>>
>> It's not that simple, there is no "master reference device type" so to
>> speak.
>>
>> Here's how rancid works:
> 
> Ok, as I thought, you just give rancid some text to store.
> 
> For non-perl gurus, the modern modular method is complicated. In fact, the
> regexes you are talking about are specific to that I believe. As are
> variables like $found_end and $clean_run that seem to be important to talk
> to the main process. (Or is it just the return codes?)

The regexes are the bulk of the main loop inside the *rancid scripts,
and there are hundreds of them. Each one follows these general sort of
examples:

/some regular expression/ && next;
/some regular expression/ && ProcessHistory(...);

These are the magic bits of code that determine exactly what text will
make it into the output file that is eventually stored in CVS. They are
a monumental pain in the butt to maintain but there's really no other
way to do it. It's not rancid's fault - blame the kit vendors for not
agreeing to provide a standard way to access the info (which just
happens to be the second most important thing about it once the device
works as intended). So each line has to be examined individually and
treated as a separate entity.

$found_end and $clean_run are internal true/false flag variables. They
indicate if the script got the full text it was expecting (a chunk of
text corresponding to each command issues plus a proper EOF at the end),
and if no errors were found. These flags tell the script if it must exit
with success or failure.


> 
> Nothing will however prevent me from using the "old" method, give it a
> "script" and a "login" (in the types file).

Yes, you can do this. It's probably the better route if you only need to
deal with one device type not supported by rancid as shipped. The code
will be clean and you know right away it's a local addition to the codebase

> 
> "login" can be, well, expect the login prompt, send the username, etc. you
> get it. The "script" can be a stupid expect script running "show
> configuration" and capturing the output. Maybe with some wrapper in a
> language one is fluent in around it to carry out additional checks. 

Yes, that's the way to do it. Use whatever tool you know and feels right

> 
> 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?

-- 
Alan McKinnon
alan.mckinnon at gmail.com