Bug 45439 - Rejoin of UCS@school 4.2 slave purges GPOs from LDAP
Rejoin of UCS@school 4.2 slave purges GPOs from LDAP
Status: CLOSED FIXED
Product: UCS
Classification: Unclassified
Component: Samba
UCS 4.2
Other Linux
: P5 major (vote)
: UCS 4.2-2-errata
Assigned To: Stefan Gohmann
Felix Botner
:
Depends on:
Blocks: 45440 45452
  Show dependency treegraph
 
Reported: 2017-09-22 14:54 CEST by Sönke Schwardt-Krummrich
Modified: 2017-09-26 17:01 CEST (History)
4 users (show)

See Also:
What kind of report is it?: Bug Report
What type of bug is this?: 5: Major Usability: Impairs usability in key scenarios
Who will be affected by this bug?: 4: Will affect most installed domains
How will those affected feel about the bug?: 5: Blocking further progress on the daily work
User Pain: 0.571
Enterprise Customer affected?:
School Customer affected?: Yes
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number: 2017081521000495
Bug group (optional):
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 2017-09-22 14:54:24 CEST
The joinscript 97univention-s4-connector.inst of UCS 4.2 seems to contain defect logic when syncing GPOs during (re)join of UCS@school slaves.

The relevant part of 97univention-s4-connector.inst looks like this:

if ! is_ucr_true 'connector/s4/allow/secondary'; then
    s4connector_dc=$(get_available_s4connector_dc) || exit $?

fi
if [ -z "$s4connector_dc" ] \
    || [ "$s4connector_dc" = "$hostname" ]; then

    if [ $JS_LAST_EXECUTED_VERSION -le 0 ] && is_ucr_true connector/s4/mapping/gpo; then
        /etc/init.d/univention-s4-connector stop

        if [ -z "$s4connector_dc" ] \
            || [ "$s4connector_dc" = "$hostname" ]; then
            # First or only Sama 4 server
            /usr/share/univention-s4-connector/msgpo.py --write2ucs "$@"
        elif ! is_ucr_true 'connector/s4/allow/secondary'; then
            # Normal Samba 4 DC
            /usr/share/univention-s4-connector/msgpo.py --write2ucs "$@"
        else
            # Slave PDC
            /usr/share/univention-s4-connector/msgpo.py --write2samba4 "$@"
        fi
    fi
fi

In school environments on the school slave connector/s4/allow/secondary=yes ist set, therefore s4connector_dc is not set. Even if the UCRV is not set or set to "no", the hostname of the school slave is stored in s4connector_dc via  get_available_s4connector_dc().
So the condition [ -z "$s4connector_dc" ] || [ "$s4connector_dc" = "$hostname" ]
is always met and therefore the branch "First or only Sama 4 server" is always executed on UCS@school slaves, which results in a
/usr/share/univention-s4-connector/msgpo.py --write2ucs "$@"

In UCS 4.1-4 the query for the s4connector host looked quite different:

        s4connectorservicehost_dns="$(univention-directory-manager computers/computer list "$@" --filter "(&(univentionService=${NAME})(!(cn=$hostname)))" | sed -ne 's|^DN: ||p')"

        if [ -z "$s4connectorservicehost_dns" ]; then
            # First Sama 4 server
            /usr/share/univention-s4-connector/msgpo.py --write2ucs "$@"
        elif ! is_ucr_true 'connector/s4/allow/secondary'; then
            # Normal Samba 4 DC
            /usr/share/univention-s4-connector/msgpo.py --write2ucs "$@"
        else
            # Slave PDC
            /usr/share/univention-s4-connector/msgpo.py --write2samba4 "$@"
        fi
Comment 1 Florian Best univentionstaff 2017-09-22 15:03:53 CEST
The change from 4.1-4 was 9fba7d8d5d8af4ca239e0b7426ff1cd33126aa21 aka:
* Bug #43478: Don't consider unreachable UCS@school Slave DCs when
      looking for hosts running a S4-Connector.
Comment 2 Sönke Schwardt-Krummrich univentionstaff 2017-09-22 17:26:45 CEST
The assumptions in the original comment were wrong. It looks like the original reason for the GPO loss is already fixed via bug 45210.
Comment 3 Stefan Gohmann univentionstaff 2017-09-25 08:06:55 CEST
(In reply to Sönke Schwardt-Krummrich from comment #2)
> The assumptions in the original comment were wrong. It looks like the
> original reason for the GPO loss is already fixed via bug 45210.

Yes.
Comment 4 Stefan Gohmann univentionstaff 2017-09-25 08:07:14 CEST
Nothing to release.
Comment 5 Sönke Schwardt-Krummrich univentionstaff 2017-09-25 10:02:37 CEST
There are still some situations, that are not clear → reopen
Comment 6 Felix Botner univentionstaff 2017-09-25 13:34:54 CEST
(In reply to Sönke Schwardt-Krummrich from comment #5)
> There are still some situations, that are not clear → reopen

yep, rejoin a school slave ...


Stopping univention-s4-connector (via systemctl): univention-s4-connector.service.
+ '[' -z '' ']'
+ /usr/share/univention-s4-connector/msgpo.py --write2ucs --binddn uid=Administrator,cn=users,dc=four,dc=two --bindpwd univention
Set msGPOLink for UCS object (dc=four,dc=two)
Set msGPOLink for UCS object (ou=domain controllers,dc=four,dc=two)


dc=four,dc=two and ou=domain controllers,dc=four,dc=two are now reseted to the default policies
Comment 7 Stefan Gohmann univentionstaff 2017-09-25 20:13:33 CEST
The issue exists since 4.2 errata44. So, I've changed the logic a little bit. In case the msGPO link is set in OpenLDAP it is not overwritten during the join. We didn't find any situation where it should be overwritten.

I've added a new parameter to the msgpo.py script -only-override-empty which can be used in case the write2ucs mode is used. Thus, the default hasn't been changed and the manual is still valid: http://docs.software-univention.de/ucsschool-handbuch-4.2.html#school:exam:gpo:general

Changes:
https://git.knut.univention.de/univention/ucs/commit/70516a0166612b6f89164a65044d77fdd5d1d476

YAML:
https://git.knut.univention.de/univention/ucs/commit/f5ae9c5ad1827e513a47ee7378bf0b0979745eef
Comment 8 Felix Botner univentionstaff 2017-09-26 13:00:29 CEST
OK - master "rejoin" (additional gpo's not removed)
OK - backup rejoin (additional gpo's not removed)
OK - installation on backup (default samba gpo in ucs)
OK - subsequent installation of s4 on master (gpo settings ok in s4/openldap)


OK - school, master s4 + slave1 s4 + slave2 s4
     new gpolinks (domain, school ou) still exists after rejoin
OK - gpo's ok after Re-Provisioning Samba4 on a UCS@school DC Master 

OK - univention-s4connector (msgpo.py --only-override-empty)
OK - YAML
Comment 9 Philipp Hahn univentionstaff 2017-09-26 17:01:53 CEST
<http://errata.software-univention.de/ucs/4.2/186.html>