iam

Ok? Dein Kundenstamm scheint ja die feinste Auslese zu sein, kenne ich so nicht.

Eine direkte Sperrug bei Zahlungsverzug ohne Mahnung ist unwirksam, da gebe ich dir Recht. Tendenziell war hier aber von "Allgemein" die Rede und das stimmt einfach nicht. Als Webhoster habe ich einen Dienstleistungsvertrag mit dem Endkunden. Genau wie bei den Stadtwerken. Ihr könnt ja gerne mal einfach die Gasrechnung nicht bezahlen. In 2-3 Monaten kommen dann die netten Kollegen im Blaumann und der Hahn ist dicht. Einfache Sache. P.S. Ich sagte bitte per PN, dies ist kein Thema, wo es um Offtopics geht.

Damit hast du dir die Frage fast schon selber beantwortet. Wenn der Kunde dann doch wieder bestellt, legst du direkt alles doppelt und dreifach an? Letzteres sehe ich nicht so, ansonsten gerne Urteile von einem OLG, BGH oder dem EUGH an mich per PN, danke.

Im grunde hast du Recht, klar. Für mich ist das nur ein Denkspiel, denn wenn ich einen Kunden deaktiviere, ist ja automatisch auch seine Domain nicht mehr nutzbar (Webspace & Mail). Somit wäre ein renew nicht nötig, wenn ich reaktiviere mit Sicherheit schon. Wie gesagt, ich bin bei weitem nicht so firm wie du im PHP und es sollte mehr oder weniger ein kleiner Verbesserungsvorschlag sein, auf den du natürlich nicht eingehen brauchst. ^^ - Wenn der Kunde deaktiviert wurde und dessen Domain(s) LE nutzt, dann führe ACME remove aus. - Wenn der Kunde reaktiviert wurde und dessen Domain(s) LE nutzt, dann führe ACME add aus. ----------------------- Tendenziell weniger, allerdings wollte ich sicher gehen, dass PHP keine benötigten Function's blockiert und oder OpenBaseDir mit dazwischen grätscht. ----------------------- Gerne, ich schreibe dich gleich mal per PN an. LG

Ja, hast du Recht. Soll mir auch Recht sein. Wäre ggf. ja noch mal eine zukünftige Verbesserung, den Ordner mit löschen zu lassen inh. des ACME. Außerdem sollte dies auch beim Deaktivieren des Kunden auch umgesetzt werden und nicht nur beim löschen der Domain, was meinst du? 😃 Allerdings habe ich nun sämtliche PHP-Features für froxlor freigegeben, bzw. Sicherheitseinschränkungen deaktiviert. Dementsprechend auch das Debugging inh. PHP und ACME aktiviert und ich wünschte ich könnte etwas anderes sagen, aber ACME wird in diesem Fall von Froxlor nicht einmal angesprochen. 😞 Ich habe definitiv nicht alles auf Default, allerdings betreffen die Anpassungen nur das Mailsystem und einige Variablen, wo die Konfigurationen liegen sollen, welche auch reibungslos funktionieren. ACME ist ja fest in der Codebasis integriert. Ich bin ehrlich gesagt auch kein Entwickler und bin froh, wenn ich den Code von dir nachvollziehen und verstehen kann. Dafür bin ich Jahrelang in der Systemintegration tätig und bin firm darin, welche Stellschrauben, was bewirkten. VG

