Univention Bugzilla – Full Text Bug Listing |
Summary: | ntpdate by u-system-setup-base/40_ssl/10ssl causes fatal UMC process exit and breaks whole system | ||
---|---|---|---|
Product: | UCS | Reporter: | Philipp Hahn <hahn> |
Component: | UMC (Generic) | Assignee: | Janek Walkenhorst <walkenhorst> |
Status: | CLOSED FIXED | QA Contact: | Stefan Gohmann <gohmann> |
Severity: | normal | ||
Priority: | P5 | CC: | best, gohmann, klaeser |
Version: | UCS 3.2 | ||
Target Milestone: | UCS 3.2-2-errata | ||
Hardware: | Other | ||
OS: | Linux | ||
See Also: | https://forge.univention.org/bugzilla/show_bug.cgi?id=27918 | ||
What kind of report is it?: | --- | What type of bug is this?: | --- |
Who will be affected by this bug?: | --- | How will those affected feel about the bug?: | --- |
User Pain: | Enterprise Customer affected?: | ||
School Customer affected?: | ISV affected?: | ||
Waiting Support: | Flags outvoted (downgraded) after PO Review: | ||
Ticket number: | Bug group (optional): | ||
Max CVSS v3 score: |
Description
Philipp Hahn
2014-02-11 23:52:16 CET
1. 40_ssl/10ssl needs to call rdate right now to prevent the generation of invalid SSL certificates, see Bug #13549 2. As UMC uses python-notifier for testing timeouts, and python-notifier uses wall-clock time, a switch to "monotonic clock" would be difficult. Instead, UMC module processes will not die by timeout anymore if the time delta is bigger then one and a half the timeout, which can be considered a safe hint for the fact that something went wrong. 3. U-S-S will now directly write the setup script output to it's log and watch the file end for new content, as suggested. I've tested the progress bar after theses changes without being able to find any problems with them. SIGPIPES should not occur anymore. svn 51039 (In reply to Lukas Walter from comment #1) > 1. 40_ssl/10ssl needs to call rdate right now to prevent the generation of > invalid SSL certificates, see Bug #13549 > > 2. As UMC uses python-notifier for testing timeouts, and python-notifier > uses wall-clock time, a switch to "monotonic clock" would be difficult. > Instead, UMC module processes will not die by timeout anymore if the time > delta is bigger then one and a half the timeout, which can be considered a > safe hint for the fact that something went wrong. Would it not be easier to adjust the timer similarly to the timer in the UMC web server, i.e., register a timer every 1sec that counts down the timeout? The check for 1.5 * self.__timeout might still leave cases where the problem occurs (although the probability of theses cases to happen is much lower, indeed), and this would then be really awkward to debug + understand, IMHO. > 3. U-S-S will now directly write the setup script output to it's log and > watch the file end for new content, as suggested. I've tested the progress > bar after theses changes without being able to find any problems with them. > SIGPIPES should not occur anymore. Which kind of problem does this adjustment solve exactly? (In reply to Alexander Kläser from comment #2) > (In reply to Lukas Walter from comment #1) > > 1. 40_ssl/10ssl needs to call rdate right now to prevent the generation of > > invalid SSL certificates, see Bug #13549 > > > > 2. As UMC uses python-notifier for testing timeouts, and python-notifier > > uses wall-clock time, a switch to "monotonic clock" would be difficult. > > Instead, UMC module processes will not die by timeout anymore if the time > > delta is bigger then one and a half the timeout, which can be considered a > > safe hint for the fact that something went wrong. > > Would it not be easier to adjust the timer similarly to the timer in the UMC > web server, i.e., register a timer every 1sec that counts down the timeout? > The check for 1.5 * self.__timeout might still leave cases where the problem > occurs (although the probability of theses cases to happen is much lower, > indeed), and this would then be really awkward to debug + understand, IMHO. Implemented. In addition, the USS module will no more return successfull execution before even processing the request, which will keep the USS module process from terminating by timeout while there are still requests to be processed, as UMC module processes do not time out with remaining active requests (svn 51088) > > 3. U-S-S will now directly write the setup script output to it's log and > > watch the file end for new content, as suggested. I've tested the progress > > bar after theses changes without being able to find any problems with them. > > SIGPIPES should not occur anymore. > > Which kind of problem does this adjustment solve exactly? This prevents the currently running setup script from receiving SIGPIPE when the USS module process dies for some reason. Before, the USS module process read the STDOUT/STDERR of each executed setup script via pipe, which always results in SIGPIPEs for the writing process (the setup scripts) if no reader is left at the other side. When running univention-system-setup-boot on an unjoined 3.2 UCS with large (2 year) time behind upstream does not lead to the same errors as without the fixes. But when starting the configuration process a dialog pops up immediately saying the configuration process was completed, although the progress bar is still showing and the setup scripts are still running. Also there are still SIGPIPE-errors in the setup.log: […] Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []:An optional company name [Univention GmbH]:yes: Standardausgabe: Datenübergabe unterbrochen (broken pipe) yes: Schreibfehler Using configuration from openssl.cnf Check that the request matches the signature Signature ok […] Interestingly the files in /etc/univention/ssl do exist. Additionally the UMC does not show most modules, but this might be unrelated. I do not understand the following line in the YAML file: * Request successfull request processing will not be reported before the actual request processing anymore. (In reply to Alexander Kläser from comment #5) > I do not understand the following line in the YAML file: > > * Request successfull request processing will not be reported before the > actual > request processing anymore. Reworded. (In reply to Janek Walkenhorst from comment #4) > When running univention-system-setup-boot on an unjoined 3.2 UCS with large > (2 year) time behind upstream does not lead to the same errors as without > the fixes. > > But when starting the configuration process a dialog pops up immediately > saying the configuration process was completed, although the progress bar is > still showing and the setup scripts are still running. With the other changes to u-s-s-boot the system setup works when the time is changed. Well, there is still a typo in the YAML "Successfull" → Successful. Also i wouldn't write that implementation detail but more something which is related to the bug title. (In reply to Florian Best from comment #7) > Well, there is still a typo in the YAML "Successfull" → Successful. Fixed. YAML: OK Code review: OK - univention-system-setup: OK - univention-management-console: OK Tests: OK date -s "$(LC_ALL=C date -d '2 years ago')" mv /etc/univention/ssl /etc/univention/ssl.BAK /var/lib/dpkg/info/univention-ssl.postinst /etc/init.d/univention-system-setup-boot start |