rseffner

Bei mir liegt der ganze acme.sh Krempel unter /root/.acme.sh. Da sind dann je (Sub-)Domain ein Ordner für die Zertifikate mit einer *.conf in der sich Le_CertCreateTime, Le_CertCreateTimeStr, Le_NextRenewTime und Le_NextRenewTimeStr befinden. Kommentiere ich diese 4 Zeilen aus und starte dann den froxlor_master_cronjob.php läuft die Zertifikatsbeschaffung ohne Fehler durch. Soweit so gut - man könnte jetzt hoffen einen Zertifikatsasynchronität durch einmaliges Ändern der *.conf's zu beheben, weil dann FROXLOR wieder "gewinnt" mit seinem Request und Glauben an den Zertifikatsablauf. Allerdings haut mir der Cronjob die eben erneuterten Zertifikate bei einer weitere Iteration wieder um die Ohren. Warum? Schaue ich in die SQL, sehe ich, dass dort noch immer eine "falsche" Expiration drinsteht. Kann es sein, dass wir hier einen Bug haben und die Daten von acme.sh gerade NICHT in die DB wandern bei renews?

Das acme.sh --upgrade meint gerade aktuell zu sein und kommt so im Code sicher nicht an die Stelle, wo es wohl sonst scheitert. Die Inhalte der Zertifikatsdateien (die Version vor meinem Eingriff) im Filesystem und der FROXLOR-DB (panel_domains.id = domain_ssl_settings.domainid) unterscheiden sich bei der Beispieldomain. Kann ich da jetzt einfach aus dem Dateisystem die Inhalte in die DB kopieren um die Gültigkeit an beiden Orten gleich zu haben? Die Stichprobe mit einer noch nicht in den Tasks zum renew geführten Domain zeigt diese Unterschied zwischen Dateisystem und DB aber auch. Ist das jetzt alles asyncron? Kann man FROXLOR "zwingen" sich nochmal am .acme.sh-Verzeichnis zu bedienen?

Ok, dann habe ich es durch diesen einen händischen acme.sh-Aufruf schlimmer gemacht. Dafür gibt es ja zum Glück Backups. Und dann vergleiche ich mal Dateisystem mit FROXLOR-DB.

Du vermutest also das Update/Upgrade von acme.sh itself? Das hat die Version und Checksumme, wie das gerade auf github.com verfügbare. Also irgendwann und irgendwie schein das Aktuellhalten auch mal zu funktionieren. Bis hierher habe ich den Eindruck, ich könnte die Cron-Meldungen, sofern sie nur vereinzelt auftauchen, einfach ignorieren.

Ich habe mal das acme.sh mit --renew und DOMAIN1.de ausgeführt, das ging problemlos. ns1:~/.acme.sh# ./acme.sh -r -d DOMAIN1.de --force [Di 31. Mär 13:10:37 CEST 2020] Renew: 'DOMAIN13.de' [Di 31. Mär 13:10:37 CEST 2020] Creating domain key [Di 31. Mär 13:10:38 CEST 2020] The domain key is here: /root/.acme.sh/DOMAIN1.de/DOMAIN1.de.key [Di 31. Mär 13:10:38 CEST 2020] Multi domain='DNS:DOMAIN1.de,DNS:www.DOMAIN1.de' [Di 31. Mär 13:10:39 CEST 2020] Getting domain auth token for each domain [Di 31. Mär 13:10:42 CEST 2020] Getting webroot for domain='DOMAIN1.de' [Di 31. Mär 13:10:42 CEST 2020] Getting webroot for domain='www.DOMAIN1.de' [Di 31. Mär 13:10:42 CEST 2020] DOMAIN1.de is already verified, skip http-01. [Di 31. Mär 13:10:42 CEST 2020] www.DOMAIN1.de is already verified, skip http-01. [Di 31. Mär 13:10:42 CEST 2020] Verify finished, start to sign. [Di 31. Mär 13:10:42 CEST 2020] Lets finalize the order, Le_OrderFinalize: https://acme-v02.api.letsencrypt.org/acme/finalize/70743315/284201xxxx [Di 31. Mär 13:10:44 CEST 2020] Download cert, Le_LinkCert: https://acme-v02.api.letsencrypt.org/acme/cert/04cad67ea8430f8aaf05f4b2784axxxxxxxx [Di 31. Mär 13:10:45 CEST 2020] Cert success. -----BEGIN CERTIFICATE----- MIIGdjCCBV6gAwIBAgISBMrWfqhDD4qvBfSyeEpsZ6IsMA0GCSqGSIb3DQEBCwUA ... 51LtN4Khp6c+z6j134QlCagAUF3OrYVVQyE= -----END CERTIFICATE----- [Di 31. Mär 13:10:45 CEST 2020] Your cert is in /root/.acme.sh/DOMAIN1.de/DOMAIN1.de.cer [Di 31. Mär 13:10:45 CEST 2020] Your cert key is in /root/.acme.sh/DOMAIN1.de/DOMAIN1.de.key [Di 31. Mär 13:10:45 CEST 2020] The intermediate CA cert is in /root/.acme.sh/DOMAIN1.de/ca.cer [Di 31. Mär 13:10:45 CEST 2020] And the full chain certs is there: /root/.acme.sh/DOMAIN1.de/fullchain.cer Habe ich jetzt ein Problem nur zu bestimmten Zeiten oder macht FROXLOR das Mithilfe der acme.sh in ganz anderen Verzeichnissen mit ganz anderen Parametern?

