Arbeitsgruppe Mailinglisten/Konzept dezentrale Server

Aus Freiheit statt Angst!

(Unterschied zwischen Versionen)
Wechseln zu: Navigation, Suche
(Verfügbare Server - wir haben noch einen :-))
(das sind 2 konzepte, klar getrennt und besser strukturiert)
Zeile 1: Zeile 1:
-
==Alternativkonzept für dezentrale Mailinglistenserver ==
+
= Team =
 +
 
 +
Hierfür ist es sinnvoll, wenn sich ein Team findet, was das Server-Konzept erarbeitet und dann später umsetzt.
 +
 
 +
* [[Benutzer:Cebe|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. --[[Benutzer:Roam|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. --[[Benutzer:Cebe|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. --[[Benutzer:Cebe|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 ... [[Benutzer:Garry|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.
Einige Ortsgruppen oder AK Mitglieder betreiben schon Server auf denen ein Teil der Mailinglisten mitlaufen könnte.
Zeile 42: Zeile 86:
* diskussion[[Bild:At.png]]lists2.ak-vds.de
* diskussion[[Bild:At.png]]lists2.ak-vds.de
-
==== Redundante "HA"-Lösung ====
 
-
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.
+
=== Notfallplan ===
-
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.
+
<s>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.</s> --[[Benutzer:Cebe|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. --[[Benutzer:Roam|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. --[[Benutzer:Cebe|CeBe]] 03:06, 26. Jun. 2009 (CEST)
-
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. --[[Benutzer:Roam|roam]] 14:03, 4. Mai 2009 (CEST)
+
= Verfügbare Server =
-
:: 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. --[[Benutzer:Cebe|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. --[[Benutzer:Cebe|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 ... [[Benutzer:Garry|Garry]] 19:04, 3. Mai 2009 (CEST)
 
- 
-
=== Verfügbare Server ===
 
bitte ergänzen
bitte ergänzen
* lists.ak-vorrat.org, betrieben von [[Benutzer:Roam|roam]]
* lists.ak-vorrat.org, betrieben von [[Benutzer:Roam|roam]]
Zeile 65: Zeile 102:
* Würde einen meiner Mailserver auch mit in den Verbund aufnehmen --[[Benutzer:Cebe|CeBe]]
* Würde einen meiner Mailserver auch mit in den Verbund aufnehmen --[[Benutzer:Cebe|CeBe]]
* Man könnte auch den bereits vorhandenen mail.vorratsdatenspeicherung.de in den Cluster mit aufnehmen... --[[Benutzer:Cebe|CeBe]]
* Man könnte auch den bereits vorhandenen mail.vorratsdatenspeicherung.de in den Cluster mit aufnehmen... --[[Benutzer:Cebe|CeBe]]
- 
-
=== Notfallplan ===
 
- 
-
<s>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.</s> --[[Benutzer:Cebe|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. --[[Benutzer:Roam|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. --[[Benutzer:Cebe|CeBe]] 03:06, 26. Jun. 2009 (CEST)
 

Version vom 01:47, 26. Jun. 2009

Inhaltsverzeichnis

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

  • hamburgBild:At.pngnord.ak-vds.de
  • muenchenBild:At.pngsued.ak-vds.de
  • koelnBild:At.pngwest.ak-vds.de

Zentrallisten ohne Subdomain

  • mlBild:At.pngak-vds.de

nach Funktion

z.B. alle Ortsgruppenlisten auf einem Server:

  • hamburgBild:At.pngog.ak-vds.de

eventuell Arbeitsgruppenlisten auf einem zweiten Server:

  • technikBild:At.pngag.ak-vds.de

Zentrallisten auf anderem Server ohne Subdomain

  • mlBild:At.pngak-vds.de
  • diskussionBild:At.pngak-vds.de

Hauptlisten auf unterschiedlichen Servern

Zur besseren Ausfallsicherheit der Hauplisten:

  • mlBild:At.pnglists1.ak-vds.de
  • diskussionBild:At.pnglists2.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)


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
Persönliche Werkzeuge
Werkzeuge