Server bei Inaktivität in S5?

[dumbshitaward]

AW: Server bei Inaktivität in S5?

Okay, jetzt bin ich auf ein neues Problem gestoßen, hatte mich schon so gefreut, dass alles jetzt liefe.


Das WOL Script auf der FritzBox macht mir noch ein wenig Kummer (ich hab noch nicht mal überprüft, obs auch automatisch startet, immer ein Ding nach dem anderen).

Das Problem ist folgendes: alle externen Clients, die übers Internet auf den Server zugreifen können wunderbar den Server per WOL hochfahren, aus dem LAN heraus klappt das aber nicht. Wenn ich MGCamd anweise über meine dyndns-Adresse zum Server zu verbinden klappt erwartungsgemäß auch. Soweit gäbe es da schon mal einen Workaround, aber inzwischen habe ich mich in diese Sache ein wenig reingesteigert und suche nun nach eine Lösung dafür.

Den "Schuldigen" habe ich womöglich auch schon identifiziert (im Script rot markiert). tcpdump horcht wie befohlen nur auf dem dsl-Port der Fritzbox. Allerdings scheine ich es nicht hinzubekommen, dass das Ding sowohl auf LAN1 (ich nehme an das sollte eth0 im Skript sein) ALS AUCH auf dem WAN-Port horcht. Die Grundidee habe ich im Netz gekl... äh sozialistisch umverteilt und daraus ein Script gebastelt.. Jemand eine Lösung?

#!/bin/sh

ip="192.168.1.1"
wolmac="xx:xx:xx:xx:xx:xx"
wolinterface="dsl"
wolinterface2="lan"
time=5

while true; do
  if [ ! -x /var/tmp/tcpdump ]; then
    eventadd 1 "WakeUp-Script: Tcpdump nicht gefunden. Script beendet."
    break 2
  fi
  eventadd 1 "WakeUp-Script: Tcpdump ueberwacht $ip"
  [COLOR=#ff0000]/var/tmp/tcpdump -i $wolinterface -p -c 1 -n -l dst host $ip and dst port 12345[/COLOR]
  if test -x /usr/bin/ether-wake ; then
    ether-wake -i $wolinterface2 $wolmac
    eventadd 1 "WakeUp-Script: WOL Packet an $wolmac und Adapter: $wolinterface$
    eventadd 1 "WakeUp-Script: wartet $time"
 sleep $time
  else
    eventadd 1 "WakeUp-Script: Ether-wake nicht gefunden. Script beendet."
    break 2
  fi
done

 

[aragorn]

AW: Server bei Inaktivität in S5?

Wenn du deinen Server immer schlafen schickst, ist somit auch deine Loadbalance statistics futsch! falls du diese benutzen solltest.

jein. er kann in oscam auch einstellen das die lb stats woanders als in /tmp/.oscam/stats gespeichert werden dann wärn sie nicht jedesmal futsch.
aber davon abgesehen finde ich das auch nicht schlimm.. meine werden auch alle 24h gelöscht

Ja, das habe ich schon bedacht, geanuso wie alle Logs weg sind (da sie alle in die ramdisk schreiben), aber das ist mir nicht sonderlich wichtig. Loadbalancer nutze ich ohnehin nicht (habe von jeder Karte eh nur eine).

wenn du tmp2ram.sh nutzt sind die logs nicht weg.. wie ich anfangs bereits erwähnt habe wird über tmp2ram ein "varlog" script installiert was beim herrunter fahren die logs nach /var/log.save kopiert und beim hochfahren daraus wiederherstellt.. unter anderem ist es nämlich wichtig das die verzeichniss struktur in /var/log/ beim hochfahren wiederhergestellt wird damit die jeweiligen dienste (vorallem apache2) die verzeichnisse vorfinden in denen sie ihre logs schreiben und auch das die rechte passen usw.. also wenn du tmpfs für /var/log/ manuell angelegt hast solltest du dir auch ein script schreiben was beim hochfahren die verzeichnisse mit den passenden rechten erstellt

auch ist für den load balancer nicht unbedingt wichtig das du von einer karte mehrere lokal hast. der load balancer arbeitet auch mit remote/proxie karten oder es wird auch der auto_betatunnel mit nur einer karte genutzt..

root@cookiemonster ~ > ps auxw | grep ftp
proftpd   1288  0.0  0.3   7636  1648 ?        Ss   21:33   0:00 proftpd: (accepting connections)
1000     19086  0.1  0.6   8244  3220 ?        S    22:18   0:00 proftpd: dumbshitaward - dumbshitaward.router: IDLE
root     19767  0.0  0.1   3316   792 pts/1    S+   22:19   0:00 grep ftp

dann führ mal folgendes aus: ps auxw|grep -v grep|grep -v "(accepting connections)"|grep proftpd
..dann sollten dir nur noch die tatsächlichen verbindungen aufgelistet werden


das WOL script möchtest du nun auf dem thin client nutzen? hat der im bios keine entsprechende einstellung?
guck dazu mal hier: Link ist nicht mehr aktiv.
oder hier:

Sie müssen registriert sein, um Links zu sehen.

oder hier:

Sie müssen registriert sein, um Links zu sehen.

(google suche nach: linux wake on lan)

 

[dumbshitaward]

AW: Server bei Inaktivität in S5?

das WOL script möchtest du nun auf dem thin client nutzen? hat der im bios keine entsprechende einstellung?
guck dazu mal hier: Link ist nicht mehr aktiv.
oder hier:

Sie müssen registriert sein, um Links zu sehen.

oder hier:

Sie müssen registriert sein, um Links zu sehen.

(google suche nach: linux wake on lan)

Ne. Hab mich da vielleicht ein wenig unklar ausgedrückt, war zu dem Zeitpunkt "etwas" müde.

Das Script läuft auf der Fritzbox, da solls auch bleiben. Allerdings überwacht es nur den WAN-Port auf eingehende Pakete auf bestimmten Ports, ergo funktioniert WOL nur von außerhalb des Netzwerks. Ich Depp hab natürlich vergessen, dass meine VU+ derzeit per WLAN angebunden ist, ergo mussten meine Versuche mit eth0 natürlich fehlschlagen *headdesk*, das aber nur am Rande, ändert nichts am ursprünglichen Problem. Das Skript soll ja nur auf einigen bestimmten Ports nach Traffic lauschen, egal was das ist, kann wegs mir auch ICMP sein, aber es muss kein Magic Packet sein. So da Traffic ist, sendet die Fritz über ether-wake ein Magic Packet an den ThinClient, welcher dann hochfährt, so die Theorie. Klappt auch alles, nur eben nicht von überall.

Ich habe das Problem jetzt etwas eingegrenzt, es liegt bei tcpdump (und jetzt wirds wohl echt OT, sollte ich bei den Fritten-Menschen einstellen).
So wie ich das sehe, kannn tcpdump immer nur auf einem interface horchen, es gibt zwar den Befehl tcpdump -i any der dann alles überwacht, der funzt aber auf der Fritte nicht (läuft nicht im promiscuous mode und den brauch ich). Ich müsste sozusagen das Interface "dsl" (WAN-Port) und "wifi0" (WLAN-Schnittstelle - bis ich da mal draufgekommen bin... wer nennt denn das so?!) überwachen, ums ganz sauber zu machen sogar noch den LAN-Port "eth0".

Und genau da liegt mein Problem: das scheint so nicht direkt zu gehen, viele User scheinen unter Linux einfach zwei, drei Instanzen aufzumachen um das Problem in den Griff zu bekommen, aber ich bin mir ehrlich gesagt nicht sicher, ob ich das a) auf einer Fritte überhaupt kann und b) wenn doch, ob die Hardware das mitmacht...

 

