Oui effectivement il faut bien dissocier ce que l'on va appeler le serveur YaKa (la machine qui va générer l'ensemble des packages, créer les serveurs (PXE/DHCP/etc) et les machines clients (postes desktop ou serveurs d'application).
Une fois cette distinction faite plusieurs points sont à aborder :
1. Ne pas se préoccuper d'un système de paquetage : Ceci est motivé par le fait que lorque l'on fait une mise à jour, il faut la faire sur l'ensemble des postes et que de toutes facon à la prochaine installation le serveur tftp doit être à jour : donc autant faire la mise à jour directement sur le serveur (de plus gérer des updates/dependances/fichiers de configuration à la volée est un travail fastidieux et non automatisable (je parle en tant qu'utilisateur chevronné de Gentoo ou un "-5" est toujours une mauvaise idée). Il faut noter que bien entendu les paquets compilés une première fois ne le seront pas par la suite.
L'avantage par rapport à Windows est bien sur que les paquets sont installés un à un et avec des configurations dépendantes de la machine cliente.
2. Concernant les librairies statiques il me semble que ce n'est plus d'actualité (mais je devrais vérifier). A la base il me semble que c'était pour s'assurer que rien dans le système de bootstraping de l'environement dans lequel on va tout compiler (ouf c'est long comme phrase) sur le serveur n'ai de lien en dehors de sa prison chroot. De plus sur les installations des clients les librairies dynamiques sont installées uniquement quand ceci est necessaire (grâce aux fonctions de la libelf).
3. Concernant la place necessaire évaluée à 15Go c'est la place pour compiler/deposer l'ensemble des paquets supportés par la distribution (3 version de GCC, kde, openoffice, firefox, thunderbird, ennemy territory, etc.). Ensuite il n'est pas obligatoire d'utiliser tous ces paquets (et il ne seront donc ni installés ni compilés). Pour ce qui est de openoffice il existe un flag dans les paquets qui nous permet de dire si tel ou tel paquet doit générer un tar.gz de ses binaires, c'est la raison pour laquelle on peut utiliser openoffice sans forcement le compiler (et si l'on veur le compiler il faut rajouter 10Go ... je sais mais c'est pas ma faute :) ). Les paquets binaires sont fournis pour la glibc 2.2, 2.3 et 2.4 (et j'espère bientôt la 2.5).
Concernant les installations nous avons fait un test récemment d'une réinstallation complête d'une machine d'enseignement (avec openoffice, thunderbird, firefox, et, etc.) Il faut 5 minutes montre en main sans utiliser le yaka-fs (voir plus bas) et l'installation d'un serveur est quasi instantanée (280 Mo décompressés sur le disque dur).
A propos du yaka-fs il s'agit d'un pseudo-système de fichier. En fait dans chaque paquet il est possible d'indiquer, fichier par fichier, si ce dernier est installé sur la machine ou distant. Pour le procédé distant, le fichier en local est un lien vers un disque NFS monté, en cas d'utilisation, le NFS le télécharge et le mets en cache. Un démon tournant sur la machine s'occupe de scruter ces fichiers et de remplacer ces derniers par le fichier s'il a été utilisé. Bien entendu ce système de fichier est totalement transparent pour l'utilisateur la distribution prenant tout en charge pour la configuration.
[^] # Re: Quelques explications s'il vous plait ?
Posté par Vincent LE LIGEOUR . En réponse à la dépêche YaKa une distribution orientée parc informatique et services. Évalué à 6.
Une fois cette distinction faite plusieurs points sont à aborder :
1. Ne pas se préoccuper d'un système de paquetage : Ceci est motivé par le fait que lorque l'on fait une mise à jour, il faut la faire sur l'ensemble des postes et que de toutes facon à la prochaine installation le serveur tftp doit être à jour : donc autant faire la mise à jour directement sur le serveur (de plus gérer des updates/dependances/fichiers de configuration à la volée est un travail fastidieux et non automatisable (je parle en tant qu'utilisateur chevronné de Gentoo ou un "-5" est toujours une mauvaise idée). Il faut noter que bien entendu les paquets compilés une première fois ne le seront pas par la suite.
L'avantage par rapport à Windows est bien sur que les paquets sont installés un à un et avec des configurations dépendantes de la machine cliente.
2. Concernant les librairies statiques il me semble que ce n'est plus d'actualité (mais je devrais vérifier). A la base il me semble que c'était pour s'assurer que rien dans le système de bootstraping de l'environement dans lequel on va tout compiler (ouf c'est long comme phrase) sur le serveur n'ai de lien en dehors de sa prison chroot. De plus sur les installations des clients les librairies dynamiques sont installées uniquement quand ceci est necessaire (grâce aux fonctions de la libelf).
3. Concernant la place necessaire évaluée à 15Go c'est la place pour compiler/deposer l'ensemble des paquets supportés par la distribution (3 version de GCC, kde, openoffice, firefox, thunderbird, ennemy territory, etc.). Ensuite il n'est pas obligatoire d'utiliser tous ces paquets (et il ne seront donc ni installés ni compilés). Pour ce qui est de openoffice il existe un flag dans les paquets qui nous permet de dire si tel ou tel paquet doit générer un tar.gz de ses binaires, c'est la raison pour laquelle on peut utiliser openoffice sans forcement le compiler (et si l'on veur le compiler il faut rajouter 10Go ... je sais mais c'est pas ma faute :) ). Les paquets binaires sont fournis pour la glibc 2.2, 2.3 et 2.4 (et j'espère bientôt la 2.5).
Concernant les installations nous avons fait un test récemment d'une réinstallation complête d'une machine d'enseignement (avec openoffice, thunderbird, firefox, et, etc.) Il faut 5 minutes montre en main sans utiliser le yaka-fs (voir plus bas) et l'installation d'un serveur est quasi instantanée (280 Mo décompressés sur le disque dur).
A propos du yaka-fs il s'agit d'un pseudo-système de fichier. En fait dans chaque paquet il est possible d'indiquer, fichier par fichier, si ce dernier est installé sur la machine ou distant. Pour le procédé distant, le fichier en local est un lien vers un disque NFS monté, en cas d'utilisation, le NFS le télécharge et le mets en cache. Un démon tournant sur la machine s'occupe de scruter ces fichiers et de remplacer ces derniers par le fichier s'il a été utilisé. Bien entendu ce système de fichier est totalement transparent pour l'utilisateur la distribution prenant tout en charge pour la configuration.
J'espère avoir répondu aux questions posées.
Vincent