Journal Fin des RPS et choix cornélien

Posté par Misc (site web personnel) le 04 mai 2013 à 00:08. Licence CC By‑SA.

Étiquettes :

mai

2013

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 ?

# Moinssage

Posté par pamputt le 04 mai 2013 à 01:26. Évalué à 5.

Je découvre le sujet et a priori ça avait l'air intéressant. Est ce que les gens qui ont moinssé (au moins 3 à l'heure actuelle) pourraient expliqué leur geste histoire que je comprenne le « faible » intérêt du journal ?
- [^] # Re: Moinssage
  
  Posté par Tonton Benoit le 04 mai 2013 à 02:14. Évalué à 3.
  
  J'ai pas moinssé, mais j'imagine qu’ils considèrent que ça a plus sa place sur le forum ou que les systemd trolls c'était hier.
  
  Pour répondre à l'auteur, moi je suis parti sur du centOS 6 + LXC (via les binaires lxc-*, pas libvirt), pour la sécurité j'ai blindé le caps.drop et pour l'instant j'audite les services pour voir quelles règles SELinux seront nécessaires.
  
  Utiliser libvirt peut être intéressant aussi vu que y'a des options spécifiques pour le confinement SELinux des containers, mais je suis personnellement un peu allergique à libvirt.
  
  Donc perso je conseillerait CentOS 6 + libvirt, en attendant CentOS 7.
  
  Et pour le dédié pourquoi pas zieuter un peu du côté des "autres" : http://www.firstheberg.com/dedies/
  - [^] # Re: Moinssage
    
    Posté par Misc (site web personnel) le 04 mai 2013 à 10:21. Évalué à 2.
    
    J'ai pas eu de retour de cette hébergeur, et je soupçonne que ça soit des machines OVH ou dans les DC d'OVH. J'étais tombé dessus, mais j'avais décidé de laisser un peu le temps de voir la solidité de l'hébergeur.
    
    Ceci dit, si tu as des retours sur eux, je suis preneur pour la prochaine fois ( vu que le serveur a à 14e a 2 disques et assez de ram pour faire un petit serveur de virtualisation, contrairement à OVH qui file ni raid, ni VT pour ce prix la )
    - [^] # Re: Moinssage
      
      Posté par syntaxerror le 04 mai 2013 à 11:22. Évalué à 3.
      
      Pas de VT avec le serveur à 14€: http://ark.intel.com/products/59682
      Sinon j'en aurais déjà pris un …
    - [^] # Re: Moinssage
      
      Posté par Tonton Benoit le 04 mai 2013 à 13:25. Évalué à 3. Dernière modification le 04 mai 2013 à 13:26.
      
      Comme dit au dessus pas de VT sur l'Atom, mais comme je ne fait que de la virtualisation légère (LXC) ça ne me dérange pas.
      
      Perso je suis allés chez eux car c'est les seuls à proposer un SSD dans ce type de config, pour les IO concurrents de 8 machines virtuelles ça aide vraiment ! Et puis plus besoin de se soucier de la position des données sur le disque.
      
      Ce ne sont pas des revendeurs d'OVH, ils opèrent leur propre datacenter, ça a ses avantages (j'ai déjà eu des problèmes avec ds revendeurs d'OVH), par contre ils n'ont pas le réseau des gros, mais ça reste correct.
      - [^] # Re: Moinssage
        
        Posté par Misc (site web personnel) le 04 mai 2013 à 13:57. Évalué à 3.
        
        Ils opèrent leur propre salle dans un datacenter de quelqu'un d'autre, en fait
        http://www.firstheberg.com/infrastructure.php
        
        Vu qu'ils disent avoir 20 m² de salle machine, j'estime qu'il y a grosso modo 4/5 racks à tout casser et je doute du coup que la société possède les locaux.
        
        [^] # Re: Moinssage
        
        Posté par claudex le 04 mai 2013 à 22:28. Évalué à 4.
        
        Leurs stocks n'ont pas l'air très fournis en ce moment.
        
        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
        
        [^] # Re: Moinssage
        
        Posté par Tonton Benoit le 05 mai 2013 à 01:02. Évalué à 2. Dernière modification le 05 mai 2013 à 01:02.
        
        Faut demander sur le forum, je pense que c’est plutôt leur compteur qui ne marche pas ou qui n’est pas mis à jours, j'ai commandé à 0 et j'a eu le miens de suite.
