Aus Freiheit statt Angst!

Inhaltsverzeichnis 1 Team 2 Konzepte 2.1 dezentrale Mailinglistenserver unter einer Domain 2.1.1 In Stichpunken 2.1.2 Details 2.2 Alternativkonzept für dezentrale Mailinglistenserver 2.2.1 Benennung der Listen 2.2.1.1 nach Region 2.2.1.2 nach Funktion 2.2.1.3 Hauptlisten auf unterschiedlichen Servern 2.2.2 Notfallplan 3 Verfügbare Server

Team

Hierfür ist es sinnvoll, wenn sich ein Team findet, was das Server-Konzept erarbeitet und dann später umsetzt.

• CeBe - Konzept und Servereinrichtung (kann einen Server bereitstellen)
• ...

Konzepte

Mir fällt auf, dass es hier eigentlich um 2 Konzepte geht...

dezentrale Mailinglistenserver unter einer Domain

In Stichpunken

bitte ergänzen und diskutieren

• Server laufen unter einer Domain über gleichwertige MX-Einträge
• Solange ein Server noch seinen Dienst tut, sind die Listen verfügbar (natürlich evtl. langsamer aufgrund der Last)
• Die Listen laufen unter der bisherigen Domain und behalten ihre Namen, auch keine Neuregistrierung notwendig. (Umzug on the fly)
• Konfigurationsaufwand bei der Einrichtung nicht unerheblich, was das Konzept des Mitglieder-Abgleichs angeht (aber das sollte uns nicht von irgendwas abhalten ;-) )
• Mailserver könnten bei Fehlconfiguration Mails mit 5xx Fehlernablehnen, das müsste man verhindern oder irgendwie unschädlich machen.
• ...

Details

Eine Lösung mit unterschiedlichen Listen-Adressen ist für "normale" Benutzer nicht unbedingt einfach zu handhaben, zumal auch erstmal erkannt werden muß, daß der primäre Server nicht funktioniert. Außerdem wird dies unter Umständen zur duplizierung der Mails sorgen, da Nutzer erst an den einen, dann an den anderen schicken.

Eine Umsetzung mit zwei (oder mehr) gleichwertigen MXen sollte dagegen technisch mit moderatem Aufwand umzusetzen sein. Voraussetzung dabei wäre aber, daß die Administration der Benutzer nur auf einem System passiert.

Das Master-System sorgt dann in regelmäßigen Abständen dafür, daß Änderungen an den Anmeldungen in den verschiedenen Listen auf das oder die Slave-Systeme übermittelt werden; diese übernehmen die Änderungen in ihren Tabellen.

Wobei dann wieder ein SPoF entsteht. Ich würde eine völlig unabhängige Lösung bevorzugen. --roam 14:03, 4. Mai 2009 (CEST)

Der SPoF wäre aber nur für Änderungen an den Listen zuständig, die übers Webinterface kommen, alles andere würde ich so auslegen, dass jeder Server Änderungen an Listen vornehmen kann und diese entsprechend komuniziert. Das muss sogar passieren, da man sich auch per Mail in Listen ein- und austragen kann. --CeBe 03:03, 26. Jun. 2009 (CEST)

Durch die gleichwertigen MX-Einträge wird zum einen für eine höhere Ausfallsicherheit gesorgt, zum anderen verteilt sich auch die Last relativ gleichmäßig, weswegen die Verteilung der Listen-Mails auch schneller passsieren sollte. Weiterhin läßt sich die Lösung auch problemlos auf weitere Server erweitern, sofern die Scripte entsprechend angelegt sind.

Das sollten wir auf jeden Fall so auslegen, dass es egal ist, welcher Server ausfällt, es also keinen Master gibt. --CeBe 03:03, 26. Jun. 2009 (CEST)

In wiefern der automatische Abgleich der Listenserver auch auf die Mailinglisten selber ausgedehnt werden kann, kann ich im Moment aber noch nicht sagen ... Garry 19:04, 3. Mai 2009 (CEST)

Alternativkonzept für dezentrale Mailinglistenserver

Einige Ortsgruppen oder AK Mitglieder betreiben schon Server auf denen ein Teil der Mailinglisten mitlaufen könnte.

Auf diese Weise

• ist das Risiko des Totalausfalls gering
• ist ggf. der Aufwand zur Totalüberwachung größer
• ist der Ressourcenaufwand pro Server überschaubar
• wird der Zusammenhalt und die Aktivität in der Regio gefördert
• steigern wir die technische Kompetenz der AK-Mitglieder auf breiterer Basis

Hier soll ein Konzept entwickelt werden, wie dies umgesetzt werden kann.

Benennung der Listen

Da die Listen auf unterschiedlichen Servern laufen müßten sie auch unterschiedliche Domainnamen haben. Je nach Anzahl verfügbarer Server würden sich verschiedene Schemata anbieten.

