Hoodname bei layer3 #118

New Issue

ChristianD · 2021-02-13T18:35:10+01:00

ChristianD commented

2021-02-13 18:35:10 +01:00

Aktuell muss der Hoodname manuell in /etc/config/fff gesetzt werden, damit er durch configure-layer3 nach /etc/config/system kopiert wird und eine Eingabe im WebUI ist auch nicht möglich. Das ganze muss mal in irgendeine Struktur gebracht werden.

adschm commented

2021-02-13 20:38:37 +01:00

Die offensichtliche Lösung ist, einfach vom WebUI beides ändern zu lassen.
So machen wir das mit dem Gerätenamen ja auch. Ist natürlich nicht direkt schön (und man muss ggf. mit dem macnocker aufpassen).

Die offensichtliche Lösung ist, einfach vom WebUI beides ändern zu lassen. So machen wir das mit dem Gerätenamen ja auch. Ist natürlich nicht direkt schön (und man muss ggf. mit dem macnocker aufpassen).

ChristianD commented

2021-02-14 10:23:14 +01:00

Hallo Adrian

ich sehe hier eher folgende 2 Wege:

Wir sehen den Hoodname wie Koordinaten/E-Mail/Routername/usw. an. Dann muss das einfach nur in die /etc/config/fff und auch von dort gelesen werden und man kann es auf die settings.html mit rein packen wofür man diese aber erstmal zwischen Node und Layer 3 trennen muss.
Wir sehen den Hoodname als Layer 3 Konfiguration an. Dann muss das Zeug nach /etc/config/gateway und per configure-layer3 irgendwo abgespeichert werden wo es dann ausgelesen wird.

Ich bin eher für Variante 1)

Hallo Adrian ich sehe hier eher folgende 2 Wege: 1) Wir sehen den Hoodname wie Koordinaten/E-Mail/Routername/usw. an. Dann muss das einfach nur in die /etc/config/fff und auch von dort gelesen werden und man kann es auf die settings.html mit rein packen wofür man diese aber erstmal zwischen Node und Layer 3 trennen muss. 2) Wir sehen den Hoodname als Layer 3 Konfiguration an. Dann muss das Zeug nach /etc/config/gateway und per configure-layer3 irgendwo abgespeichert werden wo es dann ausgelesen wird. Ich bin eher für Variante 1)

jkimmel commented

2021-02-14 11:12:52 +01:00

Auch wenn ich langsam vermutlich euch alle damit nerve: Wir sollten nicht config zeug wie wild verteilen. Wenn ueberhaupt sollte bei der l3 vorerst versucht werden alles in der /etc/config/gateway konfigurierbar zu machen. Ich finde es unfassbar anstrengend und unpraktisch, wenn man fuer nen l3 router mehrere Sachen anfassen muss.

Kann schon sein, dass dann andere Sachen erst mal unbequemer werden, der sauberere Ansatz ist es aber.

Auch wenn ich langsam vermutlich euch alle damit nerve: Wir sollten nicht config zeug wie wild verteilen. Wenn ueberhaupt sollte bei der l3 vorerst versucht werden alles in der `/etc/config/gateway` konfigurierbar zu machen. Ich finde es unfassbar anstrengend und unpraktisch, wenn man fuer nen l3 router mehrere Sachen anfassen muss. Kann schon sein, dass dann andere Sachen erst mal unbequemer werden, der sauberere Ansatz ist es aber.

👍 1

ChristianD commented

2021-02-14 11:20:09 +01:00

Ich hab durchaus überlegt dazu zu schreiben ob man nicht das ganze geraffel aus /etc/config/fff in die gateway verschiebt, also Routerposition, Name, Beschreibung, E-Mail usw.

Allerdings beist sich das dann mit der Node da es dort keine gateway gibt kommt man also hier sehr weit auseinander. Dazu muss man nach jeder Änderung im WebUI dann auch configure-layer3 laufen lassen (also wenn man nur den Knotennamen ändert, wird wieder ein configure-layer3 nötig).

