I am unsure what we as networkers have done in the past, but I am sure
we've done our fair share of atonement and don't have to keep using
RANCID.
Some might say "it took ages to get rancid to do kinda what we want!",
but not all software ages well. One might work in environments where
archived configurations are needed to even start provisioning, one
might desire a separation between actual config and transcient data.
As I am evaluating our path forward, I've compiled a small list of open
source projects with some biased highlights. Your feedback is most
welcome, maybe I missed some interesting projects or developments. I
would also be very interested in what other operators seek in a network
config/state archive tool.
RANCID - http://www.shrubbery.net/rancid/
* Support for a wild variery of devices and operating systems
* complex perl code base [1]
* no central developer team, the internet is littered with forks
Oxidized - https://github.com/ytti/oxidized
* modern & sexy approach with queue & workers
* RESTful API (example: can bump devices to the head of the queue)
* small user & developer base
* written in that ruby language
Some might say "it took ages to get rancid to do kinda what we want!",
but not all software ages well. One might work in environments where
archived configurations are needed to even start provisioning, one
might desire a separation between actual config and transcient data.
Rancid certainly has its warts, but other than needing to test, pull hair, and patch things for new OS/platform deployments, it still generally Just Works once you have it installed, IME... and references like http://www.shrubbery.net/rancid/SteveSmithFedora15.pdf that are a bit dated still work well as a guide for deployment on more recent server OSes.
As I am evaluating our path forward, I've compiled a small list of open
source projects with some biased highlights. Your feedback is most
welcome, maybe I missed some interesting projects or developments. I
would also be very interested in what other operators seek in a network
config/state archive tool.
I can't claim any knowledge of its actual functionality, but I've also heard of
NOC Project - http://nocproject.org/
From the docs, it seems like it's trying to be more of an all-in-one do-everything package than just an archiving tool, but it could be worth investigating. It claims support for a wide array of kit, and seems to have a non-trivial user base.
I'm sure I'm not the only one who'd be interested to hear if your evaluation determines that there is a R,RAN*ID out there that we've been overlooking.
-e
Rancid is known to crash cisco devices doing config backups. I've seen it
on 7200/7500 routers multiple times
I don't doubt it, but since RANCID only uses show commands; I would
suspect that any similar tool that uses similar show commands, could
expose the same issue ---- which is obviously a router CLI bug not a
RANCID bug.
Does the nature of the codebase and future development matter all that
much? Not to dismiss it as a factor, but I think other criteria should
be more important
Nrmally when I would want to compare software ---- I would be concerned
first and foremost, (1) What does it do/what makes it unique -- is
something special about package X over package Y?;
(2) Does it meet all the minimum needs I have right now to be a viable
solution?
Does it grab all my configs and put them in a permanent
revision control system?
(3) How reliable is it, can I trust it? Is it very secure and safe to
use? It's no good if it breaks, fails, or does something dangerous.
How much care and feeding will it need to keep working? If it
needs complex repair work every few weeks, I don't like it.
(4) How easy is it to get up and running, and to perform any required
ongoing maintenance
(5) What extra nice to have functionality does it have?
(6) Maybe other stuff like what language its written in, if extra
features need to be added
Puppet, Chef, cfEngine, etc... the list goes on and on, it's a matter of taste (no chef pun intended) and what you're familiar with as well as what works for your device configurations and the management team
Rancid is great, we use it. It's hard to justify paying money for
something that really isn't that complicated, especially stupid licensing
fees.
One of my problems with rancid though is that many of the commands it runs
can be somewhat intrusive, and also smacks of trying to use a configuration
management system as an active monitoring tool.
Go into the commandtable entries for your various devices, and remove
everything except the show running-config bits (or whatever your $vendor
uses) and you'll run into a lot less risk of blowing a device up with
rancid, also a lot quicker execution times.
Or just remove rancid entirely, and just ssh show running-config (using rsa
keys) on your devices and dump the output into cvs/svn/whatever. Not
everything has ssh though.
For us problem with rancid is that we're quite married to configuration
backups, provisioning depends on them. And we have good number of devices in
rancid and rancid runs take several hours.
Now we may need refreshed configuration backup to satisfy some dependencies to
complete some work, but if rancid is running we cannot, in worst case, we may
need to postpone some work to next working day.
We have 'one off' hack script for rancid, which fetches just one device right
now, but we cannot run it if rancid proper is currently running.
Other than that, rancid works very reliably and is highly robust. For style
rancid does not get points as there is terrible amount of code duplication for
different platforms.
Philosophically speaking, configuration backups should be completely useless,
full configuration to network should be generated from central place in
fully automated manner.
> Rancid certainly has its warts, but other than needing to test, pull
> hair, and patch things for new OS/platform deployments, it still
> generally Just Works once you have it installed, IME... and
> references like
For us problem with rancid is that we're quite married to configuration
backups, provisioning depends on them. And we have good number of devices in
rancid and rancid runs take several hours.
Now we may need refreshed configuration backup to satisfy some dependencies to
complete some work, but if rancid is running we cannot, in worst case, we may
need to postpone some work to next working day.
We have 'one off' hack script for rancid, which fetches just one device right
now, but we cannot run it if rancid proper is currently running.
Have you tried running multiple rancid instances in parallel? (each talking to a
different batch of devices)
Other than that, rancid works very reliably and is highly robust. For style
rancid does not get points as there is terrible amount of code duplication for
different platforms.
The main reason we're all stuck with rancid is that there is no standardized
way to securely pull configurations and other information from devices built by
all major vendors. Rancid, as horribly written as it may be, has over the years
incorporated ways to deal with the quirks of pretty much every CLI out there.
This is hard to duplicate.
Philosophically speaking, configuration backups should be completely useless,
full configuration to network should be generated from central place in
fully automated manner.
The diff-ed backups that rancid provides serve another purpose: verifying that
what your NMS says should be configured matches the actual device
configurations.
For the last ~8 years we've used a very simple in-house bash
script that uses SNMP to tell the switch to write its config using
tftp, and then does a wr mem. It then checks the configs into a
subversion repository and e-mails out any diffs.
One criteria we had was that our config backup system wasn't going
to get CLI access to any routers if at all possible, and this
turned out to be a good alternative. I can't think of many times
when it's failed to work; occasionally the odd switch might not
respond, but that's rare.
The only possible issue being that we're 100% Cisco, so I don't
know if other vendors support the same MIBs.
I'll try and post the script (250 lines) somewhere if anyone's
interested.
SNMP is a good/ quick way to do it, however you should keep in mind that
your configurations are not being sent securely if you're using tftp. Cisco
devices do allow you to also use ftp, rcp, scp and sftp.
As far as I'm aware (someone please correct me if I'm wrong), but Cisco is
the only vendor that supports this.
It's almost as easy to have a python/ perl script to do the exact same
thing as Matthew described but with SSH instead of SNMP.
