Jump to content
Froxlor Forum

chrisiwien

Members
  • Posts

    65
  • Joined

  • Last visited

  • Days Won

    2

Posts posted by chrisiwien

  1. In meinem Froxlor-Panel werden SSL-Zertifikate von zwei Domains als abgelaufen markiert (hellrot hinterlegt).

    Lt. Cronjob-Einstellungen läuft der Let's encrypt-Cronjob im Interval von 5 Minuten.

    Auch den Mastercronjob in der Shell ausführen mit "php /var/www/froxlor/scripts/froxlor_master_cronjob.php --letsencrypt --debug" hat nichts gebracht.

    Erst als ich die Zertifikate im Admin-Panel manuell gelöscht habe und dann den Mastercronjob in der Shell ausgeführt habe hat es gepasst.

    Was ist falsch? Server ist nginx.

  2. Hör zu, Du sagst es ist wurscht. Ich hab aber nichts verstellt und laboriere schon Monate mit diesem Problem rum und habe bisher keine Lösung gesehen.

    Fakt ist dass der Webserver mit dem falschen Befehl nicht neu startet!

    Also is es nicht wurscht was Du als default definiert hast weil ich das dann nachprüfen kann!

    Was ist jetzt der default-Wert? Und warum werden die Optionen bei nginx-Befehlen nicht akzeptiert?

    • Downvote 1
  3. Hallo zusammen,

    weitere Entwicklungen: im Froxlor-Panel ist unter Webserver-Einstellungen der Befehl eingetragen:

    /etc/init.d/nginx -s reload

    Hab versucht den mal in der Shell auszuführen - klappt nicht. Dann kommt eine Meldung wie bei einer unbekannten Kommandozeilenoption:

    Usage: nginx {start|stop|restart|reload|force-reload|status|configtest|rotate|upgrade}

    D.h. der Befehl /etc/init.d/nginx -s reload wird nie ausgeführt. Die Optionen (-s, -v, etc.) sind aus irgendeinem Grund auf meinem System nicht ausführbar. Muss man die Verwendung von Optionen bei nginx in den Config-Dateien explizit angeben?

    Auf alle Fälle ohne Kommandozeilen-Optionen funktioniert der Befehl (ich hab gleich restart statt reload genommen):

    /etc/init.d/nginx restart

     

     

  4. Das kommt dabei raus, nach php /var/www/Froxlor/scripts/froxlor_master_cronjob.php --letsdebug --debug:

    [Wed Jan 12 17:56:17 CET 2022] Already uptodate!
    [Wed Jan 12 17:56:17 CET 2022] Upgrade success!
    [Wed Jan 12 17:56:18 CET 2022] Installing cron job
    25 0 * * * "/root/.acme.sh"/acme.sh --cron --home "/root/.acme.sh" > /dev/null
    [information] No new certificates or certificate updates found
    [notice] Checking system's last guid

    Keine Warnungen, keine Fehler.
     

  5. vor 11 Minuten schrieb みゆき:

    Das was du im Panel eingestellt hast, es spielt aber keine Rolle ob Reload oder Restart.
    Poste mal die logs von der acme, alle Certs laufen über diese Datei, Froxlor startet nur den Prozess mehr und weniger nicht.

    Bist Du sicher? Lt. kurzer Recherche heisst es:

    Zitat

    restart shuts the service down and then starts it up again, whereas reload instructs the daemon to reload its configuration

    Könnte doch einen Unterschied machen bezogen auf nginx vs Apache, oder?

  6. Kann ich nicht sagen...mir bleibt pro 3 Monate immer nur ein Versuch um alles herauszufinden... kann ja im April darauf achten...😄

    Der Froxlor-vHost hat jedenfalls jetzt auch ein Zertifikat mit dem selben Erneuerungszeitraum wie die Kundendomain.

    Wie gesagt tritt das Problem bei meinem nginx-Server auf. Ich habe auch noch einen Apache-Server mit froxlor laufen, da tritt das Problem nicht auf.

    Ein nginx-bezogenes Problem? Verwendest Du beim cronjob auch "service nginx restart" oder reload zum Schluss?

  7. So, wieder mehrmals gewartet, am 10.1.2022 wieder das selbe Problem: das Zertifikat für die Website wird im Browser als ungültig dargestellt.

    Ich habe jetzt nur den nginx-Server mit "service nginx restart" neu gestartet und das Problem war sofort behoben.

    Daraus schließe ich:

    • Dass der Froxlor cronjob mit der letsencrypt-Erneuerung ausgeführt wird - da ja nach Server-Neustart das neue Zertifikat sofort aktiv ist.
    • Dass der froxlor-cronjob /var/www/froxlor/scripts/froxlor_master_cronjob.php den Server nicht richtig neu startet.

    Was kann ich tun um das Problem zu beheben?

  8. Evil: ok, kann ich mir vorstellen. Da ich das "nebenberuflich" mache bin ich mal zufrieden und lese mich später ein.

    Zweiter vHost, ich weiß, aber da hatten wir mal eine Diskussion (https://forum.froxlor.org/index.php?/topic/19573-automatische-verlängerung-von-lets-encrypt-zertifikat/page/3/#comment-43204) bzgl. nicht funktionierendem automatischen Lets Encrypt-Update. Jetzt klappt das, das will ich momentan nimma angreifen.

    Danke jedenfalls für die Rückmeldung.

  9. Sicher krieg ist das raus, hab auch schon zig Einträge selbst gemacht. Aber das ist wieder eine neuer Fall, neue Einstellungen. Hör mir zudem lieber zuerst an was Froxlor dazu sagt bevor ich was selber schnitz!

    Danke für die Kommunikation, ich versuch das mal. Das muss man mal behirnen, dass durch den gesetzen www-Alias der non-www-vHost aufgerufen wird - und dass ich dann dort die www-domain nochmals verarbeiten kann.

  10. Hm, ev. blicke ich nicht ganz durch... die Header kann ich schon einstellen, Problem ist aber ich kann aber beim "Access-Control-Allow-Origin"-Header nur eine Domain einstellen!

    Umgehen könnte ich das wenn ich eine Weiterleitung von www.domain.com auf domain.com OHNE zusätzlichen www-vHost schaffen kann, mit Froxlor. Das wird aber nicht gehen, oder?

    Wenn ich das script https://domain.com/script.php aufrufe ABER die Seite über https://www.domain.com betrachte schießt mir die CORS-policy den Aufruf ab.

    Hm.

  11. Das hilft mir jetzt nicht weiter. Auf https://developer.mozilla.org/de/docs/Web/HTTP/CORS/Errors/CORSMissingAllowOrigin ist zu lesen dass man auch eine "origin-list" angeben kann:

    Zitat

    Private APIs sollten niemals "*" verwenden, sondern stattdessen eine spezifische Domain oder eine Liste von Domains. 

    Die Referenzseite wurde erst vor kurzem bearbeitet, die Infos scheinen aktuell zu sein. Bloß wo definiert man diese "origin-list"? Wenn man einfach mit Leerzeichen separiert oder mehrere add_header-Anweisungen untereinander einfügt heißt es es darf nur ein Origin definiert werden...

  12. Hallo d00p!

    Ich möchte den Content-Security-Header "Access-Control-Allow-Origin" mit mehreren Domains setzen. Das geht aber offenbar gar nicht - oder doch? Die Developer-Konsole im Browser sagt "multiple domains not allowed" wenn ich diesen Eintrag einfüge:

    add_header Access-Control-Allow-Origin "https://domain.com https://www.domain.com";

    Das Blöde ist, dass Skriptaufrufe mit domain.com hardcoded sind, d.h. bei www-Domain Aufruf werden diese von der Content-Security-Policy gekillt.

    DIE Lösung wäre es wenn ich eine direkte Weiterleitung von www.domain.com auf domain.com setzen könnte. Dazu müsste ich einen zusätzlichen www-vHost anlegen (momentan läuft nur ein vHost mit www-Alias). Allerdings hatte ich mit dieser Lösung Probleme beim automatischen Update der Lets Encrypt-Zertifikate.

    Hab ich mich soweit verständlich ausgedrückt? 😉

    Hast Du ev. einen Tipp wie ich das Problem mit Froxlor lösen kann? Einerseits ist das Thema "Access-Control-Allow-Origin multiple Domains nginx" etwas off topic - andererseits nicht, da ich das Problem nur mit Froxlor lösen sollte und nicht etwas zu Fuß schnitzen will.

     

    Grüße aus Wien

     

  13. Hallo d00p!

    Ich möchte das froxlor-Backend über ein Lets Encrypt-Zertifikat absichern. Die notwendigen Einstellungen in den "Froxlor Virtual Host Einstellungen" habe ich vorgenommen, Häkchen bei "Lets Encrypt verwenden" und "SSL-Weiterleitung" aktiviert.

    Der Froxlor-Cronjob wirft aber diese Meldungen aus:

    [error] Could not find file '[server-domain].cer' in '/root/.acme.sh/[server-domain]/'
    [error] Could not find file 'ca.cer' in '/root/.acme.sh/[server-domain]/'
    [error] Could not find file 'fullchain.cer' in '/root/.acme.sh/[server-domain]/'
    [error] Could not get Let's Encrypt certificate for [server-domain]:

    Im Ordner root/.acme.sh/[server-domain]/ sind nur diese Dateien zu finden:

    [server-domain].conf
    [server-domain].csr
    [server-domain].csr.conf
    [server-domain].key


    Was mache ich falsch?

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

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

    "auch hier wieder, ssl-redirect heisst: leite http auf https um, NICHT leite www auf non-www" - ja logisch. Was ist meinte ist: wenn ich in den Froxlor-Settings "leite http auf https um" wähle brauche ich das nicht mehr in der htaccess manuell einzustellen.

     

    Wichtig ist nur dass bei Aufruf von www und non-www der selbe Inhalt erscheint (aus der selben document-root). Je mehr redirects man sich sparen kann desto besser!

  16. 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 der da den Hund reinhaut.

×
×
  • Create New...