Univention Bugzilla – Bug 47944
Add settings/data udm module
Last modified: 2019-03-16 18:48:31 CET
The UDM module is intended to hold binary or text blobs, that can be used to store source/binary code in LDAP. It will be used to distribute univention-join hooks in the domain. Code is in oschwieg/4.3-2/47944
The module/LDAP object should also contain a "package version" (like e.g. registered LDAP schema). Then we can use ucs_registerLDAPextension to install only newer versions of the code blob. If a package with an older package version tries to change/register the blob, ucs_registerLDAPExtension will not change the LDAP.
Please create cn=code,cn=univention,$LDAP_BASE during update/installation.
(In reply to Sönke Schwardt-Krummrich from comment #2) > The module/LDAP object should also contain a "package version" (like e.g. > registered LDAP schema). Then we can use ucs_registerLDAPextension to > install only newer versions of the code blob. If a package with an older > package version tries to change/register the blob, ucs_registerLDAPExtension > will not change the LDAP. 2c83d0b2c2 Bug #47944: add "package" and "packageversion" properties (In reply to Sönke Schwardt-Krummrich from comment #3) > Please create cn=code,cn=univention,$LDAP_BASE during update/installation. 0249f8adc0 Bug #47944: create container for settings/code objects Built univention-ldap and univention-directory-manager-modules in: Branch: ucs_4.3-0 Scope: ucs-school-setup
settings/code was renamed to settings/data. The LDAP attributes and UDM properties have been adapted. A property "filename" was added. 56dfbfcfb4 Bug #47944: rename settings/code to settings/data
Added a test to verify ucs_registerLDAPExtension operations. c926f4a5fc Bug #47944: add test for settings/data using ucs_registerLDAPExtension → ucs_registerLDAPExtension doesn't support "description" property → ucs_registerLDAPExtension doesn't support multiple "--data_meta" arguments TODO: adapt version of univention-ldap-config dependency in debian/control after merging to 4.3-2.
Sönke will add the code for "description" and "--data_meta".
Please also make it possible to set the name. Currently it is automatically set to the filename, and that means that the same file cannot be registered more than once.
(In reply to Daniel Tröder from comment #8) > Please also make it possible to set the name. > Currently it is automatically set to the filename, and that means that the > same file cannot be registered more than once. I understand where you're going with this, but I haven't yet formed a final opinion about the following: All other LDAP objects created with ucs_registerLDAPExtension get their name from the filename used as data source. We would now implement a different/unanticipated behavior here. Do we want that? Until now, a file name for a UDM module, for example, could only be imported once. If you want to bring the module for 2 different UCS version ranges (4.1<=x<=4.2 and 4.3<=x<=4.4), you also have to use 2 different file names. This can have advantages, because e.g. in the file system it is immediately clear which version is still lying around, but also disadvantages, if it must be a certain file name.
I have now used it like this: 1) cp $FILENAME /tmp/$FILENAME.$(hostname -f) 2) register_ldap... --data "/tmp/$FILENAME.$(hostname -f)" ... That's finde for me, as I don't intend to find the correct object by name anyway. I filter using attributes "packagename", "data_type" and "data_meta".
Bug #40609 depends on this, as settings/data objects are used there to distribute public RSA keys for UCS mail servers in the domain.
(In reply to Daniel Tröder from comment #10) > I have now used it like this: > > 1) cp $FILENAME /tmp/$FILENAME.$(hostname -f) > 2) register_ldap... --data "/tmp/$FILENAME.$(hostname -f)" ... I think this is currently the best solution. The object name is currently derived from the filename. If we separate filename and object name, we will have problems with the update mechanism. > That's finde for me, as I don't intend to find the correct object by name > anyway. > I filter using attributes "packagename", "data_type" and "data_meta". I don't think you should filter for the package name. Because what you want to find should be uniquely identified by the DataType and possibly by the meta data. If the package name is included in the search, it will become much more difficult later to register data of the same type in other packages or even manually. packagename and packageversion are currently only required to determine if an update of the LDAP object is required. If the search is done manually, the objectclass should be part of the filter. At the moment it is not quite clear whether we can automatically extend the LDAP indexes in an erratum. If this is not the case and we can only extend the index with UCS 4.3-3, the LDAP filter should be selected so that as few objects as possible have to be found and opened to determine the result list.
(In reply to Sönke Schwardt-Krummrich from comment #12) > > I filter using attributes "packagename", "data_type" and "data_meta". > > I don't think you should filter for the package name. Because what you want > to find should be uniquely identified by the DataType and possibly by the > meta data. If the package name is included in the search, it will become > much more difficult later to register data of the same type in other > packages or even manually. Actually that's the reason I included "packagename" in the filter. I understand "data_type" as a category and in my case it is "RSA_public_key". I expect other packages to use the same category, but I don't want to use their keys. So I filter with "packagename=univention-mail-server" to get only "my" keys: ldap_filter = ( '(&' '(objectClass=univentionData)' '(univentionDataType=RSA_public_key)' '(univentionOwnedByPackage=univention-mail-server)' ')' )
(In reply to Daniel Tröder from comment #13) > (In reply to Sönke Schwardt-Krummrich from comment #12) > > > I filter using attributes "packagename", "data_type" and "data_meta". > > > > I don't think you should filter for the package name. Because what you want > > to find should be uniquely identified by the DataType and possibly by the > > meta data. If the package name is included in the search, it will become > > much more difficult later to register data of the same type in other > > packages or even manually. > Actually that's the reason I included "packagename" in the filter. > I understand "data_type" as a category and in my case it is "RSA_public_key". > I expect other packages to use the same category, but I don't want to use > their keys. So I filter with "packagename=univention-mail-server" to get > only "my" keys: > > ldap_filter = ( > '(&' > '(objectClass=univentionData)' > '(univentionDataType=RSA_public_key)' > '(univentionOwnedByPackage=univention-mail-server)' > ')' > ) I think by using "(univentionDataType=RSA_public_key)" the search/the object is insufficiently specified. I would suggest something like univentionDataType=mail/signing/RSA_public_key This way, the customer and other packages (e.g. 3rd party packages) are able to register additional keys (for a good reason). And each package (or the customer) is able to update the data objects in a sane way.
(In reply to Daniel Tröder from comment #7) > Sönke will add the code for "description" and "--data_meta". To keep the API identical to all other objects that may be registered via ucs_registerLDAPExtension, "description" may not be set via ucs_registerLDAPExtension. But I implemented --data_meta which may be specified multiple times. The ucs-test has been adapted accordingly. The branches school/samba_vereinfachung and oschwieg/4.3-2/47944 are now in sync regarding ldap_extensions.py.
We suggest to use data_type like this: $context/$thing for example "mail/sendercheck/rsa_key" or "join/pre-joinscript" "join/post-joinscript" "join/pre-join" To be honest, the data_type is not checked by the UDM module, but using a naming scheme similar to UCR variables helps to subdivide and categorize large amounts of settings/data objects.
PS: both univentionDataType and univentionDataMeta have: EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch
Looks good so far to me. Please build the packages so I can do the final QA.
[4.3-2] 13ca7e0c19 Bug #47944: Merge branch 'oschwieg/4.3-2/47944' into 4.3-2 [4.3-2] 4e0da28cd1 Bug #47944: update dependencies [4.3-2] 523820228d Bug #47944: update dependencies [4.3-2] 58351e4ad4 Bug #47944: advisories univention-lib 7.0.0-14A~4.3.0.201811191459 univention-ldap 14.0.2-29A~4.3.0.201811191500 univention-directory-manager-modules 13.0.25-18A~4.3.0.201811191502 ucs-test can currently not be build, because of Bug #48182.
According to Bug 48182 this commit causes a regression: [4.3-2] 4e0da28cd1 Bug #47944: update dependencies
(In reply to Arvid Requate from comment #20) > According to Bug 48182 this commit causes a regression: > > [4.3-2] 4e0da28cd1 Bug #47944: update dependencies The problem has been identified and split into a separate bug (Bug #48182) which blocks this one. The fix will have to be released together with this bug.
Advisory & Changelog: OK settings/data object with expected values available: OK register ldap extension accepts multiple meta fields: OK tests run: OK
(In reply to Daniel Tröder from comment #21) > (In reply to Arvid Requate from comment #20) > > According to Bug 48182 this commit causes a regression: > > > > [4.3-2] 4e0da28cd1 Bug #47944: update dependencies > The problem has been identified and split into a separate bug (Bug #48182) > which blocks this one. The fix will have to be released together with this > bug. If I see this correctly, the YAML files do not prevent this. Blocking bugs in Bugzilla is not enough. That's why I open this bug again so that an erratum is not accidentally published.
If I read Bug #48182#c5 correctly, you have removed the dependency and this erratum can be released. So, I'm setting this bug back to verified and set the flags of Bug #48182.
(In reply to Stefan Gohmann from comment #24) > If I read Bug #48182#c5 correctly, you have removed the dependency and this > erratum can be released. So, I'm setting this bug back to verified and set > the flags of Bug #48182.
<http://errata.software-univention.de/ucs/4.3/355.html> <http://errata.software-univention.de/ucs/4.3/356.html> <http://errata.software-univention.de/ucs/4.3/357.html>