Hallo,
in gefühlt jedem Topic in dem es um Änderungen an den Einstellungen geht wird vor der Updatefestigkeit gewarnt.
Meine Vermutung ist jedoch, daß diese Angst unbegründet oder gar falsch ist. Eine Einstellung wie Mesh-on-LAN z.B. landet doch auch wie das per GUI verfügbare Mesh-on-WAN in /etc/config/network. Meine Erfahrung mit dem letzten (manuellen) update zeigte mir, daß diese Änderungen auch nach dem Update noch vorhanden waren.
Klar, theoretisch kann ein Update alles verändern, aber sinnvoller Weise wird dabei Rücksicht auf vorhandene Einstellungen genommen bzw. diese Config-Files erst gar nicht angefasst.
Wer hat sich den Code schon mal angeschaut und kann gesicherte Fakten hierzu nennen?
Interessant wäre hier sicherlich auch was alles vor einem Update Rollout getestet wird und ob es eine entsprechende vorherige Kommunikation geben würde falls ein Update Einfluss auf vorhandene Einstellungen hätte.
Bitte nur das Thema Updatefestigkeit behandeln, es soll hier nicht darum gehen welche Änderungen sinnvoll sind, ob es andere Lösungswege gibt oder wer überhaupt Änderungen vornehmensollte bzw. wer besser nicht.
Ich habe nirgends gelesen, MoW-Settings seien nicht updatefest.
Problem sind aber Port-Configs wie „LAN auf brwan bridgen“ oder „brclient nur auf bestimmte LANports“.
Oder auch Firewall-Setting wie „Statusseite/Webserver auch auf BRwan-ipv4“.
Die gehen bei einem Update verloren… leider mehrfach erlebt.
Spätestens wenn die zugrunde liegende OpenWRT Version sich für ein Gluon Build ändert, wars das mit speziellen Netzwerk Configs. Baut man sich jetzt nen Gluon aus dem aktuellen Master Branch, so ändern sich z.B. die Interface Namen.
Meine Lösung für das Problem:
In rc.local ein Skript schreibt der meine eigene Daten auf vorhanden sein überprüft und sollten sie weg sein (nach ein Update) schreibt er sie neu. Sowie Firewall Einstellungen (Die rc.local wird beim update gesichert)
Bei MoW hatte ich diese Warungen bisher auch noch nicht gelesen, aber bei MoL dann schon, deshalb der Hinweis auf die gleiche Config-Datei und eigentlich nur minimalem Unterschied zwischen beiden Sachen.
Etwas unverständlich warum eins problemlos sein soll, das Andere jedoch nicht.
Die Switch-Einstellungen sind ja auch in der Datei, warum werden diese dann nicht übernommen?
Wenn das wirklich der Fall sein sollte, dann wären die Warungen berechtigt aber hinnehmen sollte man die Situation nicht, also quasi ein Bug. Der Updateprozess sollte das berücksichtigen.
Ich nehme mal an es wird die /etc/config/network beim Update nicht einfach überschrieben sondern bekannte Einstellungen in die neue Version übernommen, sonst wäre MoW ja auch weg. Ist das der Fall und die Switcheinstellung z.B. wird nicht übernommen weil nicht damit gerechnet wird das diese verändert wurde?
Ganz so einfach wird es dann aber wohl auch nicht sein. Ich würde erwarten, daß der Updateprozess die Datei nur anpackt, wenn wirklich Änderungen zwischen den Versionen nötig sind oder sie sonst einfach unverändert übernimmt.
Bei Änderungen müsste dann ein merge zwischen alt und neu stattfinden.
Wenn du jetzt nur kopierst verwirfst du quasi die neuen Sachen.
Dir mag das gesagt worden sein. Meine Erfahrungen sind teilweise andere. Die Firewalleinstellungen kann man per UCI verdrehen… und bleiben NICHT erhalten.
Aus Interesse: In welchem Fall muss man die Firewall anfassen?
Ich finde die Situation auch nicht so schlimm. Gluon läuft imo out of the box gut, wenn man aufwendigere Installationen baut hat man halt etwas Administrationsaufwand. Autoupdate aus. Kopien von /etc/config/network und eventuell /etc/config/wireless ziehen. Kann man dann oft einfach zurückspielen oder als Vorlage verwenden. Ausnahme POE passthrough.
Vor allem wird Gluon weiterentwickelt, in Zukunft ist mit Verbesserungen zu rechen.
Wenn einem die Standard-Config von Gluon/site.mk nicht gefällt.
(Ist hier aber off_topic, daher gehe ich NICHT drauf ein. Threads teilen werde ich hier nicht mehr, das gibt nur böses Blut)
Was ich definitiv für einen Mythos halte, ist dieses: „Änderungen im Config-Interface sind sicher, solche per ssh nicht.“ Was sollte es für Updatefestigkeit für einen Unterschied machen, ob schon jemanden ein Klick-Interface geschrieben hat oder nicht?
Mesh-on-LAN hat zumindest die letzten zwei Updates gut überlebt. …
Bei Updates muss zwischen lokalen Communityupdates mit neuen Einstellungen (z.B. Änderung an der Paketzusammenstellung, Änderungen an der site.conf, usw.) und Gluon Updates z.B. von 2014.3 auf 2014.4 und demnächst 2015.x) unterschieden werden.
Bei den Einstellungen muss zwischen allem, was in LuCi gesetzt wurde, also offiziell von Gluon unterstützt wird, und allem was per UCI reingesetzt wurde, unterschieden werden. Wobei WAN-Mesh, auch wenn es per uci gesetzt wurde, zu ersterem zählt.
Lokales Updates überlebt eigentlich alles, Gluon Updates überleben nur die in LuCi offiziell unterstützten Einstellungen, wie z.B. WAN-Mesh.
Es ist definitiv kein Mythos. Aktuell geht zwar noch nichts kaputt, wir planen jedoch Änderungen an Gluon, die so etwas prinzipiell kaputt machen könnten. Beispielsweise soll /etc/config/network bald nach jedem Durchlauf des Configmodes komplett neu generiert werden um erweiterte Portkonfigurationen (je Port zwischen mesh, wan, lan, usw. wählen) einfacher umsetzen zu können. Ähnliches ist für /etc/config/wireless. Alles was bisher im Config und Expertmode einstellbar war, wird dann natürlich auch noch funktionieren. Wenn dann aber jemand z.B. WAN und LAN Ports getauscht hat, geht das kaputt.
Und da kommen wir eigentlich schon zum akuten Problem, das häufiger auftreten dürfte und zum Mythos geführt hat:
Wenn man in der /etc/config/network WAN und LAN Port tauscht, muss man auch unbedingt /lib/gluon/core/sysconfig/wan_ifname und lan_ifname tauschen. Ansonsten setzt das nächste Update die config anhand der sysconfig Einträge neu und man hat, jenachdem welcher Anleitung zum Tauschen man gefolgt ist, sein LAN mit dem Freifunk gebridged.
Statt einer einzelnen Config (/etc/config/network) könnte man ein Verz. /etc/confi/network anlegen, wo man eine beliebige Anzahl Config-Files anlegen kann, die mit einem Zahlen-Präfix versehen sind, um die Reihenfolge der Auswertung kontollieren zu können - ähnlich wie init.d das macht.
Darin könnte dann eine „10gluon.conf“ liegen, die komplett und allein durch Gluon selbst verwaltet wird, und zusäzlich eine Datei „20usernetwork.conf“
Alles, was man in der 2. Datei unterbringt wäre dann updatefest, und würde erst NACH der Basisconfiguration von Gluon angewendet.
Ähnlich kann man dann mit /etc/config/wireless usw. verfahren.
So etwas ähnliches ist geplant, allerdings muss dazu zunächst einmal UCI erweitert so erweitert werden, dass die Patches von auch von OpenWrt akzeptiert werden. Die Übergangslösung ist dann erstmal das neuschreiben.
Ist wahrscheinlich 'ne dämliche Frage:
Werden die Dateien in /etc auf Basis der uci-Einstellungen überschrieben oder werden die uci-Einstellungen auf Basis der Dateien in /etc angepasst?
Oder nix von beidem?