Univention Bugzilla – Bug 49463
Backup2master problem with Apps that deploy LDAP Schema locally
Last modified: 2020-03-10 09:27:00 CET
Steps to reproduce: Installing an app which provides a schema extension. Editing some LDAP objects to use this app which will add attributes to the LDAP object. De-installation of app as no longer needed. LDAP Schema extension is still available in LDAP by purpose (otherwise the object attributes would be invalid). Setting up a backup server, installing same packages and same versions of current installed master. This backup will replicate the schema extensions but will not have the local schema files installed (as the app is not installed any longer). Now doing backup2master and you will get couple of rejects or similar failures due to unknown attributes on the objects. Trying to filter them out through https://help.univention.com/t/problem-after-a-ldap-schema-was-removed-there-are-still-some-references-in-your-ldap/11810 will frequently bring other issues... We should make sure a backup2master will have the same LDAP schemas on the new master.
(In reply to Christian Völker from comment #0) > Setting up a backup server, installing same packages and same versions of > current installed master. This backup will replicate the schema extensions > but will not have the local schema files installed (as the app is not > installed any longer). I don't understand "will not have the local schema files installed"? They are not necessary because the listener should get them from the LDAP. Doesn't it do it? Which specific app/schema is affected?
(In reply to Florian Best from comment #1) > I don't understand "will not have the local schema files installed"? > They are not necessary because the listener should get them from the LDAP. > Doesn't it do it? > Which specific app/schema is affected? To be honest I do not know how the schema replication works. If there is a file missing or not. But what we have seen frequently in support is described above. The schema extension get lost during backup2master and the app has been removed before backup2master. Re-installing the app and removing it after brings back the schema extension. There is no specific app. We have seen this with Nextcloud, Bareos, Kopano and even CoolSolutions.
(In reply to Christian Völker from comment #2) > There is no specific app. We have seen this with Nextcloud, Bareos, Kopano > and even CoolSolutions. There are at least two ways to add a new LDAP schema to an UCS domain: 1. "old": add it to the local slapd.conf as include 2. "new": upload the schema to an UCS specific LDAP object and "let the listener do the job" For 1. we have some mitigations in the App Center integrations to automatically install Schema definitions also on DC Backup roles, but these can't cover all cases (like if the DC Backup is deployed after the App has been installed). So 2. is the better way and should be used by all Apps. My assumption is, that the described behaviour only occures for Apps using the "old" way 1. of deploying LDAP schemas. So what is needed here is to review which Apps use the old way 1. and initiate a migration to the variant 2.. A first step would be a reliable list of Apps that trigger(ed) this. As this is an issue to be covered in the App Center team I move the bug to the App Center component.
The following package based apps (with DefaultPackagesMaster) still use the old ucs_registerLDAPSchema 4.1/zarafa (ucs_registerLDAPSchema, EOL) 4.2/asterisk4ucs (slapd.conf template, EOL) 4.2/plucs (ucs_registerLDAPSchema) 4.4/fetchmail (ucs_registerLDAPSchema) 4.4/kopano-core (ucs_registerLDAPSchema) 4.4/openvpn4ucs (ucs_registerLDAPSchema) 4.4/ucc (ucs_registerLDAPSchema, EOL)
(In reply to Felix Botner from comment #4) > The following package based apps (with DefaultPackagesMaster) still use the > old ucs_registerLDAPSchema > > 4.1/zarafa (ucs_registerLDAPSchema, EOL) > 4.2/asterisk4ucs (slapd.conf template, EOL) > 4.2/plucs (ucs_registerLDAPSchema) > 4.4/fetchmail (ucs_registerLDAPSchema) > 4.4/kopano-core (ucs_registerLDAPSchema) > 4.4/openvpn4ucs (ucs_registerLDAPSchema) > 4.4/ucc (ucs_registerLDAPSchema, EOL) There are 4 of 7 apps that are either EOL or are not maintained anymore or respectively not available on UCS systems under maintenance. Do we need to switch the LDAP schema registration method for those apps, as well?
(In reply to Nico Gulden from comment #5) > There are 4 of 7 apps that are either EOL or are not maintained anymore or > respectively not available on UCS systems under maintenance. > > Do we need to switch the LDAP schema registration method for those apps, as > well? i guess not
(In reply to Nico Gulden from comment #5) > (In reply to Felix Botner from comment #4) > > The following package based apps (with DefaultPackagesMaster) still use the > > old ucs_registerLDAPSchema > > > > 4.1/zarafa (ucs_registerLDAPSchema, EOL) > > 4.2/asterisk4ucs (slapd.conf template, EOL) > > 4.2/plucs (ucs_registerLDAPSchema) > > 4.4/fetchmail (ucs_registerLDAPSchema) > > 4.4/kopano-core (ucs_registerLDAPSchema) > > 4.4/openvpn4ucs (ucs_registerLDAPSchema) > > 4.4/ucc (ucs_registerLDAPSchema, EOL) > > There are 4 of 7 apps that are either EOL or are not maintained anymore or > respectively not available on UCS systems under maintenance. > > Do we need to switch the LDAP schema registration method for those apps, as > well? I don't see a need to migrate discontinued Apps. But we need to find a solution for systems which have these Apps installed or had them installed in the past and still have the schema in place. I recommend a UMC system check which detects those schemas and a SDB article with a guide how to remove them.
ucs_registerLDAPSchema calls have been removed from Kopano Core, OpenVPN4UCS and Fetchmail. Those apps are no longer using it. The other apps are end-of-life and will not receive an update that removes those calls.
an SDB article to remove LDAP schemas already exists: https://help.univention.com/t/remove-ldap-schema-extensions/6443
Works for me as we built a diagnosis module: Bug #50889