Bug 49384

Summary: License request from system setup not working in App Appliances
Product: UCS Reporter: Erik Damrose <damrose>
Component: System setupAssignee: Florian Best <best>
Status: CLOSED FIXED QA Contact: Jürn Brodersen <brodersen>
Severity: normal    
Priority: P5 CC: best, brodersen
Version: UCS 4.4   
Target Milestone: UCS 4.4-0-errata   
Hardware: Other   
OS: Linux   
See Also: https://forge.univention.org/bugzilla/show_bug.cgi?id=47880
https://forge.univention.org/bugzilla/show_bug.cgi?id=38319
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: Flags outvoted (downgraded) after PO Review:
Ticket number: Bug group (optional): Appliance, Usability
Max CVSS v3 score:
Bug Depends on:    
Bug Blocks: 51299    
Attachments: possible patch
patch (git:fbest/49384-license-request)

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