Grommunio for Synology (G4S)

[Andy+]

Pop-Up zur Passwortneueingabe

Habe ich manchmal auch auf meinem Android Smartphone. Ich denke, das ist bei schlechten oder abreissenden Verbindungen eine Timeoutgeschichte oder sowas.

 

[491810]

Okay. Bin ich nicht alleine (auf iOS). Das freut mich dann doch. Immerhin muss man die Kennwörter nicht eingeben sondern nur wegklicken. Passt für mich.

 

[Caramlo]

Ich nutze Gro mit einem Ipad und einem Iphone. Musste noch nie das Passwort neu eingeben.

 

[FricklerAtHome]

Bei mir mit GRO folgender Einsatz: 4 x iPhone, 4 x iPad. 2 Phones und 2 Pads nutzen GRO und Kopano gleichzeitig. Anbindung immer über Apple Mail. Aktuelles iOS. Standort Ruhrgebiet. Gigabit Internetzugang via Kabel. Quasi "Feste IP4 Adresse".
Das Problem ist auch bei uns unbekannt!

Alle Clients (ob im Hausnetz oder von aussen) nutzen immer den auch im Internet aufgelösten FQDN für den Connect! In der realen Nutzung bei uns clientseitig reine Apple Infrastruktur, Windows-Outlook nur in dezidierten VM.

 

[FricklerAtHome]

Mal ein anderes Thema: MAIL Backup

GrO bietet ja mit dem ARCHIVE eine integrierte Mail-Backup Lösung an. Hat die jemand von euch im Einsatz?
Ich persönlich nutze ja wie vor langem auch schon mal in einem anderen Thread mit Tosoboso diskutiert hier ein kommerzielles Produkt. Das von GrO eingesetzte Tool ist PILER. In der von mir betreuten Nachbarschaft ( 6 Installationen die mittlerweile von einer Kopano VM auf GrO VM umgezogen sind ) kommt jetzt auch die Frage nach MAIL-Backups auf.
Ich nutze um meine Postfächer klein zu halten, das kommerzielle Ding. ES speichert alle eingehenden und ausgehenden Mails und löscht alles älter als 6 Monaten aus den Postfächern. Deshalb sind meine User Postfächer schmal. Das Ding läuft auf einem anderen Server gleichzeitig zu GrO bzw. Kopano. Für natives Outlook gibt es ein PlugIn und alle anderen User können das Archiv direkt über eine WEB-GUI nutzen. --- Kostet halt, ist aber mir seit vielen Jahren im dankbaren Einsatz.
Jetzt kommt die betreute Nachbarschaft. Die wollen so was ähnliches, aber umsonst. Erste Versuche mit GRO Archive habe ich gestartet. Aber eine echte Empfehlung ist es für mich noch nicht. Da es ein natives Ding in der GrO VM ist muss auch einiges andere betrachtet werden.

Hat jemand von euch damit schon Erfahrungen?

 

[Andy+]

Damit und mit den optionalen Modulen habe ich keinerlei Erfahrung. Mir wäre auch nicht klar, wo im System ich ansetzen sollte.

Backups erfolgen täglich und automatisch per Aufgabenplaner mit einer VM-Exportsequenz, beschrieben in Beitrag #356.

 

[FricklerAtHome]

