Journal Mauvaise surprise virtuelle…

Posté par jyes le 25 février 2011 à 17:56. Licence CC By‑SA.

Étiquettes :

fév.

2011

… ou comment une mauvaise surprise peut en cacher une bonne.

Comme depuis que je lis LinuxFr, je suis devenu un fervent disciple de Tanguy Ortolo, je ne confonds plus Web et Internet et j'ai mon serveur personnel à domicile qui héberge des services Web mais pas que… ce qui en fait un authentique serveur Internet.

Comme depuis que je lis TrollFr, j'ai conscience que Debian est non seulement la distribution universelle, mais qu'elle est surtout le meilleur système d'exploitation tous noyaux et toutes libc confondus, tant du point de vue de sa sécurité que de son installation, de son utilisation quotidienne ou de son site internet ^Wweb (qui était mieux avant). C'est donc tout naturellement que j'ai orienté le choix du système qui fait tourner mon serveur vers Debian.

Comme j'ai arrêté de lire AppleFr, il y a quelques années, je suis toujours persuadé que l'hégémonie des processures X86 n'est vraiment pas méritées et que l'architecture PowerPC poutre des mamans ourses. Comme Apple c'est de la pure qualitay magique et révolutionnaire, leurs machines ne meurent jamais, et c'est ainsi qu'un vieux MacBook fait tourner la Debian qui fait touner mon serveur.

Comme en arrêtant de lire AppleFr, je me suis mis aux magazines branchés et modernes qui orientent tous les bon dissaïdorz vers les solutions virtualisées, je pense que seules les machines virtuelles permettent d'allier souplesse et sécurité pour répondre aux problématiques de l'Internet d'aujourd'hui et de demain. Paré pour le Web 3.0, j'ai donc cherché une solution de virtualisation élégante pour cloisonner les services de ma machine.

Comme je reste un vieux ^Wjeune réac' qui lit Jean-Pierre Troll assiduement, j'ai gardé un certain recul sur la virtualisation et me suis en fait tourner vers une solution de cloisonnement non virtualisé, en l'occurence VServer.

Là, j'ai pendant longtemps été le plus heureux des hommes. La vie était belle, le ciel bleu et mon serveur ronronnait. Jusqu'à la sortie de Debian Squeeze. Il n'y a pas à tergiverser, cette manie de sortir des nouvelles versions trop souvent à la Debian pose bien des soucis aux administrateurs consciencieux qui veulent des logiciels éprouvés. Obligés de se tenir à jour et de courir après la nouveauté, la mode et les plaisirs éphémères. Pressé par l'abandon imminent du support de Debian Lenny, le lendemain de la sortie de Squeeze, je mettais à jour mon serveur.

Comme je suis un bon petit debianeux, j'avais d'abord lu des notes de publication qui m'informaient que Squeeze serait la dernière version de Debian à supporter VServer et que cette solution était désormais considérée osbolète. tellement obsolète qu'il semblerait même que le noyau VServer pour architecture PowerPC de Squeeze ne marche même pas. En fait il marche, mais VServer semble inutilisable. Mais ça ce n'était pas dans les notes de publication, c'était la surprise.

Comme je suis un administrateur consciencieux, j'ai une vague solution de sauvegarde pour les données mais pas pour le système et aucun serveur de test. C'est donc ma machine de prod' (relative toutefois, elle prod' pour trois utilisateurs les jours de forte charge) que j'ai mis à jour directement. Pas de panique, aucun soucis, à partir de ce moment là, mon serveur rendait autant de services Internet qu'un fer à repasser… mais je n'avais pas dis mon dernier mot.

En trois jours d'interruption de servicen j'ai pu me former à LXC (ou Linux Containers) et découvrir à quel point cette solution est belle. C'est une solution de cloisonnement un peu comme VServer. Contrairement à de la vraie virtualisation, il n'y a qu'un seul noyau qui est en charge de gérer tous les processus, mais les conteneurs Linux, un peu à la manière des prisons BSD (« jails »), permet d'exécuter des programmes dans racines et des contextes différents. Comme programmes particuliers, en exécutant les Inits de racines différentes, cela revient à faire tourner plusieurs machines virtuelles complètes.

Par rapport à VServer, c'est bien mieux, parce que ça cloisonne aussi le réseau. À l'inverse pour tranformer mon installation VServer en LXC, j'ai du reproduire le comportement non cloisonné de VServer avec LXC, ce qui se fait en créant une interface bridge, appelée ici br0. Voici ce qu'il m'a fallut ajouter au fichier /etc/network/interfaces/ :

auto br0
iface br0 inet dhcp
bridge_ports eth0

