Ce projet simplifie le processus sysupgrade pour mettre à niveau le micrologiciel des appareils exécutant OpenWrt ou des distributions basées sur celui-ci. Ces outils offrent un moyen simple de reflasher le routeur avec une nouvelle version du micrologiciel (y compris tous les packages) sans avoir besoin d'utiliser opkg .
ASU est basé sur une API pour demander des images de micrologiciel personnalisées avec n'importe quelle sélection de packages préinstallés. Cela évite d'avoir à configurer un environnement de construction et permet de créer une image de micrologiciel personnalisée même à l'aide d'un appareil mobile.
Interface Web simple utilisant Vanilla JavaScript actuellement développée par @mwarning. Il propose une recherche d'appareils basée sur les noms de modèles et affiche des liens vers des images officielles ou demande des images via l'API asu . Veuillez participer au développement du référentiel GitLab
Le package luci-app-attendedsysupgrade propose un outil simple sous System > Attended Sysupgrade . Il demande une nouvelle image de micrologiciel qui inclut l'ensemble actuel de packages, attend qu'elle soit construite et la flashe. Si « Conserver la configuration » est coché dans l'interface graphique, l'appareil est mis à niveau vers le nouveau micrologiciel sans qu'il soit nécessaire de saisir à nouveau une configuration ou de réinstaller des packages.
Avec OpenWrt SNAPSHOT-r26792 or newer l'application CLI auc a été remplacée par owut en tant qu'outil CLI plus complet pour fournir un moyen simple de mettre à niveau votre appareil.
Le package auc exécute le même processus que luci-app-attendedsysupgrade depuis SSH/la ligne de commande.
Le serveur écoute les demandes d'images et, si elles sont valides, les génère automatiquement. Il coordonne plusieurs OpenWrt ImageBuilders et met en cache les images résultantes dans une base de données Redis. Si une image est mise en cache, le serveur peut la fournir immédiatement sans reconstruction.
Pour des raisons de sécurité, chaque build se déroule dans un conteneur afin qu'une build ne puisse pas affecter une autre build. Pour que cela fonctionne, un conteneur Podman exécute un service API afin que les travailleurs puissent eux-mêmes exécuter des builds à l'intérieur des conteneurs.
Veuillez installer Podman et tester s'il fonctionne :
podman run --rm -it docker.io/library/alpine:latest
Une fois Podman fonctionnel, installez podman-compose :
pip install podman-compose
Il est désormais possible d'exécuter tous les services via podman-compose :
# 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
Cela démarrera le serveur, le conteneur API Podman et deux travailleurs. La première exécution prend quelques minutes puisque les packages disponibles sont analysés à partir du serveur en amont. Une fois le serveur exécuté, il est possible de demander des images via l'API sur http://localhost:8000 . Modifiez podman-compose.yml pour changer le port.
Pour la production, il est recommandé d'utiliser un proxy inverse comme nginx ou caddy .
Après avoir cloné ce référentiel, créez un environnement virtuel Python et installez les dépendances :
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
Pour mettre à jour la liste des cibles disponibles, exécutez :
poetry run python3 misc/update_all_targets.py
Cela peut être ajouté à une tâche cron pour mettre à jour régulièrement les cibles. Le script doit être modifié au cas où vous souhaiteriez mettre à jour les cibles à partir d'une source différente ou exécuter le serveur sur un port différent.
L'API est documentée via OpenAPI et peut être consultée de manière interactive sur le serveur :
