Quelles sont vos meilleures pratiques et vos plans futurs pour le déploiement de bureaux unixoid? [fermé]

J'ai installé des bureaux Linux pour un observatoire radio à but non lucratif. Pour moi, c'était la première fois que je devais penser à "déployer" plusieurs machines identiques, à centraliser la connexion, les répertoires personnels, etc. Il est rapidement devenu clair pour moi que, peut-être contrairement à l'intuition, la philosophie du «tout est textuel» ne rend pas nécessairement cela une tâche facile, et je me suis demandé ce que les administrateurs chevronnés font à ce sujet.

Dans mon cas, j'installais Ubuntu 10.04 LTS sur chaque machine. Après l'installation, j'ai exécuté un script personnalisé qui modifie les fichiers de configuration, supprime et installe le logiciel et copie certains fichiers, comme les images d'arrière-plan ou les signets du navigateur, depuis le serveur. Je pense cependant que mes questions sont indépendantes de la distribution.

Problèmes

Je rencontrais principalement deux problèmes: premièrement, des outils et des fichiers de configuration incohérents, à la fois entre les distributions et entre les versions, et deuxièmement, certains logiciels cruciaux n'exposant pas les paramètres aux fichiers de configuration de manière simple et intuitive.

Permettez-moi de donner deux courts exemples de ce que je veux dire:

L' ifconfigoutil est remplacé par ip. Tous les scripts reposant sur la présence du premier se briseront si, par exemple, ils s'exécutent sur une boîte ArchLinux actuelle. Donc, je devrais vérifier quels outils dans quelles versions sont présentes sur une machine sur laquelle j'exécute un script ... cela ressemble en quelque sorte à réinventer l'autoconf à petite échelle.

Pour le deuxième problème, considérez que je voulais donner aux bureaux une sorte "d'identité commune". Dans mon script post-installation-config, j'utilise les lignes suivantes pour y parvenir:

