Forum Linux.debian/ubuntu gestion des correctifs

Posté par  . Licence CC By‑SA.
Étiquettes : aucune
1
16
juin
2022

Bonjour,
Que recommandez-vous pour la gestion des correctifs sur des serveurs linux?
Je trouve beaucoup de solutions payantes mais je n'ai pas vraiment vu de logiciels libres ou de solutions gratuites mais j'imagine qu'il en existe.

En outre, j'ai entendu parler d'ansible, est ce que ca peut aider à gérer le déploiement de correctifs sur des serveurs en le testant sur un local puis en déployant ensuite?

Merci

  • # apt update + upgrade ?

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

    Hello, je pense qu'il faudrait être un peu plus spécifique, car pour la gestion de correctifs systèmes, une réponse possible est un simple apt update + apt upgrade (ou équivalent selon la distro). Mais j'ai le sentiment que ce n'est pas ce que tu veux.

    Un gentil du net

    • [^] # Re: apt update + upgrade ?

      Posté par  . Évalué à 5.

      Au vu de la mention d'ansible, du pluriel et de l'usage de serveurs, je dirais que le problème que l'OP cherche a résoudre est la gestion de correctifs sur un parc, chose qu'apt-get ou autres ne font pas.

      Du coup, oui, ansible est une possibilité, mais personnellement je ne pense pas qu'il s'agisse de la solution la plus efficace, du fait qu'ansible est "sans agent", tout comme rexify ou drist.
      Ces solutions sont pratiques dans le cas ou il n'est pas possible d'installer un outil ou si l'on veut éviter de faire tourner un agent H24 (pour des raisons de performances), avec l'inconvénient que si une machine tombe ou est injoignable pour une raison X ou Y, l'indisponibilité ne se résoudra pas toute seule.

      Je pense que les solutions a base d'agent, du type cfengine, chef, puppet (flemme de mettre tous les liens) et bien d'autres sont plus pertinentes, mais ça requiert d'installer des logiciels sur les machines cibles ainsi qu'une (ou plusieurs) machine centrales, ce qui implique un impact de performances et une complexité supérieure.
      En échange, les machines cibles vont se maintenir "toutes seules", c'est à dire que leur configuration se dirigera vers la configuration voulue, sans intervention manuelle. Bon, évidemment, il reste en pratique à mettre en place le système ainsi qu'a maintenir les configurations.

      En terme d'impact sur les performances systèmes, cfengine est le plus léger dans la catégorie des systèmes à agents, étant écrit en C. Il ne nécessite aussi aucune dépendance, et est packagé dans debian, à minima (qui en empaquète d'autres, hein!).
      Dans la liste des outils sans agents, rex est en perl, et donc ne nécessite aussi que peu de dépendance, mais celui qui gagne est clairement drist, étant écrit en shell posix, sa portabilité est maximale. Drist est également, et de loin, le plus simple a utiliser.

      Bref, il y a pas mal d'outils (open source ET gratuit, j'ai bien l'impression que c'est ce point qui est important pour l'OP :D, bien que par exemple cfengine est poussé par une boîte qui peut vendre du support) pour gérer un parc, chaque solution a ses avantages et inconvénients. Certains outils sont en Ruby, d'autres en python, en C, en bourne shell, en perl… et nécessiterons donc plus ou moins d'efforts en fonction de son confort personnel avec ces différentes techno.

  • # quelle distro ?

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

    Tu ne précises pas quelle(s) distribution(s) tu gères…

    Pour du Debian et similaire, j'ai utilisé cron-apt depuis la 6 avec plaisir car complet et flexible
    Il y a aussi, maintenant (et connu précédemment sur Ubuntu), unattended-upgrades tout aussi complet et intégré
    Attention à bien régler le type/niveau de mises à jour ; moi je ne fais que celles de sécurité avec mail de notification (et vérification chaque fois qu'on a un message et j'ai apt-listchanges sur ces serveurs).
    Si on veut juste être notifié des mises à jour sans les faire, les deux peuvent servir aussi, mais j'ai tendance à préférer apticron qui fait très bien le job. Si tu veux scripter cet aspect toi-même, tu peux récupérer la sortie de apt list --upgradeable ou aptitude search '~U' ou apt-get -u upgrade --assume-no

    Pour du CentOS et RHEL, j'utilisais yum-cron
    Il semble que dnf-automatic ait pris le relais.

    “It is seldom that liberty of any kind is lost all at once.” ― David Hume

    • [^] # Re: quelle distro ?

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

      Tu ne précises pas quelle(s) distribution(s) tu gères…

      Arf, c'est la section de Forum Linux.debian/ubuntu

      Nota : comme indiqué dans une autre réponse, la taille du parc et son homogénéité/hétérogénéité est aussi un facteur à prendre en compte.

      “It is seldom that liberty of any kind is lost all at once.” ― David Hume

  • # tableau de bord ?

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

    Dans ton cas, je me pose 2 questions :
    - la taille du parc : pour 5 machines, un simple cron suffit, pour 1000 machines, il faut industrialiser
    - faut-il un tableau de bord, qui permet de savoir quel est l'état du parc : combien de machines à jour, combien de machines n'ont pas été vue depuis x jours.

    Dans mon travail, j'utilisais pour cela puppet et puppetboard.

  • # OCS Inventory + Ansible ?

    Posté par  . Évalué à 1.

    Pour connaitre l'état du parc, peut être OCS Iventory.

    Pour appliquer du déploiement, Ansible peut répondre.
    Cela demande un peu d'apprentissage mais après c'est confortable à utiliser et fiable.

  • # apt-dater

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

    Petit complément aux solutions précédentes:

    sur un parc homogène (ou en tout cas sur des OS dérivés de debian/apt) avec une volonté de contrôle apt-dater (https://github.com/DE-IBH/apt-dater) est un très chouette outil pour avoir une vision globale de l'état du parc et pour y appliquer les remédiations nécessaires.

  • # Ansible

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

    Professionnellement, via Ansible (vu que c'est l'outil pour l'automatisation que nous utilisons) : c'est un peu plus compliqué que juste de l'apt ou yum. Il faut aussi du needrestart ou du needs-restarting, des listes d'exclusion si tu veux éviter des impacts clients, de la gestion des grappes de serveurs (il faut synchroniser ou séquencer les opérations), et au final il faut du temps et de nombreuses mises à jour successives pour déboguer/stabiliser tout ça… Ça fait désormais un petit bout de temps que l'on lancer en un clic sur la CI la mise à jour avec redémarrage (ou non) d'une centaine de machines virtuelles, en évitant les impacts sur le service rendu, et malgré ça on a encore régulièrement des petites surprises (exemple récent : squid qui se prend un SIGSEV sur une Ubuntu 18.04 LTS lors de son arrêt, juste avant le reboot, ce que au final est sans conséquence, vu le redémarrage derrière, à part l'alerte générée par l'apparition du fichier de crash…).
    Comme souvent ça dépend du contexte et des outils déjà connus/utilisés (donc je ne dirais pas qu'Ansible est la solution qu'il faut utiliser dans l'absolu).

  • # merci

    Posté par  . Évalué à 1.

    merci pour vos nombreuses reponses

Suivre le flux des commentaires

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