Bug 34776 - Should fix_gpo_container_names() rename policy folder to uppercase?
Should fix_gpo_container_names() rename policy folder to uppercase?
Status: CLOSED FIXED
Product: UCS
Classification: Unclassified
Component: S4 Connector
UCS 3.2
Other Linux
: P5 normal (vote)
: UCS 3.2-2-errata
Assigned To: Arvid Requate
Felix Botner
:
: 29753 (view as bug list)
Depends on:
Blocks: 39074
  Show dependency treegraph
 
Reported: 2014-05-08 13:08 CEST by Janis Meybohm
Modified: 2015-08-04 12:37 CEST (History)
3 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):
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Janis Meybohm univentionstaff 2014-05-08 13:08:43 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".
Comment 1 Arvid Requate univentionstaff 2014-07-28 19:24:15 CEST
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
Comment 2 Stefan Gohmann univentionstaff 2014-08-01 10:00:19 CEST
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.
Comment 3 Stefan Gohmann univentionstaff 2014-08-01 10:00:46 CEST
I can't finish the QA next week.
Comment 4 Arvid Requate univentionstaff 2014-08-04 20:05:34 CEST
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,))
Comment 5 Arvid Requate univentionstaff 2014-08-06 15:37:04 CEST
*** Bug 29753 has been marked as a duplicate of this bug. ***
Comment 6 Arvid Requate univentionstaff 2014-08-06 15:39:14 CEST
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.
Comment 7 Arvid Requate univentionstaff 2014-08-06 16:01:36 CEST
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.
Comment 8 Felix Botner univentionstaff 2014-08-06 16:41:19 CEST
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.
Comment 9 Arvid Requate univentionstaff 2014-08-06 17:37:10 CEST
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.
Comment 10 Felix Botner univentionstaff 2014-08-06 17:52:59 CEST
OK
Comment 11 Janek Walkenhorst univentionstaff 2014-08-07 17:48:55 CEST
http://errata.univention.de/ucs/3.2/172.html