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

[Christoph Schulz]

Hallo!

Hans Bachner schrieb:

> Wenn man die Änderung *nur* in der /boot/rc.cfg einträgt, dann ja.
> Wenn man aber die von dnsmasq verwendeten Konfigurations-Dateien kennt,
> ist das Hinzufügen eines Hosts mit dem Editieren einer, maximal zwei
> weiterer Datei(en) und einem anschließenden
> 
> # killall dnsmasq
> # dnsmasq --min-port=4096
> 
> erledigt. (Bitte nicht in die Doku aufnehmen - das war jetzt aus dem
> Gedächtnis.)

Genau darum geht es mir aber: Woher weißt du, auf welche Teile des Systems 
sich die Konfigurationsänderungen auswirken? Kannst du mir aus dem Kopf 
sagen, was alles angepasst werden muss, wenn man OPT_IPV6 von 'no' auf 'yes' 
setzt? Selbst _ich_, der in den letzten Jahren maßgeblich an der Entwicklung 
vom ipv6-Paket beteiligt war, könnte dir eine solche Aufzählung nicht 
liefern!

> - weil ich bei einem Reboot nicht nur für mich selbst den
> Internet-Zugang unterbreche.

Ja, das ist ein valides Argument. Aber auch hier stellt sich dieselbe Frage: 
Welche Änderungen an der Konfiguration haben Auswirkungen auf die Internet-
Anbindung? Das Hinzufügen von ACLs zur WebGUI sicher nicht. Das Ändern der 
MTU der Netzwerkkarte, über welche die Internet-Anbindung erfolgt, 
sicherlich. Wie will man diese Abhängigkeiten in den Griff bekommen?

Ich habe hier zuhause eine FritzBox laufen. Auch diese bootet bei den 
meisten Konfigurationsänderungen. Und das in meinen Augen zu Recht -- die 
Entwickler haben sich entschieden, die funktionale Vorhersagbarkeit 
wichtiger zu nehmen als eine potentiell erhöhte Benutzerfreundlichkeit 
(potentiell nur deshalb, weil im Falle einer Fehleinschätzung die Dienste 
ohne den Reboot eben doch nicht 100%-ig arbeiten, was sich wieder negativ 
auf die Benutzerlaune auswirken kann).

> Um es auf den Punkt zu bringen: um die Funktionalität zu erweitern, ist
> (in der Regel) tatsächlich ein neuer Build, Upload und Reboot nötig.
> Wenn es aber nur um - sagen wir einmal: Konfigurations*daten* geht, ist
> das doch Overkill und bringt ernsthafte Einschränkungen beim Zeitpunkt,
> an dem eine Änderung durchgeführt und/oder zur Geschwindigkeit, mit
> dem sie wirksam werden kann, mit sich.

Sicher. Ich habe das auch im Hinterkopf. Die Umsetzung ist aber immer 
schwieriger, als man denkt, insbesondere wenn man berücksichtigt, dass das 
fli4l-Projekt vor 14 Jahren nicht mit dieser Anforderung entworfen wurde. 
Mit anderen Worten: Die Code-Basis gibt das zur Zeit nicht her. Und es wird 
ein langer Weg werden, das zu ändern.

> Ich meine, die Möglichkeit so eines Eingreifens über die offiziellen
> Schnittstellen hinaus ist eine der großen Stärken des fli4l-Projektes.

Sorry, da mache ich nicht mit. Ich bin Entwickler und weiß, was es heißt, 
wenn irgendjemand "über die offiziellen Schnittstellen hinaus" auf ein 
System zugreift. Wenn keine benötigten Schnittstellen da sind, müssen 
entsprechend welche geschaffen werden. Punkt. Dass es auch anders geht ist 
klar, es bleibt jedoch immer eine Frickel-Lösung. Und dass dies eine Stärke 
des fli4l-Projekts ist, spricht nicht gerade für die API, die von fli4l 
angeboten wird. Mich erinnert dies an DOS vs. Windows: DOS hat kaum API 
geboten (außer für den Zugriff aufs Dateisystem), und fast alle Programme 
haben sich dadrumgemogelt und direkt aufs BIOS oder die Hardware 
zugegriffen. Dadurch konnten tolle Programme geschrieben werden, die aber 
nicht vernünftig zusammengearbeitet haben. Dann kam Windows, schob dem 
direkten BIOS- und Hardware-Zugriff einen Riegel vor, und nun wurden die 
Programme zwar weniger individuell, dafür aber haben sie i.d.R. problemloser 
zusammengearbeitet, und Dinge wie Multitasking waren -- verglichen mit DOS-
Lösungen -- wirklich zuverlässig.


Viele Grüße,
-- 
Christoph Schulz
[fli4l-Team]