L'imagerie est une proposition perdante. Une installation complète de kickstart CentOS devrait prendre moins de 10 minutes. Si votre installation est beaucoup plus lente, c'est le problème qui mérite d'être étudié.
Le problème avec l'imagerie est que vous devez conserver une copie «dorée» et la mettre à jour lorsque vous apportez des modifications à votre build. Cela signifie que vous avez toujours besoin d'un mécanisme pour une installation sans assistance, et chaque changement nécessite de faire une telle installation, de changer l'image (nécessitant un mécanisme de personnalisation automatisée pour votre environnement) et de faire de cette copie la copie d'or. Si vous souhaitez apporter des modifications directement à votre copie d'or, vous vous retrouverez rapidement avec un gâchis après des années de correctifs, de mises à niveau, etc.
Si vous devez créer une image des systèmes, vous devez créer une image de la version par défaut du système d'exploitation et faire en sorte que votre travail de post-installation (personnalisation locale) se produise séparément sur chaque nouvelle machine. De cette façon, des modifications triviales de la build ne nécessiteront pas de reconstruire la copie d'or.
Si votre matériel n'est pas tous identiques, vous pouvez tirer parti de la détection / configuration automatisée de l'installateur. J'ai utilisé une configuration Kickstart pratiquement identique entre RedHat / CentOS 3, 4 et 5 et toutes sortes de matériel.
Le pire résultat de l'imagerie que j'ai jamais vu était un système d'installation de systèmes Solaris utilisant une image dorée (et dd avec des multipacks). Leur programme d'installation et de correction est si lent que cela semblait logique. Malheureusement, ils ne changent pas complètement le matériel d'un système installé. Chaque type de matériel avait sa propre image dorée. Un changement de build insignifiant nécessiterait une modification sur des dizaines de disques. Le deuxième pire était celui des machines d'imagerie de groupe Windows (encore une fois raisonnable en raison d'un programme d'installation paralysé) par rapport à un groupe Linux utilisant Kickstart. Le groupe Linux pourrait déployer une modification, par exemple, de la configuration DNS en quelques minutes. (Une minute pour changer la post-installation, puis une version de test, puis une poussée manuelle de la configuration sur les machines existantes). Le groupe Windows a dû démarrer chaque image dorée, faire le changement, annulez la corruption causée par le démarrage de l'image dorée, puis effectuez un test de build. (Ils ont également dû acheter des outils spéciaux pour automatiser les modifications de la configuration du système sur plusieurs machines, pour changer les machines existantes). Le groupe Windows avait également la possibilité de réinstaller l'image dorée pour effectuer leur changement, mais comme il s'agissait d'une installation manuelle du système d'exploitation et de dizaines d'applications, elle serait légèrement différente à chaque fois, nécessitant des semaines de tests et risquant de réduire les systèmes de production. identique qu'autrement possible.
Notez que dans les deux cas, les configurations Windows et Solaris utilisant une image dorée n'ont pas été traitées de la meilleure façon possible et certains des choix effectués par les administrateurs impliqués ont démenti un manque de compétence. Mais commencer avec un design qui n'était pas raisonnable n'a pas aidé.
Kickstart fonctionne si bien qu'il n'y a aucune raison d'envisager de faire autrement (j'ai beaucoup de petites plaintes à ce sujet, mais ce serait mille fois pire s'il était fait par des machines d'imagerie). Si votre programme d'installation est autre qu'Anaconda et que ses installations automatisées sont moins utiles que kickstart, vous devez vous demander si cette distribution a vraiment été conçue pour une utilisation en entreprise.