Y a mock, y a docker, y a lxc pour faire ça sur les distros RH like, et je suis globalement sur qu'il y a partout le même genre de trucs, ne serait ce que pour permettre une compilation propre. Un chroot en soit est sans doute une solution pour certains problèmes, mais pour lancer des serveurs, tu as souvent besoin de plus d'isolation
mock semble très axé sur la compilation, mais j'irais creuser car avoir un équivalent de debootstrap sur Centos intéresserais vraiment. Ici on ne recherche pas l'isolation, on a des machines virtuelles pour ce genre de cas, mais plutôt de pouvoir faire tourner des vieux binaires avec de la puissance de calcul. La sécurité n'est pas l'objectif pour ce cas d'usage, ce qui répond à ta dernière question.
Les gens ont aussi un manque de recul critique sur la question de la mise à jours de distribution. La principal raison de vouloir ça, c'est pour palier à la difficulté de mise en place de façon répétable d'un système. C'est souvent manuel et non documenté, et donc chiant.
Que chacun dans son coin fasse ses tests de mises à jour pour des paquets bateaux lors des changements de versions de la distribution, je trouve ça dommage. Pour reprendre l'exemple d'apache, que ce soit Debian ou Centos, si je réinstalle, je vais devoir faire un script qui bascule mes anciennes conf apache 2.2 en 2.4, mon voisin va lui aussi refaire son script chez lui et le voisin de mon voisin aussi. Si c'est une chose qui peut être prise en charge et mutualisée par une ou des distributions, tant mieux et je trouve que ça fait partie des choses qui justifie une distribution.
D'autant plus que Debian avec testing et sid le fait déjà. D'ailleurs étant en Debian testing chez moi, je suis passé de l'init classique à systemd avec de rares soucis que les mises à jour ont peu à peu réglés, sans intervention de ma part. Le changement de version a déjà été scripté et testé par Debian, pourquoi d'un coup ne plus vouloir l'utiliser.
Ça ne m'empêche pas de pouvoir réinstaller mes serveurs automatiquement en grande majorité et de virtualiser ce qui peut l'être.
[^] # Re: Bon, tu l'as cherché mais on est vendredi
Posté par jolitorax . En réponse au journal Debian Jessie, release prévue le 25 Avril avec deux nouvelles architectures. Évalué à 1.
mock semble très axé sur la compilation, mais j'irais creuser car avoir un équivalent de debootstrap sur Centos intéresserais vraiment. Ici on ne recherche pas l'isolation, on a des machines virtuelles pour ce genre de cas, mais plutôt de pouvoir faire tourner des vieux binaires avec de la puissance de calcul. La sécurité n'est pas l'objectif pour ce cas d'usage, ce qui répond à ta dernière question.
Que chacun dans son coin fasse ses tests de mises à jour pour des paquets bateaux lors des changements de versions de la distribution, je trouve ça dommage. Pour reprendre l'exemple d'apache, que ce soit Debian ou Centos, si je réinstalle, je vais devoir faire un script qui bascule mes anciennes conf apache 2.2 en 2.4, mon voisin va lui aussi refaire son script chez lui et le voisin de mon voisin aussi. Si c'est une chose qui peut être prise en charge et mutualisée par une ou des distributions, tant mieux et je trouve que ça fait partie des choses qui justifie une distribution.
D'autant plus que Debian avec testing et sid le fait déjà. D'ailleurs étant en Debian testing chez moi, je suis passé de l'init classique à systemd avec de rares soucis que les mises à jour ont peu à peu réglés, sans intervention de ma part. Le changement de version a déjà été scripté et testé par Debian, pourquoi d'un coup ne plus vouloir l'utiliser.
Ça ne m'empêche pas de pouvoir réinstaller mes serveurs automatiquement en grande majorité et de virtualiser ce qui peut l'être.