Neos 7.1 Grundeinstellung settings.yaml - core:

Hallo,

ich betreibe ein Neos CMS in der Version 4.x bei netcup.
Jetzt möchte ich ein neues Neos CMS 7.1 aufsetzen und habe einige Schwierigkeiten.

In der Version 4 hatte ich in der Settings.yaml
core: phpBinaryPathAndFilename: /usr/local/php72/bin/php
angegeben.

In der Version 7.1 bekomme ich mit der Angabe
core: phpBinaryPathAndFilename: /usr/local/php74/bin/php
Eine Fehlermeldung, wenn ich mich im Backend einloggen möchte.

Warning: realpath(): open_basedir restriction in effect.
File(/usr/local/php74/bin/php) is not within the allowed path(s):
(/var/www/vhosts/hostingxxxxx.netcup.net/:/tmp/:/var/lib/php/sessions)
in
/var/www/vhosts/hostingxxxxx.netcup.net/httpdocs/neos7/Packages/Framework/Neos.Flow/Classes/Core/Booting/Scripts.php
line 842
Type: Neos\Flow\Error\Exception
Code: 1
File: Packages/Framework/Neos.Flow/Classes/Error/ErrorHandler.php
Line: 81
Open Data/Logs/Exceptions/20210511112927c20532.txt for a full stack trace.
Exception Code 1355480641
Exception Type Neos\Flow\Core\Booting\Exception\SubProcessException
Log Reference 20210511112919e1b90d
Thrown in File Packages/Framework/Neos.Flow/Classes/Core/Booting/Scripts.php
Line 702

Nach einer Anpassung der Zeile (/var/www/vhosts/hostingxxxxx.netcup.net/usr/local/php74/bin/php) kann ich mich einloggen.

Wenn ich dann über Cli arbeiten möchte, bekomme ich eine Fehlermeldung, dass

/var/www/vhosts/hostingxxxxx.netcup.net/usr/local/php74/bin/php nicht existiert (no such directory …)

Ich kann also entweder oder.

Bernd

Ich habe jetzt in der neos > Packages > Framework > Neos.Flow > Configuration > Settings.Core.yaml folgendes eingetragen:

phpBinaryPathAndFilename: ‘/usr/local/php74/bin/php’

und gleichzeitig den Part aus der neos > Configuration > Settings.yaml gelöscht.

Nun scheint es zu funktionieren. Ist das so OK?

Vielen Dank im voraus.
Bernd

Hi Bernd,

prima, dass es jetzt läuft. phpBinaryPathAndFilename ist die korrekte Einstellung zum anpassen.

Aber bitte ändere nichts in den Corepaketen selbst.
Lege in deinem Sitepackage eine Settings.yaml an (falls sie noch nicht existiert) und füge dort die entsprechenden Konfiguration ein. Oder in dem Configuration Ordner im Projektverzeichnis.
Sonst wirst du große Probleme mit Updates bekommen.

Hi Sebastian,
ich habe mich zu früh gefreut. Ich hatte gerade im Cli mit flush den Cache gelöscht und jetzt habe ich weiterhin das Problem.
Zuerst kann ich meine Änderung wieder rückgängig machen, damit die Corepakete sauber bleiben.
Aber was könnte ich sonst machen. Die Einstellung in der Configuration funktioniert ja nicht.
sh: /var/www/vhosts/hostingxxxxx.netcup.net/usr/local/php74/bin/php: Datei oder Verzeichnis nicht gefunden

Ich habe mich nun auf Fehlersuche begeben.
In der Datei neos\Packages\Framework\Neos.Flow\Classes\Core\Booting\Scripts.php habe ich in Zeile 842 den Inhalt ersetzt.
$realPhpBinary = realpath(PHP_BINARY);
geändert in
$realPhpBinary = '/usr/local/php74/bin/php';

Damit habe ich die Funktion außer Betrieb gesetzt und auch unerwünschterweise im Core Änderungen vorgenommen. Wenigstens scheint es jetzt zu funktionieren.

Hi Bernd,

Für den Aufruf über den Server genügt die Anpassung in den Settings.

Für das CLI reicht das allerdings nicht aus, da die Settings ja erst geladen werden nachdem der command bereits gestartet wurde.

Beim CLI hast du 2 Möglichkeiten das Problem zu lösen:

  1. Du führst deinen Command direkt mit dem korrekten php Pad aus:
    /usr/local/php74/bin/php ./flow flow:cache:flush

  2. Oder du passt in der flow Datei im Root das shebang tag entsprechend an:
    #!/usr/local/php74/bin/php

    <?php ...

