URL: https://linuxfr.org/users/misc/journaux/fin-des-rps-et-choix-cornelien Title: Fin des RPS et choix cornélien Authors: Misc Date: 2013年05月04日T00:08:38+02:00 License: CC By-SA Tags: ovh, systemd, selinux, ubuntu, lxc, hébergement et mageia Score: 40 J'ai eu aujourd'hui la désagréable surprise de recevoir un email d'OVh me disant en substance ceci : [IMPORTANT] Arrêt du service RPS le 24 Juin 2013 OVH a proposé le produit RPS de Janvier 2008 à Juin 2011. L'infrastructure de ce produit devient obsolète, amenant à terme de potentiels risques. OVH proposant désormais des offres plus adaptées à ce type de besoin, nous avons pris la décision de stopper le service. Le service RPS sera donc définitivement stoppé le 24 juin 2013 à 11h00. L'infrastructure sera rendue indisponible à cette date, et toutes les données que vous n'aurez pas récupérées seront perdues. Suivi de ma liste de 2 serveurs, ainsi que des conseils pour migrer ailleurs. Pour les gens qui ne connaissent pas par coeur la gamme d'OVH, le serveur RPS était une innovation intéressante de l'hébergeur. L'idée était d'avoir une machine sans disque dur, capable de booter entièrement sur le réseau, puis de monter son / en iscsi sur un SAN classique. Vu le prix du gigabit chez NetApp et consort, l'espace était limité à 10 G par défaut, mais c'était quand même sympa pour une dizaine d'euros ( avec 2 ips, un peu de ram et du cpu ). Les avantages par rapport à un serveur classique à l'époque sont la sécurité d'avoir un SAN, et le fait d'avoir son propre serveur non soumis aux envies de reboot inopiné du serveur principal comme sur les systèmes à base d'openvz ou de lxc. Les soucis sont bien sur qu'en cas de congestion réseau, le disque se bloque, et que de toute façon, les accès disque ne sont pas terribles. Et pour des raisons techniques, le noyau n'était pas modifiable, ce qui n'était pas sans causer de souci comme on va le voir. Et bien sur maintenant, le fait que ça ne soit plus supporté. Moi, j'avais trouvé ça bien, et donc j'avais pris 2 serveurs y 3 ans qu'on va nommer U et Y. U était la gentoo de base préinstallé qui m'a servi surtout de passerelle VPN et de tunnel DNS. Rien de critique pour moi. Y par contre était plus intéressant car c'est un serveur séparé pour faire tourner du php pour une amie. N'ayant aucune confiance dans ce langage, j'ai préféré isolé physiquement le serveur web sur une machine à part tournant sur une Mageia 1, Mageia non mise à jour car je ne pouvais pas utiliser systemd sur la version suivante car OVH n'avait pas compilé les cgroups dans son kernel 2.6.32 maison. Selon moi, c'est le plus gros souci de systemd, à savoir requérir d'avoir une option dans le kernel qu'on peut pas toujours modifié, mais j'ai vu presque personne n'en faire mention ici et la ce qui n'a pas amélioré ma vision du camp des anti-systemd se focalisant surtout sur des aspects totalement fumeux ( derniers exemples en date : http://www.linuxadvocates.com/2013/04/developer-dissatisfaction-looms-with.html et http://www.linuxadvocates.com/2013/05/systemd-accident-waiting-to-happen.html, qui mériterait un journal du vendredi ). Du coup, je me retrouve à devoir migrer les 2 machines fissa et comme on ne devient pas riche en signant des chèques, j'ai restreint mes choix entre prendre chez OVH un kimsufi ou une dedibox chez online. L'auto hébergement n'est pas une option car la ligne ADSL est déjà occupé et malheureusement, le monde entier traine encore sur le déploiement de l'IP v6 pour des basses raisons budgétaires dans la plupart des boites. Et je préfère éviter les VMs en location autant que possible car c'est souvent plus cher ou moins bien niveau ressources. Et j'ai pas le sentiment que ces machines soient assez critiques pour avoir besoin de la redondance que ça apporte. Ovh et dedibox, c'est blanc bonnet et bonnet blanc, donc je ne fait pas de souci. Par contre se pose la question de ce qu'il faut faire tourner dessus. Mon plan à la base pour lourder ces 2 machines, c'était d'attendre d'avoir un support correct d'une solution de container suffisamment sécurisé et simple dans une distro avec une durée de vie suffisante et de migrer. N'importe quel système Linux aurait fait l'affaire à ce niveau, je m'en fout un peu de la techno sous jacente tant que j'ai la durée de vie, j'ai fait suffisamment d'admin système dans ma vie pour me démerder n'importe ou, et s'adapter, c'est aussi mon taf. Je visait les dérivés de RHEL 7, mais c'est pas pour aujourd'hui. - Des containers car je veux isoler du php, donc des processus, pas un système complet. - Sécurisé sur car je veux partir du principe que le code qui tourne n'est pas de confiance. - Simple car j'utilise puppet, donc un système rapide à mettre en place, ça serait bien. Idéalement, si ça peut supporter plus qu'une poignée de site, ça me ferait marrer d'avoir du mass hosting ( genre 30/40 ). - Et avec une durée de vie suffisante car j'ai pas envie de gérer trop de serveurs, j'ai assez à faire en dehors. Donc j'ai rapidement fait le tour, lu le journal récent sur openvz et debian et j'ai pondu une liste de contraintes : - Tout d'abord, pas d'OpenVZ, de Vserver ( surtout pas vserver en fait ). Je veux un kernel vanilla, c'est non négociable. De la même façon, pas de ppa ou de dépôt tierce non maintenu par le projet, c'est une question d’hygiène basique. - Si possible, ne pas besoin de sortir la grosse artillerie. Qemu ou Xen en dernier recours, j'ai pas prévu de prendre une tonne de ram sur le serveur et même si 2G devrait suffire pour tout ça, ce n'est pas une raison de gaspiller. - Enfin, sécurisé et isolation, ça exclue LXC de base ou chroot. Au final, il ne reste donc plus que 2 choix sur Linux, soit LXC + SELinux, soit LXC + AppArmor. Et la, c'est le drame car dans l'absolu, la solution ou j'aurais le plus confiance et qui me semblerait le plus souple, c'est dans un système basé sur virt-sandbox-service ( donc LXC + SELinux ), mais il est trop jeune. Je considère ce dernier comme plus avancé que AppArmor car les politiques de sécurité sont plus complètes ( surtout parce que c'est le plus ancien ), et parce que visiblement, les configurations d'AppArmor chez Ubuntu sont encore un peu jeunes ( cf http://blog.azimuthsecurity.com/2012/09/poking-holes-in-apparmor-profiles.html ), et ne sont pas visiblement si facile que ça à écrire correctement, contrairement à ce que le site web nous dit. En cerise sur le gâteau, j'ai plus l'habitude de SELinux mais c'est un détail comme dit plus haut. Mais voila, bien que virt-sandbox-service fasse ce que je veux ( modulo une paire de patchs que j'ai envoyé ce soir ), il est tout nouveau et se base sur systemd ( voir pire, requiert bientôt une version de systemd d'il y a moins de 2 mois ), ce qui exclue de facto les distros à longue durée de vie pour le moment sur lesquelles je veux m'appuyer. Je me retrouve donc face à 3 alternatives : - installer une Fedora 19 ( qui sort en juillet ) comme serveur, et faire assez de tests pour que virt-sandbox-service soit correct, puis attendre un jour l'arrivée dans une Debian, une Centos, une SLES ou autre. - installer une Ubuntu LTS, et prendre LXC + AppArmor, même si je n'ai pas assez confiance dans AppArmor, ni dans la capacité de Canonical de pas changer tout d'un coup ( example, Eucalyptus vs Openstack vs Vmware, bazaar vs bzr ). Sans compter que la 12.04 est un chouia vielle sur divers composants ( genre puppet ), et que je ne sais toujours pas si les paquets en dehors de main bénéficie d'un support sécurité correct. - prendre une Debian wheezy ( elle sort ce weekend si tout va bien ), et voir à partir de la ce que je peux bricoler soit du LXC avec SELinux ( si le support selinux est aussi complet que celui de Fedora ), soit du LXC avec AppArmor comme sur Ubuntu ( si Ubuntu a poussé ça chez Debian ), soit utiliser systemd dans une version récente ( vu que systemd 44 date de novembre 2012, ça doit pouvoir se faire sans trop de souci ) Donc à choisir entre ces 3 alternatives, chères lecteurs, que devrais je faire ? Ou est ce qu'il y a d'autres propositions ( en fait, il y a d'autres idées, mais je veux juste voir si les gens les trouvent ) ? Et en fait, parmi tout les trolls qui se cachent ( systemd vs reste du monde, apparmor vs selinux, fedora vs debian vs ubuntu vs centos, obsolescence de debian ou d'ubuntu, Ipv6 vs auto-hebergement ), lequel va prendre le plus facilement ?

AltStyle によって変換されたページ (->オリジナル) /