Cool! JFTR, mein »Hilfestellung hierzu dürfte es von verschiedener Seite geben« war als Angebot gemeint, allerdings auch eher im »Standby-Betrieb kann ich sicherlich gut leisten. Allerdings bin ich in der lokalen Community nicht verankert, wäre also 100% auf externe Reports angewiesen«-Modus (»Starthilfeerfahrung« bei FF Nordlippe, FF Nordheide, …).
Ich habe leider keine Elternzeit-Zeit und meine primären Communities haben auch lange ToDo- als auch NiceToHave-Listen. Motivation ist primär »die Leute können ja nix dafür« und »wenn eine 800-Knoten-Domain in NRW implodiert, wird es auch mehr lokale Vorbehalte gegen Freifunk geben«.
Sorry, aber Niersufer hat keinen aktiven Admin mehr, wenn ich das richtig sehe. Also nicht nur eine verloren, sondern 0 (in Worten: Null) übrig. Man kann das schönreden (»ist ja nur einer abgesprungen«), aber schon »mehr schlecht als Recht« stellt die Aussage auf den Kopf, IMHO. Ich bin einer von außen, mir ist das latent egal, aber ein bißchen mehr Realitätssinn vor Ort wäre imho hilfreich. Aber vielleicht übersehe ich aus Außenseiter ja auch was?
Tja, dann müßte »man« (die noch Aktiven) sich mal »im Niersufer« zusammensetzen und eruieren, was man will und was man für erreichbar hält. Mehrere Leute sagen nun »kümmert euch um Geld und Admins«, und bieten übergangsweise Hilfe an — damit es langfristig besser wird, muß vor Ort etwas getan werden (was: s. o.). (Ich sage nicht »gründet einen Verein«, aber eine Klärung mit dem FFRL, ob Ihr als »Ortsgruppe« oder sowas agieren könnt und über den gemeinnützigen FFRL Spenden aquirieren, wäre ggf. sinnvoll.)
Bitte aus gegebenem Anlaß (Meltdown/Spectre) darauf achten, daß jenes Blech moderat frisch ist; bei uns sind gerade 3 Hosts frühverrentet worden, da sie »PCID« nicht unterstützen und damit deutlich zweistellige Performanceeinbußen ins Haus stehen (könnten; benchmarken mit den VMs drauf konnten wir es noch nicht).
Du meinst bei 1. »in der Aachener Infra«? Verstehe ich jetzt nicht so ganz, denn ob ich nun auf unserer Kiste (oder einer VM davon) in Berlin rummache oder auf meinem Server (oder einer VM davon) in Falkenstein oder einer VM einer »unterstützten Community«, ist mir an sich egal — ich muß nur wissen, was ich wie tun kann? Beim Schwenk zurück von L2TP auf fastd allerdings sehe ich ganz klar eine Baustelle, die derzeitigen 3 (FFRL-) VMs dürften bei der im Raum stehenden Knotenanzahl einfach zusammenbrechen.
Ja, aber … hier geht es um »Niersufer«. Keiner muß bei Null anfangen; allerdings muß sich ggf. diese Community erst einmal als solche finden — oder, auch eine Option, die einzelnen tatsächlichen Communites (Grefrath, Kempen, Krefeld, Viersen las ich bislang) lokal in sich gehen und, jeweils als existierende Community, sich ›dezentral‹ um eine Lösung ›nach Niersufer‹ bemühen.
Und ja, je weniger Admins lokal gestellt werden, desto weniger Mitsprache bei technischen Dingen gibt es. Sollte auch klar sein — you get what you pay for, best effort is the basis.
Ja, da stimme ich Dir zu. Ob die geschilderte Wahrnehmung, auf die Du Bezug nimmst, konkret auch so intendiert war, ist dann wieder eine andere Frage. Es gibt auch durchaus einen »fast path« und einen »slow path«, Leute an Setups heranzuführen, und dann kommt es wieder auf Kommunikation und Befindlichkeiten an, wer was wie versteht.
Da hilft in der Tat Mitarbeit von Leuten, die schon ein paar Jahre Serverbetrieb auch als Lebensunterhalt bestreiten — man sieht dann einfach Probleme früher, die, faktisch, durch VMs und/oder Containertechnologie heute niemand mehr durchleiden muß 
(Ich hasse Docker per se; aber Discourse in einer eigenen VM läßt mich heute viel ruhiger schlafen als vormals direkt auf dem Blech ;))
Das geht schon, die Oberfläche ist allerdings textbasiert und die Werte sind mit einem Editor in eine Datei zu schreiben. Dann einmal „puppet apply --verbose $(uname -n).pp“ eintippen und fertig ist die Laube. Äh, das Gateway. (Geht wohl ähnlich mit Ansible oder Saltstack — den Deploymenttools der Nachbarcommunities ;))
Nur sollte ein »Admin« auch in der Lage sein, technisch wie intellektuell, Probleme seines Gateways nachzuvollziehen, zu finden und ggf. zu lösen. Mit »mehr Admins als nötig«, die über einen Click auf Reboot nicht hinauswissen, ist Freifunk auch nicht wirklich gedient.
Jein; das mit dem Basiswissen dürfte stimmen (an »Linux Kommandozeilenritter« und »Grundlagen IP-Routing (v4 & v6)« sollte man ›mit Erfolg teilgenommen‹), und dann muß man bereit sein – wegen Batman-Advanced – ein paar Lerninhalte nach Glacier zu schieben. Mir – unixoider ISPler seit Mitte der 90er – machten initial die Eigenheiten von batman-adv.ko (Routing, ein Layer-3-Feature, auf Layer 2, häh?) die meisten Probleme. Wenn man das einfach als weltweite Bridge mit komischer Syntax zu akzeptieren gelernt hat, rückt auch das Weltbild wieder ins Lot
Aber Freifunk ist nun einmal ein Netzdienst, und ohne ›erweiterte Grundkenntnisse‹ in (IP-) Netzwerken kommt man da imho nicht weit. Der Rest sind DHCP (v4), RA (v6) und DNS. Und irgendein wirrer Dienst für den lokalen Kartenservice.
Ja, aber … wenn Du von Gluon sprichst, ist es nachwievor fastd (vielleicht L2TP) für die Verbindung Knoten<>Gateway, batman-adv.ko für’s Mesh und sonst technisch eher Hausmannskost (auf den GWs)?
Muß man Ansible nicht aktiv von einem ›Ansible-Config-Host‹ starten, daß es die Config auf die Systeme packt? Puppet in der reinen Lehre baut auf dem puppetmaster auf, sodaß alle n (typisch 5-15) Minuten der Regelsatz auf die Server geprest wird: lokale Änderungen haben also eine sehr kurze Lebensdauer (sofern der Admin nichts gegen die Änderungen durch Puppet unternimmt, was typischerweise vom Monitoring dann erfaßt werden sollte). Toll: zentrale Konfiguration und die Sicherheit, daß alle Systeme immer die gewollten Einstellungen haben. Weniger toll: das Admin-Foo um den Puppetmaster (Erreichbarkeit, Zertifikate, generic foo). Kurz: bei einem klassischen Puppet-Setup ist der Systemzustand (nahezu) zu jeder Zeit so, wie in Puppets Konfiguration beschrieben (oder es gibt bei Fehlern einen Monitoring-Event). Bei Ansible hatte ich bislang den Eindruck, daß man immer aktiv die Konfiguration auf die Clients pushen muß?
(Wir nutzen serverless Puppet, i. e. ein Admin aktualisiert das Regelwerk auf dem System per git pull (dies ließe sich per cron automatisieren) und läßt dann puppet apply laufen (dies könnte auch cron machen).)
Nö, denn es hilft nicht.
Siehe oben; Routing kann auch Windows machen, aber die Grundlagen muß man verstehen. Und was NAT ist, warum man das anwendet und wie auf dem Zielsystem konfiguriert. Und ggf. auch was MTU und MSS bedeuten und wie sie zusammenhängen (je nach IPv4-Exit).
Routing und NAT zähle ich zu den IP-Grundlagen. MTU/MSS löst für TCP ein iptables-Eintrag unter Linux (für UDP gibt’s AFAIK keine Lösung), man sollte wissen, wie man dessen Existenz verifiziert.
Schon da; die (OpenWRT-basierte) Gluon-Firmware reduziert die Konfigurationsoptionen auf ein Minimum und bietet mit einem standardisierten Serversetup die Möglichkeit des netzweiten Handovers unter einer SSID.
Hä? Gilt nicht für Gluon, daß ist fire & forget (in einer VM, wo es hingehört, wo es alles machen kann/man es alles machen lassen kann).
Docker bricht beim nächstbesten OS-Update ins Essen (weil … das Overlay-FS nicht mehr existiert; der TCP-Proxy kommentarlos nicht mehr startet; …) — Docker ist eine Hipster-Eintagsfliege. Been there, cursed it. Die Idee ist toll. Die durch fehlende Rückwärtskompatibilität und nichtexistenten Servicegedanken der Projektleiter erzeugten Schmerzen verleiden jedem damit in Berührung gekommenem Echtwelt-Admin die Lust auf mehr.
… und ist definiv keine Lösung für Niersufers Admin-Mangel: auch Docker-Container muß jemand warten (was schmerzlicher ist als bei jeder VM). Von jailed batman_adv.ko mal ganz abgesehen. (Hint: geht nicht.)
(<KopfschüttelnBisSchleudertrauma> Meine Güte. Den ersten, der jetzt hier mit Blockchain ankommt, werde ich tracken und ihm/ihr vor die Wohnungstür kacken. Nicht alles, was ComputerBlöd schreibt, hat was mit der Realität zu tun. </KopfschüttelnBisSchleudertrauma>)