Bug 45167 – Traceback in sync_to_ucs after deleting a GPO with sub-objects

Bug 45167 - Traceback in sync_to_ucs after deleting a GPO with sub-objects


Summary:	Traceback in sync_to_ucs after deleting a GPO with sub-objects

Status:	RESOLVED DUPLICATE of bug 49324

Product:	UCS
Classification:	Unclassified
Component:	S4 Connector
Version:	UCS 4.4
Hardware:	Other Linux

Importance:	P5 normal (vote)
Target Milestone:	---
Assigned To:	Samba maintainers
QA Contact:	Samba maintainers

URL:
Keywords:

Depends on:
Blocks:
	Show dependency tree / graph

Reported:	2017-08-08 17:13 CEST by Arvid Requate
Modified:	2019-11-12 06:35 CET (History)
CC List:	2 users (show)

See Also:	49324
What kind of report is it?:	Bug Report
What type of bug is this?:	3: Simply Wrong: The implementation doesn't match the docu
Who will be affected by this bug?:	2: Will only affect a few installed domains
How will those affected feel about the bug?:	2: A Pain – users won’t like this once they notice it
User Pain:	0.069
Enterprise Customer affected?:	Yes
School Customer affected?:	Yes
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:	2019110821000597
Bug group (optional):
Max CVSS v3 score:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.

Description Arvid Requate

2017-08-08 17:13:20 CEST

Traceback in sync_to_ucs after deleting a GPO with sub-objects:

===========================================================================
08.08.2017 14:07:44,373 LDAP        (WARNING): Failed to get Result for DN (ou=e474,dc=edu,dc=foo,dc=bar
08.08.2017 14:07:44,374 LDAP        (PROCESS): sync to ucs: Resync rejected dn: cn={E3C49B01-3873-459E
08.08.2017 14:07:44,376 LDAP        (PROCESS): sync to ucs:   [         msGPO] [    delete] cn={E3C49B
08.08.2017 14:07:44,379 LDAP        (WARNING): delete subobject: cn=Machine,cn={E3C49B01-3873-459E-88A
08.08.2017 14:07:44,380 LDAP        (PROCESS): sync to ucs:   [     container] [    delete] cn=Machine
08.08.2017 14:07:44,383 LDAP        (WARNING): delete subobject: cn=microsoft,cn=machine,cn={e3c49b01-
08.08.2017 14:07:44,384 LDAP        (PROCESS): sync to ucs:   [     container] [    delete] cn=Microso
08.08.2017 14:07:44,385 LDAP        (ERROR  ): Unknown Exception during sync_to_ucs
08.08.2017 14:07:44,385 LDAP        (ERROR  ): Traceback (most recent call last):
  File "/usr/lib/pymodules/python2.7/univention/s4connector/__init__.py", line 1450, in sync_to_ucs
    guid_unicode = original_object.get('attributes').get('objectGUID')[0]
TypeError: 'NoneType' object has no attribute '__getitem__'

08.08.2017 14:07:44,385 LDAP        (WARNING): delete of subobject failed: cn=Microsoft,cn=Machine,cn=

08.08.2017 14:07:44,385 LDAP        (WARNING): Failed to get Result for DN (cn=Machine,cn={E3C49B01-38
08.08.2017 14:07:44,385 LDAP        (WARNING): delete of subobject failed: cn=Machine,cn={E3C49B01-387
08.08.2017 14:07:44,386 LDAP        (WARNING): Failed to get Result for DN (cn={E3C49B01-3873-459E-88A
===========================================================================

Comment 1 Florian Best

2017-08-08 17:24:09 CEST

A test case would be nice.

Comment 2 Stefan Gohmann

2019-01-03 07:17:53 CET

This issue has been filled against UCS 4.1. The maintenance with bug and security fixes for UCS 4.1 has ended on 5st of April 2018.

Customers still on UCS 4.1 are encouraged to update to UCS 4.3. Please contact
your partner or Univention for any questions.

If this issue still occurs in newer UCS versions, please use "Clone this bug" or simply reopen the issue. In this case please provide detailed information on how this issue is affecting you.

Comment 4 Arvid Requate

2019-11-11 22:24:46 CET

The code shown in the Traceback in Comment 3 has gone since commit 757f3158e0, which should be included in Erratum 298, which additionally fixes Bug #49324, which looks related to me. So I recommend updating to the latest Errata version in that case.

Comment 5 Florian Best

2019-11-12 06:35:22 CET


*** This bug has been marked as a duplicate of bug 49324 ***