Univention Bugzilla – Bug 34776
Should fix_gpo_container_names() rename policy folder to uppercase?
Last modified: 2015-08-04 12:37:07 CEST
2014050521006581 I'm not completely sure about this but customer and me got into a situation where the default GPO is "robocopied" with the lowercase "f" but gPCFileSysPath points to a directory with uppercase "F" - corrected by fix_gpo_container_names(). Should we rename the directory in this case (using uppercase)? Or should we avoid renaming completely and extend remove_conflicting_msgpo_objects_from_LDAP() to be case insensitive? Last option preserves the AD behaviour of the "wrong" lowercase "f".
Ok, the ad-takeover backend code has been adjusted to first check for GPOs with mixed-case GUID if the directory acutally doesn't exist in the mixed case spelling but in the upper case. Only in that case the gPCFileSysPath is adjusted. Additionally the code then checks if there is another GPO object of similar but different spelling which points to the same directory. If that is the case, then the uppercase GPO object is removed. This is required since the GPO in question ("6AC1786C-016F-11D2-945F-00C04fB984F9") is one of the two default ones, which also exist in standard UCS/Samba4. Probably this additional step is now obsolete due to the changes for Bug 35252, but it shouldn't hurt either. Advisory: 2014-07-28-univention-management-console-module-adtakeover.yaml
YAML: OK Code Review: Failed (In reply to Arvid Requate from comment #1) > Additionally the code then checks if there is another GPO object of similar > but different spelling which points to the same directory. If that is the > case, then the uppercase GPO object is removed. This is required since the > GPO in question ("6AC1786C-016F-11D2-945F-00C04fB984F9") is one of the two > default ones, which also exist in standard UCS/Samba4. Probably this > additional step is now obsolete due to the changes for Bug 35252, but it > shouldn't hurt either. I think we should at least log this information with debug level process. Otherwise I don't have the chance to see what happened.
I can't finish the QA next week.
The log messages should be present already? log.warn("GPO object %s and %s look similar, but their gPCFileSysPath differ, leaving them untouched." % (obj.dn, obj2.dn)) log.warn("Probably %s should be obsolete?" % (obj2.dn,)) and log.info("Removing %s from SAM database." % (obj2.dn,)) log.info("Keeping similar object %s." % (obj.dn,))
*** Bug 29753 has been marked as a duplicate of this bug. ***
Ok, I just checked this again and reduced/simplified the patch: * The function fix_gpo_container_names has been removed. * The code was moved to check_gpo_presence and only adjusts gPCFileSysPath if 1. the GPO name was mixed case. 2. the gPCFileSysPath was not found in sysvol. 3. it was found in sysvol in uppercase spelling. * remove_conflicting_msgpo_objects_from_LDAP now also looks for GPO names in upper case in UCS LDAP if the name is mixed case in Samba4. Package rebuilt and changelog adjusted.
Felix also found out how this happens: 1. due to initial Samba4 provisioning prior to the adtakeover, the directory {6AC1786C-016F-11D2-945F-00C04FB984F9} already exists in uppercase before the robocopy 2. If the directory exists, robocopy finds it, irrespectable of the case, and copies the content of the mixed case directory {6AC1786C-016F-11D2-945F-00C04fB984F9} in AD to the corresponding existing upper case directory in UCS. 3. In this case the gPCFileSysPath is mixed case and doesn't match the upper case name in the UCS filesystem. That's why I generally changed the gPCFileSysPath to upper case during the development of hte UMC module (Bug #29753). Now what is this bug here about? In case the customer deleted the sysvol content before the robocopy, the robocopy will create the directory in mixed case, and the uppcercase gPCFileSysPath doesn't match. What's the solution? For mixed case GPOs check if the gPCFileSysPath is valid. If yes, don't do anything. If it's not, then check if the uppercase version of the directory exists in the filesystem. If yes, modify gPCFileSysPath to be valid. Another solution would have been to remove the pre-existing GPO directories in the UCS sysvol during the first phase of the takeover (e.g. while removing the corresponding msgpo objects in OpenLDAP). Anyway, this solution was not taken here and now.
OK, mismatch happens because we already have a 6AC1786C-016F-11D2-945F-00C04FB984F9 directory robocopy/samba uses this dir when copying the 6AC1786C-016F-11D2-945F-00C04fB984F9 dir from windows Test - deleted 6AC1786C-016F-11D2-945F-00C04FB984F9 after installing ad-takeover (before the takeover): OK - UCS gpo objects are deleted (upper and mixed case) 2014-08-06 17:15:25,719 Calling: /usr/sbin/univention-directory-manager container/msgpo delete --filter name={31B2F340-016D-11D2-945F-00C04FB984F9} 2014-08-06 17:15:25,857 Object removed: 2014-08-06 17:15:25,869 Calling: /usr/sbin/univention-directory-manager container/msgpo delete --filter name={6AC1786C-016F-11D2-945F-00C04fB984F9} 2014-08-06 17:15:26,021 Object removed: 2014-08-06 17:15:26,033 Calling: /usr/sbin/univention-directory-manager container/msgpo delete --filter name={6AC1786C-016F-11D2-945F-00C04FB984F9} OK - local dir {6AC1786C-016F-11D2-945F-00C04fB984F9} OK - gPCFileSysPath was not changed (still points to ...00C04fB9...) OK - no log messages OK - samba-tool ntacl sysvolreset Test - with 6AC1786C-016F-11D2-945F-00C04FB984F9 in UCS before the takeover OK - UCS gpo objects are deleted (upper and mixed case) 2014-08-07 01:19:51,367 Calling: /usr/sbin/univention-directory-manager container/msgpo delete --filter name={31B2F340-016D-11D2-945F-00C04FB984F9} 2014-08-07 01:19:51,518 Object removed: 2014-08-07 01:19:51,532 Calling: /usr/sbin/univention-directory-manager container/msgpo delete --filter name={6AC1786C-016F-11D2-945F-00C04fB984F9} 2014-08-07 01:19:51,680 Object removed: 2014-08-07 01:19:51,689 Calling: /usr/sbin/univention-directory-manager container/msgpo delete --filter name={6AC1786C-016F-11D2-945F-00C04FB984F9} OK - local dir {6AC1786C-016F-11D2-945F-00C04FB984F9} OK - gPCFileSysPath was updated to 6AC1786C-016F-11D2-945F-00C04FB984F9 OK - log message 2014-08-07 01:24:16,274 Adjusting gPCFileSysPath \\w2k8r2en.test\sysvol\w2k8r2en.test\Policies\{6AC1786C-016F-11D2-945F-00C04fB984F9} of CN={6AC1786C-016F-11D2-945F-00C04fB984F9},CN=Policies,CN=System,DC=w2k8r2en,DC=test to uppercas FAIL - samba-tool ntacl sysvolreset sysvolreset uses the value from "cn" (not gPCFileSysPath)to build the directory name.
Ok, then we remove the pre-existing conflicting GPO directories in the UCS sysvol during the first phase of the takeover (e.g. while removing the corresponding msgpo objects in OpenLDAP). This is also the most clean approach.
OK
http://errata.univention.de/ucs/3.2/172.html