Wie kann ich in eine SQLite-Datenbankdatei im Webspace eines SourceForge-Projekts schreiben?

Question

Ich habe eine kleine Perl-basierte CGI-Anwendung, die ich im Projekt-Webspace für ein SourceForge-Projekt ausführe. Diese Anwendung speichert Daten in einer SQLite (v. 3) Datenbankdatei.

Wenn ich Testskripte über eine Shell ausführe, kann ich von dieser SQLite-Datei lesen und in sie schreiben. Wenn der CGI-Code jedoch von Apache ausgeführt wird, hat er nur Lesezugriff. Schreibvorgänge führen zu einem Fehler in der Protokolldatei:

error.log.web-2:[Wed Oct 27 14:40:22 2010] [error] [client 127.0.0.1] DBD::SQLite::db do failed: unable to open database file

Zu Testzwecken habe ich die Berechtigungen für die SQLite-Datei auf 777 erhöht. Kein Unterschied.

Allerdings gibt es ein paar lustige Vorbehalte gegen SourceForges Projekt-Webspace, und ich frage mich, ob ich dadurch in die Irre geführt werde. Im Allgemeinen ist das Dateisystem des Webservers für den Apache schreibgeschützt. Wenn Sie Dateien haben, die zur Laufzeit beschreibbar sein müssen, sollten Sie diese in einem speziellen "persistenten" Verzeichnis an anderer Stelle speichern... und Symlinks von Ihrem Webspace zu den tatsächlichen Dateien in diesem Verzeichnis erstellen.

Ich habe dies getan, und die Berechtigungen sind auf 777 für beide Symlinks gesetzt et die eigentliche SQLite-Datei unter dem Speicherort "persistence". Ich weiß, dass dieser Mechanismus im Allgemeinen funktioniert, weil ich dasselbe mit Cache- und Protokolldateien mache und es dort funktioniert.

Ich frage mich, ob es etwas funky über SQLite selbst, entlang der Linien von es nicht wollen, einen Symlink (anstatt eine Rohdatei) für das Schreiben zu öffnen.

Answer 1

Ich glaube, die Antwort auf diese Frage lautet, dass das nicht möglich ist. Weitere Nachforschungen über SQLite haben mir gezeigt, dass der Treiber eine Sperre für die Datenbankdatei erhalten muss, bevor er Schreiboperationen durchführen kann. Diese Art von Sperre kann nicht erlangt werden, wenn sich die eigentliche Datei auf einem anderen Rechner befindet, dessen Dateisystem quer gemountet ist.

Ich glaube, dass dies beim Webspace-Hosting des SourceForge-Projekts der Fall ist. Es sieht so aus, als befände sich das (beschreibbare) "persistente" Verzeichnis tatsächlich auf einem völlig anderen Rechner als das schreibgeschützte Webserver-Dateisystem.

Kurz gesagt, wenn Sie über diese Frage stolpern, weil Sie das gleiche Problem haben ... entweder für andere Webspace-Hosting suchen, oder sonst kann es Zeit sein, Ihre App zu überarbeiten und Schritt bis zu MySQL oder eine andere DB (SourceForge gibt Ihnen kostenlose MySQL-Hosting sowieso).

Answer 2

Ein weiteres Problem besteht darin, dass Sie zwar über die Berechtigungen für die betreffende db-Datei verfügen, aber nicht die Berechtigung haben, die temporären Dateien im Verzeichnis zu erstellen. (Gemischte Berechtigungen oder zu restriktive Berechtigungen)

https://www.sqlite.org/tempfiles.html

Wenn Sie die temporären Dateien nicht schreiben können, können Sie auch keine Schreibvorgänge in einer Sqlite-Datenbankdatei durchführen. Wenn Sie zu einer :memory: Datenbank wechseln, könnten Sie es schaffen oder vielleicht das von @bob.faist erwähnte pragma verwenden PRAGMA temp_store = MEMORY aber Sie sollten das Problem mit den Berechtigungen diagnostizieren und beheben, wenn möglich.

Verwenden Sie diese Befehle, um festzustellen, ob Sie die Berechtigung haben, an diesen Dateispeicherorten zu schreiben.

ls -l app.db
getfacl app.db
ls -l -d .  # check the directory to see if you can write the temp files there
getfacl .

Utilice chmod o setfacl -m um die Dateien oder Ordner zu fixieren, damit Sie in sie schreiben können.

Überprüfen Sie auch Ihren Speicherplatz.

df -k

Wenn es anzeigt, dass die Partition, auf der sich die Datenbankdatei befindet oder auf die sie zu schreiben versucht, voll ist, können Sie auch diese Art von Problemen bekommen.

Ich hoffe, das hilft.