[fli4l] IPs/Netze vone?==?utf-8?Q?inander trennen Fragen üb?==?utf-8?Q?er Fragen

[Hans Bachner]

Hallo Christoph,

danke für deine ausführliche Antwort.

Christoph Schulz schrieb:

>>>  Zweitens: An vielen Stellen im Code wird (zu recht!) angenommen,
>>>  dass
>>>  die Inhalte von /etc/rc.cfg und /boot/rc.cfg identisch sind.
>>  
>>  Warum wird hier doppelt gemoppelt? Warum wird die Konfiguration noch
ein
>>  zweites Mal in das rootfs verpackt? Wenn man sie dort haben will
kann
>>  man sie ja auch während des Bootens aus dem /boot Verzeichnis
dorthin
>>  kopieren. Welcher Code schaut sich die /etc/rc.cfg an?
> 
> Nun, die Archive wurden auf Basis der Konfiguration in /etc/rc.cfg
> gebaut.

Nun, ob der Build-Prozess seine Infos in der einen oder anderen Datei
sammelt und sie am Ende in die andere kopiert, ist wohl nicht von
strategischer Bedeutung und auch nicht in Stein gemeißelt.

> Insofern hast du Recht, dass die Redundanz (die vermutlich
> historisch
> bedingt ist) natürlich nicht schön ist. Jedoch würde ich deshalb
> irgendwann
> den anderen Weg gehen, nämlich die /boot/rc.cfg wegzulassen und
> die
> Konfiguration nur noch aus /etc/rc.cfg auszulesen.

Ich würde es genau umgekehrt machen, wenn aus historischen Gründen
eine /etc/rc.cfg erforderlich ist.

> Mal ehrlich: Das nachträgliche Ändern der Konfiguration in /boot
> ist doch
> Hackaround ohnegleichen.

Nein - das ist ein Workaround für die (noch) fehlenden
Konfigurationsmöglichkeiten auf dem Router selbst.

> Das eine Argument ist bislang "ich mach's, weil
> ich es kann (und weil es geht, wenn ich aufpasse)" (das andere
> Argument mit
> der Zeitersparnis greife ich weiter unten auf). Das ist sicherlich
> kein
> tragfähiges Konzept und sollte nicht künstlich am Leben gehalten
> werden. Vor
> allem kann man nur dann überblicken, was geht und was nicht geht,
> wenn man
> im Detail verstanden hat, wie Pakete aufgebaut sind und was für
> Prüfungen
> und Aktionen mkfli4l so macht, um die Installationsarchive zu bauen.
> Dieses
> Wissen ist sicherlich "advanced" und nicht einem "normalen" Nutzer
> zuzumuten.

Ich halte es absolut nicht für die Lösung, die man einem neuen
fli4l-Nutzer ans Herz legen sollte. Aber es ist für erfahrenere Nutzer
eine Möglichkeit, (noch) fehlende Funktionalität auf einfache Weise zu
ersetzen. Ich verwende fli4l seit der Version 2.0.4 (ca. 2002) - mit ein
Grund dafür ist, dass der Router eben *keine* Black Box ist und ich bei
Problemen oder Wünschen auf Gedeih und Verderb auf den
Router-Hersteller angewiesen bin.

Und selbst bei den "Black Box" Routern, die zumindest einen
telnet/ssh/ftp-Zugang bieten, kann ich Konfigurationsdateien ändern,
ohne gleich ein Firmware-Update machen zu müssen. Natürlich kann auch
bei diesen Routern nicht alles übers Web-Interface konfiguriert
werden.

> Allerdings gebe ich dir hiermit Recht:
> 
[schnipp]
> 
> Eine Verknüpfung von WebGUI und Persistenz (und ein Rückkanal zu
> der
> Konfiguration auf dem Build-Host) wäre eine feine Sache. Leider
> sind hier
> viele Fragen zu klären, viele Probleme zu wälzen und natürlich
> geeignete
> technische Lösungen zu entwickeln. Nicht unmöglich, aber sicher
> nichts für
> "so mal nebenbei".

Erst einmal danke für die Zustimmung in der Sache.

Dass so ein Teil-Projekt nicht in drei Abenden erledigt ist, ist mir
(vor allem als auch-Software-Entwickler) völlig klar. Worum es mir in
diesem Beitrag geht: der - wenn auch wacklige - Steg sollte nicht
abgerissen werden, bevor die neue Brücke steht.

> Mein ursprünglicher Beitrag sollte eigentlich auch nur darauf
> hinweisen,
> dass es _nicht_ ratsam ist, die /boot/rc.cfg nachträglich zu
> verändern.

Ja, eh.

> Und
> bei diesem Standpunkt bleibe ich ;-) Jegliche unerwünschte
> Konsequenzen, die
> aus einem solchen Handeln resultieren, sind hausgemacht.

Ist klar.

> Es gibt keinen "offiziellen Support" dafür.

Den verlang ich auch gar nicht. Wenn sich aus einer (direkten) Änderung
der boot.cfg ein Problem ergibt, werde ich hier sicher nicht motzen -
sondern (wenn ich den Grund nicht selbst ermitteln kann) halt einmal
nach den Gründen fragen. Ich erwarte sicher nicht, dass ein geändertes
Verhalten automatisch sofort als Bug eingestuft wird. 

Wenn es aber gute Gründe für das alte Verhalten gibt, erwarte ich
schon, dass diese in die Überlegungen des Teams mit einfließen.
Mutwilliges Abdrehen von Möglichkeiten ohne echten Mehrwert sollte imho
nicht vorkommen, das wäre eine Missachtung der Anwender, denen ja das
ganze Projekt letztlich zugute kommen soll.

> Was ich bei der ganzen Diskussion nicht verstehe: Wenn man (z.B.)
> zusätzliche Hosts in der /boot/rc.cfg eintragen will, dann muss man
> den
> Router doch ohnehin booten.

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.)
Mit ein paar Befehlen mehr werden sogar die
dnsmasq-Konfigurationsdateien automatisch neu gebaut.

Bei den aktuellen Tarball-Versionen geht es auch einfacher, da kann
zumindest die laufende Konfiguration schon über das Web-GUI modifiziert
werden; es braucht dann wirklich nur noch für Persistenz gesorgt werden
(/boot/rc.cfg).

> Warum dann nicht einfach den normalen Weg gehen
> (Konfiguration auf Build-Host ändern, Archive bauen, Router
> aktualisieren,
> booten)? Das kostet vielleicht zwei Minuten mehr, ist aber sauber
> (es kann
> nichts kaputt gemacht werden, weil mkfli4l alles überprüft) und
> unterstützt. 

- weil der Router, um den es geht, nicht immer neben mir steht, und bei
der Upload-Geschwindigkeit meines DSL Anschlusses zu Hause ein
mehrfaches von den genannten zwei Minuten für ein Update zur Folge
hätte
- weil ich bei einem Reboot nicht nur für mich selbst den
Internet-Zugang unterbreche. Im günstigsten Fall hab ich "nur" die
Familie am Hals, mittleres Szenario ist ein Büro mit einem halben
Dutzend Mitarbeitern. Ich hab fli4l aber auch schon auf Jugendlagern mit
vier- oder fünftausend Teilnehmern eingesetzt, der Internetzugang war
sowohl für die Administration als auch für die Programmgestaltung
essenziell.

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.

Außerdem: wegen eines zusätzlichen Host-Eintrags neu zu booten, ist
nicht einmal mehr unter Windows notwendig. Und hier ist Linux. Wo bleibt
da meine schöne Uptime?

======
fli4l läuft seit:
378 Tagen, 14 Stunden und 10 Minuten
======

Ich meine, die Möglichkeit so eines Eingreifens über die offiziellen
Schnittstellen hinaus ist eine der großen Stärken des fli4l-Projektes.
Ich hab halt nicht die Zeit, für alles, was ich mir wünsche, eine
Lösung zu produzieren und bin daher für diese Flexibilität sehr
dankbar. Mein bisher einziger Beitrag (zum opt cpmvrmlog) ist schon
einige Jahre her - will sagen, wenn ich wirklich die Zeit aufbringen
kann, behalt ich das Ergebnis auch nicht für mich.

Danke fürs bis hierher Mitlesen.

Schöne Grüße,
Hans.