froxlorforum@pilsgenuss.de

Prima! Das klappt einwandfrei! Diese Einstellungsmöglichkeit hatte ich nicht auf dem Schirm. Vielen Dank für Deine wie immer superschnelle und zielführende Hilfe! 🙂

Hallo d00p, OK, ich denke, ich verstehe das Problem: Der Froxlor-Server ist ein virtuelles System hinter einer FW in einer DMZ. Die ganzen "Verbindungen" von außen nach innen werden geNATted. Und irgendwann scheint da eine neue Prüfung dazugekommen zu sein, die dann - wie Du sagst - vorab prüft, ob das DNS passt. Das hat früher wie heute nicht in dem Sinne gepasst, aber Let's Encrypt selbst hatte nie Schwierigkeiten. Ist das das Problem? Und wenn ja, wie kann ich das "umschiffen"? Danke!

Moin allerseits, der Eintrag ist noch nicht so alt, daher erlaube ich mir, mich dranzuhängen: @Lonesomewalker: Was kam denn raus dabei? Ich habe aktuell dasselbe Problem wie beschrieben. Ich habe versucht, eine Domain einer anderen PHP-Konfiguration zuzuweisen (ist hier nicht relevant, war nur der Grund, warum ich die Domain neu speichern musste) und nun schimpft Froxlor genau dasselbe: Fehlermeldung Die DNS-Einträge der Domain enhalten keine der gewählten IP Adressen. Let's Encrypt Zertifikats-Erstellung ist nicht möglich. Ich habe noch ein paar andere Domains probiert - überall dieselbe Meldung. Auch jeweils geprüft, ob die verwendete SSL-IP dem dig bzw. nslookup entspricht und ja, das ist immer der Fall. Die DNS-Einträge der Domains und die Domains in Froxlor wurden ansonsten seit langer Zeit nicht mehr angefasst. Froxlor ist aktuell wie ich hoffe (0.10.33-1 (DB: 202112310)) ... Unterschied bei mir ist, dass DNS extern definiert ist (bspw. ffmcity.de auf die 195.5.191.48). Hilft eventuell meine Aussage, dass ich mehrere IPs auf dem Server definiert habe? Vielen Dank im voraus!

Ist schon länger her, der Thread, gerade musste ich noch einen Nachzügler unter den Froxlor-Servern von Debian 9 auf 10 bringen. Dabei hatte ich auch zunächst wieder das Problem, dass der Server "unavailable" nach dem Upgrade zurückgab. Selbe Meldung auch im Log "Permission denied" beim Zugriff auf den Socket. chmod 777 auf die Dateien half für schnelle Reaktivierung, bei der Fehlersuche hat sich rausgestellt, dass die /etc/nsswitch.conf keine "extrausers" be passd/group/shadow gesetzt hatte. Hinzugefügt, dann klappte es auch nach Serverneustart und Configs neu erzeugen: # Make sure that `passwd`, `group` and `shadow` have mysql in their lines # You should place mysql at the end, so that it is queried after the other mechanisams # passwd: compat mysql systemd extrausers group: compat mysql systemd extrausers shadow: compat mysql extrausers hosts: files dns networks: files dns services: db files protocols: db files rpc: db files ethers: db files netmasks: files netgroup: files bootparams: files automount: files aliases: files Und natürlich ohne chmod 777 auf die Sockets. 😉

Ja, Du hast natürlich recht: Wenn die IPs eingetragen (sind sie), konfiguriert und auch durch die Firewall gelassen werden, sollte das alles funktionieren. Hat es leider nicht. 🙂 Ich habe die Domain nun auch auf die .71 umgestellt, sie hatte für sich ein Zertifikat gezogen. Das habe ich ihr nun "weggenommen" (war quatsch - habe es danach wieder gesetzt), sie wieder als Alias für die andere Domain konfiguriert. Dazwischen immer brav das Skript ablaufen lassen. Wo ich mir nun nicht mehr sicher bin: Muss die Domain ein "eigenes" Häkchen bei "Let's Encrypt" haben (davon gehe ich aus) oder wird das dann über die Hauptdomain gesteuert, auf die die Aliases zeigen? Hat auf jeden Fall geklappt ... 😉 Ergebnis stimmt, funktioniert wieder. Die IP .74 sehe ich mir noch mal genau an mit einer Testdomain. Die anderen waren wichtiger. Danke!

konnt' es doch nicht lassen: Ganz einfache Sache, denke ich: ich-bin-auch-verschnupft.de hat auf die IP .74 gezeigt, der Rest auf die .71. Ist zwar alles auf demselben Server, mag aber LE wohl nicht ... Na denn.

