Datenbank im Web updaten - Sicherheit

[Dieter Raber]

Hallo,

Ich habe eine Anwendung in PHP/MySQL geschrieben, die im Prinzip eine Datenbank lokal verwaltet. Eine der Tabellen soll jetzt dazu dienen, eine entsprechende Tabelle im Web upzudaten und zwar DAUsicher. Die Tabelle liegt mir als Dump vor und meine Idee sieht etwa so aus:

• lokal die sql-Datei in ein Datei-Upload-Feld eintragen
• mit POST zum Webserver transportieren
• dort ein File aufrufen, dass die sql-Datei in die Datenbank eintraegt

Meine Probleme sind:

• Datei-Upload-Felder kann man ja nicht vorbelegen mit Werten, ich sehe also, dass  da irgendwann was schiefgeht. Hat dazu vielleicht jemand eine Idee?

• die Daten muessen sicher uebertragen werden, ich habe an SSL gedacht, habe aber eigentlich bisher keine Ahnung davon, ist das eine gute Idee?

Ich stelle mir von Seiten des Forums natuerlich keine fertigen Loesungen vor, sondern nur, in die richtige Richtung geschubst zu werden. Vielleicht ist das ganze Konzept ja auch Mist und irgendjemand zaubert ein besseres Kaninchen aus dem Hut.

Danke fuer jeden Input

Dieter

[Andreas Korthaus]

Hallo!

ich habe vor einiger zeit eine Synchronisation 2er mYSQL-Datenbanken gebastelt, ist zwar sehr speziell gewesen, aber vielleicht bringt es Dir ja was Dich durch die alten Diskissionen zu lesen. Wenn Du dazu fragen hast kannst Du sie gerne hier stellen. Gucke mal im Archiv:

http://selfsuche.teamone.de/cgi-bin/such.pl?suchausdruck=author%3A"Andreas+Korthaus"+Synchronisation&feld=alle&index_6=on&hits=100

• Datei-Upload-Felder kann man ja nicht vorbelegen mit Werten, ich sehe also, dass  da irgendwann was schiefgeht. Hat dazu vielleicht jemand eine Idee?

Das kommt drauf an wieviel Zeit Du da reinstecken willst/kannst (was stark davon abhängt welche Kenntnisse Du mitbringst, ich mußte viel lernen), welche Techniken Du im Internet und vor allem Lokal zur Verfügung hast und wer das ganze am Ende zu bedienen hat. Meine Variante ist _sehr_ aufwendig, funktioniert aber von ganz alleine. Grob skizziert, ich habe ein Script geschreiben, welches lokal aus der Datenbank die zu synchronisierten Daten ausliest, diese komprimiert udn ich glaube ich verschlüsselt und an ein Script auf dem Server schickt, welches die Daten entgegennimmt, entschlüsselt und dekomprimiert, und danach in die dortige Datenbank einliest.

• die Daten muessen sicher uebertragen werden, ich habe an SSL gedacht, habe aber eigentlich bisher keine Ahnung davon, ist das eine gute Idee?

Eine sehr gute, leider hatteich damals keine PHP-Version zur Verfügung mit der das so ohne weiteres ging, heute funktioniert das mehr oder weniger automatisch.

Ich stelle mir von Seiten des Forums natuerlich keine fertigen Loesungen vor, sondern nur, in die richtige Richtung geschubst zu werden. Vielleicht ist das ganze Konzept ja auch Mist und irgendjemand zaubert ein besseres Kaninchen aus dem Hut.

Ist genau der richtige Weg, lies dir mal ein bisschen von dem was da im Archiv steht durch, vielleicht gibt Dir das ja schon ein paar Ideen!

Grüße
Andreas

[Dieter Raber]

Hallo Andreas,

Gucke mal im Archiv: http://selfsuche.teamone.de/cgi-bin/such.pl?suchausdruck=author%3A"Andreas+Korthaus"+Synchronisation&feld=alle&index_6=on&hits=100

Ich hab mal einen kurzen Blick in den Thread geworfen, das klingt sehr nach nuetzlichem Wissen fuer meinen Fall.

Das kommt drauf an wieviel Zeit Du da reinstecken willst/kannst (was stark davon abhängt welche Kenntnisse Du mitbringst, ich mußte viel lernen),

Ich wuerd schon gern mal eiens Tages fertig werden, schaun wir halt mal...

Vielen Dank fuer Deine Hilfe

Dieter

[Philipp Hasenfratz]