Es ist eigentlich nicht nötig in den Core-Packages Änderungen vor zu nehmen.
Da diese bei einem Update ohnehin überschrieben werden und man dann im Update unschöne Fehler riskiert.

Hi Lean,

vielen Dank für Deine Anregungen. Ich habe die Core-Datei wieder in den Originalzustand versetzt.

./flow flow:cache:flush

geht ohne Probleme schon immer.

./flow kickstart:site Vendor.Site .... und ./flow site:import

funktionieren leider mit den Änderungen weiterhin nicht.
(weder mit /usr/local/php74/bin/php ./flow kickstart:site noch mit #!/usr/local/php74/bin/php in der flow Datei)

Leider fehlt mir weiterhin eine Lösung, vor allem, weil ich mit der Materie nicht vertraut bin.

Eigentlich hätte ich keine Probleme, wenn ich in der Configuration/Settings.yaml den kurzen Pfad angeben könnte. So hatte ich es auch in der Neos Version 4.
Durch die neue Vergleichsfunktion und die Variable $realPhpBinary = realpath(PHP_BINARY);
entsteht bei mir der Fehler. Es wird der absolute, lange Pfad mit dem kurzen Pfad aus der Settings.yaml verglichen. Das führt zu einer Fehlermeldung.

Hmmm das klingt seltsam. Hast du vorher nochmal das Verzeichnis Data/Temporary gelöscht?

Oh ich sehe gerade, dass der absolute Pfad bei dir ja /var/www/vhosts/hostingxxxxx.netcup.net/usr/local/php74/bin/php
sein muss, statt /usr/local/php74/bin/php.

Ja also versuch nochmal den absoluten Pfad. Und lösch dann noch das Data/Temporary Verzeichnis.

Ansonsten, kann es sein, dass dein ssh user ein anderer ist als der vom apache oder nginx und irgendwelche Rechte fehlen um auf die php version zuzugreifen?

Evtl. auch interessant: https://forum.netcup.de/anwendung/wcp-webhosting-control-panel/12701-unterschiedliche-working-directory-bei-php-über-cli-ssh-und-php-per-webserver/

Ich habe den absoluten Pfad eingesetzt und das Temporary Verzeichnis gelöscht.
Ich bekomme dann die Fehlermeldung:

./flow: /var/www/vhosts/hostingxxx.yyy.netcup.net/usr/local/php74/bin/php: Defekter Interpreter: Datei oder Verzeichnis nicht gefunden

Eigentlich arbeite ich ja gar nicht mit zwei verschiedenen Pfadangaben.
Die Pfadangabe /usr/local/php74/bin/php hatte in Neos 4 prima funktioniert und funktioniert auch in Neos 7.1 prima.
Leider gibt es in der Booting/Scripts.php eine Funktion, die meinen Pfad aus der Settings.yaml mit
dem realpath(PHP_BINARY); vergleicht. Diese Funktion macht mein running System platt, weil ich ja an der Fehlerseite dann nicht mehr vorbeikomme.
Sobald ich die Funktion “deaktiviere” funktioniert alles.
Allerdings sehe ich auch keinen Sinn darin, an den Coredateien zu manipulieren. Bisher ist es die einzige Lösung, die funktioniert.

Ich freue mich, dass Du Dir mein Thema ansiehst, nochmal Danke dafür.

Mhm ja also der Vergleich ist schon korrekt, weil die cli ja auch sub commands abfeuern kann und da wird dann sicher der Pfad aus den Settings genommen. Das wird also nur funktionieren wenn der Pfad in den settings und im cli gleich sind. :-/

Also müsste dann vermutlich /usr/local/php74/bin/php an beiden Stellen verwendet werden. Aber wenn der Webaufruf dann wiederum den Pfad nicht kennt, stimmt da etwas mit der Server Konfiguration nicht. Weil das sollte generell nicht so sein. Ich weis nur, dass es mit nextcloud und netcup auch ähnliche Probleme gab.

Man könnte das umgehen in dem man für den CLI-Aufruf separate Settings macht und den command dann z.B. mit FLOW_CONTEXT=production/cli ausführt. Dann werden settings geladen, die nur fürs cli gelten. Das ist aber ein Workaround, der schlimme Auswirkungen für die Inhalte haben kann wenn bestimmte Settings sich von den Settings für Web unterscheiden und man commands nutzt die was am content repository machen. :-/

Ich würde empfehlen das Problem serverseitig zu lösen und dafür zu sorgen, dass Server und CLI auch die selben Pfade verwenden. Alles andere ist relativ unsicher.

Also müsste dann vermutlich /usr/local/php74/bin/php an beiden Stellen verwendet werden.

Ja, richtig. Funktioniert auch und war auch in Neos 4 so, da habe ich diese Vergleichsfunktion in der Scripts.php nicht gesehen.

Aber wenn der Webaufruf dann wiederum den Pfad nicht kennt,

Der Webaufruf kennt ja den Pfad. Nur weil die Funktion meinen gültigen Pfad aus der Settings.yaml mit realpath(PHP_BINARY); vergleicht und diese nicht übereinstimmen, habe ich die Probleme.
Der Webaufruf funktioniert bei deaktivierter Vergleichsfunktion mit beiden Pfaden - also dem Langen und dem Kurzen. Die Cli funktioniert generell nur mit dem kurzen Pfad.
Ich denke, ich werde mal bei netcup nachfragen, warum ich auf die realpath(PHP_BINARY); den langen Pfad bekomme. Hätte ich dort den kurzen Pfad, wäre alles TOP.

OK jetzt verstehe ich das vollständig. :slightly_smiling_face:

Ich vermute, dass der kurze Pfad ein Symlink ist. Der wird dann beim vergleich nur an einer Stelle in einen Absoluten Pfad umgewandelt. Man müsste dann an der Stelle auf beide Pfade realpath anwenden um das auszugleichen denk ich.

Kannst du das einmal testen was dabei raus kommt wenn $configuredPhpBinaryPathAndFilename nur im Vergleich mit ebenfalls realpath() umgewandelt wird?

PHP: realpath - Manual

realpath() expands all symbolic links and resolves references to /./ , /../ and extra / characters in the input path and returns the canonicalized absolute pathname.

Das könnte auch bei anderen Shared Servern zu einem Problem führen die ähnlich konfiguriert sind.

Dank Deiner letzten Ausführung bin ich jetzt auf der richtigen Spur.
In meinen oberen Beiträgen habe ich als Ursache mehrfach die “Vergleichsfunktion” “verdächtigt”.
Diese hat damit gar nichts zu tun. Es ist alleine die Zeile 842 $realPhpBinary = realpath(PHP_BINARY);

Der wird dann beim vergleich nur an einer Stelle in einen Absoluten Pfad umgewandelt.

Bei mir wird ein Symlink nicht in einen absoluten Pfad umgewandelt. Nur ein absoluter und gültiger Pfad wird bei mir durch realpath überhaupt validiert.

realpath('/usr/local/php74/bin/php') ergibt keine Reaktion.

realpath('') ergibt /var/www/vhosts/hostingxxx.yyy.netcup.net/httpdocs/neos/Web

realpath(PHP_BINARY) ergibt /var/www/vhosts/hostingxxx.yyy.netcup.net/usr/local/php74/bin/php ABER NUR, wenn ich die lange Pfadversion in der Settings.yaml eingetragen habe.

Damit habe ich jetzt zwar ein gültiges Setup für realpath(), aber wie bereits geschrieben, funktioniert dann ./flow nicht mehr.

Neos selbst bzw. der Webaufruf funktioniert ja auch mit /usr/local/php74/bin/php
Zusammanfassung:
Mit dem Pfad /var/www/vhosts/hostingxxx.yyy.netcup.net/usr/local/php74/bin/php
in der Settings.yaml funktioniert Neos Webaufruf und realpath() wird korrekt behandelt.
./flow erzeugt dann eine Fehlermeldung.

Mit dem Pfad /usr/local/php74/bin/php in der Settings.yaml funktioniert Neos Webaufruf (wenn realpath() von mir manipuliert wurde) und ./flow.
realpath() erzeugt ohne meine Manipulation eine Fehlermeldung und der Webaufruf ist dann nicht möglich.

Mit /var/www/vhosts/hostingxxx.yyy.netcup.net/usr/local/php74/bin/php funktioniert das per ssh wahrscheinlich nicht, weil der ssh user keinen Zugriff auf diesen Bereich hat. :-/
Das könnte dann auch erklären warum realpath() bei dem kürzeren Pfad den Symlink nicht nachverfolgen kann.

Ich weis allerdings jetzt auch nicht so wirklich wie man mit dieser Server-Konfiguration umgehen soll. Der einzige Workaround der mir da einfällt ist dann tatsächlich mit jeweils einem anderen FLOW_CONTEXT zu arbeiten and dann für web und cli unterschiedliche Settings zu nutzen.

Vllt fällt ja noch jemand anderem was besseres ein?