Bug 29683 - Unnötige Fehlermeldung beim Löschen von Objekten mit dazugehörigen Objekten
Summary: Unnötige Fehlermeldung beim Löschen von Objekten mit dazugehörigen Objekten
Status: RESOLVED WORKSFORME
Alias: None
Product: UCS
Classification: Unclassified
Component: UDM (Generic)
Version: UCS 3.1
Hardware: Other Linux
: P4 normal
Target Milestone: UCS 3.2-x
Assignee: UMC maintainers
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-12-10 14:28 CET by Dirk Wiesenthal
Modified: 2018-04-13 13:29 CEST (History)
4 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):
Customer ID: 00026
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dirk Wiesenthal univentionstaff 2012-12-10 14:28:27 CET
Beim Löschen eines DNS-Objekts (mitsamt zugehöriger Objekte) kam folgende Fehlermeldung:

Die/das folgende(n) Objekt(e) konnte(n) nicht gelöscht werden:

    cn=mygroup,cn=groups,dc=dirk,dc=ucs31,dc=qa: Das LDAP-Objekt konnte nicht identifiziert werden

Diese Gruppe hatte ich vor kurzem gelöscht (und sie hat natürlich nichts mit dem DNS-Eintrag zu tun). Dieses Verhalten habe ich hin und wieder beobachtet: Man löscht ein Objekt und beim Löschen eines anderen Objektes taucht dann diese Fehlermeldung auf. Übrigens ist das eigentliche Objekt und das dazugehörige Netzwerk-Objekt gelöscht worden.

Ich glaube, den Bug gibt es schon irgendwo. Aber ich finde ihn einfach nicht.
Comment 1 Dirk Wiesenthal univentionstaff 2012-12-10 18:35:22 CET
Der Fehler taucht auch beim Speichern auf. Und hier verhindert er tatsächlich ein Speichern des Objekts. Der Drucker existiert schon eine Weile nicht mehr. Da muss irgend ein merkwürdiges LDAP-Backlog noch irgend etwas gespeichert haben...

Workaround ist, einfach noch mal zu speichern. Dann klappt es meistens...

  File "/usr/lib/pymodules/python2.6/notifier/threads.py", line 82, in _run
    tmp = self._function()
  File "/usr/lib/pymodules/python2.6/notifier/__init__.py", line 104, in __call__
    return self._function( *tmp, **self._kwargs )
  File "/usr/lib/pymodules/python2.6/univention/management/console/modules/udm/__init__.py", line 345, in _thread
    raise UMC_OptionTypeError( _( 'Could not find a matching UDM module for the LDAP object %s' ) % ldap_dn )

