Grommunio for Synology (G4S)

[FricklerAtHome]

Hab mal mit meiner alten Kopano VM im VMM experimentiert:

Das betrachtete Phänomen scheint ein BUG im VMM zu sein:
Df -h innerhalb der Kopano VM


Ansicht im VMM

Also eine Differenz von fast 22 GB zwischen beiden Anzeigen. In der VM 7,3GB auf der /dev/sda1 genutzt. Angezeigt im VMM 29,46GB.
Im VMM hatte ich zuvor die virtuelle Festplatte von 30 GB auf 50 GB vergrößert. Das entsprechende Resize habe ich aber noch nicht gemacht, deshalb steht als Größe für die /dev/sda1 in der VM noch der alte Wert 28GB.
Danach habe ich einen OVA-Export der KOPA-VM gemacht. Die Größe der OVA Datei liegt bei lediglich 7,9GB. Mit entsprechendem Overhead also exakt beim genutzten Speicher in der VM. Das OVA habe ich dann in den VMM importiert und was ist zu sehen:

Obwohl die OVA VM noch nie gestartet wurde, sind wieder die 29GB ausgewiesen.
Meine GRO-VM läuft unter Proxmox, da kann ich nur die Basis-Größe der vHD sehen und die Größe der Snapshots. Belegungtdaten gibt es nur in der VM mit df -h



Und das passt super zu:

 

[FricklerAtHome]

Abschließend hier noch die beiden unterschiedlichen Auskünfte zu einer virtuellen Synology Kiste (vDSM)

Aus der vDSM


und aus dem VMM

Also eigentlich eine sinnfreie Angabe, bzw. nur die Angabe der bereitgestellten Dateisystem-Größen und nicht die reale durch Daten belegte Nutzung

 

[Andy+]

Das ist schon ziemlich heftig, wie sich das aufbaut mit der Zeit. Ich habe bislang nichts gefunden, was man da tun könnte. Auch ein Defragmentieren gab keine Hinweise. Kann man mit einem Terminal in den VMM, um die Umgebung um eine VM zu sehen, geht sowas?

 

[FricklerAtHome]

ich habe mich da heute nur zum Spass drangemacht. Aber das man über ein Terminal in den VMM kann ist nahezu auszuschließen.
Nach meinen jahrelangen Erfahrungen ist das auch weitgehend sinnfrei. Ich habe bisher nur regelmäßig bei wichtigen VM den real genutzten Speicher mittels PTRG ausgelesen.

Wenn da was aus dem Ruder läuft bekomme ich eine Mail. Das geht auch auf einzelne Verzeichnisse in Linux Maschinen bzw. LINUX VM.

Oder man löst das wie für @491810 vorgeschlagen mit einem selbstgebauten LOG. Im echten Leben haben mich die Diskrepanzen bisher nie beschäftigt. Schlagartiger Mehrverbrauch bei der die Dateisystemgrenzen der VM überschritten werden habe ich noch nie erlebt. Und wie man sieht sind auch für GRO und KOPA meine vordefinierten HD-Größen sehr moderat definiert und bei weitem nicht real ausgelastet. Und nur die reale Datennutzung ist entscheidend.
Bei @491810 ist es offensichtlich ein realer Datenzuwachs im User-Bereich, bei dir und mir aber eher eine nicht deckungsgleiche Ausweisung.
Man muss das eher so lesen: Der VMM sagt das er zur Nutzung 39GB von definierten 40GB zur Verfügung stellen kann. Ob die auch so real als Verbrauch genutzt sind sagt er nicht. Das sagt dir nur df -h in der virtuellen Maschine. Und wenn du die echte Größe der virtuellen Festplatte ermitteln willst, muß du die krypitsch benannte Datei auf dem NAS suchen und dir dessen Größe anschauen.
Da kann ich keinen genauen ORT angeben. Das hängt davon ab wie und auf welchem Volume du den VMM installiert hast.

 

[Andy+]

Ist ja im Moment noch nicht so schlimm, ich seh es aber kommen, dass ich den Speicher im VMM irgendwann erhöhen muss und mit dem

"btrfs filesystem resize max /" das "/dev/sda3"

erweitern muss. Die richtige Kombi habe ich dafür allerdings noch nicht.

 

