ich administriere die Server seit 2014 allein obwohl @DSchmidtberg als Co-Admin fungiert
ich bat ihn während meines Studiums mehr (Wartungs-/Pflege-)arbeiten zu übernehmen … ein Server war mal 516 d ohne ein Update. Dass die Webseite/Server/Firmware von FFW verschwunden ist, geht auch auf sein Konto, sowie die verschieden große MTUs auf gleichem Port im Tal
Weitere Einzelheiten kann ich noch hinzufügen
der einseitige Konsens seinerseits war „du »machst« die Server, ich kümmere mich um den Rest“
hier im Forum herrscht von anderen „verantwortlichen“ stille
E-Mails werden nicht kommentiert/beantwortet
im stillen Kämmerlein wird ohne mein und anderer Wissen „umgebaut“
mag sein, dass es öffentlich ist, aber Menschen, die keine Zeit haben treffen beizuwohnen, werden in außen vor gelassen
für 3 Server wurden GRE-Tunnel von FFRL umgebohrt. Diese Server hat @c.epp organisiert
2 wurden aus Gründen abgeschaltet; dies wurde mir mitgeteilt
heute wurde ohne Absprache ein weiterer abgeschaltet
Ich weiß, dass bei FFRL die Maßeinheit für die Abweichung von der Norm Wuppertal heißt. Ich weiß nicht, ob die Skala nach oben offen ist. Ich kann so nicht Arbeiten und die Wolke am Leben erhalten … wenn der Wert der Abweichung nicht mehr messbar ist.
Das Treffen letzte Woche kam kurzfristig zu Stande, wurde aber 3-4 Tage vorher bei euch angekündigt.
Initiator für das Treffen war Freifunk Solingen, die ggf. vor größeren organisatorischen Änderungen stehen und auf der Suche nach Zukunftsperspektiven sich mit den angrenzenden FF Communities austauschen wollten.
Dies habe ich zum Anlass genommen um ein kurzfristiges Treffen zu organisieren. Da es bei FFWTAL aktuell nicht gerade rund läuft haben wir es für sinnvoll gehalten zu fragen ob Personen aus Wuppertal dazu kommen wollen, um gemeinsam über zukunftsfähige Lösungen für die Region zu diskutieren. Das Treffen musste aus Gründen letzte Woche stattfinden.
Hierbei ging es zunächst primär um die Schaffung von organisatorischen Rahmenbedingungen und nicht um den technischen Umbau von FF Solingen oder FF WTAL.
Das Treffen war in Wuppertal, weil es logistisch und ökologisch die beste Lösung für alle war…
Wir warten selbst aktuell noch auf das Protokoll des Meetings.
Weitere werden hoffentlich folgen, an denen die „nicht informierten“ teilnehmen können.
Mir ist es ein großes Anliegen Freifunk in der Region (Krei ME und Umland) mit einem
positiven Image voran zu bringen. Die Zustände in WTAL fördern dies aktuell nicht gerade.
Die Unterstützungsangebote von verschiedenen Seiten existieren weiterhin, wenn wir dir helfen können, sei es bei der Firmware, den Supernodes oder ähnliches, musst du dich nur melden!
Ich schreibe so was, wie Eingangs des Threads doch nicht aus Spaß. Fakt ist: mein Co-Admin macht nichts und andere, die mit-administrieren wollen, verstehen die Doku in Form der Konfiguration nicht.
Ich weiß, danke.
Ich habe dazu schon was geschrieben und füge dem noch dies hinzu: Ich werde keine VMs administrieren, die ich nicht selbst einschalten kann, sowie keine VMs, die nicht im Besitz eines gemeinnützigen Vereins stehen.
FFRL wurde u. A. auch dafür gegründet, um VMs zu besitzen. Das dies nun nicht mehr geht (aus BB-Gründen nehme ich an), wurde den FF-Gemeinschaften nahegelegt vor Ort neue FF-Vereine zu gründen. Dies wurde in W aus Gründen nicht gemacht. Letztes Jahr wurde FFW im /dev/tal e. V. untergebracht, wo es ursprünglich her kommt.
Jetzt, wo ein riesen DoS im FFW war, will man neu Strukturieren ohne das Problem zu verstehen und für die Nutzer zu beheben. Mein Gefühl ist, dass die FF-Gemeinschaft, die die Knoten aufstellt, betreibt, pflegt und wartet, komplett in Stich und Unwissenheit gelassen wird. Deshalb werde ich in diesem Thread Probleme öffentlich dokumentieren.
Oh, klassische Admin-Doku? Im Ernst, wie anders ist Wuppertal im Vergleich zu un-anderen Setups? An Batman v15 habt Ihr Euch, dankenswerterweise, frühzeitig die Finger verbrannt, IIRC setzt aber auch Wuppertal auf Gluon auf?
Na ja, geht. Abgesehen von den Überbleibseln der Domäne Wupper und zwei unterschiedlichen MTUs auf dem gleichen Port plus der Anbindung von fastd über IPv6 sollte alles identisch sein. Die Unterschiede sind mit einer kleinen Transferleistung von jedem administrierbar, der Ahnung von der Materie hat.
Ich nenne das konsequentes Benutzen und Debuggen. Wenn die Entwickler sagen, dass bat15 der nächste Schritt ist und dieser auch noch 10 Jahre anhält, dann benutzt man den nächsten Schritt, wenn man gerade eine Wolke neu einrichtet.
Korrekt. Ich frage mich also wirklich, was ich noch dokumentieren soll.
Das ist aber eine schöne Umschreibung für „mittel- bis langfristig nur solche im Besitz des FFRL“
Denn so ziemlich alle anderen mir bekannten Freifunk-Vereine besitzenkeine Gemeinnützigkeit und die gemeinnützigen Hackspaces kommen regelmäßig in Deubels Küche (F, DA, um Beispiele zu liefern), wenn sie Bleche mieten/kaufen auf denen die Supernodes laufen.
Umgekehrt ist „Supernode-Verleih“ beim FFRL ein Auslaufmodell bei dem das Kehrlicht schon ziemlich unangenehm flackert.
Will sagen: Ich sehe für das von Dir angestrebte Modell keine Option.
Du sagst damit, dass Du die Funktion gern mangels Alternativen zeitnah an andere übergeben möchtest, korrekt?
OT, aber habe ich was verpaßt und dem FFRL wurde die Gemeinnützigkeit zwischenzeitlich wieder erteilt?
Insofern stimmt ich Dir zu, @adorfer, daß die Festlegung auf nur durch gemeinnützigen Verein besessene VMs auf mehrfacher Ebene problematisch ist: Einerseits durch den grassierenden Vereins-Auflösungsstoß durch die Finanzämter, die – korrekterweise – Freifunk direkt nicht in der AO finden und erteilte Gemeinnützigkeiten kassieren, andererseits durch den Zwang gemeinnütziger Vereine, ihre Mittel nur satzungsgemäß zu verwenden — und da Freifunk – politisch gewollt – nach wie vor nicht gemeinnützig ist, wird die Luft hier sehr, sehr dünn.
Somit ist quasi Freifunk Wuppertal ein Beispiel dafür, was absehbar auch für andere Freifunk-Communities mit Infrastrukturbedarf zum Problem werden kann.
Kurzum:
Das macht voll und ganz Sinn, …
… dies aus den genannten Gründen eher weniger.
Hmm, vielleicht sollten sich die verschiedenen Einzelkämpfer mal zusammentun und quasi ein FF-Admin-Kollektiv bilden. Denn eigentlich rennt so ein Netz ja doch ganz passabel vor sich hin, wenn einmal eingerichtet und das Wachstum überschaubar ist. Und Skripte zur Unterstützung gibt es dankenswerterweise heute auch — was wiederum die Abweichungen minimiert. Derlei setzt aber eher voraus, daß keine Vereine im Spiel sind, denen die Server/VMs gehören — sonst wird das mit Haftung ggf. unerquicklich.
Aktuell sieht zumindest das Reporting (das was die Knoten so per respondd zu sagen haben) danach aus, als ob am Freitag 23.08.2019 gegen 16h eine Topologie-Änderung vorgenommen wurde/eingetreten ist:
Was zumindest mir auffällt ist, dass es nach respondd-Daten zwei Gateways gibt, nach „batman gwl“ jedoch nur einen. (Zumindest fällt mir für so einen Effekt gerade plausible Erklärung ein)
Bisher hatten die Wupper Server eine MAC aus dem Bereich 04:be:4a:de:fe:xx und Radevormwald den Bereich 04:be:4a:de:ff:xx genutzt.
Das Wuppertaler GW für Rade ist unter 04:be:4a:de:fe:60 auch noch da und verteilt IP Adressen im Rader FF Netz. Durchsatz ins Internet geht aber gegen null
Danke fürs Überwachen. Ich bin z. Z. im Ausland und habe die Wolke gerade nicht auf dem Schirm/Radar. nf_conntrack ist überlaufen. K. A. warum die Verstellung auf eine längere Tabellengröße nach dem Reboot nicht griff.
21,0.: Reboot
24,2.: Laut Euren Quellen brach das Ganze ein
28,5.: Fehler hier gemeldet (zukünftig gerne in einem neuen Thread; a la „»Datum« »Problem«“)
29,0.: Fehler gelesen und behoben; nf_conntrack auf Korrektheit überprüft
Im Ernst, wie anders ist Wuppertal im Vergleich zu un-anderen Setups? An Batman v15 habt Ihr Euch, dankenswerterweise, frühzeitig die Finger verbrannt, IIRC setzt aber auch Wuppertal auf Gluon auf?