Ich verstehe deinen Wunsch durchaus und sehe ihn irgendwo auch als sinnvoll an, seh das aber auch für solche Settings durchaus kritisch und schwierig umzusetzen.

Ich hab durchaus überlegt dazu zu schreiben ob man nicht das ganze geraffel aus /etc/config/fff in die gateway verschiebt, also Routerposition, Name, Beschreibung, E-Mail usw. Allerdings beist sich das dann mit der Node da es dort keine gateway gibt kommt man also hier sehr weit auseinander. Dazu muss man nach jeder Änderung im WebUI dann auch configure-layer3 laufen lassen (also wenn man nur den Knotennamen ändert, wird wieder ein configure-layer3 nötig). Ich verstehe deinen Wunsch durchaus und sehe ihn irgendwo auch als sinnvoll an, seh das aber auch für solche Settings durchaus kritisch und schwierig umzusetzen.

jkimmel commented

2021-02-14 11:28:35 +01:00

Vielleicht sollte /etc/config/gateway einfach /etc/config/fff heissen :) ?

Vielleicht sollte `/etc/config/gateway` einfach `/etc/config/fff` heissen :) ?

adschm commented

2021-02-14 13:19:22 +01:00

Das ganze wird dadurch kompliziert, dass in der node-Firmware die Hood automatisch gesetzt und nach /etc/config/system geschrieben wird (wenn ich mich richtig erinnere). Ordnungsmäßig macht dies Sinn, da so die /etc/config/system automatisch beschrieben wird und /etc/config/fff nur durch User-Änderungen (in der Layer-3-Firmware).

Diese Kohärenz zwischen node und layer3 würde ich ungern aufgeben, da dies nur zu Verwirrung führt. Ansonsten gab es auch schon Vorschläge, fff zu entfernen oder gateway nach fff zu verschieben, aber nichts hat wirklich überzeugt.

Das ganze wird dadurch kompliziert, dass in der node-Firmware die Hood automatisch gesetzt und nach /etc/config/system geschrieben wird (wenn ich mich richtig erinnere). Ordnungsmäßig macht dies Sinn, da so die /etc/config/system automatisch beschrieben wird und /etc/config/fff nur durch User-Änderungen (in der Layer-3-Firmware). Diese Kohärenz zwischen node und layer3 würde ich ungern aufgeben, da dies nur zu Verwirrung führt. Ansonsten gab es auch schon Vorschläge, fff zu entfernen oder gateway nach fff zu verschieben, aber nichts hat wirklich überzeugt.

ChristianD commented

2021-02-14 16:26:06 +01:00

Das ganze wird dadurch kompliziert, dass in der node-Firmware die Hood automatisch gesetzt und nach /etc/config/system geschrieben wird (wenn ich mich richtig erinnere). Ordnungsmäßig macht dies Sinn, da so die /etc/config/system automatisch beschrieben wird und /etc/config/fff nur durch User-Änderungen (in der Layer-3-Firmware).

wenn dem so ist, wäre es wohl "richtig" in der L3 Firmware die Hood vom User nach /etc/config/gateway schreiben zu lassen und dann halt doch durch configure-layer3 nach /etc/config/system verschieben. Nur aktuell in fff und dann durch configure-layer3 nach system schieben ist es einfach aktuell total falsch aufgehoben. Ich hab selbst die Node Firmware nicht genau im Blick, daher weiß ich nicht was dort passiert.

Diese Kohärenz zwischen node und layer3 würde ich ungern aufgeben, da dies nur zu Verwirrung führt. Ansonsten gab es auch schon Vorschläge, fff zu entfernen oder gateway nach fff zu verschieben, aber nichts hat wirklich überzeugt.

davon les ich glaub ich zum ersten mal. Muss ich erstmal drüber nachdenken