nach Region

z.B. Ortsgruppen nach Region

• hamburgnord.ak-vds.de
• muenchensued.ak-vds.de
• koelnwest.ak-vds.de

Zentrallisten ohne Subdomain

• mlak-vds.de

nach Funktion

z.B. alle Ortsgruppenlisten auf einem Server:

• hamburgog.ak-vds.de

eventuell Arbeitsgruppenlisten auf einem zweiten Server:

• technikag.ak-vds.de

Zentrallisten auf anderem Server ohne Subdomain

• mlak-vds.de
• diskussionak-vds.de

Hauptlisten auf unterschiedlichen Servern

Zur besseren Ausfallsicherheit der Hauplisten:

• mllists1.ak-vds.de
• diskussionlists2.ak-vds.de

Notfallplan

Meine Idee dazu: Auf jedem der Server gibt es eine not-ml@ (oder auch anders zu benennen), die im Normalbetrieb nicht genutzt wird, auf der aber alle ML-Abonenten automatisch auch angemeldet werden. Es steht somit bei einem Ausfall sofort eine Ausweichmöglichkeit zur Verfügung. Ist ne spontane Idee, noch nicht ausgereift, sollte man aber weiterdenken, mein ich. --CeBe 12:32, 28. Apr. 2009 (CEST)

M.E. reicht es, wenn z.B. ml und diskussion nicht gleichzeitig ausfallen können. Im Normalfall reden wir ja nur über ein paar Stunden downtime und selbst wenn wir die ml auf einen anderen Server migrieren würde das nicht länger dauern und wäre zu verkraften. --roam 14:01, 4. Mai 2009 (CEST)

Ziehe meine Idee zurück, viel besser ist System mit gleichwertigen MX-Einträgen, dann bekommen die Nutzer einen Ausfall garnicht mit. --CeBe 03:06, 26. Jun. 2009 (CEST)

Ein paralleler Betrieb von gleichen Listen auf mehreren Servern ist nicht gerade trivial umzusetzen, da die meisten (mir bekannten) Listserver nicht darauf ausgelegt sind ... es müßte zB ein zeitnaher Abgleich von An- und Abmeldungen passieren ... im ersten/zweiten Schritt daher sicherlich nicht empfehlenswert ... soll aber nicht heißen, daß es nicht geht ... nur sollte vielleicht erstmal überhaupt etwas funktionierendes aufgebaut werden, bevor man die "Bells and Whistles" anbaut ... --Garry

mir ist bewusst, dass das nicht trivial ist, allerdings wäre das ne Nette Herausforderung, der ich mich gern stellen würde. Nen Postfix und Mailman aufzusetzen sollte nicht das Problem sein, die wirkliche Arbeit wäre das Sync-Konzept. Ich bin sicher, dass sich da was bauen lässt, was angemessen funktioniert.

Ich sehe auch das Problem, dass wenn wir diese Lösung nicht jetzt bauen, wir ein anderes Listen-Konzept haben, andere Domainnamen evtl. Listennamen sind anders, User müssen sich auf den neuen Listen neu registrieren etc... Warum sollten wir das, wenn es steht und funktioniert wieder über den Haufen werfen? Klar ist die Ein-Domain-Lösung netter, allerdings macht die Umsetzung nur sinn, wenn daraus der Vorteil resultiert, dass sich die Abbonenten um nichts kümmern müssen. --CeBe 02:01, 27. Jun. 2009 (CEST)

Die Migration der User hat bei der Kölner und Bonner Liste gut geklappt. Die User kann man aus dem alten Listserver auslesen und in den neuen einlesen. Die Abonementen habe ausser der Ankündigungsmails davon nichts tun müssen. --roam 17:06, 30. Jun. 2009 (CEST)

Das glaube ich dir, finde es aber schöner, wenn alles unter einer Domain läuft und nach außen so aussieht, wie bisher... --CeBe 15:52, 2. Jul. 2009 (CEST)

Bisher gibt es ja auch schon mehrere Domains. --roam 17:23, 3. Jul. 2009 (CEST)

Verfügbare Server

bitte ergänzen

• lists.ak-vorrat.org, betrieben von roam
• Angebot zum Betrieb eines dedizierten Servers von Garry Glendown
• Würde einen meiner Mailserver auch mit in den Verbund aufnehmen --CeBe
• Man könnte auch den bereits vorhandenen mail.vorratsdatenspeicherung.de in den Cluster mit aufnehmen... --CeBe

• Davor kann ich nur warnen: Wenn aus irgendeinem Grund die Mailauslieferung auf dem Mailinglistenserver verzögert wäre, würde darunter auch die Kommunikation über die @vorratsdatenspeicherung.de-Adressen leiden. Werner 16:07, 29. Jun. 2009 (CEST)