Halihallo Dieter

Ich habe eine Anwendung in PHP/MySQL geschrieben, die im Prinzip eine Datenbank lokal verwaltet. Eine der Tabellen soll jetzt dazu dienen, eine entsprechende Tabelle im Web upzudaten und zwar DAUsicher. Die Tabelle liegt mir als Dump vor und meine Idee sieht etwa so aus:

Wird der Upload denn von DAU's gemacht?

• dort ein File aufrufen, dass die sql-Datei in die Datenbank eintraegt

Du meinst ein Script?

• Datei-Upload-Felder kann man ja nicht vorbelegen mit Werten, ich sehe also, dass  da irgendwann was schiefgeht. Hat dazu vielleicht jemand eine Idee?

Nicht über den Browser zu gehen. PHP bietet Möglichkeiten, die Datei einzulesen und dann
über eine HTTP-Verbindung zum Server zu senden. Dann hast du zudem den Vorteil, dass
du die Arbeit nicht manuell erledigen musst und schützt dich vor Tippfehlern o. ä.

• die Daten muessen sicher uebertragen werden, ich habe an SSL gedacht, habe aber eigentlich bisher keine Ahnung davon, ist das eine gute Idee?

Ja. Mit SSL werden die Daten sicher übertragen, wenn sich einer in die Verbindung
"einklinkt", kann er die Daten nicht entziffern.

Ich stelle mir von Seiten des Forums natuerlich keine fertigen Loesungen vor

Danke ;)

sondern nur, in die richtige Richtung geschubst zu werden. Vielleicht ist das ganze Konzept ja auch Mist und irgendjemand zaubert ein besseres Kaninchen aus dem Hut.

Ich halte den Weg über den Browser für etwas missraten; auf diese Applikation kannst du
verzichten (oder arbeiten mehrere mit dem System?). Für grosse Daten würde ich den
Dump erst zippen, dann wird die Übertragungszeit kürzer und Verbindungsfehler minimiert.
HTTP ist nicht das geeignete Protokol, FTP wäre sinnvoller, da auf die Übertragung von
Dateien ausgelegt (auch über PHP automatisierbar).
Du sprichst von UPDATE; werden online dann alle Daten mit dem aktuellen Stand
überschrieben? - Oder sprichst du von einer Synchronisation? - Kannst du Datenverlust
ausschliessen (eg. selber Datensatz online und offline aktualisiert => Konflikt)?

Viele Grüsse

Philipp

[Dieter Raber]

Hallo Philipp,

Wird der Upload denn von DAU's gemacht?

Jo, ich rechne mit dem Schlimmsten... ;-(

• dort ein File aufrufen, dass die sql-Datei in die Datenbank eintraegt
  Du meinst ein Script?

meinte ich, sorry

über eine HTTP-Verbindung zum Server zu senden.
FTP wäre sinnvoller, da auf die Übertragung von
Dateien ausgelegt (auch über PHP automatisierbar).

Das klingt sehr gut, hast Du vielleicht ein Stichwort, wo ich im PHP-Manual zu lesen anfangen soll?

Du sprichst von UPDATE; werden online dann alle Daten mit dem aktuellen Stand
überschrieben? -

Die Web DB wird ueberschrieben

ausschliessen (eg. selber Datensatz online und offline aktualisiert => Konflikt)?

Im Prinzip funktioniert es so: Tabelle 1 (lokal) wird vom User verwaltet, ein Script erstellt daraus Tabelle 2 (lokal, Teilmenge von Tbl 1) und dumpt beide zu je einem File. Die Tabelle im Web ist eine Kopie von Tbl 2 und wird jedesmal ueberschrieben. Fuer alle Faelle gibt es aber immer das lokale Original, sowie den lokalen Dump

Du hast mit jedenfalls sehr weitergeholfen, danke nochmal

Dieter

[Philipp Hasenfratz]

Halihallo Dieter

über eine HTTP-Verbindung zum Server zu senden.
FTP wäre sinnvoller, da auf die Übertragung von
Dateien ausgelegt (auch über PHP automatisierbar).
Das klingt sehr gut, hast Du vielleicht ein Stichwort, wo ich im PHP-Manual zu lesen anfangen soll?

www.php.net und das gleichnamige Suchwort oben rechts eingeben (FTP)...
http://www.php.net/manual/de/ref.ftp.php der entsprechende Link.

ausschliessen (eg. selber Datensatz online und offline aktualisiert => Konflikt)?
Im Prinzip funktioniert es so: Tabelle 1 (lokal) wird vom User verwaltet, ein Script erstellt daraus Tabelle 2 (lokal, Teilmenge von Tbl 1) und dumpt beide zu je einem File. Die Tabelle im Web ist eine Kopie von Tbl 2 und wird jedesmal ueberschrieben. Fuer alle Faelle gibt es aber immer das lokale Original, sowie den lokalen Dump

Du hast mehrere User, die das machen? - Entweder du überschreibst bei jedem User die
Daten eines anderen, oder du begehst einen Datenbank-Design-Technischen Fehler und hast
für jeden User eine eigene Tabelle angelegt. Das nur so nebenbei ;))

