Seite 1 von 1

Script was sich selber updated?

Verfasst: 04.06.2006, 16:48
von Airport1
Folgende kranke Idee:

Ein Schutzscript vor Blutsaugern des WWW (Contentgrabber etc.)
was sich z.B. alle 7 Tage z.B. selber updated in der Form
dass es eine neue Version von einem Quellserver requested
und sich dann selber mit der neuen Version ueberschreibt.

Moeglich.. maybe mit chmod777.. oder total gesponnen ;) ?

Also ungefaehr so:

if script older than 7 days,
check for new version on source server,
if new available
overwrite (SELF) with new version..

Wie koennte man das mit moeglichst wenig Aufwand und Rumgetrickse loesen?

Das Hauptprob wird wohl auftreten wenn man dem Script sagen soll "ueberschreibe Dich selbst" ;)

Verfasst:
von

Re: Script was sich selber updated?

Verfasst: 04.06.2006, 17:02
von Hasenhuf
Airport1 hat geschrieben:Das Hauptprob wird wohl auftreten wenn man dem Script sagen soll "ueberschreibe Dich selbst" ;)
Was spricht gegen zwei Dateien?

Verfasst: 04.06.2006, 17:04
von oldInternetUser
Das ist keine kranke Idee und kein Rumgetrickse, das ist Alltag von partiell aktualisiertem Code:

Nimm zwei Scripts - das eine überprüft, ob eine neue Version vorliegt, lädt diese eventuell - und startet dann das alte oder überschriebene Script.

Allerdings sollte irgendeine Signaturprüfung drin sein, nicht, daß eine manipulierte Hosts-Datei dazu führt, daß Code von einem fremden Server nachgeladen und ausgeführt wird.

Verfasst:
von

Verfasst: 04.06.2006, 17:07
von SebaF
Hi,

warum speicherst Du die Liste mit IPs etc. nicht in einer gesonderten Datei ab?
Macht es Sinn, dass in einer Datei das Update-Script und die "Schutz"-Datei liegt?

Verfasst: 04.06.2006, 17:14
von Airport1
Dachte mir schon dass das mit zwei Dateien kommt.
Bin etwas minimalistisch veranlagt, wollte UNBEDINGT alles in einer Datei haben.
Mit einer Datei muesste es ggf. auch gehen, allerdings frage ich mich wie.
Mich reizt einfach schon allein die Aufgabe ;)
Werde nachher mal den "kranken Weg" versuchen..

Verfasst: 04.06.2006, 17:24
von Airport1
Also unter PHP5 gehts mit dem "kranken Weg", und zwar ohne Mucken! Der Hammer ,)

Verfasst: 04.06.2006, 17:48
von oldInternetUser
Airport1 hat geschrieben:Also unter PHP5 gehts mit dem "kranken Weg", und zwar ohne Mucken! Der Hammer ,)
Nur so eine kleine Warnung, weshalb ich trotzdem zwei Dateien verwenden würde: Bei Datumsüberprüfungen kann es im Zusammenhang mit Winter/Sommerzeit oder Datumsformaten alle möglichen Probleme geben. Bei einem Selbststart kann es immer irgendeinen Bug geben, der zu einer Dauerschleife (erneuter Selbststart) führt.

Defensives Programmieren würde an dieser Stelle eine Zwei-Dateien-Lösung bevorzugen.

Verfasst: 04.06.2006, 22:03
von net(t)worker
Airport1 hat geschrieben:Also unter PHP5 gehts mit dem "kranken Weg", und zwar ohne Mucken! Der Hammer ,)
naja... was hattest du erwartet.... das script wird doch erst in den speicher geladen und dort ausgeführt... also warum nicht die eigene Quelldatei überschreiben..... ein unix/Linux kann sich schliesslich auch selber von der festplatte löschen.... windows weigert sich da ja...
Linux/Unix gehen haöt davon aus, dass der user weis was er da macht....


