RANCID monitors a router’s (or more generally a device’s) configuration, including software and hardware (cards, serial numbers, etc) and uses CVS (Concurrent Version System) or Subversion to maintain history of changes.
Installation
(Optional Step) The first thing to do is to create a new user called rancid because you should avoid running any applications with the root rights for security reasons.
#adduser rancid –home /home/rancid
Step 1.
#sudo apt-get install rancid
Configuration
The installation creates a new user and group named “rancid” with a home directory of /var/lib/rancid. Now, we must create at one least one group in RANCID to logically organize our devices. Groups can be based on any criteria you wish. So if you’ve got one physical location you could create “router”, “firewall”, and “switch” groups, or, in larger environments with multiple physical locations, group names such as “Los Angeles”, “San Francisco”, and “New York”
Note:Even though it’s a blank file, it’s good practice to start by making a backup copy of the original rancid.conf file.
sudo cp /etc/rancid/rancid.conf /etc/rancid/rancid.conf.ORIGINAL
Open the file “/etc/rancid/rancid.conf” in your favorite text editor, add a line similar to the following, and save and exit.
LIST_OF_GROUPS=”Los_Angeles, San_Francisco, and New_York”
E-Mail Notification
Here we have to let RANCID know who should receive e-mail notifications for each group of devices. This is done by creating e-mail aliases in your MTA’s configuration files. By default on Ubuntu this is the “/etc/aliases” file.
For each group that you created, we need to add two aliases to the aliases file named “rancid-<groupname>” and “rancid-admin-<groupname>”. Open up the “/etc/aliases” file in a text editor and add lines similar to the following:
rancid-Los_Angeles: <your_email@address.com>
rancid-admin-Los_Angeles: <your_email@address.com>
rancid-San_Francisco: <your_email@address.com>
rancid-admin-San_Francisco: <your_email@address.com>
rancid-New_York: <your_email@address.com>
rancid-admin-New_York: <your_email@address.com>
After saving your changes and exiting, you’ll need to let your MTA know about the changes. Since Ubuntu use sendmail by default, this can be accomplished by running…
sudo /usr/bin/newaliases
CVS Repository
Your device’s configuration files will be stored in a Concurrent Versions System (CVS). This provides a way to track changes over time as well as provides you with a bit of disaster recovery. In order to prepare CVS we must create a folder structure based off of the RANCID groups that we created earlier. This command needs to be run as the “rancid” user that was created when the RANCID software was first installed.
sudo su -c /var/lib/rancid/bin/rancid-cvs -s /bin/bash -l rancid
Assuming that runs without any errors, you should see a number of new directories created under “/var/lib/rancid”, named according to the RANCID groups you defined earlier (e.g. “/var/lib/rancid/Los_Angeles”, “/var/lib/rancid/San_Francisco”, “/var/lib/rancid/New_York”, etc). Inside each will be a file named “router.db”:
[username@hostname ~]
$ sudo find /var/lib/rancid -type f -name router.db
./Los_Angeles/router.db
./San_Francisco/router.db
./New_York/router.db
Hosts File
Before going any further, it’s a good idea to ensure that you can ping the devices that you want to download configuration files from by name.
Again, it’s a good idea to make a backup copy of the original file that we’re about to work on. In this case the /etc/hosts file.
sudo cp /etc/hosts /etc/hosts.ORIGINAL
The original /etc/hosts file should look something like this…
127.0.0.1 localhost
127.0.1.1 yourcomputershostname.exampledomain.com yourcomputershostname
# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
Now that you’ve made a backup, edit the /etc/hosts file and just above the commented line so that they’re grouped with the other IPv4 information, add something like the following…
1.1.1.1 router.location1.com router
2.2.2.2 firewall.location2.com firewall
3.3.3.3 switch.location3.com switch
This is VERY important so take the time to ensure that not only can you ping the device by its IP address, you can also ping it by either it’s Fully Qualified Domain Name (FQDN) or simply by its hostname.
Router.db Files
Inside each of these “router.db” files is where we let RANCID know what devices exist in each location. A single line in each file is used to identify a single device. The format of the definitions is of the format “hostname:type:status”, where “hostname” is the fully-qualified domain name or IP address, “type” defines the type of device (e.g. “cisco”, “hp”, “foundry”, etc.) and “status” is either “up” or “down”. If “status” is set to “down”, RANCID will simply ignore the device.
Sample entries might look like this:
router.location1.com:cisco:up
firewall.location2.com:hp:down
switch.location3.com:foundry:down
cloginrc
Once you have successfully added your devices to the appropriate “router.db” files, we need to let RANCID know how to access the devices (telnet, SSH, etc.) and what credentials to use to login. This is done via the “.cloginrc” file that exists in the rancid user’s home directory (“/var/lib/rancid/.cloginrc”, by default).
It is a good security practice to never connect to devices via telnet, so this guide will only cover the SSH method of connecting to a device. Other connection methods are also supported. The way the .cloginrc file is configured also depends on how the end device is configured to authenticate users. Users can be configured locally or a device can authenticate users agains an enterprise system such as LDAP or Active Directory. It gets complicated quickly so make sure that you take your time and read the documentation all the way through.
man cloginrc to see the details of all the available options and keywords available for use.
This guide will assume the simplest setup in which local usernames and passwords are defined on the end devices themselves.
Here’s some example information my a .cloginrc file…
#Firewall
add method firewall.location2.com {ssh}
add cyphertype firewall.location2.com {des}
add user firewall.location2.com {rancid}
add password firewall.location2.com {<user_password>} {<enable_password}
Testing
clogin
The basic of tests utilizes the clogin application.
/usr/lib/rancid/bin/clogin -f /var/lib/rancid/.cloginrc firewall.location2.com
The clogin application will use the .clogin configuration file specified by the -f variable and will automatically login to the device named firewall.location2.com When it’s all said and done you should end up in enable mode on the firewall device. If there are problems, clogin does an excellent job of providing pointed advice on what is wrong.
rancid-run
With RANCID now configured, it’s time to test it out! Let’s manually invoke “rancid-run” (as the “rancid” user) to see if it all blows up!
[username@hostname ~]
$ sudo su -c /var/lib/rancid/bin/rancid-run -s /bin/bash -l rancid
This command may take a while to run, depending on how many devices you have configured. Be patient and, when it finishes, review the logfiles created in “/var/log/rancid”.
Assuming all goes well, you should receive e-mails from RANCID sent to the addresses that you defined in earlier in “/etc/aliases”.
Automating
Once everything is working, it’s time to automate the collection and archiving. The easiest way to do this is to simply create a cronjob under the rancid user that calls “rancid-run” for us on a periodic basis. We have RANCID run weekly, every Wednesday at 11:59AM
[username@hostname ~]
$ sudo su -c “/usr/bin/crontab -e -u rancid”
Modify the contents of the file so that you end up with something like this.
# m h dom mon dow command
59 11 * * Wed /usr/bin/rancid-run