On Fri, 25 Oct 2013 10:07:49 +0300 Saku Ytti <saku@ytti.fi> wrote:
On (2013-10-24 23:05 -0400), Erik Muller wrote:
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. Regards, Martin