How RANCID Tool Keeps Config Files Clean

Configuration management (CM) tools like Puppet and Chef are really useful for keeping your systems in line, but what about your infrastructure? The Really AwesomeNew Cisco confIg Differ — or RANCID for short — is the first step in tackling this problem (out of 5 tools of DevOps) In essence, RANCID is a suite of utilities that enables automatic retention of your configurations in revision control. If you have a physical infrastructure at any level, you should be working to have the same level of control as you do on your servers with your CM solution.

So that sounds good, but what problem does RANCID really solve? The core usage is to create an audit trail of software configurations and hardware information for the devices that glue servers together. The configuration of your switches, routers, and load balancers may not be changing as fast as the code in your Rails app (at least I hope not!), but it does change over time. The rate of change is usually tied to how fast your environment is either changing or expanding.

Auditing is a great first step in the automation process. You have to know where you are to get where you’re going after all! RANCID does this out of the box for devices from Cisco, Juniper, F5, and many other vendors. The audit process requires a basic installation of RANCID and configuration of a read-only user on the devices you want to monitor. The result is a current configuration automatically pulled on a regular schedule, committed to revision control, and an email detailing that changes in your inbox.

So now you’re ready to try out RANCID, but where to start? If you are a Subversion shop, you’re set — go grab the latest tarball and follow along with the Getting Started guide. Git users can grab a fork of RANCID that is patched to add git functionality. Though git isn’t natively supported by the maintainer of RANCID, I prefer git to Subversion, so that’s the code base that I use.

Once you have RANCID installed, there are a few base configuration items that need to be set in /etc/rancid/rancid.conf (or wherever your rancid.conf was installed).

rancid.conf

RCSSYS=git

FILTER_PWDS=YES

LIST_OF_GROUPS="pdx slc ord"

Configuring RANCID to pull configs requires the username and password used to connect to each device, optionally using hostname matching. RANCID supports connecting to devices over telnet and ssh. I’m sure this goes without saying, but don’t use telnet, and don’t even enable it on the devices! Some devices support key-based authentication (like Juniper and F5) and do not require passwords. In this case, RANCID will use the ssh key if one has been configured for the ranicd user, and RANCID is configured to connect via ssh. Otherwise, you can configure passwords in the .cloginrc file, which can be found in the rancid user’s home directory. Here is an example:

~/.cloginrc

#We only use SSH

add method * {ssh}

#Wildcard for all devices

add password *.example.com LoginPassword EnablePassword

add password router.example.com OtherPass AndAnotherPass

Finally, you need to configure which group a device belongs to. You will need a directory with the same name as each group you identified above, and each should contain a configuration file. This is where RANCID shows some of its heritage, as the configuration file, for this is called router.db. It’s not limited to, routers, however, and it’s not a database but a simple text file. Each line in the file represents a device in the form of hostname:type:status, where type is the type of device from the list of supported devices and status is either up or down. Devices that are marked down are not queried for their configuration, but they remain in revision control. Here is an example:

~/pdx/router.db

switch.example.com:cisco:up

router.example.com:juniper:up

balance.example.com:f5:up

Now, assuming you configured the user RANCID runs as on the above devices, as the RANCID user, you should be able to manually run rancid-run to gather all the configs. Once the devices have been queried, the full config is available at ~/pdx/configs/switch.example.com and a diff is emailed to rancid-pdx, which should have been aliased to you previously.

Phew — now you can rest knowing that the configurations and hardware details for all of your configured devices are safely on the system running RANCID. That might be good enough, but having that repo pushed to, say, your local git server, is probably better. That’s another easy setup.

Set up a remote for the git repo

$ git remote add upstream <git url>

Create the following file at ~/.git/hooks/post-commit

#!/bin/sh

# Push the local repo to my upstream on commit

git push upstream

Now, that you’re armed with the basic details of setting up RANCID and a newly found tool for keeping track of your configurations, go forth and hack at it! With the goal of controlling your equipment, you can extend your current CM solution to reach down into the depths of the networking stack.

Enroll in DevOps training, to get more insight into its present day scenarios.