Hallo!

Ich habe eine Frage an jene, die Joomla auf Froxlor nutzen, weil mir folgendes aufgefallen ist:

Nachdem ich die Joomla-Dateien ins web-root geladen und die Installation aufgerufen habe, erhalte ich die Fehlermeldung, dass die "configuration.php" nicht erstellt werden kann.
Das führte ich auf fehlende Rechte zurück und habe webroot temporär auf 777 gesetzt. 
Damit ist zwar das Installations-Problem gelöst, es lassen sich aber keinerlei Module oder Templates laden.

Augenscheinlich werden die Rechte durch FTP-Upload auf 10000:10000 gesetzt, Jommla über html erwartet jedoch www-data:www-data (ich kann aber auch falsch liegen, mit dieser Vermutung).

Kann mir jmd, der Joomla im Einsatz hat, nützliche Hinweise geben?

Danke & greets 

mod_php oder fcgid/fpm?

vor 23 Minuten schrieb d00p:

mod_php oder fcgid/fpm?

wo finde ich diese Einstellung bzw. wie lässt es ermitteln?

Na du weisst doch was du eingerichtet hast...hast du nix php spezielles eingerichtet, nutzt du wohl mod_php - hier solltest du dann libnss-extrausers einrichten, damit der user www-data der gruppe der kunden hinzugefügt werden kann, und dann solltest du auch kein zugriffsproblem mehr haben

heisst das im Umkehrschluss, wenn ich FCGID & PHP-FPM in den Einstellungen aktiviere benötige ich libnss-extrausers nicht?

Doch dann erst Recht, denn die PHP Prozesse laufen dann unter den customer Usern und die müssen ja bekannt sein

wie vorgeschlagen vorgegangen libnss-extrausers eingerichtet - scheint zu funktionieren: ftp user:group wird auf customer:customer umgeschrieben.

neues Problem entstanden: php wird nicht ausgeführt, sondern der code im browser angezeigt. Zum Test deaktiviere ich den <FilesMatch \.(php)$> im vhost => wird php ausgeführt.

vl auch von Bedeutung: 

Froxlor\Cron\Http\ApacheFcgi::reload: running service php8.0-fpm restart
sh: 1: service: not found

 

1 hour ago, saxandl said:

Froxlor\Cron\Http\ApacheFcgi::reload: running service php8.0-fpm restart
sh: 1: service: not found

vllt von bedeutung? Ziemlich sicher...was hast du denn für nen OS das er den "service" befehl nich hat?

Im Zweifel musst du halt in den froxlor/php-fpm-daemon settings den korrekten reload-command angeben

vor 38 Minuten schrieb d00p:

 nen OS das er den "service" befehl nich hat?

als root von der console:

# sudo service Usage: service < option > | --status-all | ....

• Debian 10
• Apache 2.4.38
• php 8.0
• MariaDB 10.3.31

vor 43 Minuten schrieb d00p:

froxlor/php-fpm-daemon settings den korrekten reload-command angeben

wo finde ich froxlor/php-fpm-daemon settings?

sudo? als root? Brauchste nich, der cron läuft doch (hoffentlich!) als root user, der braucht die rechte und "service php8.0-fpm restart" sollte problemlos gehen, ggfls nimmste halt einfach "systemctl restart php8.0-fpm"

2 minutes ago, saxandl said:

wo finde ich froxlor/php-fpm-daemon settings?

Als admin einloggen, links im Menü "PHP-FPM Versionen"

2 hours ago, saxandl said:

neues Problem entstanden: php wird nicht ausgeführt, sondern der code im browser angezeigt. Zum Test deaktiviere ich den <FilesMatch \.(php)$> im vhost => wird php ausgeführt.

Settings -> PHP-FPM -> Use mod_proxy / mod_proxy_fcgi steht aber auf "Ja" oder? das muss bei debian 9+ 

Auch nicht vergessen dann die Webserver Configuration-Templates zu prüfen, ggfls musst du entsprechende module noch aktiveren (die config-templates zeigen dir die befehle dafür an)

vor 32 Minuten schrieb d00p:

Auch nicht vergessen dann die Webserver Configuration-Templates zu prüfen, ggfls musst du entsprechende module noch aktiveren (die config-templates zeigen dir die befehle dafür an)

a2enmod proxy_fcgi => alles gut

thanks!

update: leider ein Folgeproblem aufgetreten:

apache error.log:
AH01215: suexec policy violation: see suexec log for more details: 

suexec.log
uid: (10000/<customer>) gid: (10000/<customer>) cmd: env.cgi
command not in docroot (/mnt/datastore2/webs/<customer>/<domain>.<tdl>/shop/cgi-bin/env.cgi)

sieht so aus, was würde das env.cgi aufgrund Rechteproblem nicht ausgeführt werden können.

