# Doute avec unattended-upgrades

**URL:** <https://www.debian-fr.org/t/doute-avec-unattended-upgrades/84357>\
**Category:** Support Debian\
**Created:** [Avril 8, 2021, 9:44 UTC](https://www.debian-fr.org/t/doute-avec-unattended-upgrades/84357 "2021-04-08T09:44:57Z")\
**Posts on this page:** 12\
**Page:** 1

<div class="post-metadata">

**Author:** ![PUNTO](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/p/db5fbb/32.png) [@PUNTO](https://www.debian-fr.org/u/PUNTO)\
**Post date:** [Avril 8, 2021, 9:44 UTC](https://www.debian-fr.org/t/doute-avec-unattended-upgrades/84357/1 "2021-04-08T09:44:57Z")

</div>

Bonjour tout le monde.

J’ai essayé de trouver des réponses à mes questions sur internet et sur le forum avant d’ouvrir ce post sans succès.

Au niveau de la sécurité et face à la grande quantité des serveurs à maintenir. J’ai testé unattended-upgrades sur un serveur de test (cloné à partir d’un serveur de production) mais uniquement pour l’actualisation des mises à jour de sécurité (Debian-Security).

Le résultat est plutôt bon, c’est à dire que le serveur comme attendu, reçoit régulièrement les mises à jour de sécurité et lors des scans de vulnérabilités en whitebox avec OpenVAS, je vois bien qu’au niveau des paquets il n’y plus du tout de faille de sécurité, contrairement au serveur de production pour lequel des failles apparaissent demandant l’actualisation des paquets.

Avant de généraliser l’utilisation sur tous les serveurs j’aurais une question.  
Je ne veux surtout pas que des paquets avec des actualisations autres que celles de sécurité viennent déstabiliser les applications des serveurs. A priori et d’après ce que j’ai pu observé, unatteded-upgrades gère bien ce côté.

Mais du coup j’ai quand-même un doute. Je m’explique:  
Par exemple imaginons que sur un serveur j’ai un CMS qui me demande comme prérequis une certaine version de PHP imaginons la 7.3. Est-ce que je suis sûr qu’en actualisant uniquement et automatiquement les MAJ Debian-Security à travers unatteded-upgrades il n’y aura pas une monté de version de PHP en 7.4 ou pire 8.0 ?

J’ai mis comme exemple PHP mais ça pourrait très bien être un auotre paquet comme MariaDB ou Apache2.

J’espère avoir été clair avec mon explication 🙄.

---

<div class="post-metadata">

**Author:** ![anon96191775](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/71c47a/32.png) [@anon96191775](https://www.debian-fr.org/u/anon96191775)\
**Post date:** [Avril 8, 2021, 11:45 UTC](https://www.debian-fr.org/t/doute-avec-unattended-upgrades/84357/2 "2021-04-08T11:45:06Z")

</div>

> [@PUNTO](#):
>
> Est-ce que je suis sûr qu’en actualisant uniquement et automatiquement les MAJ Debian-Security à travers unatteded-upgrades il n’y aura pas une monté de version de PHP en 7.4 ou pire 8.0 ?

Les mises-à-jour de sécurité n’apportent jamais de montée en version pouvant modifier la compatibilité des applications. _Sauf_ pour Firefox et Google Chromium™.

---

<div class="post-metadata">

**Author:** ![PUNTO](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/p/db5fbb/32.png) [@PUNTO](https://www.debian-fr.org/u/PUNTO)\
**Post date:** [Avril 8, 2021, 1:56 UTC](https://www.debian-fr.org/t/doute-avec-unattended-upgrades/84357/3 "2021-04-08T13:56:24Z")

</div>

Bonjour vv222 !

Merci beaucoup pour ta réponse. Il n’y a pas de Firefox et Chromium. Il n’y a pas d’interface graphique non plus.  
Je vais alors déployer unattended-upgrades sur tous mes serveurs.

Encore merci !!! 🙂

---

<div class="post-metadata">

**Author:** ![anon96191775](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/71c47a/32.png) [@anon96191775](https://www.debian-fr.org/u/anon96191775)\
**Post date:** [Avril 8, 2021, 3:16 UTC](https://www.debian-fr.org/t/doute-avec-unattended-upgrades/84357/4 "2021-04-08T15:16:08Z")

</div>

J’utilise unattended-upgrades sur tous mes serveurs depuis des années, sans mauvaise surprise 😉

Y compris sur des serveurs faisant tourner PHP et MariaDB (mais pas Apache, j’utilise nginx).

---

<div class="post-metadata">

**Author:** ![anon70622873](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/278dde/32.png) [@anon70622873](https://www.debian-fr.org/u/anon70622873)\
**Post date:** [Avril 9, 2021, 7:48 UTC](https://www.debian-fr.org/t/doute-avec-unattended-upgrades/84357/5 "2021-04-09T07:48:37Z")

</div>

Salut,

Une mauvaise surprise peut toujours arriver 😉  
Ce qui amène deux questions :

- est-ce que tu es notifié des mises à jour et de leur bon déroulement ou de leur échec ?
- est-ce que tu as bien pensé a automatiser le redémarrage des services qui le nécessitent après une mise à jour ? (_needrestart_ est ton ami) Par exemple après une mise à jour d’une bibliothèque TLS, redémarrer tous les services qui en dépendent.

---

<div class="post-metadata">

**Author:** ![anon96191775](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/71c47a/32.png) [@anon96191775](https://www.debian-fr.org/u/anon96191775)\
**Post date:** [Avril 9, 2021, 9:22 UTC](https://www.debian-fr.org/t/doute-avec-unattended-upgrades/84357/6 "2021-04-09T09:22:49Z")

</div>

> [@anon70622873](#):
>
> est-ce que tu es notifié des mises à jour et de leur bon déroulement ou de leur échec ?

Oui, par e-mail. On peut demander à ne recevoir que les notifications d’échec, mais dans mon cas je préfère recevoir une notification à chaque fois qu’une action est effectuée, y compris quand tout se déroule comme prévu.

> [@anon70622873](#):
>
> est-ce que tu as bien pensé a automatiser le redémarrage des services qui le nécessitent après une mise à jour ? ( _needrestart_ est ton ami)

[needrestart](https://packages.debian.org/buster/needrestart) est installé et redémarre automatiquement les services concernés par les bibliothèques mises à jour. En complément, un redémarrage total du serveur est lui aussi automatique en cas de mise-à-jour d’un paquet le nécessitant, comme le noyau.

* * *

Et le plus beau dans tout ça, c’est que ça se fait sans _aucune_ intervention manuelle de ma part. Un serveur configuré de cette manière pourrait probablement me survire pendant des mois sans que personne ne se rendre compte que je ne suis plus là pour m’en occuper 😉

---

<div class="post-metadata">

**Author:** ![PUNTO](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/p/db5fbb/32.png) [@PUNTO](https://www.debian-fr.org/u/PUNTO)\
**Post date:** [Avril 13, 2021, 3:38 UTC](https://www.debian-fr.org/t/doute-avec-unattended-upgrades/84357/7 "2021-04-13T15:38:12Z")

</div>

Je n’ai peut-être pas assez cherché mais je ne pas encore trouvé la façon de configurer l’heure et les intervalles des mises à jour. Grâce aux logs et surtour aux E-mails récapitulatifs je vois qu’il se met à jour de façon journalière.

---

<div class="post-metadata">

**Author:** ![anon96191775](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/71c47a/32.png) [@anon96191775](https://www.debian-fr.org/u/anon96191775)\
**Post date:** [Avril 13, 2021, 9:04 UTC](https://www.debian-fr.org/t/doute-avec-unattended-upgrades/84357/8 "2021-04-13T21:04:42Z")

</div>

> [@PUNTO](#):
>
> je ne pas encore trouvé la façon de configurer l’heure et les intervalles des mises à jour.

Sauf erreur de ma part, c’est défini par _apt-daily-upgrade.timer_.

Par défaut, ce timer utilise une heure aléatoire chaque jour, pour éviter que toutes les Debian téléchargent leurs mises-à-jour en même temps et surchargent les serveurs de paquets dans l’opération.

La mise-à-jour n’a pas pour autant lieu n’importe quand dans la journée, mais dans un intervalle de 60 minutes après 6h du matin (donc à un moment aléatoire entre 6h et 7h).

Changer l’heure et l’intervalle de randomisation peut se faire en surchargeant les valeurs définies par _/lib/systemd/system/apt-daily-upgrade.timer_.

---

<div class="post-metadata">

**Author:** ![nam1962](https://www.debian-fr.org/user_avatar/www.debian-fr.org/nam1962/32/9129_2.png) [@nam1962](https://www.debian-fr.org/u/nam1962)\
**Post date:** [Avril 14, 2021, 1:53 UTC](https://www.debian-fr.org/t/doute-avec-unattended-upgrades/84357/9 "2021-04-14T13:53:32Z")

</div>

> [@PUNTO](#):
>
> Au niveau de la sécurité et face à la grande quantité des serveurs à maintenir

Ce n’est pas une réponse à ta question, mais je suis curieux sur ce type de contrainte, utilises-tu :

> **[OCS Inventory Professionnel – Solution open source d'inventaire de parc...](https://ocsinventory-ng.org/?lang=fr)**

ou

> **[Cockpit Project](https://cockpit-project.org/)**
>
> Cockpit makes it easy to administer your Linux servers via a web browser.

?

---

<div class="post-metadata">

**Author:** ![PUNTO](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/p/db5fbb/32.png) [@PUNTO](https://www.debian-fr.org/u/PUNTO)\
**Post date:** [Avril 14, 2021, 8:23 UTC](https://www.debian-fr.org/t/doute-avec-unattended-upgrades/84357/10 "2021-04-14T20:23:53Z")

</div>

Merci à nouveau vv22 !!! 😀

---

<div class="post-metadata">

**Author:** ![PUNTO](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/p/db5fbb/32.png) [@PUNTO](https://www.debian-fr.org/u/PUNTO)\
**Post date:** [Avril 14, 2021, 8:29 UTC](https://www.debian-fr.org/t/doute-avec-unattended-upgrades/84357/11 "2021-04-14T20:29:17Z")

</div>

Bonjour nam1962.

Oui pour OCS, on l’utilise pour tenir un inventaire du parque informatique tout système confondu (Serveur, poste de travail, Windows ou Linux) et pour pousser des mises à jour logicielles sur les postes/serveurs en Windows.

Par contre je ne connais pas Cockpit Project. Je vais jeter un coup d’œil.

Merci en tout cas ! Je suis preneur de ce type d’information.

---

<div class="post-metadata">

**Author:** ![nam1962](https://www.debian-fr.org/user_avatar/www.debian-fr.org/nam1962/32/9129_2.png) [@nam1962](https://www.debian-fr.org/u/nam1962)\
**Post date:** [Avril 16, 2021, 7:46 UTC](https://www.debian-fr.org/t/doute-avec-unattended-upgrades/84357/12 "2021-04-16T07:46:30Z")

</div>

Projectpad ?

> **[GitHub - emmanueltouzery/projectpad2: Projectpad allows to manage secret credentials and...](https://github.com/emmanueltouzery/projectpad2)**
>
> Projectpad allows to manage secret credentials and server information that you need to handle as a software developer or sysadmin.