Nun Backup ist nicht Backup. Sicher kann man täglich die gesamte GRO-Server VM als Backup sichern, aber damit hat man nicht in jedem Szenario eine echte Hilfe.
Die Handys und Pads synchronisieren in der Regel nur über einen bestimmten Zeitraum (bei uns auf den iPhones ist unter den entsprechenden Accounts ein Zeitraum von lediglich 1 bis 3 Monaten eingestellt. Ältere Mails werden schlicht nicht mehr dargestellt / syncronisiert. Wir haben zwar keine Postfachquota's eingerichtet aber der Sync läuft "as designed" nur über diesen Zeitraum.
Man sitzt nur mit Handy oder PAD im Urlaub und plötzlich fragt die Kindergeldkasse nach der Studienbescheinigung aus dem letzten Jahr. An die kommt man dann nicht so einfach heran. Das ist auch in meinem Arbeitsumfeld so wo in einem echten Exchange Umfeld zB. die gelöschen Mails älter als 90 Tage auch automatisch gelöscht werden. Das erhöht die Performance und schont die Resourcen.
Die Mail-Backup Idee ist nun jede Mail gesondert zu sichern und sie nach einem bestimmten Zeitraum auch aus dem aktiven Postfach zu löschen. Outlook macht das mit seinen PST Dateien in der Autoarchivierung. Wir haben aber kein Outlook da reine Apple-Infrastrukur. Früher haben wir das so gelöst das alle Mails die rein oder raus gingen mittel BBC auch an ein spezielles Postfach versand wurden. Das war auf einer WIN Kiste mit Outlook angebunden und alle 3 Monate wurde dieses Postfach in einer PST Datei archiviert. Letztlich war das aber lästig.
Ich habe dann für unsere Kopano Nutzung nach einer Alternative gesucht. Für Kopano gab und gibt es Benno (kommerziell) und direkt als PlugIn im Kopano-Web-Interface integriert, und weitere kommerzielle Programme. Benno sollte ggf. auch mit GRO funktionieren. GRO bietet mit ARCHIVE eine Alternative an, die auf dem OpenSource Paket PILER basiert. Das kenne ich bereits aus Frickeleien zu Kopano Zeiten. Grundlegend ein bewährtes Programm aber so richtig hab ich es damals nicht zum Laufen bekommen, jetzt bietet sich die Change es mit der Integrationshilfe aus GRO erneut zu versuchen. Das ist der Grund für meine Frage.

In meinem Mail-Backup liegen alle E-Mails unseres 4 Personenhaushalt seit 2005 in hochkomprimierter Form. Platzbedarf aktuell knapp 30 GB. Unsere aktiven Mail-Postfächer schwanken mit der Technik zwischen 2 und 4 GB. Sie werden ja automatisch bereinigt. Und jeder von uns kann über das WEB-Interface weltweit auf das Archiv zugreifen. Bei uns sind dort nun ca. 200.000 Mails inkl. Anhänge archiviert. Suchzeit in der Regel kleiner als 3 Sek. Und ja, das Programm sichert seine Datenbestände täglich noch auf einen physikalisch getrennten NAS Bereich.

Bei der GRO Piler Integration interessiert mich die Anbindung an GRO. Technisch möchte ich daraus lernen wie man PILER auch ausserhalb der GRO App (also in anderer VM oder mittels Raspi) einbinden kann. Es innerhalb der GRO-VM laufen zu lassen macht wie richtig beschrieben keinen Sinn wenn man die ganze VM sichert. Läuft es ausserhalb bleibt auch die GRO-VM schön klein. Meine GRO VM hat lediglich 32 GB Festplatte von der gerade mal 16 GB belegt sind. Und sie wächst halt nicht.

 

[Andy+]

Ein solches Konzept macht sicherlich Sinn. Ich dagegen habe kein Archiv, sondern in den Postfächern alle Emails bis zurück ca. bis zum Jahr 2000 und sichere das komplett. Sicherlich, bez. Performance usw. ist das nicht ganz so ideal. Jedoch bezogen auf meine verwendete Sicherung passt das wieder.

 

[491810]

Das glaubt mir jetzt kein Mensch. Gestern Abend war meine GRO noch bei sparsamen 185GB Plattenvolumen.
Jetzt ist sie bei Sage und Schreibe 305GB (!). Wie geht denn bitte sowas??? Kann mir das mal wer erklären?



Ich habe zwar einen Ordner "/.snapshot" entdeckt (warum macht die GRO selbst noch Snapshots und welcher Art?)
gefunden. Aber der ist jetzt selbst auch nicht so groß, dass er diesen rasanten Plattenplatzanstieg erklären würde.



Hier mal der Vergleich vor und nach der Rücksicherung auf den Snapshot von Mitternacht. 100GB in einem 1/2 Tag (?)

Eben um 12:41 Uhr bevor ich den Snap von 0:00 Uhr zurückgesichert habe (=285,87GB):



Und hier der Snapshot von 0:00 Uhr heute Nacht (=174,65GB):

 

[Andy+]

Solche Zuwächse habe ich nicht, aber ich arbeite auch kaum mit Snapshots. Sind das Snapshots vom VMM oder von Grommunio? Ich würde die bis auf einen oder zwei mal alle löschen, ich meine Snapshots schlagen sich schliesslich auch in Inhalten nieder. Ansonsten kommst Du um eine Analyse nicht herum, was sich in Deinen Verzeichnissen so abspielt, diverse Hinweise gibts einige Beiträge zurück bereits.

 

[491810]

Ich nutze nur die Snapshots der Syno VMM. Die speichert die Syno ja aber nicht innerhalb der VM.
Dennoch speichert die GRO im Ordner /.snapshot (bei mir) auch nochmal 10GB an "snapshots".
Ich bekomme zwar auch hier mit Verzeichnisanalyse raus in welchem Ordner der Wachstum ist.
WIESO die GRO aber diesen Wachstum innerhalb eines 1/2 Tages an den Tag legt ist weiter unklar.
Und das irritiert mich. Und eine Antwort auf meine Frage, was und wo man kontrollieren kann, dass
die GRO kein offener SMTP Server ist (meine Postfächer haben alle Kennwörter) habe ich noch nicht.
Die Frage habe ich hier ja mehrfach gestellt und es hat mir bis dato leider noch niemand hier beantwortet.

 

[FricklerAtHome]

Das Eine hat offensichlich nichts mit dem anderen zu tun. Gro läuft auf einer BTRFS formatierten Festplatte (in der Regel /dev/sda3). Das Dateisystem kann selbständig "snapshot" zur internen Sicherheit erstellen. Aber deinen Ordner ./snapshots finde ich bei mir nicht. In keiner Installation. Ebenso diesen mystischen Plattenverbrauch nicht.
Nutz mal Omma Google zu deinen Fragen zum Postfix. Da gibt es einige Tips und Tools mit denen man testen kann. Ich kann dazu nichts sagen weil ich grundsätzlich keinen offenen Port nutze und deshalb auch keine Erfahrung habe. Das Postfix nicht als OpenRelay genutzt werden sollte ist mit der Basis Installation schon gut eingestellt.
Beim letzten Mal ist doch das Verzeichnis einer deiner USER "übergelaufen".
Lass mal den Befehl "du -h --max-depth 1 ./ | sort -h >> verbrauch.txt" im Ordner /var/lib/groxmox/user per cron-job alle 10 Minuten laufen. In der Datei findet du dann wie in einem log was sich an den Ordner-Größen ändert, zwar ohne Zeitangabe aber sollte als erster Schitt helfen

 

[FricklerAtHome]

Mit
echo `date` - `du -h --max-depth 1 ./ | sort -h` >> verbrauch.txt

schreibt es das alles in eine Zeile mit Datum und Uhrzeit

 

[Andy+]

Schau auch einmal, ob ein "df -h" dazu plausibel ist. Da wird bei mir unter "used" weniger angezeigt, als der VMM als belegt ausgibt, da sind bei mir ca. 11 GB Differenz. Das würde eigentlich bedeuten, dass der VMM oder die VM zur Verwaltung noch Speicher belegt.

Wenn ich im WinSCP die verdeckten Verzeichnisse anzeigen lasse, wird auch bei mir das Verzeichnis /.snapshots angezeigt. Das belegt bei mir 2.94 GB.

Abgesehen davon, habe ich noch immer im grössten Userverzeichnis die Verteilung

localhost:/var/lib/gromox/user/0/1 # du -h --max-depth 1 ./ | sort -h
0 ./tmp
60K ./config
430M ./ext
1,3G ./exmdb
16G ./eml
18G ./cid
35G ./
localhost:/var/lib/gromox/user/0/1 #

und was sich im CID befindet, ist für mich noch immer unklar. Ist das eine Art Backup oder laufende Sicherung ... (?)

 

[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!

 

[Andy+]

Bislang nicht, habe ich jetzt mal durchgeführt, brachte ca. 6 GB (!). Zum Vergleich:

localhost:/var/lib/gromox/user/0/1 # du -h --max-depth 1 ./ | sort -h
0 ./tmp
60K ./config
211M ./ext
1,3G ./exmdb
13G ./cid
15G ./eml
29G ./
localhost:/var/lib/gromox/user/0/1 #

 

[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

vielleicht sinkt diese noch durch diese Bereinigung, mal sehen.

 

[FricklerAtHome]

Solche Vergleiche zwischen "df -h" in der VM und der Speicherbelegung im VMM sind üblicherweise nicht statthaft. Vor allem dann nicht wenn "Speicherrückgewinnung" für die VM aktiviert ist.
Mit der Anlage einer VM definiert man die maximale Festpattengröße einer VM. Dieser Platz wird aber üblicherweise nicht fest für die VM definiert, die Hypervisor bilden diesen Platz nur nach der tatsächlichen genutzten Größe ab.
Beispiel: ich teile der VM eine Festplatte von 32 GB zu. Real benutzt die VM jedoch nur 6 GB. Der Hypervisor benötigt also nur 6 GB um die VM laufen zu lassen, bietet aber eine Vergrößerung auf 32 GB dynamisch an. In der VM stehen die ganze Zeit 32 GB zur Verfügung, der Hypervisor des Host-System kümmert sich bei Bedarf um den entsprechenden zusätzlichen Platz. Beendet man die VM prüft der Hypervisor wie viel tatsächlichen Platz nun verbraucht wurde. Er kann dann mittels "Speicherrückgewinnung" unbenutzten Speicher wieder freigeben.
Das Beispiel: VM hat eine eingestellte HDD von 100 GB. Nach dem letzten Start wurden 60 GB genutzt. Im Hypervisor hat die VM lediglich 65 GB benutzt. Jetzt kommt ein großes Update. Der Festplattenverbrauch steigt in der VM auf 85 GB. Nachdem das Update durchgelaufen ist wird er Mehraufwand wieder gelöst und in der VM sind wieder nur 60 GB belegt. Im Hypervisor stehen nun aber 85 GB, denn das war die Größe die genutzt wurde. Mit der Speicherrückgewinnung kann nun der mal benötige Festplattenplatz wieder auf seine jetzige Nutzung zurückgeführt werden. --- Vielleicht hilft hier mal wieder Omma Google: VM dynamische Datenträger etc.

 

[FricklerAtHome]

Bei mir läuft
"for i in /var/lib/gromox/user/*/*; do /usr/libexec/gromox/cleaner -v -d "$i"; done "
als cronjob jeden Monat.
Gerade bei euren fetten Postfächern scheint es ja zu wirken (6GB!). Lief bei mir eher im Hintergrund!

Für @491810 kann als Zuwachslog zur Ursachenfindung folgendes als cronjob helfen:

"cd /var/lib/gromox/user/
echo `date +"%d.%m.%Y"` `date +"%T"` >> /root/verbraucher.txt
du -h --max-depth 1 ./ >> /root/verbraucher.txt"

 

[Andy+]

Hypervisor benötigt also nur 6 GB um die VM laufen zu lassen, bietet aber eine Vergrößerung auf 32 GB dynamisch an.

Nachvollziehbar erklärt, so dachte ich mir das auch. Dennoch, auch wenn nun der gemeinte Vergleich nachvollziehbar hinkt oder nicht statthaft ist, so ist mM. nach doch eine gewisse Relation zueinander erkennbar, zumal die maximale Vergrößerung ja mehr oder minder der Gesamt-Partitionsgrösse des Systems entspricht.

Nachdem ich gestern die 6 GB gewonnen habe, ist die Gesamtinstallation nun grob 38 GB gross statt der vorherigen grob 44 GB. Im VMM werden aber weiterhin, vorher, wie auch nachher und auch nach einem Reboot rund 49 GB als Belegung ausgegeben. Und auch wenn eine Differenz nachvollziehbar als Overhead usw. da ist, ist die Differenz rund 6 GB auf 12 GB angewachsen, wobei die 6 GB eigentlich auch schon viel sind.

Trotz Deiner guten Erklärung kann ich mir nicht vorstellen, dass das plausibel ist. Man könnte meinen, da gibts noch einen Papierkorb, der geleert werden muss.