Dieses Projekt vereinfacht den Sysupgrade-Prozess zum Aktualisieren der Firmware von Geräten, auf denen OpenWrt oder darauf basierende Distributionen ausgeführt werden. Diese Tools bieten eine einfache Möglichkeit, den Router mit einer neuen Firmware-Version (einschließlich aller Pakete) neu zu flashen, ohne opkg verwenden zu müssen.
ASU basiert auf einer API zum Anfordern benutzerdefinierter Firmware-Images mit einer beliebigen Auswahl an vorinstallierten Paketen. Dadurch entfällt die Notwendigkeit, eine Build-Umgebung einzurichten, und es ist möglich, auch mit einem mobilen Gerät ein benutzerdefiniertes Firmware-Image zu erstellen.
Einfache Weboberfläche mit Vanilla-JavaScript, derzeit entwickelt von @mwarning. Es bietet eine Gerätesuche basierend auf Modellnamen und zeigt Links entweder zu offiziellen Bildern an oder fordert Bilder über die asu -API an. Bitte beteiligen Sie sich an der Entwicklung im GitLab-Repository
Das Paket luci-app-attendedsysupgrade bietet unter System > Attended Sysupgrade ein einfaches Tool. Es fordert ein neues Firmware-Image an, das den aktuellen Paketsatz enthält, wartet, bis es erstellt ist, und flasht es. Wenn „Konfiguration beibehalten“ in der GUI aktiviert ist, wird das Gerät auf die neue Firmware aktualisiert, ohne dass eine erneute Konfiguration oder Neuinstallation von Paketen erforderlich ist.
Mit OpenWrt SNAPSHOT-r26792 or newer wurde die CLI-App auc durch owut als umfassenderes CLI-Tool ersetzt, um eine einfache Möglichkeit zum Aktualisieren Ihres Geräts zu bieten.
Das auc -Paket führt den gleichen Prozess aus wie das luci-app-attendedsysupgrade über SSH/die Befehlszeile.
Der Server lauscht auf Bildanfragen und generiert diese automatisch, sofern sie gültig sind. Es koordiniert mehrere OpenWrt ImageBuilder und speichert die resultierenden Bilder in einer Redis-Datenbank zwischen. Wenn ein Bild zwischengespeichert wird, kann der Server es sofort bereitstellen, ohne es neu erstellen zu müssen.
Aus Sicherheitsgründen erfolgt jeder Build in einem Container, sodass ein Build keinen Einfluss auf einen anderen Build haben kann. Damit dies funktioniert, führt ein Podman-Container einen API-Dienst aus, sodass Mitarbeiter selbst Builds in Containern ausführen können.
Bitte installieren Sie Podman und testen Sie, ob es funktioniert:
podman run --rm -it docker.io/library/alpine:latest
Sobald Podman funktioniert, installieren Sie podman-compose :
pip install podman-compose
Jetzt ist es möglich, alle Dienste über podman-compose auszuführen:
# where to store images and json files
echo "PUBLIC_PATH=$(pwd)/public" > .env
# absolute path to podman socket mounted into worker containers
echo "CONTAINER_SOCK=/run/user/$(id -u)/podman/podman.sock" >> .env
podman-compose up -d
Dadurch werden der Server, der Podman-API-Container und zwei Worker gestartet. Der erste Durchlauf dauert einige Minuten, da verfügbare Pakete vom Upstream-Server analysiert werden. Sobald der Server läuft, ist es möglich, Bilder über die API unter http://localhost:8000 anzufordern. Ändern Sie podman-compose.yml um den Port zu ändern.
Für die Produktion wird empfohlen, einen Reverse-Proxy wie nginx oder caddy zu verwenden.
Erstellen Sie nach dem Klonen dieses Repositorys eine virtuelle Python-Umgebung und installieren Sie die Abhängigkeiten:
poetry install
poetry run fastapi dev asu/main.py
# podman unix socket (not path), no need to mount anything
export CONTAINER_HOST=unix:///run/user/1001/podman/podman.sock
poetry run rq worker
Führen Sie Folgendes aus, um die Liste der verfügbaren Ziele zu aktualisieren:
poetry run python3 misc/update_all_targets.py
Dies kann zu einem Cronjob hinzugefügt werden, um die Ziele regelmäßig zu aktualisieren. Das Skript muss geändert werden, falls Sie die Ziele von einer anderen Quelle aktualisieren oder den Server auf einem anderen Port ausführen möchten.
Die API ist über OpenAPI dokumentiert und kann interaktiv auf dem Server eingesehen werden:
