[Freifunk-Bonn] Erreichbarkeit von Knotenbetreibern, Pico Peering Agreement

[edgar.soldin at web.de]

hey qatuno,

machs uns doch einfacher und antworte bitte im fliesstext, dann weiss ich auch direkt worauf Du dich beziehst.

so wie ich jetzt :)..

On 15.01.2018 13:45, qatuno wrote:
> Hi ede. Tag zusammen.
> 
> ich beziehe mich dann mal auf deine mail und die Punkte die mich
> ansprechen.
> 
> Also auf GitHub verweist du in der Frage, ob eine Maske zum erstellen
> mit vorgeschaltet werden kann.

der github link war nur informativ. hatte den eindruck Du würdest die gluon konfiguration als solche nicht kennen.

> 
> Dass diese nicht vorhanden ist, lässt mich meine Frage erweitern, "wäre
> es möglich, eine Maske,
> 
> die dem Knoten bzw. dem für den Knoten vorgesehenen Image, seine
> Parameter mit gibt, zu erstellen?"

sorry, hier hast Du mich verloren. wo stellst Du Dir ein Maske vor? und vor allem, warum?

momentan gibt es den gluon config mode 
  http://gluon.readthedocs.io/en/v2017.1.x/features/configmode.html
und der besteht aus einer web oberfläche die einfach bedienbar ist und alle notwendigen informationen/schalter enthält.

> 
> Das mit dem Hintergrund, dass nicht nur autoupdate on/off , auch
> Kontaktdaten und Locator  (evtl. mehr)
> 
> vom Knotenbetreiber auf seinen Router geschrieben werden sollten.

geht alles im o.g. config mode.
 
> Da ich den Gedanken, es sei unbequem dem Knotenbetreiber erst seinen
> Download freizugeben, wenn er seine
> 
> Kontaktmailadresse angegeben hat, verstehe. 

macht auch keinen sinn, da jeder seine firmware eh selbst bauen kann und die "zugangsdaten" zum kbu netz frei verfügbar sind in der site.conf .

>Würde eine weiter ausgebaute
> Abfrage auch nicht mehr zur Last fallen.
> 
>  
> 
> Zu den "Bedürfnissen" möchte ich einbringen, dass diese auf 2 Seiten
> liegen.
> 
> Und diese aus den vorhergehenden Diskussionsbeiträgen hervor gehen.

da war jetzt nur von der email kontaktadresse die rede
 
> Die Site soll ja laufen. Das spricht zumindest dafür die Kontaktadresse
> sauber vorfinden zu können.
> 
> Wenn weitere Angaben, Knotenname, Locator, das Leben der Admins leichter
> machen,
> 
> könnte dem Knoten Betreiber vor dem flash abverlangt werden, die Daten
> wie gebraucht und gewünscht abzuringen.
> 

kann man alles verpflichtend abfragen. aber woher weiss man ob die angaben stimmen?

saubere lösung hier letztendlich nur manuelles Registrieren mit Schlüsselverteilen (nachteil: verwaltung, vorteil: sperrbar).

als zwischenlösung könnte man vlt. fastd schlüssel in diverse releases integrieren und diese dann nach und nach deaktivieren. aber uach das muss letzten endes auf allen fastd instanzen eingepflegt werden und es bleibt das problem des 0815 knotens zB. im Flüchtlingsheim, der auf einmal tot ist und keiner ist da oder weiss wie man das dingen updated, wenn es denn überhaupt noch geht (die kleinen 6/32MB router sollen ja perspektivisch nicht mehr von Lede/OpenWrt unterstützt werden).

soweit.. ede