Viele Grüsse

Philipp

[Andreas Korthaus]

Hallo!

über eine HTTP-Verbindung zum Server zu senden.
FTP wäre sinnvoller, da auf die Übertragung von
Dateien ausgelegt (auch über PHP automatisierbar).

Wieso habe ich damals eigentlich nicht an FTP gedacht(und Du auch nicht!!!?;-)), denn dann müßte man sich nicht mehr um die Header... kümmern... Naja, dafür kommt meine Variante aus ohne aufs Dateisystem zuzugreifen ;-) Ist nur die Frage was ich davon habe ;-) FTP ist sicher einfacher. Vor allem braucht man dafür lokal gar kein PHP, das ginge sogar mit einer einfach Batch-Datei die FTP über die Komandozeile bedient... aber egal.

Grüße
Andreas

PS: danke für die Erklärung unten, habe es noch nicht 100% verstanden da ich vermutlich zu schnell gelesen habe, aber werde es später nochmal lesen ;-)

[Andreas Korthaus]

ich nochmal ;-)

Wieso habe ich damals eigentlich nicht an FTP gedacht?

Ich glaube mich dran zu erinnern das ich doch mit dem Gedanken gespielt habe, das aber wegen der bidirektionalen Kommunikation sein gelassen habe, wobei es sicher auch funktioniert hätte, naja. Hat aber nichts mit dem vorliegenden Fall zu tun, da ist FTP die erste Wahl.

Grüße
Andreas

[Sven Rautenberg]

Moin!

Hat aber nichts mit dem vorliegenden Fall zu tun, da ist FTP die erste Wahl.

FTP ist _letzte_ Wahl. Denn die Tatsache, dass eine verschlüsselte Übertragung gewünscht war, verhindert, dass ein unverschlüsseltes Protokoll wie FTP zum Einsatz kommen kann.

Sicherlich kann man den reinen Dateiinhalt durch Anwendung von PGP schützen. Aber das FTP-Passwort wird unverschlüsselt übertragen, und es ist zu befürchten, dass jemand, der die Datenübertragung abfangen kann, dann auch das Passwort abfangen kann. Und wenn es dumm kommt, kriegt er dadurch Zugriff auf den Webspace, alle PHP-Skripte und den geheimen PGP-Schlüssel, der zur erfolgreichen Anwendung ohne Zugangsbarrieren wie Passphrase etc. gespeichert sein muß. Das ist im Endeffekt dann genauso sicher, wie die Passwortabfragen von try2hack.nl - nämlich gar nicht sicher!

FTP scheidet also aus diversen Gründen, primär aber wegen der unverschlüsselten Passwortübertragung aus.

Bleiben: HTTP, HTTPS und SSH.

HTTP ist auch unverschlüsselt, aber wenn man eine verschlüsselte Datei per POST sendet, kriegt ein Angreifer nur mit, dass zu einer bestimmten URL, die er natürlich auch selbst füttern könnte, eine Dateiübertragung stattgefunden hat. Wenn man die Möglichkeiten der digitalen Signatur von PGP zusätzlich einsetzt und vom Empfangsskript prüft, ist ein mutwilliges Hochladen von Fake-Daten nahezu unmöglich. Merke: Auch ein passwortgeschütztes Skript (.htaccess) braucht unverschlüsselte Passwortinformationen, ist also als Schutz unbrauchbar.

Als Bonus gibts die Tatsache, dass das externe Skript exakt dann gestartet wird, wenn die Datei hochgeladen wird - es ist kein Cron-Job etc. notwendig, um die Dateiankunft per FTP zu prüfen.

HTTPS läuft komplett verschlüsselt ab. Da kann man eigentlich nichts mehr verkehrt machen. Allerdings benötigt man natürlich einen SSL-fähigen Webserver, der leider in den typischen Standard-Hosting-Paketen nicht enthalten ist. Und nur für die regelmäßigen Updates wäre es nicht zu rechtfertigen, deshalb ein Upgrade für den Webspace zu ordern.

