Jump to content
Froxlor Forum

rseffner

Members
  • Posts

    152
  • Joined

  • Last visited

  • Days Won

    5

Everything posted by rseffner

  1. Auch die neue Version ändert an der Ausgabe nichts. Eine Stichprobe meint zum Zertifikat in /root/.acme CreateTimeStr="Fr 3. Apr ..." bzw. NextRenewTimeStr="Mi 2. Jun ..." und in der DB als expiration="2020-04-26 09:10:21". Ich weiß ja nicht was Dein Code tun soll, aber in der DB sind noch immer andere Zertifikate wie im Dateisystem.
  2. root@ns2:~# /usr/bin/php7.3 -q /var/www/webs/its/froxlor.DOAMIN.de/scripts/froxlor_master_cronjob.php --force --debug ... [information] Running Let's Encrypt cronjob prior to regenerating webserver config files [error] Could not get Let's Encrypt certificate for bam-****.de: [error] Could not get Let's Encrypt certificate for angl****.de: ... [information] Let's Encrypt certificates have been updated [information] apache::createIpPort: creating ip/port settings for xxx.xxx.xxx.xxx:80 Ich nahm an --force ist ein weiterer Parameter zu --tasks. Leider ist die Ausgabe mit --debug an der gesuchten Stelle um keinen Deut umfangreicher.
  3. Danke für Deine Mühen. root@ns2:~# /usr/bin/php7.3 -q /var/www/webs/its/froxlor.DOMAIN.de/scripts/froxlor_master_cronjob.php --tasks --force [error] Could not get Let's Encrypt certificate for bam-****.de: [error] Could not get Let's Encrypt certificate for angl****.de: [error] Could not get Let's Encrypt certificate for anti****.de: .... Rechte? Wobei das php als root lief.
  4. Ich habe die Ursache für den, durch den cron-job angestoßenen renew, ja im Froxlor vermutet. - in der DB steht, das Zertifikat läuft bald aus - es wird von FROXLOR der renew geplant - da beim renew acme.sh aber merkt, dass sein Zertifikat noch längst nicht fällig wird verwehrt es den renew -> der Fehler, mit dem ich hier einstieg = nun habe ich acme.sh um die Kenntnis der Gültigkeit beraubt und der renew durch FROXLOR-cron fand statt, in .acme/ liegt ein neues Zertifikat ? warum ist das nun nicht auch in der DB erneuert Was verstehe ich hier falsch?
  5. 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?
  6. 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?
  7. 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.
  8. 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.
  9. 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?
  10. 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
  11. 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?
  12. Dieser punktgenaue, fixe Support gehört bezahlt - zumindest kann man sich da anderswo ein Scheibchen abschneiden. Die Fehlermeldung ist damit weg. Danke.
  13. 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
  14. Wenn ich ergänzen darf: rspamd.
  15. An PHP wirds mit Sicherheit nicht liegen. Deine Aussagen sind allerdings zu dünn und konfus um jetzt konkret zu helfen. Erst schreibst Du POP3/IMAP tun und dann zeigst Du uns Fehler aus deren Log. SMTP geht nicht aber Du bleibst uns Logs schuldig. Soweit ich mich erinnere, sehen die Configtemplates von Froxlor keine eigene TLS/SSL Zertifikate für postfix?/dovecot vor. Was hindert Dich die Konfig von Debian 8 zu übernehmen? Im Zweifel mit Intelligenz und "diff". Ich habe vor einer Woche erst ein Upgrade von Debain 8 auf 9 mit installiertem Froxlor gemacht, da war nur bisschen im Dovecot anzupassen mit den Mailbox-Pfaden. So wie Du Dich hier ausdrückst, erweckt das den Eindruck, man könne Dir nur effektiv remote helfen. "d00p" hat dazu ein Bussines und andere wie ich könnten das vermutlich auch, wenn Du den per PM Logindaten rausgeben willst.
  16. Ich möchte zu bedenken geben, dass der Support von PHP 7.0 seit 2 Wochen eingestellt ist und das Ende für 5.6 zum Jahreswechsel ansteht. Nehme der geneigte Admin doch bitte 7.2 oder 7.3 (aber das ist taufrisch).
  17. Wird denn die Funktion domainValidate perspektivisch entsorechend angepasst, dass sie auch den "_" zulässt?
  18. Microsoft wünscht sich, dass ich u.a. "selector1._domainkey 1D IN CNAME selector1-DOMAIN-TLD._domainkey.DOMAIN.onmicrosoft.com" im DNS verewige. Also nutze ich den DNS-Editor auf Domainebene und fülle wie folgt aus: Record : selector1._domainkey Type : CNAME Priority : ich lösche die vorausgefüllte "0" Content : selector1-DOMAIN-TLD._domainkey.DOMAIN.onmicrosoft.com. (man beachte den Punkt am Ende; natürlich ersetze ich DOMAIN und TLD durch was Sinnvolles) TTL : 86400 Froxlor meint dazu aber "Ungültiger Domain-Name für CNAME Eintrag". Mache ich den Fehler (welchen) oder Froxlor?
  19. Ich habe den Fall hier auch mehrfach, dass Kunden eigenen Mail- oder Groupware-Server als hidden MX betreiben. Dass man dazu eine transport-Regel für den postfix manuell bauen muss ist für einen Admin kein Ding und muss nicht unbedingt ins Froxlor (dann aber "E-Mail-Domain" deaktivieren!). Was mir mehr "Kummer" bereitet ist, dass diese Kunden mich dann als smarthost/relayhost verwenden möchten und ich für die ja keinen sasl-Nutzer anlegen kann (ohne Weiteres). Bisher helfe ich mir dadurch, dass ich trotz deaktivierte E-Mail-Domaineinstellung direkt im SQL einen Nutzer/ein für den Kunden anlege. Das ist schon ein dirty Hack, den man schnell übersieht. Hier könnte ich mir schon eine Implementation ins Froxlor wünschen: - einen sasl-enabled Nutzer anlegen, für denn dann auch traffic gezälht wird, aber das ist wirklich kein Kernfeature - vermutlich ist dann der transport Eintrag auch noch ein Klacks Aber ich hätte auch gern DKIM-Support für opendkim gesehen, jetzt sogar für rspamd. Das alles hat hier wohl keine breite Anwenderschaar und steht deswegen - wenn überhaupt - ganz hinten auf der Entwicklerliste.
  20. Hi Doop, in der Angabe des von Kunden belegten Platzes fließen wohl das DocRoot, die Mailordner und die Datenbank(en) ein. Wie wird denn dabei konkret der Datenbankplatz ermittelt? Ich frage, weil mir eben auffiel, dass MyISAM Tabellen wohl eigenständig unter /var/lib/mysql/CUSTOMER zu finden sind, aber die INNODB (zumindest unter Debian) alles in eine Datei packt. Man kann das INNODB-Verhalten aber per Parameter ändern. Für den Fall, dass über das Dateisystem gezählt wird, wäre das vielleicht zu beachten, aus Sicht von SQL-Abfragen zur DB-/Tabellengröße spielt diese Erkenntnis jetzt keine Rolle. Gruß, Ronny
  21. Mit dem git clone läuft das Backup (wieder). Danke.
  22. Existiert nicht. Ist nicht "/", heißt nicht wie der Kundenpräfix und ist nicht gleich dem Homedir. Die erwartete Logzeile fehlt hartnäckig. Ich teste auf anderem Server mit anderem Kunden gegen ... da gehts auch nicht. (beide froxlor 0.9.39.5)
  23. ns1:~# dpkg -l | grep zip ... ii php-zip 1:7.2+62+0~20180924124148.6+jessie~1.gbp62811c all Zip module for PHP [default] ii php7.2-zip 7.2.10-1+0~20181001133426.7+jessie~1.gbpb6e829 amd64 Zip module for PHP ... ii zip 3.0-8 amd64 Archiver for .zip files Ich denke schon.
  24. Der SQL-Export sieht eigentlich (weil vorhanden und ein paar verständliche Inhalte - aber was weiß ich schon) gut aus: INSERT INTO `panel_tasks` (`id`, `type`, `data`) VALUES (16, 20, 'a:8:{s:10:\"customerid\";s:2:\"18\";s:3:\"uid\";s:5:\"10017\";s:3:\"gid\";s:5:\"10017\";s:9:\"loginname\";s:3:\"kep\";s:7:\"destdir\";s:29:\"/var/www/webs/kep/backuptest/\";s:10:\"backup_dbs\";i:1;s:11:\"backup_mail\";i:1;s:10:\"backup_web\";i:1;}');
  25. Klar. Pfad ist jetzt "/backuptest" weil ich vermute, dass dieser relativ zum Kundenordner verwendet wird und nicht absolut im Dateisystem. /usr/bin/nice -n 5 /usr/bin/php5 -q /var/www/webs/its/froxlor1.seffner-schlesier.de/scripts/froxlor_master_cronjob.php --backup --debug [information] cron_backup: started - creating customer backup [notice] Creating passwd file [notice] Writing 76 entries to passwd file [notice] Succesfully wrote passwd file [notice] Creating group file [notice] Writing 21 entries to group file [notice] Succesfully wrote group file [notice] Creating shadow file [notice] Writing 76 entries to shadow file [notice] Succesfully wrote shadow file [notice] Checking system's last guid Weder Pfad noch Backup sind auffindbar.
×
×
  • Create New...