Mail Backup und Traffic

[ramsys]

Mir sind gerade folgende Punkte aufgefallen (ISPConfig 3.1.11, Debian 9, The Perfect Server Manual):

1) Das Mail-Backup wird ja nur dann bei der Quota-Berechnung berücksichtigt, wenn es unter der gleichen Domain auch eine entsprechende Website gibt. Das ist jedoch nicht zwangsläufig immer gegeben bzw. kann vom Kunden leicht umgangen werden. Gibt es einen Workaround damit der Kunde seinen Speicherplatz nicht sprengen kann?

2) Die Mail-Backups haben im Gegensatz zu den Web-Backups nicht die in ISPConfig konfigurierte Backupzeit sondern sondern werden um Mitternacht erstellt.

3) Der Mail-Traffic wird momentan nicht berechnet, die DB-Tabelle "mail_traffic" ist leer. Die Datei "mail_log_parser.state" wird zwar um 00:00 geschrieben, hat aber nur einen einzigen Eintrag. Gibt es hierfür eine Debug-Möglichkeit?

4) Wenn die Option "Backups löschen wenn eine Domain / Webseite gelöscht wird" deaktiviert ist, müssen die Backups dann per Hand aus der DB-Tabelle und von der Festplatte gelöscht werden?

5) Gilt die vorgenannte Option auch für Mail-Backups, oder werden diese immer beim Löschen eines Postfach automatisch mit entfernt?

6) Bei der Statistik für Mail-Speicher zeigt die Sortierung nach "Verbrauchter Speicherplatz" und "Verbraucht in %" keine Daten an. Die Seitennummerierung ist aber vorhanden.

7) Die Sortierung bei den Statistiken berücksichtigt generell keine Einheiten (KB, MB, GB) sondern sortiert nur nach den angezeigten Zahlenwerten.

 

[florian030]

1) Das Mail-Backup wird ja nur dann bei der Quota-Berechnung berücksichtigt, wenn es unter der gleichen Domain auch eine entsprechende Website gibt. Das ist jedoch nicht zwangsläufig immer gegeben bzw. kann vom Kunden leicht umgangen werden. Gibt es einen Workaround damit der Kunde seinen Speicherplatz nicht sprengen kann?

Nein, die Dateien in den Webverzeichnissen gehören dem jeweiligen Client, die Mails immer dem User vmail.

2) Die Mail-Backups haben im Gegensatz zu den Web-Backups nicht die in ISPConfig konfigurierte Backupzeit sondern sondern werden um Mitternacht erstellt.

Schreib das mal in den Bug-Tracker.

3) Der Mail-Traffic wird momentan nicht berechnet, die DB-Tabelle "mail_traffic" ist leer. Die Datei "mail_log_parser.state" wird zwar um 00:00 geschrieben, hat aber nur einen einzigen Eintrag. Gibt es hierfür eine Debug-Möglichkeit?

Die Mailstatistiken kann man leider nicht wirklich debuggen.

4) Wenn die Option "Backups löschen wenn eine Domain / Webseite gelöscht wird" deaktiviert ist, müssen die Backups dann per Hand aus der DB-Tabelle und von der Festplatte gelöscht werden?

5) Gilt die vorgenannte Option auch für Mail-Backups, oder werden diese immer beim Löschen eines Postfach automatisch mit entfernt?

2x ja

6) Bei der Statistik für Mail-Speicher zeigt die Sortierung nach "Verbrauchter Speicherplatz" und "Verbraucht in %" keine Daten an. Die Seitennummerierung ist aber vorhanden.

7) Die Sortierung bei den Statistiken berücksichtigt generell keine Einheiten (KB, MB, GB) sondern sortiert nur nach den angezeigten Zahlenwerten.

Kannst Du mal in den Bugtracker schreiben. Ich glaube aber, dazu gibt es schon was.

 

[ramsys]

Nein, die Dateien in den Webverzeichnissen gehören dem jeweiligen Client, die Mails immer dem User vmail.

Das Mail-Backup gehört dem User root. Das wird aber auf den jeweiligen Client umgeschrieben, wenn:

• das so in ISPConfig konfiguriert ist
• eine entsprechende Website der Domain existiert
• sich Mail und Web auf dem gleichen Server befinden

500-backup_mail.inc.php:

                        $backupusername = 'root';
                        $backupgroup = 'root';
                        if ($global_config['backups_include_into_web_quota'] == 'y') {
                            // this only works, if mail and webdomains are on the same server
                            // find webdomain fitting to maildomain
                            $sql = "SELECT * FROM web_domain WHERE domain = ?";
                            $webdomain = $app->db->queryOneRecord($sql, $domain_rec['domain']);
                            // if this is not also the website, find website now
                            if ($webdomain && ($webdomain['parent_domain_id'] != 0)) {
                                do {
                                    $sql = "SELECT * FROM web_domain WHERE domain_id = ?";
                                    $webdomain = $app->db->queryOneRecord($sql, $webdomain['parent_domain_id']);
                                } while ($webdomain && ($webdomain['parent_domain_id'] != 0));
                            }
                            // if webdomain is found, change username/group now
                            if ($webdomain) {
                                $backupusername = $webdomain['system_user'];
                                $backupgroup = $webdomain['system_group'];
                            }
                        }

Gerade nochmal gecheckt: Das wird auch so umgesetzt, entweder root oder client.

Eigentliche eine ganz sinnvolle Idee um den Speicherplatz für den Kunden zu begrenzen. Nur kann der Kunde dies elegant umgehen, wenn er einfach die Website entfernt.

 

[florian030]

Das geht aber auch nur, wenn auf dem Server eine Webseite existiert. Bei dedicated mail geht das zB nicht - ich würde mich also nicht darauf verlassen. Web-User haben auf der Platte eine quota (und darüber geht die Berechung), bei mail geht nicht über fs-quota.

 

[ramsys]

Wie macht es ihr es in der Praxis um den Speicherplatz für den Kunden zu organisieren? Ein Backup von 3x 20 Tage pro Website, Datenbank und Mail ist ja schon eine ziemliche Hausnummer was die Festplatte betrifft! Gerade SSD ist da noch ziemlich begrenzt.

 

[ramsys]

Wenn ich das richtig sehe, ist die Einstellung "Use Websites Linux uid for mailbox" auch keine Option, da auch hier die Abhängigkeit zu einer existierenden Website (pro Maildomain) gegeben ist.

 

[florian030]

SSD??? Wer speichert denn Backups direkt auf dem Server? Dann kannst Du das ja gleich sein lassen.

 

[ramsys]

SSD??? Wer speichert denn Backups direkt auf dem Server? Dann kannst Du das ja gleich sein lassen.

Ja klar Wir wollten das erstmal testen und sind dabei über die verschiedenen Möglichkeiten in ISPConfig "gestolpert".

 

[ramsys]

BTW

1) Wenn Backups in ISPConfig gelöscht werden, werden zwar die Dateien auf der Festplatte gelöscht nicht aber das Backup aus Interface entfernt (wahrscheinlich erst beim nächsten Wartungslauf um Mitternacht). Mit der Folge, dass der Kunde die tatsächliche Löschung nicht erkennen kann und den Löschvorgang daher mehrfach wiederholt (ggf. mit Fehlermeldung per E-Mail an den Admin und Anruf des Kunden beim Support).

2) Die Qutowarnung (Speicherplatz) geht vor den Backups raus und berücksichtigt daher nur das Backup von gestern. Ist es nicht sinnvoller, die Berechnung erst nach den Backups durchzuführen?