# Séparation par utilisateurs/groupes ?

Posté par palkeo (site web personnel) le 04 mai 2013 à 02:48. Évalué à 5.

J'ai une question : Pourquoi tu ne ferais pas tourner php simplement avec un utilisateur différent ?
Si ton système est bien configuré et que tes fichiers ont les bonnes permissions, ça devrait le faire, non ?
- [^] # Re: Séparation par utilisateurs/groupes ?
  
  Posté par Misc (site web personnel) le 04 mai 2013 à 11:11. Évalué à 2.
  
  Idéalement et pour avoir un truc blindé, ça impliquerais pour chaque vhost d'avoir 1 user pour le php, et 1 user pour l'upload des fichiers. L'user qui fait tourner le php ( pour l'instant avec php-fpm ) devrait en effet être blindé ( idéalement, via seccomp, car les attaques sur le kernel sont un risque que j'aimerais évité, mais je ne sais pas comment utiliser seccomp sur un soft arbitraire à part en utilisant systemd ), bloqué au niveau du réseau soit via de l'uid matching dans netfilter ( facile ), soit via un namespace réseau ( moins facile, la doc d'iproute est pas stellaire ) et si possible avec des namespaces fichiers différents ( genre /tmp non partagé, , facile via pam_namespace ) pour rendre la tache plus difficile à un exploit automatique ( car je suis pas en train de me défendre contre les Illuminatis qui controle la NSA, le FSB et le MSS ).
  
  Au final, ça reviendrais pour moi à faire tout le travail de lxc ( lxc qui en soit n'est qu'un set d'outil qui utilise les namespaces ), donc un peu de la duplication d'effort, que je cherche à éviter.
  
  Peut être que tu as raison et que juste des uid différents + bons droits, ça suffit, et qu'il faut que je prenne mes pilules contre la paranoia :)
  - [^] # Re: Séparation par utilisateurs/groupes ?
    
    Posté par palkeo (site web personnel) le 04 mai 2013 à 12:27. Évalué à 2.
    
    Si tu maintiens ton système à jour, je suppose que les attaques connues sur le kernel doivent être impossibles (après forcément, ça dépend du niveau de parano :p )
    
    Perso je fonctionne comme ça, avec comme tu le dis un blocage réseau avec de l'uid matching, plein de petites règles d'hygiène (/tmp non exécutable, un répertoire temporaire par utilisateur…), et une lecture des logs (dont certains générés par un système qui surveille les fichiers modifiés).
    Je me considère comme plutôt parano aussi, et je pense que c'est suffisant.
    
    Ah, et pourquoi LXC tout seul ne te semble pas suffisant en fait ?
    - [^] # Re: Séparation par utilisateurs/groupes ?
      
      Posté par Misc (site web personnel) le 04 mai 2013 à 13:50. Évalué à 3.
      
      LXC ne me semble pas suffisant parce que j'ai lu tout ce que les distros font pour le sécuriser :
      - https://wiki.ubuntu.com/LxcSecurity
      - http://mattoncloud.org/2012/07/16/are-lxc-containers-enough/
      - http://www.slideshare.net/dpavlin/security-of-linux-containers-in-the-cloud
      
      En gros, le kernel est partagé et tout comme les chroots, tu as des milliers de façon d'en sortir sauf à customiser à fond les capacité et les permissions et bloquer des syscalls ( ce qui est faisable, mais ça reste toujours qu'une question de compromis temps/résultat ), donc je préfère laisser ça à des gens qui ont déjà fait l'effort de chercher :)
      
      Ensuite, c'est un peu les vacances, donc je peux aussi faire l'effort sans doute.
      - [^] # Re: Séparation par utilisateurs/groupes ?
        
        Posté par palkeo (site web personnel) le 04 mai 2013 à 22:20. Évalué à 2.
        
        Merci pour les liens, ce fut fort instructif !
      - [^] # Re: Séparation par utilisateurs/groupes ?
        
        Posté par barmic le 05 mai 2013 à 00:31. Évalué à 3.
        
        En gros, le kernel est partagé et tout comme les chroots, tu as des milliers de façon d'en sortir […]
        
        J'entends ça depuis des années, comment ça se fait que ça n'évolue pas ?
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Séparation par utilisateurs/groupes ?
        
        Posté par Misc (site web personnel) le 05 mai 2013 à 00:52. Évalué à 5.
        
        Parce que chroot n'est pas prévu pour la sécurité, c'est juste pour changer 1 flag sur le process. Donc je pense que changer la sémantique n'est pas terrible ( en plus de casser posix ). Il suffit de voir le changement sur les hardlinks dans /tmp, qui est activé par défaut sur Ubuntu, Debian wheezy et partout systemd se trouve depuis 2/3 versions ( ie depuis 1/2 mois ). mais toujours bloqué upstream, car 1 personne a eu un souci le jour de la sortie du 3.8.
        
        ( et même si c'est pas prévu pour la sécurité, chroot aide un peu, ça dépend de la menace ( genre un verre automatisé qui dépend de ls pour se lancer, il va avoir plus de mal ), mais ça reste pas non plus utile face à un attaquant plus sophistiqué ).
        
        Quand à lxc, il y a des travaux sur ça, cf les liens que j'ai donné pour d'une part, du coté de Canonical, poussé à l'usage d'apparmor avec l'userspace de lxc, et du coté de Red hat, l'usage de selinux avec les namespaces ( donc lxc ), notament virt-sandbox-service, systemd aussi un peu, et tout le travail fait pour openshift.
        
        Freebsd a jail pour remplacer ça, solaris a les zones, etc, etc.
        
        Et le kernel Linux reste super compliqué, et quand tu regardes tout ce que tu peux faire avec les capabilities
        http://forums.grsecurity.net/viewtopic.php?f=7&t=2522 , tu vois que rajouter plus de complexité n'aide pas vraiment.
        
        Une des solutions, ça aurait été de merger grsec ( qui propose un chroot comme celui d'openbsd ), mais Linus n'a pas envie d'arbitrer ( et je le comprends ) des disputes entre les psychopathes moyens que le monde de la sécurité héberge, et je pense donc qu'il y a juste eu une mauvaise volonté des 2 cotés.
        
        une autre, c’était de merger openvz ce qui arrive par petit bout. Quand à vserver, je pense que les devs upstreams rentrent dans la catégorie "mecs opiniatres avec qui je voudrait pas bosser" ( en tout cas, les 2 avec qui j'ai interagi ), donc ça doit être le même genre de souci que pour grsec.
# artillerie

Posté par bubar🦥 (Mastodon) le 04 mai 2013 à 05:40. Évalué à 3. Dernière modification le 04 mai 2013 à 05:44.

L'artillerie lourde est elle plus du coté d'une sandbox via libvirt/selinux, ou bien du coté d'une vm via kvm ? A priori plutot cette seconde, mais l'avancé des travaux que tu décris ici, et la fenetre entre date de besoin et date de pérénité, fait peut etre pencher la balance de l'artillerie lourde du coté de cette solution, pour le moment … Ne serais tu pas en train de réviser le "isoler des processus, pas un système complet" sur ce fait ? (et garder libvirt-sanbox pour la migration suivante) ou au contraire chercher des arguments faisant définitivement gagner le coeur sur la raison, et prendre plus de temps pour s'occuper d'une sandbox en prod ?
- [^] # Re: artillerie
  
  Posté par Misc (site web personnel) le 04 mai 2013 à 10:22. Évalué à 2.
  
  Du coté de kvm. Les serveurs les moins chers chez kimsufi sont sans VT donc ça va être lent :/
  
  En fait, rien n'est insoluble, je demande juste quoi sacrifier :)
  - [^] # Re: artillerie
    
    Posté par navaati le 05 mai 2013 à 21:07. Évalué à 1.
    
    Avec Xen tu peux faire de la virtualisation sans instructions VT, c'est la paravirtualisation.
    Mais ça garde le problème de la duplication des noyaux, c'est sûr.
    - [^] # Re: artillerie
      
      Posté par Misc (site web personnel) le 06 mai 2013 à 09:21. Évalué à 2.
      
      C'était pas non plus ultra rapide, la virtualisation sans instruction prévu pour. En tout cas sur qemu et bochs à l'époque.
      - [^] # Re: artillerie
        
        Posté par navaati le 06 mai 2013 à 12:09. Évalué à 3. Dernière modification le 06 mai 2013 à 12:10.
        
        Nan, là le truc PV de Xen ça nécessite un noyal du guest qui soit spécialement prévu pour être paravirtualisé (mais c'est mainline depuis longtemps dans linux), donc les perfs sont sensées être à peu près natives.
        
        Rien à voir avec qemu sans kvm qui lui fait de l'émulation totale, donc wep super lent.
# autres offres

Posté par Hardy Damien le 04 mai 2013 à 08:51. Évalué à 8.

Et pourquoi ne pas pousser PHP sur leur mutu a 3 kopecs par mois ? Et ne plus t'en soucier
- [^] # Re: autres offres
  
  Posté par mackwic le 04 mai 2013 à 15:16. Évalué à 3.
  
  Je pense qu'il aime le sysadmin au moins un peu, puisque c'est son boulot. Et que ça lui fait plaisir d'administrer son propre serveur.
# FreeBSD

Posté par MTux le 04 mai 2013 à 11:20. Évalué à 9.

Et pourquoi pas FreeBSD ? Toi qui est un utilisateur de Gentoo tu devrais aimer.
Les jails répondent à ton besoin.
- [^] # Re: FreeBSD
  
  Posté par Misc (site web personnel) le 04 mai 2013 à 13:38. Évalué à 2.
  J'avais pris Gentoo surtout pour essayer et pour élargir mes horizons ( d'autres vont dire pour être capable de troller efficacement sur tout ce qui bouge ), mais au final, une rolling release n'est pas ce que je cherche pour la partie php ( et pour puppet que j'utilise ) :
  - y a toujours le risque de "oops, on a un souci de sécu mais on a aussi cassé la compatibilité" ( ce qui était trop courant avant, et j'ai peur que ça ne soit pas mieux maintenant )
  - je n'ai pas le sentiment que la personnalisation que Gentoo propose m'apportais grand chose. La facilité de faire des paquets m'a permis de mettre à jour nginx et dns2tcp de maniére propre, et faut reconnaitre que faire des ebuilds est des plus simple. Mais j'ai pas changer les flags ou ce genre de choses.
  Mais oui, les BSD, j'ai pensé. Je sais pas à quel point les jails sont suffisamment sécurisé pour ma tranquillité d'esprit, même si je pense qu'on peut supposer que les exploits kernels sont moins exploités sur un FreeBSD, donc peut être moins un souci au niveau de la surface d'attaque.
  J'ai des réserves sur le fait d'industrialiser l'installation de nginx et php pour tout ça, mais c'est peut être juste une méconnaissance de ma part. Mais j'ai peur que la séparation en 2 ( ie d'un coté le système de base, de l'autre les ports ou pkgsrc ) soit au final comme une rolling release ( ie, correctif de secu par upgrade de version ), et je veux éviter ça, mais j'ai peut être tort ( pas tort d'éviter, tort de supposer que c'est semblable à une rolling release dans la gestion de la sécurité sur le long terme ( 2/3 ans )).
  - [^] # Re: FreeBSD
    
    Posté par MTux le 04 mai 2013 à 23:28. Évalué à 4. Dernière modification le 04 mai 2013 à 23:30.
    
    http://en.wikipedia.org/wiki/FreeBSD_jail#Security
    Ça a l'air pas mal sécurisé.
    En gros une jail ne peut pas modifier les tables de routage, charger des modules dans le noyau, monter des fs… ni même lancer de ping.
    Il est aussi possible d'avoir plusieurs morceaux des jails en readonly, c'est d'ailleurs fait automatiquement avec l'outil ezjail.
    
    J'ai pas beaucoup d'expérience avec FreeBSD, j'ai juste eu l'occasion de m'amuser avec quelques fois. Je sais que les ports sont proposé dans plusieurs versions. Par exemple on peut, à l'heure actuelle, installer la branche 1 de dovecot ou la branche 2. Donc tout le monde y trouve son compte.
    
    Et quand pkgng sera pleinement opérationnel (en fait il l'est, mais les dépôts publics sont fermés) on aura des ports aussi simple à gérer que sous netbsd/dflybsd avec pkgin.
    - [^] # Re: FreeBSD
      
      Posté par Misc (site web personnel) le 05 mai 2013 à 00:02. Évalué à 3.
      
      J'ai lu la doc durant les premiers samedis du libre ( honte à moi, au lieu d'aider les gens ), et si j'en crois ça :
      http://www.freebsd.org/doc/en/books/handbook/jails-application.html , ça reste encore un peu manuel et long :/
      Y a en effet plusieurs outils pour aider, dont ezjail, faut voir ce que ça vaut. ( au passage, je pige pas que personne ne s'insurge sur la violation de la FHS qu'est l'usage de /usr/jails au lieu de /var, mais bon, c'est pas lennart qui a codé ezjail, donc ça doit être acceptable ).
      
      Et en cherchant un peu pour voir le genre de souci qu'il y a, je tombe sur ça :
      http://r00tsec.blogspot.fr/2011/05/freebsd-privilege-escalation-using.html
      
      Ce qui est techniquement aussi un souci sur les namespaces de linux et pas non plus une surprise mais qui montre qu'il faut bien faire gaffe à tout. Par exemple, mon premier reflexe a été de voir si on peut accéder à un device spécifique, et la réponse "faut faire gaffe". Donc j'ai un peu peur que ça tombe dans le même cas que LXC nu, à savoir que je connais pas assez freebsd pour être sur de pas faire de connerie tôt ou tard.
      
      Quand aux ports qui sont dans plusieurs versions, je pense que ça dépend de l'upstream et ça ne me donne pas d'indication sur la durée de vie des dits ports. Par exemple, si jamais puppet est tout troué, debian/centos vont mettre à jour le paquet en corrigeant la faille et pas en upgradant le paquet. Et c'est ce que je recherche.
      
      J'ai aussi dans la foulée regardé du coté de openbsd, pour voir qu'il y a rien ( car le projet pense que c'est pas utile ), et pour netbsd, je pense qu'il faut magouiller avec rump, mais ça devient plus compliqué.
      - [^] # Re: FreeBSD
        
        Posté par MTux le 05 mai 2013 à 11:06. Évalué à 4.
        
        Effectivement la doc officielle décrit la procédure manuelle pour créer les jails. C'est utile de le faire pour apprendre, mais après on utilise généralement ezjail pour ne pas se prendre la tête : absence de compilation (il travaille en téléchargeant les sets en .txz), création d'une arborescence-template (modifiable pour créer des jails adaptées) avec des parties en read-only.
        
        Pour l'usage de /usr je ne sais pas trop pourquoi, ils aiment bien mettre des choses dedans (les ports installés, les homes…). On s'habitue.
        
        Concernant la sécurité des jails c'est à creuser. Mais c'est mature et stable, contrairement à LXC qui est jeune. Peut-être qu'il n'y a pas d'intérêt à bloquer certaines choses, sinon ce serait déjà fait.
        
        [^] # Re: FreeBSD
        
        Posté par Joris Dedieu (site web personnel) le 06 mai 2013 à 10:26. Évalué à 2.
        
        Pour l'usage de /usr je ne sais pas trop pourquoi, ils aiment bien mettre des choses dedans (les ports installés, les homes…). On s'habitue.
        
        J'avais lu quelque part qu'historiquement /usr était placé sur une seconde bande plus grande mais moins rapide que celle contenant le noyau et les éléments pour booter.
# J -50 ?????

Posté par fcartegnie le 04 mai 2013 à 16:26. Évalué à 10. Dernière modification le 04 mai 2013 à 16:27.

Arrêt du service RPS le 24 Juin 2013

Sérieusement ???
Arrêter un service à J-50, c'est limite non ?
# Ma petite expérience en la matière...

Posté par scullder le 04 mai 2013 à 21:30. Évalué à 4.

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."

Et c'est pour ça que je prends des vm pour mes besoins persos, je ne veux pas m'occuper du hardware, risquer de subir une panne et devoir réinstaller. J'ai trop peu de temps à y consacrer (ce qui a d'ailleurs dicté mon choix d'os, à savoir celui que je maîtrise le mieux, debian, directement en wheezy)…

Pour l'ipv6, je conseille ovh et beaucoup moins online. J'ai switché de online à ovh exactement pour ça.
J'avais une dedibox avec du lxc, et je voulais une ipv6 par conteneur, sauf que je n'avais qu'un /128…

Donc j'ai râlé un peu, et on m'a dit que si je voulais de l'ipv6, il fallait aller voir "en face" (parce qu'on s'en fout un peu de nos besoins de geeks avec l'ipv6 là).

Et finalement, j'ai switché vers l'offre virtual kimsufi. D'ailleurs le morceau d'amd opteron alloué à ma machine virtuelle me semble plus véloce en général que le via nano d'une dedibox de base (ça mérite benchmark).
- [^] # Re: Ma petite expérience en la matière...
  
  Posté par claudex le 04 mai 2013 à 22:33. Évalué à 4.
  
  Le problème des vm, c'est souvent l'espace disque réduit par rapport aux offres dédiées plus ou moins équivalentes.
  
  « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
  - [^] # Re: Ma petite expérience en la matière...
    
    Posté par MTux le 04 mai 2013 à 23:31. Évalué à 3.
    
    Le coût de la VM est vachement important par rapport aux ressources allouées.
    Il faut vraiment en avoir l'utilité (continuité de service…)
- [^] # Re: Ma petite expérience en la matière...
  
  Posté par Misc (site web personnel) le 05 mai 2013 à 00:53. Évalué à 2.
  
  Pour le moment, je touche du bois, j'ai eu 0 souci de hardware sur les dédiés. Les seules fois ou ç'est parti en vrille, c'est sur des serveurs d'occases qui étaient déjà vieux et torturés à l'époque ou on a chopé ça ( fusion compaq/HP ). Et c'est après des années d'usage.
  
  Le VPS classique ( né VKS ), il a moins de disque, un peu plus de cpu et autant de ram sur les versions kimsufi à 15 euros.
  Et il a un kernel custom car basé sur openvz, ce que je veux éviter ( cf mes mésaventures avant, et parce qu'un kernel custom, c'est ni selinux, ni apparmor ). Et ça implique un reboot de temps en temps sans prévenir comme j'ai pu le constater et le confirmer par d'autres.
  
  Ensuite, y a les VPS basé sur une techno VMWare ( vps cloud ). En dehors d'avoir un chouia mal au fondement d'utiliser une techno proprio, ça reste cher. 2G de ram, 2x2ghz et 100g, tu tapes dans les 30 euros par mois. Mais pas de reboot intempestif ( du moins je crois ).
  
  En face, gandi, 2G de ram, ça va dans les 35 euros.
  
  Dreamhost, 100$ par mois.
  
  Si je prends la quantité de ram comme mesure, je pense que le kimsufi ou équivalent reste meilleur marché, avec le risque de souci hardware. Et encore, si ça tombe sur autre chose que le disque, je m'en fout. Et sur le disque, je ressort puppet et les backups. Donc pour moi, c'est un risque acceptable ( vu que je perds 0 euros si j'ai du downtime bien sur ).
  - [^] # Re: Ma petite expérience en la matière...
    
    Posté par MTux le 12 mai 2013 à 21:58. Évalué à 3.
    
    Voir online.net ils ont des tarifs intéressants, et même leur entrée de gamme dispose d'un CPU avec les instructions de virtualisation :)
    - [^] # Re: Ma petite expérience en la matière...
      
      Posté par claudex le 12 mai 2013 à 22:29. Évalué à 4.
      
      un CPU avec les instructions de virtualisation
      
      Tu vois ça écrit où ? Ni http://www.online.net/fr/serveur-dedie/dedibox-sc ou http://www.via.com.tw/en/products/processors/nano/ n'en parle.
      
      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
      - [^] # Re: Ma petite expérience en la matière...
        
        Posté par Misc (site web personnel) le 13 mai 2013 à 00:10. Évalué à 2.
        
        Je confirme néanmoins, j'ai le flag vmx sur ma dedibox.
        
        $ grep vmx /proc/cpuinfo flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush acpi mmx fxsr sse sse2 ss tm pbe syscall nx lm constant_tsc rep_good nopl pni monitor vmx est tm2 ssse3 cx16 xtpr rng rng_en ace ace_en ace2 phe phe_en lahf_lm
        
        Ensuite, j'ai pas testé qemu.

Suivre le flux des commentaires

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