Neben mir waren auch noch andere Benutzter betroffen. Letztendlich wurde das Problem durch Linbo 4.2.14 verursacht und ein Rollback auf 4.2.13 löste das Problem.
Nun scheint sich durch diesen Workaround jedoch ein anderes Problem zu ergeben.
Zwar bekommen die Clients nun auf der Betriebssystemebene alle wieder eine IP, dafür bekommt Linbo beim Start aber keine IP mehr.
Ich wollte gerade eine neue Software über ein neues Image verteilen, was aber nun nicht möglich ist. Linbo zeigt auf allen Rechnern OFFLINE! Vor dem Rollback auf 4.2.13 waren sie noch alle ONLINE…
Mir ist aufgefallen, dass der Server durch das Downgrade nun (wie gewollt) Linbo 4.2.13 verwendet auf allen Clients aber noch Linbo 4.2.14 läuft. Könnte das die Ursache sein?
Wie kann ich auf den Clients Linbo downgraden?
Habt ihr andere Ideen?
Liebe Grüße aus dem Westerwald
Ralf
P.S. mir ist außerdem aufgefallen, dass die Vergabe einer IP beim Start des Rechners per PXE wirklich lange dauert. Er bekommt aber nach ca. 20s eine IP.
Linbo scheint nicht zu warten. In der Konsole erscheint bereits nach wenigen Sekunden „eth0 no IP“. Lässt sich hier die Wartezeit verlängern?
Problem erstmal gelöst:
Ich hatte im Zuge des Workarounds dhcpretry = 10 gesetzt.
Nun habe ich es wieder auf 20 gestellt und schon bekommt Linbo auf den Clients wieder eine IP.
Bleibt natürlich die Frage offen, warum mehr als 10 retrys notwendig sind
Das wäre ärgerlich, da in den Sommerferien alles erneuert wurde. Neue Verkabelung, neuer Server, neuer Switch (Ubiquiti)… eigentlich alles vom Feinsten.
Wenn ich auf einem Client den DHCP teste, dann bekomme ich übrigens unverzüglich eine Antwort:
[jardon@LehrerPC03 ~]$ sudo nmap --script broadcast-dhcp-discover
Starting Nmap 7.60 ( https://nmap.org ) at 2024-11-12 10:22 CET
Pre-scan script results:
| broadcast-dhcp-discover:
| Response 1 of 1:
| IP Offered: 172.16.1.105
| DHCP Message Type: DHCPOFFER
| Server Identifier: 172.16.1.1
| IP Address Lease Time: 5m00s
| Subnet Mask: 255.255.255.0
| Router: 172.16.1.253
| Domain Name Server: 172.16.1.1
| Hostname: pxeclient
| Domain Name: linuxmuster.lan
| Broadcast Address: 172.16.1.255
| NTP Servers: 172.16.1.1
| NetBIOS Name Server: 172.16.1.1
|_ X Window Font Server: 172.16.1.1
Nmap scan report for server.linuxmuster.lan (172.16.1.1)
Host is up (0.00015s latency).
[...]
Nmap done: 1 IP address (1 host up) scanned in 2.03 seconds
Der komplette Scan dauert nur 2s, d.h. der DHCP hat direkt geantwortet.
Warum warte ich dann bei PXE/Linbo über 20s???
NACHTRAG:
Noch ein Test mit iperf:
[jardon@LehrerPC03 ~]$ iperf -c server
------------------------------------------------------------
Client connecting to server, TCP port 5001
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
[ 3] local 172.16.1.54 port 50314 connected with 172.16.1.1 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 1.09 GBytes 936 Mbits/sec
dass bei euch alles neu ist hatte ich mir fast schon gedacht.
Solche Dinge fallen immer erst nach einer Weile auf.
Wurden die Prioritäten der unifi Switches für das RSTP Protoboll ordentlich gesetzt, wie hier beschrieben?
Ich habe jetzt die Schul-IT der Kreisverwaltung um einen Termin gebeten.
Seit der Umstellung/Neuinstallation habe ich nämlich keinen Zugriff mehr auf die Router
Sehr hinderlich…
Danke jedenfalls für den Tipp! Sobald die hier waren melde ich mich nochmals mit einem Feedback!
Liebe Grüße
Ralf
Hallo Holger,
der Hinweis mit STP war gut!
Die Kreisverwaltung hat heute morgen STP deaktiviert (oder jedenfalls irgendwie verändert) und nun bekommen die Clients die IP per PXE in ca. 2-3s anstatt 20-30s.
Vielen Dank!
Liebe Grüße
Ralf
… ist ein Klassiker: vor allem in eurer Konstellation:
„Jemand“ hat uns ein neues Netzwerk hingestellt: jetzt dürfen wir nix mehr.
Da geht man davon aus, dass „Jemand“ Jemanden beauftragt hat, der sich auskennt und das ordentlich macht … meist werden aber nur Switches hingestellt, die managementerreichbarkeit eingestellt und fertig. Das geht aber nur bei sehr kleinen Netzen gut …
Netzwerk ist halt sehr viel mehr als nur Kabel von A nach B ziehen und in Switches stecken. Das einstellen von SpanningTree gehort zur Ersteinrichtung dazu: und das geht aber nur in ZUsammenarbeit mit dem Netzadmin vor Ort, weil der weiß, wie das Netz aufgebaut ist, wo das Hauptgateway sitzt, an welchem Switch der Server hängt usw.
Hatten die euch ins Boot geholt? Oder habt ihr einfach „neue Switches“ bekommen?
Du hast doch bei meinem Einwurf, dass das Netz lahm ist, auch erstmal gedacht… das kann nicht sein.
Ich schreib das nicht hier hin, weil ich da Jemand den schwarzen Peter zustecken will oder weil ich über Jemand schimpfen will, sondern dass jedem bewußt wird, wo da Fußangeln liegen und dass das „von Außen“ nicht ohne weiteres gemacht werden kann: ihr müßt da im Boot sein, sonst kommt es halt zu Problemen.
Ihr hattet jetzt ja noch Glück, dass die nicht gleich gesagt haben: „nee … an den neuen Switches kanns nicht liegen, die sind super schnell“ (hab ich auch schon erlebt …).
