Univention Bugzilla – Bug 43006
Pre-checks for univention-join
Last modified: 2019-01-03 07:19:32 CET
Currently there is no possibility to perform some checks *before* the actual join process starts. Cause of this requirement: there are situations where the joining system wants to check the environment it is joining in, e.g. check if the master has a matching/compatible UCS/UCS@school version. Especially in case of a rejoin the pre-checks are important → when using an early join script (e.g. 00_aaaa.inst) the join process has already been started and changes have been made to LDAP and/or local system (changed password of machine account). It would be great if univention-join would perform pre-checks on the backup/slave/memberserver AND on the UCS master. So the slave is able to abort joining if the master/environment is not suitable and the master is also able to prevent the join if the slave is not suitable for joining. In UCS@school it would be possible to prevent (re)join attempts from outdated/incompatible UCS@school slaves.
The system-setup join process would also benefit from a generic mechanism before joining. Fixing this is the base for Bug #42769, Bug #42918, Bug #42910, Bug #42911, Bug #42911, Bug #42430, Bug #42425, Bug #42124, Bug #42022, Bug #42021, Bug #42020.
We could allow join-scripts to be run with a --check option to allow an extensible mechanism of pre-checks.
(In reply to Alexander Kläser from comment #2) > We could allow join-scripts to be run with a --check option to allow an > extensible mechanism of pre-checks. Just adding --check would be an API change and not backwards compatible. Because the current joinscripts don't evaluate --check and would therefore run the while script. Joinscripts could have a flag which shows that they support --check. BUT I think this is ugly and unnecessary. We should instead just run-parts a specific directory where the pre-checks lie. Then the checks aren't directly in the joinscript (the debian package still can ship the checks which are specific to a joinscript) and the checks can be written in python/bash/whatever-you-like but don't have to be in joinscript-bash.
(In reply to Florian Best from comment #3) > Just adding --check would be an API change and not backwards compatible. > Because the current joinscripts don't evaluate --check and would therefore > run the while script. Joinscripts could have a flag which shows that they > support --check. BUT I think this is ugly and unnecessary. IMHO specifying the checkability via a flag similar to "CHECK_SUPPORTED=1" as 2nd line in the script or via a comment seems to be a valid and pragmatic option to me. > We should instead just run-parts a specific directory where the pre-checks > lie. Then the checks aren't directly in the joinscript (the debian package > still can ship the checks which are specific to a joinscript) and the checks > can be written in python/bash/whatever-you-like but don't have to be in > joinscript-bash. This is also fine.
This issue has been filled against UCS 4.1. The maintenance with bug and security fixes for UCS 4.1 has ended on 5st of April 2018. Customers still on UCS 4.1 are encouraged to update to UCS 4.3. Please contact your partner or Univention for any questions. If this issue still occurs in newer UCS versions, please use "Clone this bug" or simply reopen the issue. In this case please provide detailed information on how this issue is affecting you.