Bien sur comme dit précédemment il ne faut pas faire les MAJ à l’aveugle. Dans un premier temps tu peux tester cron-apt en pre-prod en automatisant uniquement l’update des MAJ security. Et oui il faut que cron-apt soit sur tous les serveurs.
[quote=“MisterFreez”]
La manière la plus classe que j’ai vu de gérer ça c’est de créer son propre dépôt et de tout faire passer par celui-ci. Le déploiement, l’exécution de script, tout passe par la création d’un paquet dans le dépôt qui va être ensuite installé sur le parc. Ensuite avec fabric ou cssh, on lance les mises à jours sur les machines que l’on veut. Tu peut faire des trucs assez énormes, par exemple tu as un paquet admin-web, installé uniquement sur les serveurs web : dans sa nouvelle version, elle dépend de la nouvelle version de PHP et installe la nouvelle version du site de l’entreprise. Je trouve ça magnifique. 
[/quote]
C’est vrai que cette façon de faire est très séduisante. À mon niveau je n’ai pas assez de machines à gérer pour aller dans cette direction, mais je retiens l’idée. 
[quote=“MisterFreez”]
La manière la plus classe que j’ai vu de gérer ça c’est de créer son propre dépôt et de tout faire passer par celui-ci. Le déploiement, l’exécution de script, tout passe par la création d’un paquet dans le dépôt qui va être ensuite installé sur le parc. Ensuite avec fabric ou cssh, on lance les mises à jours sur les machines que l’on veut. Tu peut faire des trucs assez énormes, par exemple tu as un paquet admin-web, installé uniquement sur les serveurs web : dans sa nouvelle version, elle dépend de la nouvelle version de PHP et installe la nouvelle version du site de l’entreprise. Je trouve ça magnifique. [/quote]
J’avais fait cela (un dépot central, un paquet local avec des scripts de configuration et des dépendances, et des corrections de scripts perso, et les paquets de mises à jour depuis une machine test) pour un parc de machines mais j’avais tout de même envie de voir si tout se passait bien. À la longue, j’ai changé pour finalement le plus simple: je regarde ce que cela donne pour une machine test puis envoie manuellement via un ssh avec identification par clef par un script les commandes de mises à jour. Le temps perdu est négligeable par rapport au fait que cela permet de vérifier l’état physique des machines.
Ils utilisent shinken pour ça, l’un des avantages c’est qu’ils ne vont pas voir si tout se passe bien c’est shinken qui viens leur dire (pareil avec nagios par exemple). Mais faut adapter son outil à ses goûts et son usage, avoir 3, 100 ou 400 machines réparties ou non sur plusieurs sites (ou pas donc) n’entraine pas les même besoins. 
Bref la bonne façon c’est celle qui nous convient.