Gestion des mises à jour
Début juillet je vous relatais Plus de barre des tâches et autres joyeusetés sur Mint Xfce après mises à jour, deux fails dans cette histoire : 1/ Mint publiant une MAJ foireuse 2/ Ma gestion des mises à jour à revoir.
Concernant le point 1/ malgré les moyens humains, financiers et techniques, les équipes derrière les systèmes d’exploitation n’arrivent pas à empêcher de gros bugs/fails. Je parle bien de tous les systèmes d’exploitation, ces deux dernières années les exemples sont nombreux, je pense notamment à Windows 10, on peut aussi citer iOS 13 en ce moment (13.1 le 24 septembre, 13.1.1 le 27/09 et 13.1.2 le 30/09). Cela revient à se demander si un jour il n’y aura plus de bugs et si on sera capable de les détecter systématiquement. Je pars du principe que ça n’arrivera jamais dit autrement ce problème continuera de se produire et nous n’avons aucun moyen de l’empêcher.
Reste le second point où on peut agir avec de l’organisation, une gestion des mises à jour.
À la maison
J’ai actuellement un pc fixe et un pc portable. J’attire votre attention sur le fait que le pc portable est le plus « essentiel », ils n’ont donc pas la même importance. En effet le pc portable me permet de travailler en déplacement (cowork/datacenter) quand le pc fixe ne me permet de travailler qu’à mon domicile.
Le 3 juillet j’ai mis à jour mon pc fixe dans la journée, Mint propose un gestionnaire de mises à jour nommé mintUpdate prévenant lorsqu’une MAJ est disponible dans la barre des tâches. Souvent dans le canapé le soir je mets à jour le pc portable en repensant que des mises à jour sont dispos. Le 4 juillet au matin alors que je devais effectuer une grosse opération pour le boulot, mes deux postes étaient pas loin d’être inutilisables (plus de barre des tâches, plus accès aux boutons Réduire/Maximiser des fenêtres, difficultés à ouvrir des applications en maximisé comme Firefox, etc.). L’erreur principale a été de mettre à jour les 2 postes en même temps (même jour), la seconde erreur vient de mon utilisation trop systématique d’un alias mis en place depuis une éternité alias uu='sudo apt update && sudo apt upgrade'
.
Voici comment je procède maintenant :
- Jour 1 :
uu
sur le pc fixe, apt update sur le pc portable - J+2 (ou davantage) : apt upgrade sur le pc portable
Il faut découpler le update du upgrade ainsi on a le même référentiel de paquets à mettre à jour sur les 2 postes, le pc fixe va essuyer les plâtres, si/quand tout se passe bien alors on upgrade le pc portable.
En environnement professionnel
Au boulot :
- Jour 1 (lundi) : update sur tous les serveurs puis upgrade des serveurs sandbox (tests) puis des serveurs mutualisés « hors BDD/http » (mail, ssh…)
- J+1 : upgrade des serveurs mutualisés BDD (mysql, postgresql…)
- J+2 : upgrade des serveurs internes (dns, dhcp, backup…)
- J+3 : upgrade des serveurs mutualisés http
- J+7 : upgrade des VPS/dédiés
Je ne rentre pas dans les détails de l’automatisation (Ansible ou autres), ce n’est pas le sujet du jour. Évidemment si il y a des mises à jour de sécurité importantes, on les fait sans attendre (mais pas sans quelques tests).
Si on veut installer/maj des outils maison en évitant un update de toutes les sources, on peut apt-get -o Dir::Etc::SourceList=/etc/apt/sources.list.d/00_jolirepoboulot.list -o Dir::Etc::sourceparts="-" update
(voir FICHIERS ici) qui va update le référentiel de paquets uniquement avec les sources présentes dans 00_jolirepoboulot.list (et pas avec les sources Debian typiquement).
Je vous rappelle l’existence des paquets unattended-upgrades et apt-listchanges en vous invitant à de saines lectures (1, 2). Lorsque j’avais juste quelques serveurs j’utilisais ces outils, dans mon contexte actuel (hébergeur) avec plus de 250 serveurs/VM, on checke le déroulement de la MAJ pour chaque serveur (en sortie de l’outil d’automatisation) et on intervient au moindre problème. Tout dépend du contexte.
Première mineure après la majeure
Dans un registre un peu différent, avec l’expérience je n’installe plus les versions majeures des systèmes d’exploitation de suite, j’attends la première mineure. Concrètement je n’installe pas Debian Buster (10) avant que la 10.1 ne soit sortie corrigeant tous les petits problèmes/bugs et laissant aux autres le soin d’essuyer les plâtres.
De votre côté, comment vous gérez vos mises à jour ?
Déjà 12 avis pertinents dans Gestion des mises à jour
Les commentaires sont fermés.
En perso (Arch partout), sur PC, j’ai un notifier, et je màj direct quand il y a une màj, après avoir vérifié le changelog si c’est une màj majeure et/ou un paquet important. Sur serveur, une fois par semaine environ, en fonction des màjs faites sur le PC : si y’a une faille critique ou autre, je màj aussitôt, sinon quand j’y pense (et je les fais tous à la suite, en cas de pépin (rare), je peux toujours downgrade).
À mon avis t’es un utilisateur « normal »
Tcho !
Merci de ton témoignage.
Il y a une certaine (trop grande ?) confiance dans les distribs qu’on utilise : Arch, Debian… Clairement les MAJ foireuses sont très rares mais pas inexistantes, je crois que je pointe un excès de confiance et un manque de lucidité de nous tous.
Tchi
j’ai un portable et un fixe, usage perso uniquement. Le fixe me sert peu, surtout quand j’ai besoin d’un grand écran.
Après avoir eu quelques problèmes de plantage (mises à jour ?) bien pénibles, j’ai décidé d’y avoir en permanence 2 distributions différentes installées sur le portable, chacune avec leur petit Home mais une grosse zone data partagée.
Depuis, je ne me pose plus de questions, j’installe les maj sur le portable dès que j’en vois et sans trop réfléchir.
Au pire j’ai toujours ma distribution secondaire du portable en état de marche et le fixe (qui a ma distribution principale du portable). Comme le fixe est rarement allumé, j’ai déjà testé les maj sur le portable quand je le mets à jour.
Ça doit bien faire 10 ans que je ne me suis pas retrouvé dans la mouise sur les 2 PC en même temps.
Hé hé je fais la même chose sur le pc portable, 2 distribs. Ceci étant dit ça permet de se sortir du cas où plus rien ne marche mais pas vraiment de réparer une MAJ foireuse rapidement. Comme je le disais dans l’article, j’ai fail en mettant à jour en même temps les 2 pc.
Tcho !
Pour les serveurs perso, à la maison les VMs sont toutes en unattented-upgrade. Par contre, une fois le cluster refait en K3S faut que je m’occupe de gérer les reboot auto avec Kured (je les fais manuellement actuellement), histoire de plus rien avoir à foutre. Sur les serveurs « publics », c’est apticron qui prévient par mail et je passe régulièrement sur les machines faire les mises à jour. A la maison j’ai moins de nécessité à conserver un truc qui fonctionne donc pas grave si via une maj auto y’a un truc qui tombe.
Pour les serveurs au boulot, les Windows sont paramétrés sur un WSUS en fonction de leur localisation, et du raccord en termes de réseau. Pour les linux, on a un outil maison, LSUS, qui couple un agent sur les serveurs avec un serveur central qui permet de lister toutes les machines installées et de définir un calendrier de patching, ainsi que quelques options comme les notifications. Par contre, c’est une horreur écrite en perl et le schéma de la base de données est une tannée sans nom, je suis bien content de pas en être le mainteneur.
Merci!
Merci pour le partage (et pour une fois ton commentaire est passé sans que tu pleures ha ha ha).
Tcho !
Je n’ai pas de préférence pour le portable, je préfère bosser sur le fixe avec un « vrai » clavier et un « vrai » écran. Par contre il est plus important car si je dois partir en intervention, je ne peux évidemment pas y aller avec le pc fixe ^^
Concernant ta question, voir Mon besoin sur https://www.bloglibre.net/2018/06/09/quelques-reflexions-autour-de-lexternalisation-des-sauvegardes/
Si c’est pas clair, tu me redemandes.
Tcho !
C’est pas un DD mais une clé USB sinon oui pour le reste. Je t’invite aussi à lire https://linuxfr.org/users/aurelieng/journaux/partage-de-owncloud-decentralise-a-syncthing-distribue sur Syncthing.
Tcho !