UMC_OptionTypeError: Es konnte kein passendes UDM-Modul für das LDAP-Object cn=pri1118,cn=Drucker,cn=printers,dc=dirk,dc=ucs31,dc=qa gefunden werden
Comment 2 Dirk Wiesenthal univentionstaff 2012-12-10 19:52:45 CET
Jetzt hatte ich den Traceback von Comment 1 auch beim Löschen (und nicht die Fehlermeldung von Comment 1). Da wurde es mir zu bunt. Ich habe slapd neugestartet. Bisher keine Probleme.
Comment 3 Alexander Kläser univentionstaff 2013-01-02 14:46:52 CET
(In reply to comment #2)
> Jetzt hatte ich den Traceback von Comment 1 auch beim Löschen (und nicht die
> Fehlermeldung von Comment 1). Da wurde es mir zu bunt. Ich habe slapd
> neugestartet. Bisher keine Probleme.

Ist der Bug dadurch obsolet?
Comment 4 Dirk Wiesenthal univentionstaff 2013-01-02 15:26:26 CET
Nein, ich denke nicht. Die Fehlermeldung kommt hin und wieder. Ich glaube, sie tritt auf, wenn referenzierte Objekte gelöscht werden (aber was da genau der Grund ist, weiß ich nicht - ob da vielleicht beim Löschen was schief geht, oder aber das Transaktionslog danach nicht aktualisiert wird).

Ein slapd restart jedenfalls geht als Workaround durch. Der Bug bleibt aber bestehen.
Comment 5 Alexander Kläser univentionstaff 2013-01-02 18:21:11 CET
OK, dann sollten wir uns das noch einmal genauer anschauen.
Comment 6 Stefan Gohmann univentionstaff 2013-04-03 07:04:56 CEST
Kann das Problem reproduziert werden?
Comment 7 Tim Petersen univentionstaff 2013-11-25 10:07:00 CET
(In reply to Stefan Gohmann from comment #6)
> Kann das Problem reproduziert werden?

Ja. Anders als in Comment #4 beschrieben scheint das auch nichts mit den referenzierten Objekten zu tun zu haben.
Ein Kunde hatte das Verhalten in Verbindung mit Druckerobjekten gemeldet und ich konnte es folgendermaßen mehrfach reproduzieren:

1. Druckerfreigabe "testdrucker" erstellt (PDF-Drucker)
2. IP-Managed Client "testdruckerobjekt" erstellt
3. Druckerfreigabe gelöscht
4. IP-Managed Client gelöscht -> "Die/das folgende(n) Objekt(e)
konnte(n) nicht gelöscht werden:
cn=testdrucker,cn=printers,dc=tim,dc=domain: Das LDAP-Objekt konnte
nicht identifiziert werden
Ok"

Anders herum konnte ich es nicht reproduzieren. Allerdings erhielt ich bei anschließenden Tests beim Löschen eines neuen Benutzers die gleiche Meldung - hier wurde allerdings nicht nur "testdrucker" angeprangert sondern zusätzlich "testdruckerobjekt" - das scheint mir ein Caching-Problem...

Beim Kunden stapelte sich das bis zu 10 in der Form angezeigten Objekten auf (alle zuvor während der Session gelöscht, afaik alles Druckerobjekte).
Comment 8 Dirk Wiesenthal univentionstaff 2013-11-25 10:37:03 CET
Es _könnte_ sich um ein reines Frontendproblem handeln, weil einmal im Grid selektierte Objekte einfach munter weiter ans Backend gesendet werden.

D.h. ich lösche "cn=mygroup,cn=groups,$ldap_base" -> Ok

Ich öffne ein weiteres Modul und lösche "uid=myuser,cn=users,$ldap_base" -> Es wird sowohl der Benutzer als auch die Gruppe ans Backend gesendet. Da die Gruppe schon gelöscht wurde, kommt eine Fehlermeldung. Wurde das Verhalten in UCS < 3.2-0 gemeldet/reproduziert?

Alex hat _dieses eine, ganz spezielle_ Problem glaube ich zu 3.2-0 gelöst. Ob es das war, weiß ich nicht. Ist nur eine Vermutung (bzw. Hoffnung)
Comment 9 Tim Petersen univentionstaff 2013-11-25 12:26:15 CET
(In reply to Dirk Wiesenthal from comment #8)

Nach Update auf 3.2 kann ich das auf Anhieb nicht mehr reproduzieren.
Comment 10 Alexander Kläser univentionstaff 2013-11-25 14:43:23 CET
(In reply to Dirk Wiesenthal from comment #8)
> Es _könnte_ sich um ein reines Frontendproblem handeln, weil einmal im Grid
> selektierte Objekte einfach munter weiter ans Backend gesendet werden.
> 
> D.h. ich lösche "cn=mygroup,cn=groups,$ldap_base" -> Ok
> 
> Ich öffne ein weiteres Modul und lösche "uid=myuser,cn=users,$ldap_base" ->
> Es wird sowohl der Benutzer als auch die Gruppe ans Backend gesendet. Da die
> Gruppe schon gelöscht wurde, kommt eine Fehlermeldung. Wurde das Verhalten
> in UCS < 3.2-0 gemeldet/reproduziert?
> 
> Alex hat _dieses eine, ganz spezielle_ Problem glaube ich zu 3.2-0 gelöst.
> Ob es das war, weiß ich nicht. Ist nur eine Vermutung (bzw. Hoffnung)

Ja, das stimmt, das hört sich sehr nach dem Problem zusammen, das wir beobachtet und ich dann behoben hatte (in r45731). Schuld war hier eine statische Array-Referenz im JS-Code. Ich setze den Bug daher auf WORKSFORME. Sollte das Problem doch wieder reproduzierbar sein (auf Grund eines anderen Fehler), bitte wieder aufmachen.