[Caramlo]

Du kannst zunächst im VMM-Manger den Speicherplatz für die VM erhöhen und dann im Terminal mit Yast die Partition vergrößern.
Einfach im Terminal "yast" eingeben und die CUI öffnet sich. Dann im Partitioner die Größe anpassen.

 

[Andy+]

Das ist natürlich besser...

 

[491810]

@FricklerAtHome kennt die Antwort aus meiner Frage zu dem Thema im Grommunio-Community bereits ... aber alle die mal auf ihrer Festplatte aufräumen wollen sei der Befehl ans Herz gelegt. Der hat aus meinen 135GB auf der virtuellen Festplatte schlanke 81GB gemacht:

grommunio-admin user query maildir | tail -n +3 | xargs -n 1 /usr/libexec/gromox/cleaner -d

Fragt mich jetzt nicht, was der wie und wo macht. Auf die Antwort von Walter (wenn er es weiß bzw. nochmal schaut, wo er es gelesen hat und ob es dort ggf. erklärt wird) warte ich noch. Wer mag kann hier mitlesen:

Grommunio-Community "Disk space increases to over 300GB while 4 mailboxes are less than 20GB in total"

 

[FricklerAtHome]

@Andy+

Hast du schon mal

" for i in /var/lib/gromox/user/*/*; do /usr/libexec/gromox/cleaner -v -d "$i"; done "

laufen lassen? Der löscht alle unnötigen Dateien bzw. ist ein manueller Aufräumer von GRO. GRO löscht nicht alles automatisch, vor allem keine Index- Dateien etc.
Weitere Antworten findest du in CID schwillt an!

Der neue Aufruf-Befehl für den CLEANER stand eigendlich schon im obigen Zitat auf Seite 25, #495

Mit einer Suche nach "cleaner" im GRO Forum findet man auch Hintergrüde

 

[Andy+]

Allerdings bleibt die Diskrepanz, die ich mir nicht erklären kann

Speicherbelegung in Grommunio
localhost:~ # df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda3 60G 33G 25G 58% /

Speicherbelegung im VMM
Anhang anzeigen 80373
vielleicht sinkt diese noch durch diese Bereinigung, mal sehen.

Inzwischen ist die Belegung der VM bei mir minimiert, da muss man wohl etwas Geduld haben

 

[Andy+]

Wenn ich in der VM einen Cronjob anlege, verwende ich doch die "/etc/crontab" oder nicht? Und den cron, wie restarte ich diesen, mit "service crond restart"?

 

[goetz]

Hallo,
kommt darauf an wie Du den anlegst und vermutlich auch was die Grundlage der VM ist. Unter armbian Debian werden die Einträge per crontab -e als root unter /var/spool/cron/crontabs/root abgelegt.

Gruß Götz

 

[FricklerAtHome]

bei mir reicht in der GRO-SUSE-APP lediglich ein Eintrag in der /etc/crontab

Da diese sofort greift gibt es keinen start oder restart. neu editiert neu konfiguriert. Eine # vor einem befehl verhindert den nächsten Start.

 

[491810]

Wenn ich nur mit "crontab -e" rein bin, den Eintrag vorgenommen und mit "wq!" gespeichert und raus bin und danach mit "crontab -l" die crontab wieder aufgerufen habe war sie wieder leer. Am Ende hat er es dann mit "sudo -u root crontab -e" angelegt. Keine Ahnung warum. War ja schon als root angemeldet. Jetzt steht die Crontab.

 

[491810]