Es gibt da bei den Einstellungen Perl/CGI den Punkt
 - Aktiviere SuExec-Workaround
der vermutlich angepasst werden muss.

Ich habe die Pfade grundsätzlich so angelegt, dass sich das Verzeichnis /cgi-bin/ unterhalb des 
docroots befindet:
/var/customers/webs/<customer>/<domain>.<tdl>/cgi-bin/
und dies in der vHost-Einstellung über ScriptAlias definiert.  

Wie sollte die Konfiguration angepasst werden?

Wenn suexec nutzt, musst du den "SuExec Workaround" nutzen, also "Enable SuExec workaround" auf ja, und "Path for customer perl-enabled directory symlinks" auf einen Pfad der innerhalb der suexec Directory von apache liegt.

Dann als customer -> Pfadoptionen -> /domain.tld/ -> Exec Perl: yes

Es wird dann ein /cgi-bin/ Ordner als Symlink in die suexec-directory erstellt (achtung, du solltest den vorhandenen ordner dann umbenennen!!!).

Custom vHost Einstellungen mit ScriptAlias oder sowas brauchst du nicht

bin exakt wie beschrieben vorgegangen. softlink's werden korrekt eingerichtet, apache scheint nicht richtig darauf zu reagieren:

AH02811: script not found or unable to stat: /usr/lib/cgi-bin/env.cgi

 

wie kommst du denn jetzt auf einmal auf /usr/lib/cgi-bin/ ???

vor 16 Minuten schrieb d00p:

wie kommst du denn jetzt auf einmal auf /usr/lib/cgi-bin/ ???

das weiss ich nicht! das cgi-script wird nicht im Verzeichnis ausgeführt - daher hab ich ins logfile geschaut. 

 

Bisschen mehr info, was is das denn für nen script? Was macht es? Verweist das ding vllt selbst irgendwo auf /usr/lib/ oder sowas? Da kann ich dir halt nur bedingt helfen 

vor 16 Minuten schrieb d00p:

Bisschen mehr info, was is das denn für nen script? Was macht es? Verweist das ding vllt selbst irgendwo auf /usr/lib/ oder sowas? Da kann ich dir halt nur bedingt helfen 

das script selbst tut nichts anderes, als das Environment auszulesen und an den Browser weiter geben - vergleichbar mit phpinfo().

Am script liegt es definitiv nicht! 

Wenn ich das script über den Browser aufrufe, bekomme ich einen 404-error und im logfile den beschriebenen error. Es sieht so aus, als würde apache nicht auf das Verzeichnis des customers zugreifen, sondern das script im Verzeichnis /usr/lib/cgi-bin/ ausführen versuchen.

Nur zur Sicherheit: FCGID ist deaktiviert

zeig doch bitte das script einfach und nen ls auf das customer dir wo die liegt und permission/ownership und den vhost der datei und und und. Ich kann dir nicht auf den server gucken sondern nur raten und ohne info wird  das schwer.

FCGID hat mit Perl genau nix zu tun

On 10/13/2021 at 5:35 PM, saxandl said:

Hallo!

Ich habe eine Frage an jene, die Joomla auf Froxlor nutzen, weil mir folgendes aufgefallen ist:

Nachdem ich die Joomla-Dateien ins web-root geladen und die Installation aufgerufen moto x3m habe, erhalte ich die Fehlermeldung, dass die "configuration.php" nicht erstellt werden kann.
Das führte ich auf fehlende Rechte zurück und habe webroot temporär auf 777 gesetzt. 
Damit ist zwar das Installations-Problem gelöst, es lassen sich aber keinerlei Module oder Templates laden.

Augenscheinlich werden die Rechte durch FTP-Upload auf 10000:10000 gesetzt, Jommla über html erwartet jedoch www-data:www-data (ich kann aber auch falsch liegen, mit dieser Vermutung).

Kann mir jmd, der Joomla im Einsatz hat, nützliche Hinweise geben?

Danke & greets 

Hier klingt es ganz danach, als würdest du in eine typische Owner/Permission-Falle von Froxlor tappen. Im Normalfall sollte dein Webroot dem System-User gehören, den Froxlor für deine Domain anlegt – also z. B. web1:client1 oder ähnlich, nicht www-data. Joomla muss dann unter genau diesem User laufen, nicht unter www-data.

Wenn du per FTP hochlädst, stimmen die Besitzer meist, aber Joomla braucht Schreibrechte via PHP, also setz besser Ordner auf 755 und Dateien auf 644. 777 solltest du unbedingt vermeiden.

Prüf in Froxlor, welcher Webuser deiner Domain zugewiesen ist, setz via SSH/Panel die Ownership korrekt und dann klappt auch das Installieren von Templates/Modulen wieder.