ich würde aber auch eine 2 Datei Lösung vorziehen.... stell dir mal vor, nach der hälfte der Übertragung bricht diese zusammen oder es wird der HTML code einer Webserverfehlerseite abgespeichert....

ein automisches unkontrolliertes update hat sowieso einen kleinen beigeschmack... egal wie sorgfältig gearbeitet wird, man kann nie wirklich sicherstellen, dass ein script auch unter allen Konfigurationen 100% ausführbar ist.... durch eine unachtsamkeit könnten also alle installationen oder zumindest ein großer Teil unbrauchbar werden.... bei einer 2 scriptlösung könnte man mit den updatescript zur not ja auch direkt wieder die lauffähige ältere version einspielen, falls die neuste nicht lauffähig ist...

Verfasst: 04.06.2006, 23:43
von Airport1
Das die Uebertragung wegfackelt / abbricht hatte ich mir schon ueberlegt, dem wollte ich mit einer Pruefsumme entgegenwirken, d.h. erst pruefen ob das requestete bei CRC Check die Pruefsumme wirklich ergibt, bevor geschrieben wird. Dann gibts nur noch ein Point of Failure: naemlich den Moment wo die Datei ueebrschrieben wird, wenn genau da dann z.B. in dieser ms der Webspace ausgeht oder jemand den Server rebooted.

Verfasst: 04.06.2006, 23:47
von /bin/false
Airport1 hat geschrieben:Das die Uebertragung wegfackelt / abbricht hatte ich mir schon ueberlegt, dem wollte ich mit einer Pruefsumme entgegenwirken, d.h. erst pruefen ob das requestete bei CRC Check die Pruefsumme wirklich ergibt, bevor geschrieben wird. Dann gibts nur noch ein Point of Failure: naemlich den Moment wo die Datei ueebrschrieben wird, wenn genau da dann z.B. in dieser ms der Webspace ausgeht oder jemand den Server rebooted.
Und warum nicht eine DB gestütze Lösung?
- Zeit zum Updaten

-> Alle Daten laden und komplett in die DB schreiben
-> Wenn DB leer, wegen Fehler etc, neu laden

- Daten in ein Cach-File in /tmp schreiben ...

Nebenbei kann man den letzten Abholzeitstempel auch noch festhalten etc

Verfasst: 04.06.2006, 23:50
von Airport1
oldinet:

> Bei Datumsüberprüfungen kann es im Zusammenhang mit Winter/Sommerzeit oder Datumsformaten alle möglichen Probleme geben.

In meinem Fall wuerde mit Wahrscheinlichkeitstheorie gearbeitet werden, und einem Vergleich der Signaturen, wenn gleich wird sogar gar nix gemacht, sonst wird mit der neuen Version ueberschrieben.

Ungefaehr so:

1. Wuerfle zw. 1 und X (X z.B. 10000)
2. Ist Ergebnis exakt Y (z.B. 3333) dann requeste von fremden Server
3. Ueberpruefe mit CRC Check ob der CRC Wert in der requesteten Datei stimmt
(=ist Datei vollstaendig uebertragen worden?), sonst ueberspringe alle folgenden Schritte
4. Vergleiche Signaturen von bisheriger und requesteter Datei (=ist Datei immer noch die gleiche?)
5. Sind diese Signaturen gleich, ueberspringe alle folgenden Schritte
6. Sonst ueberschreibe Dich selbst mit der requesteten Datei

Einziger Point of Failure kann jetzt nur noch sein wenn die Datei geschrieben wird.?

Verfasst: 04.06.2006, 23:52
von Airport1
/bin/false:

Weil es ein Script ist das weder auf .htaccess noch mysql angewiesen sein soll, da es auf allen (!) meinen Domains installiert wird und manche gar kein mysql haben.

Zudem wirds auch fuer andere User freigegeben werden, sogar fuer solche die kA von mysql, .htaccess und php etc. haben ;)