Also meine GRO treibt mich (erneut) in den Wahnsinn. Es gibt vier Postfächer. Das Postfach, was die meisten Werbe-Emails erhält, wächst kaum an und die anderen zwei, wo am wenigsen ankommt, wachsen exponentiell an. Ich habe schon bei allen Emailaccounts die Kennwörter geändert. Auch meine Astaro zeigt keinen großen Emailverkehr an. Kann mir mal einer erklären, WIE sich die GRO binnen zwei Tagen ein Postfach von 4,0GB auf 36GB (+32GB) und ein anderes Postfach von 129GB auf 169GB (+6GB) anwachsen lassen kann??? Im Postfach /var/lib/gromox/users/1/1 (169GB) ist mein Hauptpostfach. Hier nutze ich nebst Email auch Kalender, Kontakte und Notizen. Im Postfach /var/lib/gromox/users/1/0 (36GB) nutze ich "nur" zusätzlich den Kalender. Alle anderen Postfächer wird nur Email genutzt. Das Postfach wo die meisten Emails (Werbung) eingeht ist das Postfach /var/lib/gromox/users/0/2 (538MB) - was am wenigstens anwächst. Vielleicht kann mir mal jemand endlich eine Antwort geben, wo und wie ich die GRO (z.B. in der main.cf) zusätzlich absichern kann??? Das wäre toll. So rasante Wachstume hatte ich noch nie. Und erklären kann ich Sie auch nicht. Klar. Ich kann die Postfächer wieder auf die 81GB von vor zwei Wochen zurücksetzen. Das kann ja aber nicht die Lösung sein. Ich mach mir auch keine Sorgen um Plattenplatz. Die virtuelle HDD hat 250GB und das Volumen hat 2TB SSD. Ich kann es also vergrößern. Dennoch. So schnell und stark kann und dürfen doch keine Postfächer ansteigen wenn in den Postfächern kaum was eingeht.

2023.03.19 (11:20)
36,5 ./1
505M ./1
36G ./0

169,5G ./0
538M ./2
169G ./1

2023.03.17 (00:49)
4,5 ./1
504M ./1
4,0G ./0

130G ./0
535M ./2
129G ./1

2023.03.16 (20:51)
1,4GB ./1
505M ./1
922M ./0

120,5G ./0
536M ./2
120G ./1

Ich habe eben mal meinen "daily_purge" laufen lassen - der bereits um Mitternacht lief. Hier mal die Ergebnisse:

18.03.23 00:00
Processing /var/lib/gromox/user/1/0/cid...
Purged 1844 files (1195kB) from /var/lib/gromox/user/1/0/cid
Processing /var/lib/gromox/user/1/0/eml...
Purged 0 files (0B) from /var/lib/gromox/user/1/0/eml
Processing /var/lib/gromox/user/1/0/ext...
Purged 0 files (0B) from /var/lib/gromox/user/1/0/ext
Processing /var/lib/gromox/user/1/1/cid...
Purged 1741 files (1127kB) from /var/lib/gromox/user/1/1/cid
Processing /var/lib/gromox/user/1/1/eml...
Purged 0 files (0B) from /var/lib/gromox/user/1/1/eml
Processing /var/lib/gromox/user/1/1/ext...
Purged 0 files (0B) from /var/lib/gromox/user/1/1/ext
Processing /var/lib/gromox/user/0/2/cid...
Purged 0 files (0B) from /var/lib/gromox/user/0/2/cid
Processing /var/lib/gromox/user/0/2/eml...
Purged 30 files (2529kB) from /var/lib/gromox/user/0/2/eml
Processing /var/lib/gromox/user/0/2/ext...
Purged 45 files (40kB) from /var/lib/gromox/user/0/2/ext

19.03.23 00:00
Processing /var/lib/gromox/user/1/0/cid...
Purged 1386 files (900kB) from /var/lib/gromox/user/1/0/cid
Processing /var/lib/gromox/user/1/0/eml...
Purged 0 files (0B) from /var/lib/gromox/user/1/0/eml
Processing /var/lib/gromox/user/1/0/ext...
Purged 0 files (0B) from /var/lib/gromox/user/1/0/ext
Processing /var/lib/gromox/user/1/1/cid...
Purged 1489 files (966kB) from /var/lib/gromox/user/1/1/cid
Processing /var/lib/gromox/user/1/1/eml...
Purged 0 files (0B) from /var/lib/gromox/user/1/1/eml
Processing /var/lib/gromox/user/1/1/ext...
Purged 0 files (0B) from /var/lib/gromox/user/1/1/ext
Processing /var/lib/gromox/user/0/2/cid...
Purged 0 files (0B) from /var/lib/gromox/user/0/2/cid
Processing /var/lib/gromox/user/0/2/eml...
Purged 20 files (1854kB) from /var/lib/gromox/user/0/2/eml
Processing /var/lib/gromox/user/0/2/ext...
Purged 28 files (27kB) from /var/lib/gromox/user/0/2/ext

