Univention Bugzilla – Bug 38850
Activation service on app appliances is started too late
Last modified: 2015-07-16 14:24:08 CEST
We need to make sure that the activation service is running as soon as the final page of the setup wizard is shown. The service is currently only activated after clicking in "Finish". See Ticket#2015070721000292. +++ This bug was initially created as a clone of Bug #38547 +++ It is required that we inform the ISV if someone installed the App of the ISV. This also applies to the App appliances. After the installation / configuration of the App appliance, we should show a pop-up which points to the activation. After a few days (one or two) UMC should only allow to activate UCS. Once the system is activated, a notification should be sent to the ISV through our normal notification system.
Fixed. I also removed the link to /univention-management-console on the last page of the setup wizard, such that only the server address is shown. The YAML files are missing the updated package version. Packages are building. univention-system-activation (0.0.1-26): r61882 | Bug #38850: activate service in appliance hooks and allow umcp commands 2015-07-08-univention-system-activation.yaml: r61884 | Bug #38850: added YAML entries 2015-07-03-univention-system-setup.yaml: r61884 | Bug #38850: added YAML entries univention-system-setup (8.1.69-17): r61881 | Bug #38850: only show general server address on final setup page
... just to be more precise, I moved the script for starting the activation service into the appliance hook directory (executed at the end of setup-join.sh) and allowed requests to /umcp in order to allow the final cleanup UMCP request (executed on the last wizard page) when the activation service has already been started.
Just realized that there is still a redirect to UMC when configuring the machine with an external browser. For this, an apache rewrite rule should be appropriate.
(In reply to Alexander Kläser from comment #3) > Just realized that there is still a redirect to UMC when configuring the > machine with an external browser. For this, an apache rewrite rule should be > appropriate. Fixed. Package is building. univention-system-activation (0.0.1-27): r61978 | Bug #38850: redirect accesses to UMC to the activation service
Another adjustment. Univention App icons will usually be stored in /var/www/icon. During the system activation, the accessed had been blocked, and in consquence, no app icon was shown on the welcome screen. I added the access to /var/www/icon. In order to avoid a user navigating to the activation page or to UMC before clicking "finish" on the last wizard page, I removed the addresses there. They will be shown anyway on the welcome screen. univention-system-activation (0.0.1-28): r62009 | Bug #38850: allow access to /icon univention-system-setup (8.1.69-19): r62010 | Bug #38850: adjust text on the last setup wizard page
If you use an external browser to configure the appliance, the activation wizard will always start with the register page. As discussed it seems that the variable hasLicenseRequested (app.js) is still false, so it is better to check if an email address is given to load the right site.
(In reply to Alexander Kramer from comment #6) > If you use an external browser to configure the appliance, the activation > wizard will always start with the register page. > > As discussed it seems that the variable hasLicenseRequested (app.js) is > still false, so it is better to check if an email address is given to load > the right site. Fixed. Package is building. univention-system-activation (0.0.1-29): r62047 | Bug #38850: check for existing email address instead license request
> Fixed. Package is building. > > univention-system-activation (0.0.1-29): > r62047 | Bug #38850: check for existing email address instead license request I merge the change also into the 4.1 branch. univention-system-activation (0.0.1-29): r62054 | Bug #38850: check for existing email address instead license request
OK - check for existing email address instead license request OK - merged changes also into the 4.1 branch OK - debian/changelog 4.0-2 & 4.1 OK - yaml file 4.0-2
<http://errata.univention.de/ucs/4.0/244.html> <http://errata.univention.de/ucs/4.0/243.html>