… et plus la peine d'une quelconque ligne mentionnant eth0, mon interface réseau d'origine.

Ensuite, les conteneurs doivent être configurés en utilisant un partage réseau veth. Par exemple pour mon serveur virtuel net :

# Container with network virtualized using the veth device driver
lxc.rootfs = /var/lib/lxc/net
lxc.utsname = net
lxc.network.type = veth
lxc.network.flags = up
lxc.network.link = br0
lxc.network.name = eth0
lxc.network.ipv4 = 192.168.0.2/24
lxc.network.hwaddr = AC:DE:48:00:00:02
lxc.network.veth.pair = veth02

Ici seule IPv4 est configurée, mais IPv6 fonctionne de la même manière en ajoutant une ligne lxc.network.ipv6.

Ce réglage fait qu'au démarrage du conteneur avec lxc-start -n net, l'interface veth02 est créée sur l'hôte et écoute sur le pont br0 qui partage l'interface eth0 entre les différents conteneurs. Depuis l'intérieur du conteneur net, l'interface apparente est eth0 comme précisé par lxc.network.name. Ainsi, la configuration de mon VServer d'origine peut être réutilisée telle quelle.

Dernier truc. Je n'aime pas avoir un serveur SSH qui tourne sur mes machines virtuelles et préfère limiter les programmes qui s'exécutent dessus au strict nécessaire. Avec VServer, les pseudo machines virtuelles pouvaient s'administrer en entrant dedans avec la commande vserver enter net depuis l'hôte. Ceci n'existe pas avec LXC. C'est dommage, car je voudrais ne pas pouvoir s'identifier en tant que root dans mes conteneurs. J'ai donc mis ! dans l'espace pour le mot de passe root du fichier /etc/shadow. Créer un nouvel utilisateur avec des droits sudo et m'y connecter en SSH allourdirait considérablement l'administration des conteneurs par rapport à ce que permettait VServer.

Une solution pour remédier ce problème est de créer des consoles ou s'exécute directement un interpréteur de commande en root. Par exemple la ligne suivante :

c1:12345:respawn:/sbin/getty -n -l /bin/bash 38400 tty1 linux

dans le fichier /var/lib/lxc/net/rootfs/etc/inittab me permet de me connecter au conteneur net direcement avec la commande lxc-console -n net depuis l'hôte.

Cool, non ?

Finalement, LXC est beaucoup plus simple que VServer, ne nécessite pas de patch noyau et réutilise toute l'infrastructure existante. Notamment, en utilisant les CGroups pour distinguer les contextes des différents conteneurs, ce qui permet de régler aisément des quotas pour chaque conteneur via les CGroups. La gestion du réseau est plus cmplète que VServer (quoique de ce côté il y avait déjà OpenVZ qui résolvait ce problème mais qui n'a jamais fonctionné correctement sur PowerPC).

Au final, malgré quelques sueurs froides et une coupure de service contrariante, je ne regrette pas d'avoir migré de VServer à LXC et le conseille à tous !

Je ne sais pas si ce retour d'expérience servira à quelqu'un, mais un journal coûte moins cher qu'un psy et ça m'a fait du bien d'en parler…

# Merci

Posté par Christophe Merlet (site web personnel) le 25 février 2011 à 19:42. Évalué à 10.

Je pertinente ce journal. Ton retour d'expérience a une valeur inestimable ;o)

Utilisant VServer sur quelques serveurs Debian, je n'était pas pressé pour mettre à jour sur Squeeze. Merci d'avoir essuyer et les plâtres et dégrossi le terrain sur une solution équivalente.

Que la version PowerPC de VServer ne fonctionne plus me désole. D'autant plus que, <mode torse_bombé=on> j'avais fait le portage initial de VServer sur PowerPC il y a un petits paquets d'années maintenant sur mon iMac DV lors des RMLL 2002 en présence de Jacques Gélinas himself.</mode> Bon, en réalité, le code était tellement clair et limpide que le patch devait faire moins de 10 lignes et a fonctionné du premier coup. Ça ne fait pas de moi un kernel hacker, d'autant plus que je n'avais même pas eu à chercher où modifier le code grâce aux indications de Jacques.

