df8oe
-
Posts
137 -
Joined
-
Last visited
-
Days Won
1
Posts posted by df8oe
-
-
Nein, nicht ganz richtig. Ich habe meinen Pull-Request zurückgezogen weil mein Code nicht deinen Qualitätsansprüchen genügt hat und ich nicht in der Lage war (und nach wie vor auch nicht bin) deine Qualitätsansprüche zu erfüllen. Ich habe noch nicht mal verstanden was Du überhaupt wolltest. Die Funktionalität ist von Anfang an gegeben gewesen und das ist sie auch noch in der 0.10.38. Mein Skill in Sachen PHP ist nicht sehr hoch. Er reicht um einfache Aufgaben zu lösen - mehr nicht. Mein Zuhause ist C. Ich habe auch nicht vor tiefer in PHP einzusteigen. Das was ich will kann ich damit. Pflege ich das wieder ein würde es zu 100% wieder nicht übernommen werden weil die Codequalität unverändert ist. Den Ansatz funktionell interessanten Code bei zu ungenügender Codequalität selbst entsprechend umzuschreiben verfolgst Du offenbar nicht - musst Du ja auch nicht. Ist ja dein Projekt! Da suche ich jetzt lieber den Grund für die Fehlfunktion in der 0.10.38 und contribute hier die Erklärung - das ist dann sozusagen mein kleiner Anteil am Support für die 0.10.x
EDIT:
Es ist aber ein immer wiederkehrendes Problem. Es gibt 1000 Leute die Änderungen gut finden und danach fragen, aber nur einen (oder wenige) die sie dann umsetzen. (Team = Toll Ein Anderer Machts). Ich hatte ja auch mal im Forum nachgefragt ob irgendjemand mit mehr PHP-Skills sich mal meine paar Zeilen anschaut und sie so ändert, dass sie deinen Ansprüchen genügen. Es gab NULL Resonanz. Ich kann Dich da auch verstehen - nur kann ich nicht anders.
-
Wie beim 0.10 von deinem GitHub oder mit den Erweiterungen/Änderungen die ich dazugecoded hatte, die aber nie Einzug in den Hauptzweig gefunden hatten: https://github.com/df8oe/Froxlor
Die Version aus dem Hauptzweig war nämlich so wie sie damals war als ich den Fork gemacht hatte noch nicht ganz lauffähig. Aber mit meinen Ergänzungen schon.
-
...und beim neuen gibt es keine DKIM-Unterstützung...
Danke!
-
Bei einem meiner Server (nicht bei allen trotz identischer Konfiguration und identischem Betriebssystem / Pflege!) stand bei Froxlor in der Datenbankprüfung bei IP-Domainverknüpfung ein Fehler. Es lief aber alles noch einwandfrei. Ich habe den Fehler automatisch reparieren lassen - danach war auch alles wieder "grün" und auf den ersten Blick lief auch alles wie vorher. Es gibt aber ein seltsames Verhalten das mir beim Wechsel der PHP-Version einer Domain aufgefallen ist:
Die Domain steht dann zweimal im php-Konfigurationspanl aufgeführt. Einmal da wo ich sie hingeschoben habe und einmal beim "recent php". Wenn ich sie ins "recent php" schiebe steht sie dort zweimal aufgeführt. Der php-fpm fastcgi Name ist auch seltsam: er lautet 1-froxlor.panel-domain-php-fpm.socket - sollte aber heißen 1-kunde-domain-php-fpm.socket. Genau auf den letzten Socket zeigt auch die Apache-Domain-Konfigurationsdatei - der Socket wird aber immer mit dem falschen Namen angelegt. Und er "übersteht" auch einen php-Wechsel der betreffenden Domain ohne Probleme: der alte Socket bleibt erhalten (in /etc/php/php-fpm.d/ steht dann nach wie vor der falsche - zusätzlich wird der richtige in der betreffenden php-fpm.d/ angelegt. Ich denke ich muss das Problem manuell in der Datenbank fixen - aber dazu fehlen mir Infos woher überhaupt der "fehlerhafte" php-fpm Socket generiert werden kann...
-
16 hours ago, d00p said:
We did not remove anything related to that - if I remember correctly you created something on your own for your needs
Thats nice to read! Because my additions / pull request was not merged I have to dig to the code once more and try to implement again. I think git cannot help me here - the differences between 10.x and 2.x are too big. I will try to install a 2.x parallel to the existing 10.38 (using a different database) and try to implement again. I am not lucky about changes that ignores different paths on different distributions in the installer (not configurable in installation), but it is solveable...
-
I cannot see dkim-implementation. Have I missed it or is it not yet implemented? This feature is used intensively on my servers...
-
OK! So you will supply security fixes on 0.10.x branch in the future? That sounds great!
-
Is there a place where I can find known exploits relating to specific Froxlor versions? I have found some on https://www.exploit-db.com/ - but I think there are continuous fixes for new discovered. I have to stay on a specific Froxlor version because newer ones are not compatible with my running DKIM implementation... So a way to use this feature is to fix exploits manually by myself.
-
1 hour ago, d00p said:
Na wenn es deine Fähigkeiten übersteigt, dann ziehe doch bitte den Pull-Request zurück und lass es
Das werde ich tun - gute Idee! Seit 3 Jahren läuft der DKIM-Support in meinem Froxlor einwandfrei und hat mir gute Dienste geleistet. Sollte mein DKIM-Support nicht einfach in das aktuelle Froxlor zu übernehmen sein bleibe ich auf meiner 0.10.x und warte bis es beim offiziellen Froxlor auch DKIM gibt... Danke für deine git-Erläuterungen, ich schaue mal ob ich das hinbekomme. Wenn nicht --> dann eben nicht
-
Geht nicht - oder ich mache was falsch. Dann sagt er mir dass ich keine Schreibberechtigung habe. Ich denke damit habe ich dein Repo auch zum versenden (push) konfiguriert.
git push --set-upstream git@github.com:Froxlor masterIch habe aber mein lokales Repo bevor ich irgendwas nach deiner Änderung geschraubt habe gesichert und kann immer auf diesen Stand zurück.
Mein lokales Repo hat nur den Branch "master". Ich hatte lange Zeit zuvor deinen master-Branch so eingerichtet, dass ich mit
git fetch upstreamdeinen neuesten Stand geholt habe. Den habe ich dann jeweils mit
git merge upstream/masterin mein lokales git geholt. Manchmal - nur sehr selten - gab es merge-Konflikte die ich dann manuell lösen musste. Wenn mein lokales Repo dann wieder aktuell war habe ich es mit
git push origin masterauf mein GitHub gepusht.
Da es bei Dir kein "master" mehr gibt macht der Befehl "git fetch upstream" nicht mehr das was er vorher gemacht hat. Ich bin kein professioneller Programmierer. Selbstverständlich verwende ich git für meine Projekte - aber die Konstellationen sind immer überschaubar und einfach. Ich war schon froh dass ich die Konfiguration mit deinem Repo so hinbekommen habe dass ich meinen Fork immer mit deinem aktualisieren konnte. Die Konstellation die jetzt vorliegt bekomme ich wohl nur gelöst wenn ich den dazugehörigen Befehl c&p machen kann. Das übersteigt definitiv meine Fähigkeiten - genauso wie die Änderungen die Du zu meinen DKIM-Implementationen von mir haben wolltest
...
-
So klappt das leider nicht weil ich dein Github als "upstream" behandle. Ich habe vor ewigen Zeiten dein Repo geclont und dann meine DKIM-Änderungen eingepflegt. Dann habe ich mein Repo auf mein Guthub gepusht. Nachdem meine DKIM-Änderungen fertig waren habe ich mein Repo immer mit
git fetch upstream git merge upstream/masterauf deinen Stand gehoben, und dann mit
git push origin masterauf mein Github veröffentlicht. So waren meine "Umbauten" immer im letzten Original-Froxlor enthalten...
-
Hi, you renamed default branch from master to main. I noticed that at my upstream sync today:
git fetch upstream git merge upstream/masterThis leads to "bereits aktuell". I do not want to scatter my working DKIM fork - so can you please point me how to get in sync with your upstream repo? I never have had such a scenario before
...
-
I mean it is simpler to fire one mysql command for modifying all domains than fiddling through individual settings of 79 domains
-
I see database is already prepared has a field for this value. I will modify this in database.
-
I am stepping forward. Because my server is running the newest software (Arch based) it now uses the strongest ciphers. One thing is remaining: I must use two weak ciphers to not kick off older OS/X and WindowsPhone devices. Now I want to set
"SSLHonorCipherOrder on"
"SSLSessionTickets off"
and I did so in apache SSL mod settings. But Froxlor does not use this: "SSLHonorCipherOrder" is always set to "off" and "SSLSessionTickets" is ignored completely. How can I tell Froxlor to activate "SSLHonorCipherOrder" for all domains?
-
Thank you - thats what I was looking for...
-
Hi to all,
I have checked my sites with https://www.ssllabs.com/ssltest/ to check http2 functionaliy. Everything is working fine - except there are many weak ciphers detected. I already have edited apache ssl config - it only contains the following ciphers:
SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
But this has no effect - weak ciphers are staying exactly as before. I checked that froxlor generated configs also include a list of ciphers. Does this list override the default settings? Where can I edit the ciphers froxlor uses for building the configs? I never have focused on that before...
-
Ergänzung: der Cronjob von acme läuft um 00:07... Damit ist die Sache mit der Wahrscheinlichkeit wieder obsolet. Vielmehr sieht es jetzt so aus als wenn acme die in der conf vorhandene Einstellung für Le_API mit zerossl überschreibt. Vielleicht hilft ja das Log von dem Cron-Lauf bei dem die Config neu (falsch) geschrieben wurde:
[Sa 14. Mai 00:07:06 CEST 2022] di='/root/.acme.sh/domain.xyz/' [Sa 14. Mai 00:07:06 CEST 2022] d='domain.xyz' [Sa 14. Mai 00:07:06 CEST 2022] Using config home:/root/.acme.sh [Sa 14. Mai 00:07:06 CEST 2022] ACME_DIRECTORY='https://acme.zerossl.com/v2/DV90' [Sa 14. Mai 00:07:06 CEST 2022] DOMAIN_PATH='/root/.acme.sh/domain.xyz' [Sa 14. Mai 00:07:06 CEST 2022] Renew: 'domain.xyz' [Sa 14. Mai 00:07:06 CEST 2022] Le_API='https://acme-v02.api.letsencrypt.org/directory' [Sa 14. Mai 00:07:06 CEST 2022] Using config home:/root/.acme.sh [Sa 14. Mai 00:07:06 CEST 2022] ACME_DIRECTORY='https://acme.zerossl.com/v2/DV90' [Sa 14. Mai 00:07:06 CEST 2022] _main_domain='domain.xyz' [Sa 14. Mai 00:07:06 CEST 2022] _alt_domains='www.domain.xyz' [Sa 14. Mai 00:07:06 CEST 2022] Le_NextRenewTime='1652396849' [Sa 14. Mai 00:07:06 CEST 2022] Using ACME_DIRECTORY: https://acme.zerossl.com/v2/DV90 [Sa 14. Mai 00:07:06 CEST 2022] _init api for server: https://acme.zerossl.com/v2/DV90 [Sa 14. Mai 00:07:06 CEST 2022] GET [Sa 14. Mai 00:07:06 CEST 2022] url='https://acme.zerossl.com/v2/DV90' [Sa 14. Mai 00:07:06 CEST 2022] timeout= [Sa 14. Mai 00:07:06 CEST 2022] _CURL='curl --silent --dump-header /root/.acme.sh/http.header -L ' [Sa 14. Mai 00:07:10 CEST 2022] ret='0' [Sa 14. Mai 00:07:10 CEST 2022] ACME_KEY_CHANGE='https://acme.zerossl.com/v2/DV90/keyChange' [Sa 14. Mai 00:07:10 CEST 2022] ACME_NEW_AUTHZ [Sa 14. Mai 00:07:10 CEST 2022] ACME_NEW_ORDER='https://acme.zerossl.com/v2/DV90/newOrder' [Sa 14. Mai 00:07:10 CEST 2022] ACME_NEW_ACCOUNT='https://acme.zerossl.com/v2/DV90/newAccount' [Sa 14. Mai 00:07:10 CEST 2022] ACME_REVOKE_CERT='https://acme.zerossl.com/v2/DV90/revokeCert' [Sa 14. Mai 00:07:10 CEST 2022] ACME_AGREEMENT='https://secure.trust-provider.com/repository/docs/Legacy/20201020_Certificate_Subscriber_Agreement_v_2_4_click.pdf' [Sa 14. Mai 00:07:10 CEST 2022] ACME_NEW_NONCE='https://acme.zerossl.com/v2/DV90/newNonce' [Sa 14. Mai 00:07:11 CEST 2022] Using CA: https://acme.zerossl.com/v2/DV90 [Sa 14. Mai 00:07:11 CEST 2022] _on_before_issue [Sa 14. Mai 00:07:11 CEST 2022] _chk_main_domain='domain.xyz' [Sa 14. Mai 00:07:11 CEST 2022] _chk_alt_domains='www.domain.xyz' [Sa 14. Mai 00:07:11 CEST 2022] Le_LocalAddress [Sa 14. Mai 00:07:11 CEST 2022] d='domain.xyz' [Sa 14. Mai 00:07:11 CEST 2022] Check for domain='domain.xyz' [Sa 14. Mai 00:07:11 CEST 2022] _currentRoot='/var/www/froxlor' [Sa 14. Mai 00:07:11 CEST 2022] d='www.domain.xyz' [Sa 14. Mai 00:07:11 CEST 2022] Check for domain='www.domain.xyz' [Sa 14. Mai 00:07:11 CEST 2022] _currentRoot='/var/www/froxlor' [Sa 14. Mai 00:07:11 CEST 2022] d [Sa 14. Mai 00:07:11 CEST 2022] config file is empty, can not read CA_KEY_HASH [Sa 14. Mai 00:07:11 CEST 2022] Using config home:/root/.acme.sh [Sa 14. Mai 00:07:11 CEST 2022] ACME_DIRECTORY='https://acme.zerossl.com/v2/DV90' [Sa 14. Mai 00:07:11 CEST 2022] _init api for server: https://acme.zerossl.com/v2/DV90 [Sa 14. Mai 00:07:11 CEST 2022] RSA key [Sa 14. Mai 00:07:11 CEST 2022] config file is empty, can not read CA_EAB_KEY_ID [Sa 14. Mai 00:07:11 CEST 2022] config file is empty, can not read CA_EAB_HMAC_KEY [Sa 14. Mai 00:07:11 CEST 2022] config file is empty, can not read CA_EMAIL [Sa 14. Mai 00:07:11 CEST 2022] No EAB credentials found for ZeroSSL, let's get one [Sa 14. Mai 00:07:11 CEST 2022] acme.sh is using ZeroSSL as default CA now. [Sa 14. Mai 00:07:11 CEST 2022] Please update your account with an email address first. [Sa 14. Mai 00:07:11 CEST 2022] acme.sh --register-account -m my@example.com [Sa 14. Mai 00:07:11 CEST 2022] See: https://github.com/acmesh-official/acme.sh/wiki/ZeroSSL.com-CA [Sa 14. Mai 00:07:11 CEST 2022] _on_issue_err [Sa 14. Mai 00:07:11 CEST 2022] Please check log file for more details: /root/.acme.sh/acme.sh.log [Sa 14. Mai 00:07:11 CEST 2022] Return code: 1 [Sa 14. Mai 00:07:11 CEST 2022] Error renew domain.xyz. -
Aber vielleicht triggert er das Schreiben? Ich finde die Tatsache dass das Modifikationsdatum der conf-Dateien exakt mit dem Werfen der Cron-Mail 24 Stunden später übereinstimmt eigenartig.
-
Ich bin mir inzwischen nicht mehr sicher ob der Fehler wirklich bei acme liegt. Ich habe auf meinen Servern nach dem letzten Problem geschaut ob in irgendeiner conf noch zerossl steht: nein, da stand überall letsencrypt - und das seit dem 5.Mai. Heute morgen bekomme ich wieder mit dass nun bei sieben Domains wieder zerossl drinsteht und der renew fehlschlägt... Die confs wurde gestern morgen um 00:07 neu geschrieben - dabei ist es passiert. Die Meldung vom Froxlor-Cronjob dass das Renew fehlgeschlagen ist datiert von heute 00:07. Ist es ein Zufall dass die Änderungen an den confs beim Froxlor-cron-Lauf um 00:07 gestern geschahen - und exakt um die gleiche Zeit am nächsten Tag können deswegen keine Zertifikate erneuert werden? Für mich ist die Wahrscheinlichkeit hoch dass Froxlor selbst bei seinem cron-Lauf gestern die confs neu geschrieben hat - und dabei ist be denen wo die Zertifikate erneuert werden sollen zerossl reingekommen. Bei allen anderen confs (bei denen die Zertifikate noch länger gültig sind) ist nichts böses passiert.
-
2 minutes ago, d00p said:
weil der ein renew-all macht und dann pro certificate in die certificate-config schaut
Danke - der Anker führt mich weiter! Ich schaue mir mal die certificate-configs an.
-
hmmmm.... Die Einstellungen sind nach wie vor alle korrekt. Ich ging bislang davon aus dass das zwei verschiedene Mechanismen sind:
1) acme pflegt die Zertifikate autark in /root/.acme.sh/ mit Hilfe des cron-Jobs von root.
2) Froxlor kopiert eventuell neu geholte Zertifikate um
Ich habe in der Crontab von root geschaut - da steht ein Standardaufruf von acme.sh drin. Woher weiß dieser Standardaufruf dass er nicht zerossl benutzen soll? Oder ist der root-acme-Cronjob obsolet/kontraproduktiv und Froxlor kaskadiert einen selbst initialisierten acme-Lauf mit seinem Teil der Zertifikatsübernahme?
-
Weitere Ergebnisse:
Es waren 5 Domains verteilt auf die zwei Server betroffen. Die letzten erfolgreichen Zertifikatserneuerungen waren am 30.04.
Ich habe die 5 Domains jetzt mit
acme.sh --renew -d mydomain1.xxx --server letsencrypt acme.sh --renew -d mydomain2.xxx --server letsencrypt ...erneuert: das lief ohne Fehler durch. Woher bekommt acme die Information dass es letsencrypt benutzen soll? Denn daran scheint es zu haken.
-
Das hatte ich auch so gesehen. Sollte es aber ein Problem von acme sein dürften ja mehr User von Froxlor betroffen sein und hier könnten weitere Reports aufschlagen. Die betreffenden Zertifikate laufen noch 1 Monat - ich werde das erstmal weiter beobachten.
[gelöst] Froxlor 0.10.38.1 - seltsames Verhalten nach "Datenbankfehler"
in German / Deutsch
Posted
Die Lösung war einfach. Die "automatische Reparatur der Datenbank" hat den Hostnamen in Einstellungen -> System neu eingetragen und dort eine normale Domain genommen. Vermutlich war das Feld warum-auch-immer beschädigt und diese Eintragung machte die Datenbank wieder konsistent. Nun lief aber auf der Domain auch das php-fpm des Froxlor-Users zusätzlich zu dem des eigentlichen Users. Das führt natürlich zu Problemen. Hostnamen wieder richtig gesetzt, alles gut.