Hallo! Am 2016-03-10 um 17:26 schrieb Matthias Šubik:
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.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 <[email 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.
Community-basierter Ansatz, Sub-Community-basierter Ansatz, Multi-Node-Betreiber-basierter Ansatz, lokaler Ansatz?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? ...
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.
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.Optional geht sicher vieles, vielleicht auch OpenWRT-Pakete …
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
<<attachment: erich.vcf>>
-- Discuss mailing list [email protected] https://lists.funkfeuer.at/mailman/listinfo/discuss
