rickstinson

So ich habe jetzt noch den Server neu gestartet, waren eh Kernel Updates offen (sonst aber nichts). Nach dem Reboot, gingen alle zuvor angelegten Testkunden. Habe dann noch einen Kunden erstellt, hat auf Anhieb geklappt. Das soll mir mal wer erklären, ist ja kein Windows... Danke für deine Zeit!

danke, auch probiert, auch OK. id www-data uid=33(www-data) gid=33(www-data) groups=33(www-data),9999(froxlorlocal) [...] ,10210(kundeneu) danke, mach ich am Montag, ich werde jetzt mal heimfahren

Sehr gut, weg damit - ist deinstalliert! Habe nochmals einen Kunden angelegt: /var/customers/webs# ls -lha |grep kundeneu drwxr-x--- 4 kundeneu kundeneu 4.0K Sep 1 17:40 kundeneu /var/customers/webs# ls -lha kundeneu total 20K drwxr-x--- 4 kundeneu kundeneu 4.0K Sep 1 17:40 . drwxr-xr-x 167 root root 4.0K Sep 1 17:40 .. drwxr-xr-x 3 kundeneu kundeneu 4.0K Sep 1 17:40 awstats -rw-r--r-- 1 kundeneu kundeneu 2.8K Sep 1 17:40 index.html drwxr-xr-x 2 kundeneu kundeneu 4.0K Sep 1 17:40 kundeneu.at Hier verweigert er aber auch wieder: (13)Permission denied: [client 213.229.46.106:53919] AH00529: /var/customers/webs/kundeneu/.htaccess pcfg_openfile: unable to check htaccess file, ensure it is readable and that '/var/customers/webs/kundeneu/' is executable, referer: http://kundeneu.at/ Habe jetzt noch kurz probiert mit als www-data anzumelden: su - www-data -s /bin/bash Hier habe ich problemlos zugriff auf /var/customers/webs/kundeneu/ Ich verstehe es einfach nicht, sobald ich mit chmod 755 drüberfahre klappt es. Mir geht nur nicht ein wo das Berechtigungsproblem bei neu angelegten Kunden liegt.

Hallo, wir haben unsere Froxlor Installation(Ubuntu 20.04 / PHP-FPM (8.1) / libextrausers) endlich auf 2.0.22 upgegraded. Hat gut funktioniert, bestehende Kunden laufen, aber bei der Neuanlage von Kunden gibt es Probleme. Der Kunde + Domain wird angelegt, die Rechte im Webroot passen meiner Meinung nach: drwxr-x--- 4 kundeneu kundeneu 4.0K Sep 1 12:55 Bei bestehenen Kunden schauts gleich aus: drwxr-x--- 8 kundealt kundealt 4.0K Aug 10 2022 In /var/lib/extrausers/passwd ist der neue Kunde ebenfalls richtig drinnen, die Gruppe scheint auch zu passen: kundeneu:x:10209:kundeneu,www-data,froxlorlocal /etc/nsswitch.conf schaut auch gut aus. passwd: files systemd compat extrausers group: files systemd compat extrausers shadow: files compat extrausers nscd auch neu gestartet. Webhosts von neu angelegten Kunden verweigern alle die Verbindung: (13) Permission denied: [client] AH00529: /var/customers/webs/kundeneu/.htaccess pcfg_openfile: unable to check htaccess file, ensure it is readable and that '/var/customers/webs/sko/' is executable Bei bestehenden Kunden funktioniert alles problemlos. Sobald ich ein chmod -R 755 /var/customers/webs/kundeneu setze, klappt es auch bei neuen Kunden anstandslos. Irgendwo hakt es mit den Berechtigungen seit dem Update, ich bin nur schon mit meiner Weisheit am Ende und finde keinen Ansatz wo das Problem sein könnte. Es wirkt so als ob Apache selbst kein Zugriffsrecht auf den Webroot Ordner hätte, obwohl diese eh mit www-data läuft. Und da es nur neue Kunden betrifft, muss da irgendwo irgendwas nicht passen. ps aux |grep apache root 927828 0.0 0.1 44712 31116 ? Ss 10:46 0:02 /usr/sbin/apache2 -k start Vielen Dank für jede Hilfe! PS: auf einer anderen Froxlor Installaton (die gleich mit 2.x installiert wurde) besteht das Problem nicht.

uff, danke... das war jetzt peinlich

Hallo, eine kurze Frage zur API (2.0.19). Ich würde gerne die erlaubten PHP Konfigurationen setzen. Beim Abruf erhalte ich zB folgenden Wert: ["allowed_phpconfigs"]=> string(5) "[2,3]" wenn ich aber da etwas setzen möchte (zB ID 3,4) bekomme ich als Antwort immer nur "NULL". Beispiel wie ich ein Update mache (die PHP IDs gibt es natürlich) $data = [ 'id' => '16', 'email_imap' => '1', 'email_pop3' => '1', 'phpenabled' => '1', 'allowed_phpconfigs' => '[3,4]' ]; $response = $fapi->request('Customers.update', $data); Vielen Dank!

passt, mach ich!

Kurz gesagt: GEHT: $data = [ 'loginname' => $kundenlogin, 'emailaddr' => $benutzername .'@'.$domain, 'email_password' => $passwort, 'email_quota' => '5000', 'sendinfomail' => 0 . uniqid() ]; // send request $response = $fapi->request('EmailAccounts.add', $data); GEHT NICHT: $data = [ 'loginname' => $kundenlogin, 'emailaddr' => $benutzername .'@'.$domain, 'email_password' => $passwort, 'sendinfomail' => 0 . uniqid() ]; // send request $response = $fapi->request('EmailAccounts.add', $data);

Kundenseite: E-Mail-Kontingent (MiB): 100000 E-Mail-Adressen: 100 E-Mail-Konten: 100 E-Mail-Weiterleitungen: 100 Angelegte Mailadressen: 0 (=unbenutzt) -> Ist nur ein Testkunde zum herumspielen, nichts produktives. System - Einstellungen - Mailserver-Einstellungen - Mailbox-Kontingent: 5000 Wie gesagt: über die normale Froxlor Weboberfläche kann ich problemlos Mailadressen + Konten hinzufügen. Nur über die API nicht, wenn ich email_quota nicht explizit angebe und einen Wert übergebe.

Das ist eh klar Das Kontingent des Kunden ist kein Problem, da ist genug da. Ich kann auch problemlos über die normale Froxlor Adminoberfläche eine Mailadresse anlegen und dann ein Konto dazu anlegen (er nimmt dann auch den Defaultwert 5000) und legt das Konto an. Nur über die API gehts nicht, wenn ich "email_quota" nicht mitgebe. Die Fehlermeldung sagt ja auch aus "sie möchten 0 zuweisen, haben aber nicht genug". Ich möchte ja nicht nicht 0 zuweisen, sondern den default wert und von dem hab ich genug 😉 1.) API Call ohne "email_quota" -> Die Fehlermeldung 2.) API Call mit "email_quota" und entsprechenden Wert in MB -> Konto wird angelegt

Hallo, kurze Frage. Wir haben im Froxlor(2.0.15) unter System - Einstellungen - Mailserver Einstellungen - Mailbox-Kontingent derzeit den Wert 5000 stehen. Im Froxlor selbst kann ich ganz einfach Mailpostfächer anlegen, 5000 wird automatisch vorgeschlagen. Über die API klappt es aber nicht, ein Postfach ohne Quotaangabe anzulegen (da sollte er ja laut Doku den Default Wert nehmen https://docs.froxlor.org/latest/api-guide/commands/emailaccounts.html#emailaccounts-add) Wenn ich also ein Postfach ohne email_quota anlege $data = [ 'loginname' => $kundenlogin, 'emailaddr' => $benutzername .'@'.$domain, 'email_password' => $passwort, 'sendinfomail' => 0 . uniqid() ]; $response = $fapi->request('EmailAccounts.add', $data); bekomme ich folgendes zurück: array(1) { ["message"]=> string(75) "Sie versuchen "0" MB Kontingent zu zuweisen, haben aber nicht genug übrig." } Muss ich jetzt zwingend eine Quota übergeben oder ist das ein Bug in 2.0.15? Danke! LG Patrick

Also ich kann zumindest bestätigen dass es nun mit PHP 8.2 nun auch wieder problemlos läuft.

hatten eben das selbe problem, von mehreren hundert Domains waren ca 50 auf einmal auf Zero SSL umgestellt. 1.) Mit dem registrieren des Accounts bei ZeroSSL hat es dann geklappt, da wurden jetzt Zero SSL Zerts ausgestellt 2.) Das mit dem löschen der Zertifikate in Froxlor und ACME funktioniert wie beschrieben auch, dann sind es wieder lets encrypt Zertifikate. Wirklich spooky. Classic Friday - dachte ich habe endlich mal Zeit um einige Dinge aufzuarbeiten 😉

