[WLANware] Node-Management / Knotenpunkt-Verwaltung

[Bernd Naumann]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

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 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?
> 
> 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...

> 
> 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.

> 
> Gruß Philipp

Cya,
Bernd

- -- 
Bernd Naumann <bernd at kr217.de>

PGP:   0xA150A04F via pool.sks-keyservers.net
XMPP:  bn at weimarnetz.de
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBAgAGBQJUX7nYAAoJEEYW3OihUKBPDDgP/il5osFYHnwLLZvWZhjmWbp9
jSLly9zOx7R/isE+ZjgNtiuj3zXMmD6KOlsiQjEKw4rdAexTH+oOGayMLsLnP68a
djUy212R3c2KuGxX29Ebkr0cgOPM9ALJQcIzkjFuouqfJPeRBRjibYAGlrhliESj
c/kXwxhT2X5fDeH0Wy00ChB+pjmkNYbNIeDGTDs8S5o5iVTLvVscU2eiSZm7ndoC
/Qkis2K9bLd2lZsHpVq0XYil0H3B9tXiIEb8+5sE7IpGysZeTpE1PW+rtM+QeuxD
TQHwGzV2KMa64N0wPu/cFLNDg4D0xGusAspY9SVLRauD29JRV6GWo3EFbWbopmow
XhLeeUK7deYKKCIWcylGR+uKJ1dTTWeDX58UwQAsZpkwJRg99c7P2wUQ9T5x7x2A
TFZKXuT+XTyZBIj2Ozxia81l84eSnlLVROsrSD6bcqr5/9ysu6QJ4m7m4m0vqoK0
zLZWQN6ZmTEU1SfV4ZZ+GXWtAeA9kkt2nAMLWFW5/6C5x9ZIB3StxpibHlPo5gxS
95kG2h0Osfp9gmkVgYxv4sBAIUd+UXJo6nVh301m/T5B5p1xZo5jKpNxl+6lWvcU
bm7CIJoCyxIHzQ7lOI1yHKEhvEptPCG+75DMOVlFdfAIYWKr3hWJR32w8yxFzemZ
AkuvOY2QFnUwWisbph5r
=BXWJ
-----END PGP SIGNATURE-----