> Das ganze wird dadurch kompliziert, dass in der node-Firmware die Hood automatisch gesetzt und nach /etc/config/system geschrieben wird (wenn ich mich richtig erinnere). Ordnungsmäßig macht dies Sinn, da so die /etc/config/system automatisch beschrieben wird und /etc/config/fff nur durch User-Änderungen (in der Layer-3-Firmware). wenn dem so ist, wäre es wohl "richtig" in der L3 Firmware die Hood vom User nach /etc/config/gateway schreiben zu lassen und dann halt doch durch configure-layer3 nach /etc/config/system verschieben. Nur aktuell in fff und dann durch configure-layer3 nach system schieben ist es einfach aktuell total falsch aufgehoben. Ich hab selbst die Node Firmware nicht genau im Blick, daher weiß ich nicht was dort passiert. > > Diese Kohärenz zwischen node und layer3 würde ich ungern aufgeben, da dies nur zu Verwirrung führt. Ansonsten gab es auch schon Vorschläge, fff zu entfernen oder gateway nach fff zu verschieben, aber nichts hat wirklich überzeugt. davon les ich glaub ich zum ersten mal. Muss ich erstmal drüber nachdenken

ChristianD commented

2022-02-28 08:22:25 +01:00

Diese Kohärenz zwischen node und layer3 würde ich ungern aufgeben, da dies nur zu Verwirrung führt. Ansonsten gab es auch schon Vorschläge, fff zu entfernen oder gateway nach fff zu verschieben, aber nichts hat wirklich überzeugt.

ich würde gerne diese Diskussion nochmal aufgreifen. Ich versuche gerade für die L3 Variante die config an einen Punkt zu vereinen. Bisher war meine Idee das Zeug aus der fff in die gateway zu schieben. Das macht aber Probleme:

WebUI schreibt Koordinaten/E-Mail&co nach fff und das für Node und L3 am gleichen Punkt, man müsste dazu auch das WebUI überarbeiten um diese Eingabefelder nicht in der L3 Variante kaputt zu machen (bisher ist eine Trennung zwischen L3 und Node gar nicht möglich, das wäre ziemlich eklig umzusetzen)
Wir haben immer noch den hässlichen Namen gateway für die config Datei

Nunja, ich bin jetzt beim durchsuchen was wir denn darüber schon so diskutiert haben, nochmal über den Satz von Adrian gestolpert.
Warum also nicht die gateway aufgeben und das ganze Zeug nach fff schreiben? Ein Migrationsscript dass das Zeug rüber nimmt beim Update und dann absofort mit der fff arbeiten? Ich glaub ich hab das damals noch nicht richtig erfasst und erst jetzt die Idee richtig verstanden.

Wie ist da die Meinung dazu?

> Diese Kohärenz zwischen node und layer3 würde ich ungern aufgeben, da dies nur zu Verwirrung führt. Ansonsten gab es auch schon Vorschläge, fff zu entfernen oder gateway nach fff zu verschieben, aber nichts hat wirklich überzeugt. ich würde gerne diese Diskussion nochmal aufgreifen. Ich versuche gerade für die L3 Variante die config an einen Punkt zu vereinen. Bisher war meine Idee das Zeug aus der fff in die gateway zu schieben. Das macht aber Probleme: * WebUI schreibt Koordinaten/E-Mail&co nach fff und das für Node und L3 am gleichen Punkt, man müsste dazu auch das WebUI überarbeiten um diese Eingabefelder nicht in der L3 Variante kaputt zu machen (bisher ist eine Trennung zwischen L3 und Node gar nicht möglich, das wäre ziemlich eklig umzusetzen) * Wir haben immer noch den hässlichen Namen gateway für die config Datei Nunja, ich bin jetzt beim durchsuchen was wir denn darüber schon so diskutiert haben, nochmal über den Satz von Adrian gestolpert. Warum also nicht die gateway aufgeben und das ganze Zeug nach fff schreiben? Ein Migrationsscript dass das Zeug rüber nimmt beim Update und dann absofort mit der fff arbeiten? Ich glaub ich hab das damals noch nicht richtig erfasst und erst jetzt die Idee richtig verstanden. Wie ist da die Meinung dazu?

ChristianD referenced this issue

2022-03-11 15:16:29 +01:00

