Univention Bugzilla – Bug 43626
apache2 reload/restart does not work during system-setup
Last modified: 2017-04-04 18:29:03 CEST
Created attachment 8454 [details]
relevant part from setup.log:
2017-02-23 14:02:28.553893483+01:00 (in joinscript_init)
E: object not found
Object created: SAMLServiceProviderIdentifier=https://master.ucs.local/univention/saml/metadata,cn=saml-serviceprovider,cn=univention,dc=ucs,dc=local
Object modified: SAMLServiceProviderIdentifier=https://master.ucs.local/univention/saml/metadata,cn=saml-serviceprovider,cn=univention,dc=ucs,dc=local
Not updating ucs/server/sso/fqdn
Reloading web server: apache2 failed!
Apache2 is not running ... (warning).
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
^M 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0curl: (7) Failed to connect to ucs-sso.ucs.local port 443: Verbindungsaufbau abgelehnt
nameserver1 was set to the dns forwarder, not the ucs master itself. We should wait for bug 43217 before looking into it, maybe the issue is resolved with 43217 fixed
The apache2 config should be reloaded in the joinscript, but that does not happen, so the curl call fails, as is seen in the comment0 log snippet.
Throughout the setup.log every apache2 restart/reload fails this way, until the 99_restart_umc restarts apache2 successfully. First occurrence is at 40_ssl/10ssl
Seems to be a regression, previously there was an explicit apache2 restart somewhere - some joinscript? I added an apache2 restart in setup-join.sh after the host certificate is created. Also: certificate for the default FQDN "unassigned-hostname.unassigned-domain" is ignored during 40_ssl/10ssl --force-recreate
r77126 univention-system-setup 10.0.7-11A~18.104.22.168702271540
In my implicit tests with DVDs in the last days, this did not lead to any issues, so RESOLVED for now. I added a changelog entry:
reopen: breaks reading of installation status on roles != master. I think the restart should be moved to the ssl reconfiguration step on the master.
I moved the check upwards to the role = master specific check. Lets see what effect that has for the SSO joinscripts on other system roles.
Another change after discussing this:
I removed the role specific "univention-certificate new", as this only runs on the master, but directly above that is (abbreviated):
if [ "$server_role" = "domaincontroller_master" ]; then
.. which recreates the CA and all previously created host certificates
r77654 univention-system-setup 10.0.8-4A~22.214.171.124703131724
It looks like it breaks the Jenkins tests. Attached you can find the Jenkins logfile of a Master / Member setup which seems to be in a endless loop.
The /etc/univention/ssl directory looks like this:
root@master096:~# ls -la /etc/univention/ssl/
drwxr-xr-x 3 root root 4096 Mär 13 18:50 .
drwxr-xr-x 11 root root 4096 Mär 13 18:52 ..
-rw------- 1 root root 2813 Mär 13 18:50 openssl.cnf
-rw------- 1 root root 20 Mär 13 18:50 password
drwxr-xr-x 6 root root 4096 Mär 13 18:51 ucsCA
I'll revert r77654 and restart the Jenkins tests.
Created attachment 8527 [details]
* Re-added the duplicated certificate renewal (Bug #43626)
I assumed the master certificate would be (re-)created in the 10ssl setup script, but it did not.
I moved the initial master certificate creation into the dc-master specific codepath in setup-join.sh
r77680 univention-system-setup 10.0.9-2A~126.96.36.199703141036
Quick test with DC Master and Backup worked.
Code review: OK (r77126 + r77654 + r77679 + r77680)
Installation Master DVD: OK
Installation Slave: OK
Installation Master Remote: Fail. If I start the setup configuration via HTTPS from a webbrowser, the system setup wizards shows much too early that the setup has been finished. Maybe the new apache2 restart is responsible?
https from remote host during debian installer: Yes, this is an issue due to the apache2 restart. It was introduced by bug #42500 at the end of 2016. I think we did that because univention-ssl behaved differently, then.
So it is not strictly a regression in 4.2.
No changelog as this bug fixed a regression in 4.2 system setup: SSO joinscripts were not running completely
(In reply to Erik Damrose from comment #13)
> https from remote host during debian installer: Yes, this is an issue due to
> the apache2 restart. It was introduced by bug #42500 at the end of 2016. I
> think we did that because univention-ssl behaved differently, then.
> So it is not strictly a regression in 4.2.
> No changelog as this bug fixed a regression in 4.2 system setup: SSO
> joinscripts were not running completely
OK, it works now.
UCS 4.2 has been released:
If this error occurs again, please use "Clone This Bug".