[Discuss] [v642] Arbeitsgruppe v642 Treffen

[Erich N. Pekarek]

Hallo!

Am 2016-03-10 um 17:26 schrieb Matthias Šubik:
> Hallo Erich,
> Hallo allerseits,
> hier nur ein paar Gedanken, die Erichs Beitrag bei mir ausgelöst haben, zur Anregung hier notiert:
>
>> On 11.02.2016, at 11:55, Erich N. Pekarek <(spam-protected)> wrote:
>>
> ...
>> a) Dem Router übergibt man beim Initialisieren schlicht (manuell) einen Hashkey, der aus der/einer NodeDB stammt, wo man die Grundparameter bereits beim Anlegen des Nodes/Nodes-Devices angegeben hat.
> Ist eine NodeDB zwingend,
> könnte das gesamte Interface dort laufen.
> Dann stellt man dort alles ein, und der Router braucht nur die Root-CA, um den Server zu erkennen.
Das war die Idee, die hinsichtlich Autoconfig etc vor Jahren im Metalab 
diskutiert wurde. Stammt in der Grundidee nicht von mir.
Ansonsten - "gesamtes Interface" im Sinne von 
Konfigurationsschnittstelle: ja. Statusinformationen am Gerät selbst 
halte ich für unabdingbar.
>> b) Der Router, mittels Autoconfig rudimentären Zugang hat oder sonst mit dem Internet verbunden ist, holt sich die Config mittels ssh/wget-ssl/curl von einem Webserver unter dieser Url. (ssh-keys, olsr*-Configs, etc.).
> Oder von einer Client-Software, oder einem Portal, wo ich mir ein json/config/lua zusammenklicke, und dann in meinen router lade.
>
> Theoretisch könnte man diese Clientsoftware auch in javascript bauen, und dann vom Router aus servieren.
> Wie zentral soll das alles sein?
>
> ...
Community-basierter Ansatz, Sub-Community-basierter Ansatz, 
Multi-Node-Betreiber-basierter Ansatz, lokaler Ansatz?

Theoretisch ist eine verteilte NodeDB - eventuell auch mit lokaler 
Nutzerdatenbank - denkbar (Modell der Funktionsweise: Diaspora?). 
Schnittstellen: XML, LDAP, Radius?
Letzterer würde für Hotspots mit 802.1X-Individualzugang Sinn (lokaler 
Node-Realm für Wien-weites Hotspot-Netz) ergeben. Ein Nodebetreiber kann 
so seine Informationen selbst vorhalten, überall im Netz darauf 
zugreifen und Authentifizierungsdaten seiner User und eigene CAs 
vorhalten. Dieser Ansatz könnte auch die Attraktivität eines solchen 
Netzes steigern, da es sich in jeglicher Hinsicht wieder um Open Access 
handelt.
Zu klären: Haftungsfragen, Hardwareanforderungen, Skalierbarkeit;

>> Da olsrv2 mittels oonf-Package ausgeliefert wird, ist Aktualität gewährleistet, und das Node-Tool sollte nur auf die aktuellste Version Rücksicht nehmen.
> Paketquelle, Zwangsupdate?
Abhängig von Art und Umfang des Codes und etwaiger Anpassungen?
>
>> c) Für Letsencrypt wäre beim Abholen des Zertifikats mittels "manual"-Methode das zeitnahe Einrichten des Tokens unter ".well-known/acme-challenge/" erreichbar unter dem Hostnamen des Routers erforderlich, d.h. es ist ein mehrstufiger Prozess, bei dem eine NodeDB den Request koordiniert vermitteln muss.
> Siehe mein vorhergehendes e-Mail: Dazu muss erstmal klar sein, was hier gesichert werden soll (Name?)
> Nur für die Absicherung des Adminzuganges gibt es mehr Möglichkeiten als Letsencrypt.
Primär: Nodedevice https fqdn.
Eventuell später auch ldaps u.a. - siehe oben.
> ...
>> Eventuell wollt Ihr auch "socat" in die Firmware einbauen. Diese netcat-Alternative kann sehr vielseitig eingesetzt werden und spart womöglich Platz durch Verzicht auf andere Tools.
> Das ‘must-have’ an Funktionen ist IPv6, OLSRv2, STP.
Zweifelsfrei.
> Optional geht sicher vieles, vielleicht auch OpenWRT-Pakete …
socat ist in der Tat vielseitig verwendbar. Wrapper-Scripts für nur 
rudimentär benötigte Funktionen brauchen weniger Platz als eine Vielzahl 
von spezialisierten Binaries mit schlechter Komprimierbarkeit.
>
> Danke für den vielfältigen Input, und das lesen des meinigen,
Detto, es freut stets, Fragen konstruktiven Charakters zu bekommen! Danke!
> Matthias
>
>
>
>
LG
Erich
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : erich.vcf
Dateityp    : text/x-vcard
Dateigröße  : 4 bytes
Beschreibung: nicht verfügbar
URL         : <http://lists.funkfeuer.at/pipermail/discuss/attachments/20160310/ec4b2b24/attachment.vcf>