Depuis, je n'ai pas trouvé mieux d'un point de vue sécurité, performances et stabilité pour cloisonner totalement chaque service d'un serveur. Je vais devoir étudier LXC.
- [^] # Re: Merci
  
  Posté par geb le 28 février 2011 à 15:10. Évalué à 4.
  
  Je pertinente ce journal. Ton retour d'expérience a une valeur inestimable ;o)
  
  Idem. Mais je ne suis pas d'accord avec tout ce qui y est dit:
  
  Il semble que l'auteur ai eu des problèmes avec Debian. Ça ne veut pas dire que Vserver ne marche pas sur powerpc, cela veut simplement dire que le packaging debian est foireux. Il y a un long historique entre vserver et debian, la version lenny était tellement bricolée qu'elle en devenait totalement insecure ( http://linux-vserver.org/Installation_on_Debian#Issues_with_Lenny.27s_2.6.26_Kernel_and_Util-vserver ).
  
  D'autre part:
  
  Par rapport à VServer, c'est bien mieux, parce que ça cloisonne aussi le réseau.
  
  Il est tout à fait possible d'utiliser le même type de cloisonnement avec vserver. C'est récent, il n'y pas encore de zoli programme d'aide en userland, mais ça marche, on peut même faire tourner un deamon bgp dedans :).
  
  Je reste aussi sceptique sur les fonctionnalités des cgroups. Je gère une infra de 40 machines virtuelles sous linux vserver et dans la dernière version j'ai voulu utiliser les cgroups. Hors pour ce qui est de la limitation mémoire c'est clairement moins bien que ce que propose vserver. Il est tout à fait possible de charger le système au point de le crasher avec des comportements très simples, qui ne posaient aucun problème avec http://linux-vserver.org/Memory_Limits .
  
  Mais, il est toujours bon de rappeler que ces solutions de virtualisation légère existent. Elles gagneraient souvent à être utilisées en lieu et place de VMware, Virtualbox, kvm, xen...
# et openvz

Posté par briaeros007 le 25 février 2011 à 21:23. Évalué à 5.

Je vais peut être dire une grosse connerie, mais la dernière fois que je me suis intéressé à vserver, il y avait aussi openvz qui était "comme vserver", mais qui gérait bien le réseau itou. tu l'a essayé aussi ou pas ? Si Tu l'a testé en face de lxc qu'est ce qui t'a décidé de prendre lxc finalement ?

