Bug 40785 - Hook scripts for UCS@school import not available on non-master
Hook scripts for UCS@school import not available on non-master
Status: RESOLVED WONTFIX
Product: UCS@school
Classification: Unclassified
Component: Import scripts
UCS@school 4.1
Other Linux
: P5 normal (vote)
: UCS@school 4.x
Assigned To: UCS@school maintainers
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2016-02-26 14:26 CET by Sönke Schwardt-Krummrich
Modified: 2020-07-09 10:46 CEST (History)
2 users (show)

See Also:
What kind of report is it?: ---
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional): Design
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sönke Schwardt-Krummrich univentionstaff 2016-02-26 14:26:06 CET
Currently ucs-school-import provides some import hooks for e.g. adding a "Marktplatz" share during OU creation. These hook scripts are usually only available on DC master.

If a new OU/group/user/share/... is created on a DC slave via the UCS@school python library the hook scripts are not called because they are not existant in the local filesystem.

Possible solutions: 
1) modification of UCS@school LDAP objects is only performed on the DC master
2) hook scripts are also registered in and distributed via LDAP to all UCS@school 
   systems.
Comment 1 Florian Best univentionstaff 2016-02-26 15:10:20 CET
When this is fixed please readd the role domaincontroller_slave to the ucs-test script 41_create_marktplatz_share. Bug #40736
Comment 2 Sönke Schwardt-Krummrich univentionstaff 2016-06-06 09:29:19 CEST
(In reply to Sönke Schwardt-Krummrich from comment #0)
> If a new OU/group/user/share/... is created on a DC slave via the UCS@school
> python library the hook scripts are not called because they are not existant
> in the local filesystem.

To align this statement with the permission context:
if the ucs-school-lib is used, valid and capable LDAP credentials have to be provided to the lib. Otherwise the LDAP modification attempt will fail. So, currently only cn=admin and Domain Admins are allowed to create/modify OUs, classes, shares, ... Some specific changes (e.g. working groups) are additionally allowed by the machine account (DC slave).

So, currently, most of the time, UMC modules and ucs-school-lib are executed on DC master, to have sufficient permissions/credentials.
Comment 3 Michel Smidt 2020-07-09 10:46:02 CEST
This issue has been filed against UCS@school 4.1.

UCS@school 4.1 is out of maintenance and many UCS@school components have changed in later releases. Thus, this issue is now being closed.

If this issue still occurs in newer UCS@school versions, please reopen it and update the UCS@school version. In this case please provide detailed information on how this issue is affecting you.