Danke für deine Antwort. Das Problem hat sich (nachdem es laut den Logs >1 Monat bestand, aber leider nicht aufgefallen ist) von selbst gelöst, nämlich ca30 Minuten nach dem Froxlor Update. Dürfte wohl wirklich mit LE zu tun gehabt haben, jetzt ist wieder Ruhe eingekehrt, nur einmal am Tag ein Reload, sofern niemand was an der PHP Config ändert: Mon Nov 15 00:15:05 CET 2021 update php 8.0 Mon Nov 15 00:15:05 CET 2021 apache reload Wed Nov 17 00:10:17 CET 2021 update php 8.0 Wed Nov 17 00:10:20 CET 2021 apache reload Zuvor wars echt alle 5 Minuten: Fri Nov 12 14:00:04 CET 2021 update php 8.0 Fri Nov 12 14:00:06 CET 2021 apache reload Fri Nov 12 14:05:04 CET 2021 update php 8.0 Fri Nov 12 14:05:06 CET 2021 apache reload Fri Nov 12 14:10:04 CET 2021 update php 8.0 Fri Nov 12 14:10:06 CET 2021 apache reload Fri Nov 12 14:15:04 CET 2021 update php 8.0 Fri Nov 12 14:15:05 CET 2021 apache reload Fri Nov 12 14:20:03 CET 2021 update php 8.0 Fri Nov 12 14:20:05 CET 2021 apache reload Fri Nov 12 14:25:04 CET 2021 update php 8.0 Fri Nov 12 14:25:06 CET 2021 apache reload Fri Nov 12 14:30:04 CET 2021 update php 8.0 Fri Nov 12 14:30:06 CET 2021 apache reload Fri Nov 12 14:35:04 CET 2021 update php 8.0 Fri Nov 12 14:35:05 CET 2021 apache reload Fri Nov 12 14:40:04 CET 2021 update php 8.0 Fri Nov 12 14:40:06 CET 2021 apache reload Fri Nov 12 14:45:04 CET 2021 update php 8.0 Fri Nov 12 14:45:06 CET 2021 apache reload Fri Nov 12 14:50:04 CET 2021 update php 8.0 Fri Nov 12 14:50:06 CET 2021 apache reload Hauptsache es klappt wieder, vielen Dank!

