An die #Linuxmuster Experten im #fediLZ: Unser Schulserver spinnt seit einigen Monaten rum, oft bekommen die Clients keine IP über DHCP, manchmal muss man zwei-dreimal neustarten.

@mg_1972

Öh, spannend aber schwierig, zu diagnostizieren, vor allem weil ihr ja wahrscheinlich nicht an den Server rankommt.

Rogue DHCP ist das erste was mir einfällt. Kann aber auch falsch konfiguriertes VLAN oder "komplexes Zeug" sein.

@DanKen Doch, an den Server komme ich ran. Und anscheinend wird vom Schulträger mittlerweile inoffiziell erwartet, dass jemand an der Schule den in Eigenregie wartet/pflegt… dafür wurde ich natürlich nie ausgebildet. Ich traue mir das zwar durchaus zu, aber wenn etwas schief geht, ist das Geschrei groß und ich der „Buhmann“.

@mg_1972 paedML und MNS-Pro hier - Was sagt das Logfile des DHCP? Keine Adressen für Clients könnte keine freien IPs mehr sein, Client kommen aus dem falschen Subnetz, Fritz!box (immer gerne genommen weil mal eben ein eigenes WLan im Klassenraum gebraucht wird) mit aktiven DHCP steht im Lan und ist näher an den Clients als der DHCP des Servers?

@mg_1972

Also sorry, ohne Zertifikat/Training/Einweisung würde ich niemals einen Server anfassen - du hast ja wahrscheinlich nicht mal eine Dokumentation, wie das eingerichtet ist.

Aber Cool, das ihr das zumindest dürft. Ich mach die IT an unserer Schule und bekomme für so was keine Passworte oder Berechtigung.

Findest du, Rogue-DHCP hört sich nach dem an, was bei euch passiert?

@DanKen Nein, das glaube ich weniger. Ich könnte mir sogar vorstellen, dass ein Server-Reboot (mache ich morgen) die Probleme schon löst. Linuxmuster als Open Source Schulserver-Lösung ist im Netz sehr gut dokumentiert und hat ein ausgezeichnetes Nutzerforum. Das Update von v7.1 auf v7.2 ist nicht so anspruchsvoll, ähnlich wie ein Ubuntu Update auf einem einfachen Client. Das kriege ich hin. Für das Update auf v7.3 allerdings werde ich ein Ticket aufsetzen.

https://docs.linuxmuster.net/de/v7.2/migration/upgrade.html

@1nine6three In das Logfile des DHCP gucke ich morgen. Die IPs sind ja statisch vergeben, müssen aber beim Netzwerkstart des Client vom DHCP „geholt“ werden. Grundsätzlich funktioniert es ja auch, phasenweise aber dann auch wieder nicht (OFFLINE in Linbo).

@1nine6three @mg_1972

Ja, auf Rogue- DHCP hatte ich auch getippt. Aber klar, ein kleines Subnetz könnte auch sein.

So am Rande: Ich hatte mal einen kleinen AP, also keine Fritzbox, sondern so ein kleines China-Ding; Auch das konnte man als DHCP-Server konfigurieren.

@mg_1972 Ich weiß nicht, wie du da verantwortlich bist, aber an deiner Stelle würde ich da ohne Ahnung nicht an den IP-Configs von Servern rumbasteln, die nicht in deiner Verantwortung stehen

@mg_1972
Ferndiagnose von Netzwerkproblemen ist schwierig.

Was sagt denn das DHCP Log am Server? Sieht man da Anfragen?

@mg_1972 Moment. Der DHCP hat Reservierungen auf Basis der Client MAC-Adressen oder haben die Clients statische IPs auf deren NICs?

Da kommt mir die Idee eines Konflikts bei IP und/oder Mac-Adresse eines Gerätes, das nicht immer im LAN aktiv ist. Das würde den Random-Faktor erklären. Muss auch im Log stehen.

@1nine6three per MAC-Adresse… Konflikte würden bei import_workstations sofort angezeigt. Daran kann es nicht liegen. Es kann auch ein zu niedriger dhcp-retry Wert sein, das werde ich aber erst dann testen, wenn ich auf dem Server alles Notwendige aktualisiert habe. Da wurden über zwei Jahre keine Updates mehr gemacht. Eventuell reicht auch schon ein Reboot des Servers. Ich werde es morgen sehen

@mschfr Das sehe ich grundsätzlich genauso. Aber wenn man dann nur zwei Optionen hat: 1) Die Rechner in den Computerräumen sind kaum sinnvoll einzusetzen und man wartet monatelang auf den Support, trotz Ticket. 2) Man versucht über die Expertenforen und die Linuxmuster-Dokumentation die Fehlerursachen einzugrenzen und „harmlose“
Lösungen auszuprobieren (dhcpretry hochsetzen z.B.).

Dann nehme ich notgedrungen Option 2, da Option 1 den Informatikunterricht beeinträchtigen würde.

@HLunke das werde ich mir morgen in Ruhe anschauen

@mg_1972

Ist jetzt ein bisschen Geraten, aber wenn zu viele (WLAN-) Clients am Server hängen und der IP-Bereich der lokalen Adressen zu klein gewählt ist, können solche Probleme durchaus auftreten. Ein Neustart könnte das Problem demnach auch temporär lösen. - Man bedenke, dass der Abruf vielen IP-Adressen auch ein Angriffsvektor sein kann um das Schulnetzwerk bewusst lahmzulegen. Zur Diagnose auf einem Client ist https://www.wireshark.org/download.html dein Freund.