Univention Bugzilla – Full Text Bug Listing |
Summary: | stunnel4 does not start on slave, member, basesystem roles due to unknown user samlcgi | ||
---|---|---|---|
Product: | UCS | Reporter: | Erik Damrose <damrose> |
Component: | General | Assignee: | Jürn Brodersen <brodersen> |
Status: | CLOSED FIXED | QA Contact: | Erik Damrose <damrose> |
Severity: | normal | ||
Priority: | P5 | CC: | best, brodersen, grandjean, heidelberger, michelsmidt, thorsten.strusch |
Version: | UCS 4.3 | ||
Target Milestone: | UCS 4.3-2-errata | ||
Hardware: | Other | ||
OS: | Linux | ||
What kind of report is it?: | Bug Report | What type of bug is this?: | 5: Major Usability: Impairs usability in key scenarios |
Who will be affected by this bug?: | 2: Will only affect a few installed domains | How will those affected feel about the bug?: | 4: A User would return the product |
User Pain: | 0.229 | Enterprise Customer affected?: | |
School Customer affected?: | Yes | ISV affected?: | |
Waiting Support: | Flags outvoted (downgraded) after PO Review: | ||
Ticket number: | Bug group (optional): | ||
Max CVSS v3 score: |
Description
Erik Damrose
2018-06-26 17:23:09 CEST
This means, that stunnel4 can not be used on UCS Slaves and Memberservers, but is often needed in scenarios like this one: https://www.univention.de/2018/06/how-to-fuer-anbindung-von-webuntis-an-ucsschool-fuer-single-sign-on-anmeldungen/ The log entries when trying to start stunnel4 look like this on a system with german locales: > Jun 26 16:34:59 slave01 systemd[1]: Starting LSB: Start or stop stunnel 4.x (TLS tunnel for network daemons)... > Jun 26 16:34:59 slave01 stunnel4[10535]: Starting TLS tunnels:install: Ungültiger Anwender „samlcgi“ > Jun 26 16:34:59 slave01 systemd[1]: stunnel4.service: Control process exited, code=exited status=1 > Jun 26 16:34:59 slave01 systemd[1]: Failed to start LSB: Start or stop stunnel 4.x (TLS tunnel for network daemons). > Jun 26 16:34:59 slave01 systemd[1]: stunnel4.service: Unit entered failed state. > Jun 26 16:34:59 slave01 systemd[1]: stunnel4.service: Failed with result 'exit-code'. This hit me again today. Please remove the patch for stunnel4 and move the logic to univention-saml. I just want to emphasize: since /var/run/ is a tmpfs, /var/run/univention-saml needs to be created on every boot. So even if we apply the workaround from comment #0 this only works until the next reboot. The creation of /var/run/univention-saml has been moved into the univention-saml package. The init script patch for stunnel4 has been removed. r18272: Bug #47250: Runtime directory is now created in the univention-saml package. [4.3-2 a8ec345196] Bug #47250: Create runtime directory for stunnel [4.3-2 65b55bd387] Bug #47250: Merge branch 'juern/bug47250' into 4.3-2 [4.3-2 ed848310f7] Bug #47250: YAML Sorry I didn't need to delete the patch. The errata release has its own patch folder. r18274: Bug #47250: revert patch deletion (wrong folder) OK: stunnel4 patch removed, package rebuild OK: stunnel4: installable and running on slave+member after package installation; no adaptions required. OK: /var/run/univention-saml created by u-saml package, with correct permissions OK: u-saml package update. Tunnel works after package update OK: no failing tests OK: yaml files stunnel4 + univention-saml Verified |