Quelqu'un a une idée de la différence entre les deux ? La seule grosse différence que je trouve c'est que l'un est dans vanilla , et l'autre non.
- [^] # Re: et openvz
  
  Posté par zebra3 le 25 février 2011 à 22:48. Évalué à 3.
  
  Apparemment, c'est pas que LXC est vanilla, c'est qu'il n'a pas besoin d'intégration dans le noyau puisqu'il utilise les outils déjà présents (comme les cgroups).
  
  C'est un gros avantage, car il n'y a pas à attendre que la distribution fournisse le package noyau (comme Debian qui ne fournissait OpenVZ qu'en stable et pas en testing).
  
  Et surtout, ça permet de tester rapidement sans avoir à redémarrer, comme je viens de le faire. D'autant qu'à mon niveau (basique, j'en conviens), je n'ai pas vu de grosse différence d'usage.
  
  Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
- [^] # Re: et openvz
  
  Posté par Sylvain Decremps le 26 février 2011 à 09:26. Évalué à 1.
  
  Son lien "note de publication Debian" précise que c'est le support final pour Vserver et openVZ. Donc on peut comprendre le choix extérieur à ces exclusions.
  - [^] # Re: et openvz
    
    Posté par Stéphane Klein (site web personnel) le 26 février 2011 à 11:13. Évalué à 1.
    
    "Choix extérieur à ces exclusions" ? c'est à dire… utiliser des packages externes ? ceux directement distribués par l'équipe VServer ? Personnellement c'est déjà ce que je fais.
- [^] # Re: et openvz
  
  Posté par geb le 28 février 2011 à 11:56. Évalué à 2.
  
  openvz est un bloat immonde. Ceux qui ont déjà essayé l'isolation réseau, et de faire de l'ipv6 avec, tout comme ceux qui ont déjà regardé le patch et la compatibilité avec les différentes versions du noyau, en sont vite revenus.
# Mais alors, il ne reste plus aucun avantage à VServer ?

Posté par Stéphane Klein (site web personnel) le 25 février 2011 à 22:17. Évalué à 3.

Très intéressant comme retour d'expérience.
Mais alors, il ne reste plus aucun avantage à VServer ?

Dans ce message "Re: vserver in debian squeeze" un des auteurs de VServer dit :

« LXC is solely based on mainline virtualization effords, which have become a topic of interest in the last two years ...

note that it still misses large parts required to create and maintain a secure guest environment :) »

Qu'est ce qu'il veut dire par là ? c'est seulement de l'humour ?
- [^] # Re: Mais alors, il ne reste plus aucun avantage à VServer ?
  
  Posté par ArnY (site web personnel) le 26 février 2011 à 00:16. Évalué à 5.
  Si, il reste encore au moins 2 avantages à vserver:
  - les vservers utils qui n'ont pas d'équivalent pour lxc (vserver <nomvserver> exec <cmd>, par exemple...)
  - sur vserver une commande exécutée dans le contexte du serveur hôte n'a pas conscience des autres contextes... un ps aux sur un maitre lxc liste tous les process.. y compris ceux des guests lxc. Moche.
  - [^] # Re: Mais alors, il ne reste plus aucun avantage à VServer ?
    
    Posté par jyes le 26 février 2011 à 01:30. Évalué à 4.
    Ben, justement, je ne suis pas trop convaincu…
    - Les vserver-utils se remplacent bien avec lxc-console, même si pour retrouver le même confort d'utilisation, j'ai dû démarrer un interpréteur de commande directement sur la console.
    - Les commandes exécutées dans les conteneurs ne voient pas les autres, c'est l'essentiel. Ensuite, si tu exécutes juste quelques programmes dans des conteneurs, c'est aussi bien de les voir dans les processus de l'hôte. Si tu as des systèmes complets qui tournent, alors autant tout pseudo-virtualiser et l'hôte ne contient presque plus rien, si bien que le ps de l'hôte remplace le vps de VServer.
    Donc voilà, bien que tes remarques soient vraies, les différences que tu pointes me paraissent assez insignifiantes en usage réel.
    - [^] # Re: Mais alors, il ne reste plus aucun avantage à VServer ?
      
      Posté par Raoul Volfoni (site web personnel) le 26 février 2011 à 12:58. Évalué à 0.
      
      j'ai dû démarrer un interpréteur de commande directement sur la console.
      
      Ca limite donc l'usage à ceux qui ont accès à la console. Amha c'est quand même sacrément gênant.
      - [^] # Re: Mais alors, il ne reste plus aucun avantage à VServer ?
        
        Posté par Victor le 26 février 2011 à 13:35. Évalué à 3.
        
        Je crois qu'il parle des consoles des conteneurs, accessible à travers l'hôte avec les outils de lxc !
- [^] # Re: Mais alors, il ne reste plus aucun avantage à VServer ?
  
  Posté par geb le 28 février 2011 à 12:08. Évalué à 3.
  
  On reconnaît en effet facilement la plume du mainteneur de vserver, qui passe énormement de temps à discuter sur IRC et les MLs avec ses utilisateurs.
  Il a sans doute un point de vue un peu biaisé, mais d'un autre, il y a pas grand monde qui connaisse le sujet aussi bien que lui.
  
  Et sur le fond, je suis d'accord, il y a encore des manques dans LXC et dans les cgroups. Des manques largement couverts par vserver ( cf: http://linux-vserver.org/Paper ).
  
  Certaines choses peuvent être considérées comme paranoïaques, mais peuvent s'avérer nécessaires lorsque on héberge des machines virtuelles "hostiles". Je pense par exemple à la barière chroot, ou à la possible intégration avec grsecurity. D'autres choses relèves plus du confort d'utilisation ou d'un partage équitable de ressources, pas encore top avec les cgroups (j'y reviendrais plus bas).
# Questionnement

Posté par barmic le 27 février 2011 à 17:30. Évalué à 3.

Merci beaucoup pour ton retour. Je réfléchis depuis quelques temps à la manière de procéder pour cloisonner des services sur du linux et ce de la manière la plus légère possible (donc adieux virtualisation). En fait je trouve débile l'usage de virtualisation pour ça, ça fait des dizaines d'années que des gars très compétents travaillent sur les manières de cloisonner des processus, je ne vois pas pourquoi ignorer tout ce travail au profit de solutions lourdes (qui ont tout de même pour avantage de facilement être backupée).

Je lorgnais pas mal sur vserver pendant un temps, mais j'ai finis par me dire qu'une telle solution est encore un peu trop encombrante. Quand on y réfléchis cgroup peux déjà faire une grosse partie du boulot, ensuite les quotas et une gestion fine des utilisateurs/groupes peut faire le reste (quitte à utiliser un LSM comme SELinux ou AppArmor)(il me semble qu'il n'est même plus nécessaire d'utiliser chroot), à ce panel d'outils que l'on trouve sur tout les postes (mêmes les bureaux), il reste le réseau qui est compliqué de gérer (il est difficile de limiter l'usage du réseau pour un utilisateur ou un groupe donné (à moins qu'un LSM le fasse je ne sais pas).

L'avantage de cette solution c'est qu'elle est très légère, il n'y a quasiment pas de sur coût, il y a juste un module noyau à ajouter et on économise aussi en espace disque (les processus savent où ils sont mais ne peuvent rien faire sur le reste du système de fichier). C'est un atout face à LXC qui, d'après ce que j'ai compris possède une racine par conteneur (dans le quel il faut installer tout un tas de logiciel). Par contre on perds en facilité de sauvegarde, la virtualisation est vraiment forte pour cela en ayant uniquement un fichier à mettre à jour. C'est aussi plus compliqué à mettre en œuvre il me semble.

Que pensez-vous de ce genre de méthode pour sécuriser son serveur à la place de virtualisation ou de gestionnaire de conteneur ?

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
- [^] # Re: Questionnement
  
  Posté par jyes le 27 février 2011 à 18:02. Évalué à 2.
  
  Pour compléter ton tour d'horizon et peut-être t'aider à choisir une solution, avec LXC, tu peux partager les racines de différents conteneurs et n'exécuter qu'un programme dans un conteneur. Notamment, tu peux lancer un programmme dans un conteneur LXC sur ta racine de l'hôte, ce qui permet de profiter du seul cloisonnement (notamment du réseau).
- [^] # Re: Questionnement
  
  Posté par geb le 28 février 2011 à 12:18. Évalué à 2.
  
  L'isolation se prête très bien à ce genre de chose. J'ai déjà monté une infrastructure similaire avec vserver (un service par vserver).
  
  Dans ce cas, il ne faut pas forcément considérer tes VMs comme des machines virtuelles, mais comme un groupe de processus, isolés.
  
  Il est pas exemple très facile de partager les disques entres différentes VM, de loguer de manière centralisé (simplement avec mount -o bind /dev/syslog), de gérer les mises à jour de manière centralisée ( for x in $(ls -1 /vservers); do vserver $x exec apt-get; done) , de partager l'authentification, la gestion des mails, le monitoring, les backups...
  
  Vserver se prête très bien à ça, je suppose qu'LXC aussi. Il y'aura peut être un peu plus de "cuisine" à faire manuellement, par contre.
  - [^] # Re: Questionnement
    
    Posté par jyes le 28 février 2011 à 14:40. Évalué à 2.
    Il y a plus de cuisine avec VServer qu'avec LXC. Dans ce journal, je raconte comment j'ai transformé une installation VServer en LXC, mais LXC présente des comportements très pratiques pour faire du seul cloisonnement. Pour s'en convaincre, lire le manuel de lxc-start et lxc-execute…
    
    Extrait du man lxc de ma Debian Squeeze :
```
Running an application inside a container is not exactly the same thing
as  running a system. For this reason, there are two different commands
to run an application into a container:

       lxc-execute -n foo [-f config] /bin/bash
       lxc-start -n foo [-f config] [/bin/bash]
```
    […]
```
To  summarize,  lxc-execute is for running an application and lxc-start
is better suited for running a system.
```
    - [^] # Re: Questionnement
      
      Posté par geb le 28 février 2011 à 14:54. Évalué à 2.
      
      Ok, en effet.
      
      Mais typiquement, pour partager /srv/home en tant que /home dans toutes tes VMs, tu fais comment ?
      
      Avec vserver: for x in $( ls -1 /vservers/); do echo "/srv/home /home auto rbind 0 0" >> /etc/vservers/$x/fstab; done; (Marche aussi pour /dev/syslog).
      
      Ça n'est qu'un exemple, mais je pense que ce genre d'usage avancé est plus simple avec vserver. Après, peut être que je me trompe :-).
      - [^] # Re: Questionnement
        
        Posté par jyes le 28 février 2011 à 15:11. Évalué à 2.
        
        Tu te trompes…
        Il y a le paramètre lxc.mount (et lxc.mount.entry) du fichier de conf’ pour traiter ce cas là ☺.
# lxc-console

Posté par Spack le 28 février 2011 à 11:38. Évalué à 1.

Donc j'ai fait mon conteneur lxc sans problème puis je lance lxc-console pour m'y connecter, pas de problème. Mais comment on en sort ?
- [^] # Re: lxc-console
  
  Posté par Spack le 28 février 2011 à 11:48. Évalué à 3.
  
  Bien je n'avais pas vu la ligne au début. Il faut entrer la combinaison Ctrl+a q le problème qui se pose maintenant c'est que screen intercepte le Ctrl+a.
  - [^] # Re: lxc-console
    
    Posté par KiKouN le 01 mars 2011 à 18:44. Évalué à 2.
```
Ctrl+a a q
```
    Non testé.
    - [^] # Re: lxc-console
      
      Posté par mornik le 04 mars 2011 à 10:03. Évalué à 2.
      
      En plus radical : utiliser tmux à la place de screen

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.