Hallo, mit Einführung des begrüßenswerten LE-Supports in FROXLOR schien hier jede dritte Meldung damit zusammenhängen. Eigentlich wollte ich auf den Zug nicht auch noch aufspringen (müssen). Nun komme aber auch ich seit einigen Tagen nicht weiter. cron führt regelmäßig den froxlor_master_cronjob mit dem Parameter --tasks aus und meldet dabei neuerdings ca. 1x am Tag: gzip: stdin: not in gzip format tar: Child returned status 1 tar: Error is not recoverable: exiting now /root/.acme.sh/acme.sh: Zeile 6310: gtar: Kommando nicht gefunden. [Di 31. Mär 02:00:02 CEST 2020] Extraction error. [Di 31. Mär 02:00:02 CEST 2020] Upgrade failed! Schaut man sich die Zeile 6310 in der acme.sh an, wird klar, dass nicht das fehlende "gtar" das Problem ist, sondern offenbar ein korruptes Archiv, welches zuvor mittels "tar" versucht wird zu entpacken. if ! (tar xzf $localname || gtar xzf $localname); then Auch ein manueller Aufruf des Task mit --force bleibt seit Tagen am Renew der gleichen Domains hängen. ns2:~# /usr/bin/php7.3 -q /var/www/webs/its/FROXLOR_DOCROOT/scripts/froxlor_master_cronjob.php --tasks --force [error] Could not get Let's Encrypt certificate for DOMAIN1.de: [Di 31. Mär 12:46:08 CEST 2020] Renew: 'DOMAIN1.de' [Di 31. Mär 12:46:08 CEST 2020] Skip, Next renewal time is: Di 26. Mai 08:20:23 UTC 2020 [Di 31. Mär 12:46:08 CEST 2020] Add '--force' to force to renew. [error] Could not get Let's Encrypt certificate for DOMAIN2.de: [Di 31. Mär 12:46:08 CEST 2020] Renew: 'DOMAIN2.de' [Di 31. Mär 12:46:08 CEST 2020] Skip, Next renewal time is: Do 28. Mai 08:30:24 UTC 2020 [Di 31. Mär 12:46:08 CEST 2020] Add '--force' to force to renew. Wie kann ich das Problem weiter zu seiner Ursache hin verfolgen? Welche Angaben sind für weitere Hilfe nötig? Am Start ist die 0.10.15 auf Debian Buster. Danke fürs Lesen, Draufrumdenken und ggf. unterstützen. Ronny

Hallo, ich bin einer der angeblich Wenigen, die von FROXLOR auch DNS verwalten lassen. Das führte am Wochenende zu einer leider ellenlangen Fehlersuche. Ich möchte anregen in den LE-Task eine zusätzliche Prüfung einzubauen, wobei ich noch nicht gänzlich durchdacht habe, ob das überhaupt realisierbar ist (z.B. Wildcard). Ein Kunde, der Jahr und Tag seine Domain und auch sein DocRoot bei mir auf dem Server hatte, hat auch LE aktivert. Nun ist er ohne mir ein Zeichen zu geben, auf anderen Webspace gewechselt und hat dazu im DNS-Editor für die Subdomain www einen A-record angelegt. Jetzt kam aber LE daher und wollte das Zertifikat erneuern und fand dann aber auf der Webseite das /.well-known/acme-challenge/ nicht. Ich Troll habe mir die Alias-Konfig angeschaut, LE für Die Domain aus und wieder an gemacht, nach .htaccess gesucht, mit anderen Domains verglichen - hat alles zu nix geführt. Wenn ich mal gleich geguckt hätte, wer da zur URL eigentlich Content ausliefert. Unschön an einer solchen Geschichte ist nicht nur der Aufwand sondern auch, das LE tagelang brach lag, weil ich dort wegen Fehlversuchen bereits gesperrt war. Toll wäre aus dieser Erfahrung einen Check abzuleiten, der vor Zertifikatsanforderung bzw. -verlängerung via DNS nachschaut, ob man überhaupt wieder auf der von FROXLOR verwalteten Kiste landet auf der auch die acme-challenge verwaltet wird. Als feature request in den bugtracker?