SSH schließlich bietet über SCP (Secure Copy) ebenfalls verschlüsselte Kopierfähigkeiten an, erfordert aber einen SSH-Zugang zum externen Server.

Zu beachten ist, dass die ganzen Spielchen auch umgekehrt ablaufen können: Durch Aufruf eines speziellen Skriptes auf dem externen Server könnte dieser eine beliebige Verbindung (sei es FTP, HTTP, HTTPS oder SSH) zum lokalen Server herstellen und sich die erforderlichen Daten einfach abholen. Diese Methode hätte insofern Vorteile, als dass der Einfluß auf das lokale System vermutlich größer ist. Dort ließe sich beispielsweise ein FTP-Account anlegen, der wirklich nur auf die gewünschte Upload-Datei Zugriff hat und sonst nirgendwo drauf. Oder es ließe sich HTTPS einrichten, bzw. ein SSH-Zugang (welcher dann allerdings auf dem externen Server eine verfügbare Version von SCP erfordert, die man aufrufen kann.

- Sven Rautenberg

[Andreas Korthaus]

Hallo!

Hat aber nichts mit dem vorliegenden Fall zu tun, da ist FTP die erste Wahl.

FTP ist _letzte_ Wahl. Denn die Tatsache, dass eine verschlüsselte Übertragung gewünscht war, verhindert, dass ein unverschlüsseltes Protokoll wie FTP zum Einsatz kommen kann.

Ach ja, ich erinnere mich, _das_ war die Begründung gegen FTP, sorry ;-)

Das ist im Endeffekt dann genauso sicher, wie die Passwortabfragen von try2hack.nl - nämlich gar nicht sicher!

;-) Wie weit bist Du gekommen? *g*

Bleiben: HTTP, HTTPS und SSH.

ich habe mit damals in mein Script mehrere Varianten eingebaut:
mit curl http + https
mit fsockopen http, und https soll noch folgen, geht erst seit php 4.3

Als Bonus gibts die Tatsache, dass das externe Skript exakt dann gestartet wird, wenn die Datei hochgeladen wird - es ist kein Cron-Job etc. notwendig, um die Dateiankunft per FTP zu prüfen.

Das empfinde ich als Vorteil, aber angenommen ich mache das mit php und ftp, dann kann ich mit fsockopen über HTTP auch ein Script auf dem Server anstoßen, genau dann wenn ftp zuende ist, selbiges geht mit batch-Dateien die erst mit scp oder mit sftp(oder wie das hieß) ene Datei kopiert haben dann mit plink(für windows.) Dafür braucht der Server nur SSH, das hat nicht jeder. SSL aber auch nicht.

Grüße
Andreas

[Sven Rautenberg]

Moin!

Das ist im Endeffekt dann genauso sicher, wie die Passwortabfragen von try2hack.nl - nämlich gar nicht sicher!
;-) Wie weit bist Du gekommen? *g*

Theoretisch wäre ich an Level 2 gescheitert, weil mein Browser beim Eintippen der Zahl "2" beim Usernamen nicht die Zahl ins SWF lassen wollte, sondern immer ein Fenster weitergeschaltet hat.

Level 3 war auch nett fies hinterhältig. Zu Level 5 hatte ich dann das Dekompilat im Web gefunden und dann die neue URL komponiert (was ziemlich simpel war), um dann aufzuhören, als ich eine Seite mit den Lösungen bis Level 9 gefunden hatte.

Summa summarum bleibt die Tatsache bestehen: Client-Side-Authentification ist unsicher, egal wie verschlüsselt sie ist.

Bleiben: HTTP, HTTPS und SSH.
ich habe mit damals in mein Script mehrere Varianten eingebaut:
mit curl http + https
mit fsockopen http, und https soll noch folgen, geht erst seit php 4.3

In der Tat: Die Integration von OpenSSL, die dafür notwendig ist, ist erst dort eingebaut worden. Das macht die Sache aber dann ziemlich einfach, weil man sich um SSL absolut nicht kümmern muß. Die Verbindung ist einfach sicher, und fertig.

Bleibt nur das Problem der Verfügbarkeit auf dem externen System. Zuhause HTTPS zu konfigurieren wäre wohl eher nicht das Problem.

- Sven Rautenberg

[Andreas Korthaus]

