Forum Linux.général Comment faire les mises à jour automatiquement avec Fedora ?

Posté par  . Licence CC By‑SA.
5
11
juil.
2023

Bonjour,

Je cherche à automatiser les mises à jour régulières d'un système Fedora (version 38) pour un utilisateur néophyte.

Contexte :
Un parent, néophyte, utilise Fedora en lieu et place de Windows : plus simple, plus rapide, plus sûr, bref il en est ravi.
Notre utilisateur n'utilise pas le terminal, n'en a aucune notion et ne souhaite pas apprendre à l'utiliser. La remarquable qualité de Fedora fait qu'il est tout-à-fait possible de l'utiliser uniquement avec les outils graphiques et cela se passe très bien.

Le seul point d'achoppement ce sont les mises à jour : elle sont fréquentes et se font par l'outil graphique Gnome Software qui a l'avantage de faire les mise à jour hors-ligne mais l'inconvénient de planter fréquemment (notamment après les mises en veille) et manque très souvent à sont devoir de gardien d'un système bien à jour : j'ai été surpris de voir des mises à jour pas faites pendant plusieurs mois car aucune notification n'est apparue, Gnome Software indique continuellement rechercher des mises à jour mais ne fait que tourner dans le vide. La solution de contournement est d'arrêter/tuer le processus mais cette manœuvre n'est pas satisfaisante pour notre utilisateur, c'est pourquoi je cherche des alternatives qui soit configurée pour rouler toutes seules.

J'ai exploré 3 pistes mais aucune ne semble idéale et fonctionnelle, c'est pourquoi je fais appel à vos lumières :

DNF automatic

Première proposition avec le paquet dnf-automatic.
La procédure d'installation est de configuration est assez simple :
- https://fedoraproject.org/wiki/AutoUpdates
- linuxiac.com/how-to-set-up-automatic-updates-on-fedora-linux/