scp user@server:/export/admin/*.jpg /usr/share/backgrounds/
scp user@server:/export/admin/ubuntu-wallpapers.xml /usr/share/gnome-background-properties/
sed 's/warty-final-ubuntu\.png/MyBackground\.jpg/' -i /usr/share/gconf/defaults/10_libgnome2-common
sed 's/warty\-final\-ubuntu\.png/MyBackground\.jpg/' -i /usr/share/gconf/defaults/16_ubuntu-wallpapers
sed 's/ubuntu-mono-dark/ubuntu-mono-light/' -i /usr/share/gconf/defaults/16_ubuntu-artwork
sed 's/Ambiance/Clearlooks/' -i /usr/share/gconf/defaults/16_ubuntu-artwork

Je suppose que la création d'un CI est une tâche courante pour les administrateurs d'organisation. Alors, comment se fait-il qu'il n'y ait pas d'installation de configuration centrale, peut-être même multi-bureau? Devoir définir deux (identiques!) Valeurs non documentées dans deux fichiers de configuration distincts me semble étrange.

Des questions

Dans un environnement organisationnel, comment gérez-vous la configuration centrale et unifiée sur plusieurs clients?

Des systèmes comme le FAI de Debian offrent-ils des avantages significatifs (en plus de ne pas avoir à changer de CD) par rapport à ma méthode "installer d'abord, exécuter le script ensuite"?

Quelles sont les bonnes pratiques pour la transition entre les versions majeures de votre distribution? Et, outre les aspects techniques: existe-t-il un environnement de bureau qui promet une stabilité à long terme en ce qui concerne l'expérience utilisateur? Je ne pense pas pouvoir migrer mes utilisateurs vers KDE 4 ou GNOME 3, mais XFCE a encore quelques inconvénients fonctionnels ...

Existe-t-il un système * nix qui résout ce type de problèmes de configuration? Par exemple, je suppose qu'il existe des systèmes qui vous demandent des images de votre organisation (logos, images d'arrière-plan, jeux de couleurs et de polices, etc.) et les appliquent au gestionnaire de connexion, aux bureaux des utilisateurs, aux applications Web (!), Etc. sur. Remarque: Dans notre cas, je dois travailler avec des clients lourds, donc une solution purement client léger n'aidera pas.

L'utilisation de Puppet ou CFEngine ou Chef est la bonne solution à votre problème. Bien sûr, cela prendra du temps et une approche d'essai et d'erreur pour écrire le script Puppet qui fonctionne. Ces outils sont largement utilisés pour automatiser des installations complexes sur le cloud et ont simplifié la vie d'administrateurs comme nous. :)

Tout d'abord, ne vous attendez pas à ce que ce soit facile de travailler avec plusieurs distributions.

Je n'ai pas exécuté de grands déploiements de bureau. Pour moi, le meilleur compromis consistait à utiliser un démarrage LAN / tftp pour démarrer le système, puis à exécuter l'installation sur NFS. La plupart des distributions Linux vous demandent toute la configuration initiale à l'avance - vous pouvez ensuite laisser l'installateur fonctionner pendant, disons, 40 minutes, sans surveillance (aucune invite "Voulez-vous vraiment exécuter ce programme?"). À ce moment-là, je m'occupais des machines Redhat et Suse - et j'avais un RPM préparé avec toutes les configurations personnalisées que j'ai installées une fois l'installation standard terminée. Cependant, il est tout à fait possible d' automatiser tout cela sur une variété de distributions.

Je ne suis pas un grand fan de la distribution Ubuntu pour diverses raisons, mais Lanscape de Canonical est un outil très impressionnant. Et si vous allez faire beaucoup d'installations Ubuntu à grande échelle / gérer plusieurs postes de travail Ubuntu, cela vaut vraiment la peine d'être examiné de plus près.

J'ai beaucoup travaillé avec un logiciel appelé CFEngine . Il s'agit d'un gestionnaire de configuration open source qui lit les "règles" que vous définissez et garantit que chaque machine à laquelle il est lié et respecte ces règles. C'est complètement open source et si utile que notre entreprise a décidé d'utiliser la version prise en charge du logiciel appelée Nova.

Ceci est une vue d'ensemble de son fonctionnement. Supposons que vous disposez de 4 ordinateurs sur votre réseau géré. Ils ont tous besoin d'avoir un fichier /etc/syslog.conf, appartenant à root, tout de même (selon un maître) et chmod 777. Vous créeriez cette règle dans le fichier de configuration de CFEngine. Depuis votre ordinateur central, vous avez le /etc/syslog.conffichier "maître" . Toutes les X fois, la version de CFEngine de votre ordinateur passera par le réseau et interrogera chaque boîte sur son /etc/syslog.conffichier. La copie locale de CFEngine exécutée sur chaque client interrogera le fichier en question et rendra compte de son contenu, de ses autorisations, etc. S'ils ne correspondent pas EXACTEMENT à votre copie de roulette, CFEngine enverra votre copie au client et vérifiera à nouveau les fichiers. Ils correspondront et il passera à votre prochaine règle.

En ce qui concerne la simplicité, la syntaxe utilisée dans les "règles" de CFEngine (qu'ils appellent des promesses) peut prendre un peu de temps pour s'y habituer, mais elles valent la peine d'être apprises (ajoute une autre grande compétence à votre compétence).

Alors, comment se fait-il qu'il n'y ait pas d'installation de configuration centrale,

Gnome a GConf qui peut effectuer toutes ces tâches mineures:

http://wiki.novell.com/index.php/Locking_Down_the_GNOME_Desktop

http://library.gnome.org/admin/system-admin-guide/stable/gconf-9.html.en

Ubuntu LTS est presque la seule option pour une prise en charge à long terme sur le bureau.

Le déploiement de plusieurs machines est presque possible avec juste un simple dd, les distributions de bureaux en font lentement une voie moins attrayante.

Considérez également une option maintenant est le soi-disant gros client .