Habe es hinbekommen: Eine der Alias-Domains ich-bin-auch-verschnupft.de hat vermutlich nicht mehr richtig aufgelöst (muss ich noch prüfen). Jedenfalls stand etwas derart in der LE-Verification. Domain als Alias entfernt, neu gestartet und glücklicherweise war ich bei meinen Versuchen unter der Max-Anzahl Versuche, die man pro Stunde machen darf. Zertifikat erstellt für die verschnupft.de, die anderen Domains mit im Zert enthalten. Nur eben die eine Alias-Domain nicht. Schaue ich mir Morgen an, dann schreibe ich den Grund. Muss für heute Schluss machen. Hab Männerschnupfen. Nacht und Danke! Jens

OK, ich probier es so wie Du sagst! Ansonsten bestell ich ein Kauf-Jahreszertifikat und gut. 😕 Danke für die schnelle Hilfe! 🙂

Verflixt, habe im Debug-Modus des Cron-Jobs eine Fehlermeldung gefunden: [Mo 17. Feb 17:58:04 CET 2020] _post_url='https://acme-v02.api.letsencrypt.org/acme/new-nonce' [Mo 17. Feb 17:58:04 CET 2020] _CURL='curl -L --silent --dump-header /root/.acme.sh/http.header -g -I ' [Mo 17. Feb 17:58:05 CET 2020] _ret='0' [Mo 17. Feb 17:58:05 CET 2020] POST [Mo 17. Feb 17:58:05 CET 2020] _post_url='https://acme-v02.api.letsencrypt.org/acme/new-order' [Mo 17. Feb 17:58:05 CET 2020] _CURL='curl -L --silent --dump-header /root/.acme.sh/http.header -g ' [Mo 17. Feb 17:58:06 CET 2020] _ret='0' [Mo 17. Feb 17:58:06 CET 2020] code='429' [Mo 17. Feb 17:58:06 CET 2020] Le_LinkOrder [Mo 17. Feb 17:58:06 CET 2020] Le_OrderFinalize [Mo 17. Feb 17:58:06 CET 2020] Create new order error. Le_OrderFinalize not found. { "type": "urn:ietf:params:acme:error:rateLimited", "detail": "Error creating new order :: too many failed authorizations recently: see https://letsencrypt.org/docs/rate-limits/", "status": 429 } [Mo 17. Feb 17:58:06 CET 2020] pid [Mo 17. Feb 17:58:06 CET 2020] No need to restore nginx, skip. [Mo 17. Feb 17:58:06 CET 2020] _clearupdns [Mo 17. Feb 17:58:06 CET 2020] dns_entries [Mo 17. Feb 17:58:06 CET 2020] skip dns. [Mo 17. Feb 17:58:06 CET 2020] _on_issue_err [Mo 17. Feb 17:58:06 CET 2020] Please add '--debug' or '--log' to check more details. [Mo 17. Feb 17:58:06 CET 2020] See: https://github.com/acmesh-official/acme.sh/wiki/How-to-debug-acme.sh [Mo 17. Feb 17:58:06 CET 2020] Diagnosis versions: openssl:openssl OpenSSL 1.1.1d 10 Sep 2019 apache: apache doesn't exists. nginx: nginx doesn't exists. socat: socat by Gerhard Rieger - see www.dest-unreach.org Usage: socat [options] <bi-address> <bi-address> options: -V print version and feature information to stdout, and exit -h|-? print a help text describing command line options and addresses -hh like -h, plus a list of all common address option names -hhh like -hh, plus a list of all available address option names -d increase verbosity (use up to 4 times; 2 are recommended) Tja, "too many failed ...". Jetzt sehe ich auch, dass das Zertifikat schon etwas älter ist - am 13.12.2019 zum letzten Mal erneuert wurde und nur noch bis zum 12.3. gültig ist. Komisch trotzdem. OK, ich lösche wie von Dir beschrieben, warte etwas und probiere wieder (zwischenzeitlich schaue ich mir die Rate-Limits an - ich habe das Gefühl, dass ich so schnell an kein Zert. komme ... ) Danke, Jens

Hallo allerseits, ich habe einen Froxlor-Server (aktuelle Version), der auf einer IP .71 ein Wildcard-Zertifikat für eine Domain *.irgendwas.de laufen hat. Auf dieser IP gibt es außer Domains, die eben auf *.irgendwas.de lauten auch noch Domains, die bspw. auf wasanderes.com lauten. Dafür habe ich jeweils Let's Encrypt Zertifikate aktiviert, was auch die letzte Zeit (Monate) soweit funktioniert hat und teilweise auch noch funktioniert. Bei einer Domain allerdings, als Bsp. ichbinverschnupft.de sieht man in Froxlor, dass Let's Encrypt aktiviert ist, Froxlor zieht sich auch brav ein Zertifikat für die verschnupfte Domain, das wird aber nicht in der Apache-Conf eingetragen. Stattdessen steht dort das besagte Wildcard der IP-Nummer. Eine andere unverschnupfte Domain verwendet dagegen wie konfiguriert ihr Let's Encrypt Zertifikat. Das Let's Encrypt sehe ich auch im Menüpunkt "SSL Zertifikate", es handelt sich dabei um eine Version mit mehreren Domains dahinter. Das ist für mein Gefühl die einzige Unterscheidung zu den übrigen unverschnupften Domains. Gerade sehe ich in den Systemlogs immer wieder diesen Fehler: Cronjob 17.02.20 17:31:05 error system Given SSL private key for verschnupft.de does not seem to match the certificate. Cannot create ssl-directives Hmm, Schluckauf, vermute ich. Die Config wurde seit einigen Tagen nicht angepasst. Ich deaktivere mal LE und aktiviere es dann nach dem Cron-Lauf neu ... Viele Grüße, Jens

