[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