Hi!

Level 3 war auch nett fies hinterhältig. Zu Level 5 hatte ich dann das Dekompilat im Web gefunden und dann die neue URL komponiert (was ziemlich simpel war), um dann aufzuhören, als ich eine Seite mit den Lösungen bis Level 9 gefunden hatte.

Hm, ich habe mich im Schweiße meines Angesichsts selber bis Level 9 gekämpft. Ich habe eigentlich nichst neues über Sicherhgeitslücken gelernt, so ziemlich alles davon wird hier sofort "niedergemacht" sobald jemand damit ankommt, das sagt einiges über die Qualität dieses Forums aus(das da nichts neues war!).
Dafür habe ich fast eien ganze Nacht damit verbracht, aber es hat wirklich Spaß gemacht, vor allem da sehr viele verschiedene Methoden zum Einsatz kamen. Ich finde es ist gut geeignet um daran Sicherheitsaspekte zu verstene, wobei ich mich frage ob Leute die derartige Grundlagen nicht kennen weiter als Level 3 kommen, aber das reicht ja auch fürs erste.

Summa summarum bleibt die Tatsache bestehen: Client-Side-Authentification ist unsicher, egal wie verschlüsselt sie ist.

Ja. Und in Level 8 lernt man das man vorsichtig sein soll interne Dateien auszugeben, da gab es irgendein altes Standard-CGI-script, welches man dazu bewegen konnte /etc/passwd anzuzeigen, naja, mußte man auch erstmal drauf kommen, und dann noch das root-Passwort entschlüsseln... spaßige Sache das ganze ;-)

In der Tat: Die Integration von OpenSSL, die dafür notwendig ist, ist erst dort eingebaut worden.

Mit dem openssl modul hatte ich es anfangs auch versucht, aber das war mir dann doch zu kompliziert, daman ssl dan komlett zu Fuß einbauen mußte, und das ist nicht ganz so lustig, vor allem wen man weiß0 das in ein paar Monaten das ganze integriert wird ;-)

Das macht die Sache aber dann ziemlich einfach, weil man sich um SSL absolut nicht kümmern muß. Die Verbindung ist einfach sicher, und fertig.

Ja, angenehme Sache das ganze.

Bleibt nur das Problem der Verfügbarkeit auf dem externen System. Zuhause HTTPS zu konfigurieren wäre wohl eher nicht das Problem.

Ja, das wird das Hauptproblem im Vorliegenden Fall sein. Wo ich gerade nochmal in der mysql doku zu mysqldump war, wenn man das Risiko eingeht seinen SQL-Server lokal mit einem offenen Port nach außen zu betreiben (wenn der Provider das wie ich vermute aus guten Gründen  nicht tut), udn dann könnte man auf dem Master-Server im Internet sowas machen:

shell> mysqldump --add-drop-table --host=entfernter-host datenbank | mysql -C datenbank

Das würde dann alles übernehmen, nur unverschlüsselt, wobei, gibt es nicht die Möglichkeit mit dem mySQL-Server über ssl zu komunizieren? Meine mal sowas gelesen zu haben, ist nur fraglich ob sowas in mysqldump eingebaut wird. Jedenfalls finde ich dazu in den Tools keine Option. Wäre ohne SSL zwar unsicher aber _sehr_ einfach, mit SSL bliebe nur noch das Manko mit dem doffenen Port, da kommt es dann auf die "Brisanz" der Daten an, udn wie gut man in der Lage ist sich gegen Angriffe zu schützen. Im Prinzip reicht es alle nicht gebrauchten User und Datenbanken zu löschen, sehr gute Passwörter zu verwenden und den Server auf dem aktuellen Stand zu halten.

Zu dem Thema dann vielleicht http://de.mysql.com/documentation/mysql/bychapter/manual.de_MySQL_Database_Administration.html#Security lesen.

Grüße
Andreas

[Dieter Raber]

Hallo Sven,

jetzt hast Du mich aber verunsichert. Sag mal, wenn ich eine normale FTP-Verbindung mache, wird doch das Passwort auch unverschluesselt gesendet, oder?

Also ich glaub, mit dem Risiko koennte ich leben. Ohnehin, so streng geheim sind meine Daten jetzt auch wieder nicht, im Endeffekt werden daraus ja schliesslich Webseiten. Zudem ist bin ich nicht sicher, ob der Server SSL hat.

Dieter

[Sven Rautenberg]

Moin!

