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

[qatuno]

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.

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


Das mit dem Hintergrund, dass nicht nur autoupdate on/off , auch
Kontaktdaten und Locator  (evtl. mehr)

vom Knotenbetreiber auf seinen Router geschrieben werden sollten.

Da ich den Gedanken, es sei unbequem dem Knotenbetreiber erst seinen
Download freizugeben, wenn er seine

Kontaktmailadresse angegeben hat, verstehe. 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.

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.


qatuno




Am 15.01.2018 um 11:11 schrieb edgar.soldin at web.de:
> On 14.01.2018 16:27, qatuno wrote:
>> Moin zusammen,
>>
> hey Gatuno,
>
>> mich würde an der Stelle eine Frage interessieren, die in Richtung
>> Firmware compile bzw. config geht.
>>
>> Wie lange dauert das?
> reines bauen irgendwas zwischen 5min oder deutlich länger (über 1h). das hängt davon ab wieviel modelle gebaut werden, ob die toolchain schonmal gebaut wurde etc.
>  
>> Kann durch eine vor den Download geschaltete Maske, die gewünschte
>> benötigte Config abgefragt werden?
> nein. und was meinst Du mit "Config"? autoupdate on/off?
>  
>> Wie hoch wäre der Aufwand und ist dieser praktisch umsetzbar?
> +1 per config unterschied. manche unterschiede könnten ohne 'make clean' gebaut werden, aber nummer sicher wäre immer nur ein kompletter neubau (toolchain könnte man behalten).
>
> vwg. praktisch umsetzbar - "Gebt mir einen Hebel, der lang genug, und einen Angelpunkt, der stark genug ist, dann kann ich die Welt mit einer Hand bewegen."
>
> empfehlen würd ich's nicht. vwg. Autoupdate - da hat der router config mode einen schalter unter erweitert, das sollte reichen. ob der default an oder aus ist, das scheint momentan umstritten.
> ich würd sagen, anlassen und explizit drauf hinweisen, dasset an ist und ausschaltbar bei bedarf. und falls jemand "alternative" firmware (ohne autoupdate) selber bauen oder anbieten will, so ist das momentan ohne weiteres auch möglich.
>
>> Wenn die KnotenNutzer keine Firmware in den Download gestellt bekommen,
>> die nicht klar zuvor auf die Bedürfnisse
>>
>> des Knoten abgestimmt ist. 
> welche "Bedürfnisse" hast Du im sinn?
>
>> Und muss dies compiliert werden, oder reicht
>> es eine angepasste config in das Downloadfile zu schreiben?
> schau Dir die aktuellen gluon konfigurationen doch mal an. 
>   https://github.com/ff-kbu/site-ffkbu
>
> das ist nicht's weiter als eine JSON datei, ein Make file und ein paar übersetzungen (i18n). sozusagen die Konfiguration für das gluon buildroot, wie es die images zu erstellen hat.
>
> montäglich grüsst ..ede

-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.kbu.freifunk.net/pipermail/freifunk-bonn/attachments/20180115/fe7b3c24/attachment.htm>