Using Built-In Revision Control In Firewall Builder - Page 2

Now I save ths file using menu File/Save and exit the program. Before I can do that, however, the program tries to check the file in to the RCS and presents a dialog where I can add a comment to document the change I made. I enter the comment and press Check file in button to complete operation. The file is now checked in and the program exits.

Now I restart the program and try to open the same file using File/Open. Since the file is now in RCS, the program presents the dialog with the list of its revisions. Each revision has a comment associated with it, shown at the bottom of the dialog. Note also that each revision also shows the user name of the user who checked it in which is very useful in a multi-user environment.

If I choose revision 1.2 (the latest) and open the file using button Open, I get my rules including rule that permits HTTP to the firewall:

If I choose revision 1.1 and open the file, I get the policy that looks like this (note revision number in the main window titlebar, it is 1.1):

The rule to permit HTTP to the firewall is not there because I opened old revision of the data file. Essentially, I rolled back the change I made in rev 1.2. If I only wanted to look how rules looked like in rev 1.1, then I can now just close the file and open its latest revision to continue working with it. I can not only just look at the rules in the old revision, I can compile them and install on the firewall if that is what I need to do. Note that this can break things if some protocols were added to the firewall rules later, but this can be useful if you need to test things as they were few days ago.

However if I want to roll back the change and continue without it, all I need to do is make the change in this revision (1.1) and then save and check it in. This will create a branch in RCS and I will be able to continue working with it later. The previous change, checked in as rev 1.2 will always be there though and I will always be able to revert to it if I want. The program does not merge branches, merging changes in XML files is a complex task and is not implemented at this time.

To illustrate creation of a branch, I am making a change to the revision 1.1 of the data file as shown on the next screenshot:

I then save and check this file in with appropriate comment. To check it in I use menu File/Commit. I then close the file using File/Close and reopen it again using File/Open. This acoomplishes the same operation as in the example above in this document, except I do not close the program. When I try to open it, the program shows the branch and new revision 1.1.1.1 that I just created. Note that the time of the revision 1.1.1.1 is later than the time of revision 1.2:

Now if I open rev 1.1.1.1 and continue working with and check new changes in, the program will create revision 1.1.1.2 and so on.

This document demonstrates how built-in revision control system (RCS) in Firewall Builder GUI can be used to document changes in the file. It can also be used to roll back changes to previous revision both temporary or permanently. Using RCS helps establish accountability if several administrators can make changes to the policy of firewalls because RCS keeps track of the user name of user who checked changes in. RCS in Firewall Builder works on all supported OS, that is Linux, FreeBSD, OpenBSD, Windows and Mac OS X. On Linux, *BSD and Mac OS X it relies on system-wide installed rcs package, while on Windows rcs tools are installed as part of the Firewall Builder package. In general, I recommend always using RCS even in simple cases when only one administrator uses the tool. Ability to document changes and roll back if necessary are great advantages that help a lot to improve the process of security policy management.