A propos des clients légers et autres
considérations
rencontre "mathrice" du 25/03/04 à l'IMB
Milos nous parle de son
produit "configuration less" :
On connaissait les
disk less, les data less. Milos invente les configuration less
parcequ'il ne veut pas voir l'ombre d'un utilisateur dans son bureau et
qu'il veut minimiser le temps d'installation pour l'ingénieur
(idéal).
- disk
less : pas de système, pas de données, pas de config sur le poste
- data
less : par de données sur le poste, système configuré sur le poste
- configuration
less : pas de configuration sur le poste, le système est généré depuis
1 serveur. Données (par AFS) et systèmes présents sur le poste.
Le configuration less
se présente à l'utilisateur comme un poste "normal".
Chaque
poste se synchronise régulièrement sur un autre poste.
A chaque
synchro, le système est celui défini par l'ingénieur.
La gestion
est la même qu'un diskless sauf qu'on a un système complet.
Concepts de base :
- Séparation
totale du système de gestion des OS des postes. On peut passer d'une
distrib linux à une autre immédiatement après changement de la
configuration sur le serveur, où tout est écrit dans un seul fichier de
configuration.
- présence
minimale sur chaque poste de : kernel + initrd + root NFS. Il y a une
partition de 10Mo à part avec tout dedans.
- Aucun
shell extérieur sur les postes individuels : c'est un système qui
modifie un autre système.
- utilisation
de rsync pour synchroniser les fs
- évolutivité
et indépendance de l'Os. Pour XP, la contrainte est l'écriture ntfs
(non encore résolu)
- installation
totale par simple reboot de disquette si les partitions et les fs sont
préexistants. Au control D, 40 Go s'installent. On peut avoir plusieurs
serveurs d'installation pour minimiser les temps.
Moyens utilisés :
- readonly
nfs root fs, kernel, initrd (un peu détourné) et fichiers lilo dans une
partirion spéciale (ext2 label bootnet), boot par dhcp normal
- cfengine
définit des classes d'action en fonction des IP, lance des shells
utilisant rsync (qui ne permet que la copie simple d' 1
arborescence vers 1 autre), mais par une combinaison d'actions va
permettre des opérations + complexes telles que la fusion
d'arborescences
- pas
d'historique des opérations, l'état du poste est indépendant de son
passé. Tous les postes sont identiques (aux clés ssh, random seed, ..
près)
- lilo
avec un lilo conf généré automatiquement. Quand on boote, c'est sur la
gestion qui resynchronise puis reboote sur le secteur du disque dur.
- option
windows
2 versions du logiciel :
- V. 1
/2002 mise en place pour un parc de postes d'étudiants : 1 seule config
locale, valable pour des postes à hard identiques, gestion à partir
d'un serveur via export nfs et rsyncd, ne permet pas de configs variées
mais la reconnaissance de configs matérielles assez variées.
- V2
/2004 mise en place pour un
parc de postes variés avec des configurations variés sur des réseaux
multiples : plus de serveur central, les machines sont
interchangeables, l'ensemble du parc est autonome. Le but est de
rendre le système indépendant : il intègre sa propre duplication et
distribution. La config de l'ensemble des postes linux intel est
concentrée dans un seul répertoire distribué via le système. Presque
tout est modifiable.
Système distribué :
- noyau
mosix (pourquoi pas ?)
- AFS
(à la place de nfs) pour le partage des fichiers et les pwds
(authentification)
- basé
sur linux gentoo
- multiple
boot géré
- hotplug
et discover pour détecter les configs
Si il faut patcher,
il suffit de mettre à jour les images.
Au 1er
boot, le noyau local monte la root nfs, fait la recopie et reboote.