Bug 41641 - Determination of policy types is indeterministic
Determination of policy types is indeterministic
Status: CLOSED FIXED
Product: UCS
Classification: Unclassified
Component: DHCP
UCS 4.1
Other Linux
: P5 normal (vote)
: UCS 4.1-2-errata
Assigned To: Sönke Schwardt-Krummrich
Philipp Hahn
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2016-06-22 18:02 CEST by Erik Damrose
Modified: 2016-09-29 20:36 CEST (History)
3 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?: 3: Will affect average number of installed domains
How will those affected feel about the bug?: 3: A User would likely not purchase the product
User Pain: 0.257
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional):
Max CVSS v3 score:


Attachments
Workaround: fix order of objectclass in every or specific policies (699 bytes, text/plain)
2016-09-13 14:23 CEST, Sönke Schwardt-Krummrich
Details
Workaround: fix order of objectclass in every or specific policies (Version 2) (699 bytes, text/plain)
2016-09-16 11:41 CEST, Sönke Schwardt-Krummrich
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Erik Damrose univentionstaff 2016-06-22 18:02:13 CEST
UCS 4.1-2e204, UCS@School 4.1 r2 v1, UCC 2.1 r2.

There are 2 DHCP routing policies defined after setting up a school-singlemaster + installing UCC:

dn: cn=ucc-dhcp-gateway,cn=routing,cn=dhcp,cn=policies,$ldap_base
objectClass: univentionPolicyDhcpRouting
objectClass: top
objectClass: univentionPolicy
objectClass: univentionObject
univentionObjectType: policies/dhcp_routing
univentionDhcpRouters: 10.200.29.1
cn: ucc-dhcp-gateway

dn: cn=default-settings,cn=routing,cn=dhcp,cn=policies,$ldap_base
objectClass: top
objectClass: univentionPolicy
objectClass: univentionPolicyDhcpRouting
objectClass: univentionObject
univentionObjectType: policies/dhcp_routing
cn: default-settings
univentionDhcpRouters: 10.200.29.1

If the ucc-dhcp-gateway policy is assigned to cn=myschool,cn=dhcp,ou=myschool,$ldap_base, it is not evaluated by dhcpd. If cn=default-settings is assigned, dhcpd will set the option.
Comment 1 Sönke Schwardt-Krummrich univentionstaff 2016-06-24 14:45:56 CEST
Problem seems to be the detection of the policy types in univention_policy_result. The C code iterates over the objectclass names and ignores the names "univentionObject", "top" and "univentionPolicyReference".
The it selects the last object class name given by the LDAP server as policy type.
So in Eriks case, the first policy is of type "univentionPolicy" whereas the second one is of type "univentionPolicyDhcpRouting". In combination with other policies and/or emptyAttributes, "interesting" and indeterministic results have been observed.
Comment 2 Sönke Schwardt-Krummrich univentionstaff 2016-06-24 14:52:09 CEST
Currently I do not see an easy fix without using hardcoded object class names. The attribute univentionObjectType cannot be used, as it is not guaranteed that this attribute is set all the time.
According to a check in UCS 4.1-2, there are only 2 policy type that use an objectclass name that does not start with "univentionPolicy":
"univentionMailQuota" and "umcPolicy". All other objectclasses start with "univentionPolicy". But all objectclasses are subclasses from "univentionPolicy".

I decided to use the cheap way:
univention_policy_result will accept all objectclasses starting with "univentionPolicy" and the two exceptions above are hardcoded.

Otherwise univention_policy_result has to fetch the LDAP schema from LDAP server and parse all object class definitions to find all subclasses of "univentionPolicy". I expect this to be an expensive task.
Comment 3 Sönke Schwardt-Krummrich univentionstaff 2016-06-24 15:21:50 CEST
The code of univention-policy has not been changed for a long time, but the UDM code has been altered recently and is expected to the cause of a different order of the object classes in new objects (it is known, that LDAP does not assure a certain order for LDAP values).

univention-policy (7.0.2-1):
r70614 | Bug #41641: added error/debug output for easier debugging
r70613 | Bug #41641: fixed detection of policy types in univention_policy_result

univention-policy.yaml:
r70615 | Bug #41641: added univention-policy.yaml
Comment 4 Philipp Hahn univentionstaff 2016-06-27 10:13:54 CEST
OK: r70614 r70613
FIXED: Package not built
 Package: univention-policy
 Version: 7.0.2-1.134.201606270906
 Branch: ucs_4.1-0
 Scope: errata4.1-2

FIXED: univention-policy.yaml
 r70623 | Bug #41641 policy: YAML
OK: errata-announce -V --only univention-policy.yaml


OK: ucs-test/tests/59_udm/07_orderObjectClasses
 r70624 | Bug #41641 test: univention-policy-result objectClass order
OK: ucs-test -E dangerous -s udm

Package: ucs-test
Version: 6.0.33-75.1489.201606271011
Branch: ucs_4.1-0
Scope: errata4.1-2
Comment 5 Janek Walkenhorst univentionstaff 2016-06-29 12:26:42 CEST
<http://errata.software-univention.de/ucs/4.1/205.html>
Comment 6 Sönke Schwardt-Krummrich univentionstaff 2016-09-13 14:23:16 CEST
Created attachment 8003 [details]
Workaround: fix order of objectclass in every or specific policies

Attached a script that fixes the order of the objectclass values in every existing policy or for a specific policy only.

fixpolicy.sh [<DN>|--all]
Comment 7 Sönke Schwardt-Krummrich univentionstaff 2016-09-16 11:41:17 CEST
Created attachment 8017 [details]
Workaround: fix order of objectclass in every or specific policies (Version 2)

New version of the workaround script (sorry, I messed up the objectclass order)