Das gute alte SSH
Aber wenns der gsnze Bildschirm sein soll würde ich auch x11vnc nehmen.
Da meiner hinten am TV klebt -> Fernseher umschalten und Funktastatur in die Hand
(29.08.2019, 11:18)Shimly_Stefan schrieb: [ -> ] (28.08.2019, 18:59)beetlestone schrieb: [ -> ]@TTpi
wenn du mehrere surfbars hast, dann bringt bis JETZT der restartercode nichts.
dann musst du den traffik auf port 80 checken (z.b. über iptables), aber dann darf keine andere surfbar laufen...
aber warte mal 1-2 tage, stefan baut da evtl was
Mit 1-2 Tagen kommen wir da leider nicht aus, da ich dafür alles umbauen und ausgiebig testen muss.
Das aktuelle System war für derartige Dinge nie ausgelegt 
Aber dennoch habe ich mir dazu schon Gedanken gemacht und werde es in der nächsten Zeit realisieren, sobald ich die Zeit dafür finde.
Gibt es dazu schon was neues ? Es geht zwar notgedrungen über Traffiküberwachung, aber so genau ist das auch nicht
(10.11.2019, 19:05)beetlestone schrieb: [ -> ] (29.08.2019, 11:18)Shimly_Stefan schrieb: [ -> ] (28.08.2019, 18:59)beetlestone schrieb: [ -> ]@TTpi
wenn du mehrere surfbars hast, dann bringt bis JETZT der restartercode nichts.
dann musst du den traffik auf port 80 checken (z.b. über iptables), aber dann darf keine andere surfbar laufen...
aber warte mal 1-2 tage, stefan baut da evtl was :D
Mit 1-2 Tagen kommen wir da leider nicht aus, da ich dafür alles umbauen und ausgiebig testen muss.
Das aktuelle System war für derartige Dinge nie ausgelegt :rolleyes:
Aber dennoch habe ich mir dazu schon Gedanken gemacht und werde es in der nächsten Zeit realisieren, sobald ich die Zeit dafür finde.
Gibt es dazu schon was neues ? Es geht zwar notgedrungen über Traffiküberwachung, aber so genau ist das auch nicht :(
gestern hat's bei mir klick gemacht, wie man das problem lösen kann. ich hatte ja bereits erwähnt, das ganze per IP zu überprüfen. das ist dann doch etwas genauer und einfacher als den port 80 über iptables zu checken.
erstmal zur theorie:
mit "netstat" oder "ss" kann man sich die verbindungen anzeigen lassen, die der rechner irgendwohin aufbaut.
in zukunft wird man häufiger "ss" sehen und nutzen, da das "netstat" als deprecated gilt und "ss" der "offizielle" nachfolger ist. im vergleich gibt "ss" auch schneller eine liste der verbindungen aus. das "ss" steht übrigens für "socket statistics" :)
wenn man nun "ss -t" aufruft, werden alle tcp verbindungen angezeigt. mittels "grep" kann man filtern. man filtert dann die IPs von ebesucher.de.
das ganze packt man in einer schleife die ne minute. wenn keine verbindung zu ebesucher aufgebaut ist, bleibt die schleife leer. kommt es dann aber zu einer verbindung, wird beim "ss" die verbindung kurz angezeigt und wir haben dann einen inhalt in der schleife. sobald dann der inhalt da ist, kann die schleife beendet werden. wenn die schleife bis zum ende durchläuft (also die eine minute), wurde keine verbindung aufgebaut und man kann stark davon ausgehen, dass ebesucher nicht mehr läuft... dann killt man den browser und startet neu.
also ist die überwachung per IP traffic relativ easy ==> schleife bauen, auf reaktion von "ss -t | grep IPs" warten <== reaktion vorhanden: schleife beenden; keine reaktion vorhanden: browser neu starten...
jetzt zur paxis:
wenn sich ein tüfteliger mitstreiter findet, kann er ja mal was basteln... ich habe momentan keine zeit und nerven dafür :) ... wahrscheinlich erst am wochenende.
ich hab da mal etwas langeweile gehabt und was hin gekritzlet
wenn jemand noch ein verbesserungsvorschlag hat, kann er diesen gerne mit einbringen
Code:
#!/bin/bash
i=66
while [ $i -gt 0 ]
do
check=`ss -t | grep "1.1.1.1" | tail -n 1`
check=`ss -t | grep -E "1.1.1.1" | tail -n 1`
if [ "$check" ]
then
echo "ONLINE"
exit 0
fi
sleep 1
i=$[$i-1]
done
echo "OFFLINE"
exit 0
das wichtigste ist damit erledigt.
das ist ein simples bash script. die mitstreiter, die einen RPi zum aufrufen nutzen, sollten wissen, wie man damit umgeht
Das würde funktionieren, aber auch nur solange man keinen privaten Proxy dazwischen hat
Ich würde dann aber die IP von eBesucher nicht fest mit grep suchen lassen, sondern zumindest bei jedem Scriptstart die IP neu ermitteln.
Könnte ja sein, dass die Server wechseln oder die IP
z.B.
ip=`dig ebesucher.de +short`
check=`ss -t | grep $ip | tail -n 1`
Der Befehl dig ist im Paket dnsutils enthalten...
(14.11.2019, 15:46)beetlestone schrieb: [ -> ]Das würde funktionieren, aber auch nur solange man keinen privaten Proxy dazwischen hat :s
Ich würde dann aber die IP von eBesucher nicht fest mit grep suchen lassen, sondern zumindest bei jedem Scriptstart die IP neu ermitteln.
Könnte ja sein, dass die Server wechseln oder die IP :D
z.B.
ip=`dig ebesucher.de +short`
check=`ss -t | grep $ip | tail -n 1`
Der Befehl dig ist im Paket dnsutils enthalten...
ja, mit'n proxy geht das nicht. die meisten nutzen das ganze ja auch nur einmal zu hause :)
an "dig" hab ich ehrlich gesagt nicht gedacht.
ich habe mir nur die IPs von ebesucher raus gesucht und die in "grep -E ..." eingetragen. ebesucher.de/com hat nur 3 IP adressen, die können sich zwar ändern, aber wer wechselt schon freiwillig die IP (... ausser die ISPs) :D
aber was mir gerade noch eingefallen ist... was ist, wenn das script die minute läuft und gerade in diesem moment sich die IP zur domain ändert, weil TTL abgelaufen ist?! wobei das jetzt auch pille palle ist, weil sone überprüfung macht man ja nicht einmal die stunde ;)
Hey zusammen
Funktioniert das noch bei euch?
Ich habe heute meinen alten Raspberry 2 1.2 eingerichtet, nutze Chromium, allerdings werden mir nur die kostenlosen Seiten angezeigt auf dem Raspberry.
Mache ich das ganze parallel auf einem normalen Windows 10 Laptop erhalte ich ca. 1000 btp pro Stunde.
Hat jemand eine Idee
?
Thanks
Also laut meinem Wissensstand hat das Ebesucher Team irgendwas eingepflegt was PI´s ausschließt...
hab auch noch keine Lösung gefunden...
falls einer eine hat bitte mal posten...
Ich habe mir ne virtuelle Maschine mit Ubuntu eingerichtet und wollte darin die Surfbar laufen lassen. Funktioniert leider auch nicht. Ich frage mich, ob die Linux ausschließen oder ob die was anderes erkennen.