Univention Bugzilla – Bug 39159
univention-system-activation: No frontend action/redirect after license upload
Last modified: 2015-08-20 13:16:26 CEST
Created attachment 7101 [details] webpage after license upload Tested with chromium 43.0.2357.130 and firefox 39.0.3 on a UCS 4.0-3 univention-app. If i upload a license file on the activation page, the loading animation plays and an empty red error box appears. I do not get redirected. Browser stays on 2nd 'step' of the wizard. system-activation-error.log: [Wed Aug 12 16:30:18 2015] [notice] Graceful restart requested, doing restart [Wed Aug 12 16:30:18 2015] [error] (9)Bad file descriptor: apr_socket_accept: (client socket) The activation seems to work, if i access http://<ucs-ip>/, the ucs-overview is presented.
I debugged this against an older working app appliance, some differences: - The "POST /license HTTP/1.1" never shows up in any apache.log, subsequently the browser never gets an answer to the POST request - On the non-working appliance, apache2/error.log contains [warn] pid file /var/run/apache2.pid overwritten -- Unclean shutdown of previous Apache run? This indicates that the apache2 process handling the license might have been killed. To me, it seems that there is a timing issue, because apache gets reloaded by the wsgi.py script - that seems like a bad idea in general. If i remove the apache2 reload in /usr/sbin/univention-system-activation, the license upload works
(In reply to Erik Damrose from comment #1) > ... > To me, it seems that there is a timing issue, because apache gets reloaded > by the wsgi.py script - that seems like a bad idea in general. If i remove > the apache2 reload in /usr/sbin/univention-system-activation, the license > upload works Good catch! I assume that line 58 in univention-system-activation should then be exchanged: > subprocess.check_call(['/usr/bin/sudo', '/usr/sbin/univention-system-activation', 'stop'], stderr=subprocess.STDOUT) This call could be replaced with a at-job in order to delay the apache restart. We have an at-job lib that could be employed: > from univention.lib import atjobs as atjobs > import datetime > execTime = datetime.datetime.now() + datetime.timedelta(0, 1) # one second after now > atjobs.add('/usr/bin/sudo /usr/sbin/univention-system-activation stop', execTime) The at-job should retain the current user ID, thus AFAIS right now this call should be fine.
As discussed, please implement the at-job and modify the last system activation wizard page: After clicking on the redirect button, a small sleep should be implemented, so that we do not redirect while apache is restarting.
(In reply to Erik Damrose from comment #3) After clicking on the redirect button, a small sleep > should be implemented, so that we do not redirect while apache is restarting. Done! If one clicks the continue button on the last wizard page - it will be checked if the start page is reachable and so the apache server. If apache isn't up the script will try it again every 500ms. After 10sec a error msg will be displayed that the user should restart the machine. FYI: For testing, I just used #finished to go to the last page und stopped apache2. After 10secs I got the error. Also tried to restart apache2 within the ten secs. Worked fine. ucs 4.0-3 r63014 patch / debian changelog Successful build Package: univention-system-activation Version: 0.0.1-33.31.201508141435 Branch: ucs_4.0-0 Scope: errata4.0-3 r63015 ymal file ----- ucs 4.1-0 r 63016 patch / debian changelog Successful build Package: univention-system-activation Version: 1.0.0-3.32.201508141455 Branch: ucs_4.1-0 Scope:
(In reply to Erik Damrose from comment #3) > As discussed, please implement the at-job ucs 4-0-3 r63056 - added a delay for stopping the process so it is enough time to send the last response - adapted the last wizard page = disable the continue button and show an loading animation Successful build Package: univention-system-activation Version: 0.0.1-34.33.201508171528 Branch: ucs_4.0-0 Scope: errata4.0-3 r63058 yam file ucs 4.1-0 r63057 Successful build Package: univention-system-activation Version: 1.0.0-4.34.201508171535 Branch: ucs_4.1-0 Scope: fyi: as discussed with Alex. An atjob wasn't possible because - there isn't an option to set seconds - the current user hasn't the permissions to use at
Created attachment 7111 [details] Proposed adjustment... Alex, I just thought that the attached adjustment should make sure that the subprocess will not be killed too early (just in case).
(In reply to Alexander Kläser from comment #6) > Created attachment 7111 [details] > Proposed adjustment... > > Alex, I just thought that the attached adjustment should make sure that the > subprocess will not be killed too early (just in case). Ty for the patch. As requested I applied the changes. UCS4.0-3 r63067 Successful build Package: univention-system-activation Version: 0.0.1-35.35.201508180816 Branch: ucs_4.0-0 Scope: errata4.0-3 r63069 yaml file UCS4.1 r63068 Successful build Package: univention-system-activation Version: 1.0.0-5.36.201508180824 Branch: ucs_4.1-0 Scope:
Reopen: In my tests this did not work very well. By waiting a bit before restarting apache, the current fix mitigates the issue of the http response not arriving, but opens up another timing issue. In my test i uploaded a license file and clicked on 'Continue'. I was redirected to the first page of the system activation screen, instead of the UMC login page. It seems that the system activation page was still active, as i saw the following http requests in system-activation.log: 192.168.0.252 - - [18/Aug/2015:17:21:10 +0200] "GET /univention-management-console?username=Administrator HTTP/1.1" 302 192.168.0.252 - - [18/Aug/2015:17:21:10 +0200] "GET /?username=Administrator HTTP/1.1" 200 The javascript on the last page has to make sure that apache has been reloaded successfully, system activation is gone and the UMC is reachable.
(In reply to Erik Damrose from comment #8) > 192.168.0.252 - - [18/Aug/2015:17:21:10 +0200] "GET > /univention-management-console?username=Administrator HTTP/1.1" 302 > > 192.168.0.252 - - [18/Aug/2015:17:21:10 +0200] "GET /?username=Administrator > HTTP/1.1" 200 > > The javascript on the last page has to make sure that apache has been > reloaded successfully, system activation is gone and the UMC is reachable. As requested I made the JS check more strict, but this did not solve the problem. Anyway still a good idea. The 'problem' was a apache redirect inside to conf file for univention-system-activation. This is the reason for the 302 followed by a 200 status code. IMHO the redirect isn't necessary, so I removed it and now you will get an 404 and the JS will try it again to reach the umc for the next 10 secs. UCS4.0-3 r 63096 UCS4.1-0 r 63097 / 63098
Successful build Package: univention-system-activation Version: 0.0.1-36.37.201508191000 Branch: ucs_4.0-0 Scope: errata4.0-3 r 63099 yaml file Successful build Package: univention-system-activation Version: 1.0.0-6.38.201508191004 Branch: ucs_4.1-0 Scope:
Reopen: As discussed, the JS wait has to be increased to take slow systems into account.
(In reply to Erik Damrose from comment #11) > Reopen: As discussed, the JS wait has to be increased to take slow systems > into account. Done, also made a minor text adaption of #finished page ucs 4.0-3 r 63104 Successful build Package: univention-system-activation Version: 0.0.1-37.39.201508191145 Branch: ucs_4.0-0 Scope: errata4.0-3 r 63106 yaml file --- ucs4.1-0 r 63105 Successful build Package: univention-system-activation Version: 1.0.0-7.40.201508191150 Branch: ucs_4.1-0 Scope:
Ok, looks good now! r63114 update yaml OK: Mitigated timing issue OK: Merge to UCS 4.1 OK: Yaml -> Verified
<http://errata.univention.de/ucs/4.0/287.html>