[dumbshitaward]

AW: Server bei Inaktivität in S5?

So, jetzt musste ich mir doch glatt ein eigenes Freetz-Image kompilieren und da dann tcpdump einbauen, aber nach reichlich Fummelei (und zwar nicht die spannende Art und Weise) habe ichs dann hinbekommen.

tcpdump (die Version, die ich hatte war wohl das mini binary, ergo beim kompilieren nicht die mini-Option wählen) tut jetzt auch mit $tcpdump -i any. Werde das mal testen...

 

[aragorn]

AW: Server bei Inaktivität in S5?

wärst du so nett wenn du damit fertig bist anderen zu erklären wie du das gemacht hast und worauf man zu achten hat usw? dann könnten das auch andere machen die das auch interessiert

da ich selber aber keine fritzbox beziehungsweise keine geflashte habe kann ich dazu nicht viel sagen (möchte sie auch nicht flashen)

 

[dumbshitaward]

Ja klar.
Hatte sowieso vor nen HowTo zu schreiben wenns läuft.

 

[dumbshitaward]

AW: Server bei Inaktivität in S5?

Langsam komme ich der Krux auf die Schliche...

Ich hatte das Problem, dass mein Receiver die Box übers LAN nicht zuverlässig hochfahren wollte. Wenn die FritzBox gerade frisch neu gestartet wurde, lief das nie, egal ob MGCamd oder CCCam als Client. Wurde der Server aber mal gestartet und dann wieder runtergefahren liefs, allerdings nur eine gewisse Zeit (nicht genau gemessen). Übers Internet läufts allerdings absolut zuverlässig.

Irgendwann habe ich mir mal den Traffic meiner Vu+ angeschaut, was da so genau passiert, wenn Server aus ist und FritzBox gerade neu gestartet wurde und ich glaube jetzt auch das Problem gefunden zu haben.

Die Box schickt einfach keine Anfragen an den Server, einzig fünf ARP who-has Pakete kommen, die Box bekommt keine zufriedenstellende Antwort und stellt dann beleidigt die Kommunikation ein. Klar, so kann das ja nicht gehen, ist ja kein Paket auf einem Port, den das Script überwacht...

Jetzt könnte ich natürlich versuchen tcpdump dazu zu bringen auf die ARP Pakete zu achten (wobei alleine der Name tcpdump mich da nicht zuversichtlich stimmt, ist immerhin gleich mal einen ganzen Netzwerklayer höher, wenn ich das richtig im Kopf habe). Das würde ggf. auch dazu führen, dass der Server hochfährt, wenn er eigentlich nicht gebraucht wird, weil z.B. irgendjemand es wagt FTA zu schauen. Nicht unbedingt gut, würde aber gehen.

Geht! tcpdump -i any arp | egrep 'arp who-has 192.168.1.x'
Sollte es zumindest, aber ich teste heute nix mehr, zu müde.


Der einfachste Workaround ist natürlich das ganze über die eigene dyndns-Adresse zu jagen, das sollte dann schon funtionieren. Bringt den Leuten aber nichts, die dieses Script vielleicht auch für andere Sachen wie ihren Kühlschrank oder den GPS-Tracker im Hund (Wake on Dog ) nutzen wollen...


Edit: könnte das für die camd3 Leute vielleicht interessant sein? Mit UDP könnte das klappen, wenn ich mir das gerade richtig zusammenreime...