meets

Updating LDAP

this document summarizes the strategy in which to correctly perform ldap updates when updating a site.

Overal Problem Description

With every release the configuration possibilities expand. New features require new configurations. Some configuration extends the existing functions (i.e. support for new DICOM attributes, internal server improvements' config), some add completely new functionalities (i.e. config of new Service Classes or HL7 messages).

With each release a update-X.X.X.ldif file is released in the opensource, setting defaults for some config options, while other optional features' config is not set, only documented in the opensource wiki howtos: The general question is, whether shall we rather keep the site configuration as close as possible to default, or only update parts which are actually in use. A mix of both is most likely appropriate for most situations. Therefore, the process of updating LDAP to a new version requires:

Vendor Data

The xsl stylesheets (i.e. ORM2MWL transformation config etc.) and other "file-based" configuration are stored in LDAP in binary form within the <device>/dicomVendorData attribute. With a new version some new features/files can be added - thus the value of this attribute needs to be updated. In case you are using the default stulesheets etc. this is quite easy:

In case you previously changed some of the vendor data config i.e. one of the stylesheets. you can modify the above approach:

Multiple servers sharing a configuration

i.e. in Tallinn: The easiest policy to adopt in this situation is to