chrisiwien

Folgendes Verhalten: bei der Hauptdomain domain.com kann ich nicht auf die PHP-Dateien zugreifen (502 Bad Gateway) aber auf die statischen Dateien (Texte, Bilder) schon. Bei der Subdomain subdomain.domain.com leitet der Server ins Nirvana. Ohne Versuch gezielt eine Datei aufzurufen kommt ein 403er mit Dateiversuch ein 404er. Und in den Error-Logs ist nach wie vor permission denied zu finden.

ps -u www-data zeigt mir vier Einträge mit nginx.

Im Froxlor-Panel unter Webserver-Einstellungen steht www-data bei Benutzername/Gruppenname.

# /etc/nsswitch.conf # # Example configuration of GNU Name Service Switch functionality. # If you have the `glibc-doc-reference' and `info' packages installed, try: # `info libc "Name Service Switch"' for information about this file. passwd: compat extrausers group: compat extrausers shadow: compat extrausers gshadow: files hosts: files dns networks: files dns protocols: db files services: db files ethers: db files rpc: db files netgroup: nis Datei var/lib/extrausers/group: domain:x:10000:domain,www-data,froxlorlocal domain2:x:10001:domain2,www-data,froxlorlocal domain3:x:10002:domain3,www-data,froxlorlocal Ist das so richtig?

Du, ich hab in dem Moment nur versucht die domain.com in die DocumentRoot einzutragen. Dann Cronjob ausgeführt und noch service nginx restart ausgeführt. An der Konfiguration habe ich nichts geändert...

2020/12/16 22:06:12 [crit] 6725#6725: *3 connect() to unix:/var/lib/nginx/fastcgi/1-domain-domain.com-php-fpm.socket failed (13: Permission denied) while connecting to upstream, client: 80.109.49.138, server: domain.com, request: "GET / HTTP/2.0", upstream: "fastcgi://unix:/var/lib/nginx/fastcgi/1-domain-domain.com-php-fpm.socket:", host: "domain.com" und für eine subdomain.domain.com (da liegt eine Testseite): 2020/12/16 22:06:10 [crit] 6725#6725: *1 stat() "/var/customers/webs/virtualbooth/index.php" failed (13: Permission denied), client: 80.109.49.138, server: virtual-booth.domain.com, request: "GET /favicon.ico HTTP/2.0", host: "virtual-booth.domain.com", referrer: "https://virtual-booth.domain.com/favicon-32x32.png" Der Froxlor-Admin läuft zum Glück. Da ist plötzlich in den vHosts ein Hund drinnen.

Die FPM-Sockets sind alle da. Was tun?

Dadurch hab ich jetzt einen 502 Bad Gateway-Error...😕 Wenn ich domain.com in die DocumentRoot einfüge erscheint bei neuerlichen Aufruf "/domain.com/".

aso

Ok, das ist bereits so. Die documentroot ist für beide Domains /var/customers/webs/domain. D.h. ich brauche den nginx-Redirect gar nicht? Froxlor erstellt automatisch den Redirect von www auf non-www???

Ok, danke für Rückmeldung. Ich habe jetzt den Mastercronjob mit --letsencrypt --force --debug laufen lassen. Es erscheint eine Fehlermeldung "[error] could not find file 'domain.com.cer' in '/root/.acme.sh/domain.com'". Das selbe für die anderen Zertifikatsdateien (key, cer, csr). Im Ordner '/root/.acme.sh/www.domain.com' sind Zertifikatsdateien. Wohlgemerkt, ich leite www.domain.com via dem nginx-Configbefehl 'return 301 https://domain.com$request_uri;' (eingestellt in den vHost-Settings von www.domain.com) auf die non-www-Adresse um. Im Froxlor-Panel wird das Zertifikat sowohl für die www also auch für die non-www-Adresse angezeigt. Im Browser erscheint domain.com mit gültigem Zertifikat. Mach ich mir ev. mit diesem nginx-Redirect einen Murks rein? Muss ich den Redirect von www auf non-www anders lösen?