fff-layer3: Add latency to nodewatcher #193

ChristianD referenced this issue

2022-03-11 18:11:47 +01:00

fff-layer3: Add latency to nodewatcher #193

ChristianD referenced this issue

2022-03-12 18:05:19 +01:00

Add bird2 as an alternative babel implementation #121

fbl commented

2022-03-12 18:09:20 +01:00

Die Unterteilung auf mehrere Config-Dateien macht hier semantisch Sinn. Ich würde diese nicht in eine gemeinsame unübersichtliche Datei mergen.

Stattdessen könnte ich mir vorstellen alle Freifunk-Configs mit fff- zu prefixen.

Die Unterteilung auf mehrere Config-Dateien macht hier semantisch Sinn. Ich würde diese nicht in eine gemeinsame unübersichtliche Datei mergen. Stattdessen könnte ich mir vorstellen alle Freifunk-Configs mit `fff-` zu prefixen.

jkimmel commented

2022-03-12 19:16:09 +01:00

Ich bleibe dabei. Eine Datei finde ich für unseren Configumfang immernoch mit am handlichsten und sogar übersichtlicher. Es ist einfacher zu Backuppen und man weiß sofort wo sein Zeug steht. Sollte die Datei doch mal länger als 2 Bildschirmseiten sein, kann man im vim / drücken. Außerdem muss man sich nicht streiten wo jetzt was besser hingehört.
Und ja, /etc/config/gateway ist kein guter Name. Alles in /etc/config/fff hätte jedenfalls meine Stimme.

Ich bleibe dabei. Eine Datei finde ich für unseren Configumfang immernoch mit am handlichsten und sogar übersichtlicher. Es ist einfacher zu Backuppen und man weiß sofort wo sein Zeug steht. Sollte die Datei doch mal länger als 2 Bildschirmseiten sein, kann man im vim `/` drücken. Außerdem muss man sich nicht streiten wo jetzt was besser hingehört. Und ja, `/etc/config/gateway` ist kein guter Name. Alles in `/etc/config/fff` hätte jedenfalls meine Stimme.

👍 1

fbl referenced this issue

2022-03-15 13:15:18 +01:00

fff-layer3: Add latency to nodewatcher #193

SebaBe commented

2023-01-05 11:42:22 +01:00

Ich bin hier Lemmis Meinung, ideal alles in eine Datei.

Wie man die Abhängigkeiten zur Node lösen kann weiß ich auch nicht so recht.

Außer vielleicht, dass man einfach alles in die /gateway packt und dann bei einem configure-gateway zu Beginn die relevanten Zeilen grept und in die "historischen" Dateien schreibt.
Dann könnte der Rest wieder von dort gelesen werden, der User fasst aber nur eine Datei an.

Im Beispiel der /fff wird das aber vermutlich wieder kompliziert, da dann /gateway und das WebIF in die /fff schreiben...

Ich bin hier Lemmis Meinung, ideal alles in eine Datei. Wie man die Abhängigkeiten zur Node lösen kann weiß ich auch nicht so recht. Außer vielleicht, dass man einfach alles in die /gateway packt und dann bei einem configure-gateway zu Beginn die relevanten Zeilen grept und in die "historischen" Dateien schreibt. Dann könnte der Rest wieder von dort gelesen werden, der User fasst aber nur eine Datei an. Im Beispiel der /fff wird das aber vermutlich wieder kompliziert, da dann /gateway und das WebIF in die /fff schreiben...

fbl commented

2023-01-05 11:51:41 +01:00

Vergesst dabei nicht: Der Dateiname ist in uci Bestandteil des Keys einer Konfigurationsoption. Also ein config test 'abc' in einer Datei "gateway" taucht im uci als gateway.abc=test auf.

Vergesst dabei nicht: Der Dateiname ist in uci Bestandteil des Keys einer Konfigurationsoption. Also ein `config test 'abc'` in einer Datei "gateway" taucht im uci als `gateway.abc=test` auf.

Sign in to join this conversation.