Univention Bugzilla – Bug 45220
Add hook for appending to the S4 Connector mapping
Last modified: 2019-10-23 13:20:34 CEST
The mapping of the S4-Connector is currently a configfile managed by us. Customers shouldn't edit it but they are. We should add a hook mechanism to make it extensible without copying the file.
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.
*** This bug has been marked as a duplicate of bug 48410 ***