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

Christoph Schulz fli4l at kristov.de
Do Nov 27 09:35:31 CET 2014


Hallo!

Hans Bachner 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. 
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.

Mal ehrlich: Das nachträgliche Ändern der Konfiguration in /boot ist doch 
ein Hackaround ohnegleichen. 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.

Allerdings gebe ich dir hiermit Recht:

> Die Mindest-Voraussetzung für eine derartige Änderung (Boot-Vorgang
> anhalten) wäre die Möglichkeit, Änderungen an der Host-Liste (samt
> DHCP-Infos) über das Web-Interface persistent eintragen zu können.
> Bitte vorher keinesfalls derartig weitreichende Beschränkungen
> einführen!

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

Mein ursprünglicher Beitrag sollte eigentlich auch nur darauf hinweisen, 
dass es _nicht_ ratsam ist, die /boot/rc.cfg nachträglich zu verändern. Und 
bei diesem Standpunkt bleibe ich ;-) Jegliche unerwünschte Konsequenzen, die 
aus einem solchen Handeln resultieren, sind hausgemacht. Es gibt keinen 
"offiziellen Support" dafür.

> Ich hab auch zwei Test-Router, auf denen ich von Fall zu Fall
> unterschiedliche NICs, WLAN-Adapter oder UMTS-Sticks (alle über USB)
> verwende. Dafür habe ich schon einmal alle notwendigen Treiber auf dem
> fli4l und wähle den richtigen durch einfaches Editieren der
> /boot/rc.cfg aus. Das hat bis jetzt immer prima geklappt. Zugegeben, das
> ist nicht gerade ein Fall, den hunderte fli4l Benutzer im Alltag
> verwenden - praktisch und zeitsparend ist diese Möglichkeit allemal.

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. 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. 
Was heißt hier also "zeitsparend"? Es geht um diese zwei Minuten? Oder geht 
es hier um größere Zeitersparnisse?


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



Mehr Informationen über die Mailingliste Fli4L