Univention Bugzilla – Bug 28137
Netzwerk-Objekt vergibt bereits manuell vergebene Adresse erneut
Last modified: 2012-12-12 21:10:19 CET
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.
(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.
(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.
Im Forum an Ticket #2012101821003893 aufgefallen.
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?
(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
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.
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?
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
(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).
(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.
Da der Teil ausgelagert wurde, ist der Rest OK.
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".