Bug 45220
|
Description
Florian Best
I can imagine three cases where extensibility is useful: 1) The customer wants to add a new mapping group, like 'user', 'dc' or 'windowscomputer'. 2) The customer wants to add new attributes to an existing mapping group. 3) The customer wants to perform complex changes, like removing, adding or changing existing groups/attributes, including various variables of a property like `scope` or `ignore_subtree`. Two ideas for some extensiblily come to mind: a) The declarative approach: files in /etc/univention/s4/mapping.d/ that allow for extensions and simple changes via some overwriting/inheritance scheme. Those files could define an `s4_mapping` dictionary that gets merged into the current one, adding new mapping groups or overwriting variables of the properties. This needs some thought as the customer may want to extend `attributes` and not simply overwrite it. 3) The functional approach: The user can supply a function that gets executed with the `s4_mapping` as an argument and performs transformations. We could supply a simple library for common operations and a guide on how to keep those transformations readable. Approach a) would be easier to understand but is also limited in its capabilities. Approach b) can lead to unreadable code, but supports all kinds of transformations. In either case, we should supply a simple command line tool, that performs the merging/transformations and outputs the final `s4_mapping` for debugability. a) sounds good
* our mapping goes to /usr/share/pyshared/univention/connector/
* by default the connector uses this mapping
* except there is a file /etc/univention/connector/ad/custom_mapping.py,
which then is used a source for the mapping definition
* the custom_mapping can just import our mapping and make the desired changes
import univention.connector.ad.mapping as mapping
print mapping.ad_mapping
mapping.ad_mapping['user'].post_attributes['newAttr'] = univention.connector.attribute(
ucs_attribute='newAttr',
ldap_attribute='newAttr',
con_attribute='newAttr',
)
del mapping.ad_mapping['user'].post_attributes['organisation']
return mapping.global_ignore_subtree, mapping.ad_mapping
* the resulting mapping is always written to /var/run/connector/mapping
and the connector uses this file
* after the update with an old /etc/univention/connector/ad/mapping, the
connector refuses to start until the old mapping
/etc/univention/connecto/ad/mapping is removed (converted to
/etc/univention/connector/ad/custom_mapping.py)
* additionally we should think about some versioning, maybe a "API" version
in our mapping. The custom mapping has to set the same version and if
they no longer match, the connector refuses to start or give some kind of
warning ....
It was not part of the voting process, so removing the target milestone. |