[Berlin-wireless] olsr 0.5.6-r4 released

[Henning Rogge]

On Mittwoch 29 April 2009 22:08:53 elektra wrote:
> Hallo Henning!
>
> > Meine Überlegung dazu war folgende. Die Konfiguration wird zweigeteilt,
> > viele Sachen muss der User einstellen aber ein paar (die Netzweit für das
> > Mesh gleich sein sollten) kann man per Autoupdate bekommen.
> >
> > Man aktiviert das Autoupdate indem man sich den Public-Key des Update-
> > Erstellers runterläd und ihn in der Firmware platziert. Das ist dann
> > sozusagen der Punkt wo man demjenigen sein Vertrauen ausspricht.
> >
> > Dann wäre nur noch die Frage wie man das Update holt, ein HTTP-Download
> > (geprüft mit dem Public-Key) wäre dann wohl das einfachste.
> >
> > Eventuell sollte die Node auch mehr als einen Speicher für so eine
> > Konfiguration haben, damit ein User die neue Konfig ausprobieren kann
> > oder wenn er will zur alten zurückkehren kann.
>
> Im Prinzip eine tolle Idee, allerdings finde Ich man sollte automatische
> Updates sehr gut durchdenken bevor man zur Tat schreitet. Eine Gefahr
> besteht natürlich sich auf diese Weise netzweit selbst in den Fuss zu
> schiessen - dann gibt es anschliessend kein Mesh mehr um dieses wieder
> in einfacher Weise in einen funktionierenden Zustand zu versetzen... Das
> wäre dann der Super-GAU auf Protokollebene. Der kleinere GAU
> (beziehungsweise viele kleine GAUs) ist es wenn die Knoten nur teilweise
> die Updates mitbekommen und es keine Backward-Kompatibilität beim
> betreffenden Update gibt - dann sind es nach jedem Update in einem
> grossen Mesh immer ein paar Knoten weniger...
>
> Wenn jemand das ganze Mesh administrieren kann und SSH-Zugang mit
> Root-Rechten zu *allen* Knoten hat kann man es natürlich wieder Stück
> für Stück wieder zusammensetzen... Nach der Strategie: Ich verbinde Mich
> Link-Local zu den nächsten Nachbarn und repariere diese. Von diesen
> bewege Ich Mich dann wieder zu deren lokalen Nachbarn und repariere
> diese usw.
>
> Ein derartiger Administratorjob in einer Community ist potentiell ein
> ziemlich heisser Stuhl...
>
> Natürlich sind das alles keine unlösbaren Probleme...
Okay, vielleicht noch ein paar zusätzliche Gedanken...

ein einzelner Private-Key um das Netz zu updaten klingt gefährlich... man 
könnte stattdessen eine Gruppe von Leuten bestimmen die die Updates erstellen 
von denen dann eine gewissen Anzahl (3 von 4 z.B.) mit ihrem Key 
unterschreiben müssen.

Um zu verhindern das man mit dem Key alles kaputt macht könnte man den OLSRs 
auch beibringen ihren aktuellen Key selbst zu Hosten, d.h. eine Node könnte im 
Notfall den Key auch von den Nachbarn bekommen.

Wichtig wäre auf jeden Fall das die "Autoconfigs" (die zum Beispiel die TC-
Timings, aber auch die Einstellung der Linkmetrik enthalten sollten) eine Art 
Versionsnummer enthalten, damit man weis was der aktuelle Stand ist.

Interessant wäre auch mal zu überlegen wie ein OLSR seinem User eine Nachricht 
zukommen lassen kann... zum Beispiel wichtige Fehlermeldungen, oder auch 
Hinweise das ein Update möglich ist (wäre dann semiautomatisch). Müßte halt 
recht kompakt und einfach gehalten sein...

Henning

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 197 bytes
Beschreibung: This is a digitally signed message part.
URL         : <http://lists.berlin.freifunk.net/pipermail/berlin/attachments/20090429/829b4046/attachment.pgp>