chrisiwien

Durcheinander: sorry, aber ich dachte wenn ich alle Schritte ins Posting schreibe ist es klarer...ich weiß, so sieht es nicht aus. Ich war der Meinung dass die Ausführung des froxlor Master-Cronjobs auch den Webserver neu startet. Zumindest meine ich dass ich bei anderen Änderungen der Konfiguration den Cronjob manuell ausgeführt habe und es hat gepasst. Ich habe den Cronjob mehrere Male ausgeführt, erst "service ngnix restart" hat dann was gebracht. Pfad zu acme.conf: Ok, d.h. wenn der Pfad falsch ist bindet nginx die Datei nicht richtig ein, korrekt? Die früheren Zertifikate wurden

Hallo d00p! Vor ein paar Monaten habe ich meinen Server auf nginx umgestellt, nur klappt schon zum zweiten Mal die automatische Let's Encrypt-Verlängerung nicht (für den einzigen SSL-vhHost am Server). Den Ordner /etc/apache2/ habe ich auf dem Server belassen. Ich habe es mittlerweile hinbekommen dass ein neues Zertifikat für diesen SSL-vHost aktiv ist, aber ich frage mich ob ich in drei Monaten nicht wieder vor dem selben Problem stehe... Folgende Schritte habe ich manuell unternommen (in der Reihenfolge): php /var/www/froxlor/scripts/froxlor_master_cronjob.php --l

Ha, das weiß ich garantiert dass das username:username ist... da ich keine stabile FTP-Verbindung mit proFTP zusammenbekomme gehe ich immer über SFTP mit root rein und chmode dann den gesamten Ordner in der Shell händisch auf den username... *rotwerd* - was soll ich tun, wieder zig Stunden in das Thema FTP investieren...uff... Gack: Hab folgendes entdeckt: der Temp-Ordner (var/customers/tmp/username) hat die User/Gruppenzuweisung (in WinSCP angezeigt) 10006 [10006], währenddessen die anderen - funktionierenden - haben username2 [10006]. Wird auch mit ls -l so angezeigt. Hab den Temp-

Hab im Zuge des Problems auch entdeckt, dass ich nach einem apt-update den Server nicht rebootet habe...hehe...äh...zuerst kam ich mit unsername.domain.com überhaupt nicht in das Verzeichnis...403 und dann 503, nachdem ich die Verzeichnisberechtigungen geändert habe. Nach dem Reboot hat es dann funktioniert - bis auf die Berechtigungen vom Temp-Ordner halt...

Habs versucht mit open_basedir wegnehmen. Auch die php-Konfig vom funktionierenden Host genommen, auch alle von mir gedachten problematischen Werte sind wie vom funktionierenden Host. Nope. Geht nicht. Ich bin mir da nicht ganz sicher, aber: wenn ich einen Kunden lösche, verschwinden nicht die Ordner im Verzeichnis "customers", richtig? Die müsste ich manuell entfernen. Kann es sein - da ich den Kunden gelöscht und wieder unter dem gleichen Username angelegt habe - dass die noch existierenden Ordner da eine korrekte Verbindung verhindern?

open_basedir: Ok, ich versuch das mal.

Noch etwas: ich fliege immer auch nach kurzer Zeit aus Froxlor raus und muss mich neu anmelden. Könnte sein, dass im Zuge dessen einige Werte nicht korrekt in die Froxlor-Datenbank geschrieben wurden. Gibt es in Bezug auf mein Problem irgendeinen Wert den ich in der Froxlor-Datenbank überprüfen könnte?

Hallo d00p! Danke für die wie immer prompte Antwort! 770 hat leider auch nicht geholfen. Ich habe die Berechtigungen wieder auf 750 gesetzt, im Error-Log username-error.log - als WordPress greift unter dem angelegten Kunden-Username zu (scheint so) - steht folgendes: proxy_fcgi:error] [pid 28270:tid 140380049725184] [client xxx.xxx.xxx.xxx:61211] AH01071: Got error 'PHP message: PHP Warning: Unknown: Unable to create temporary file, Check permissions in temporary files directory. in Unknown on line 0PHP message: PHP Warning: Unknown: POST data can't be buffered; all data disca

Hallo! Meine Server/Froxlor-Installation unter Debian 9 mit Apache 2.4 und PHP-FPM 7.3 läuft grundsätzlich sehr gut, wenn ich einen neuen Kunden einrichte, dazu eine Domain und eine Datenbank klappt bisher alles prima. Ich stehe nun bei einer neuen WordPress-Installation vor dem Problem, dass der System-Temp Ordner (var/customers/tmp/username) nur mit chmod 777 funktioniert, das ist natürlich suboptimal... bei den anderen funktionierenden Installationen hat der jeweilige Temp-Ordner die Berechtigung 750 und alles klappt. Bisher habe ich eine neue Website strikt nach dieser Abfol

Ok! Danke für Deine Antworten! Super Hilfestellung! Zusatz: nach enablen der php7.3-fpm.conf rennen die beiden Webseiten gefühlt schneller? (Noch vor der FPM-Werteumstellung) Hat ev. doch einen Einfluss?? Die Gaudi fängt erst an, da ich auf nginx umstellen werden. Keine Panik, habe ich gestern bei einem anderen RootServer gemacht. Und ich liebe nginx bisher - die strukturierten Config-Dateien haben im Vergleich zu Apache auf alle Fälle die Nase vorn!

Ah ok, danke für die Einstellungen. Werde das umstellen und weiter beobachten. I Kipfl hab übrigens die php7.3-fpm.conf nicht enabled (a2enconf). 😁

Was? 7.3 war gestern doch noch neu! 😀 Hast Du eine Idee mit der Fehlermeldung? Übrigens danke für die rasche Rückmeldung. Ich weiß schon, das Thema ist etwas offtopic-froxlor, allerdings muss ich Verbesserungen wenn dann genau dort vornehmen...

Ok. Ich hab mich mal danach gerichtet: https://haydenjames.io/php-fpm-tuning-using-pm-static-max-performance/ Eine Idee welche Werte ich nehmen soll? Du hast recht mit dem spawnen....wenn ich die Anzahl der php7.3-fpm Prozesse ansehe wird mir schlecht....

Liebe Leute! Meine Installation: Debian 9 mit Apache/mpm_event und php7.3-fpm. Auf dem Server laufen gerade zwei Wordpress-Seiten produktiv. Aus für mich nicht ersichtlichen Gründen liefert der Aufruf der Webseiten von Zeit zu Zeit einen 503 Service Unavailable Error. Im dazu passenden vHost-error-log steht: [Tue Feb 04 13:52:52.651498 2020] [proxy:error] [pid 2510:tid 139659873113856] (13)Permission denied: AH02454: FCGI: attempt to connect to Unix domain socket /var/lib/apache2/fastcgi/1-vHost-Name-php-fpm.socket (*) failed [Tue Feb 04 13:52:52.651552 2020] [proxy_fcgi:error] [

I've struggled with this issue myself now for a couple of days. My goal was to activate Apache + mpm_event + php7.3-fpm. For now, i playing around with a WordPress installation and it runs fast as hell (considering WordPress with OPCache and RedisCache-Server, without any WordPress caching plugin). TTFB is around 170ms, I am satisfied. Finally I solved it ? (thankfully without fiddling in conf-Files) by disabling the Apache-conf for php7.3-fpm (in my case php7.3): a2disconf php7.3-fpm (removes /etc/apache2/conf-enabled/php7.3-fpm.conf) I searched for the string "php7.3