next up previous contents
Next: Security Issues Up: Using CVS to Administer Previous: Version Control on Routers   Contents

Extended Architecture

Figure 3: Extended Architecture
[Extended Architecture]

The lock file concurrency control that is implemented for the architectures covers so far does not scale well. An administrator can quite easily hold a file open for longer that it is reasonable for a script to try and gain access, especially if these scripts are interfaced off the web and are expected to run in real time. An additional short coming of the systems outlines is that edits are made directly to the production system. This can be dangerous if partial edits are written to disk and the system is then committed by some other process bringing those changes into effect.

An alternative, though more complicated system involves each user and each script having their own working directory in which their edits are made. This fits more closely to the way that CVS is intended to be used and as a result the concurrency control build into CVS can be brought into play.

Figure 4: Extended Architecture - Entity Relationships
[Extended Architecture ERD]

Each user or script checks out the configuration files into a local directory that is local to them. Checkouts are expensive but after the first time a CVS update can be used to ensure that the local tree is up to date. Updates are quite cheap in comparison to checkouts. Edits are made to the configuration and once these are completed a commit is made placing the changes made into the repository. Finally an update is run on the production system in order for the changes to become 'live'.

In the case where there is contention for the edit of a file that CVS cannot resolve and a commit is being made by a script this can be considered to be an error state. When this occurs some form of notification should be given to enable human intervention and any changes made to the local directory should be rolled back.

These processes can once again be automated with the aid of make and even the updated on the production system can be automated being triggered either by make in the local directory or run periodically as a cron job.

Aside from giving greater concurrency control this system also offers the potential for a stronger audit trail as the commits made by different users and scripts can be more easily traced, depending on the access mechanism.


next up previous contents
Next: Security Issues Up: Using CVS to Administer Previous: Version Control on Routers   Contents

1999-02-04