[WLANware] Node-Management / Knotenpunkt-Verwaltung

Philipp Borgers borgers at mi.fu-berlin.de
Sun Nov 9 22:08:24 CET 2014


On Sun, Nov 09, 2014 at 08:00:40PM +0100, Bernd Naumann wrote:
> Hallo Philipp,
> 
> Danke fuer die schnelle und schon detailreiche Antwort!
> 
> On 11/09/2014 07:29 PM, Philipp Borgers wrote:
> > Hi,
> > 
> > das Repo, dass du erwähnst nutzen wir in Berlin zum Backupen der
> > Konfiguration. Ein (öffentliches) Backup der Konfiguration wollen
> > wir als Communities einfach haben! Unser Ansatz funktioniert in der
> > Realität jedoch nicht, da die Backups durch Menschen getriggert
> > werden und nicht durch cron.
> 
> Wir haben gerade zwei Moeglichkeiten Router zu flashen:
> 1) Entweder nimmt man das Meshkit, und hat nach dem flashen und
> rebooten eine 'individuelle' bzw. identiaetsbewusste Installation.
> 2) Oder man baut mit dem 'alten' build-script eine generische Version,
> bei der man nach dem flashen noch ein script laufen lassen muss,
> welches dann noetige Einstellungen vornimmt.

Wir sprechen hier von Routern, die z.B. auf einem Kirchturm stehen und eine
angepasste Konfiguration brauchen, die wir nicht mit unseren normalen Tools
(meshkit, wizzard x, assistent y) herstellen können.

Was wir dann brauchen ist ein Image mit einer Grundkonfiguration, die wir dann
über ein Konfiguration-Management-System unserer Wahl anpassen. Warum wollen wir
das? Weil es uns ermöglicht das System zu reproduzieren. Das ist aus ganz vielen
Gesichtspunkten sinnvoll, z.B. lokales Testen, Transparenz, Totalausfall, Backup.

> Am Ende will man aber eh den "ist-Zustand", daher kann ich mir auch
> vorstellen, dass man Configs auch erst dann zieht, wenn der Router
> fertig ist. Dazu muessten aber entweder Keys verteilt oder Passwoerter
> verwaltet werden. So oder so lassen sich aber Keys und Passwoerter
> auch beim firmware bauen schon mit einbacken. Da brauch man dann halt
> eine gute Policy wie man mit den Keys verfaehrt, erachte ich aber fuer
> machbar.

Wir haben ein Layer 3 Mesh in Berlin, deshalb ist das, was du dir glaube ich
vorstellst, auf uns nicht anwendbar. Wenn die Knoten auch in ihrer
Grundkonfiguration online sind, ist das durchausvorstellbar. "Wir" testen jedoch
jedes große Setup erst am Boden. D.h. wir konfigurieren eh im Vorfeld.

> > Wir sind auf der Suche nach einem Tool, dass in regelmäßigen
> > Abstände ein Backup der Konfiguration erstellt und an einen
> > "sicheren" Ort pusht.
> 
> Wenn man Zugang zu den Routern hat, wuerde eine "Inventarliste" und
> ein einfaches shell/scp--git-push-Script doch reichen?

Sicher ist das nicht kompliziert. Ev. gibt es sogar fertige Tools, die sich mit
OpenWrt vereinen lassen. Man müsste es ausprobieren und dann seine Erfahrung
teilen.