jetzt hast Du mich aber verunsichert. Sag mal, wenn ich eine normale FTP-Verbindung mache, wird doch das Passwort auch unverschluesselt gesendet, oder?

Richtig. Deshalb ist FTP eigentlich auch ganz und gar nicht gut. Insbesondere für Server, auf denen sicherheitsrelevante Daten liegen, verbietet sich jeglich unverschlüsselte Kommunikation - zumindest mit dem Admin, die Besucher können zum Gucken ja gerne HTTP verwenden, solange das keine Vertrauenslücke darstellt.

Also ich glaub, mit dem Risiko koennte ich leben. Ohnehin, so streng geheim sind meine Daten jetzt auch wieder nicht, im Endeffekt werden daraus ja schliesslich Webseiten. Zudem ist bin ich nicht sicher, ob der Server SSL hat.

SSL hat er eher nicht, HTTPS in Richtung externem Server würde also ausfallen. Und auch umgekehrt dürftest du nicht erfolgreich sein, weil auf dem externen Server nur mit geringer Wahrscheinlichkeit ein SSL-fähiges PHP installiert ist.

Bleiben also vier Methoden übrig:
1. FTP
1a. zum externen Server hin (Upload vom internen Server) - eher ungut, da dein Skript ja über den Webspace-Account gehen muß und damit im Prinzip Vollzugriff auf alle Dateien hat. Zumindest bringt es dann auch nichts mehr, die Datenbank-Dumps zu verschlüsseln.
1b. zum internen Server hin (externer Server holt sich die Daten ab) - besser, erfordert aber natürlich, dass du für das Downloaden einen FTP-Server online bringts. Den kannst du aber restriktiv so konfigurieren, dass er nur die eine Datei zum Download anbietet.

2. HTTP
2a. zum externen Server hin - ist eigentlich ganz prima geeignet, weil du damit die Daten direkt per POST zum Datenbankskript senden kannst. Das bisschen fsockopen-Gefummel sollte mit den Useranmerkungen von php.net eigentlich hinzukriegen sein
2b. zum internen Server hin - auch nicht schlecht, geht sogar noch einfacher, weil du die Daten mit fopen() lesen kannst und sie auf interner Seite dynamisch mit einem simplen PHP-Skript generierst.

Mit ein wenig Authentifizierung angereichert, würde ich die HTTP-Methode 2b bevorzugen, sofern du einen internet-öffentlichen Webserver lokal einrichten kannst. Naja, irgendwie mußt der lokale Server ja schon HTTP sprechen - das kann er grundsätzlich ja auch Richtung Internet tun. Pack noch eine IP-Sperre mit rein, dass er nur Verbindungen von dem externen Webserver annimmt (deny from all, allow from WebserverIP), und schon ist dein lokaler Server relativ sicher.

Wie gesagt: Mit ein wenig Authentifizierung - das muß nicht mal zwingend .htaccess-artig sein - kannst du einen sicheren Zugang realisieren.

Wenn dir das alles bis hierher noch vollkommen unklar ist, dann erkläre, welche Möglichkeiten du hast: 1. Kannst du den lokalen Server vom Internet aus zugriffsfähig machen - dann würde ich Methode 2b empfehlen, sonst 2a.

- Sven Rautenberg

[Dieter Raber]

Hi Sven,

danke fuer Deine Ausfuehrungen. Im Moment schwirrt mir der Kopf etwas, ich muss mich durch die ganzen Meinungen sowie Andreas alten Thread und die entsprechenden Teile im PHP-Manual erstmal durchackern. Es waere nett, wenn Du morgen noch einmal einen Blick auf den Thread werfen koenntest, ich werde sicher noch einges nachhaken muessen. Vielleicht lege ich das Thema aber auch noch etwas zur Seite (vulgo: druecke mich ein bisschen davor) und komme zu einem spaeteren Zeitpunkt darauf zurueck.
Letztendlich ging es mir heute abend nur mal darum, einen Ueberblick ueber die verschiedenen Moeglichkeiten zu bekommen und da ist ja einiges zusammengekommen.

@ Philipp
@ Andreas
@ Sven
Nochmal vielen Dank fuer Eure Beitraege!

Dieter

