PHP Script mit SQLite3 - Aufruf regiert überall anders

  • Hallo zusammen,

    Ich habe folgendes Problem und bisher keine Lösung in den Weiten des Internets und hier gefunden:

    Ich habe auf meinem Pi3 den apache2 installiert und laufen und möchte dort eine html Seite mit PHP Code zur Verfügung stellen (nur interner Gebrauch). Der PHP Code soll die Verbindung zu einer SQLite3 Datenbank aufbauen und steuern (Auslesen und füllen).

    Wenn ich den Codeschnipsel in der shell direkt mit $ php ps.php aufrufe, funktioniert er einwandfrei.

    Sobald ich den Schnipsel aber in eine html Seite einbaue funktioniert es nicht mehr.

    Mit der Endung .php wird bei Chrome nur "Ende" angedruckt, was mir zeigt er geht in den PHP Teil und interpretiert ihn, steigt dann aber wohl beim SQLite aus.

    Mit der Endung .php bekomme ich beim IE "HTTP 500: interner Serverfehler"

    Wenn ich den ganzen SQLite teil rauslösche, zeigt der IE "EndeEnde2" an.

    die HTML Seite "index.php" sieht wie folgt aus :

    (wie gesagt, nut eine Testseite)

    Ich hoffe jemand hat eine Idee.

    Viele Grüße

    Alti

  • PHP Script mit SQLite3 - Aufruf regiert überall anders? Schau mal ob du hier fündig wirst!

  • Wenn ich den Codeschnipsel in der shell direkt mit $ php ps.php aufrufe, funktioniert er einwandfrei.

    "Ich" gibt es bei einem Mehrbenutzerbetriebsystem nur insoweit, als der Sysadmin einen User "ich" angelegt hat und dieser "ich" eingeloggt ist.

    Dann wird die Shell als eingeloggter User mit dessen User- und Gruppenrechten und dessen Environment (Umgebungsvariablen) abgearbeitet.

    < whoami >, also wer bin ich ? zeigt den Usernamen an,

    < id > dessen Uid und dessen Gruppenmitgliedschaften.

    < ls -al /Pfad/zu/ps.php > zeigt die Rechte des php-Codeschnipsels

    < ls -al /Pfad/zu/index.php > die Rechte der php Startdatei

    < ls -al /mnt/hdd/SQLite3.db > die Rechte des Datenbankfiles

    Finde den (Rechte-)Fehler !

    Servus !

    PS: Der Apache Webserver läuft mit dem Environment und dem User/Gruppe, die in seinem Config-File stehen.

    RTFM = Read The Factory Manual, oder so

    Einmal editiert, zuletzt von RTFM (26. September 2018 um 12:27)

  • Danke für die schnelle Antwort.

    Die Rechte stehen auf 0777, deshalb gehe ich davon aus, dass der Zugriff funktioniert. Wie gesagt der Webserver ist nur für den internen Gebrauch.

    Aber das Error.log schreibt folgendes:

    Die ini Dateien mit den ganzen extension=sqlite3.so etc. liegen im php5 Verzeichnis.

  • Die Rechte stehen auf 0777, deshalb gehe ich davon aus, dass der Zugriff funktioniert. Wie gesagt der Webserver ist nur für den internen Gebrauch.

    Diese Annahme ist leider unrichtig.

    Zugriff, also lesen, schreiben, löschen auf das File reicht nicht aus.

    Der sctipt-aufrufende User muss auch berechtigt sein auf die vom Script verwendeten Ausgabe-Devices zu schreiben und zu lesen.

    Im Verzeichnis /dev/ - und unterhalb - sind die Rechte, insbesondere Gruppen(schreib)rechte ersichtluch.

    Die Rechteverwaltung macht keinen Unterschied, ob ein File intern, normal oder extern verwendet wird. Dazu kommt möglicherweise bei Dir auch noch ein Mount-Fehler.

    Servus !

    RTFM = Read The Factory Manual, oder so

  • Hmmm... auf PHP Seite schein alles zu funktionieren.

    Code
    Testi@Test:/var/www/html $ sudo -u www-data php /var/www/html/ps.php
    111110-0-11111-0011-0-000+045+300+010+3600+0099+2018-09-25 03:21:20.266102824

    Das PHP Script liefert auch als www-data.

    Die Anmerkung "Nur interner Gebrauch" war nur, da 777 doch sehr weitreichende Rechte sind.

    Das Error.log moppert die fehlende .so-Datei-Einbindung an. Nur eigentlich sieht alles gut aus. Wo kann ich noch suchen?

    • Offizieller Beitrag

    da 777 doch sehr weitreichende Rechte sind

    Aber das Thema verfehlen.... ;)


    Ersetz mal bitte die Zeile 11 mit folgendem:

    PHP
    if ($db = sqlite_open('/mnt/hdd/SQLite3.db', 0666, $sqliteerror)) { 
      echo "Zugriff erfolgreich";
    } else {
        die($sqliteerror);
    }

    Ich kenne mich zwar nicht wirklich mit SQLite aus, aber das ist eine leichte Abwandlung von der Doku.

  • Das sind die letzten Fehlermeldungen.

    Code
    [Wed Sep 26 18:02:36.152400 2018] [:error] [pid 31500] [client 192.125.36.5:58895] PHP Fatal error:  Call to undefined function sqlite_open() in /var/www/html/index.php on line 11
    [Wed Sep 26 18:04:40.285973 2018] [:error] [pid 30496] [client 192.125.36.5:59100] PHP Fatal error:  Class 'SQLite3' not found in /var/www/html/index.php on line 11

    hab dann beim 2. Lauf sqlite_open() durch SQLite3 ersetzt. Ich verstehe nur nicht, dass php alleine keine Probleme hat und im apache plötzlich SQLite nicht mehr kennt.

    Einmal editiert, zuletzt von Alti (26. September 2018 um 20:12)

    • Offizieller Beitrag

    Was wird das hier... ein Monolog oder liest Du das was wir hier schreiben auch mal? :-/

    Also nochmals, der User www-data darf per default nicht auf Wechseldatenträger zugreifen. Das dürfen nur Mitglieder der Gruppe plugdev. Außerdem muss der Datenträger auch richtig gemountet und im Idealfall mit Linuxdateisystem formatiert sein. Erst danach bringt das unsinnige 777 die vermeintlich gewünschten weitreichenden Rechte, die aber unnötig bis gefährlich sind.

  • Was wird das hier... ein Monolog oder liest Du das was wir hier schreiben auch mal? :-/

    Hmmm... kann ich nicht nachvollziehen, denn wenn Du genau liest habe ich genau das gemacht was Du wolltest, leider hat es nicht funktioniert. Lohnt sich aber nicht drüber zu streiten.

    Ich habe jetzt www-data nicht nur in die Gruppe plugdev sondern auch gleich in die Gruppe root gepackt um zu testen ob es an den Rechten liegt.

    Code
    Testi@Test:/var/www/html $ groups www-data
    www-data : www-data root plugdev

    Leider funktioniert es nicht immer noch nicht.

    Und leider weiterhin die Fehlermeldung im apache2/error.log

    Code
    [Wed Sep 26 19:57:08.669798 2018] [:error] [pid 24292] [client 192.125.36.5:54247] PHP Fatal error:  Class 'SQLite3' not found in /var/www/html/index.php on line 11
  • Abfragen zu Punkt 1 bzw. Beitrag #3

    Code
    testi@test:~ $ id
    uid=1001(testi) gid=1001(testi) groups=1001(testi)
    testi@test:~ $ ls -al /var/www/html/ps.php
    -rw-r--r-- 1 root root 372 Sep 23 19:35 /var/www/html/ps.php
    testi@test:~ $ ls -al /var/www/html/index.php
    -rw-r--r-- 1 root root 800 Sep 26 18:04 /var/www/html/index.php
    testi@test:~ $ ls -al /mnt/hdd/SQLite3.db
    -rwxrwxrwx 1 root root 2121728 Sep 25 03:21 /mnt/hdd/SQLite3.db

    zu Punkt 2: Die Platte ist NTFS formatiert, da ich auch aus meiner Windowsumgebung darauf zu greife.

    zu Punkt 3 das ps.php

    PHP
    <?php
    $db = new SQLite3('/mnt/hdd/SQLite3.db');
    $results = $db->query("Select Status as status, strftime('%Y-%m-%d %H:%M:%f',timestamp) as timestp, id as id from LogTable where (Select max(id) from LogTable where so$
    while ($row = $results->fetchArray()) {
       echo $row['status'];
       echo $row['timestp'];
       echo $row['id'];
    }
    ?>
  • @
    @ Disk /dev/sdx: 931.5 GiB, 1000202043392 bytes, 1953519616 sectors

    @ Units: sectors of 1 * 512 = 512 bytes

    @ Sector size (logical/physical): 512 bytes / 512 bytes

    @ I/O size (minimum/optimal): 512 bytes / 512 bytes

    @ Disklabel type: dos

    Mit der 1 TB Platte und MBR (type dos) brauchst Du gar nicht weiterarbeiten. Die I/O size von 512/512 (statt 512/4096) würde sie ja noch vertragen.

    Formatiere sie im Windows-Rechner komplett neu, oder verpass ihr einen GPT Header (Disklabel type: GPT).

    Servus !

    RTFM = Read The Factory Manual, oder so

  • Hallo zusammen,

    Problem ist gelöst.

    Ich komme aber leider jetzt erst dazu zu schreiben.

    Ihr hattet Euch so auf das Rechte-Thema eingeschossen, dass Ihr wohl auch meine Beiträge nicht akkurat genug gelesen habt. Am Ende stand im Raum warum funktioniert PHP mit SQLite als Script, aber nicht als Teil der HTML Seite über den Apache2.

    Es hatte nichts mit den Dateizugriffsrechten zu tun, noch mit der Art der Formatierung oder dem Einhängen der Festplatte.

    Es ist einfach das PHP aus der Shell auf eine andere .ini Datei zugreift als über den Apache2.

    Trotzdem waren Eure Beiträge sehr hilfreich und dafür mochte ich Euch danken. Besonders der Hinweis mit den Logs, der mich dann auf die Spur gebracht hat. Ja, eigentlich sollte Logs checken standard sein, aber ich denke da nie dran. Nobody is perfect, aber das wisst ihr ja selber.

    Nochmals vielen Dank für die Unterstützung.

    Hier für alle die ein ähnliches Problem haben:

    Die php.ini liegt bei Jessie unter /etc/php5/apache2

    unter Stretch liegt es unter /etc/php/7.0/fpm

    In der php.ini gibt es einen TAG:

    [sqlite3]

    ;sqlite3.extension_dir =

    Der muss entkommentiert werden und das Verzeichnis der .so Dateien für SQLite3 eingetragen werden.

    Die .so Dateien findet in einem Verzeichnis

    bei Jessie unter /usr/lib/php5

    bei Stretch liegt es unter /usr/lib/php

    Dort findet Ihr ein Verzeichnis im Datumsformat YYYYMMDD.

    In diesem Verzeichnis sind die .so Dateien

    Dieses Verzeichnis muss dann in die php.ini unter dem TAG eingetragen werden.

    Bei mir sieht das dann so aus

    unter Jessie:

    [sqlite3]

    sqlite3.extension_dir =/usr/lib/php5/20131226

    unter Stretch:

    [sqlite3]

    sqlite3.extension_dir = /usr/lib/php/20151012

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!