Stay Informed

Sign up to whitepaper announcements here.

From the Isode blog...

Subscribe to RSS headline updates from:
Powered by FeedBurner

 

Creative Commons

Creative Commons License
Isode's whitepapers are licenced under a Creative Commons Licence.

Summary: Isode's messaging configuration is held in the directory. This provides a number of benefits, including client/server GUI management of configuration and the ability to share configuration data between multiple servers. This is described in detail in the Isode white paper Isode Management Architecture: Client/Server and Directory.

This core architecture provides a means for editing and management of a live configuration. This paper explains how this basic concept is extended to support offline configuration development and review, offline configuration testing and configuration version management. This paper explains the overall approach and shows how Isode tools are used to achieve this.

Publish Date
?
Last Modify Date
n/a

Share this whitepaper:

Basic Online Configuration Management

 

Isode's message routing and user configuration is held in the directory, as illustrated above. Message switch, routing configuration and X.400 users are managed using Isode’s EMMA tool. The configuration information is held in the directory, with EMMA providing a message management oriented view of this configuration. The following screen shots show example configuration, with the "raw" information as represented in the directory (shown by Isode's Sodium directory management tool) and the same information presented by EMMA.

 

Sodium (click for more detail)
EMMA (click for more detail)

 

This setup enables easy GUI management of a live configuration, with configuration data held in the directory. When changes are made using EMMA, some are used immediately by the live configuration, and others will be picked up at a polling interval set to five minutes by default.

Version Management

This basic model is extended to provide version management. EMMA can take a copy of the live configuration and save it in a file (LDIF format). Saved configurations can be loaded into the directory to enable restore to a previously saved version.

This version management allows "snap-shotting" of live versions and the ability to easily revert to a previous version. This can be used to support temporary changes with roll back, and also to give a safety mechanism when updates are made.

Offline Configuration Editing and Review

 

The systems described so far have always edited "live" configurations, which is not always desirable. The above diagram shows how the directory configuration model is extended to support offline configuration editing.

The basic model is to use a second directory server, which holds the offline configuration. This offline configuration is identical to an online configuration. This approach is used for a number of reasons:

  1. Directory names are used within the configuration, and a given name can only be held once in a given directory server. If the same configuration is needed in two places, two directory servers are needed.
  2. It gives a clear separation between the live and offline configuration.
  3. It provides a natural testing framework, as described in the next section.

Offline configuration editing will usually be used in conjunction with version management. The version to be edited offline will usually be based on a saved configuration version. When a new version goes live, it will often be saved as a labelled version first. In order to help manage this process, EMMA's version management is integrated with use of two directory copies of the configuration (live and offline). The following screen shots illustrate moving a configuration from offline to live.

For many sites, offline configuration editing typically in conjunction with independent configuration review will be a useful complete process. The next section shows how this can be extended to support testing of the offline configuration.

Configuration Testing

Use of two directory servers means that testing is done simply by making the offline directory the live directory for a test configuration, as shown above. Basic testing can be done by running a messaging system against the offline configuration. This will allow basic checking to be done, including routing and address checking.

In a large deployment with stringent testing requirements, it is quite likely that there is a separate test system that comprises multiple servers that are absolutely identical to the live systems. In this sort of test environment, multiple test servers can be used to test the actual live configuration.

For most environments, the test systems will be slightly different, an in particular machines will have different names and IP addresses. This means that testing communications with an exact copy of the live configuration is generally not possible. In order to test out an offline configuration, it will need to be modified to some greater or lesser degree, dependent on the nature and extent of testing. Built in IP addresses following RFC 1277 are used in a number of places. To make testing easier, EMMA provides a change IP address option, illustrated below. Note that IP addresses may be input directly or by using a hostname that resolves to the desired IP address.

This capability will generally be used for testing an offline configuration, to change from the IP address of the live system to the IP address of the system being used for testing.

Customer Support

The capabilities described above are useful for customer support. This includes Isode support of Isode customers, and Isode partner support of their customers using Isode products. The versioning capability makes it easy for customers to send a (text/LDIF) definition of the configuration to the supporting organization, who can run it up on a test system to examine and test the configuration.

 

 

Copyright © 2010 Isode sitemap    privacy   feedback Subscribe to our rss newsfeed