Bug 28137 - Netzwerk-Objekt vergibt bereits manuell vergebene Adresse erneut
Netzwerk-Objekt vergibt bereits manuell vergebene Adresse erneut
Status: CLOSED FIXED
Product: UCS
Classification: Unclassified
Component: UDM (Generic)
UCS 3.0
Other Linux
: P3 normal (vote)
: UCS 3.1
Assigned To: Lukas Walter
Stefan Gohmann
: interim-3
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-08-02 12:35 CEST by Ingo Steuwer
Modified: 2012-12-12 21:10 CET (History)
6 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 Ingo Steuwer univentionstaff 2012-08-02 12:35:32 CEST
Das Netzwerk-Objekt berücksichtigt beim Anlegen neuer Rechner keine Konflikte in der IP-Adresse mit manuell (bei Rechnern ohne Netzwerkobjekt) vergebenen Adressen.

Vorgehen:

- Rechner mit IP 10.202.110.200 und 10.202.110.201 angelegt
- Netzwerk-Objekt mit Range 10.202.110.200-10.202.110.250 angelegt
- weiteren Rechner angelegt und Netzwer-Objekt zugewiesen
-> der Rechner bekommt die erste IP des Range (10.202.110.200), beim Speichern gibt es entsprechend die Meldung das die IP schon vergeben ist.