Zu. 1: Richtig, den hat Froxlor bei mir nicht installiert. Habe ich jetzt mit acme.sh --install-cronjob nachgeholt. Zu 2: Den suche ich auch gerade -> GitHub, kann den acme.sh --remove Befehl nicht finden. Zu 3: Kurz die Schritte: Anlegen einer Testdomain + Aktivierung von LE Zertifikat korrekt bezogen und unter /root/acme.sh/*domain* abgelegt, sowie auch in dem Webserver-Kunden-SSL-Zertifikatsverzeichnis Domain gelöscht + Cronjob durchlaufen lassen Zertifikat und Domain wurden sauber aus der Datenbank entfernt, sowie in dem Webserver-Kunden-SSL-Zertifikatsverzeichnis Nur bleibt der Ordner /root/acme.sh/*domain* bestehen und somit sich auch die Konfigurationen. Dementsprechend versucht der ACME-Cronjob bei jedem Renew ein Zertifikat für diese alte Domain zu beziehen, obwohl diese ja nicht mehr existent ist. Hoffe das man mit den Schritten was anfangen kann. ^^

Also Froxlor legt bei mir den Cronjob nicht erneut an, den musste ich manuell Nachpflegen. Noch mal eine andere Sache... Ist es so gewollt, dass unter /root/acme.sh die alten, nichtexistenten Domains bunkert? Erschließt sich mir nicht, wieso ACME immer in einen renew von Domains laufen sollte, der zum Scheitern verurteilt ist. Alles weitere funktioniert. Der Eintrag in der Datenbank wird korrekt entfernt, das Webserver-Kunden-SSL-Zertifikatsverzeichnis wird auch korrekt bereinigt, nur im /root/.acme.sh bunkern sich die alten Daten.

Naja, wenn man den Ordner "/root/acme.sh" löscht, die Tabelle "domain_ssl_settings" leert und den "froxlor_master_cronjob.php --debug --force" hinterhersetzt, passiert nichts anderes, als das Froxlor alles neu generiert. Aber wem erzähle ich das... ^^ Muss der ACME-Cronjob installiert sein? Den habe ich nach dem "Big-Update" rausgeschmissen, da er seinerzeit für Fehler gesorgt hatte.

Hallo, vor drei Monaten wollte mir ACME meine Zertifikate nicht erneuern, da es irgendein Problem mit ECC hatte. Ich habe dann kurzen Prozess gemacht und alle Zertifikate aus der Datenbank manuell entfernt, sowie den "/root/.acme.sh" Ordner gelöscht und alles via "froxlor_master_cronjob.php --debug --force" neu anlegen lassen. Jetzt wieder ein Fehler. Froxlor oder ACME wollen nicht erkennen, dass die Zertifikate abgelaufen sind. Hier der Auszug aus: froxlor_master_cronjob.php --debug --force [information] TasksCron: Searching for tasks to do [information] TasksCron: Task10 started - setting filesystem quota [information] Running Let's Encrypt cronjob prior to regenerating webserver config files [information] Updated Let's Encrypt certificate for *privacy*.net [information] Updated Let's Encrypt certificate for *privacy*.net [information] Updated Let's Encrypt certificate for *privacy*.net [information] Updated Let's Encrypt certificate for *privacy*.net [information] Updated Let's Encrypt certificate for *privacy*.biz [information] Updated Let's Encrypt certificate for *privacy*.de [information] Updated Let's Encrypt certificate for *privacy*.de [information] Updated Let's Encrypt certificate for *privacy*.de [information] Updated Let's Encrypt certificate for *privacy*.de [information] Updated Let's Encrypt certificate for *privacy*.de [information] Updated Let's Encrypt certificate for *privacy*.eu [information] Let's Encrypt certificates have been updated [information] apache::createIpPort: creating ip/port settings for *:80 [information] apache::createIpPort: creating ip/port settings for *:443 [information] apache::createVirtualHosts: creating vhost container for domain 2, customer web0 [information] apache::createVirtualHosts: creating vhost container for domain 3, customer web0 [information] apache::createVirtualHosts: creating vhost container for domain 4, customer web0 [information] apache::createVirtualHosts: creating vhost container for domain 8, customer web4 [information] apache::createVirtualHosts: creating vhost container for domain 9, customer web5 [information] apache::createVirtualHosts: creating vhost container for domain 10, customer web6 [information] apache::createVirtualHosts: creating vhost container for domain 7, customer web3 [information] apache::createVirtualHosts: creating vhost container for domain 11, customer web7 [information] apache::createVirtualHosts: creating vhost container for domain 5, customer web1 [information] apache::createVirtualHosts: creating vhost container for domain 12, customer web8 [information] apache::createVirtualHosts: creating vhost container for domain 6, customer web2 [information] apache::createVirtualHosts: creating vhost container for domain 1, customer web0 [information] apache::writeConfigs: rebuilding /etc/apache2/froxlor-directorys/ [information] apache::writeConfigs: rebuilding /etc/apache2/froxlor-htpasswd/ [information] apache::writeConfigs: rebuilding /etc/apache2/froxlor-sites/ [information] Froxlor\Cron\Http\ApacheFcgi::reload: running service php7.3-fpm reload [information] Froxlor\Cron\Http\ApacheFcgi::reload: reloading Froxlor\Cron\Http\ApacheFcgi [notice] Creating passwd file [notice] Writing 9 entries to passwd file [notice] Succesfully wrote passwd file [notice] Creating group file [notice] Writing 9 entries to group file [notice] Succesfully wrote group file [notice] Creating shadow file [notice] Writing 9 entries to shadow file [notice] Succesfully wrote shadow file [notice] Checking system's last guid Und: froxlor_master_cronjob.php --debug --letsencrypt [information] No new certificates or certificate updates found [notice] Checking system's last guid Kann mir btw auch noch mal jemand beantworten, weshalb ein Wechsel zu ACME notwendig war? 😕 Das alte System schien mir wesentlich zuverlässiger. Da hatte ich noch nie ein Problem mit der Erstellung oder Erneuerung von Zertifikaten. Und wieso muss ".acme.sh" im Homevz des Benutzer Root liegen? Ich persönlich störe mich daran und würde mir einen variablen Ort wünschen, den man im Panel konfigurieren kann. Wurde mMn auch schon mal angesprochen hier im Forum. LG P.S. Da die Zeit knapp ist, werde ich die Prozedur wiederholen und alle Zertifikate, sowie Ordner löschen.

I have the exact same problem. 0.10.17 (DB: 202005150)

Auch eils Einzelunternehmer hast du einen kommerziellen Druck dahinter, dich um Froxlor zu kümmern, um nicht die Sicherheit der Daten von deinen Kunden zu gefährden. Du wirst mir wohl nicht sagen wollen, dass du hier Plesk o.A. eingesetzt hast. Generell bin schaue ich mich gerade tatsächlich um und bin auf KeyHelp von der KeyWeb AG gestoßen. Gleicher bis größerer Funktionsumfang (Antivirus & Spam), guter freundlicher Support inh. der Community, kommerziell gestützt und gratis. Diese Entscheidung ist nicht mal hautpsächlich bzgl. Froxlor, welches mit obsoleten Funktionen durchsetzt ist. Vielmehr auch, dass du dich gefühlt leider sehr schnell angegriffen fühlst und daraufhin in eine Art Gott-Modus wechselst. Niemand will dich unter Druck setzen, dir deine Arbeit abreden oder sonst was um den Kopf hauen. Würde ich Froxlor nur als Nutzen zum Zweck ansehen, so wäre ich ihne mit der Wimper zu zucken schon lange abgehauen. Ich liebe aber die Anpassungsmöglichkeiten, die Froxlor mir als Administrator lässt. Doch die Probleme die ich sehe habe ich dir ja schon Oben genannt. Wärest du in Linux-Kernel Entwickler, könntest du dich mit der Art sehr gut neben Linus Trovald aufstellen. :-P

Ja gut, dass lass ich jetzt mal so dahingestellt mit den besten Hoffnungen & einem Gedanken, dass wenn hinter einem Projekt ein kommerzieller Druck steht, dies auch priorisierter behandelt wird. Zu dem Bugrequest und den anderen "kritischen" Fragen wird nicht drauf eingegangen?

Hallo, da libapache2-mod-fastcgi in Debian Strech ebenfalls obsolet ist, muss das Cronscript auf das Modul proxy-fcgid angepasst werden FastCgiExternalServer *pool* -socket *socket* -idle-timeout 300 auf <FilesMatch \.php$> SetHandler "proxy:unix:/var/run/php5-fpm.sock" </FilesMatch> Somit ist die PHP-FPM Funktion "Alias-directory of php-fpm" für Debian Stretch obsolet und bedarf keiner weitern Anpassungen. Ebenfall kann FCGID aus Froxlor entfernt werden... Ist sowieso ein veraltetes System, welches durch FPM verdrängt wurde. Generell würde mich mal interessieren, wie es mit Froxlor weitergeht, da es primär ja wohl für Nutime (d00p) entwickelt wurde und nun aufgrund des Datencrashes, wie man es auch hier im Forum mitbekommen hat, schließt. Ich habe die befürchtung, dass Froxlor nicht zu einem Hobbyprojekt verkommt, welches irgendwann in die Ecke getreten wird. Diese Befürchtungen ziehe ich aus den "Altlasten" in Froxlor. - Als Beispiel ist die Distribution Ubuntu Precise. - Seit dem 28 April 2017 wurden schon sämtliche Sicherheitsupdates eingestellt. Diese Spagat zwischen den "Neuen" Distributionen wie Ubuntu Xenial, Debian Stretch und den alten ist auch von den Paketen her mitlerweile so groß, dass man, bevor neue Funktionen implementiert werden erstmal ein Source Code Review macht und die ganzen "Altlasten" rausschmeißt. Das fällt mir auch schon bei der DKIM Funktion auf, die seit Debian Jessie (2015) ohne Workaround für Debian-Benutzer, nicht mehr funktioniert. Die meisten Nutzer von Froxlor werden vermutlich sowieso auf Debian setzen. Da Gentoo mit dem Portage aber auch ziemlich aktuell ist und Ubuntu auf Debian basiert, hätte man somit keine 2 Trees die man Pflegen müsste. Wie das mit CentOS aussieht, weiß ich nicht. Ist für mich eine Randdistribution, so wie Fedora. Für die Konstellation Debian Stretch (Apache2 - PHP-FPM - Postfix - Dovecot) stelle ich gerne meine Manpower zur Verfügung (@d00p ohne Git) Grüße, IAM

Naja, wenn ich immer wieder gesagt bekomme, ich solle ein push-request starten, impliziere ich das aber damit. Datei: scripts/jobs/cron_tasks.inc.http.30.nginx.php Zeile: 761 Alt: $path_options .= "\t" . 'location ~ \(.pl|.cgi)$ {' . "\n"; Neu: $path_options .= "\t" . 'location ~ \.pl|.cgi$ {' . "\n"; Frag mich jetzt bitte nicht, ob das so funktioniert... Der NGINX startet mit dieser Konfiguration, aber testen kann ich es nicht, da wie gesagt SimpleCGI obsolet ist. Kannst du dem was beipflegen oder soll das so bleiben?

Falls es dir in dem falschen Hals kam, bitte ich um Entschuldigung. Ich habe nur keine Lust dir Anpassungen zukommen zu lassen, wo dann immer wieder heißt, besorg dir Git... Bei den "Einzeilern" die ich entdecke denk ich mir dann immer: "Dann halt nicht." Ich werde dir gleich alles weiter zukommen lassen. Könnten wir wieder Back 2 Topic kommen?