chrisiwien

Ah ok, mach ich gleich mal.

Tja, das ist der Einstellungsdschungel in dem ich nicht ganz durchblicke... Mein Ziel ist es ja dass die automatische Zertifikatserneuerung funktioniert. Ok, ich versuch es zu erklären: Ich habe die www und die non-www-Domain in Froxlor eingerichtet. Das Ziel war aber IMMER dass die www-Domain zur non-www-Domain umgeleitet wird. Ich dachte mir es ist richtig wenn ich auch die www-Domain mit einem Zertifikat absichere, obwohl die auf die non-www-Domain weiterleitet. Ist das richtig? Oder bräuchte die www-Domain gar kein Zertifikat, da die eh auf die non-www-Domain MIT Zertifikat umleitet? Bei der non-www-Domain habe ich "Keine Aliasdomain" und "Keine Subdomain einer Hauptdomain" ausgewählt. (keinen www-Alias eingestellt) Bei der www-Domain habe ich "Keine Aliasdomain" und ("ist eine Subdomain von") "domain.com" ausgewählt. (dort ist der www-Alias also eingestellt) Nochmals die Frage zum FDQN: ist es überhaupt zulässig dass ich ein Zertifikat für "www.domain.com" erstelle UND eines für "domain.com"? Der FDQN ist ja bis auf das "www" gleich. Oder sehe ich das falsch? Fakt ist: ich habe auf dem Server wo die automatische Zertifikatserneuerung klappt nur die non-www-Domain mit einem www-Alias eingerichtet. Nach meinem Verständnis entspricht der www-Alias einem Redirect zur non-www-Domain. Ist das korrekt? Dann bräuchte ich ja keinen htaccess redirect von www auf non-www. Auf dem Server wo die Zertifikatserneuerung funktioniert leite ich in der htaccess nur von http auf https um. Bräuchte ich aber auch nicht, da ich in Froxlor ja die SSL-Weiterleitung in der SSL-Rubrik einstellen kann....help! Ich kenn mich nicht immer aus was welche Einstellung tut... und kratzen kann man sich ja bekanntlich auch von links oder von rechts.

Hallo d00p! Mir lässt das keine Ruh. Ich habe was entdeckt: die fragliche Domain auf dem nginx-Server hab ich doppelt eingerichtet: einmal als non-www-Variante, einmal als www-Variante. Die www-Domain leite ich auf die non-www-Domain um. Bei der www-Domain habe ich auch SSL aktiviert, auch bei der non-www-Variante. Ich blick das nicht ganz durch aber mein Hausverstand flüstert mir leise zu dass ich einen Blödsinn gemacht habe. Ein Zertifikat muss ja einen FDQN haben, www.domain.com und domain.com - der Name ist ja eigentlich gleich oder? Also daher könnte der Murks mit der nicht automatischen Zertifkatsverlängerung herrühren, hm. Was meinst Du? Hab auch grad auf meinen anderen Server geschaut, da hab ich nur die non-www-Domain angelegt und eine www-Alias dazu - das ist vmtl. die korrekte Lösung.

Klar. Bis zum nächsten Problem. Salut

A Fünfziger ist unterwegs. Wiegt zwar nicht auf, dass ein Servermensch rund um die Uhr da ist, aber immerhin. Geht sich fast a Stange Zigaretten drum aus!

Wegen dem Zertifikatsproblem: ich greif das jetzt nicht mehr an, erst wieder in 3 Monaten. Hab keine Zeit dafür nochmal ein paar Stunden mich mit Serverfehlern herum zu quälen, habe mom andere Prioritäten.

Is ok. Du sag, ich würde mich sehr gern mal erkenntlich zeigen. Du bist praktisch 24/7 da und gibst Hilfestellung. Bist Du gar ein Bot?? 😀 Na im Ernst ich find das einfach super. Gibts ein Spendenkonto oder so?

Hm, "Eigene Logdatei" und "Zugriffs Logdatei" ist doch das selbe...ah, das heisst die eigene Log-Datei könnte ein User einsehen wenn er sich in Froxlor anmeldet, die Zugriffs-Logdatei am Server nicht, oder?

Wie kann sowas vorkommen? Zeit für einen Server-Reboot?

Dafür heißen meine Logs ab und zu domain-domain.com-access.log und domain-domain.com-error.log anstat domain-access.log und domain-error.log...

d00p ich zweifle an meinem Verstand. Habe mehrmals nginx und php7.3-fpm gestartet und jetzt geht wieder alles. Keine Ahnung warum.

In den error-Logs der subdomain steht auf bei Aufruf dieser Datei permission denied. In den Error-Logs wird auch immer eine Datei "0f77fa1d3f85a43126aa55a99269a3ec.htm" aufgerufen. Seltsam. Die korrekte document-root ist für die subdomain eingestellt.

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