Jump to content
Froxlor Forum

df8oe

Members
  • Content Count

    81
  • Joined

  • Last visited

Community Reputation

0 Neutral

About df8oe

  • Rank
    Advanced Froxie

Recent Profile Visitors

1096 profile views
  1. Solange ich Debian hatte habe ich die fertigen .deb-Pakete genommen - das war für mich "das Release". Seit ich Arch habe nehme ich git - weil es sowieso auf dem Server läuft und ständig aktuell ist. Der Rest von Arch ist ja auch "bleeding edge" - da warte ich nicht auf die Releases.
  2. Wir reden einfach eine andere Sprache. Ich will niemanden ärgern Und Froxlor ist echt Klasse. Dann ändere ich es bei mir nicht sondern mache einfach ein rebase. EDIT: Ich nutze ja sowieso die Dateien von Github und nicht die eines Releases - weil ich meine Server mit Arch betreibe. DF8OE
  3. Fazit: Wenn bei jemandem dieses Problem auftritt kann man sich mit einem Workaround helfen. Vermutlich sind bei denen, die das Problem haben, im IP/PORT-SSL-Vhost die beiden Pfade "Pfad zum Zertifikat" und "Pfad zum SSL-Private-Key" nicht leer, sondern haben eine Pfad/Dateikombination, die auf dem Server nicht existiert. Löscht einfach die dort vorhandenen Einträge und lasst die Felder leer. Dann erkennt Froxlor beim Neuanlegen einer Domain mit den Defaulteinstellungen ("aktiviere SSL" gesetzt, "Letsencrypt" nicht gesetzt) dass es kein gültiges Zertifikat gibt und erstellt einen leeren S
  4. Nein, hat er nicht. Und Flames sind auch unnütze Zeitverschwendung - genauso wie Diskussionen. Ich werde mich nachher drum kümmern und hier entweder die Lösung in Form geänderter Einstellungen oder in Form eines Patches veröffentlichen. Vielleicht macht das dann das Problem transparenter. Das Ziel ist die Behebung einer Fehlfunktion, die für weniger versierte Nutzer zu einem Problem führen kann, das sie nicht ohne weiteres wieder beheben können.
  5. Ich denke ich verschwende meine Zeit nicht Logs zu verändern oder hier das Fehlverhalten zu posten, sondern den Fehler selbst zu fixen und in mein Froxlor-Github einzufügen. Es existiert auch ein Pull-Request für meine Implementierung von DKIM, der aber schwebt, weil der Part für die Erstellung der DKIM-Serverkonfigurationen fehlt (und ich keine Zeit habe ihn zu erstellen). Aktuell gibt es aber noch keine Merge-Konflikte Alles, was zum Verstehen der Fehlfunktion nötig ist, steht hier bereits. Und dass eine IP/Port-Kombination für den Vhost von Froxlor verwendet wird kann ich weder nachvo
  6. Froxlor läuft nicht über IP (weil ich kein teures IP-Zertifikat habe), sondern auf einer Subdomain. Und die hat ein Letsencrypt-Zertifikat. Das manuelle Anonymisieren frisst jede Menge zeit (ich schrieb es bereits). Ich kann also die IP/Port-Kombination für SSL nicht löschen, wenn irgend eine Domain via SSL läuft. So gut wie niemand dürfte ein IP-Zertifikat haben. Wie lange es sowas überhaupt noch gibt ist auch fraglich. Aber es werden sehr viele Leute auch ohne existentes IP-Zertifikat Domains mit SSL genutzt werden. Man *MUSS* also eine IP/Port-Kombination für SSL anlegen - au
  7. Die ganzen Einstellungen kann ich nicht unverändert posten weil da Kundendaten drin sind (DSGVO). Und die ganzen Stellen unkenntlich zu machen ist eine Heidenarbeit. Aber wir nähern uns. Es ist auf allen drei Servern auch eine IP/Port-Kombination für Port 443 in Froxlor eingetragen - aber es soll kein Vhost dafür erstellt werden. Dementsprechend stört es auch nicht, dass die dort eingetragene Pfad/Zertifikat-Kombination nicht existiert. Alle drei Server laufen seit Äonen - bis Mai mit Debian, seit Mai mit Arch Linux. Das Problem, dass ssl-Vhosts erstellt werden ohne existente Zertifikate ist e
  8. Bei Arch Linux gibt es keine Ordner oder Dateien die mit"apache*" benannt sind. Die haben alle ein "http*" im Namen - ganz sicher. Es gibt weder einen Unterordner "apache" noch irgendwo Zertifikatsdateien die mit "apache" benannt sind.
  9. Hier die beiden relevanten Zeilen aus der erstellten ssl-Vhost-conf: SSLCertificateFile /etc/ssl/apache/apache.crt SSLCertificateKeyFile /etc/ssl/apache/apache.key Ich habe es vermieden die gesamte conf zu posten da das Unkenntlichmachen der 30 für dieses Problem absolut irrelevanten Stellen sinnlos Arbeit erzeugt. Der Knackpunkt wurde klar beschrieben: Es ist default "SSL aktivieren" ausgewählt. Es gibt kein systemweites oder IP-basiertes Zertifikat. Letsencrypt ist nicht angehakt. Dann erstellt Froxlor einen ssl-Vhost mit den oben aufgeführten Zeilen und startet den Webser
  10. Leider wird der Vhost bei drei unterschiedlichen Server nicht deaktiviert. Es wird ein Vhost angelegt dessen Zertifikat in /etc/ssl/apache/apache.crt / /etc/ssl/apache/apache.key liegen soll. Da liegt aber keines (es gibt noch nicht mal den Ordner /etc/ssl/apache) und das wars dann mit dem Webserver...
  11. Das Neuanlegen einer Domain führt jetzt oft dazu, dass der Webserver nicht mehr startet. Wie kommt das zu Stande? Beim Neuanlegen einer Domain wird, wenn in den Webserver-Grundeinstellungen SSL enabled ist, in der Sektion "Webserver SSL-Einstellungen" bei "Aktiviere Nutzung von SSL:" generell ein Haken gesetzt. Bei "SSL Zertifikat erstellen (Let's Encrypt):" ist dagegen kein Haken gesetzt. Das führt dazu, dass beim nächsten Cron-Lauf die Konfiguration so geschrieben wird, dass von einem lokal vorhandenen Zertifikat ausgegangen wird. Das ist aber nicht vorhanden - und damit sta
  12. Nein, funktioniert immer noch nicht. Ich habe vor der Entscheidung ein var_dump($renew_domains) eingefügt und dort wird mir nach wie vor die komplette Liste aller Domains incl. der Keys ausgegeben - auch nach dem Patch. Könnte hier dran liegen: private static function renewDomains($check = false) damit ist $check immer false und das Ergebnis immer so wie vorher - oder nicht?
  13. Das Problem entsteht in /var/www/froxlor/lib/Froxlor/Cron/Http/LetsEncrypt/AcmeSh.php und zwar durch diese Zuweisung in Zeile 65: $renew_domains = self::renewDomains(); Da kommt hier true raus und deswegen sollen die Configs neu geschrieben werden. Wenn ich $renew_domains eine Zeile danach auf false setze wird kein false-renew der Config mehr gemacht. EDIT: Da kommt nicht true raus - da werden alle Domains mit letsencrypt als Array zurückgegeben. Und damit ist die nachfolgende Bedingung immer erfüllt - es sei denn, man hat keine Domains mit letsencrypt.
  14. Einen ssh-Zugang kann ich Dir aus DSGVO-Gründen bei keinem der Server geben. Aber ich kann forschen - auch ohne weitere Tipps. Vielleicht fällt Dir als der "Schöpfer von Froxlor" mit dem entsprechenden Überblick ja mit irgendeinem meiner Hinweise was ein. starte ich /usr/bin/php -q /var/www/froxlor/scripts/froxlor_master_cronjob.php --tasks aus der Konsole so ist im Admin-Panel immer zu finden, dass keine Cron-Aufgaben anstehen. Warte ich ab bis der Cronjob das tut dann steht nach Lauf des Cronjobs im Admin Panel, dass die Webserverconfig neu geschrieben werden muss.
×
×
  • Create New...