19.03.23 11:42
Processing /var/lib/gromox/user/1/0/cid...
Purged 182 files (117kB) from /var/lib/gromox/user/1/0/cid
Processing /var/lib/gromox/user/1/0/eml...
Purged 112899 files (39GB) from /var/lib/gromox/user/1/0/eml
Processing /var/lib/gromox/user/1/0/ext...
Purged 112899 files (125MB) from /var/lib/gromox/user/1/0/ext
Processing /var/lib/gromox/user/1/1/cid...
Purged 168 files (107kB) from /var/lib/gromox/user/1/1/cid
Processing /var/lib/gromox/user/1/1/eml...
Purged 0 files (0B) from /var/lib/gromox/user/1/1/eml
Processing /var/lib/gromox/user/1/1/ext...
Purged 0 files (0B) from /var/lib/gromox/user/1/1/ext
Processing /var/lib/gromox/user/0/2/cid...
Purged 0 files (0B) from /var/lib/gromox/user/0/2/cid
Processing /var/lib/gromox/user/0/2/eml...
Purged 23 files (2611kB) from /var/lib/gromox/user/0/2/eml
Processing /var/lib/gromox/user/0/2/ext...
Purged 33 files (27kB) from /var/lib/gromox/user/0/2/ext

 

[FricklerAtHome]

Wenn man sich das so anschaut hat es zwischen Mitternacht und 11:42 insgesamt 112899 Mail Bewegungen im Userbereich des User 1 gegeben. Also am Sonntag morgen. Das müssen keine frischen Mails sein. Das sind ca 2,6 Mails pro Sekunde als Zuwachs. Ob die nun von aussen kommen oder ein "Anderer Aufräum bzw. Verschiebe Vorgang" dies verursacht musst du klären. Es könnte beispielsweise sein das du um beispielsweise 03:00 Uhr in der Nacht jeweils Sonntags in diesem Postfach Dinge von A nach B verschiebst. Nach den Funktionalitäten von GRO werden die verschobenen Elemente in A aber damit nicht physikalisch gelöchst. Das macht nur der Cleaner.

 

[491810]

Ja @FricklerAtHome. Das komische ist aber, dass ich in dem Postfach in der Zeit 0,0 Emails erhalten habe. Wie sich da 2,6 Mails/Sekunde ergeben ist die Frage. Ich habe auch nachts nichts von A nach B verschoben. Das aktviste Postfach - wo lauter Werbung eingeht - ist "user/0/2". Das hat aber a.) nur 536MB und b.) wächst das nicht so irrsinnig schnell an. Ich habe daher jetzt mal alle Kennwörter geändert. Und als ITler sind die bei mir schon 17 stellig und haben Großschreibung, Kleinschreibung und Sonderzeichen. Dennoch. Komisch. Daher ja auch mal die Frage, wo und wie ich a.) kontrollieren kann, dass die GRO sicher eingestellt ist bzw. b.) wo ich sie weiter "harden" (absichern) kann. In der main.cf sind da ja einige Einstelloptionen.

 

[FricklerAtHome]