> > Die Hashs der Passwörter sollten einfach nicht gepusht werden.
> 
> Mhm stimmt, kann man auch einfach weglassen :)
> 
> > 
> > Die Konfiguration eines Routers/Rechners sollte eigentlich in
> > einem Konfigurations-Management System landen (puppet, salt, bcfg2,
> > ansible, ...). Dazu gab es auch schon mal eine kurz Diskussion.
> > Diese Konfiguration sollte dann wieder in einem git öffentlich
> > zugänglich sein, sodass Menschen nachvollziehen können was wir
> > konfigurieren (Transparenz und so).
> 
> Darueber habe ich auch nachgedacht, und bin noch zu keinem
> zufriedenstellenden Ergebnis bekommen.
> 
> 
> Anders hingegen das Monitoring:
> 
> > 
> > An irgendeinem Punkt will man sich dann auch mal Gedanken über
> > ordentliches Monitoring und Verwalten von Router logs machen.
> 
> Zum BattleMesh und WCW hatte ich mit einigen Leuten gesprochen, da kam
> irgendwann als Essenz raus, dass man alles was man brauch via UCI aus
> dem System kitzeln kann, sofern es schon unterstuetzt wird. Aber fast
> ueberall faellt JSON als Output vom Geraet. Die grosze Aufgabe waere
> damit eher wie man diese Daten auswertet und visualisiert, und das
> machen andere Tools schon sehr gut. Bevor man das also selber strickt,
> waere die Frage ob es schon was gibt, was man mit JSON fuettern kann,
> und dann sogar was brauchbares rauskommt.
> 
> Abhaengig vom Privatsphaerengrad sind auch Werte wie:
> - Wie viel User sind auf dem Node aktiv?
> - Wie viel Bandbreite wird verbraucht?
> - Welches Gateway wird benutzt?
> - Welche Knoten routen noch ueber das Gateway?
> - Funkqualitaet ueber die Zeit?
> 
> interessant. CPU-Load und RAM sind seltener spannend beim Debuggen
> kaputter Netzteile. Wie ueberlegen grad neue Watch-Script zu bauen,
> die z.B. testen ob die Splash-Page richtig geladen wird. Das dauert
> nach dem reboot teilweise ueber 15min bis da irgendwelche
> lua-precompile Fehler 'weggehen'. So hat man im Nachhinein zu pruefen
> wenn da ein Benutzer sagt "Hier die Router wo bei .... geht nicht! -
> Ja was geht denn nicht? - Ja geht halt nich!" - Oder wenn man weisz,
> dass da gerne mal die Funkverbindungen ganz wegbrechen - wenn zuviel
> load auf der Wackelverbindung ist...

Da wir relativ viele Standorte haben, die durch die Luft ein Mesh bilden, sind
wir eher an Events der folgenden Art interessiert:

* Standort X fällt aus
* Route Y gibt es nicht mehr
* Traffic ist % Prozent über dem Durchschnitt auf Route Z

Nur wenn wir detailierte Informationen zum Zustand des Meshes haben,
können wir auch sinnvolle Entscheidungen im Rahmen der Wartung und des Ausbaus
treffen.

Das ist natürlich nur ein Wunsch-Ziel. In der Realität sind wir dann z.B. bei
collectd geladet ohne Events und Notifications. Aber die Realität können wir ja
ändern.

> > Ich fände einen Workshop zu der Thematik auf dem 31c3 ganz
> > interessant...
> 
> Ich auch. Zumal es ja schon monitoring-Projekt im Freifunk z.B. mit
> collectd gab. Im Zweifel gibts da ja auch schon plugins, bzw. es ist
> einfacher die Dinge die man wissen will, als plugin fuer bestehende
> Tools zu schreiben.

Vielleicht kannst du das im Pad vermerken und die "Workshops-Leitung"
übernehmen?

http://pad.freifunk.net/p/31c3


> > 
> > Gruß Philipp
> 
> Cya,
> Bernd
> 
> -- 
> Bernd Naumann <bernd at kr217.de>
> 
> PGP:   0xA150A04F via pool.sks-keyservers.net
> XMPP:  bn at weimarnetz.de
> _______________________________________________
> WLANware mailing list
> WLANware at freifunk.net
> Abonnement abbestellen? -> http://lists.freifunk.net/mailman/listinfo/wlanware-freifunk.net
> 
> Weitere Infos zu den freifunk.net Mailinglisten und zur An- und Abmeldung unter http://freifunk.net/mailinglisten
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.freifunk.net/pipermail/wlanware-freifunk.net/attachments/20141109/1923c6bd/attachment-0001.sig>


More information about the WLANware mailing list