"zumal du damit jetzt natürlich die Möglichkeit zum debuggen ausgelöscht hast" - echt? Ich hab ja nur die Zertifikatseinträge gelöscht. Ist halt blöd, meine Website rankt für meine Schlüsselwörter in Google recht gut, die will ich nicht ohne Zertifkat stehen lassen weil dann potentielle Kunden die Meckerei im Browser sehen. Ok, kann ich mich so herantasten ob der Cronjob überhaupt automatisch ausgeführt wird? Wie kann ich das prüfen? Über die Server-Logs? Zudem bringt das manuelle Ausführen ja nix, erst das Löschen und Server-Restart... Liegt das ev. an der nginx-Konfiguration? Soll ich diese posten? Auf einem anderen Server den ich betreibe (Apache) steht im Ordner "var/www/froxlor/.well-known/acme-challenge" nur ein Eintrag a la "AdVu25vcdf9-orM5-LIFssjJx4G6JxgjAgzVR6OCzVfIM". Beim nginx-Server bleiben dort immer die alten Zertifkatseinträge stehen. Nachdem ich die lösche und den nginx-Server neu starte gehts.

Lieber d00p! Ich bin unglücklich. Ich habe jetzt die 3 Monate gewartet, heute war das Zertifikat wieder ungültig. Die automatische Erneuerung hat nicht funktioniert. ich habe wieder die Einträge in /root/.acme.sh/ und /var/www/froxlor/.well-known/acme-challenge gelöscht, den froxlor Master-Cronjob laufen lassen und dann den Server mit service nginx restart neu gestartet, jetzt passt es wieder. Wo kann ich weiter nachforschen warum die automatische Aktualisierung nicht hinhaut? Ev. wird der Master-Cronjob nicht richtig ausgeführt? Help! Schöne Grüße aus Wien

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 trotz falschen Pfades ausgestellt - die Tokens der früheren Zertifikate waren auch in /var/www/froxlor/.well-known/acme-challenge zu finden - , die Verlängerung hat halt nicht geklappt. Der Inhalt der acme.conf war trotz falschen Pfades die korrekte Froxlor-acme-Konfiguration in nginx-Notation. Token: ok, das beruhigt mich. Ich muss halt in 3 Monaten schauen ob es geht. Schön wäre es wenn es eine Liste mit Parametern gäbe wie das automatische Update garantiert funktioniert. Aber Server und immer gleichbleibende Parameter...man wird ja wohl noch träumen dürfen! 😉 Danke für die Rückmeldung.

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 --letsencrypt --debug - Kein Erfolg, in Froxlor wurde trotzdem das alte, ungültige Zertifikat angezeigt. Das ungültige Zertifikat in Froxler gelöscht (x-Button). Erneut php /var/www/froxlor/scripts/froxlor_master_cronjob.php --letsencrypt --debug ausgeführt, nun war das neue Zertifikat in Froxlor sichtbar. Trotzdem wurde auf der Website das alte Zertifikat angezeigt. Den alten Apache-Pfad der acme.conf auf /etc/nginx/ gesetzt (Inhalt ist der Standard-Froxlor-nginx-Config-Code) Die Einträge in /root/.acme.sh/ gelöscht und den Cronjob erneut manuell gestartet. Kein Erfolg, nach wie vor das alte Zertifikat auf der Website. Die acme-challenge-Tokens in /var/www/froxlor/.well-known/acme-challenge gelöscht und Cronjob ausgeführt. Kein Erfolg. Den nginx-Server restartet - dann hat es funktioniert, neues Zertifikat ist nun auf der Website sichtbar. Vmtl. habe ich da was durcheinander gebracht. Jetzt ist kein Token mehr im Ordner /var/www/froxlor/.well-known/acme-challenge zu finden - ist das ein Problem? Ich glaube ich hab verstanden, dass NUR beim Einholen des Zertifikates diese Tokens zur Prüfung wichtig sind. Da das Zertifikat ja schon existiert ist der Token momentan nicht wichtig. Wie kann ich diese Tokens wieder generieren? Werden die bei der automatischen Verlängerung neu generiert? Wie kann ich sicher sein dass die automatische Verlängerung läuft? Hast Du einen Tipp für mich? Grüße aus Wien

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-Ordner jetzt manuell mit chown -R auf username:username gesetzt und ... ... es läuft! 😀 Danke Dir für den Zuspruch! Da ja alles mit Froxlor von Haus aus gehen sollte hab ich hier gefragt. War keine schlechte Idee, wieder was gelernt!

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 discarded in Unknown on line 0PHP message: PHP Warning: array_key_exists() expects parameter 2 to be array, null given in /var/customers/webs/username/wp-includes/rest-api/class-wp-rest-request.php on line 412PHP message: PHP Warning: array_key_exists() expects parameter 2 to be array, null given in /var/customers/webs/username/wp-includes/rest-api/class-wp-rest-request.php on line 412', referer: http://username.domain.com/wp-admin/post.php?post=5&action=edit vHost-Datei vom nicht funktionierenden Host: # 35_froxlor_normal_vhost_username.domain.com.conf # Created 09.06.2020 16:28 # Do NOT manually edit this file, all changes will be deleted after the next domain change at the panel. # Domain ID: 16 - CustomerID: 8 - CustomerLogin: username <VirtualHost [Server-IP]:80> ServerName username.domain.com ServerAlias *.username.domain.com ServerAdmin chrisiwien@domain.com DocumentRoot "/var/customers/webs/username/" <FilesMatch \.(php)$> SetHandler proxy:unix:/var/lib/apache2/fastcgi/1-username-username.domain.com-php-fpm.socket|fcgi://localhost </FilesMatch> <Directory "/var/customers/webs/username/"> CGIPassAuth On Require all granted AllowOverride All </Directory> LogLevel warn ErrorLog "/var/customers/logs/username-error.log" CustomLog "/var/customers/logs/username-access.log" combined </VirtualHost> vHost-Datei von einem anderen, mit Temp-Ordner auf 750, funktionierenden Host: # 35_froxlor_normal_vhost_username2.domain.com.conf # Created 09.06.2020 16:28 # Do NOT manually edit this file, all changes will be deleted after the next domain change at the panel. # Domain ID: 3 - CustomerID: 2 - CustomerLogin: username2 <VirtualHost [Server-IP]:80> ServerName username2.domain.com ServerAlias *.username2.domain.com ServerAdmin chrisiwien@domain.com DocumentRoot "/var/customers/webs/username2/" <FilesMatch \.(php)$> SetHandler proxy:unix:/var/lib/apache2/fastcgi/1-username2-username2.domain.com-php-fpm.socket|fcgi://localhost </FilesMatch> <Directory "/var/customers/webs/username2/"> Require all granted AllowOverride All </Directory> Alias /webalizer "/var/customers/webs/username2/webalizer/username2.domain.com" LogLevel warn ErrorLog "/var/customers/logs/username2-username2.domain.com-error.log" CustomLog "/var/customers/logs/username2-username2.domain.com-access.log" combined LogLevel debug </VirtualHost> In der Folge die php-fpm pool-Dateien, einmal vom funktionierenden, einmal vom nicht funktionierenden vHost. Um das ganze ev. abzukürzen, die Unterschiede die mir beim nicht funktionierenden Host aufgefallen sind: php_admin_flag[allow_url_fopen] = Off php_admin_value[open_basedir] = "/var/customers/webs/dcamp:/var/customers/tmp/dcamp:/usr/share/php:/usr/share/php5:/tmp" (open_basdir Wert ist definiert, bei der funktionierenden pool-Konfiguration nicht) php_admin_value[post_max_size] = 16M (im Vergleich 256M bei der funktionierenden pool-Konfiguration. Mir ist auch aufgefallen, dass NUR bei sehr komplexen Gutenberg-Posts, also mit vielen Blöcken, Änderungen nicht gespeichert werden. Wie selbst die großen Gutenberg-Posts 16M haben sollen ist mir aber ein Rätsel. Sollte ja nur Text sein.) php-fpm pool-Datei, nicht funktionierender Host: ;PHP-FPM configuration for "username.domain.com" created on 2020.06.09 16:28:44 [username.domain.com] listen = /var/lib/apache2/fastcgi/1-username-username.domain.com-php-fpm.socket listen.owner = username listen.group = username listen.mode = 0660 user = username group = username pm = dynamic pm.max_children = 5 pm.start_servers = 2 pm.min_spare_servers = 1 pm.max_spare_servers = 3 pm.max_requests = 0 ;chroot = /var/customers/webs/username/ security.limit_extensions = .php env[PATH] = /usr/local/bin:/usr/bin:/bin env[TMP] = /var/customers/tmp/username/ env[TMPDIR] = /var/customers/tmp/username/ env[TEMP] = /var/customers/tmp/username/ php_admin_value[session.save_path] = /var/customers/tmp/username/ php_admin_value[upload_tmp_dir] = /var/customers/tmp/username/ php_admin_flag[allow_call_time_pass_reference] = Off php_admin_flag[allow_url_fopen] = Off php_flag[asp_tags] = Off php_admin_value[disable_classes] = php_admin_value[disable_functions] = curl_multi_exec,exec,parse_ini_file,passthru,popen,proc_close,proc_get_status,proc_nice,proc_open,proc_terminate,show_source,system php_flag[display_errors] = On php_flag[display_startup_errors] = Off php_admin_flag[enable_dl] = Off php_value[error_reporting] = E_ALL & ~E_NOTICE php_admin_flag[expose_php] = Off php_admin_flag[file_uploads] = On php_admin_flag[cgi.force_redirect] = 1 php_admin_value[gpc_order] = "GPC" php_flag[html_errors] = Off php_admin_flag[ignore_repeated_errors] = Off php_admin_flag[ignore_repeated_source] = Off php_value[include_path] = ".:/usr/share/php/:/usr/share/php5/" php_flag[log_errors] = On php_admin_flag[log_errors] = On php_value[log_errors_max_len] = 1024 php_flag[magic_quotes_gpc] = Off php_flag[magic_quotes_runtime] = Off php_flag[magic_quotes_sybase] = Off php_value[max_execution_time] = 300 php_admin_value[max_input_time] = 1000 php_admin_value[memory_limit] = 256M php_admin_value[open_basedir] = "/var/customers/webs/username:/var/customers/tmp/username:/usr/share/php:/usr/share/php5:/tmp" php_admin_value[output_buffering] = 4096 php_admin_value[post_max_size] = 16M php_admin_value[precision] = 14 php_admin_flag[register_argc_argv] = Off php_admin_flag[report_memleaks] = On php_admin_value[sendmail_path] = "/usr/sbin/sendmail -t -i -f chrisiwien@domain.com" php_value[session.auto_start] = 0 php_value[session.cookie_domain] = php_value[session.cookie_lifetime] = 0 php_value[session.cookie_path] = / php_admin_value[session.gc_divisor] = 1000 php_admin_value[session.gc_probability] = 1 php_value[session.name] = PHPSESSID php_value[session.serialize_handler] = php php_flag[session.use_cookies] = 1 php_flag[short_open_tag] = On php_flag[suhosin.simulation] = Off php_flag[track_errors] = Off php_value[upload_max_filesize] = 32M php_admin_value[variables_order] = "GPCS" php_admin_value[opcache.restrict_api] = "/var/customers/webs/username/" php-fpm pool-Datei, funktionierender Host: ;PHP-FPM configuration for "username2.domain.com" created on 2020.06.09 16:28:44 [username2.domain.com] listen = /var/lib/apache2/fastcgi/1-username2-username2.domain.com-php-fpm.socket listen.owner = username2 listen.group = username2 listen.mode = 0660 user = username2 group = username2 pm = dynamic pm.max_children = 5 pm.start_servers = 2 pm.min_spare_servers = 1 pm.max_spare_servers = 3 pm.max_requests = 0 ;chroot = /var/customers/webs/username2/ security.limit_extensions = .php env[PATH] = /usr/local/bin:/usr/bin:/bin env[TMP] = /var/customers/tmp/username2/ env[TMPDIR] = /var/customers/tmp/username2/ env[TEMP] = /var/customers/tmp/username2/ php_admin_value[session.save_path] = /var/customers/tmp/username2/ php_admin_value[upload_tmp_dir] = /var/customers/tmp/username2/ php_admin_flag[allow_call_time_pass_reference] = Off php_admin_flag[allow_url_fopen] = On php_flag[asp_tags] = Off php_admin_value[disable_classes] = php_admin_value[disable_functions] = curl_multi_exec,exec,parse_ini_file,passthru,popen,proc_close,proc_get_status,proc_nice,proc_open,proc_terminate,shell_exec,show_source,system php_flag[display_errors] = Off php_flag[display_startup_errors] = Off php_admin_flag[enable_dl] = Off php_value[error_reporting] = E_ALL & ~E_NOTICE php_admin_flag[expose_php] = Off php_admin_flag[file_uploads] = On php_admin_flag[cgi.force_redirect] = 1 php_admin_value[gpc_order] = "GPC" php_flag[html_errors] = Off php_admin_flag[ignore_repeated_errors] = Off php_admin_flag[ignore_repeated_source] = Off php_value[include_path] = ".:/usr/share/php/:/usr/share/php5/" php_flag[log_errors] = On php_admin_flag[log_errors] = On php_value[log_errors_max_len] = 1024 php_flag[magic_quotes_gpc] = Off php_flag[magic_quotes_runtime] = Off php_flag[magic_quotes_sybase] = Off php_value[max_execution_time] = 60 php_admin_value[max_input_time] = 60 php_admin_value[memory_limit] = 256M php_admin_value[output_buffering] = 4096 php_admin_value[post_max_size] = 256M php_admin_value[precision] = 14 php_admin_flag[register_argc_argv] = Off php_admin_flag[report_memleaks] = On php_admin_value[sendmail_path] = "/usr/sbin/sendmail -t -i -f chrisiwien@domain.com" php_value[session.auto_start] = 0 php_value[session.cookie_domain] = php_value[session.cookie_lifetime] = 0 php_value[session.cookie_path] = / php_admin_value[session.gc_divisor] = 1000 php_admin_value[session.gc_probability] = 1 php_value[session.name] = PHPSESSID php_value[session.serialize_handler] = php php_flag[session.use_cookies] = 1 php_flag[short_open_tag] = On php_flag[suhosin.simulation] = Off php_flag[track_errors] = Off php_value[upload_max_filesize] = 256M php_admin_value[variables_order] = "GPCS" php_admin_value[opcache.restrict_api] = ""

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 Abfolge angelegt: Kunde/Benutzername einrichten Datenbank einrichten Domain einrichten und dem Benutzer zuweisen Beim letzten Mal habe ich unter Zeitdruck die Schritte vertauscht, und nach Nicht-Funktionieren den Kunden und die Domain wieder gelöscht und nochmals angelegt. Scheint so dass sich Froxlor "verschluckt" hat... Woran kann das liegen dass der System-Temp Ordner nur mehr mit chmod 777 funktioniert? Wie kann ich das ändern? Die vHost-Settings und die php-fpm pool Konfiguration entsprechen den anderen Installationen. Der System-Temp Ordner ist für die Funktionalität von WordPress entscheidend, z.B. Mediaupload, Speichern von Gutenberg-Posts... Froxlor-Version ist 0.10.15-1 (DB: 202002290) Grüße aus Wien

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...