Moin, der OP hier. Sorry, dass ich mich die ganze Zeit nicht gemeldet habe - gab/ gibt leider schwerwiegende Gründe. Hat mit Krhs und Koma zu tun. Ist sonst nicht meine Art, mich nicht zu melden. Zur Sache: Ich hatte mir für's Erste mit dem viel weiter oben beschriebenen Workaround (www-data an Gruppen in /etc/groups) beholfen. Den von mir selbst reingesetzten Link auf einen älteren Post hatte ich angesehen, geprüft, brachte mich aber nicht weiter. Inzwischen wurden 2 Froxlor-Updates reingedrückt und siehe da, beim heutigen Prüfen stand auf einmal "www-data" mit hinter jedem Eintrag in /var/lib/extrausers/groups : jens:x:10002:jens,froxlorlocal,froxlorlocal,www-data Da ich nun wegen der privaten Schwierigkeiten tatsächlich sonst in der Zwischenzeit nichts geändert hatte, bin ich ein wenig irritiert, freue mich aber natürlich, dass es nun läuft. Ich versuche trotzdem, das Ganze noch nachzuvollziehen. Inzwischen ist in der Konfiguration auch der anfangs fehlende Eintrag drin: "system.httpuser": "www-data", "system.httpgroup": "www-data", Vermutlich macht der das aus. Nur, wie gesagt, k.A., wo der herkommt ... 😕 Grüße, Jens

Kann es sein, dass mein Problem mit diesem hier identisch ist: Ich lese mir das in Ruhe durch und schaue, ob das passt. Da ging es auch um die ftp_groups

ok. ? aber sonst gibt es definitiv kein "froxlorlocal". Bzw. schon, in ftp_groups: Suchergebnisse für "froxlorlocal" mindestens eines der Wörter: 0 Treffer in cronjobs_run 0 Treffer in domain_dns_entries 0 Treffer in domain_redirect_codes 0 Treffer in domain_ssl_settings 4 Treffer in ftp_groups Anzeigen Löschen 0 Treffer in ftp_quotalimits 0 Treffer in ftp_quotatallies 0 Treffer in ftp_users 0 Treffer in mail_users 0 Treffer in mail_virtual 0 Treffer in panel_activation 0 Treffer in panel_admins 0 Treffer in panel_customers 0 Treffer in panel_databases 0 Treffer in panel_diskspace 0 Treffer in panel_diskspace_admins 0 Treffer in panel_domains 0 Treffer in panel_domaintoip 0 Treffer in panel_fpmdaemons 0 Treffer in panel_htaccess 0 Treffer in panel_htpasswds 0 Treffer in panel_ipsandports 0 Treffer in panel_languages 0 Treffer in panel_phpconfigs 0 Treffer in panel_plans 0 Treffer in panel_sessions 4 Treffer in panel_settings Anzeigen Löschen 0 Treffer in panel_syslog 0 Treffer in panel_tasks 0 Treffer in panel_templates 0 Treffer in panel_ticket_categories 0 Treffer in panel_tickets 0 Treffer in panel_traffic 0 Treffer in panel_traffic_admins 0 Treffer in redirect_codes Insgesamt 8 Treffer

Anders rum: Kann ich über die Datenbank die beiden Einträge korrigieren - auf www-data? "system.mod_fcgid_httpuser": "froxlorlocal", "system.mod_fcgid_httpgroup": "froxlorlocal", Ich trau mich mal. Moment.

OK, verstehe. Aber was doch schon bei mir falsch ist: Der "varname" ist nicht httpuser, sondern mod_fcgid_httpuser! Das bedeutet doch vermutlich, dass ich irgendwo eine Checkbox falsch gesetzt habe .. Grundsätzlich habe ich ja genau den httpuser richtig: "system.httpuser": "www-data", "system.httpgroup": "www-data", Kann es sein, dass hier fälschlich "froxlorlocal" aus dem fcgid gezogen wird? Editieren kann ich das Feld ja nicht ...