PHP soll ein Shellscript Starten : mysql<backup

[amiga1200]

Ich habe ein shellscript geschrieben, was ein Mysql Backup zurück spielt.

Code: Select all

echo $(date)  >>log.txt;
mysql <$1;

was als Root über Shell gut funktioniert, klappt unter PHP nicht.
<?php
exec("./fun.sh DB-29.06.11.sql");
?>

Das Script wird zwar gestartet, ich glaube aber ohne Rootrechte lässt sich Mysql nicht überreden zu starten.

Es geht um eine einfache wiederherstellungs-Funktion für Mysql übers Web.
Rein über PHP wollte ich es nicht realisieren, weil schnell ein Time-out
zu schlagen kann.

Hat jemand eine Idee?

(Gesichert wird täglich über Cron)

[EdRoxter]

Du müsstest im Shellscript dem mysql-Befehl auch als Parameter noch den Datenbankuser und das Passwort übergeben, da, wie du richtig erkannt hast, das Shellskript als der unprivilegierte User ausgeführt wird, unter dem auch PHP ausgeführt wird (bei mod_php der User des Webservers, also www oder www-data; bei suPHP und/oder FastCGI je nach Konfiguration).

Jedenfalls müsste im Shellskript was à la

Code: Select all

mysql -u dbuser -p passwortdesusers <$1;

stehen, wobei der User natürlich auf die entsprechende Datenbank Zugriff haben muss.

[ddm3ve]

Um generell eine Sicherheitslücke zu vermeiden würde ich den direkten Systemzugriff z.B. per exec vermeiden und lediglich ein Triggerfile an legen. Z.b. in einem nicht öffentlich erreichbaren Ordner, für jede Datenbank die restored werden soll, ein eigenes Triggerfile.

Das ganze lässt sich generisch lösen und ein, per Cron angestossenes, Shell Script restored diese Datenbank. Ein weiteres Triggerfile signalisiert der Anwendung dann z.B. ob der Restore gerade läuft oder abgeschlossen ist.

Als Beispiel:

/restore-trigger/mysql-test

/restore-trigger/mysql-test.inprogress

/restore-trigger/mysql-test.done

Um das ganze "zeitnah" zu realisieren kan man eine simplem Schleife erstellen, welche genau 58 mal durchlaufen wird und das Script minütlich vom cron angestossen wird.
Ist nichts zu erledigen, wartet die Schleife je Durchgang 1 Sekunde mit z.B. sleep 1.

Ich denke, das ist schnell genug um von zeitnah zu reden, was ein direktes starten durch php unnötig macht.

Meine Einschätzung nach würde auch ein minütliches prüfen ausreichen.

[rudelgurke]

Oder - neben den Triggern - das Backup anders gestalten dass anstatt der kompletten DB die Tabellen einzeln gesichert werden und dann bei Bedarf wieder eingespielt - um Timeout Probleme zu vermeiden.

[ddm3ve]

Bei der Lösung hat er ggf. das Problem von Dateninkonsistenzen.

Bei einer Sicherung einer Datenbank sollte möglichst ein writelock auf alle Tabellen der Datenbank bestehen. Beim späteren Restore will man i.d.R ebenfalls ein konsistenten Stand haben.
Im Einzelfall mag das ein legitimes Verfahren sein einzelne Tabellen zu restoren, aber bei unbekannten Schematas und darüber liegenden Anwendungen, würde ich das generell vermeiden wollen.