> Il me semblait que c'était les dépendances des paquets qui était "testing".
Hmmm... je ne vois pas trop ce que tu veux dire...
Sous Debian, en tout cas :
- stable ne bouge pas, à part pour les bugs critiques, la sécu, et récemment pour les paquets volatiles (nouveau sous-dépôt permettant par exemple d'avoir des bases clamav à jour) ;
- unstable bouge tout le temps (et je la trouve vraiment "stable" pour quelque chose du genre - NB les guillemets à "stable");
- testing bouge quand ça n'introduit pas plus de bugs critiques que le paquet qui existe dans stable et que ses dépendances ont migré ou migrent en même temps, ou quand le maintien d'un paquet dans testing provoquerait des problèmes de dépendances... auquel dernier cas, le paquet est (a priori temporairement) éjecté, comme ça a longtemps été le cas avec VLC, comme ça l'est encore pour Ardour, ou comme ça l'était il y a environ une semaine, pour gtk-qt-engine ; et personnellement, je trouve que c'est le plus saoulant dans testing (même si ça se comprend bien), et c'est d'ailleurs ce qui me fait utiliser des Sid.
> Juste un truc pas très clair : pour vserver et openvz, le cpu doit supporter la virtualisation ou pas ? Comme j'ai un vieux cpu...
Ca, c'est l'intérêt principal, pour moi : mes serveurs sont des Athlon XP de récup, sans moult RAM (512Mo max), et sans instructions spécifiques à la virtualisation...
... et c'est bien pour ça que j'utilise VServer (depuis 6 mois, sans le moindre soucis : rock-stable de chez rock-stable... et pourtant, j'y fais fonctionner de l'imprimante et du scanner USB, ainsi que des cartes TV, ce qui suppose un peu de configuration pour que les conteneurs y aient accès - ie démasquage de périphs, voire ajout de gestion de capacités du noyau au conteneur), et que je me suis mis récemment à tester OpenVZ (jusqu'ici, dans un Qemu, qui me permet déjà de m'amuser avec la virtualisation complète du réseau, ce qui est excellent, puisqu'il semble vraiment qu'on puisse tout faire comme dans un vrai, plutôt que la simple isolation qui passe par le loopback, comme dans VServer).
Autre intérêt de taille, ne pas avoir à se saouler avec du CFS et cie pour partager des données entre les conteneurs : un bind mount (pas encore de possibilité de les faire en read-only, sous Etch, puisque je crois que c'est arrivé avec le kernel 2.6.24 ou 2.6.25), et zou : le conteneur à accès aux données que l'on veut.
Par contre, pas de choses comme des serveurs NFS en plein kernel (de toute façon, l'hôte a plutôt intérêt à être minimal) - ce qui n'empêche pas d'utiliser un serveur NFS en userland, dans un conteneur, s'il est suffisant, selon l'utilisation (ce qui tombe bien : c'est mon cas ;) ).
VServer est officiellement supporté par Debian (les paquets binaires du kernel patché et les outils sont dispos dans les dépôts officiels) - par contre, la doc est parfois un peu dure à trouver.
OpenVZ est maintenu par ceux qui font Virtuozzo (ils fournissent un miroir Debian avec les kernels binaires et les outils qui vont bien, même si les sources du patch et quelques outils existent déjà dans Debian) - le wiki est prolifique (pas forcément trop orienté Debian, puisqu'ils se concentrent sur les distros à RPM... m'enfin, ça ne change pas grand chose), le forum assez vivant : bref, là par contre, niveau doc, ça me paraît mieux. Niveau fonctionnalités (quotas, virtualisation et non simple isolaton du réseau, avec des possbilités de fous [pour moi, jusqu'ici utilisateur de VServer], comme d'avoir accès au broadcast dans le conteneur, de l'interface réseau physiquement gérée par le conteneur sans même que l'hôte n'y ait accès, bridging et routage avancés, conteneur pouvant être bridgé et écouter en promiscuous, par exemple, pour y mettre une sonde d'IDS, IPv6 [apparemment], iptables dans le conteneur, migration de conteneur sans interruption de service...) aussi... A noter qu'ils semblent plutôt travailler en bonne intelligence avec upstream, pour le kernel : pour le 2.6.26-rc1, 299 patches [1] sur les quelques 7500 de la release-candidate [2], soit environ 4% des patches upstream commités par l'équipe d'OpenVZ, essentiellement sur les namespaces, dans le cadre de l'intégration dans le noyau des fonctions qui lui permettront nativement d'embarquer de quoi compartimenter. Voilà qui mérite un "Kudos, OpenVZ ! Kudos !". Si toutes les boîtes qui bénéficient du libre, quand bien même elles proposent un truc proprio à côté, faisaient comme eux...
Si on n'a pas besoin de faire tourner des kernels différents, voire pire, si on ne peut pas le faire en accélérant matériellement (ce qui est faisable, mais lourd), et si on n'a pas trop de RAM à dépenser dans de la virtualisation complète, les conteneurs, c'est de la bombe : mangez-en ! Faudrait d'ailleurs que je fasse un journal quand j'aurai installé de l'OpenVZ sur des serveurs physiques, parce qu'aussi excellent qu'il ait l'air, niveau infos/publicité/... sur DLFP, c'est maigre [3].
[^] # Re: Ca marche, ça marche plus
Posté par Aefron . En réponse au journal [Darty] Putain de wifi. Évalué à 4.
Hmmm... je ne vois pas trop ce que tu veux dire...
Sous Debian, en tout cas :
- stable ne bouge pas, à part pour les bugs critiques, la sécu, et récemment pour les paquets volatiles (nouveau sous-dépôt permettant par exemple d'avoir des bases clamav à jour) ;
- unstable bouge tout le temps (et je la trouve vraiment "stable" pour quelque chose du genre - NB les guillemets à "stable");
- testing bouge quand ça n'introduit pas plus de bugs critiques que le paquet qui existe dans stable et que ses dépendances ont migré ou migrent en même temps, ou quand le maintien d'un paquet dans testing provoquerait des problèmes de dépendances... auquel dernier cas, le paquet est (a priori temporairement) éjecté, comme ça a longtemps été le cas avec VLC, comme ça l'est encore pour Ardour, ou comme ça l'était il y a environ une semaine, pour gtk-qt-engine ; et personnellement, je trouve que c'est le plus saoulant dans testing (même si ça se comprend bien), et c'est d'ailleurs ce qui me fait utiliser des Sid.
> Juste un truc pas très clair : pour vserver et openvz, le cpu doit supporter la virtualisation ou pas ? Comme j'ai un vieux cpu...
Ca, c'est l'intérêt principal, pour moi : mes serveurs sont des Athlon XP de récup, sans moult RAM (512Mo max), et sans instructions spécifiques à la virtualisation...
... et c'est bien pour ça que j'utilise VServer (depuis 6 mois, sans le moindre soucis : rock-stable de chez rock-stable... et pourtant, j'y fais fonctionner de l'imprimante et du scanner USB, ainsi que des cartes TV, ce qui suppose un peu de configuration pour que les conteneurs y aient accès - ie démasquage de périphs, voire ajout de gestion de capacités du noyau au conteneur), et que je me suis mis récemment à tester OpenVZ (jusqu'ici, dans un Qemu, qui me permet déjà de m'amuser avec la virtualisation complète du réseau, ce qui est excellent, puisqu'il semble vraiment qu'on puisse tout faire comme dans un vrai, plutôt que la simple isolation qui passe par le loopback, comme dans VServer).
Autre intérêt de taille, ne pas avoir à se saouler avec du CFS et cie pour partager des données entre les conteneurs : un bind mount (pas encore de possibilité de les faire en read-only, sous Etch, puisque je crois que c'est arrivé avec le kernel 2.6.24 ou 2.6.25), et zou : le conteneur à accès aux données que l'on veut.
Par contre, pas de choses comme des serveurs NFS en plein kernel (de toute façon, l'hôte a plutôt intérêt à être minimal) - ce qui n'empêche pas d'utiliser un serveur NFS en userland, dans un conteneur, s'il est suffisant, selon l'utilisation (ce qui tombe bien : c'est mon cas ;) ).
VServer est officiellement supporté par Debian (les paquets binaires du kernel patché et les outils sont dispos dans les dépôts officiels) - par contre, la doc est parfois un peu dure à trouver.
OpenVZ est maintenu par ceux qui font Virtuozzo (ils fournissent un miroir Debian avec les kernels binaires et les outils qui vont bien, même si les sources du patch et quelques outils existent déjà dans Debian) - le wiki est prolifique (pas forcément trop orienté Debian, puisqu'ils se concentrent sur les distros à RPM... m'enfin, ça ne change pas grand chose), le forum assez vivant : bref, là par contre, niveau doc, ça me paraît mieux. Niveau fonctionnalités (quotas, virtualisation et non simple isolaton du réseau, avec des possbilités de fous [pour moi, jusqu'ici utilisateur de VServer], comme d'avoir accès au broadcast dans le conteneur, de l'interface réseau physiquement gérée par le conteneur sans même que l'hôte n'y ait accès, bridging et routage avancés, conteneur pouvant être bridgé et écouter en promiscuous, par exemple, pour y mettre une sonde d'IDS, IPv6 [apparemment], iptables dans le conteneur, migration de conteneur sans interruption de service...) aussi... A noter qu'ils semblent plutôt travailler en bonne intelligence avec upstream, pour le kernel : pour le 2.6.26-rc1, 299 patches [1] sur les quelques 7500 de la release-candidate [2], soit environ 4% des patches upstream commités par l'équipe d'OpenVZ, essentiellement sur les namespaces, dans le cadre de l'intégration dans le noyau des fonctions qui lui permettront nativement d'embarquer de quoi compartimenter. Voilà qui mérite un "Kudos, OpenVZ ! Kudos !". Si toutes les boîtes qui bénéficient du libre, quand bien même elles proposent un truc proprio à côté, faisaient comme eux...
Si on n'a pas besoin de faire tourner des kernels différents, voire pire, si on ne peut pas le faire en accélérant matériellement (ce qui est faisable, mais lourd), et si on n'a pas trop de RAM à dépenser dans de la virtualisation complète, les conteneurs, c'est de la bombe : mangez-en ! Faudrait d'ailleurs que je fasse un journal quand j'aurai installé de l'OpenVZ sur des serveurs physiques, parce qu'aussi excellent qu'il ait l'air, niveau infos/publicité/... sur DLFP, c'est maigre [3].
[1] http://community.livejournal.com/openvz/22369.html
[2] http://kerneltrap.org/node/16101
[3] http://www.google.fr/custom?cof=AH%3Acenter%3BLP%3A1%3BLW%3A(...)