Il y a un service et un timer systemd associés mais il semblerait que faire des mises à jour "online" (pendant l'utilisation) puisse amener à des erreurs et des instabilités.

Cela est-il fréquent ? Est-ce grave ? Est-ce une raison suffisamment valable pour abandonner cette piste ?

DNF plugins

Une deuxième proposition serait d'utiliser DNF avec un plugin "offline-updates" mais la documentation à ce sujet est manquante :
- https://readthedocs.org/search/?q=project%3Adnf-plugins-extras

Quelqu'un l'utilise et pourrait éclairer ma lanterne ?

Systemd/PackageKit ?

Une autre proposition serait d'utiliser la mise à jour "offline" telle que mise en œuvre par Gnome-Software. Des travaux ont été commencés, apparemment :
- https://fedoraproject.org/wiki/Features/OfflineSystemUpdates

De ce que j'ai compris, cela passe par Package-Kit (pkcon get-updates) et systemd
https://www.freedesktop.org/software/systemd/man/systemd.offline-updates.html

Bingo ! C'est ce que je recherche MAIS cela passe par Gnome Software.

Y'a-t-il moyen de faire sans cette interface graphique ? Est-il possible de créer un service pour faire en sorte que PackageKit télécharge automatiquement les mises à jour (une fois par semaine, par exemple) et qu'il soit simplement proposé à l'utilisateur de les installer lors de l'extinction ou le redémarrage de l'ordinateur ?

Il semblerait que les commandes suivantes fassent le job :

/bin/pkcon refresh force
/bin/pkcon update –only-download
/bin/pkcon offline-trigger
Maintenant, comment les intégrer dans une service systemd qui les exécute 1 ou 2 fois par semaine ?

Merci d'avance !

  • # autre option : crontab ?

    Posté par  . Évalué à 2.

    Maintenant, comment les intégrer dans une service systemd qui les exécute 1 ou 2 fois par semaine ?

    une entrée dans crontab ne suffirait-elle pas ?

    0 0 * * 3,6 path/to/script.sh # lancement le mercredi et le samedi à minuit par exmeple
    

    avec tes commandes collées dans script.sh

    Le plus gros problème (ce sera pareil avec systemd d'ailleurs), c'est être sur que le linux soit up au moment où la commande de musise à jour sera exécutée)

    • [^] # Re: autre option : crontab ?

      Posté par  (Mastodon) . Évalué à 5.

      Le plus gros problème (ce sera pareil avec systemd d'ailleurs)

      Non, ce ne sera pas pareil, systemd a l'option persistent pour ça.

      En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

      • [^] # Re: autre option : crontab ?

        Posté par  . Évalué à 2. Dernière modification le 12 juillet 2023 à 09:16.

        Ah, cool, je n'y connais pas grand chose en systemd
        Donc effectivement, systemd, c'est mieux

        edit:

        il y a aussi le @reboot de crontab, maintenant que j'y pense,pour lancer un job à chaque reboot

        • [^] # Re: autre option : crontab ?

          Posté par  . Évalué à 3.

          il y a aussi le @reboot de crontab, maintenant que j'y pense,pour lancer un job à chaque reboot

          sauf que l'utilisateur moderne ne redemarre que rarement son ordinateur, au mieux il le met en veille, voire il ferme juste le capot

          • [^] # Re: autre option : crontab ?

            Posté par  (site web personnel, Mastodon) . Évalué à 3.

            Ah !

            « Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.

          • [^] # Re: autre option : crontab ?

            Posté par  (site web personnel) . Évalué à 4. Dernière modification le 12 juillet 2023 à 16:18.

            Pour appliquer les correctifs, il faut parfois redémarrer pour changer le noyau ou redémarrer X.org/Wayland ou dbus ou… Redémarrer régulièrement est aussi conseillé sur les smartphone, et ça ne paraît pas idiot sur un poste client en général, de temps en temps (y aura forcément des ressources perdues/bloquées/résiduelles qui apparaîtront au fil du temps, enfin jusqu'à que l'informatique ZeroBug (tm) apparaisse).

    • [^] # Re: autre option : crontab ?

      Posté par  (site web personnel) . Évalué à 4.

      Sur nos machines linux, il y a le paquet anacron (cronie-anacron sur fedora) qui est fait pour cela : exécuter les commandes cron qui ne se sont pas lancées aux heures prévues.

  • # Est-ce la bonne distribution pour ton utilisateur ?

    Posté par  . Évalué à 3.

    LE problème de Fedora es que c'est une distribution en rolling release, et que certaines mises à jour peuvent causer pas mal de problèmes. Peut-être que ça a changé depuis mais personnellement, quand je l'ai testée, je ne l'ai pas gardée à cause de ce point (j'ai eu quelques mises à jour qui m'ont cassé mon système à des moments ou j'en avais besoin), et je suis passé à autre chose.

    Pour un utilisateur qui n'y connait pas grand chose, je crains que ce genre de distribution ne renvoie une image négative de Linux et du libre.

    • [^] # Re: Est-ce la bonne distribution pour ton utilisateur ?

      Posté par  . Évalué à 1.

      J'utilise Fedora depuis une dizaine d'années et je suis sûr que ce n'est pas une rolling release. Il y a un cycle de publication de 6 mois avec des mises à niveau majeures à cette occasion. Tout au plus voit-on le noyau, Firefox et Thunderbird être mis à jour en cours de cycle vers une version plus récente mais je ne pense pas qu'on puisse pour autant qualifier Fedora de rolling release au même titre que ArchLinux ou OpenSUSE TW.

      Je n'ai eu aucun problème causé par une mise à jour aussi loin que je m'en souvienne. Peut-être est-ce aussi lié au fait que je garde volontairement une version de retard par rapport à la dernière publication en date pour gagner en fiabilité.

      Pour autant, je souhaite vraiment creuser l'option Fedora et non tenter une autre distribution car, de toutes celles que j'ai pu tester, c'est celle qui offre la meilleure une expérience utilisateur : des mises à jour simples et accessibles avec une interface graphique, pas de solutions imposées (coucou Ubuntu et les snaps), des mises à niveau fluides et très fiables, peu de bogues aléatoires, une configuration automatique type « Plug'n'Play » des nouveaux périphériques types scanner ou imprimantes (utilisables sans bidouillage en ligne de commande), accélération graphique dans Firefox qui fonctionne out-of-the-box), etc.

      Bref, dans le cas d'une utilisation basique (type Web, courriel, bureautique), Fedora me donne l'impression d'être un tout bien intégré plutôt qu'un simple agrégat de logiciels. C'est difficile à expliquer mais Debian, que j'utilise aussi, et malgré toutes ses autres qualités, ne me donne pas cette impression à l'utilisation.

      J'ai creusé la piste RHEL mais la souscription à renouveler tous les ans me gêne un peu sur le principe. CentOS Stream est encore dans le flou (je verrai au lancement de CentOS Stream 10 qui préparera la prochaine RHEL sur la base de Fedora 39/40?). Rocky et Alma sont dans le flou aussi depuis le récent drame autour de la fermeture de l'accès public aux sources de RHEL. Donc, à défaut, Fedora me semble la bonne solution.

      L'idée est simplement de trouver le moins pire meilleur moyen de faire les mises à jour automatiquement en gardant un cycle de retard pour profiter. Je n'aurai qu'à faire les mises à niveau tous les 6 mois mais ça me semble acceptable comme maintenance.

  • # Silverblue

    Posté par  . Évalué à 1.

    Bonjour,

    Je me suis retrouvé dans la même situation avec ce souci de mises à jour, j'ai fini par installer Fedora Silverblue sur le poste.

    Pour autoriser les mises à jour automatiques dans Fedora Silverblue, c'est simple:

    $ sudo sed -i 's|^#AutomaticUpdatePolicy=none|AutomaticUpdatePolicy=stage|' /etc/rpm-ostreed.conf
    $ sudo rpm-ostree reload
    $ sudo systemctl enable rpm-ostreed-automatic.timer --now

    Ensuite, on vérifie que rpm-ostree et le timer sont correctement activés:

    $ rpm-ostree status
    State: idle
    AutomaticUpdates: stage; rpm-ostreed-automatic.timer: no runs since boot
    Deployments:
    ● ostree://fedora:fedora/30/x86_64/testing/silverblue

    Et hop! à condition que le PC soit redémarré régulièrement, plus de soucis de mises à jour!

    En effet, dans Silverblue, le système de base n'est plus constitué de logiciels en paquets, mais est d'un seul bloc, versionné par la date.

    Silverblue garde plusieurs versions du système de base. On a donc:

    • Version n-1
    • Version n (courante)
    • Version n+1

    Mettre à jour Silverblue signifie mettre à jour le système de base vers la version n+1 sans altérer l'actuelle version n.

    La version n+1 ne sera activée qu'au prochain redémarrage et deviendra la version n. (Note: Si la version n ne démarre pas, on peut revenir à la version n-1).

    Les applications sont à installer via Flatpak, donc l'utilisateur peut les installer sans avoir besoin de droits spéciaux. (Bien vérifier que la mise à jour auto est activée).

    • [^] # Re: Silverblue

      Posté par  . Évalué à 1.

      Bonjour,

      Effectivement, de ce que tu m'en dis, il y a quelque chose à creuser par là. J'ai toujours vu Silverblue comme un jouet pour geek avancé qui vise à préparer le futur modèle de Fedora et je ne m'y suis jamais vraiment intéressé.

      Peux-tu me donner un retour sur l'utilisation au quotidien, notamment :
      - la fiabilité globale est-elle bonne ? On est sur quelque chose d'utilisable en prod ou sur encore sur une proposition de qualité alpha/beta ouverte ?
      - la détection des périphériques est-elle aussi bonne que la distribution classique ?
      - la ligne de commande est-elle incontournable pour faire les tâches d'administration basiques (installer/désinstaller un programme, mettre à jour le système, installer des périphériques, etc.) ?
      - peut-on installer des logiciels en RPM ( il semblerait que oui avec toolbox) ?
      - Quels sont les éléments à signaler pour un nouvel utilisateur avant de se lancer ?

      Merci !

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.