[tapg] Fragen zum Aufbau des neuen Mailservers

Jogi Hofmüller jogi at mur.at
Mo Sep 23 14:01:28 CEST 2013


Folks,

Vielen Dank für die erste Runde an Feedback (ich hoffe es kommt noch
mehr) :)

Am 2013-09-17 22:31, schrieb Takashi Linzbichler:

> Hm, kann da nur eine ganz persönliche Erfahrung abrufen, ich bin 
> irgendwann von Cyrus (1.irgendwas) abgegangen, weil ich das Teil als
> rel. mühsam zu administrieren empfand und v.a. der Umstieg auf Ver.
> 2.x in 2 Versuchen 2x überhaupt nicht vernünftig klappen wollte...

Die Problematik ist bekannt, und einer der Gründe, warum wir immer noch
Cyrus 2.1 verwenden :(  Von der Upgrade-Problematik abgesehen gibt's mit
dem Teil aber keine ernsten Probleme.

> Was mir allerdings bei diesem Umstieg schon aufgefallen ist, war die 
> Tatsache, dass Citadel (speichert Mails in einer Berkeley-DB) beim 
> Zugriff auf den gleichen Mailbestand (ca. 11k Nachrichten)_deutlich_ 
> schneller war als Dovecot, also die Speicher-/Indizier-Methodik von 
> letzterem einer 'echten' Datanebank doch deutlich überlegen ist. Das
> würde im Rückschluss für mich doch  eher in Richtung Cyrus deuten...

Interessanter Punkt.  AFAIK biete Dovecot aber auch mehrere
Möglichkeiten der Speicherung von Metadaten bzw. der Indizierung von
Mails.  Citadel allerdings ist auf den ersten Blick zu viel für uns ;)

> Ich glaub' übrigens die überwiegende Mehrzahl der User hat wenig Ambitionen, 
> im FS Mailfiles zu editieren ;-)

+1 ;)

Wie Martin schon schrieb, bereiten shared Mailboxen eines der größten
Probleme (nicht nur bei der Migration).  Dieses Konzept ist im Cyrus
zufriedenstellend gelöst, und die neueren Versionen können auch mit
sieve für shared Mailboxen umgehen.  Dovecot wiederum kann "nur"
Submailboxen von User+innen für andere zugänglich machen, und das sieht
sehr kompliziert aus.  Hier müssten wir eventuell "Dummyuser" anlegen,
deren Mailboxen von anderen benutzt werden dürfen ...

> Somit würde ich die 'Krot schlucken' und doch bei ext4 bleiben (bin da 
> bekanntermaßen aber auch eher konservativ/vorsichtig/ängstlich). Ich glaube, 
> bis zum nächsten Upgrade wird das locker reichen und bis dahin wird 
> wahrscheinlich selbst Debian btrfs als Std-FS verwenden 

Was ich vergessen habe ist, dass wir auch eine vernünftige Backup-Lösung
suchen.  Kopieren via rsync etc. halte ich nicht für vernünftig (das
machen wir jetzt, und die Backups sind 1. nie vollständig, und 2.
reichen sie nicht weit zurück).

Weiß jemand zufällig, wie sich LVM bei Snapshots verhält?  Experimente
(vor Jahren) zeigten uns, dass das Filesystem nach ein paar Snapshots
quasi unbrauchbar (weil nicht mehr Performant) wird.  Hier punkten
btrfs/zfs natürlich voll.

> Selbst wenn es auf einer eigenen Maschine läuft würde ich, des einfacheren 
> potentiellen Umzugs wegen, einen Hypervisor darunterlegen...

Danke, ja, sehe ich auch so.

Am 2013-09-18 21:51, schrieb Winfried Ritsch:

> Hatte als ziemlicher wenig zeit-aufwand maessiger Sicht neues 
> Mailserversystem aufgesetzt und geich zu einer Groupwarelösung als 
> Kompaktlösung gewählt, die getestet, gewartet und als Debian PAckete 
> angeboten wird: Kolab

Aha, noch eine Schicht drauf :)

> Haupsächlich: postfix, cyrus und 389directory server für LDAP etc.

Die alten Bekannten :)

> Email, Calendaring, Task Management, Journalling, Contacts, Address 
> Books, Notebooks & Notes

Ist natürlich ein Punkt, den manche Leute eh schon seit längerem
fordern.  Wie sieht das mit administrativem Overhead aus?

Am 2013-09-18 13:42, schrieb otti:

> btrfs ist glaub ich immer noch nicht für den Normalbetrieb freigegeben.
> Falls man das einsetzt sollte man nen Fallback Plan haben falls sich das
> schrottet.

Daran arbeite ich gerade, weil sich mein btrfs am Laptop vor einer Woche
geschrottet hat.  Mittlerweile weiß ich aber viel mehr darüber ;)

> zfs on linux (das kernel modul, nicht die fuse implementierung) geht bei
> meinen tests auch recht zuverlässig. Es gilt aber natürlich das gleiche
> wie für btrfs.

Und noch die Sache mit der Lizenz, und mit der Frage nach der
Weiterentwicklung.  Soweit ich sehen kann, ist btrfs die einzige
sinnvolle Alternative, wenngleich noch nicht ganz so stabil.

Um das alles zusammenzufassen, muss ich den ehem. Bundeskanzler Fred
Sinowatz zitieren:  es ist alles sehr kompliziert. :)

Besten Gruß!
-- 
j.hofmüller

Optimism doesn't alter the laws of physics.         - Subcommander T'Pol

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 230 bytes
Beschreibung: OpenPGP digital signature
URL         : <http://lists.mur.at/pipermail/tapg/attachments/20130923/81a0ae30/attachment.sig>


Mehr Informationen über die Mailingliste Tapg