KeyHelp Community

Hallo,

ich betreibe auf einer Subdomain eine Nextcloud-Instanz. Die Nextcloud-Dokumentation empfiehlt mindestens die folgenden Einstellungen für diese Domain, um eine stabile Umgebung zu gewährleisten, die, was Geschwindigkeit angeht, auch noch mit dem heutigen Zeitgefühl mithalten kann:

Code: Select all

opcache.enable=1
opcache.enable_cli=1
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=10000
opcache.memory_consumption=128
opcache.save_comments=1
opcache.revalidate_freq=1

Wie kann ich die genannten Einstellungen für meine Subdomain cloud.example.com setzen?
Außerdem: Haltet ihr das für sinnvoll? Was könnte man noch optimieren?

Beste Grüße,

Jay

Ich habe für Nextcloud einen eigenen Benutzer angelegt. Und dieser hat eine eigens dafür angelegte Domain, die ja auch eine Subdomain sein kann, zugewiesen bekommen. So kann man entspannt alle Einstellungen am Benutzer vornehmen.

Und mit diesen Einstellungen fahre ich sehr gt:

Code: Select all

opcache.enable_cli=1
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=10000
opcache.memory_consumption=128
opcache.save_comments=1
opcache.revalidate_freq=1

Im open_basedir habe ich folgendes eingetragen:

Code: Select all

##DOCROOT##/www:##DOCROOT##/files:##DOCROOT##/tmp:/dev

disable_functions lauten bei mir:

Code: Select all

dl, disk_free_space, diskfreespace, stream_socket_sendto, proc_get_status, proc_nice, proc_open, proc_terminate, proc_close, popen, curl_multi_exec, pcntl_exec, pcntl_fork, pcntl_setpriority, symlink, link, posix_kill, posix_mkfifo, posix_setsid, posix_setuid, posix_setpgid, posix_getpwuid, show_source, highlight_file, syslog, error_log, openlog, define_syslog_variables, apache_child_terminate, apache_setenv, apache_note, exec, system, shell_exec, passthru

Ergänzend zu Reseller4711s Antwort:

Setzen kannst du das Ganze über den KeyHelp Adminbereich:

-> Benutzerverwaltung
-> den entsprechenden Benutzer zum Bearbeiten auswählen
-> bis nach unten scrollen, dort wo "PHP-Einstellungen" stehen und darauf klicken
-> hier die o.g. Angaben in die Felder eintragen - die opcache Anweisungen in das Feld "Zusätzliche PHP-Einstellungen"

Hi,

danke für die Tipps. Ich werde es mal über KeyWeb machen. Frage ist nun:

- wie kriege ich die Nextcloud aus "/home/users/jay/www/cloud.jacboy.com" nach "/home/users/nextcloud/www/"
- wie setze ich dann die Berechtigungen korrekt auf den KeyHelp-User "nextcloud"
- gibt es eine Möglichkeit, die Datenbanken KH-intern dem neuen Nutzer zu zuweisen?
- dasselbe sollte mit der Subdomain "cloud.jacboy.com" passieren.

Beste Grüße,

Jay

jacboy wrote: ↑Fri 9. Feb 2018, 11:45 - wie kriege ich die Nextcloud aus "/home/users/jay/www/cloud.jacboy.com" nach "/home/users/nextcloud/www/"
- wie setze ich dann die Berechtigungen korrekt auf den KeyHelp-User "nextcloud"
- gibt es eine Möglichkeit, die Datenbanken KH-intern dem neuen Nutzer zu zuweisen?
- dasselbe sollte mit der Subdomain "cloud.jacboy.com" passieren.

Tja, aktuell ist es nicht vorgesehen eine Domain von User A nach User B zu verschieben.

@Keyhelp
Ich hatte es schonmal geschrieben, dass die Bindung der PHP-INI Einstellungen an einen User aus meiner Sicht Nachteile nach sich ziehen. Das hier ist so einer. Ist es denn angedacht mittelfristig, besser noch kurzfristig

