Ich ahnte doch, dass es den Nachwuchs-Admins gelingt, den Thread früher oder später zu entern. Gern auch in Kombination mit persönlichen Angriffen. (Wo der Funke bei „Jomla vs. Typo3 vs Wordpress“ vorher schon nicht überspringen wollte.)
Wenn wir heute mehrere Admins im Bereich Eulenfunk haben, die vor 2 Jahren noch nie ein Linux installiert hatten (nichtmal ein Mint auf einem Laptop), dann würde ich die Grenze für „mangelndes Basiswissen“ sehr gering ansetzen und eher ein Problem bei denjenigen sehen, die sich nicht auf Neulinge einstellen mögen und diese FREUNDLICH dort abholen, wo sie stehen. „Du bekommt schon mit, dass“ ist da vermutlich der weniger geeignete Ansatz.
Interessierte müssen bereit zum Lernen sein (und nicht nur dazu, Erklärungen zu finden, warum sie etwas NICHT lernen möchten/können).
Und Wissensvermittelnde müssen bereit sein, Dinge wirklich zu vermitteln (und nicht nur, Erklärungen zu liefern, warum sie nun heute oder dieser speziellen Person nichts beibringen möchten.)
Deshalb habe ich ja auch davor geschrieben, „Bitte nicht falsch verstehen“.
Ich erlebe jeden Tag solche Denkweisen bei Windows-Admins und ich mache mir da teilweise ernsthaft sorgen, wie deren Berufsaussichten in möglicherweise 10 Jahren aussehen.
Wenn es zu angreifend war, entschuldige ich mich für die Ausdrucksweise.
@ErwinLindemann hat im Abschnitt „Was aus meiner Sicht passieren muss“ klar seinen Anspruch zum Ausdruck gebracht und das verstehe ich als „Bitte ein fertig Produkt liefern, deren Funktionsweise ich nicht verstehen muss.“
Das ist aus Sicht kleiner Communities durchaus nachvollziehbar und ich wäre der Letzte der gegen eine Art „Community Selfservice Portal“ was einzuwenden hätte.
Wir reden hier aber von der technischen Ebene darunter. Deren Skalierungssprobleme, sowohl technischer als auch personeller Art, müssen zuerst einmal behoben werden. Und eben darum geht es ja primär in diesem Thread.
Ja, ich habe Jehova… äääh… Windows gesagt. Irgendwer muss das ja auch machen.
Benutzeroberfläche oder Konfigurationsdatei oder was auch immer, ist mir im Grunde auch egal. Der Punkt „…deren Funktionsweise ich nicht verstehen muss“ trifft es aber irgendwie. So wie es im Moment läuft, muss man ja nicht nur die Funktionsweise eines Systems verstehen, sondern die von etwa zwei Dutzend komplett unterschiedlichen, um überhaupt nur zu wissen, aus welchen Komponenten man es zusammenstellen will, und dann weiß man noch nicht, wie. Meinen Respekt vor denen, die das können, aber deren Zahl wird sich aus genau diesen Gründen nie signifikant erhöhen. ich wäre durchaus bereit, mich da ein wenig einzuarbeiten, aber ich habe auch noch eine Familie, einen Beruf, ein Ehrenamt, … , es bleibt also nur ein begrenztes Kontingent an Zeit übrig.
Deshalb ja mein Ansatz, vielleicht mal nicht das Rad zum xten Mal neu zu erfinden und alles anders zu machen als die Community nebenan, sondern mal etwas Zeit in Standardisierung zu investieren, damit zukünftig mehr Leute mitmachen können.
Man bräuchte die einzelnen Freifunk-Komponenten als Baukasten den man „nur“ noch konfigurierten muss.
Nimmt man als Beispiel die Routerfirmware: Bis man einmal eine funktionierende Buildumgebung hat… da ist man mehr mit beschäftigt als das Bauen selber.
Vielleicht wäre da eine Cointainerumgebung wie z.B Docker sinnvoll. Da hat man schon mal die einzelnen Grundvoraussetzung passen und kann sich der Konfiguration und betrieb konzentrieren. Tritt ein Fehler auf Hamm man den an der gemeinsamen Basis fixen und zieht den Container neu.
Gibt ja einen guten Grund warum das auch von den Großen genutzt wird. Das skaliert ja ganz ordentlich und bildet immer konsistente Umgebungen.
Wie oft ich gehört habe bei „mir“ läuft der Build aber mit den gleichen Parametern durch. Ursache war oft irgendeine fehlende Abhängigkeit in der Buildumgebung.
Tooldiskussionen sind auch immer gut, wenn es darum geht, in der Sache nichts tun zu müssen.
Wie schon weiter oben erläutert, Freifunk ist dezentral.
Die Probleme des Niersufers wären auch mit und ohne Docker oder mit und ohne Windows-Like WebUI nicht anders. Es gibt doch inzwischen so ziemlich HowTos auf jeder halbwegs geeigneten Orchestrierungsplatform. Nur zu jeder braucht es wieder Leute, die das dann auch tun.
Es geht es meiner Ansicht nach völlig daran vorbei, was dort dazu führt, dass sich keine Admins finden, die zum Freifunk bereit wären. Zumindest dachte ich, dass wir bei der Bestandsaufnahme inzwischen wesentlich weiter fortgeschritten wären.
Bereit wären viele, in der Lage wenige. Wieso, habe ich versucht zu erklären. Wenn keine Bereitschaft da ist, an der Stelle anzusetzen, also die Komplexität der Aufgaben zu vermindern, werden sich auch weiterhin zu wenige Admins finden. Freifunk ist dezentral, super. Es wird daran irgendwann sterben, immer noch super?
Es gibt mehrere Ansatze, genau dieses zu tun.
Eines davon ist das Wiki der FFNordler zum Thema „Gateway aufsetzen“ (was aber den FFRL-Exit für IPv6 nur schwer verdaulich thematisiert), ein anderes ist das Eulenfunk-Kochbuch (damit sind Leute zu Freifunk-Domain-Admins, und zwar zum Hauptadmin ihres Bleches geworden, die bis dato nur Windows-Domain-Kram in BüroIT gemacht haben. Oder als „Ich-nur-Windows-User“, jenseits der 50, beruflich im Hotelfachgewerbe unterwegs waren.) Und dann gibt es noch die Ansible-Scripte der Münsteraner, die meines Erachtens noch einfacher sind.
Will sagen: Es mangelt derzeit nicht an Kochbüchern, Scripten und Tutorials.
Es braucht dafür aber eben Menschen, die lokal andere Menschen an die Hand nehmen. Und Dinge ausprobieren.
Und sich auch dann auf Tutorials „not invented here“ einlassen. Denn ein Haar findet man immer in der Suppe. Und wenn man dann sagt „schön und gut, aber so machen wir das nicht“, dann hat man eben wieder Tooldiskussion um Orchestrierung, Monitoring, Virtualisierung und Firmwarebuilder.
Will sagen: Das Problem der Kochbücher ist, dass sie „auf freiem Feld“, oder bei „alles abgebrannt“ gut funktionieren.
Wenn aber nur noch ein „alt-Admin“ da ist, der gerne „seine Note mit herüberretten möchte an die Nachfolger“, dann wird es schwierig. Sowohl von der Terminfindung (der alte hat häufig kaum noch Termine frei), als auch technisch (der alte ist mit dem Kochbuch unzufrieden. Seine Änderungswünsche sind aber eben nicht so dokumentiert, dass die Neuen das verstehen würden.)
Von daher braucht es wahlweise einen weisen, abgeklärten Altadmin, der loslassen kann und seine Nachfolger auch Dinge tun lässt, die er persönlich für falsch hält.
Oder man forked „völlig unabhängig“.
Und wenn beides nicht geht, dann muss man warten, bis die Hütte komplett abgebrannt ist, damit man neu starten kann.
off topic, aber das ist einer der grossartigsten Threads im ganzen Forum.
Ich habe durch diesen sehr viele, bisher mir noch unklare, technische Zusammenhaenge verstanden und auch die Vorschlaege zur Nachwuchsfoerderung bzw. deren Problematik ist die beste Sammlung, die mir bisher untergekommen ist.
Diese sind in ein paar Postings verteilt und durch die unterschiedliche Sichtweise sehr aufschlussreich und regen maechtig zum Nachdenken und aktiv werden an.
Danke an alle Schreiber hierfuer.
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>)
als einer der „Väter“ des Niersufers möchte ich mich auch mal kurz zu Wort melden.
Das Niersufer besteht aus drei Netzen, die für sich getrennte Meshs sind. Die Niersufer-FF-Karte zeigt die Nodes aller Netze - es ist also keine Riesenwolke, sondern sind drei Wolken.
Die Entscheidung aus Willich kann ich prinzipiell nachvollziehen, allerdings ist das Problem hausgemacht. Willich war von Beginn an nur Nutzer und vielleicht Multiplikator. Außer dem Aufstellen von Nodes kam aus Willich meines Wissens nach keine aktive Mitarbeit am Freifunk, wir waren nur „billiger ISP“ für ein freies Netz.
Ich bin seinerzeit selber aus dem Adminteam raus, weil sich in meinem Leben und damit bei meinen Prioritäten einiges geändert hat. Der ein oder andere wird Dinge wie gesundheitliche Veränderungen, aktivere Lebensweise, usw. noch mitbekommen haben. Mittlerweile habe ich mich gewichtsmäßig quasi halbiert. Dazu ist inzwischen noch eine Trennung nach fast 20 Jahren gekommen und es werden vermutlich ein paar weitere Veränderungen (Job und evtl. Lebensmittelpunk) folgen. Ich für meinen Teil finde den FF-Gedanken immernoch klasse und wäre auch bereit wieder Teil eines aktiven Admin-Teams zu sein, aber nicht als einer von zwei oder drei Admins für ein Netz dieser Größe, wenn aus den teilnehmenden Communities nichts kommt, außer Gejammer wenn mal was nicht geht. Dafür ist mir meine Freizeit einfach zu schade.
Klares jain
Ansible ist typischerweise Clientless (brauch nur ssh-Login und etwas python), also muss es auf dem „Masternode“ es aufgerufen werden.
Aber normalerweise ruft man ein sogenanntes Playbook mit dem globalen „Inventory“ (das alle Hosts und Gruppen) enthält auf, und in dem Playbook ist dann definiert welche Gruppen was bekommen (inkl. Abhängigkeiten wie nicht mehr als x gleichzeitig usw.).
Das ruft man immer auf, wenn sich etwas in der Konfiguration geändert hat => Danach ist bei allen Hosts die Konfiguration wieder up2date.
(Und da es zentral läuft, kann man auch definieren, wieviele Hosts bei den Fehler auftreten ok sind, so dass eine (erkennbar, z.B. Dienst startet danach nicht mehr) fehlerhafte Konfiguration nicht auf alle Systeme ausgerollt wird.
Gibt mit ansible Tower auch ein Produkt, das das laufen lassen automatisiert.
Ein Abgleiten in einer Tooldiskussion wird dem Niersufer (und anderen Domains mit Adminmangel) nicht weiterhelfen.
Nach meiner Erfahrung ist Nutzung von Orchestrierung in der Regel sogar extrem kontraproduktiv.
Es es ist für Nachwuchs-Admins in der Regel abschreckend, weil es eventuell zusätzliche Hürden aufbaut.
Zumal man zumindest Eingangs nur mit 1-2 VMs „pro Typ“ (Supernodes, Firmwareserver, Webserver) konfrontiert ist.
(Und diejenigen, die es sowieso schon können und ihr Handwerk verstehen, denen gelingt mit ihrem bevorzugten Werkzeugkasten alles, inkl. dessen was eigentlich™ nicht geht.)
Aber wenn ihr eine Tooldiskussion führen möchtet: Tut das, aber wundert Euch dann nicht, warum viele Leute glauben, es handle sich um Rocket-Science.
Klar, man kann mit der Tooldiskusion aufhören und weiter hoffen das sich ein paar allwissende Superadmins melden um die Domain zu übernehmen.
Ich denke aber das ist der falsche Ansatz.
Schön wäre es wenn man potenziellen Admins für eine neue bzw. eine „sterbende“ Community ein funktionierendes Standardsetup an Supernodes, Firmwareserver, Webserver usw an die Hand geben kann was ersteinmal funktioniert und auch von einer breiteren Basis supportet werden kann. Dann können die neuen langsam mit reinwachsen und in einer funktionieren Infrastruktur lernen.
Anders herum kann die Motivation schon sehr leiden.
Warum im Konjunktiv?
Gibt es ja mehrere.
Und sogar Leute (aus 3 verschiedenen Richtungen, mit unterschiedlichem Hintergrund), die potentielle Bereitschaft erklärt haben (entweder hier im Thread, in den üblichen Mumble-Runden etc), potentielle Interessierte an die Hand zu nehmen.
Nur wenn es dort lokal keine Menchen gibt, die dort lokal Fluchtgeschwindigkeit erreichen, um Teile (oder auch das Ganze) auf neue Beine zu stellen: Dann passiert eben nichts.
Es hängt meiner Meinung nach nicht an Tools, sondern an Leuten mit Interesse und einem gemeinsamen Plan.
Gemeint war schon das ein wenig utopische Szenario die Niersufer-Domäne zu „schlucken“ und alles auf unsere Infrastruktur umzuziehen. Das wäre dann vom Arbeitsaufwand her nach der initialen Umstellung mehr oder weniger ein Selbstläufer, weil unsere Domäne konkret so entworfen wurde, dass geographisch disjunke Segmente beliebig hinzugenommen werden könnten, ohne die anderen zu beeinflussen.
Habe aber bereits schon erklärt, dass das aus wirtschaftlichen Gründen nicht tragbar ist. Wir zahlen aktuell alles bis auf FFRL-Backbone selber… Wobei das halt auch gelogen ist, denn natürlich meine ich damit eigentlich unsere Spender
Mein Ziel wäre eine ähnlich nachhaltige Infra in Niersufer hochzuziehen, bzw. erst einmal zu schauen inwiefern das mit den vorhandenen Ressourcen möglich ist. Werde mich in der nächsten Zeit hoffentlich IRL mit den Kollegen aus Niersufer austauschen.
Orchestrierung (ich würde ja initial schon eine »configuration database« gutheißen) klingt erst einmal mächtig mächig, und wenn man das erste Deployment hinter sich gebracht hat, auch gar nicht mehr nach Mondlandung und so weiter. Es gibt, denke ich, zwei ›Schulen‹; die, die Angst haben, was kaputt zu machen sowie die, die ›endlich‹ was erreichen möchten…
Aber im Grunde führt diese Diskussion hier zu nichts, also lassen wir’s besser.
Full Ack.
Übergangsweise lassen sich »eine Handvoll VMs« bei uns unterbringen (wenn das denn hilft), aber dauerhaft muß sich Niersufer halt auch irgendwie selbst finanzieren. Auch wir operieren auf Spendenbasis mit gewissem Lokalbezug
Das war bisher bei allen, die sich so gemeldet haben.
(Ob es gut oder schlecht ist, dass man „Freifunk-Domain as a Service“ nirgendwo buchen kann, darüber haben wir -wenn auch unter anderen Vorzeichen- bereits 2016 vortrefflich debattiert.)
So sehr sich das Konzept evtl unterscheidet, der verschiedenen Hilfsangebote, die im Raum stehen, z.B.
Bringt mir Signkeys, Zugang zum passenden DNS, ich sauge das mit meinen Tools/meiner Infra kurzfristigig komplett auf, in einem Abend (YMMV). Im zweiten Schritt besorgt Ihr Blech, dann wird das herübergeschoben, abgekoppelt und ihr bekommt erklärt, wie das Ding funktioniert und dann macht ihr selbst.
Bringt mir Signkeys und Zugang zum DNS. Ich habe hier noch Blech. Ich setze das geschwind nach Schema F auf und ihr übernehmt das Zeug dann mit einem noch gründenen Verein oder notfalls privat.
Wir setzen uns zusammen wir bauen gemeinsam an einem Wochenende auf hier überzähliger Infrastruktur. Dabei lernt ihr. Ihr übernehmt das/die Bleche (siehe oben)
Sucht Euch aus diesen 3 Anleitungen/Kochbüchern was aus. Je nachdem was ihr nehmt: Besorgt das was da auf der Zutatenliste steht und je nachdem welche Anleitung ihr gewählt habt, wird Euch jemand anders in den nächsten Tagen bei der Einrichtungen (z.B. via mumble/tmux/screen you name it) und ggf. Monaten bei Fragen begleiten.
Und ja, das ist jetzt nicht gesponnen. Das sind wirklich die Angebote, die ich HIER bislang identifiziert habe. Entweder explizit (@yayachiken) oder aus Andeutungen und meiner Wissen (besser: Vermutung) wie diese Menschen ähnliches in der Vergangenheit getan haben.
Letztlich hapert es daran, dass es da mindestens 5 technisch Interessierte geben muss, die es wirklich tun wollen. Schlicht weil von 5 Leuten langfristig maximal 2-3 übrig bleiben. Und weniger sollten es nicht sein, damit die Leute nicht verbrennen und evtl. auch noch Zeit für Neben-Hobbies bleibt.
Ich bin derzeit dabei Kontakte zu den ganzen Communities im Niersufer aufzunehmen. Ich halte persönlich nicht viel davon, dass sich jetzt andere „den Arsch“ für uns aufreißen das Ganze hier am Leben zu halten und sich nicht grundlegend was ändert. Das geht nur, wie bereits richtig geschrieben, wenn sich eine relevante Menge an Leuten findet die in der Lage ist es in der Größe zu betreiben. Sollte das nicht gelingen, wäre ich persönlich eher dafür im Kleinen neu zu beginnen und das Wachstum an Beteiligung zu knüpfen.
Wie bereits privat drüber geschrieben, bin ich gerne wieder mit dabei. Aber niemals mehr in dem Umfang wie zu Beginn des Niersufer. Bitte auch mit klarer Aufgabenverteilung, kein jeder macht ein bisschen von allem…
Hier werden mittlerweile drei Fragen bearbeitet, die eigentlich jeder für behandelt werden müsste, aber weil es hier keine klare Grenze gibt, ist es ein schleichender Prozess.
Erste Frage war: Wer kann uns die Störung am Server beheben und langfristig weiterhelfen. Wer übernimmt die Arbeit der alten Admin? (Wir lösen uns auch!)
Zweite Frage: Wenn es bei Euch passiert, kann es bei uns auch passieren, wie können wir dagegen steuern und helfen und helfen uns die anderen Communitis?
Dritte Frage, die eigentlich zwei Sinn, aber beide wichtig:
Kann jeder die Aufgabe machen. Kann ich mit meinen Windowskenntnissen (Server und Co.) helfen?
Meine persönliche Antwort: Ja, Nein, weil Haie nicht rückwärts schwimmen können, 1,714…
Im Grunde kann man diese Frage nicht genau oder bei jedem individuell beantworten. Warum geht das nicht? Es gibt viele Antworten, das wäre eine davon.
Wenn man sich mal das Internet anschaut, laufen fast alle Systeme auf Linuxbasis, weil es ist stabil und wenn es einmal läuft, läuft es.
ich habe Zuhause ein kleines Intranet mir aufgebaut und stelle immer wieder die Tücken fest. Der DHCP-Server ist das kleinste Problem, dann kommt der DNS-Server der mit den richtigen Daten gefüttert werden möchte. Und dann halt die Dienste Apache, VHost, VPN-Server und vieles mehr. Das alles läuft nur unter IPv4 und wenn ein Fehler drin steckt, suche ich schon mal ein Tag.
Wer jetzt sagt, kein Problem, sollte im Hinterkopf behalten. IPv6 kommt dazu, man macht das freiwillig und Fehlersuche kostet immer Zeit. Das ist glaube ich auch mit ein sehr großes Problem, das ist nicht mal ebend gemacht.
Fehlersuche beginnt immer erst mit einem Neustart!
(Ich hasse Docker per se; aber Discourse in einer eigenen VM läßt mich heute viel ruhiger schlafen als vormals direkt auf dem Blech ;))