P.S. komm mit Telnet nicht ins verdammte Level 8 ;-(

[Dieter Raber]

Hallo,

Also ich bin von der FTP_Idee auch ganz begeistert. Ich benutzte PHP meist im Zusammenhang mit Webseiten, das macht anscheinend blind fuer das naheliegende...
Zudem liest sich das Kapitel FTP-Functions im PHP-Manual fast wie eine fertige Loesung fuer mein Problem.

Dieter

[Philipp Hasenfratz]

Halihallo Dieter

Also ich bin von der FTP_Idee auch ganz begeistert. Ich benutzte PHP meist im Zusammenhang mit Webseiten, das macht anscheinend blind fuer das naheliegende...

Ah, danke für diesen Satz! - PHP ist für deine Zwecke nicht geeignet, Perl ist bei
Konsolenprogrammen viel, viel besser! - PHP ist nur für Websiten zu gebrauchen!

@Dieter:           Nimm mich hier bloss nicht ernst!
@Andreas:          ätschibätsch! ;-))
@Christian Seiler: du darfst mich wieder schlagen ;-)

Viele Grüsse

Philipp

[Andreas Korthaus]

Hallo!

Ah, danke für diesen Satz! - PHP ist für deine Zwecke nicht geeignet, Perl ist bei
Konsolenprogrammen viel, viel besser! - PHP ist nur für Websiten zu gebrauchen!

[ ] Du kennst http://www.php3.de/manual/en/features.commandline.php
[ ] Du kennst http://pear.php.net/manual/en/core.console.getopt.php

@Dieter:           Nimm mich hier bloss nicht ernst!

Genau, denn das ist Quatsch, es gibt nichts besseres als PHP!

@Andreas:          ätschibätsch! ;-))

Najanaja, PERL hat objektiv IMHO nur noch Vorteile wenn es um Prozesse und Threads geht. Der Rest ist Geschmacksache.

@Christian Seiler: du darfst mich wieder schlagen ;-)

genau, sach auch ma was!

Grüße
Andreas

[Dieter Raber]

Hallo,

@Dieter:           Nimm mich hier bloss nicht ernst!

PHP hat einen Riesenvorteil gegenueber Perl, naemlich den, dass ich's kann

Dieter

[Philipp Hasenfratz]

Halihallo Andreas

So ihr beiden, schreibt nicht so schnell, ich komme nimmer nach mit lesen! :-))

über eine HTTP-Verbindung zum Server zu senden.
FTP wäre sinnvoller, da auf die Übertragung von
Dateien ausgelegt (auch über PHP automatisierbar).
Wieso habe ich damals eigentlich nicht an FTP gedacht(und Du auch nicht!!!?;-)),

Ich? - Nicht an FTP gedacht? - Manno... Aber hast recht, bin untröstlich! :-)
Mit der Zeit kommt Rat, auch bei mir ;)

denn dann müßte man sich nicht mehr um die Header... kümmern... Naja, dafür kommt meine Variante aus ohne aufs Dateisystem zuzugreifen ;-) Ist nur die Frage was ich davon habe ;-) FTP ist sicher einfacher. Vor allem braucht man dafür lokal gar kein PHP, das ginge sogar mit einer einfach Batch-Datei die FTP über die Komandozeile bedient... aber egal.

Da hast du auch recht.

PS: danke für die Erklärung unten, habe es noch nicht 100% verstanden da ich vermutlich zu schnell gelesen habe, aber werde es später nochmal lesen ;-)

Okidoki... Jetzt hab ich endlich den Überlick wieder und hoffe, dass du ihn auch kriegen
wirst.

Viele Grüsse

Philipp

[Philipp Hasenfratz]

Halihallo Andreas

PS: danke für die Erklärung unten, habe es noch nicht 100% verstanden da ich vermutlich zu schnell gelesen habe, aber werde es später nochmal lesen ;-)

Okidoki... Jetzt hab ich endlich den Überlick wieder und hoffe, dass du ihn auch kriegen
wirst.

Uhhh, das klingt ja wie ein Vorwurf, sorry; das war nicht so gemeint. Wollte damit nur
ausdrücken, dass dir die Beschreibung hoffentlich hilft. Weiter nichts.

Viele Grüsse

Philipp

[Dieter Raber]

Hallo,

www.php.net und das gleichnamige Suchwort oben rechts eingeben (FTP)...
http://www.php.net/manual/de/ref.ftp.php der entsprechende Link.

Ok, ich hab kurz ins Manual geschaut und hab jetzt ne Idee von der Marschrichtung

Du hast mehrere User, die das machen? - Entweder du überschreibst bei jedem User die
Daten eines anderen, oder du begehst einen Datenbank-Design-Technischen Fehler und hast

