Hallo Liste kennt jemand eine Archvierungslösung für Mails und allenfalls auch andere Dokumente? Es sollten auch Suchfunktionen und ev. Statistiken enthalten sein. Danke für jeden Tipp. Grüsse -- Bernhard -- 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
Bernhard Bühler wrote:
Hallo Liste
kennt jemand eine Archvierungslösung für Mails und allenfalls auch andere Dokumente? Es sollten auch Suchfunktionen und ev. Statistiken enthalten sein.
Das kommt sehr auf deine Bedürfnisse an. - Wie skalierbar soll die Lösung sein? - Wie gut die Suchfunktionen? - Wie hoch die Kosten? - Welche Authentifikation für die Anwender? - Welche weiteren Dokumente sollten es sein? - Welche Sicherheitsfunktionen brauchst du? Es sieht eher danach aus, als möchtest du ein Dokumenten-Management-System, welches auch Emails verdaut. -- 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
Hallo und danke für die Antwort Primär habe ich nur die Aufgabenstellung für Mails. Ich rechne mit einem jährlichen Datenaufkommen von ca. 100 GB, dies auf fünf oder 10 Jahre. Ein Budget besteht aktuell noch nicht, es darf jedoch etwas kosten. Es gibt nur wenige Anwender (einfache Authentifikation) Es werden nur Mails und allenfalls Mail-Anhänge gespeichert (PDFs, Excel, Word-Docs) Der Zugriffschutz wird organisatorisch geregelt, die Daten müssen aber absolut sicher sein (während der Zeitdauer). Ich stelle mir das so vor, dass jede ankommende und ausgehende Mail in ein Archiv aufgenommen wird. Dazu sollen relevante Daten in einer Datenbank mit entsprechender Referenz zur Mail (Sender, Empfänger, Datum, Betrifft, usw.) gespeichert werden. Anhand von Suchkriterien sollen Mails später wieder gefunden und danach zB. gedruckt werden können. Hast du mir einige Tipps? Danke Bernhard Am Sonntag, 28. Januar 2007 13.59 schrieb Sandy Drobic:
Bernhard Bühler wrote:
Hallo Liste
kennt jemand eine Archvierungslösung für Mails und allenfalls auch andere Dokumente? Es sollten auch Suchfunktionen und ev. Statistiken enthalten sein.
Das kommt sehr auf deine Bedürfnisse an. - Wie skalierbar soll die Lösung sein? - Wie gut die Suchfunktionen? - Wie hoch die Kosten? - Welche Authentifikation für die Anwender? - Welche weiteren Dokumente sollten es sein? - Welche Sicherheitsfunktionen brauchst du?
Es sieht eher danach aus, als möchtest du ein Dokumenten-Management-System, welches auch Emails verdaut.
-- 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
Bernhard Bühler wrote:
Hallo und danke für die Antwort
Primär habe ich nur die Aufgabenstellung für Mails. Ich rechne mit einem jährlichen Datenaufkommen von ca. 100 GB, dies auf fünf oder 10 Jahre.
Vertue dich da besser nicht. Die normale Annahme ist, dass die Datenmenge eines Unternehmens sich etwa alle zwei Jahre verdoppelt. Anhand unseres Mailvolumens kann ich das locker bestätigen. Vor etwa drei Jahren brauchte unser Dominoserver etwa 10GB, inzwischen gehen sind wir 90GB zu, obwohl wir die Leute dazu anhalten, Schrott zu löschen. Der Trend geht rasant nach oben.
Ein Budget besteht aktuell noch nicht, es darf jedoch etwas kosten.
Da müsst ihr vorab auswählen, ob ihr selbst Arbeit und Entwicklung in den Aufbau des Archivs stecken wollt oder für eine schlüsselfertige Lösung eine entsprechend größere Investition tätigen wollt. Entscheidend ist auch, wie gut die Suchfunktionen sein sollen. Wenn auch die Anhänge indiziert werden sollen, dann gibt es eigentlich nur die Wahl zwischen teuer: kommerzielle Lösung verwenden unsicher: eine Desktop-Suchmaschine verwenden mühselig: Apache-Suchfunktionen in Verbindung mit Imapserver begrenzt: Cyrus-Server mit Squatter als Volltext-Index ohne Anhänge Daneben gibt es noch Zwischenlösungen wie etwa einen Dominoserver, in dem alle Daten in Lotus-Datenbanken einfließen. Dieser kann PDF, Word, und Excel indizieren. Die Kosten sind für einen lokalen Server nur ein paar hundert Euro. Dafür kann die Datenbank verschlüsselt werden und fein granuliert Zugriffsrechte auf Datenbanken und sogar einzelne Dokumente gegeben werden. Appropos "darf etwas kosten": Schon die Hardware allein für ein paar Terabyte Speicherkapazität kostet schon einiges, die Sicherung des ganzen noch einiges mehr (ihr plant doch ein Backup dieser Daten, oder?). Ich wäre erstaunt, wenn eine Lösung mit einigen wenigen Terabyte für einen vierstelligen Betrag zu haben ist. Ich würde als grobe Gesamtsumme für Hardware + Software + Entwicklung + Anpassung + Schulung grob etwa 10-15 kEuro ansetzen. Ohne irgendwelche Sonderwünsche.
Es gibt nur wenige Anwender (einfache Authentifikation)
Das ist schon einmal gut. Ist das ein rein interner Server oder ist es auch gedacht als Archiv, das jederzeit von überall erreichbar sein soll?
Es werden nur Mails und allenfalls Mail-Anhänge gespeichert (PDFs, Excel, Word-Docs)
Auch das sollte machbar sein.
Der Zugriffschutz wird organisatorisch geregelt, die Daten müssen aber absolut sicher sein (während der Zeitdauer).
Das habe ich nicht ganz verstanden. Wovor sollen die Daten sicher sein? Gegen unberechtigen Zugriff oder vor Zerstörung/Manipulation?
Ich stelle mir das so vor, dass jede ankommende und ausgehende Mail in ein Archiv aufgenommen wird. Dazu sollen relevante Daten in einer Datenbank mit entsprechender Referenz zur Mail (Sender, Empfänger, Datum, Betrifft, usw.) gespeichert werden. Anhand von Suchkriterien sollen Mails später wieder gefunden und danach zB. gedruckt werden können.
Das ist das geringste Problem. Dazu gibt es Lösungen wie Mailinglisten-Manager bzw. deren Webarchive. Das ist sogar mit Cyrus sehr einfach machbar. Obwohl squatter nicht gerade ein Platzsparer ist, eigentlich ist es sogar ein ziemlicher Verwender. (^-^) Wo sind eure Prioritäten? Was muss erfüllt sein? Was darf auf keinen Fall passieren? -- 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
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. Es stehen beide Varianten zur Wahl, schlüsselfertig oder zum anpassen zB. mit Standardpaketen und Ergänzungen individueller Art. 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. 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. 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. 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? Mit Squatter habe ich mich noch nicht beschäftigt. Ich sehe nur in den Kolab-Logs immer die Hinweise auf fehlende Indexe. - Priorität ist eine betriebssichere und stabile Lösung - Suchfunktionen für Headers, Sender, Empfänger, Datumsbereich - Einfaches Wählen der gefundenen Mails und Ausdruck - ev. Userstatistik (wer wie viel Mails und Speicherplatz) - Datenverlust darf niemals passieren! Danke und Grüsse Bernhard Am Montag, 29. Januar 2007 20.05 schrieb Sandy Drobic:
Bernhard Bühler wrote:
Hallo und danke für die Antwort
Primär habe ich nur die Aufgabenstellung für Mails. Ich rechne mit einem jährlichen Datenaufkommen von ca. 100 GB, dies auf fünf oder 10 Jahre.
Vertue dich da besser nicht. Die normale Annahme ist, dass die Datenmenge eines Unternehmens sich etwa alle zwei Jahre verdoppelt. Anhand unseres Mailvolumens kann ich das locker bestätigen. Vor etwa drei Jahren brauchte unser Dominoserver etwa 10GB, inzwischen gehen sind wir 90GB zu, obwohl wir die Leute dazu anhalten, Schrott zu löschen. Der Trend geht rasant nach oben.
Ein Budget besteht aktuell noch nicht, es darf jedoch etwas kosten.
Da müsst ihr vorab auswählen, ob ihr selbst Arbeit und Entwicklung in den Aufbau des Archivs stecken wollt oder für eine schlüsselfertige Lösung eine entsprechend größere Investition tätigen wollt.
Entscheidend ist auch, wie gut die Suchfunktionen sein sollen. Wenn auch die Anhänge indiziert werden sollen, dann gibt es eigentlich nur die Wahl zwischen teuer: kommerzielle Lösung verwenden unsicher: eine Desktop-Suchmaschine verwenden mühselig: Apache-Suchfunktionen in Verbindung mit Imapserver begrenzt: Cyrus-Server mit Squatter als Volltext-Index ohne Anhänge
Daneben gibt es noch Zwischenlösungen wie etwa einen Dominoserver, in dem alle Daten in Lotus-Datenbanken einfließen. Dieser kann PDF, Word, und Excel indizieren. Die Kosten sind für einen lokalen Server nur ein paar hundert Euro. Dafür kann die Datenbank verschlüsselt werden und fein granuliert Zugriffsrechte auf Datenbanken und sogar einzelne Dokumente gegeben werden.
Appropos "darf etwas kosten":
Schon die Hardware allein für ein paar Terabyte Speicherkapazität kostet schon einiges, die Sicherung des ganzen noch einiges mehr (ihr plant doch ein Backup dieser Daten, oder?). Ich wäre erstaunt, wenn eine Lösung mit einigen wenigen Terabyte für einen vierstelligen Betrag zu haben ist. Ich würde als grobe Gesamtsumme für Hardware + Software + Entwicklung + Anpassung + Schulung grob etwa 10-15 kEuro ansetzen. Ohne irgendwelche Sonderwünsche.
Es gibt nur wenige Anwender (einfache Authentifikation)
Das ist schon einmal gut. Ist das ein rein interner Server oder ist es auch gedacht als Archiv, das jederzeit von überall erreichbar sein soll?
Es werden nur Mails und allenfalls Mail-Anhänge gespeichert (PDFs, Excel, Word-Docs)
Auch das sollte machbar sein.
Der Zugriffschutz wird organisatorisch geregelt, die Daten müssen aber absolut sicher sein (während der Zeitdauer).
Das habe ich nicht ganz verstanden. Wovor sollen die Daten sicher sein? Gegen unberechtigen Zugriff oder vor Zerstörung/Manipulation?
Ich stelle mir das so vor, dass jede ankommende und ausgehende Mail in ein Archiv aufgenommen wird. Dazu sollen relevante Daten in einer Datenbank mit entsprechender Referenz zur Mail (Sender, Empfänger, Datum, Betrifft, usw.) gespeichert werden. Anhand von Suchkriterien sollen Mails später wieder gefunden und danach zB. gedruckt werden können.
Das ist das geringste Problem. Dazu gibt es Lösungen wie Mailinglisten-Manager bzw. deren Webarchive. Das ist sogar mit Cyrus sehr einfach machbar. Obwohl squatter nicht gerade ein Platzsparer ist, eigentlich ist es sogar ein ziemlicher Verwender. (^-^)
Wo sind eure Prioritäten? Was muss erfüllt sein? Was darf auf keinen Fall passieren?
-- 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
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
Hallo Sandy Am Mittwoch, 31. Januar 2007 23.24 schrieb Sandy Drobic:
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.
wäre wohl richtig, nur geniessen SATA-Systeme und deren Raids bei mir (noch) kein oder wenig Vertrauen
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. (^-^)
Nein, es sollte wirklich etwas professioneller sein.
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.
Wir haben in kürzester Zeit rund 100 Clients mit einer Datenmenge von rund 35GB (nur aktuelles keine Archive) aus Exchange migriert. Ich bin von der Stabilität von Cyrus bisher sehr zufrieden. Es wäre sicher ein prüfenswerter Weg damit weiterzumachen (ich meine als Archivlösung (wenn sich nichts Besseres bietet).
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.
Werde ich mir ansehen, wobei aktuell die Performance auch ohne Indexe gut ist.
- Priorität ist eine betriebssichere und stabile Lösung - Suchfunktionen für Headers, Sender, Empfänger, Datumsbereich
Das kann Cyrus.
Offenbar habe ich hier einen Mangel an Wissen.
- 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".
So ist es nicht. Ich arbeite schon viele Jahre in der Informatik und weiss gut zwischen Wunschdenken und Realität zu unterscheiden.
Ü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.
Das ist auch die Idee und genügt den Ansprüchen.
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.
Mache ich immer so. Danke für deine Ausführungen und auch die Mühe die du in der Mailingliste immer wieder einbringst. Grüsse Bernhard
-- 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
participants (2)
-
Bernhard Bühler -
Sandy Drobic