@491810
es geht nicht nur ob du Mails erhalten hast, sondern auch ob Mails versand wurden. Erste Auskunft gibt das LOG. Mein Wissen zum "harden" etc. habe ich dir bereits geantwortet.
Evtl. musst du dich ernsthaft mal mit einer sinnhaften Mail-Backup Strategie beschäftigen. Auf meinem Mail-Backup Server läuft gerade eine "Revision", also die Prüfung ob alle gespeicherten Mails noch reproduzierbar sind. Es sind 250.000 Mails im Backup die lediglich 24 GB Datenvolumen fressen. Sie hängen nicht in GRO oder Kopano sondern werden im Minuten Takt mittels IMAP aus diesen System kopiert und die Original MAIL auf KOPA oder CRO wird nach 120 Tagen in diesen Systemen gelöscht. Deshalb sind meine User-Postfächer in GRO / KOPA klein. Die User können jedoch all ihre Mails über das WEB-Interface des MAIL-BACKUP Server weltweit wie den eigentlichen MAIL-SERVER nutzen.
Bei dieser Nutzung ist zu beachten das Kalendereinträge, Termine, Aufgaben nicht per IMAP gehen. IMAP kann nur Mails und Notizen. Also habe ich immer noch eine originale OUTLOOK Instanz die genau für diese Inhalte einmal in der Woche eine "Autoarchivierung" in eine PST-DATEI durchführt. Weitere stumpfe Win 10 VM.
Mit diesen Schritten laufen weiterhin KOPA (VM) und GRO (VM) gleichzeitig ohne eines deiner Probleme. Keiner meiner Serverdienste ist "direkt ohne Spezialwissen" aus dem Internet erreichbar. Mein Heimnetz hat nur einen PORT der Zugriff aus dem Internet auf jedweden Dienst erlaubt (insgesamt 6 auf dem gleichen Port (Reverse Proxy)), und dann folgen regelhaft wie bereits beschrieben weitere Absicherungen der WEB-Interfaces der Anwendungen. Ein Zugriff auf SMTP, POP, IMAP oder sonstigen ausserhalb von HTTPS gibt es bei mir nicht. Und Angriffe darauf sind noch mit FAIL2BAN zusätzlich gesichert. ---- Da kann man lange über eine erfolgreiche Strategie diskutieren. Bei mir ist das seit mehr als 10 Jahren aktiv und hat bisher keines deiner Probleme erzeugt. --- Nur zum Spass: Was kommt denn bei deinem SPAM-Postfach (Werbung-Postfach) an. Bei mir fast nichts da das RSPAMD aus GRO für mich als Privat-Anwender 99% abbügelt. Also nicht mehr als 2 Mails pro Woche bei 5 Usern!

 

[491810]

Dank Dir. Backup und funktionierender Restore ist natürlich auch wichtig (prüfen die wenigsten). Ich verstehe ja nur den Wachstum nicht.
Wenn ich ich kaum Emails erhalte (vielleicht 2-3 Emails am Tag erhalte die keine Anhänge haben) und z.Zt. keine versendet habe frage ich
mich schon, wie die Postfächer genau dieser Konten sprunghaft um 5-10GB ansteigen können binnen Tagen. Daher die Frage nach Hardening.
Da ich die Kennwörter aller Postfächer bereits geändert habe wird es schon mal kein geleaktes Kennwort einer meiner Accounts mehr sein.

 

[FricklerAtHome]

Thema "Hardening":
ich fummel als Laie da nicht rum. Bei mir werden alle Mails primär durch meinen Provider empfangen. Das ist meine "First Line of Defence". Ja mit Viren / Spam und Missbrauchs-Schutz.
Ich hole via fetchmail alle POST beim Provider ab. --- Kein direkter Kontakt meines Mail Servers mit dem gesamten Internet!
Fetchmail sendet bei mir alle Mails an den MAIL-PLUS-SERVER auf der Synology (Second Line of Defence). Der hat wirklich gute und ständig aktualisierte Sicherheitseinstellungen. Mein Trick: Syno-Mail Plus ist so eingerichtet das er die Mails zwar annimmt, weil er sie aber nicht bedienen kann, an den eigendlichen GRO Server weiterleitet (habe ich in diesem Forum auch schon mal beschrieben).
Hierdurch habe ich eine weitreichende Kontrolle über alles was rein und raus geht. Denn mein GRO ist so eingerichetet das es nicht direkt in die Welt versendet sondern auch alle rausgehenden Mail über den Syno-Mail-Plus laufen. Das ermöglicht eine weitgehende Kontrolle über IN / OUT im Bereich MAIL.
Zu "siehe im LOG nach" schicke ich in den nächsten Tagen mal ein Beispiel wie der Konten-Bereich der USER mitprotokuliert aussieht. Du prüfts scheinbar bereits in einer zu kleinen Auflösung. Ich habe 5 Benutzer die sich unter /var/..../user in den Unterverzeichnissen ./0 bis ./4 verteilen. Ich messe im LOG wie sich die Größe gesamt entwickelt. Erst wenn es da Auffölligkeiten gibt schaue ich mir einzelne User raus. Ich poste mal die Tage wie ein LOG bei mir aussieht. --- Wie gesagt bei mit total unauffällig!