Die Suche hier an Firewalleinstellungen ist nicht zielführend. Wenn das WOL Paket vom Server schon über die Netzgrenzen hinweg beim Client ankommt, dann funktioniert das auch.
Linbo verwendet intern glaube ich wakeonlan, genau wie von dir getestet. Welche Version von Linbo kommt denn zum Einsatz? An der Stelle wurde in letzter Zeit viel geschraubt, es ist nicht ausgeschlossen, dass es hierbei ein Bug gibt.
Ist denn der Client auch mit linuxmuster-import-devies aufgenommen? Seit kurzer Zeit werden hierfür Informationen aus dem AD genommen statt direkt aus der devices.csv.
Hallo Till,
sorry, aber ich habe oben alles beschrieben (VLAN, wakeonlan funktioniert, linbo mit IP garnicht, linbo mit hostname auch nicht, etc). Alois scheint das nicht reichtig gelesen zu haben.
Erst Du scheinst das Problem verstanden zu haben:
Die Suche hier an Firewalleinstellungen ist nicht zielführend. Wenn das WOL Paket vom Server schon über die Netzgrenzen hinweg beim Client ankommt, dann funktioniert das auch.
Warum geht wakeonlan und warum linbo NICHT! Diese Frage habe ich mehrfach gestellt und Sie ist von Alois ignoriert worden.
Deswegen meine forsche Frage an Alois. Sorry dafür. Bin zur Zeit einwenig genervt, weil mit Linuxmuster scheinbar nix richtig läuft. Was aber läuft ist die Zeit bis Ende der Ferien. Bis dahin soll logosrv abgelößt sein. Aber die einfachsten Dinge wie Drucken oder wol scheinen nicht zu funkionieren. Dabei haben wir alles nach Anleitung gemacht und sogar schon eine teuere Schulung hinter uns.
Ich kann den Unmut ja verstehen. Dass du hier in ein paar Probleme läufst, kann vorkommen. Linuxmuster 7.1 ist allerdings auch immer noch offiziell im Beta Status. Das hier die ein oder andere Funktion schiefläuft, kann also passieren. Das sollte so auch bei der Schulung komuniziert worden sein.
Von welcher Schulung sprechen wir denn hier? Die Dienstleisterschulung für LMN7? Wenn die Zeit drängt und du unzufrieden mit dem Support der Community bist (welche hier im Übrigen alle Ehrenamtlich in Ihrer Freizeit versuchen zu helfen), gibt es auch die Möglichkeit kommerziellen Support hinzuzukaufen. Die Händlerliste findet sich auf der Linuxmuster Homepage. Ich selber bin für die Firma Netzint tätig und mache auch die Schulungen. Daher sollten wir uns zumindest mal getroffen haben.Die Supportmöglichkeiten sollten auch bei der Schulung erklärt worden sein, wenn dort was nicht angekommen ist dann gerne melden.
zuallererst: ich kenne leider nicht die Lösung zu Deinem Problem, möchte aber ein paar Dinge anmerken:
Nun ja…: die Information, dass Du Deine Netze getrennt hast, konnte ein aufmerksamer Leser des Threads überhaupt erst aus dem ip a Output im 12. Post herauslesen! Welche VLANs Du da verwendest (auch wenn das nicht wichtig ist), erst in Post 16.
Solche (in diesem Fall wichtigen!) Informationen hätte ich von Dir ganz zu Anfang erwartet.
Nun sind Deine Erwartungshaltungen ja aber auch nicht ganz gering: ich kann zwar gut nachvollziehen, dass Du angesichts der schwindenden Zeit im Stress bist und dringend eine Lösung suchst. Das Feature, alle Clients remote (scriptgesteuert) aufzuwecken, ist aber zwar „nice to have“, darf aber kein Showstopper für den GoLive der lmn7.1 sein!? Das kannst Du doch auch in ein paar Wochen/Monaten noch nachziehen, wenn die kritischen Dinge gelöst sind!?
Und wie Andreas bereits sagte: wir sind hier zu 99% ehrenamtliche Supporter, die das gerne nach bestem Wissen und Gewissen und in ihrer Freizeit machen. Oder hast Du mit Alois einen Dienstleistervertrag und wirfst ihm pro Tag 1000€ in den Rachen? Dann würde ich auch Ansprüche stellen. Andernfalls sollte man sich aus o.g. Gründen da vielleicht etwas diplomatischer ausdrücken.
Und falls Dir der manchmal etwas langsame (wobei ich denke, wir sind da ganz gut) ehrenamtliche Support nicht genügt, hat Dir Andreas ja bereits angeboten, dass u.a. die Firma netzint (gegen Einwurf kleiner Münzen) schnellen und professionellen Support anbietet.
Just my 0,02$ und nichts für ungut, viele Grüße,
Jochen
Wie auch immer. Ich habe mir nun den Sourcecode von linbo-remote mal angeschaut und die zwei Fehler gefunden:
Fehler: linbo-remote mit einer IP nach dem -i wird mit not a pxe host beendet. Also z.B. linbo-remote -i 10.101.199.182 → not a pxe host
Das liegt daran, dass nslookup den Hostnamen in Kleinbuchstaben auflöst, der PC in der devices.csv ($WIMPORTDATA) aber in Großbuchstaben steht und hinter dem zweiten grep kein -i.
Lösung:
A.) entweder Unterbindet man die Registierung von PC’s mit Großbuchstanben in der GUI und in Limbo
oder
B:) Man entnimmt den Hostnamen aus der devices.csv statt mit nslookup
oder
C:) man schreibt hinter dem zweiten grep ein -i
Ich habe mich für Lösung C entschieden.
Meine geänderte Zeile lautet statt diese Zeile pxe="$(grep -i ^[a-z0-9] $WIMPORTDATA | grep ";$HOSTNAME;" | awk -F\; '{ print $11 }')"
nun wie folgt pxe="$(grep -i ^[a-z0-9] $WIMPORTDATA | grep -i ";$HOSTNAME;" | awk -F\; '{ print $11 }')"
Damit ist Fehler 1 gelößt.
Fehler: linbo-remote ruft wakeonlan NICHT mit -i gefolgt mit der IP des hosts auf. Bzw. mit Parameter -u schon, aber dann nur die Brodcastadresse.
Lösung: Änderung von linbo-remote in so fern, dass statt
# use broadcast address
if [ -n "$USEBCADDR" ]; then
if validip "$i"; then
hostip="$i"
else
hostip="$(get_ip "$i")"
fi
bcaddr=$(get_bcaddress "$hostip")
[ -n "$bcaddr" ] && WOL="$WOL -i $bcaddr"
fi
nun dort steht:
if validip "$i"; then
hostip="$i"
else
hostip="$(get_ip "$i")"
fi
# use broadcast address
if [ -n "$USEBCADDR" ]; then
bcaddr=$(get_bcaddress "$hostip")
[ -n "$bcaddr" ] && WOL="$WOL -i $bcaddr"
else
[ -n "$hostip" ] && WOL="$WOL -i $hostip"
fi
Damit ist Fehler 2 gelößt
Ich denke, dass sollte im Quellcode von Linuxmuster übernommen werden. Vielleicht hilft es ja.
vielen Dank für das Debuggin MIT Lösung: tolle Sache
Dass der Fehler von den „alten Hasen“ die linbo 4 seit etlichen Monaten
produktiv einsetzten, nicht gefunden wurde, kann ich auch erklären: wir
nutzen alle immer nur Kleinbuchstaben bei den Hosts.
Ich weiß nicht mehr, was das ausgelößt hat, aber das war auch imemr mal
eine Empfehlung.
In die Doku und in die WebUI hat es diese Empfehlung bisher aber nicht
geschafft.
Es sollte unterbunden werden.
Gleichzeitig sollte es aber linbo trotzdem richtig machen.
Damit haben wir ja die Lösung gefunden, in der Richtung hatte ich auch das Problem vermutet. Wie schon gesagt, früher wurde nicht über nslookup der Name aufgelöst, das kam mit der 7.1 hinzu.
Ich finde nicht, dass das dauerhaft in der Doku stehen sollte. Wenn es kein Problem gibt sollte es auch nicht dokumentiert werden, das ist nur ein Workaround zu einem Problem, das es gar nicht geben sollte.
Leider zu früh gefreut. O.g. Lösung funktioniert auch nicht zuverlässig.
wakeonlan -i mit ipdresse funktioniert nur, wenn die firewall (hier: Opensense) den entsprechenden PC noch in der ARP Tabelle hat. (Schnittstellen->Diagnose->ARP Tabelle). Wenn der PC aber aus ist, verschwindet der PC nach ein paar Stunden jedoch automatisch aus der ARP Tabelle der firewall. Opensense weiß dann wohl nicht ins welches Netz das wakeonlan-paket gehört und verwirft es. Somit funktioniert dann auch wakeonlan -i mit ipdresse NICHT mehr. Natürlich auch linbo-remote nicht mehr
Wir haben weiter nach Lösungen gesucht:
Nun kann man ja auch bei wakeonlan -i eine Brodcastadresse angeben. Z.B. wakeonlan -i 10.101.255.255. Sollte normalerweise funktionieren, da die Firewall anhand Ihrer Schnittstellen das passende Netz herrausfinden könnte. Macht Opensense aber nicht. Auch das Brodcast-wakeonlan-Paket verwirft sie.
Lösung wäre hier, das man in der ARP-Tabelle von Opensense die Netze mit den entsprechenden Brodcastadressen neustartfest einträgt. Das sieht aber die WebGUI von Opensense nicht vor. Somit muss man das über die Konsole machen: Login mit root → 8 drücken → shell → cd /usr/local/etc/rc.syshook.d/start/ → dann dort für jedes Netz eine Datei (z.B. 99-broadcast-vlan101) erzeugen (Brodcastadresse entsprechend anpassen)
#!/bin/sh
arp -S 10.101.255.255 FF:FF:FF:FF:FF:FF
Damit funktioniert wakeonlan -i 10.101.255.255 zuverlässig.
Die Frage bleibt, wie machen wir das nun bei linbo-remote? Nun linbo-remote hat ja den Parameter -u. Doch fragen wir uns, warum wakeonlan nicht immer mit der Brodcastadresse aufrufen? Wir haben da keine Nachteile gesehen und somit nun in linbo-remote statt
# use broadcast address
if [ -n "$USEBCADDR" ]; then
bcaddr=$(get_bcaddress "$hostip")
[ -n "$bcaddr" ] && WOL="$WOL -i $bcaddr"
else
[ -n "$hostip" ] && WOL="$WOL -i $hostip"
fi
komplett auf den else-zweig verzichtet:
# # use broadcast address
# if [ -n "$USEBCADDR" ]; then
bcaddr=$(get_bcaddress "$hostip")
[ -n "$bcaddr" ] && WOL="$WOL -i $bcaddr"
# else
# [ -n "$hostip" ] && WOL="$WOL -i $hostip"
# fi
Ich glaube das kann man so in git übernehmen plus den Parameter -u komplett rausimplentieren.
Oder sieht da einer Nachteile?
das von " anacronataff" beobachtete Problem sollte ja nur bei einer Segmentierung der Netze auftreten (und nur dann benötigt man „-i“ bei wakeonlan) , dürfte dann aber auch andere Router betreffen. Wenn man die Broadcastadresse verwendet, hat man auf jeden Fall bessere Chancen, dass das Paket durchkommt.
Mit der IP-Adressen funktioniert das nur dann zuverlässig, wenn im Router eine statische ARP-Tabelle für alle Rechner vorhanden ist. Das steht auch so in der Manpage.
Wakeonlan sollte also immer die Broadcastadresse verwenden, unabhängig von der Netzstruktur. Das „-u“ sollte also das Standardverhalten sein. Wenn überhaupt, dann sollte die IP-Adressen nur dann verwendet werden, wenn man es explizit angibt.
Die Funktion validip ist nicht sinnvoll für Broadcastadressen, da das letzte Oktett nicht 255 sein darf, laut Funktion. Generell sind alle 255er ausgeschlossen?
/usr/share/linuxmuster/linbo/helperfunctions.sh
# check valid ip
validip(){
(expr match "$1" '\(\([1-9]\|[1-9][0-9]\|1[0-9]\{2\}\|2[0-4][0-9]\|25[0-4]\)\.\([0-9]\|[1-9][0-9]\|1[0-9]\{2\}\|2[0-4][0-9]\|25[0-4]\)\.\([0-9]\|[1-9][0-9]\|1[0-9]\{2\}\|2[0-4][0-9]\|25[0-4]\)\.\([1-9]\|[1-9][0-9]\|1[0-9]\{2\}\|2[0-4][0-9]\|25[0-4]\)$\)') &> /dev/null || return 1
}