Zivios Architecture

Zivios is an n-tiered PHP-5 application. It uses MySQL and OpenLDAP as it's datastore, with OpenLdap being the primary backend for identity management and application integration and MySQL being used for panel specific data.

Zend Framework is our framework of choice and Zivios implements its MVC design pattern.

View Larger

The Default Module

The default module contains core Zivios logic in the form of model classes, implemented on the front via controllers and views. All models in Zivios are children of Ldap_Cache which is a built-in generic caching mechanism. Object loads are always requested through the Cache. If the cache misses the request, it is handed over to the Ldap_Engine which does the actual data loading and ACL parsing. The default module's controller are the first to load when an object is being viewed. The default module dispatches calls for the correct module controller thereafter.

The default module's models are the brains behing Zivios. All plugins, services, etc. must extend from one of the models to be used inside the Zivios code base.

Acls

Zivios supports Openldap ACI based ACLs as well as internal Zivios ACLs. OpenLDAP ACIs are read and parsed automatically on object loading, allowing read-only attributes to be set before any attempt is made to write to them.

Zivios ACLs (supplementary to OpenLDAP ACIs) provide a mechanism by which even modules can define and use their own ACLs. An example of such an ACL is CORE_USER_CANCHANGEPW. This ACL is checked everytime a password update is requested. Zivios ACLs resemble OpenLDAP ACIs in format and functionality. Like OpenLDAP ACIs they can be placed on subtree, entry and applicable to users, groups, subtrees, self or none.

Zivios also provides a comfortable panel for administration of OpenLDAP and Zivios ACLs

Caching Engine

All activity within Zivios is cached for the inidividual session. Caching is necessary as Zivios computes and stores ACLs and supplementary objects on initialization. Since a large tree can have hundreds of thousands of entries, caching proves extremely beneficial as usually common items are accessed. The cache maintains ldap coherency by checking the modify timestamp. If an entry is modified (externally or internally) the cache misses and updates itself.

Cache also goes into transaction mode when a transaction is being prepared. This allows disjointed pieces of code to formulate a coherent transaction without any change to their normal functionality.

Users,Groups,Computers and Service

These are the four building blocks of Zivios:

Transactions

Transactions allow loosely coupled code within Zivios. This is necessary for multiple reasons:

• Implementing Workflow or delayed code execution. We need a mechanism to be able to store object state AND the code to be called on it in case we wish to delay the actual processing (for workflow purposes).
• Transparent plugins. Plugins need not follow any hardcoded pattern for different scenarios. The controllers can 'chain' multiple transactions. Each 'unit' of Zivios simply has to do its part and chain it to the existing transaction. This allows loosely coupled code. Problem being that I have no idea which plugins a particular USER has on which 'UPDATE' needs to be called.

Zivios Agent

Zivios utilizes a client side Python Agent for remote execution of commands. The Agent is itself infinitely extensible. You can write a python agent module for your own user module. XML-RPC calls are utilized to communicate with this agent. For security reasons, all communication with the agent is SSL Encrypted using the certificate that Zivios produces from its CA module.

Zivios Modules

Everything in Zivios (other than core libraries and the default module) is a module. As such all modules follow similar design principles. As outlined earlier in this section, there are four building blocks of Zivios: User, Group, Computer and Service.

Modules must (at least) extend on one of these models to be called a Zivios module. Modules may further implement as much other functionality as they may prefer, but at least one side of it must link to Zivios. The table below highlights the prior explanation:

If a module implements user, group or a computer plugin it will show as an orange tab in their respective views. If the module implements a service model, it will become available as a pluggable service.

For plugins, page rendering is diverted completely to a plugins UserController. This means that a module providing a UserPlugin must also implement a UserController. This allows for maximum flexiblity in the plugins design while maintaining the overall look and feel consistent.

Please check Modules, Services and Plugins on the Zivios wiki for a detailed discussion