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

[Kay Martinen]

Am 01.12.2014 um 23:48 schrieb Hans Bachner an Christoph Schulz:
> 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.

Ich weiß jetzt nicht welche, wo liegt, würde als FLI user aber vorziehen
eine cfg zu belassen die nicht irgendwo verpackt ist. So das man ggf.
bei Problemen von außen ran kommt, z.b. mit einem Live-System.

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

Auch sus eben dem Grund mein Obiger Einwurf. Allerdings sehe ich auch
die Möglichkeit das die fehlende Konfigurierbarkeit als "Security by
Design" gedacht ist. Kann das sein?
Wenn die nicht einfach zugänglich ist kann sie bei einem Hack-versuch
auch nicht manipuliert werden. Andererseits kann ein Hacker der schon
auf der router-shell ist vermutlich eh alles erreichen. Nicht nur /etc

Aber: Ich wünsche mir eine Möglichkeit das man auf dem Build-PC eine
Konfiguration ändert, auf den FLI schiebt (z.b. per imonc) und dieser
statt eines Reboot nur ein schnelles neu starten aller (oder
betroffener) Dienste macht. Also z.b. grob geschnitzt

copy cfg
dialmode=manual, hangup
restart all
dialmode=auto

sollte auf jedem Router-PC schneller gehen als ein komplett Reboot aber
genau so gut sein. Ich meine jetzt nur bei Änderungen an der konfig die
keine Module de-aktivieren, sondern reine parameter-änderungen sind.
Z.b. die hosts liste, firewall-einstellungen u.a.




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

Wenn mein FLI 3 min. und mehr braucht für einen Neustart, aber
vielleicht nur wenige sekunden um alle Dienste neu zu starten
(serverdienste gehören ja eh per Design nicht auf den router) dann finde
ich das alles andere als irrelevant. Da nun auch der Trend zu VOIP geht
wären das immer noch fast 3min der nicht -Erreichbarkeit gegenüber X
sekunden als Beispiel. Und es hört ja nicht auf, Internet scheint immer
wichtiger zu werden, man denke nur an IPTV u. was noch alles kommt.
Dinge die man eben nicht gern unterbrechen will.... ohne gleich von
Sucht zu reden. Nicht an jedem FLI hängt nur ein Nutzer! Wäre es so,
bräuchte man keinen Router, nur ein DSL-Modem!

>> Prüfungen
>> und Aktionen mkfli4l so macht, um die Installationsarchive zu bauen.

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.

>> Dieses
>> Wissen ist sicherlich "advanced" und nicht einem "normalen" Nutzer
>> zuzumuten.

Eben, ich bin ja nur ein normaler. Kann man das einfacher vermitteln
warum obiges nicht gehen sollte?

> 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

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!
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?

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

Sicher nicht einfach. Ich stelle mir das mal so vor: imonc kommuniziert
eh mit dem FLI. Und dort hab ich den pfad zu den configs eingetragen.
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.

Ich finde auch nicht das so was Priorität bräuchte. Mir wäre lieber ein
schnelles übertragen der konfig-dateien und eine übernahme ohne reboot.

> 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?

Gute Erklärung. Das sehe ich genau so.

Kay