, die PHP-INI Einstelllungen an die jeweilige Sub-Domain zu binden?
Nur so kann man dann innerhalb eines Users überhaupt unterschiedliche PHP Versionen verwenden. Aktuell ist die PHP Umschaltung an die Sub-Domain gebunden. Aber eigene PHP-INI Einstellungen sind dann halt nicht möglich.

Ja, denke ich mir. Deswegen muss man es ja irgendwie manuell machen.
Ich habe nur keine Lust, alles hoch und runter zu laden - das wäre die Laien-Methode.
Betrachte ich es von der anderen Seite, hab ich auch kein' Bock, mir die Berechtigungen und Dateirechte zu zerschießen und dann meine Nextcloud irgendwie zu retten.

Du kannst das User-Backup nutzen. Dann hast du deine Daten, Verzeichnisse und einen SQL Dump.
Das Userbackup ist nicht an den Usernamen gebunden- meines Wissens nach.

Ob ein internes Kopieren auf dem Server via "mc" reicht, weiss ich nicht und habe es auch nicht getestet.

Ich hatte es schonmal geschrieben, dass die Bindung der PHP-INI Einstellungen an einen User aus meiner Sicht Nachteile nach sich ziehen. Das hier ist so einer. Ist es denn angedacht mittelfristig, besser noch kurzfristig , die PHP-INI Einstelllungen an die jeweilige Sub-Domain zu binden?
Nur so kann man dann innerhalb eines Users überhaupt unterschiedliche PHP Versionen verwenden. Aktuell ist die PHP Umschaltung an die Sub-Domain gebunden. Aber eigene PHP-INI Einstellungen sind dann halt nicht möglich.

Wenn jede Domain eine php.ini besitzen würde, müsste auch für jede Domain eine eigene PHP-FPM-Pool-Datei existieren und das würde die Last des Servers deutlich in die Höhe treiben, je nach Anzahl vorhandener Domains.
Das macht sich auf einem privat genutzten Server noch nicht bemerkbar. Wenn jedoch der Server mit 100ten Kunden mit jeweils mehreren Domain (hierbei zählt die Standard-Subdomain <username>.<keyhelp-domain> auch mit rein) gefüllt ist, sieht das schon anders aus.
Durch die PHP-FPM Einstellungen spawnt der PHP-FPM für jede existierende Pool-Datei je nach Einstellungen Kindprozesse, um PHP-Anwendungen auszuführen, diese müssten dann nicht mehr pro Benutzer sonder pro Domain gespawnt werden.

Quasi Performance vs. Komfort, aufgrund des zu erwartenden Performance-Impact ist es vorerst nicht vorgesehen, dieses Verhalten zu ändern.

Es steht einem aktuell natürlich frei für Domains einen extra User anzulegen, das hat dann auch den Vorteil, wenn ein PHP-FPM Prozess von Domain A lahmgelegt wird, Domain B trotzdem noch funktioniert. Andernfalls - wenn die Domains unter einem User laufen - könnte sich, ein PHP-Fehler auf Domain A ggf. auch auf Domain B auswirken.

Hi Alexander,

danke für deine ausführliche Antwort.

Alexander wrote: ↑Fri 9. Feb 2018, 16:11 Wenn jede Domain eine php.ini besitzen würde, müsste auch für jede Domain eine eigene PHP-FPM-Pool-Datei existieren und das würde die Last des Servers deutlich in die Höhe treiben, je nach Anzahl vorhandener Domains.

Diesen Punkt kann ich jetzt nicht wirklich beurteilen, das liegt in deinem Kompetenzbereich.
Daher möchte ich den Faden mal theoretisch weiterspinnen.

Wäre es denn möglich dass zuerst nachgeschaut wird ob eine domainspezifische PHP-FPM-Pool-Datei Datei existiert und wenn nicht, die userspezifische PHP-FPM-Pool-Datei verwendet wird? Das würde die Anzahl der bereitgestellten PHP-FPM-Pool-Dateien verringern, da diese nur bei Bedarf angelegt werden.

