While running an UCS appliance from 4.1-0 with selected Update, I observed that apache was stopped somewhere during the update. The apache package status was at this time: > iU apache2-mpm-prefork 2.2.22-13.95.201603212007 amd64 Apache HTTP Server - traditional non-threaded model > ii apache2-suexec 2.2.22-13.95.201603212007 amd64 Standard suexec program for Apache 2 mod_suexec > iU apache2-utils 2.2.22-13.95.201603212007 amd64 utility programs for webservers > iU apache2.2-bin 2.2.22-13.95.201603212007 amd64 Apache HTTP Server common binary files > iU apache2.2-common 2.2.22-13.95.201603212007 amd64 Apache HTTP Server common files > ii libapache2-mod-auth-pam 1.1.1-9.27.201408261725 amd64 module for Apache2 which authenticate using PAM > ii libapache2-mod-php5 5.4.45-0.216.201510081527 amd64 server-side, HTML-embedded scripting language (Apache 2 module) > iU univention-apache 8.0.1-6.256.201601140838 all UCS - Apache2 configuration
Created attachment 7957 [details] Screenshot of the setup wizard session with JS console Here the message that is shown in the wizard.
Created attachment 7958 [details] /var/log/univention/updater.log
Created attachment 7959 [details] /var/log/univention/setup.log
Below an excerpt from updater.log ... it seems that we need to do something about the maintainer scripts of apche2-mpm-prefork: ---------- 8< ---------- [...] Unpacking replacement openssh-client ... Preparing to replace apache2-mpm-prefork 2.2.22-13.93.201510081517 (using .../apache2-mpm-prefork_2.2.22-13.95.201603212007_amd64.deb) ... Stopping web server: apache2 ... waiting . Unpacking replacement apache2-mpm-prefork ... Preparing to replace apache2.2-common 2.2.22-13.93.201510081517 (using .../apache2.2-common_2.2.22-13.95.201603212007_amd64.deb) ... Unpacking replacement apache2.2-common ... [...] Setting up apache2.2-common (2.2.22-13.95.201603212007) ... Installing new version of config file /etc/init.d/apache2 ... Setting up apache2-mpm-prefork (2.2.22-13.95.201603212007) ... Starting web server: apache2. Setting up curl (7.26.0-1.63.201510202222) ... [...] ---------- 8< ----------
Apache is stopped in the prerm script and started in the postinst script.
Created attachment 7967 [details] /var/log/univention/updater.log
Created attachment 7968 [details] /var/log/univention/setup.log
(In reply to Alexander Kläser from comment #5) > Apache is stopped in the prerm script and started in the postinst script. PLEASE READ Bug #41203 comment 2 BEFORE EVER MUCKING WITH APACHE AGAIN!
(In reply to Philipp Hahn from comment #8) > (In reply to Alexander Kläser from comment #5) > > Apache is stopped in the prerm script and started in the postinst script. > > PLEASE READ Bug #41203 comment 2 BEFORE EVER MUCKING WITH APACHE AGAIN! As discussed, apache will surely run into problems if not being stopped in its prerm and started in its postinst after all of its dependencies have been updated. Other alternatives: * Access via JavaScript the UMC web server directly at its specific port. * Try to re-route traffic to port 80 to UMC web server directly.
(In reply to Alexander Kläser from comment #9) > Other alternatives: > * Access via JavaScript the UMC web server directly at its specific port. The port is not exposed to the outside as the socket is bound to the 'lo' interface. Also in 4.2 this would bypass some security relevant HTTP response headers. And the UMC-Webserver expects to be behind a reverse proxy. The UMC-Webserver is also not available via HTTPS.
See Ticket#2016092721000105, the user was logged out during the setup process and during.
(In reply to Alexander Kläser from comment #11) > See Ticket#2016092721000105, the user was logged out during the setup > process and during. Hm, I don't think that the ticket is this bug. He spoke about session timeout and not about attachment 7957 [details].
It shouldn't affected so many users since we don't have a appliance on UCS 4.1-0 basis. But it is still an important issue because it will always happen if we release a new Apache Erratum, right?
Could this be a duplicated of Bug 42865?
(In reply to Alexander Kläser from comment #14) > Could this be a duplicated of Bug 42865? I don't think so. The session timeout has nothing to do with Apache. But the problem might be similar: instead of that Apache is restarted the UMC-Webserver is restarted and all sessions lost → Our login dialog / authentication handling should be able to solve this.
To avoid these problems, we could update the apache package in the preup script. That would be a fairly simple workaround which also could be applied to 4.1-x releases.
(In reply to Stefan Gohmann from comment #13) > It shouldn't affected so many users since we don't have a appliance on UCS > 4.1-0 basis. > > But it is still an important issue because it will always happen if we > release a new Apache Erratum, right? Yes, if we publish an erratum for apache, we will run into this problem again for people who are updating during the setup process. If the update consists of few packages, it will not be a problem. However, if the update takes several minutes, we will have the same problem.
(In reply to Alexander Kläser from comment #16) > To avoid these problems, we could update the apache package in the preup > script. That would be a fairly simple workaround which also could be applied > to 4.1-x releases. Note that preup probably will not work if an apache update is published as erratum. Another workaround could then be to define a pre-depends to apache2 for the package univention-management-console. However, this will only work if there is an update for univention-management-console and apache2 at the same time.
As discussed, technically it is not a problem that the Apache is stopped during the update. This is rather a usability problem as it might irritate a user to wait 5-15min with a progress bar being at 95% and nothing happens. Therefore, I remove the errata milestone.
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.