Es gibt nur einen User, aber selbst wenn es mehrere waeren, sie kommen immer nur an die Tabelle 1, 'Mastertabelle'. Dass dort alle Schreibrechte haben, ist im Sinne des Erfinders. Beim abendlichen WebUpdate kommt also nur _ein_ Dump raus, also auch, wenn 10x upgedatet wird, aendert das nichts am Datenbestand. Ich lass mir das aber schon mal wieder durch den Kopf gehen

Dieter

[Andreas Korthaus]

Hi!

www.php.net und das gleichnamige Suchwort oben rechts eingeben (FTP)...
http://www.php.net/manual/de/ref.ftp.php der entsprechende Link.
Ok, ich hab kurz ins Manual geschaut und hab jetzt ne Idee von der Marschrichtung

Vielleicht als kleiner Ergänzung zum Manual: http://www.dclp-faq.de/q/q-datei-upload-ftp.html

Ach ja, wie erstellst Du den Dump? Auch automatisch?

Grüße
Andreas

[Dieter Raber]

Hallo,

Ich hab ein Script geschrieben, dass auch ein paar Anleihen bei anderen Autoren  macht. Im Prinzip klickst Du nur noch auf einen Link und fertig. Moechtest du eine Kopie (PHP)?

Dieter

[Andreas Korthaus]

Hallo!

Ich hab ein Script geschrieben, dass auch ein paar Anleihen bei anderen Autoren  macht. Im Prinzip klickst Du nur noch auf einen Link und fertig. Moechtest du eine Kopie (PHP)?

"Wenn Du es nicht lassen kannst"(und das Script nicht gerade 10KB hat) kannst Du es ja hier posten, dann finden es andere Leute die nach diesem Problem vielleicht mal im Archiv suchen!

Grüße
Andreas

[Dieter Raber]

Hallo,

"Wenn Du es nicht lassen kannst"(und das Script nicht gerade 10KB hat) kannst Du es ja hier posten, dann finden es andere Leute die nach diesem Problem vielleicht mal im Archiv suchen!

Das Script ist ca 50% bei_andern_klau und 50% Dieter und das alles ohne Copyrighthinweise, was solange ok ist, wie ich es fuer meine eigenen Zwecke nutze. Aber so richtig veroeffentlichen waere nicht so nett.

Dieter

[Andreas Korthaus]

Hallo!

"Wenn Du es nicht lassen kannst"(und das Script nicht gerade 10KB hat) kannst Du es ja hier posten, dann finden es andere Leute die nach diesem Problem vielleicht mal im Archiv suchen!
Das Script ist ca 50% bei_andern_klau und 50% Dieter und das alles ohne Copyrighthinweise, was solange ok ist, wie ich es fuer meine eigenen Zwecke nutze. Aber so richtig veroeffentlichen waere nicht so nett.

Wovon hast Du denn die 50%? Kannst es mir ja mal per mail schicken. Ich glaube ich habe noch nie anderen Code außer den aus Beispielen des Manuals oder der FAQ in meinen Scripten verwendet, außer einigen freien PHP-Klassen wie smarty oder pear. Mir ist fremder code meist zu kompliziert oder unvorteilhaft umgesetzt, aber manchmal bekommt man gute Ideen, also lass mal sehen...

Grüße
Andreas

[Dieter Raber]

Hallo,

Ist unterwegs

Dieter

[Andreas Korthaus]

Hallo!

Ist unterwegs

Danke Dir, nur der Vollständigkeit halber, ich habe jetzt nicht alles angesehen, aber wie es aussieht verwendest Du den größten Teil Deines Codes darauf den Dump zu erstellen, das ist bei mir eine Zeile:

system("mysqldump -u user -p password -h localhost database table > /path/to/dump.sql"); [2]

so ungefähr, und es wird eine Datei dump.sql mit einem vollständigen Dump der Tabelle erstellt. Dazu muß das Kommandozeilentool mysqldump [1] installiert sein, was es normalerweise ist, und Du mußt entsprechende Rechte haben das Programm mit PHP auszuführen. Ggfs. mußt Du den Pfad zu mysqldump angeben, z.B. system("c:/mysql/bin/mysqldump -u user ...

Naja, wollte es nur einwerfen.

Grüße
Andreas

PS:
[1]: http://de.mysql.com/documentation/mysql/bychapter/manual.de_MySQL_Database_Administration.html#mysqldump
[2]: http://www.php3.de/manual/de/function.system.php

[Dieter Raber]

Hallo,

man lernt halt nie aus...

Dieter