Most firewalls are administered by a group of administrators and not just by a single individual. In a Zorp system each administrator can have his or her own ZMC console and administrators can be separated geographically. Regardless of their locations they administer the same set of Zorp firewalls through a single ZMS host machine. Therefore, to avoid configuration inconsistency caused by more than one administrator working with the same configuration simultaneously, a configuration lock mechanism ensures that a component's configuration can only be modified by a single administrator at a given time. Locking takes place per component, as soon as they are changed, for example, a setting in a component, the status bar displays the following string: Unsaved changes and that component is locked for configuration.

However, modifying a component might make it necessary for other components to be locked as well, in order to prevent configuration from inconsistent changes.

There exist some generic rules that can be applied for managing locking successfully:

Active locks can be viewed at Management > Locks:

Figure 3.21. Management > Locks - Viewing active locks

The Owner column can take two values:

The lock placement is automatic. The first administrator who starts modifying a component's settings gets the lock of that actual component. In the Active locks column the exact name of the locked component (Site/Host/Component) is displayed. Locks are cooperative, meaning that any administrator can release any other administrator's locks by selecting the desired component in the Lock management window and then clicking Release. The administrator whose lock is released this way is immediately notified in a warning dialog. Also note that as a result of the release of the forced unlock, the GUI owning the released lock closes without saving any modifications in order to avoid any inconsistency in the configuration.

It is not possible to edit a component that is already locked by someone else, because a notification dialog immediately appears upon trying to change anything inside the given component. The following window will be displayed for any other administrator who wishes to edit the component:

Figure 3.22. Notification on a locked component

As required by the mentioned lock queue mechanism implemented in ZMS, administrators shall not normally release each other's locks, but they can preregister for future locks while the current lock is active.

The above window will however not disappear, after the locking administrator commits the changes. Other administrators therefore, can either preregister for locking the component by clicking yes or choose not to preregister by clicking no.

In case an administrator preregisters for the locking of an element, the following window appears:

Figure 3.23. Component waiting for locking

As soon as the locking administrator releases the lock, the window Component waiting for lock disappears and the user wishing to edit the component is granted the lock automatically. Normally, this shall not take long.