Hallo, irgendwie haben wir ein seltsames Problem. Im Punkt PHP - PHP-FPM Versionen haben wir 3 PHP Versionen konfiguriert. Funktionier auch alles wunderbar. Allerdings werden die PHP Konfigurationen (/etc/php/x.x/fpm/pool.d/*.conf) alle 5 MInuten neu geschrieben und dann das PHP-FPM neugestartet. Das ist irgendwie suboptimal alle 5 Minuten alle gehosteten Seiten für ein paar Sekunden nicht geladen werden können... Jetzt stellt sich mir die Frage wo ansetzen. Warum erstellt mir Froxlor die Config Files alle 5 Min neu? Vielen Dank für jede Hilfe! LG Patrick PS: Gerade auf die letze Froxlor Version upgegraded, hat soweit keine Veränderung gebracht.

Sound great! Good luck + best wishes for your new project!

Danke! Ich schau mal was wir zambringen, ich überlege eben gerade WHMCS einzusetzen, bis auf Froxlor gibt es für alle unsere Produkte nämlich Module, was schon sehr bequem ist Ich werde feedback geben, falls/wenn wir so weit sind, spätestens 2030

Hallo, vor 10 Jahren hat es hier im Forum geheißen, dass wenn Froxlor die 1.0 mit API released, es eventuell mal ein WHCMS Modul geben könnte (um es vorsichtig auszudrücken). Wie hoch stehen die Chancen dafür? Oder soll ich 2030 nochmals fragen? LG

Danke, hat so funktioniert! Falls jemand noch Warnungsmails bei Quotaüberschreitung benötigt, hier mein Setup: vi /etc/dovecot/conf.d/90-quota.conf plugin { quota_warning = storage=95%% quota-warning 95 %u } service quota-warning { executable = script /usr/local/bin/quota-warning.sh user = vmail unix_listener quota-warning { user = vmail } } plugin { quota = maildir:User quota } Das eigentliche Mail wird über dieses Script versandt (chmod 755): vi /usr/local/bin/quota-warning.sh #!/bin/sh PERCENT=$1 USER=$2 cat << EOF | /usr/lib/dovecot/dovecot-lda -d $USER -o "plugin/quota=maildir:User quota:noenforcing" From: support@XXXXX To: $USER Date: `date +"%a, %d %b %Y %H:%M:%S %z"` Subject: Ihr Postfach ist fast voll! Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Ihr Postfach $USER ist aktuell zu $PERCENT% belegt. Bitte archivieren oder entfernen Sie alte, nicht mehr benötige Nachrichten. Andernfalls könnte es vorkommen, dass Sie keine neuen Nachrichten mehr empfangen können! Bei Fragen stehen wir Ihnen unter XXXXX oder unter support@XXXX zur Verfuegung. Ihr Hosting Team EOF

Hallo, so, nachdem ich aus der Dovecot Doku nicht schlau geworden bin, probiere ich es mal hier ? Froxlor läuft bei uns mit Dovecot wunderbar, auch die Quotas funktionieren entsprechend (werden im Webmail/Thunderbird angezeigt, wenn Mailbox voll werden keine Mails mehr angenommen). Passt. Was nicht funktioniert ist, dass ein User eine Warn E-Mail ab 80% bzw. 95% bekommt. In /etc/dovecot/conf.d/90-quota.conf habe ich mal die Quotas festgelegt: plugin { quota_warning = storage=95%% quota-warning 95 %u quota_warning2 = storage=80%% quota-warning 80 %u } service quota-warning { executable = script /usr/local/bin/quota-warning.sh user = dovecot unix_listener quota-warning { user = vmail } } Das oben genannte Shellscript funktioniert auch per manuellen aufruf, da bekommt der per Paramenter angegebene User eine Mail Wenn ich richtig liege, müsste man jetzt noch das Quota Backend festlegen, und genau hier stehe ich an. Dovecot holt sich die Quota ja aus der SQLDB von Froxlor, wie konfiguriere ich das nun richtig? plugin { #quota = dirsize:User quota #quota = maildir:User quota #quota = dict:User quota::proxy::quota #quota = fs:User quota } Danke!! Patrick

Umpf, danke - auf das hätte ich selbst auch kommen können

Hallo, sorry, ich muss das nochmals kurz ausgraben. Habe jetzt letztes Monat bei "E-Mail- & Dateivorlagen" die Mailvorlage für "Hinweismail für Kunden, wenn sie die angegegebenen Prozent" rausgelöscht. Dennoch haben jetzt wieder viele diese E-Mail bekommen: "Sie haben bereits 10605.29 MB von Ihren insgesamt 3000 MB Speicherplatz verbraucht. Dies sind mehr als 90%. " Wie kann ich denn diese E-Mails abschalten? Dachte die Vorlage zu löschen reicht, aber jetzt nimmt er klarerweise die Standardvorlage

damit ist die Warn E-Mail eigentlich für Hugo, da sobald ein Kunde mehr E-Mail Kontingent als Webspace verbraucht, die Warn E-Mail versandt wird ? habe jetzt mal die Mailvorlage gelöscht. Damit sollten die Kunden zumindest nicht mehr mit Warnungen zugespammt werden ?

Danke für die ausführliche Nachricht! Ich weiß eh, im Dashboard stimmt es dann. Aber warum sendet Froxlor dann eine Warnmeldung per E-Mail, dass der Speicherplatz voll ist ? Vor allem dürften die die Variablen für {DISKUSED} und {DISKAVAILABLE} falsch gesetzt sein, oder meine Installation hat da einen Haken "Sie haben bereits {DISKUSED} MB von Ihren insgesamt {DISKAVAILABLE} MB " Im Report berechnet er anscheinend es so: {DISKUSED} = web + mail + mysql {DISKAVAILABLE} = nur web Und damit kommt dann so eine Mail wie: "Sie haben bereits 3939 MB von Ihren insgesamt 2500 MB Speicherplatz verbraucht."

Hallo, sorry für die späte Antwort! Hatte null Zeit, dann wieder drauf vergessen. Jetzt am 1. kam wieder die Mail mit den Warnmeldungen an alle Kunden. In der Mail steht zB folgendes: "Sie haben bereits 3939 MB von Ihren insgesamt 2500 MB Speicherplatz verbraucht." In diesen konkreten Fall hat der Kunde 2500 MB Webspace, und davon nur 10 MB benutzt. -> Da dürfte ja keine Warnung kommen. Der Kunde hat aber, und da liegt der Hund begraben: 5000 MB an E-Mail Speicherplatz, und davon 3939 zugewiesen. Die 3939,36 zugewiesener E-Mail Speicher dürfte für die Webspace Berechnung verwendet werden... Da hats was mit der Berechnung, da ist irgendwo eine Variable falsch gesetzt... Zwei Screenshots auch nur zur Untermauerung. Weißt, was ich mein? LG Patrick