OpenWrt Hinzufügen eines neuen Repos

[Der Eifelsachse]

Hallo Freunde!
Eigentlich kenne ich mich mit OpenWrt ganz gut aus, aber ich bin jetzt an einem Punkt angelangt, wo ich nicht weiter weiß und um einen "Denkanstoß" bitte.

Ich betreibe (ja, wie schon oft gepostet) ein Netz aus 9 WireGuard-Routern + 9 Ersatzgeräten. Die hohen aktuell Temperaturen ... veranlassen mich, mir die Betriebstemperaturen meiner Geräte zumindest etwas zu überwachen. Dafür gibt es ja zwei gut funktionierende Lösungen:
1. Die vollständige grafische Anzeige mit luci-app-statistics und collectd-mod-thermal.
2. Die Integration der Temperatur in Status > Übersicht mittels luci-app-temp-status.

Beide Lösungen machen genau das, was sie sollen. Problemlose Installation. Nur, gerade auf den als Reservegeräte genutzten FRITZ 7412 ist die Variante 1 einfach "zu fett" und fällt damit aus. Also überall Variante 2 installiert.

Das Problem, an dessen Lösung ich momentan scheitere:
Das Paket luci-app-temp-status ist leider "nur" über Github (github.com/gSpotx2f/packages-openwrt/raw/master/25.12/luci-app-temp-status-0.8.1-r1.apk) erhältlich und nicht in den üblichen OpenWrt-Repos enthalten, was dadurch bei den Upgrades zu einer zu erwartenden Fehlermeldung führt. [Obigen Link absichtlich nicht ausführbar gemacht ]

Ich suche also jetzt eine Lösung, wie ich entweder dieses Paket bewusst dauerhaft von den Upgrades ausklammern oder in die customfeeds.list einfügen kann. Alle gefundenen oder (anhand der vorgegebenen Beispiele) erratenen Strings führten immer zur Fehlermeldung.
Irgendwie trete ich da jetzt auf dem Schlauch.

Würde mich über eine hilfreiche Antwort sehr freuen.
vy 73 de Peter

 

[blurrrr]

Hi,

