chrisiwien

Ja eh. Da ich nur gelegentlich mit Server-Arbeit konfrontiert bin habe ich aus unerfindlichen Gründen nicht die Vorgehensweise vom funktionierenden Server übernommen. Blöd. Ich werde versuchen vor dem nächsten Zert-Update das mit den Domains zu ändern. Ich sehe mich aber so gegen Mitte März 2021 wieder auf schrill gebürstet im Forum posten...*seufz* Danke für die Antworten jedenfalls!

Sorry, hab Dein vorletztes Mail mit den vielen Erklärungen übersehen. "Nein, ein Alias bedeutet nur, dass der apache vhost nur 1x generiert wird, in erster linie für domain.tld und dann als alias (ServerAlias direktive) auch für www.domain.tld - das impliziert keinen redirect - der vhost reagiert nur auf beide urls". Der vHost reagiert nur auf beide urls - ja dann - aber dann ist das Ergebnis doch das gleiche wie bei Anlegen einer www-Domain und redirect auf non-www?? So klappt das zumindest auf dem Server wo es keine Zert-Probleme gibt - wo ich auch nur die non-www-Domain angelegt habe

Ich sehe das "hallo". Der Redirect geift also. Aber was mich trotzdem stutzig macht: Der Froxlor-Mastercronjob führt ja die Let's Encrypt-Anfragen aus, also auch für den FDQN "www.domain.com". Let's Encrypt bekommt aber dank der Weiterleitung "domain.com" präsentiert. Das macht einen Unterschied, oder? Im Ordner root/.acme.sh liegen jetzt im Ordner "domain.com" keine Zertifikatsdateien. Im Ordner "www.domain.com" sehr wohl. Beim vorigen Zertifikatslauf waren aber auch im Ordner "domain.com" Zertifikatsdateien. Es ist zum schreien. Aber ich tippe auf den unnötig komplizierten Redirect

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 Ze

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 auto

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.