Bernhard Bühler wrote:
Hallo Sandy danke für deine Ausführungen. ich antworte mal dazu direkt hier oben (in der Mail):
Ich habe die Datenmenge auch nur mal "über den Daumen" geschätzt. Es ist klar, dass die Hardware diesbezüglich den Anforderungen genügen muss. Ich denke da an ein SCSI-Raid mit Ausbaureserven.
SCSI im Terabyte-Bereich ist schon recht teuer. Da würde ich eher auf SATA gehen.
Die Suchfunktionen dürften schon so ausführlich wie möglich sein. Eigentlich stelle ich mir eine relationale Datenbank vor, die auch bei grossem Datenvolumen immer noch performant ist und dazu eine Benutzeroberfläche die die erw. Suchmöglichkeiten bietet. Eine gefundene Mail sollte sich dann auch relativ einfach aufrufen und zB. drucken lassen.
Dann wirst du wohl um eine kommerzielle Lösung nicht herumkommen. Es gibt zwar die Möglichkeit, Dokumente über den Volltext-Index zu erfassen, aber wenn du explizite Feldersuche haben möchtest, dann wird es schwieriger.
Domino schaue ich mir mal näher an.
Es ist klar, dass es etwas kostet. Ich meine nicht, dass alles mit Linux immer total gratis sein muss.
Völlig richtig.
Die Daten sollen über den vorgesehen Zeitraum zugänglich (lesbar) sein. Der Zugriffschutz wird organisatorisch geregelt (Zugang zum Serverraum). Ein Backup der Platte(n) muss vorhanden sein.
Entweder ein Spiegelserver oder ein Autoloader/Library. Das möchtest du nicht mehr mit USB-Platten sichern. (^-^)
Ich kenne das Index-System für Cyrus (noch) nicht. Aktuell haben wir einen neuen Kolab-Server in Betrieb, brauchen natürlich relativ viel Platz, da die Mails unkomprimiert abgelegt sind. Persönlich glaube ich im Moment nicht, dass sich die erwarteten Datenmengen auch mit Cyrus speichern und verwalten liessen. Was ich dazu auch vermisse, ist eine einfache grafische GUI um so einige Verwaltungsaufgaben durchzuführen. Nicht alle Leute arbeiten gerne mit dem cyradm auf der Kommandozeile. Weist du hier ein Produkt?
Wenn ich mich richtig erinnere, benutzt Kolab intern Cyrus als Imapserver. Ihr arbeitet also bereits mit Cyrus.
Mit Squatter habe ich mich noch nicht beschäftigt. Ich sehe nur in den Kolab-Logs immer die Hinweise auf fehlende Indexe.
"man squatter" zeigt dir, welche Optionen es gibt. Der Aufruf ist eine einzige Zeile, entweder als cron-Job, oder aus der cyrus.conf heraus. squatter cmd="/usr/lib/cyrus/bin/squatter -r -s user" at=0430 Das scheppert bei mir um 4:30 über alle Datenbanken im Unterordner user.
- Priorität ist eine betriebssichere und stabile Lösung - Suchfunktionen für Headers, Sender, Empfänger, Datumsbereich
Das kann Cyrus.
- Einfaches Wählen der gefundenen Mails und Ausdruck
Der Ausdruck könnte ein Problem, obwohl dies keine Funktion des Servers ist, sondern eine Funktion des Clients.
- ev. Userstatistik (wer wie viel Mails und Speicherplatz) - Datenverlust darf niemals passieren!
Das ist schon eher ein interessanter Punkt. Generell bin ich der Meinung "darf nicht passieren" ist ein Synonym für "keine Ahnung, was ich dann tun soll". Überhaupt keinen Datenverlust kann man, wenn überhaupt, nur sehr aufwendig erreichen. Da würde ich eher ein Konzept aufsetzen, wie ich vom letzten Backup wieder zuverlässig auf den aktuellen Stand komme (wie bestimme ich, welche Mails/Dokumente erneut in das Archiv geschickt werden, nachdem das letzte Backup zur Wiederherstellung verwendet wurde. Es gibt keine Garantie, dass ein defekter Treiber nicht Harakiri mit dem Dateisystem spielt, oder eine unglückliche Kette von Umständen den Server über den Jordan schicken. Besser, sich auf den Katastrophenfall vorzubereiten, ihn zu testen und in einer Anleitung zu dokumentieren. -- Sandy Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org