ein Github-Link ist allerdings kein apk-Repository, von daher würde ich diesen Gedanken mal verwerfen. Wie ist es denn, wenn Du die Version anpinnst (s. https://wiki.alpinelinux.org/wiki/Alpine_Package_Keeper#Package_pinning) - kommt dann immer noch die Fehlermeldung?

Alternativ... Findest Du es nicht etwas mühsam, auf jeder Kiste einzeln nachzuschauen? Soweit ich weiss, gibt es bei OpenWRT auch SNMP. Wenn die Temperaturen dort auch mit ausgegeben werden, könntest Du einfach bei Dir zentral etwas laufen lassen, was sich via SNMP die Daten der anderen Büchsen (via VPN) holt. Zudem könntest Du dann auch noch überlegen, ob Du Dich bei Überschreitung von Schwellwerten benachrichten lässt.

Hab nur leider so gar keine Ahnung von OpenWRT, von daher diese Dinge nur mal so als kleine Info. Wie genau die Dinge dann umzusetzen sind unter OpenWRT... keine Ahnung

 

[Der Eifelsachse]

Hi @blurrrr und vielen Dank für deine Antwort!

Ich gehe mal davon aus, dass in deinem ersten Satz die zielführende Antwort steht. Ich werde an dieser Stelle weiter graben. Und mich - so wie es sich gehört - wieder melden.
Gedanken über eine zentrale Erfassung oder automatisierte Meldungen hätte ich mir an dieser Stelle gemacht, als ich noch "In Lohn und Brot" stand. Heute ist das alles nur noch Hobby. Aber wenn die Langeweile mal hoch kommen sollte, werde ich darüber nachdenken. Nur so nebenbei: mein gar nicht mehr so kleines WireGuard-Netz läuft immerhin fast völlig störungsfrei seit Mitte 2019! Es wurden lediglich zwei der vier F!B4040 durch Cudys ausgetauscht.

vy 73 de Peter

 

[Confluencer]

@Der Eifelsachse hast Du schon versucht, ob es mit owut download --remove luci-app-temp-status funktioniert?

Wenn an owut selbst die Liste der Pakete mitgeben könnte, könnte man sich auch ein entsprechendes Wrapper-Skript bauen, dass die aktuelle Liste um die Ausnahmen bereinigt und dann entsprechend das Image zum Bau beauftragt. Wobei es in der Doku von owut nicht so aussieht, als wenn man die List selbst angeben könnte (oder macht `--add` das?)

 

[Der Eifelsachse]

Es ist schön zu erleben, wie in einem guten Forum versucht wird, einander zu helfen. (OK, ich mache das in den Foren, wo ich aktiv bin, ja genau so ... .) Das ist das, was für mich "Forum" ausmacht!

Zu deinem Beitrag, @blurr:
Ich habe mir alle in deinem Link aufgezeigten Möglichkeiten intensiv vorgenommen und (an einem der Reservegeräte) durchexerziert. Aber es war nicht das dabei, was ich erreichen wollte. Ich kann zwar, wenn ich selbst per Script ein selektives Upgrade vornehmen will, dieses damit tun, aber den owut-Befehl damit dauerhaft beeinflussen konnte ich nicht. (Kann auch locker mit meiner Unerfahrenheit in dieser Hinsicht zu tun haben.) Auf jedem Fall habe ich wieder etwas gelernt.

Zum Beitrag von dir, @Confluencer:
Auch mit owut habe ich mich schon recht intensiv befasst. Ich denke da speziell an

--ignored-changes IGNORED_CHANGES

Wir denken hier wohl in die gleiche oder ähnliche Richtung.
Ich könnte mir vorstellen, "irgendwie" dem Programm "owut" eine Liste vorzusetzen, dessen Inhalt nur aus dem einen Programm besteht, welches eben von vorn herein aus dem Update auszuschließen ist. Logisch wäre mir das. Nur das "wie" ist mir eben noch nicht ganz klar. Man kann ja eine Liste der zusätzlich installierten Programme erzeugen lassen. Und da würde ich einfach mal alles, außer eben "luci-app-temp-status" löschen und diese Datei dann als "IGNORED_CHANGES" speichern. Versuch macht kluch .... .

BTW: Ich finde es spannend, mich mit einem Betriebssystem, welches ich nie offiziell gelernt habe, intensiv zu beschäftigen.

vy 73 de Peter

 

[blurrrr]

Aber es war nicht das dabei, was ich erreichen wollte. Ich kann zwar, wenn ich selbst per Script ein selektives Upgrade vornehmen will, dieses damit tun, aber den owut-Befehl damit dauerhaft beeinflussen konnte ich nicht.

Achso, da wird standardmässig owut genutzt? Dachte da geht es dann einfach via "apk upgrade" (daher auch eher Richtung apk mit Versionspinning).

 

[Der Eifelsachse]

Wars wohl auch nicht:

ERROR: Package 'luci-app-temp-status-0.8.1-r1' is not available on this platform

Es wird also immer im offiziellen oder einem weiteren eingetragenen Repo gesucht. Ich habe gedacht, dass ich einfach ein einzelnes Programm aus dem Upgrade ausschließen kann.

Ja, ich mache das mit einem automatisch startenden Script, welches ein Gerät nach dem anderen per ssh antriggert und dort "owut upgrade" aufruft.

So, für den alten Mann reicht es für heute. Jetzt kommt der Hund zu seinem Recht!
Achtung: Das jetzt folgende ist definitiv [OT]!

 

[blurrrr]

Ja, ich mache das mit einem automatisch startenden Script, welches ein Gerät nach dem anderen per ssh antriggert und dort "owut upgrade" aufruft.

Wenn an owut selbst die Liste der Pakete mitgeben könnte, könnte man sich auch ein entsprechendes Wrapper-Skript bauen, dass die aktuelle Liste um die Ausnahmen bereinigt und dann entsprechend das Image zum Bau beauftragt.

Dann vermutlich owut upgrade -r luci-app-temp-status . Aber so oder so scheint es, als müsse man das Paket dann auch wieder nachträglich installieren. Alternativ halt vorher manuell deinstallieren, Upgrade durchführen und Paket erneut installieren.

Macht ja schon einen etwas "lästigen" Eindruck...

 

[Confluencer]

achte da geht es dann einfach via "apk upgrade" (daher auch eher Richtung apk mit Versionspinning).

Jein, es wird explizit davor gewarnt das System per apk upgrade aktuell zu halten, da es passieren kann das einem dabei das System zerschießt. Der Hinweis ist explizit nicht diesen Weg zu gehen, ausser man wird im Rahmen eines Austausches mit einem OpenWRT-Entwickler darauf hingeweisen ein oder mehere Pakete zu aktuallisieren.

Damit die Versionen auch sauber zusammenpassen baut man bei OpenWRT ein neues Image und spielt es ein.

owut upgrade -r luci-app-temp-status

Genau in die Richtung ging mein Gedanke. Nur das ich es erstmal nur bauen und herunterladen lassen würde (deswegen download statt upgrade) - im Gegensatz zum upgrade spielt es das Image nach dem herunterladen nicht ein.

Bei OpenWRT bedeuet update ein neues Image zu flashen. Owut koordiniert quasi das Zusammensammeln der installierten Pakete, das Übermitteln der Modell-Version und Paket-Liste, holt das Image ab sobald es fertig ist und spielt es bei upgrade auch direkt ein.

Es wirkt so, als wenn der Image Builder den Feed kennen muss - was kein Problem wäre, wenn man einen eigenen betreiben würde. Ein eigener Image Builder (gibt es auch als Docker image) könnte auch ein "First start" Skript ausführen, dass bspw. das benötige Paket installiert.

Kann man dem Remote Image Builder überhaupt eine eigene Liste von Feeds mitgeben?

Bisher wirkt es nicht danach, als wenn Feeds tatsächlich die Lösung für das Problem sind - zumal die apk-Pakete eben nicht in einem Repository liegen. Dabei wäre es für den Ersteller des Repos eignetlich nicht mal aufwändig ein apk-Repository mittels GitHub-Pages bereitzustellen.

 

[blurrrr]

Jein, es wird explizit davor gewarnt das System per apk upgrade aktuell zu halten, da es passieren kann das einem dabei das System zerschießt.

Ok, das ist natürlich ein Argument!

Bei OpenWRT bedeuet update ein neues Image zu flashen. Owut koordiniert quasi das Zusammensammeln der installierten Pakete, das Übermitteln der Modell-Version und Paket-Liste, holt das Image ab sobald es fertig ist und spielt es bei upgrade auch direkt ein.

Dann führt ja kein Weg an owut vorbei (hatte da auch einiges bzgl. Build gelesen und es deswegen für die falsche Wahl bzgl. Paket-Upgrades gehalten).

Es wirkt so, als wenn der Image Builder den Feed kennen muss - was kein Problem wäre, wenn man einen eigenen betreiben würde. Ein eigener Image Builder (gibt es auch als Docker image) könnte auch ein "First start" Skript ausführen, dass bspw. das benötige Paket installiert.

Ja, das wäre dann wohl der Weg.

Kann man dem Remote Image Builder überhaupt eine eigene Liste von Feeds mitgeben?

Auf der Website gibt es etwas zum ausklappen (beim Firmware-Download), wo man Pakete angeben kann. Bezüglich owut heisst es in der entsprechenden Doku dazu:

owut list - generate lists of installed package for use with Firmware Selector or source builds

Der Firmware-Selector ist dann die eben erwähnte Firmware-Download-Website. Da ich da aber damals auch nichts von irgendwelchen "eigenen" Dingen gesehen habe, wird es wohl auf jenen hier hinauslaufen "müssen":

Ein eigener Image Builder (gibt es auch als Docker image) könnte auch ein "First start" Skript ausführen, dass bspw. das benötige Paket installiert.

Alternativ halt SNMP und zentral die gewünschten Infos abgrabbeln. Ich persönlich würde ja eher letzteres bevorzugen, aber sowas hat ja eher etwas mit individuellen Vorlieben zu tun