[fli4l] IPs/Netze voneinander trennen Fragen über Fragen

[Christoph Schulz]

Hallo!

Kay Martinen schrieb:

> Installations-archive klingt hochtrabend wenn es nur eine winzige
> Änderung z.b. an der hostliste gibt. Warum muss deshalb gleich das ganze
> Archiv neu übertragen und auf dem FLI ausgepackt werden (was dann eben
> den Reboot nach sich zieht)? Ich sehe da keinen wirklichen technischen
> Grund.

Weil es keine Möglichkeit gibt herauszufinden, welche Skripte auf dem fli4l 
die Konfiguration an welcher Stelle auslesen. Woher "weißt" du denn, welche 
Änderungen sich auf welche Komponenten auswirken? Stell dir einfach vor, du 
änderst OPT_IPV6 von 'no' auf 'yes' (oder umgekehrt). Dies ist eine "winzige 
Änderung" in der rc.cfg, sie betrifft jedoch so ungefähr fünfzig 
verschiedene Skripte, hat das Einbinden diverser zusätzlicher Dateien zur 
Folge und bringt einen Haufen an zusätzlichen Anforderungen an die 
Konfiguration mit.

> Und ich verwendete ihn seit 1.6.x. DA gab es sogar mal ein Windows-GUI
> Programm das die parameter-eingabe und Erstellung der routerdisks bot.
> Eine eingebaute Hilfe zu den Optionen war M.W. zumindest "angedacht".
> Jedenfalls gab es IMHO direkt bei Änderung eine Warnung das sich diese
> auf anderes auswirkt und beim deaktivieren verschwand dann auch der
> zugehörige Block an werten. Das war praktisch.Eindeutig für den Normalen
> User leichter verständlich und einfacher. Aber: Gibt es nicht mehr!

Das ist sehr einfach zu beantworten: Vor der 2.0 war die Menge der 
Konfigurationsoptionen fest. Es gab keine Möglichkeit, den fli4l durch 
externe Pakete zu erweitern. Wenn man eine feste Menge von 
Konfigurationsoptionen hat, dann kann man auch sehr einfach eine 
Konfigurationsanwendung dafür schreiben und auf diese Einstellungen hin 
optimieren. Wenn man hingegen eine variable (und unterschiedlich getypte) 
Menge von Konfigurationsoptionen hat, wird das um einiges schwieriger, vor 
allem dann, wenn es nicht eine endlose Liste von Variablen und 
Eingabefeldern werden soll.

> Stattdessen blafft mir mkfli seine Fehlermeldungen vor, und wenn ich das
> Fenster schließe sind die infos weg. Also darf ich es nicht zu machen,
> sondern muss gleich nach den monierten werten in den config-dateien
> suchen und es erneut probieren. Bestenfalls unpraktisch, meine ich. Oder
> schreibt der die irgendwo in ein log?

Sicher.

> Sicher nicht einfach. Ich stelle mir das mal so vor: imonc kommuniziert
> eh mit dem FLI.

Schon ein falscher Ansatz. Für dich mag das imonc/imond-Duo das Nonplusultra 
des fli4l sein, viele jedoch setzen diese Programme gar nicht ein, allein 
schon deshalb, weil sie gar kein Windows nutzen! Auch dafür muss es Lösungen 
geben.

> Und dort hab ich den pfad zu den configs eingetragen.

Zu welchen Konfigurationen? Anwender im semiprofessionellen Umfeld 
konfigurieren an die 10-50 fli4l-Installationen mit entsprechend vielen 
Konfigurationen. Wie willst du das mit imonc vernünftig in den Griff 
bekommen?

> Wenn jetzt eine datei auf dem router geändert würde (bietet das
> dateisystem dafür nicht einen event-support an?) dann braucht imond die
> config nur an imonc zurück übertragen. Klingt für mich "relativ"
> einfach, aber ich könnte es nat. nicht.

Die Konfiguration ist eine Abstraktion der Situation auf dem Router. Während 
du in der Konfiguration DOMAIN_NAME='lan', HOST_1_NAME='test' und 
HOST_1_IP4='1.2.3.4' schreibst, steht auf dem Router

  1.2.3.4 test.lan test

in der /etc/hosts.d/hosts.dns drin. Das ist nicht automatisiert 
"zurückzuportieren", es müsste für jedes Paket, jedes OPT und jedes die 
Konfiguration auslesende Skript Code geben, der diese Rückwärtsumsetzung 
macht. Abgesehen davon ist nicht jede Änderung auf dem fli4l kompatibel mit 
der Ausgangskonfiguration, da ich auf dem fli4l alles mögliche machen kann, 
also auch Dinge wie

-  1.2.3.4 test.lan test
+  1.2.3.4 test2.lanx test3

was nicht mit Hilfe einer fli4l-Konfiguration erreicht werden kann (wenn die 
Domäne ".lan" bleibt und es noch andere Einträge mit ".lan" gibt).


Gruß,
-- 
Christoph Schulz
[fli4l-Team]