Journal OpenVZ sur Debian : Que prévoyez-vous avec Wheezy ?

Posté par  . Licence CC By‑SA.
Étiquettes :
14
30
avr.
2013

Bonjour à tous,

Je prends ma plume pour la première fois ici pour une question de fond à propos de Debian, OpenVZ et de la suite à donner à cette association.

C'est certainement une question que la plupart des admins qui font tourner OpenVZ sur une Debian Squeeze (sans Proxmox) doivent également se poser.
Comme chacun le sait à partir de Wheezy (aka 7.0), OpenVZ est deprecated et Debian ne fournira plus de kernel OpenVZ (cf. http://wiki.debian.org/OpenVz)

Que comptez-vous faire avec votre infrastructure actuelle ?

Pour moi, il y a 5 possibilités :

  • Upgrader votre Debian vers Wheezy et tout casser :D
  • Rester toute votre vie sur Squeeze (=> plus supporté) et prendre l'habitude de mettre à jour votre kernel à coup de RPM et alien (beurk :/)
  • Attendre patiemment que le projet OpenVZ mette à jour son dépot Wheezy (http://download.open...g/debian/dists/). Je n'y crois pas trop car la dernière version du kernel disponible remonte à octobre 2012 :(
  • Migrer de OpenVZ vers une autre solution supportée sous Wheezy (du genre LXC qui est prometteur mais pas au niveau d'OpenVZ à priori)
  • Installer Proxmox (qui repose sur Debian) et bénéficier des dernières mises à jour kernel (et plus tard également bénéficier de la mise à jour vers Wheezy)

Avec la sortie imminente de Wheezy et devant la popularité du duo Debian/OpenVZ (surtout sur les dediboites et autre kimsufi), je m'étonne de ne pas trouver plus de blogs ou sujets en rapport. Alors votre avis ?

  • # On peut espérer...

    Posté par  (site web personnel) . Évalué à 3.

    Peut-être qu'OpenVZ suivra le même chemin que Xen et sera intégré au noyau à l'avenir…

    Pour ma part, j'ai commencé les conteneurs avec LXC, et ne connaissant pas OpenVZ, je ne sais pas ce que je rate. Je m’accommode donc de la jeunesse d'LXC (pour l'instant).

    There is no spoon...

    • [^] # Commentaire supprimé

      Posté par  . Évalué à 5.

      Ce commentaire a été supprimé par l’équipe de modération.

      • [^] # Re: On peut espérer...

        Posté par  (site web personnel) . Évalué à 1.

        Certes. Mais comme le dit le premier article que tu cites, SELinux peut pallier ces problèmes de sécurité.

        OpenVZ est-il plus abouti qu'LXC concernant la sécurité ?

        There is no spoon...

        • [^] # Re: On peut espérer...

          Posté par  . Évalué à 2.

          Peut-être qu'OpenVZ suivra le même chemin que Xen et sera intégré au noyau à l'avenir…

          La plupart des patchs "lxc" du noyau proviennent des développeurs d'OpenVZ, et les versions récentes de l'userland OpenVZ peuvent se contenter d'un noyau lxc. OpenVZ dans le noyau = LXC.

          OpenVZ est-il plus abouti qu'LXC concernant la sécurité ?

          Certain ! OpenVZ tourne sur des vieux noyaux, mais encores maintenus (2.6.32, c'est la même version qu'Entreprise Linux et CentOS) coté sécurité du container lui-même ils y sont allés clairement à la truelle pour empêcher l'utilisateur du container de foutre en l'air le système, ce qui provoque au passage quelques bugs que j'ai rencontrés et la difficulté à maintenir le patchset au fil des versions du noyau, mais c'est clairement assez secure.

          Le but de LXC est de re-implémenter proprement les fonctionnalités d'OpenVZ, c'est pas encore tout à fait ça, mais ça progresse relativement vite et dans le bon sens.

          Parallèlement le but d'OpenVZ est de faire vivre la version commerciale, Virtuozzo, et donc d'avoir un truc qui marche de suite même si techniquement une demande d’intégration au noyau filerait une crise cardiaque à Linus.

          • [^] # Re: On peut espérer...

            Posté par  (site web personnel) . Évalué à 4.

            En fait, en regardant hier la video de dan walsh ( mr SElinux ) sur la façon dont la framework de sécurité est utilisé pour confiner les applications dans openshift ( une plateforme de PaaS libre, qui fait de l’hébergement massif de containeurs pour les applications déployés ), il a expliqué que "lxc n'existe pas", c'est juste des utilitaires d'IBM pour tirer parti des fonctions natives du noyau, comme les namespaces, etc. IE, c'est un abus de langage selon lui ( et déplore le fait que libvirt-lxc perpétue le nommage et la confusion si c'est pas exactement compatible )

            Il explique également le travail qu'il fait pour justement sécuriser tout ça, via virt-sandbox et l'intégration avec systemd.

            La video est sur http://www.youtube.com/watch?v=VaxkrSpBr6M , dan est pas un mauvais présentateur donc je conseille de la regarder.

          • [^] # Re: On peut espérer...

            Posté par  . Évalué à 1.

            Le but de LXC est de re-implémenter proprement les fonctionnalités d'OpenVZ

            On comprend alors pourquoi c'est plus mis en avant. Par contre je dois admettre être étonné que Debian privilégie un successeur beaucoup moins mûr et notamment au niveau sécurité que le prédécesseur. Des infos à ce sujet? Des explications sur ML peut-être? (je suis juste curieux, hein, moi et la virtualisation…)

  • # Kernels de Proxmox ?

    Posté par  . Évalué à 2.

    En prenant le repo de Proxmox et juste les kernels qui vont avec, ce serait peut-être jouable ?
    De mémoire, c'est des kernels RHEL qu'ils intègrent (peut-être je dis grosse bêtise).

  • # LXC

    Posté par  . Évalué à 4.

    Même réflexion voici 2/3 ans maintenant car déjà à l'époque c'était un peu galère de maintenir la techno à jour. J'ai switché sur LXC (et KVM mais pour d'autres besoins). LXC est clairement plus jeune mais a pour avantage une grande simplicité d'utilisation et une plutot bonne intégration à Linux (cgroup, bridge…). Le tout couplé à libvirt (pouvoir gérer LXC et KVM de la mếmé façon c'est cool).

    Mais si tu as besoin du périmêtre fonctionnel d'OpenVZ (par exemple une gestion fine des ressources ou une bonne isolation) clairement tu vas perdre avec LXC. J'ai cru voir un projet passer récemment pour rendre les containers LXC plus secure mais je me souviens plus du nom.

    PS : passer ses VMs OpenVZ en LXC est simple.

    • [^] # Re: LXC

      Posté par  . Évalué à 4.

      Pareil je suis passé à LXC y'a quelques jours, car j'ai eu besoin de certaines fonctionnalités qu'on trouves pas dans les vieux noyaux d'OpenVZ. Par contre bien que sous CentOS j'ai choisi d'utiliser l'userland lxc, libvirt est trop bloated pour l'utiliser avec juste lxc dont l'esprit est plutôt la simplicité.

      Après ça dépend des usages, perso je l'utilise plutôt comme un super-chroot pour isoler les services et simplifier l'admin, pas pour des vm avec un autre admin que moi.

      Même là j'ai blindé mon caps.drop et je travaille à faire marcher le tout avec SELinux, libvirt s'occupe automatiquement de cette partie lui, je crois.

    • [^] # Re: LXC

      Posté par  . Évalué à 2. Dernière modification le 01 mai 2013 à 01:20.

      double post

    • [^] # Re: LXC

      Posté par  (site web personnel) . Évalué à 3.

      Y a plusieurs projets. Ubuntu a poussé l'intégration avec apparmor d’après la page sur le sujet :
      https://wiki.ubuntu.com/LxcSecurity

      On trouve également la présence de seccomp pour filtrer les appels systèmes, et il y a des efforts fait à ce niveau ( même si depuis la 12.04, j'ai le sentiment que les efforts ralentissent un peu )

      Du coté de Fedora, il y a d'abord le travail sur systemd-nspawn ( qui au final utilise les mêmes APIs que l'utilitaire LXC ), et l'intégration avec svirt/libvirt ( http://kernsec.org/files/securelinuxcontainers.pdf ), et l'outil virt-sandbox.

Suivre le flux des commentaires

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