Bug 19356 - join mit langer DN des joinusers schlägt fehl
join mit langer DN des joinusers schlägt fehl
Status: RESOLVED WONTFIX
Product: UCS
Classification: Unclassified
Component: Join (univention-join)
UCS 2.4
Other Linux
: P5 normal (vote)
: ---
Assigned To: Bugzilla Mailingliste
:
Depends on: 16211 19111
Blocks:
  Show dependency treegraph
 
Reported: 2010-08-10 17:38 CEST by Daniel Hofmann
Modified: 2016-04-25 07:52 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):
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Hofmann univentionstaff 2010-08-10 17:38:23 CEST
+++ This bug was initially created as a clone of Bug #16211 +++

Dazu sollte es einen automatischen Test geben:

+++ This bug was initially created as a clone of Bug #16210 +++

univention-join ermittelt die Bind-DN des joinusers per ldapsearch ohne auf den
Zeilenumbruch in langen Domains zu achten, die Domain ist dann für lange DNs
falsch und der join scheitert.

---------------------

Konnte das Problem, weswegen der Test ausgeschlossen wurde, im Zuge des Fixens von Bug 16211 nachstellen, und es verdient mit Sicherheit einen eigenen Bug:

Repro:

* 2.4-master aufsetzen (per update von der 2.3 qa-vm)
* 2.4-backup aufsetzen (per update von der 2.3 qa-vm)
* im backup den master als primären nameserver eintragen
* auf das ucs-test-skript 10_ldap/05join_with_long_bind_dn folgenden diff anwenden:
- while [ $i -le 10 ]
+ while [ $i -le 20 ]
das macht die verwendete DN für den Joinuser länger und ist offensichtlich (mit)-verantwortlich für das Problem
* !! von Backup und Master jeweils einen VM-Snapshot machen !! (zwar nicht nötig für die repro, aber gut, wenn man das mehrmals nachstellen will)
* !! eine ssh-shell auf dem Master öffnen !! (auch nicht nötig für die Repro, aber hilfreich für die Fehlersuche, da man sich hinterher nicht mehr einloggen kann)
* das Test-Skript auf dem Backup ausführen

Der Join verläuft dann scheinbar erfolgreich, beendet sich aber nicht komplett. Deutlicher wird das Problem, wenn man anschließend auf dem Master einen beliebigen ldapsearch ausführt, da diese zwar alle brav ihre Arbeit verrichten, aber nicht zur Kommandozeile zurückkehren. Vermutlich funktioniert jetzt sogut wie nichts mehr auf dem Master, was schon beim ssh-login anfängt. Habe es trotz ssh-shell auch noch nicht geschafft, ohne vm-revert aus diesem verzwickten Zustand wieder rauszukommen.
Comment 1 Stefan Gohmann univentionstaff 2016-04-25 07:52:25 CEST
This issue has been filed against UCS 2.4.

UCS 2.4 is out of maintenance and many UCS components have vastly changed in
later releases. Thus, this issue is now being closed.

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