Bug 49384 - License request from system setup not working in App Appliances
License request from system setup not working in App Appliances
Status: CLOSED FIXED
Product: UCS
Classification: Unclassified
Component: System setup
UCS 4.4
Other Linux
: P5 normal (vote)
: UCS 4.4-0-errata
Assigned To: Florian Best
Jürn Brodersen
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2019-04-29 14:06 CEST by Erik Damrose
Modified: 2019-07-10 13:20 CEST (History)
2 users (show)

See Also:
What kind of report is it?: Bug Report
What type of bug is this?: 6: Setup Problem: Issue for the setup process
Who will be affected by this bug?: 3: Will affect average number of installed domains
How will those affected feel about the bug?: 2: A Pain – users won’t like this once they notice it
User Pain: 0.206
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Ticket number:
Bug group (optional): Appliance, Usability
Max CVSS v3 score:


Attachments
possible patch (1008 bytes, patch)
2019-06-25 12:20 CEST, Florian Best
Details | Diff
patch (git:fbest/49384-license-request) (1.78 KB, patch)
2019-06-25 13:19 CEST, Florian Best
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Erik Damrose univentionstaff 2019-04-29 14:06:18 CEST
Users can enter an email address in system setup to request a license - this request will be sent at the end of our setup. An ISV reported it as being broken.

The request is done in /usr/lib/univention-system-setup/cleanup-post.d/08_activate_license from package univention-system-setup by calling umcp udm/request_new_license.

However, we block umc access in app appliances at the end of the setup, in /usr/lib/univention-system-setup/appliance-hooks.d/96_enable_system_activation from package univention-system-activation.

The UMC access is blocked to early, and the umcp request does not work; from setup.log:
=== Running appliance hook scripts (2019-04-29 12:55:08) ===
...
= Running 96_enable_system_activation
...
=== Running cleanup-post scripts (2019-04-29 12:56:28) ===
...
= Running 08_activate_license
Activating the UCS license with the email address damrose@univention.de...
29.04.19 12:56:29.807  DEBUG_INIT
Response: COMMAND
  data length   :  272
  message length:  191
  ---
  ARGUMENTS: ['udm/request_new_license']
MIMETYPE   : application/json
  STATUS   : 403
  MESSAGE  : Verboten
  ERROR    : {u'traceback': None, u'command': u'handle_request_command'}
  RESULT   : { u'error': { u'command': u'handle_request_command', u'traceback': None},
  u'headers': { u'Content-Language': u'en-US', u'Vary': u'Content-Language'},
  u'message': u'Verboten',
  u'result': None,
  u'status': 403}
... done

I see several solutions:
* whitelist the license request; u-system-activation already whitelists some requests, see conffiles/etc/apache2/sites-available/univention-system-activation.conf.
* Move the license request to an earlier point in the setup process
* Move the u-app-activation script to a later point in the setup process
Comment 2 Jürn Brodersen univentionstaff 2019-06-03 14:07:15 CEST
This is also a problem in normal ucs appliances.

The setup log has the same error message, but I also get this error in management-console-server.log:

03.06.19 13:51:32.089  MAIN        ( WARN    ) : Module None (command='udm/request_new_license', id='155956269191661-0') does not exists anymore
03.06.19 13:51:32.119  MODULE      ( PROCESS ) : Verboten
Comment 3 Florian Best univentionstaff 2019-06-25 12:20:39 CEST
Created attachment 10084 [details]
possible patch
Comment 4 Jürn Brodersen univentionstaff 2019-06-25 12:32:01 CEST
Comment on attachment 10084 [details]
possible patch

Es wird der Maschinenaccount genutzt, nicht __systemsetup__.

Siehe auch base/univention-system-setup/usr/lib/univention-system-setup/cleanup-post.d/08_activate_license
Comment 5 Florian Best univentionstaff 2019-06-25 12:43:01 CEST
Okay, then, let's see what permissions the machine account has?:

# eval "$(ucr shell)"
# umc-acls show -u "$hostname\$"
Username: master100$

→ None?!
Comment 6 Florian Best univentionstaff 2019-06-25 13:10:45 CEST
I analyzed this, and it is a regression from Bug #47880.
Because now all flavors have a <requiredCommand> and therefore the module is forbidden for the user because the DC Master only has permissions for udm/request_new_license.
Somehow even if the request doesn't specify a flavor the ACL evaluation doesn't consider this.
Comment 7 Florian Best univentionstaff 2019-06-25 13:19:05 CEST
Created attachment 10085 [details]
patch (git:fbest/49384-license-request)

Could you test this patch? For me it works. But didn't run system-setup.
Comment 8 Florian Best univentionstaff 2019-06-27 14:11:54 CEST
Patch + Translation has been applied.

univention-management-console-module-udm.yaml
a80a65f0629f | YAML Bug #49384

univention-management-console-module-udm (9.0.12-16)
5b3a5f412c53 | Bug #49384: fix permissions for requesting a license

univention-system-setup.yaml
a80a65f0629f | YAML Bug #49384

univention-system-setup (12.0.2-9)
5b3a5f412c53 | Bug #49384: fix permissions for requesting a license
Comment 9 Jürn Brodersen univentionstaff 2019-06-28 16:19:54 CEST
What I tested:
Installed from the latest test dvd with email -> License was requested and send -> OK
The new flavor does not show up as a module -> OK
jenkins -> OK
YAML -> OK

I added a test:
[4.4-0 f35f62f317] Bug #49384: add 59_udm/21_request_new_license.py

-> Verified