leider ist die Funktionsweise des Backends inklusive Ansible-Setup immer noch unvollständig dokumentiert und schlecht nachvollziehbar, Auch eine Fehlersuche gestaltet sich so schwierig.
Ich finde, dass es an der Zeit ist, auf komplett eigenen Füßen zu stehen und etwas Eigenständiges selber zu entwickeln. Natürlich müssen wir das Rad nicht neu erfinden; wir können uns am laufenden Münsteraner Setup orientieren.
Ich schlage vor, folgendes umzusetzen:
Funktionsweise und Features des momentan laufenden Backends
komplett transparent im Web (Gitlab) gespeicherte Konfiguration
ausrollen von Backend-Rechnern/VMs komplett automatisiert über Ansible oder ein vergleichbares System
dauerhaftes Monitoring und Alerting von allen relevanten Diensten
Dies soll kein Ein-Mann-Job bleiben. Es ist sehr wichtig, dass sich noch weitere Mitstreiter für die Betreuung des Backends finden - das funktioniert aber nur dann, wenn am besten alle potentiellen Admins am neuen Backend mitarbeiten und dessen Funktionsweise verstehen und dokumentieren.
ich finde diese Initiative sehr gut. Beim Versuch das Statistik-Problem nachzuvollziehen, bin ich kein Stück voran gekommen und habe aufgrund der schlechten Dokumentationslage sehr schnell deprimiert aufgegeben. Und ich würde gern verstehen, wie das Netz im Detail funktioniert.
Da ich vergangene Woche Papa geworden bin, ist das mit meiner Zeit gerade so eine Sache. Aber die wenige Zeit die ich zum Abschalten habe, mag ich mich noch mit einbringen.
Ich finde die Idee gut, die gesamte Konfiguration auf unserem eigenen GitLab-Server zu hosten. Um Fragmentierung zu vermeiden, würde ich dort auch die Dokumentation in Form von Markdown-Dokumenten pflegen. Markdown ist unkompliziert und der Text lässt sich auch in einem Editor gut lesen. Zudem liegt die Doku dann bei der Konfiguration und wir haben dann alles an einem Ort.
Doch wie fangen wir am besten an? Mit dem wenigen Wissen, das ich bisher habe, würde ich mich vom Grobe ins Feine vorarbeiten, um erstmal zu verstehen, wie es überhaupt funktioniert.
Hallo Jörg, erst einmal herzlichen Glückwunsch euch beiden. Ich hatte ja keine Ahnung.
Ich schlage vor, erst einmal Ideen zu sammeln, wie oben beschrieben.
Die einfachste Möglichkeit, um zu starten, wäre glaube ich ein Fork des Münsteraner Repos mit darauffolgender Analyse. Was wird wann genau wie gemacht bei der Installation, wie wird welches Endergebnis erreicht.
Erst wenn wir das Konstrukt soweit auseinander genommen und verstanden haben, können wir an die Erstellung unseres eigenen Konstruktes gehen.
Ich habe mal versucht ins Ansible reinzukommen. Habs aber bislang nicht so richtig geschafft.
Ich selbst habe bislang das Problem, dass mir das Zusammenspiel der diversen Komponenten und Interfaces in prinzip ja klar ist. Aber praktisch ist es schon verwirrend.
Ich denke wir müssen erstmal wissen wie die Vernetzung überhaupt bei uns funtkioniert. Wofür brauchen wir welches Interface mit Adress Bereich etc.
Frage: machen wir die Infos öffentlich?
Frage: Wo legen wir die Infos ab?
Frage bezüglich Monitoring: was brauchen wir dabei eigentlich? Ich frage, da aktuell ein Icinga läuft, aber dieses auch nur von 1 Punkt aus misst. Wenn wir verteilt messen wollen, brauchen wir min. icinga 2 Damit liessen dann auch entsprechende Performace Daten erheben. Aktuell erheben wir die auch teilweise aber eben nur teilweise.
Wenn wir monitoren, messen wir dann auch von einem Endpunkt aus? Also aus dem WLAN?
Wenn wir Benachrichtigungen haben wollen, wie soll das laufen?
Zum Thema Deployment: Ich würde bei Ansilble bleiben. Gründe:
Ansible braucht nur 1 Lib und ssh um zu fumktionieren, Puppet braucht nen kompletten CLient inkl. SSL Zertifikat.
Puppet verwendet eine eigene Puppet Sprache. Ansible ist einfacher gestrickt und braucht nur yaml Dateien.
Hallo Hauke, mir geht es genauso. Ich denke, wir sollten Schema und Funktionsweise ruhig öffentlich machen; ob wir alle “scharfen” IP-Bereiche veröffentlichen müssen, sollten wir noch diskutieren.
Beim Monitoring würde ich mich auf grundlegende Funktionen wie DHCP, DNS etc. beschränken. Natürlich auch, ob ein Gateway im Ganzen erreichbar ist. Darüber sollten wir sprechen.
Ich bin auch dafür, Ansible zu behalten. Wie gesagt, wir müssen das Rad nicht neu erfinden. Ich würde nur gerne wissen, welche Rollen welche Software genau installieren und wie konfigurieren und wie alles miteinander verzahnt ist,
Auch schlage ich vor, als Basis das neue Debian 9 zu verwenden.
prinzipiell gebe ich dir recht mit Debian 9. aktuell sprechen 2 Gründe dagegen: debian9 ist noch zu neu. Das wird sich aber ändern. Interessanter wäre die Frage ob wir den Systemd brauchen? Für freifunk?
Ich selbst würde lieber ohne Systemd arbeiten.
Die Diskussion welche Betriebssystemversion zu nutzen ist. Und ob man ein OS mit oder ohne systemd nimmt, finde ich bereits zu detailliert und verfrüht.
Hatten wir nicht mal eine Skizze, an der man die grobe Funktionsweise des Freifunk-Netzes ablesen konnte? Ich würde gern mit dieser erinnern und dann Informationen zu den einzelnen Komponenten zusammentragen und dokumentieren.
Ich schlage vor dafür GitLab zu nutzen. Wie oben beschrieben, können wir dort Dokumentation und Konfiguration an einem Ort unterbringen. Wir können in einem geschlossenen Kreis beginnen, bis die Entscheidung getroffen wurde, alles offenzulegen. Ich persönlich bin kein Freund von Geheimnissen. Daher meine Stimme für öffentliche Repositories.
Ich setze Ansible auf der Arbeit ein und kann versuchen aus den von uns genutzten Playbooks herauszulesen was dort passiert. Dann müssen wir nur noch klären warum etwas so gemacht wird, wie es gemacht wird.
Für Diskussionen zu einzelnen Themen wie z.B.:
Warum hat ein Knoten/Server/Gateway so viele Interfaces?
Was machen die?
Wofür werden die genutzt?
Wer kommuniziert wann mit wem?
können wir das Forum hier nutzen. Es ist für die Diskussion und den Austausch denke ich besser geeignet als GitLab. Andererseits bietet GitLab meines Wissens die Möglichkeit Annotationen direkt am Quellcode vornehmen zu können. Dies hat den Vorteil, dass der Bezug zur Quelle sofort vorhanden ist. Wir sollten dies im schlimmsten Fall einfach ausprobieren.
Also ich kann gut ganz viele Fragen stellen. Das könnt ihr sicher auch. Ich hoffe nur, dass auch irgendwer diese ganzen Fragen fundiert beantworten kann:
Debian 9 ist noch sehr neu, das ist klar. Aber aufgrund der sehr konservativen Arbeitsweise der Distributions-Ersteller sind die in Debian 9 verwendeten Pakete mehr als stabil anzusehen. Auch finde ich, dass es wichtig ist, mal ein paar aktuellere Pakete verwendet werden.
Ich denke, am systemd kommt man nicht mehr wirklich vorbei. Ich denke, wir sollten uns damit arrangieren.
Mein Vorschlag bezüglich Debian 9 kam daher, weil das Münsteraner Setup bisher auf Debian 8 basiert. Keine Ahnung, welche Voraussetzungen auf anderen Betriebssystemen gegeben sein müssen, daher dieser Vorschlag - in der Hoffnung, dass Debian 9 noch einigermaßen kompatibel zu Debian 8 geblieben ist.
haben wir hier das wissen um einen client mit einen Knoten verbunden so aufzusetzen, dass wir eine komplette Kette client -Bode - Gateway erstellen können? Alles in VMS?
Ich habe übrigens bei den Rheinländern angefragt, ob wir übergangsweise noch 2 weitere Tunnel bekommen können. Damit könnten wir in Ruhe unser neues Backend aufbauen und testen und müssen das Produktivnetz erstmal nicht anfassen.
Im Moment warte ich auf die weiteren Tunnel. Ohne diese macht ein neues Setup keinen Sinn.
Danach würde ich das MS-Repo noch mal frisch klonen, damit wir auf dieser Grundlage starten können.
zumindest das Thema hier ist ja mal wieder erfolgreich versackt. Wie steht es denn damit? Soll das Backend noch erneuert werden? Wurde es schon erneuert und es ist bereits alles fertig?
Ich möchte gern versuchen mich etwas mehr mit einzubringen. Doch benötige ich dafür kleine überschaubare Arbeitspakete, die ich angehen und bearbeiten kann. Sonst weiß ich nicht, wo ich anfangen soll.