Oder ein anderer Gedanke: Statt userspezifischer PHP-FPM-Pool-Dateien, PHP-Versions-bezogene PHP-FPM-Pool-Dateien. Sprich unabhängig vom User könnte die nötige PHP-FPM-Pool-Datei abhängig von der PHP-Version geladen werden. Das sollte die Anzahl der PHP-FPM-Pool-Dateien drastisch reduzieren. Insbesonders auf Systemen mit mehr Benutzern als PHP-Versionen

. Hilfreich wäre es dann auch wenn man unterschiedliche Konfigurationen für diesselbe PHP Version hinterlegen könnte. So könnte man eine Domain mit minimalen PHP Modulen betreiben (PHP7 MIN-Config), oder alternativ auf eine Konfiguration mit allen PHP Modulen (PHP7 MAX-Config) umschalten.

Ich freue mich auf deine Antwort.

Hi,

also für mich persönlich zumindest ist es so wie es momentan ist absoulut Okay alles andere schadet nur der unnötig der Performance. Es ist ja jezt schonmöglich für eine bestimmte Domain extra User anlegen und diesem extra PHP Funktionen zuweisen. Daher sehe ich hier keinen bedarf an Domain Spezifischen PHP-FPM-Pool-Dateien.

Ja, b0snax, ich teile deine Meinung.
Zudem sehe ich den programmiertechnischen Aufwand, der absolut nicht unerheblich ist. Dad darf man dabei nämlich nicht vergessen.

Es ist mit der aktuellen Zuordnung nicht möglich innerhalb eines Accounts zwei verschiedene PHP Versionen zu benutzen.

Es müssen immer alle Domains auf derselben PHP Version laufen oder man darf keine individuellen PHP Einstellungen verwenden. Ansonsten ist ein Umschalten nicht möglich.

Somit kann man zum Beispiel nicht testen ob sich diese oder jene Software mit einer neueren PHP Version verträgt. Man kann auch nicht einfach die Domain umziehen. S.o.

Ich zum Beispiel verwende für alle Kunden eine CMS Instanz. Ich kann weder eine Kundendomain noch das CMS umstellen. Für mich ich das Feature im aktuellen Zustand schlichtweg nicht nutzbar.

Aber nein.... sobald du mehrere PHP Versionen aktiv hast, kannst du jeder Domain des Users (sogar jeder Subdomain) ihre eigene PHP Version in den Usereinstellungen (als User unter Domaineinstellungen) zuordnen.

...lediglich userspezifische Anpassungen gelten für den User und alle Userdomains.... (meinetwegen max_input_vars = 10000;) ...

nikko wrote: ↑Sat 10. Feb 2018, 22:50 ...lediglich userspezifische Anpassungen gelten für den User und alle Userdomains.... (meinetwegen max_input_vars = 10000;) ...

Und genau darum dreht sich mein Wunsch.

Owncloud möchte zum Beispiel den APCU Cache.
Das geht aber nur in der PHP5 ODER PHP7 Variante.
Sprich ich kann nicht umschalten wenn noch andere Domains mit abweichender PHP Version in dem Account involviert sind.
Und nach einer gewissen Zeit und einer gewissen Anzahl von Domains trifft meines Erachtens nach dieses Problem jeden Account.

KeyHelp Community

Eigene php.ini-Anpassungen für Subdomain

Eigene php.ini-Anpassungen für Subdomain

Re: Eigene php.ini-Anpassungen für Subdomain

Re: Eigene php.ini-Anpassungen für Subdomain

Re: Eigene php.ini-Anpassungen für Subdomain

Re: Eigene php.ini-Anpassungen für Subdomain

Re: Eigene php.ini-Anpassungen für Subdomain

Re: Eigene php.ini-Anpassungen für Subdomain

Re: Eigene php.ini-Anpassungen für Subdomain

Re: Eigene php.ini-Anpassungen für Subdomain

Re: Eigene php.ini-Anpassungen für Subdomain

Re: Eigene php.ini-Anpassungen für Subdomain

Re: Eigene php.ini-Anpassungen für Subdomain

Re: Eigene php.ini-Anpassungen für Subdomain

Re: Eigene php.ini-Anpassungen für Subdomain

Re: Eigene php.ini-Anpassungen für Subdomain