Dieser punktgenaue, fixe Support gehört bezahlt - zumindest kann man sich da anderswo ein Scheibchen abschneiden. Die Fehlermeldung ist damit weg. Danke.

Hallo, im Bugtracker steht, bei Unsicherheit erst hier fragen ;-) Editiere ich eine Domain (keine Änderung, nur Speichern) als der Admin, mit dem ich einst syscp/froxlor installiert habe, gibt es erwartungsgemäß unter 0.10.12 keine Probleme. Nutze ich dazu allerdings einen Admin, den ich nachträglich angelegt habe (und der auch Kunden/Domains besitzt), passiert folgendes beim Speichern: PHP warning/error #2 implode(): Invalid arguments passed lib/Froxlor/Api/Commands/Domains.php:1572 PHP warning/error #2 implode(): Invalid arguments passed lib/Froxlor/Api/Commands/Domains.php:1638 PHP warning/error #2 Cannot modify header information - headers already sent by (output started at /var/www/webs/XXX/XXX.XXX-XXX.de/lib/Froxlor/PhpHelper.php:138) lib/Froxlor/Api/ApiCommand.php:448 PHP warning/error #2 Cannot modify header information - headers already sent by (output started at /var/www/webs/XXX/XXX.XXX-XXX.de/lib/Froxlor/PhpHelper.php:138) lib/Froxlor/UI/Response.php:55 Ich habe mehrere solcher "Admins", das tritt bei allen auf. Kann das jemand verifizieren und viel besser noch, beheben? Gruß Ronny

Wenn ich ergänzen darf: rspamd.

Klar will man 2 DNS, man will ja auch 2 MX also hat man doch auch gleich zwei FROXLOR. Das gibt Redundanz für DNS und MX und man kann die Kunden aufteilen. Warum so tunlichst DNS von Web trennen? DNS einkaufen nimmt Flexibilität, ich vermute es gibt wenige bis keine Provider wo ich dynamische Updates fahren kann oder die haben ne API in die ich Mantage investieren muss sie zu verstehen und zu implementieren. Die Antwort auf meine Frage ist also weniger eine statistisch belastbare Aussage als vielmehr Deine Meinung (sicherlich basierend auf Deiner Supporterfahrung). Ich schätze den DNS-Support von FROXLOR sehr und würde sehr Bedauern, wenn dieser sich nicht weiter oder viel schlimmer, zurück entwickelt. Irgendwie sollte mal opendkim (oder rspamd's dkim) als Ersatz zu dkim-filter umgesetzt werden und in Sachen DNSSec oder einer der anderen Technologien (over HTTPs?) könnte auch mal was kommen. Ob ich das je git-tauglich bekomme um es hier abzukippen? Seit Jahren komme ich nicht dazu mich mit git zu beschäftigen. Zuletzt habe ich einen IPv6-Anonymisierungspatch für apache2.4 in einem git angepasst - dort bewegt sich nichts (vielleicht weil ich was falsch gemacht habe).

Hallo, ich lese im Kontext DNS immer wieder, dass nur sehr wenige das nutzen würden. Kommt diese Erkenntnis empirisch aus den Supportanfragen hier im Forum oder gibt es da eine andere Basis? Mich z.B. würde die Weiterentwicklung/Anpassung vom DKIM-Support vielleicht bis hin zu DNSSEC interessieren. Dazu möchte ich hinterfragen ob die Annahme der untergeordneten Bedeutung von DNS in FROXLOR auf Vermutung basiert und wir das vielleicht mal mit einer Umfrage belegbar machen können/wollen.

Just my cents: - a TTL of 1 is not conform to RFC's (at SOA's base, maybe allowed for an A record), you insert a task to froxlors cron so it takes just therefore more than 1 second - your solution misses IPv6 support - DNS is a fundamental service an should be high available, your updateip.php isn't But all in all a nice thought an easy, lightweight solution implemented in froxlor. Thanks for sharing this.

Thanks for your work again. 'cron_traffic.php' seems to work now.