Automatisation de l'application des MAJ de sécurité

Bonjour,

JE m’efforce de suivre toujours attentivement ce post : maj-de-securite-t33391.html et surtout le fil rss Debian-security et effectue donc mes MAJ régulièrement sur mes 3 serveurs.

et je me pose à chaque fois la question de la pertinence (ou pas ) d’automatiser ces MAJ de sécurité. Pourtant je lis ici ou là que c’est déconseillé. Mais je n’imagine pas un admin sys passer ses maj à la main sur des parcs de machine Debian ni bien sur laisser des maj de sécurité non effectuées.

Alors ? quelle est la bonne politique en matière de MAJ de sécurité ?

Salut,
Je n’ai pas un grand parc, donc mon opinion n’a pas beaucoup de valeur…

Quoi qu’il en soit, je n’appliquerais jamais un upgrade sur un ensemble de machines sans en avoir réussi un (upgrade) sur au moins une (machine).
Si j’avais beaucoup de machine, je procéderais ainsi:

  • Automatisation de aptitude update && aptitude -dy upgrade quotidiennement.
  • Essai d’un aptitude upgrade sur une machine en cas de MAJ à faire.
  • Lancement de aptitude upgrade sur le reste de la “flotte” avec un script déclenché à distance (+ envoie des logs de l’upgrade par mail pour vérification). Le script doit être assez complet, il faut gérer les éventuelle question que dpkg pourrait poser…

Le problème avec les mises à jour automatiques, c’est par exemple les cas comme ça :
oracle-fait-encore-des-siennes-t37881.html
oracle-fait-encore-des-siennes-t37881.html#p381510

Sur une machine de prod qui serait concernée par ces changements, je te raconte pas le merdier que ça foutrait (et en plus ça mettrait probablement un moment avant de s’en apercevoir). Bon d’accord les changements incompatibles en stable ça arrive pas tous les jours, mais ça arrive (la preuve).

On n’est jamais non plus à l’abri d’un problème d’empaquetage ou un bug quelconque qui serait passé au travers…

La question que tu dois te poser c’est : qu’est-ce qui est mieux ? Passer quelques minutes régulièrement à vérifier les mises à jour sur une machine de test puis à les reporter en prod, ou bien réparer des conneries a posteriori (ce qui est généralement assez long, pénible, et implique du downtime non contrôlé et la perte de service qui va avec).

Ah oui c’est vrai … Machine de test puis automatisation en prod.

Je vais farfouiller ici ou là pour voir comment mettre en place un déclenchement de maj sur plusieurs machines sans avoir à aller le faire sur chacune d’entre elles.

Si vous avez un bon lien ou une bonne source pour commencer ma recherche, je suis preneur :slightly_smiling:

Ce n’est pas tellement que j’en ai besoin actuellement mais j’aime bien essayer d’adopter des pratiques “propres” et reproductibles dans l’hypothèse éventuelle où ma “charge d’administration” pourrait augmenter. :laughing:

Toujours avoir une machine (ou VM) de test pour chaque configuration de prod (une VM peut donc correspondre à plusieurs machines physiques, la question est de savoir ce qu’il y a d’installé dessus – suivant les services que tu utilises tu peux même peut-être tout installer sur une seule et unique VM même si en réalité tu as des serveurs web, des serveurs mail séparés, des applis métiers, …). Ça dépend beaucoup de la fragmentation de tes configurations.

Un bête script qui utilise SSH…

  1. ssh
  2. screen (pour éviter que la mise à jour soit interrompue si la liaison tombe)
  3. apt(itude)
  4. récupération et filtrage du log apt(itude), récupération du code de sortie etc

[quote=“sorodje”]Je vais farfouiller ici ou là pour voir comment mettre en place un déclenchement de maj sur plusieurs machines sans avoir à aller le faire sur chacune d’entre elles.

Si vous avez un bon lien ou une bonne source pour commencer ma recherche, je suis preneur :slightly_smiling: [/quote]
Je crois qu’il existe vraiment des centaines de solutions. Dans celles que je connais qui sont les plus intéressantes (AMHA) :
[ul]
[li]création d’un dépôt apt à toi, tu fais des mises à jour automatique de tes machines sauf de celle de test, lorsque tu as testé une mise à jour tu dépose les paquets en question dans ton dépôt APT fera le reste ;[/li]
[li]fabric est très intéressant pour deux choses : il est simple, il marche même sur des environnement hétérogène. Il ne demande pas d’installation/configuration particulière ailleurs que sur le poste que tu va utiliser pour faire les mises à jour.[/li][/ul]

Mais tu as aussi :
[ul]
[li]puppet[/li]
[li]mcollective[/li]
[li]cfengine[/li]
[li]…[/li][/ul]

Bref du choix ce n’est pas ce qu’il manque. Je pense que pour un usage non professionnel, les derniers que j’ai cité ne sont pas une bonne voie car ils demandent un gros investissement, là où les deux premiers sont bien plus simple à prendre en main (le premier demande l’installation d’un serveur web comme nginx et d’ajouter des tâches cron, le second demande rien si ce n’est l’installation de fabric sur une machine). Après tu as toujours les solutions fait mains à coup de ssh dans une boucle mais c’est plus casse tête que fabric (et moins performant si tu n’utilise pas pas de parallélisation).

Merci beaucoup :wink:

Misterfreez: J’ai en effet profité de ma pause déjeuner pour (re)penser à ma question et j’ai effectivement pensé à l’idée d’un miroir de dépôt à mettre à jour à la main tout en utlisant ce dépôt dans le sources.list des autres machines.

Avec un tour express de google j’avais repéré aussi cfengine mais c’est effectivement gros pour mon objectif actuel.

Je vais regarder fabric !

Syam : J’avoue que je rechigne à scripter . Déjà, je pars de zéro ou preque en la matière et je manque de connaissances approfondies pour être à peu près sur de contruire une procédure à la fois sensée et pertinente. En bref, j’me sens pas :mrgreen:

Je comprends. Moi je suis programmeur avec quelques (maigres) compétences en admin, donc forcément j’ai pas la même vision des choses. Comme on dit, quand on a qu’un marteau tous les problèmes ressemblent à un clou (ou a un pouce, selon). :wink: