Univention Bugzilla – Bug 41641
Determination of policy types is indeterministic
Last modified: 2016-09-29 20:36:31 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.
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.
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.
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
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
<http://errata.software-univention.de/ucs/4.1/205.html>
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]
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)