PHP Cli und (fake) DocumentRoot ? (Laravel)

  • Hallo zusammen,


    ein neuer Tag, ein neues Problem ^^


    Ich habe ein Skript welches ich auf der Kommandozeile ausführen möchte (Im Detail: Ich erstelle den Konfigurationscache für laravel).

    Das Skript macht fleißig gebrauch von __DIR__ um die Konfigurationspfade abzulegen.


    Nun ist aber mein Problem, dass __DIR__ in der CLI und im Browser verschieden sind.


    __DIR__ in der CLI

    Code
    bash-4.4$ pwd
    /projekt_xy
    bash-4.4$ php -r "echo __DIR__;"
    /projekt_xy


    __DIR__ im Browser

    /var/www/vhosts/hosting123.abc123.netcup.net/projekt_xy


    Meine Frage nun:
    Habt ihr einen Tipp für mich wie ich den Pfad "umbiegen" kann?

    Was mir spontan einfällt:

    • Mir schwebt der Gedanke vor die untere Ordnerstruktur temporär "nachzubauen" und von dort aus dann das Skript aufzurufen, die Idee gefällt mir aber überhaupt nicht.
    • Nachträglich in der generierten Konfigurationsdatei die Pfade anpassen
    • Ein Hilfsskript bauen (welches ich über den Browser aufrufe) das wiederum mein Skript aufruft. Dann bin ich ja nämlich im richtigen Pfad


    Danke Euch

  • Ist doch eh das gleiche Verzeichnis, solange das Skript in der Konsole die Pfade relativ zu /projekt_xy anlegt kann doch der Webprozess über /var/www/vhosts/hosting123.abc123.netcup.net/projekt_xy darauf zugreifen?!? Ansonsten hilft eventuell die realpath() Funktion. Welches Problem entsteht denn konkret?

  • Hallo tab


    dann hole ich mal ein wenig aus mit Informationen :)


    Ich mache ein automatisches Deployment eines Projekts mit Laravel.

    Nachdem das Deployment fertig ist, generiere ich den Konfigurationscache neu (php ./artisan config:cache)

    Der Befehl schnappt sich die vielen Konfigurationsdateien und baut daraus eine Einzelne.


    In der neuen Datei sind dann Einträge (als Resultat) wie:

    Code
    'path' => '/project_xy/storage/framework/cache/data',

    Die original Konfigurationsdatei für diese Zeile sieht so aus:

    Code
    'path' => storage_path('framework/cache/data'),


    Der Eintrag /project_xy/storage/framework/cache/dataexistiert aber für einen Aufruf im Web nicht und es kommt zu einer Fehlermeldung (open_basedir ...)


    D.h.

    Code
    Falsch
    'path' => '/project_xy/storage/framework/cache/data',
    Richtig
    'path' => /var/www/vhosts/hosting123.abc123.netcup.net/project_xy/storage/framework/cache/data

    Mache ich die diese Änderung in der gecachten Konfigurationsdatei händisch, funktioniert alles.


    storage_path() im original wird vermutlich auf __DIR__ zurückgreifen. Dies würde erklären, warum ich in der CLI und im Browserunterschiedliche Pfade habe. Mein Ziel (Wunsch) ist es also über die CLI valide Pfade für Aufrufe über den Browser zu erhalten.

  • Hatte KB19 nicht mal einen Workaround (für nextcloud) für dieses Problem gepostet? Sollte doch hier ebenfalls funktionieren.

    Meine Minecraft-Plugins auf SpigotMC (Open Source): www.spigotmc.org/members/mfnalex.175238/#resources

    Discord: discord.jeff-media.com

  • Hast Du da eventuell einen Link für mich?
    KB19 schreibt ja recht viel, ich konnte es auf anhieb nicht finden ^^

    Leider hab ich auch keinen Link, deshalb hatte ich ihn verlinkt, er wird bestimmt zeitnah antworten :) Jedenfalls war der Trick einfach die Variable abhängig von irgendwelchen Umgebungsvariablen mit dem ?-Operator zu setzen. Ich such noch mal schnell, vielleicht find ich den Link ja doch :)

    Meine Minecraft-Plugins auf SpigotMC (Open Source): www.spigotmc.org/members/mfnalex.175238/#resources

    Discord: discord.jeff-media.com

  • Wenn

    Hatte KB19 nicht mal einen Workaround (für nextcloud) für dieses Problem gepostet? Sollte doch hier ebenfalls funktionieren.

    Das hatte ich auch im Hinterkopf als ich das mit realpath() geschrieben habe. Die Frage ist halt, ob sich das ähnlich flexibel konfigurieren lässt wie bei Nextcloud, nämlich so, dass es updatesicher ist und der Pfad für Webprozess und CLI passt. Da war nur das data-Verzeichnis betroffen. Eventuell müsste man hier mehrere Pfade manuell anpassen. Da kenne ich mich leider mit Laravel und Artisan nicht aus.

  • Es gibt sicherliche mehrere unterschiedliche Ansätze, dein Problem mit den Pfadnamen zu lösen.

    Ich persönlich lasse Webserver und php immer in eigenen chroot Umgebungen laufen.

    (...)

    Der Eintrag /project_xy/storage/framework/cache/dataexistiert aber für einen Aufruf im Web nicht und es kommt zu einer Fehlermeldung (open_basedir ...)
    (...)

    Mal angenommen, du benutzt auch php-fpm, dann würde man hier in der Konfigurationsdatei des fpm pools chrooot = /var/www/vhosts/hosting123.abc123.netcup.net/ setzen und dann existiert auch /project_xy/storage/framework/cache/data

  • Danke für Eure Antworten,


    echi dieses Projekt (muss) auf einem shared Hosting laufen. Bei meinen vservern hätte ich ja viiiel mehr Freiheiten ;)


    Ich habe als Lösung vorerst die Option gewählt, dass ich in der generierten Cache-Datei die Pfade manuell umbiege.


    Falls jemand auf das gleiche Problem stößt, so habe ich es gelöst:

    1. neuer artisan command: php artisan config:cacheSharedWebhosting /var/www/vhosts/hosting123.abc123.netcup.net
      der Parameter ist der Pfad der vorangestellt wird
    2. im Skript selbst ermittle ich den Hauptordner der Webanwendung --> /project_xy
    3. im Skript: /bootstrap/cache/config.php öffnen und nach /project_xy suchen. Hier den übergebenen Parameter aus dem Aufruf voranstellen

    Die Lösung ist nicht wirklich schön, aber sie funktioniert. Auf Dauer ist es denke ich eh besser das Projekt auf einen vServer zu migrieren, da ich früher oder später mit Sicherheit auf weitere Einschränkungen stoßen werde.

  • KB19 Klar, die data.config.php hab ich ja auch genau so im Einsatz (gehabt). Aber da meine Nextclouds nicht mehr bei netcup sind, brauch ich es nicht mehr. Muss mich auch nicht mehr mit open_basedir rumschlagen, was der Performance deutlich gut tut. Aber ich bin jedenfalls bei dir, das wird dem TE nicht weiterhelfen.