PHP settings per Domain anstatt per User?

[Ralph]

Wäre es nicht besser wenn die PHP settings per Domain (subdomain) anstatt per User Account einzustellen wären?
Mal angenommen ein User hat 30 Domains (webs) im Konto und nur eine davon benötigt z.b. fopen oder ein ganz spezielles disable_functions OFF ...
Mit einer php.conf "pro Domain (web)" wären somit nicht alle anderen Domains (webs) dieses Kunden davon betroffen und sinnvolle bzw. sichere PHP Settings bleiben für seine anderen Webs erhalten.

Im Grunde kann das Account Template so bleiben, als Vorlage eben ... beim anlegen von Zusatz Domains oder Subdomains werden diese Settings dann auch abgefragt und dann eine jeweilige .conf erstellt die dann über Domains editierbar wäre z.b. unter Apache Settings noch hinzu -> PHP settings ...

[24unix]

Moin Ralph,

ich fände dass nicht schlecht, aber wenn, dann als Option. Sonst läuft für jede Domain ein eigener FPM-Prozess, wenn bei den 30 Seiten 29 statische Visitenkarten sind ist das Resourcenverschwendung, wenn nur eine Domain wirklich individuelle Settings braucht.

Also evtl. als Auswahl: Default-Config oder Custom-Config. Und nur wenn Custom-Config, dann dafür einen extra FPM-Prozess starten.

[Ralph]

Moin Ralph,
ich fände dass nicht schlecht, aber wenn, dann als Option. Sonst läuft für jede Domain ein eigener FPM-Prozess, wenn bei den 30 Seiten 29 statische Visitenkarten sind ist das Resourcenverschwendung, wenn nur eine Domain wirklich individuelle Settings braucht.
Also evtl. als Auswahl: Default-Config oder Custom-Config. Und nur wenn Custom-Config, dann dafür einen extra FPM-Prozess starten.

Ja genau, auch die Weiterleitungen könnten dabei noch ausgeschlossen werden ... es soll ja nicht zwingend für alle Konten angewendet werden, nur in dem Fall wie im Beispiel oben ... bei einem User mit vielen Webs wäre es schon sinnvoll.

Eventl. nur für den Admin > für eine ausgewählte Domain (web) extra PHP conf aktivieren ... wäre noch einfacher, so könnte man gezielt eingreifen und alle anderen Webs dieses Kunden bleiben sicher/er.

[Tobi]

viewtopic.php?p=5079#p5079

[Ralph]

OK, wenn ich jetzt im Effizienz Modus denke dann wäre die beste Lösung wenn nur der Admin in Einzelfällen entscheidet eine extra conf für den fpm.pool erstellen zu können. In der Domain Table könnte dafür z.b. eine Spalte "ownphp" zum filtern hinzugefügt werden.
Nur der Admin kann dann im Panel unter Domains z.b. unter Apache settings einen Haken setzen der dann eine fpm.conf generiert, darunter kann der Admin dann zusätzliche Einstellungen setzen z.b. fopen on/off, disable_functions ...
Kleiner Hinweis .... es nur in Ausnahmefällen zu aktivieren (wo es sinnvoll ist) um die Prozesselast im Rahmen zu halten.
Beim löschen der Domain wird dann die "ownphp" Spalte berücksichtigt eventl. kann dort auch der Pfad zur conf noch hinterlegt werden.

[Tobi]

Aber noch viel einfacher ist es wenn du in solchen speziellen Fällen einfach einen weiteren User anlegst und fettig.

So handhabe ich das mittlerweile seit 2018 und gerade bei so Sachen wie nextcloud oder shopware ist ein zweiter User aus vielerlei Hinsicht besser.

[Ralph]

Aber noch viel einfacher ist es wenn du in solchen speziellen Fällen einfach einen weiteren User anlegst und fettig.
So handhabe ich das mittlerweile seit 2018 und gerade bei so Sachen wie nextcloud oder shopware ist ein zweiter User aus vielerlei Hinsicht besser.

Bei bestehenden Kunden mit vielen Webs wird's schwierig werden, auch wg. Quota usw. aber davon mal abgesehen, was die Probleme mit Prozessen betrifft, halte ich eher für unwahrscheinlich. PHP fpm mit mpm-event hat damit keine Probleme, jedenfalls auf einem anderen System mit eigener fpm conf u. starter pro Domain (ca. 700 Domains incl. Zusatz & Subdomains) sehe ich keinen Unterschied ... hält sich permanent stabil unter 400.

Code: Select all

pm = ondemand
pm.max_children = 6
pm.start_servers = 1
pm.min_spare_servers = 1
pm.max_spare_servers = 2
pm.process_idle_timeout = 60s
pm.max_requests = 1000