Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
We have a group of system administrators who would like to share a fwbuilder XML config file.
How can we prevent one administrator's fwbuilder instanct overwriting changes made wiht another administrator's fwbuilder instance using the same file?
use built-in RCS, it provides locking mechanism in addition to revision tracking. Put the file on a network share or in a shared directory, chgrp it to the group all your administrators belong to and make it group-writable, then open it in fwbuilder GUI and add it to RCS (menu File/Add to RCS). Now, when one administrator opens the file for editing, others will only be able to open it read-only.
What would you recommend for a team of 10 admins, where we would need an auditing system to track down who made changes and where/what in FWbuilder? Is there a feature like that? (I remember in my old days Checkpoint had it, would love to see something like that here).
Also, 1 more question - we went for now with Linux version of FWbuilder, installed on X windows system, what would you recommend to use for simplicity of work for several admins at once? We tried with NX, VNC, but it seems like we have no possibility to track down detailed changes (who made changes, where/what exactly).
Your advise is appreciated.
Right now there is no audit logging, but this is something we are looking at as part of a set of features that are targeted at large environments with a large number of firewalls and admins. We call these enterprise class requirements and they include features like a centralized object database, role-based access controls, revision history and rollback, audit logging, etc. We are actively working with several customers right now to capture more detailed requirements. Anyone who is interested in this type of multi-user solution should email email@example.com to learn more.
Right now the best solution we can recommend is to use a combination of storing the file on a network share and using RCS to control read-write access to the file. You can add comments when the data file is committed, so this is the best place for admins to log the changes that they have made to the data file. For example, if you are using a ticket system to track requested firewall changes you can include the ticket number (or url) in the commit log. The RCS history then becomes your audit log.
You can also split your firewalls up in to multiple data files to allow more admins to have read-write access to different firewalls in parallel. The tradeoff is that you have to create duplicate information, like commonly used networks, in two different data files.