Scheinbar verlässt sich das Netzwerk-Objekt ausschließlich auf die intern gespeicherte zuletzt per Netzwerk-Objekt zugeordnete IP.
Comment 1 Alexander Kläser univentionstaff 2012-08-02 12:40:25 CEST
(In reply to comment #0)
> ...
> Scheinbar verlässt sich das Netzwerk-Objekt ausschließlich auf die intern
> gespeicherte zuletzt per Netzwerk-Objekt zugeordnete IP.

Ja, ich denke das ist das Verhalten. Ich gehe davon aus, dass dieses Verhalten in UCS 2.4 bereits auch schon so war. Bitte korrigiere mich, wenn dies falsch ist. Ich markiere den Bug einmal als ein Enhancement.
Comment 2 Stefan Gohmann univentionstaff 2012-08-13 06:48:57 CEST
(In reply to comment #1)
> (In reply to comment #0)
> > ...
> > Scheinbar verlässt sich das Netzwerk-Objekt ausschließlich auf die intern
> > gespeicherte zuletzt per Netzwerk-Objekt zugeordnete IP.
> 
> Ja, ich denke das ist das Verhalten. Ich gehe davon aus, dass dieses Verhalten
> in UCS 2.4 bereits auch schon so war. Bitte korrigiere mich, wenn dies falsch
> ist. Ich markiere den Bug einmal als ein Enhancement.

Wenn es in 2.4 auch schon so war, dann ist es ein Bug. Es darf keine doppelten IPs geben, schon gar nicht, wenn das System die IPs selbst vergibt. Nach jeder nächsten IP sollte ein Lock der IP durchgeführt werden, IMHO war das früher auch so.
Comment 3 Tim Petersen univentionstaff 2012-10-23 12:04:53 CEST
Im Forum an Ticket #2012101821003893 aufgefallen.
Comment 4 Tim Petersen univentionstaff 2012-10-23 12:18:43 CEST
Am Forenticket fiel hierzu noch folgendes auf:
Passt man nachträglich an einem Netzwerk die Startaddresse an und wechselt später wieder zurück, "vergisst" das System scheinbar bekannte Adressen.

Beispiel:
1. Startaddresse Netzwerk 10.200.11.1
2. zugewiesene Addresse Rechner-> 10.200.11.1
3. Startadresse Netzwerk 10.200.12.1
4. zugewiesene Addresse Rechner -> 10.200.12.1
5. Startaddresse Netzwerk wieder zurück auf 10.200.11.1
6. zugewiesene Addresse Rechner -> wieder 10.200.11.1 -> doppelte IP

Was spricht dagegen, hier neben einem "Locking" einfach im LDAP nach den aRecords zu schauen?
Comment 5 Lukas Walter univentionstaff 2012-10-25 11:08:27 CEST
(In reply to comment #0)
> Das Netzwerk-Objekt berücksichtigt beim Anlegen neuer Rechner keine Konflikte
> in der IP-Adresse mit manuell (bei Rechnern ohne Netzwerkobjekt) vergebenen
> Adressen.
> Scheinbar verlässt sich das Netzwerk-Objekt ausschließlich auf die intern
> gespeicherte zuletzt per Netzwerk-Objekt zugeordnete IP.

Netzwerkobjekte verfügen jetzt über eine Methode welche die intern gespeicherte nächste freie IP aktualisiert und dabei alle im LDAP bereits vergebenen aRecords berücksichtigt. Die Methode wird aufgerufen ehe eine IP aus dem Netzobjekt bezogen wird.


(In reply to comment #4)
> Am Forenticket fiel hierzu noch folgendes auf:
> Passt man nachträglich an einem Netzwerk die Startaddresse an und wechselt
> später wieder zurück, "vergisst" das System scheinbar bekannte Adressen.

Wenn sich die IP Range ändert wird die intern vorgehalten nächste verfügbare IP jetzt immer auf die erste Adresse der IP-Range mit der geringsten Startadresse gesetzt. Da jetzt vor der Vergabe einer IP immer geprüft wird ob sie bereits vergeben ist stellt das kein Problem dar und führt dazu, dass immer die Adresse vergeben wird bei der möglichst viele Hostbits auf 0 stehen und die zugleich noch frei ist.

Darüber hinaus wurde der Fix für Bug #18581 korrigiert - das hat bisher nie wirklich funktioniert und wurde hier angepasst weil die betroffene Codestelle für diesen Bug ohnehin neugeschrieben wurde.
-> Es Adressen die auf "1" oder "254" enden werden nun nicht mehr vorgeschlagen da häufig für Router verwendet.





univention-directory-manager-modules (8.0.70-1) unstable; urgency=low
  * do not return ip addresses which are already in use
    (Bug #28137)

univention-management-console-module-udm (3.0.36-1) unstable; urgency=low
  * refresh network objects nextIp before transmitting it's value
  * do not send "increaseCounter" field in udm/network umcp command anymore
    (it's obsolete)
  (Bug #28137)

svn 36610
Comment 6 Tim Petersen univentionstaff 2012-10-26 11:21:29 CEST
Aus dem Forum:
"ich habe gerade in den Bug geschaut, die Problematik mit der Startadresse gestaltet sich ein wenig anders, bitte entschuldigen Sie die Unklarheit:

1. Startaddresse Netzwerk 10.200.11.1
2. zugewiesene Addresse Rechner-> 10.200.11.1
3. Startadresse Netzwerk 10.200.12.1
4. zugewiesene Addresse Rechner -> 10.200.12.1
5. Startaddresse Netzwerk wieder zurück auf 10.200.11.1
6. zugewiesene Addresse Rechner -> immer noch 10.200.12.1
--- Das ganze kann jetzt so fortgeführt werden
7. Startadresse Netzwerk 10.200.13.1
8. zugewiesene Addresse Rechner -> 10.200.13.1
9. Startaddresse Netzwerk wieder zurück auf 10.200.11.1
10. zugewiesene Addresse Rechner -> nun bei 10.200.13.1

Die Startadresse wird also nicht korrekt zurückgesetzt."

-> Könnte man in der QA noch einmal kurz prüfen, sofern das dem bisher geschilderten Verhalten widerspricht.
Comment 7 Alexander Kläser univentionstaff 2012-11-01 13:03:41 CET
Für die QA, bitte die folgenden Fälle auch überprüfen:
* Was passiert, wenn keine IP-Adresse in der Range mehr frei ist? (Endlosschleife?)
* Wird beim Durchzählen korrekt wieder vorne angefangen?
Comment 8 Stefan Gohmann univentionstaff 2012-11-15 16:19:59 CET
Es wird jetzt immer wieder bei der ersten Adresse angefangen: OK

Bereits vergebene Adressen werden nicht mehr vorgeschlagen: OK

Wenn keine Adresse mehr verfügbar ist wird ein Traceback angezeigt: FAILED

Die Ausführung des Kommandos udm/network ist fehlgeschlagen:

Traceback (most recent call last):
  File "/usr/lib/pymodules/python2.6/univention/management/console/modules/__init__.py", line 204, in execute
    func( request )
  File "/usr/lib/pymodules/python2.6/univention/management/console/modules/udm/__init__.py", line 584, in network
    obj.refreshNextIp()
  File "/usr/lib/pymodules/python2.6/univention/admin/handlers/networks/network.py", line 236, in refreshNextIp
    raise univention.admin.uexceptions.nextFreeIp
nextFreeIp

Changelog: OK
Comment 9 Lukas Walter univentionstaff 2012-11-19 16:23:24 CET
(In reply to comment #8)
> Wenn keine Adresse mehr verfügbar ist wird ein Traceback angezeigt: FAILED
> 
> Die Ausführung des Kommandos udm/network ist fehlgeschlagen:
> 
> Traceback (most recent call last):
>   File
> "/usr/lib/pymodules/python2.6/univention/management/console/modules/__init__.py",
> line 204, in execute
>     func( request )
>   File
> "/usr/lib/pymodules/python2.6/univention/management/console/modules/udm/__init__.py",
> line 584, in network
>     obj.refreshNextIp()
>   File
> "/usr/lib/pymodules/python2.6/univention/admin/handlers/networks/network.py",
> line 236, in refreshNextIp
>     raise univention.admin.uexceptions.nextFreeIp
> nextFreeIp

Es ist mit der UMC derzeit nicht möglich an dieser Stelle eine angemessene Fehlermeldung in Form eines Popups zu erzeugen (siehe Bug #29284).
Comment 10 Lukas Walter univentionstaff 2012-11-19 16:34:22 CET
(In reply to comment #9)
> (In reply to comment #8)
> > Wenn keine Adresse mehr verfügbar ist wird ein Traceback angezeigt: FAILED
> > 
> > Die Ausführung des Kommandos udm/network ist fehlgeschlagen:
> > 
> > Traceback (most recent call last):
> >   File
> > "/usr/lib/pymodules/python2.6/univention/management/console/modules/__init__.py",
> > line 204, in execute
> >     func( request )
> >   File
> > "/usr/lib/pymodules/python2.6/univention/management/console/modules/udm/__init__.py",
> > line 584, in network
> >     obj.refreshNextIp()
> >   File
> > "/usr/lib/pymodules/python2.6/univention/admin/handlers/networks/network.py",
> > line 236, in refreshNextIp
> >     raise univention.admin.uexceptions.nextFreeIp
> > nextFreeIp
> 
> Es ist mit der UMC derzeit nicht möglich an dieser Stelle eine angemessene
> Fehlermeldung in Form eines Popups zu erzeugen (siehe Bug #29284).

Dieser Teil wird daher ausgelagert nach Bug #29285.
Comment 11 Stefan Gohmann univentionstaff 2012-11-20 07:00:07 CET
Da der Teil ausgelagert wurde, ist der Rest OK.
Comment 12 Stefan Gohmann univentionstaff 2012-12-12 21:10:19 CET
UCS 3.1-0 has been released: 
 http://forum.univention.de/viewtopic.php?f=54&t=2125

If this error occurs again, please use "Clone This Bug".