Je pense pas que apparmor réponde à la problématique "je file tout un tas de lib en bundle".
Nitchevo parle d'un gros .deb, je dit qu'il suffirait de directement filer une appliance et basta. ( bien sur, c'était ironique mais visiblement, le sarcasme doit être explicite car distribuer 1 g de disque virtuel ne me semble pas viable personnellement )
Quand à dire que apparmor est éprouvé, je vais me permettre d’émettre des doutes.
Sur Ubuntu Precise, je compte 96 profiles dans apparmor-profiles, dont 29 pour les sous composants de postfix, plus divers doulons et triplets ( firefox compte pour 3, etc ), ce qui fait grosso modo 60 profiles. Ce qui fait en moyenne 12 profiles par an sur 5 ans, soit 1 profile par mois. Pour une technologie qui est proposé comme étant "plus simple que selinux", je trouve ce nombre curieusement bas. ( en fait si bas que j'ai chercher un autre paquet sans succès ).
À titre de comparaison, il y a 4089 types différents sur un F19, 1247 sur une wheezy. Si on prends que chaque programme va avoir en moyenne 4/5 types ( 1 pour le process, 2/3 pour les fichiers, parfois plus ), ça fait quand même de 2 à 8 fois plus de couverture.
Et tu pourrais te dire qu'avec 1 profile par mois, il y a le temps de peaufiner, mais visiblement pas vraiment ( cf ce lien que je ressort à chaque fois : http://blog.azimuthsecurity.com/2012/09/poking-holes-in-apparmor-profiles.html ). Je sais que faire une policy pour ce genre de choses requiert beaucoup de temps, de test, que les programmes sont assez compliqués, qu'il faut jongler entre "activer et bloquer par défaut puis voir les gens raler", ou "ne mettre ça qu'en opt-in puis ne pas avoir assez de retour". Et que les softs bougent sans arrêt pour le bonheur des petits et grands.
De plus, si AppArmor était suffisant, je pense qu'il n'y aurais pas besoin de coder tout un tas de choses qui manque, venant du document que tu donnes, je cite :
D-Bus will gain AppArmor mediation capabilities
Mir will be implemented with security hooks at appropriate places that AppArmor can plugin to.
If fine-grained access to GNOME Keyring is a requirement, GNOME Keyring will gain AppArmor integration
AppArmor will gain support for using a "PID" variable in profile rules
Ubuntu Online Accounts will gain AppArmor integration
Once a file is authorized, it could be dynamically loaded into the AppArmor profile by the daemon. This functionality doesn't currently exist in AppArmor
ça fait beaucoup de choses à coder ( mais le travail a déjà bien commencé pour dbus ).
Et comme j'assume totalement mon fanboyisme sur SElinux :
le 1, c'est déjà codé pour SElinux ( cf page de man de dbus-daemon ), mais que je sache peu exploité.
le 2, c'est un truc sur lequel la NSA bosse depuis 2/3 ans ( http://selinuxproject.org/page/Experimenting_With_X-Windows ). Ou d'autres gens que la NSA en fait ( http://lwn.net/Articles/517375/ ).
le 4, c'est fait nativement via SElinux vu que chaque entrée dans /proc a un label correspondant au processus. Je viens de vérifier sur l'instance publique d'openshift, j'ai pas accès au /proc des autres grâce à ça.
Je comprends parfaitement que Canonical ayant plus de compétences internes sur AppArmor préfère utiliser ça comme base, surtout si il y a pas mal de code à écrire pour mir, mais dire 4 fois dans la page que "apparmor est une technologie mature" ne rends pas la chose vraie pour autant.
Le credo d'AppArmor a toujours été "on utilise un système path based car c'est plus simple que les labels de SELinux" et c'est vrai, en retirant une couche d'indirection, tu simplifie grandement la compréhension. Mais les labels ont l'avantage de justement permettre ensuite de se mettre sur tout ce qui bouge, comme les processus, les bases de données, les objets dans xorg, les paquets réseau, etc.
Et la, avec tout ce que Canonical doit rajouter, la partie "path based et simplicité" risque d'être un peu moins vrai, et un peu moins élégante. Et si tu commences à greffer des nouveaux morceaux, ton code va plus être aussi mature et éprouvé qu'on pourrait croire.
Si l'idée est d'avoir un SDK, ça implique d'avoir une version du SDK, donc je doute que ça change grand chose à ton problème. Au lieu de viser le SDK de ta version d'Ubuntu, ils auraient pris la vielle version.
En fait, c'est surtout que faire un .deb, c'est compliqué, c'est un format relativement riche et qui possède beaucoup de possibilité. Donc faire quelque chose de sécurisé ( ie face à un attaquant déterminé ) est sans doute plus difficile qu'avec un simple tar. Donc l'idée est double, simplifier pour le dev externe, simplifier pour la sécurité.
en gros, Ubuntu veut un format en plus pour les applications tierces, genre pour son pour mobile, etc.
( je précise bien "en plus" car dpkg ne va pas disparaitre )
Mon expérience des sites démontrent que celui qui est en négatif n'est pas forcément un mauvais contributeur.
Démontrer, c'est quand on a une démonstration. La, tout au plus, tu as un jeu incomplet et subjectif d'impression. Et c'est pas parce qu'il y a des commentaires incorrectement en négatif que tes commentaires ne sont pas à juste titre dans le négatif.
Si ma mémoire est bonne, la plupart des lecteurs n'ont pas le temps de cliquer systèmatiquement sur +/-.
Ta mémoire de ?
Par contre, je le sais bien que les afficionados s'empressent de négativer un commentaire qui pourraient nuire à leurs intérêts.
C'est comme cela dans tous les sites, et je doute que sur linuxfr ils dérogent à cette règle.
Les intérêts de quoi ? C'est juste un site web, la seule chose qui fait que tu es à 0, c'est parce qu'une majeure partie des gens pense que tu es inutile dans tes interventions.
Tu as fait des études en gestion d'entreprise ? Je ne pense pas, au vu de tes commentaires sur le sujet…
Tu sais même pas ou je bosse, mais tu pars quand même du principe que je sais rien ou que je serais moins au courant que toi concernant le quatar. Ton arrogance n'a visiblement d'égale que le gouffre de ton incompétence.
Ce n'est pas parce qu'ils n'ont pas fait de cleanup de leur code que cela veut dire que c'est m…que.
Non, c'est parce que c'est merdique que c'est merdique.
C'est parce que le code est merdique, parce que l'ergonomie est merdique, parce qu'il y a une architecture moisi qui par exemple ne permet pas la mise en commun des informations ( ie, si tu veux ajouter le support ldap dans plus que le serveur, faut remettre les infos dans chaque module, super \o/ )
Par exemple pour l'ergonomie, tu prends ça : http://www.webmin.com/screenshots/chapter19/figure2.png
l'interface est pourri, y a aucune facilité de haut niveau, aucune analyse des règles, aucune facilité pour faire des choses de façon souple ou fine. C'est tout juste un éditeur web par dessus un format linéaire.
Windows est encore sur 80% des PC, je ne vois pas un éditeur se passer d'un tel marché…
un chouia plus que 80% en fait. Plus dans les 95% dans les estimations pessimistes. Pendant ce temps, le logiciel libre peine à dépasser l'erreur statistique dans les études ( genre http://www.phoronix.com/scan.php?page=news_item&px=MTM2Mjg )
Pour suivre ta logique, OpenBSD serait de la m… puisqu'on n'en parle pas ?
Alors :
1) on est entre adulte, tu as le droit de dire merde.
2) Permet moi de te citer :
J'ai dit que debian est supérieur à RHEL-like/fedora-like.
Si ce n'était pas le cas, alors tous les magazines que j'ai eu à lire ne parleraient pas de linux debian, dans leurs nombreux exemples
concernant les logiciels qu'ils veulent présenter…
Donc pour toi, Debian est supérieur à RHEL-like car les magazines en parle. Donc si les magazines parlent beaucoup plus de Windows, est ce que je doit conclure que Windows est supérieur à Debian, et si personne ne parle de OpenBSD, doit je aussi conclure que Windows est aussi supérieur à OpenBSD ?
Je parle des magazines qui parlent de Linux de manière sérieuse: il y en a tout un paquet.
Donc c'est bien ce que je dit. Ton raisonnement de "tout les magazines" ne s'appliquent qu'à un jeu restreint de magazines qui t'arrange pour tirer les conclusions. Si ça te dérange pas, je vais poser la question à mon chien, puis je vais en tirer des conclusions foireuses.
En fait, si tu arrives pas à suivre un raisonnement simple, si tu oses pas dire merde, je commence à m'interroger sur ton degré de maturité effective.
Un admin compétent sait en qui il a confiance: donc il aura par exemple confiance à la communauté comme debian.
Il n'a pas le temps de construire un paquet et n'a pas besoin de le faire car :
1/ il aura déjà la communauté qui le fait à sa place.
sauf si la communauté a une politique de mise à jour différente.
Par exemple, Debian qui a retiré haproxy de wheezy car non maintenu, et la communauté a juste un paquet pour sid ou squeeze.
Donc je fait quoi, je prends sid sachant qu'à tout moment, ça va peter ? À un obscure paquet qui va pas être plus maintenu que le paquet de wheezy avant qu'il dégage ?
2/ il l'a fait une fois pour toute et le reste du temps c'est automatisé.
C'est cela oui, c'est cela. Ça se voit que tu as vraiment aucune idée de quoi tu parles, si c'était automatique, ça fait longtemps que les distributions n'auraient plus rien à faire.
3/ si nécessaire il sous traite.
À qui ? À des admins incompétents ?
( vu que par définition, les admins compétents vont sous traités, donc il reste que les autres pour faire le taf )
Je m'attendais à du moins vingt depuis longtemps mais je suis encore qu'à moins dix dans certains commentaires.
Pardonnez moi, mais vous êtes peut-être tombé de la dernière pluie mais je connais l'histoire de Mandrake/Mageia.
Et je suis un fan de Mageia donc je vous suggèrerais de ne pas dire n'importe quoi:
vous vous ridiculisez.
une simple comparaison entre les noms sur la page et mon login te monteras que pendant que tu connais l'histoire, moi, je l'ai vécu et j'aurais tendance à dire que je l'ai fait.
a) Je ne savais pas que tu as contribué à Mandrake/Mageia…
y a en effet plein de choses que tu ignores, à commencer par savoir quand t’arrêter.
b) Je n'apprécie pas les commentaires d'un admin incompétent.
Tu peux avoir même contribué à la construction de debian que je t'aurais fait les mêmes commentaires.
bah tu peux, j'ai envoyé 3 patches y a 2 jours à Debian ( #707293 #707247 #707243 ). Rappelle moi, à quoi tu as contribué ?
( parce que bon, tu sembles parler de compétence, mais que je sache, j'ai fait preuve de ma compétence en gérant les machines de Mageia de façon bénévole, et toi, tu as juste fait preuve de ridicule en parlant sur linuxfr )
On paye quelque chose ce qui ne change rien.
Par exemple certains antivirus font une sorte de souscription annuelle pour 3 ordi…
Lorsque la souscription est terminée, la mis à jour est terminée aussi.
Une entreprise n'a pas besoin de çà.
Une entreprise n'a pas besoin de mise à jour ? C'est nouveau, j'aurais cru qu'une entreprise avaiet justement besoin de correctif de bug, de support, de ce genre de choses. Je dois pas bosser dans les bonnes boites alors.
Avec l'émergence du Cloud, debian s'imposera de facto car, l'admin [du fournisseur du cloud] voudra du debian pour gérer le
serveur/machine virtuelle/etc. servit aux clients.
y a pas grand chose encore. Tout est en dehors de la distribution, avec chacun qui refait le travail.
Le client veut que çà marche, c'est tout ce qui l'importe… Il s'en fout si c'est du debian ou un machin.
[Transfert de fichiers, mailing, web, mobilité, vpn, etc.]
En fait non, y a des gens qui veulent que ça marche et aussi que ça soit certifié pour faire tourner certains softs, certifiés vis à vis de certains standards ( exemple, fips 140 pour les USAs ), y en a qui veulent aussi être sur que les 300 servuers qui sont commandés sont certifiés pour marcher, etc. Y aussi des clients qui veulent pas refaire toute la formation de leurs employés et se foute pas trop de ce qu'il y a en dessous.
Est-ce que debian est très stable et sécurisé, à moindre coût ?
(La pérénité est-elle garantie ?)
Et la réponse est "sans doute que non". Par exemple, j'ai mis une Debian pour remplacer mes 2 serveurs chez OVH et j'ai déjà trouvé 4 soucis avec SELinux. Et que je sache, y a aucune garantie nulle part, c'est même dans la GPL et la plupart des licenses, alors que par exemple, RH va aller avec toi devant le tribunal ( cf histoire avec rackspace déjà pointé plus haut ). Tu as aucune garantie de durée du support pour ta stable, ça va durer "un certain temps", ce qui parfois est fâcheusement vague.
Tu veux dire "on va mettre un appareil avec une puce gsm dans la poche des gens, et on demande aux opérateurs de faire comme pour les bouchons et d'estimer le nombre de personne" ?
On pourrait. Bon bien sur, ensuite, on va dire qu'il y a des gens avec plusieurs tels portables, et ceux qui n'ont pas de portables. Mais je doute que ça varie plus que du simple au double comme c'est le cas actuellement.
C'est une question de leadership, s'il n'y a pas d'alternative ou que personne n'imagine te remettre en cause alors tu peut te permettre des
dérapages et autre sans perdre tout d'un coup. Pour Linus personne n'imagine sereinement reprendre ce qu'il fait, il est le seul légitime
actuel.
En même temps, le noyau est un logiciel les plus forkés. Toute les distros ont des patches qui changent le comportement, certaines dépendent même de module qui n'ont pas été admis upstream ( genre les livecds ), d'autres font leur beurre sur ça ( genre openvz ), voir rajoute des API qui font des noyaux impacompatible ( khof android khof )
Je vais pas défendre Ulrich Drepper car je pense qu'il avait un comportement de merde, mais on a évité le même genre de souci sur la glibc en partie grâce à lui.
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 ).
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.
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 ).
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é.
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.
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.
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 )).
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 :)
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 )
LE Qatar ne te dira pas si il a acheté du Red Hat ou pas.
C'est une possibilité…
Personnellement, je pense que je serais au courant si le prince du Qatar avait effectué une opération gigantesque de rachat de RH. Et tu te ridiculises de jour en jour en t'acharnant dans ton déni de réalité.
J'ai déjà répondu à la plupart des points que tu réitéres, donc je ne pense pas te convaincre plus en ressortant le même argumentaire, si tu n'es pas d'accord la première fois, tu va pas comprendre la seconde.
Mais quand même :
La plupart des applications modernes utilisent des pages web pour être configurées…
Webmin est un exemple typique.
Exemple typique d'application moderne ? On doit pas parler du même webmin avec du code perl qui continue de suivre les conventions de perl 4 ( à savoir mettre un & pour les fonctions ), et qui continue encore à se baser sur une technologie d'il y a 20 ans comme les cgis.
Et même si l'exemple est mal trouvé, le reste du point est foireux car la plupart des applis avec une interface web intégré sont soit des applications webs ( exemple, jive, sharepoint, nagios, oracle truc, drupal ), soit des applications non webs avec un serveur web en bundle ( exemple : ejabberd, couchdb ), soit des applications webs fournit à part.
Et dans tout les cas, c'est des applications que soit tu n'exposes pas sur le web ( donc hors du pool qui sort de l'étude que tu cites ), soit des applications qui ont globalement besoin de tourner sur apache et qui donc vont tourner globalement sur n'importe quel distro.
Mais ne te fais pas d'illusion dans l'embarqué Ubuntu va très probablement s'imposer notamment grâce aux smartphones…
Tu veux dire que Ubuntu va virer openwrt ou android de leur place ?
J'ai dit que debian est supérieur à RHEL-like/fedora-like.
Si ce n'était pas le cas, alors tous les magazines que j'ai eu à lire ne parleraient pas de linux debian
Alors donc, si une majeur partie des magazines que je vois chez mon buraliste parle d'installer des softs windows, je doit conclure quoi vis à vis de ton raisonnement ? Est ce qu'il ne s'applique que quand il est favorable à ta définition de supériorité ?
Tu ne vois pas MS se tirer la balle dans le pied quand même…
[C'est une entreprise commerciale]
Si les clients payent pour le support, Microsoft peut continuer pendant 50 ans.
Mais un admin compétent se fout du LTS: il fait comme moi, il construit ses propres paquets.
(Je te rappelle encore que je ne suis pas admin et j'ai des tas de paquets que j'ai moi même construits.)
Je suis content de voir que tu ne me classes pas dans "admin compétent" malgré le fait que ça soit mon travail. Parce que moi, je ne me fout pas de la durée de vie, et faire ses paquets, ça va 5 minutes mais faire le suivi des soucis des sécurité et les correctifs de bugs, c'est vite chiant ( encore une fois, je le sais, j'ai fait ça pendant un bout de temps pour des distros sur mon temps libre ). Donc j'aurais tendance à dire qu'un admin a mieux à faire que le travail d'une distribution dans son coin ( ie, faire ses propres paquets ), et qu'il apporte plus de valeur en laissant les autres faire ça, et qu'il se focalise sur les besoins plus direct. Ensuite, c'est vrai qu'il faut être compétent pour faire ses paquets, mais quand même un peu con pour ne pas mutualiser.
Je suis sur que c'est pas ton cas, et que tu peux nous montrer tout tes paquets que tu distribues sans doute ( sauf si tu n'as pas le temps et qu'au lieu d'aider, tu préfères poster sur linuxfr )
Tu te rappelles sûrement de ce que je t'avais dit: "Un admin vient me voir pour se plaindre que probablement on ne va pas investir dans la > bonne techno"
En fait, non, je passe pas mon temps à retenir ta prose incohérente. Y répondre me prends déjà assez de temps libre, et encore, je fait ça uniquement dans un but scientifique, voir à combien tu peux descendre.
[^] # Re: gros deb?
Posté par Misc (site web personnel) . En réponse au journal Un nouveau format de paquets pour Ubuntu. Évalué à 6.
Je pense pas que apparmor réponde à la problématique "je file tout un tas de lib en bundle".
Nitchevo parle d'un gros .deb, je dit qu'il suffirait de directement filer une appliance et basta. ( bien sur, c'était ironique mais visiblement, le sarcasme doit être explicite car distribuer 1 g de disque virtuel ne me semble pas viable personnellement )
Quand à dire que apparmor est éprouvé, je vais me permettre d’émettre des doutes.
Sur Ubuntu Precise, je compte 96 profiles dans apparmor-profiles, dont 29 pour les sous composants de postfix, plus divers doulons et triplets ( firefox compte pour 3, etc ), ce qui fait grosso modo 60 profiles. Ce qui fait en moyenne 12 profiles par an sur 5 ans, soit 1 profile par mois. Pour une technologie qui est proposé comme étant "plus simple que selinux", je trouve ce nombre curieusement bas. ( en fait si bas que j'ai chercher un autre paquet sans succès ).
À titre de comparaison, il y a 4089 types différents sur un F19, 1247 sur une wheezy. Si on prends que chaque programme va avoir en moyenne 4/5 types ( 1 pour le process, 2/3 pour les fichiers, parfois plus ), ça fait quand même de 2 à 8 fois plus de couverture.
Et tu pourrais te dire qu'avec 1 profile par mois, il y a le temps de peaufiner, mais visiblement pas vraiment ( cf ce lien que je ressort à chaque fois : http://blog.azimuthsecurity.com/2012/09/poking-holes-in-apparmor-profiles.html ). Je sais que faire une policy pour ce genre de choses requiert beaucoup de temps, de test, que les programmes sont assez compliqués, qu'il faut jongler entre "activer et bloquer par défaut puis voir les gens raler", ou "ne mettre ça qu'en opt-in puis ne pas avoir assez de retour". Et que les softs bougent sans arrêt pour le bonheur des petits et grands.
De plus, si AppArmor était suffisant, je pense qu'il n'y aurais pas besoin de coder tout un tas de choses qui manque, venant du document que tu donnes, je cite :
ça fait beaucoup de choses à coder ( mais le travail a déjà bien commencé pour dbus ).
Et comme j'assume totalement mon fanboyisme sur SElinux :
le 1, c'est déjà codé pour SElinux ( cf page de man de dbus-daemon ), mais que je sache peu exploité.
le 2, c'est un truc sur lequel la NSA bosse depuis 2/3 ans ( http://selinuxproject.org/page/Experimenting_With_X-Windows ). Ou d'autres gens que la NSA en fait ( http://lwn.net/Articles/517375/ ).
le 4, c'est fait nativement via SElinux vu que chaque entrée dans /proc a un label correspondant au processus. Je viens de vérifier sur l'instance publique d'openshift, j'ai pas accès au /proc des autres grâce à ça.
Je comprends parfaitement que Canonical ayant plus de compétences internes sur AppArmor préfère utiliser ça comme base, surtout si il y a pas mal de code à écrire pour mir, mais dire 4 fois dans la page que "apparmor est une technologie mature" ne rends pas la chose vraie pour autant.
Le credo d'AppArmor a toujours été "on utilise un système path based car c'est plus simple que les labels de SELinux" et c'est vrai, en retirant une couche d'indirection, tu simplifie grandement la compréhension. Mais les labels ont l'avantage de justement permettre ensuite de se mettre sur tout ce qui bouge, comme les processus, les bases de données, les objets dans xorg, les paquets réseau, etc.
Et la, avec tout ce que Canonical doit rajouter, la partie "path based et simplicité" risque d'être un peu moins vrai, et un peu moins élégante. Et si tu commences à greffer des nouveaux morceaux, ton code va plus être aussi mature et éprouvé qu'on pourrait croire.
[^] # Re: gros deb?
Posté par Misc (site web personnel) . En réponse au journal Un nouveau format de paquets pour Ubuntu. Évalué à 1.
Bah, autant filer une appliance pour VM. En fait, vu que lxc sur ubuntu permet de démarrer directement une image de vm, ça serait idéal.
[^] # Re: Ça peut être intéressant
Posté par Misc (site web personnel) . En réponse au journal Un nouveau format de paquets pour Ubuntu. Évalué à 1.
Si l'idée est d'avoir un SDK, ça implique d'avoir une version du SDK, donc je doute que ça change grand chose à ton problème. Au lieu de viser le SDK de ta version d'Ubuntu, ils auraient pris la vielle version.
[^] # Re: gros deb?
Posté par Misc (site web personnel) . En réponse au journal Un nouveau format de paquets pour Ubuntu. Évalué à 5.
En fait, c'est surtout que faire un .deb, c'est compliqué, c'est un format relativement riche et qui possède beaucoup de possibilité. Donc faire quelque chose de sécurisé ( ie face à un attaquant déterminé ) est sans doute plus difficile qu'avec un simple tar. Donc l'idée est double, simplifier pour le dev externe, simplifier pour la sécurité.
Je pense qu'à coté de ça, ils veulent aussi intégrer des choses pour le confinement d'application :
https://wiki.ubuntu.com/SecurityTeam/Specifications/ApplicationConfinement
( mais bon, le vrai troll sur Ubuntu du jour :
http://benjaminkerensa.com/2013/05/10/ubuntu-is-community
à savoir que Canonical a retiré "community" du site web "ubuntu.com", et des cris sont poussés de partout )
[^] # Re: Software center ?
Posté par Misc (site web personnel) . En réponse au journal Debian Wheezy, une distribution aux finitions impeccables !. Évalué à 1.
ça :
https://lwn.net/Articles/549704/
en gros, Ubuntu veut un format en plus pour les applications tierces, genre pour son pour mobile, etc.
( je précise bien "en plus" car dpkg ne va pas disparaitre )
[^] # Re: La caricature de Misc
Posté par Misc (site web personnel) . En réponse à la dépêche Ubuntu 13.04 Raring Ringtail. Évalué à 3.
Démontrer, c'est quand on a une démonstration. La, tout au plus, tu as un jeu incomplet et subjectif d'impression. Et c'est pas parce qu'il y a des commentaires incorrectement en négatif que tes commentaires ne sont pas à juste titre dans le négatif.
Ta mémoire de ?
Les intérêts de quoi ? C'est juste un site web, la seule chose qui fait que tu es à 0, c'est parce qu'une majeure partie des gens pense que tu es inutile dans tes interventions.
[^] # Re: "Gnome livre des versions avec des modifications faites à moitié"
Posté par Misc (site web personnel) . En réponse à la dépêche Ubuntu 13.04 Raring Ringtail. Évalué à 2.
Tu sais même pas ou je bosse, mais tu pars quand même du principe que je sais rien ou que je serais moins au courant que toi concernant le quatar. Ton arrogance n'a visiblement d'égale que le gouffre de ton incompétence.
Non, c'est parce que c'est merdique que c'est merdique.
C'est parce que le code est merdique, parce que l'ergonomie est merdique, parce qu'il y a une architecture moisi qui par exemple ne permet pas la mise en commun des informations ( ie, si tu veux ajouter le support ldap dans plus que le serveur, faut remettre les infos dans chaque module, super \o/ )
Par exemple pour l'ergonomie, tu prends ça :
http://www.webmin.com/screenshots/chapter19/figure2.png
l'interface est pourri, y a aucune facilité de haut niveau, aucune analyse des règles, aucune facilité pour faire des choses de façon souple ou fine. C'est tout juste un éditeur web par dessus un format linéaire.
un chouia plus que 80% en fait. Plus dans les 95% dans les estimations pessimistes. Pendant ce temps, le logiciel libre peine à dépasser l'erreur statistique dans les études ( genre http://www.phoronix.com/scan.php?page=news_item&px=MTM2Mjg )
Alors :
1) on est entre adulte, tu as le droit de dire merde.
2) Permet moi de te citer :
Donc pour toi, Debian est supérieur à RHEL-like car les magazines en parle. Donc si les magazines parlent beaucoup plus de Windows, est ce que je doit conclure que Windows est supérieur à Debian, et si personne ne parle de OpenBSD, doit je aussi conclure que Windows est aussi supérieur à OpenBSD ?
En fait, si tu arrives pas à suivre un raisonnement simple, si tu oses pas dire merde, je commence à m'interroger sur ton degré de maturité effective.
sauf si la communauté a une politique de mise à jour différente.
Par exemple, Debian qui a retiré haproxy de wheezy car non maintenu, et la communauté a juste un paquet pour sid ou squeeze.
Donc je fait quoi, je prends sid sachant qu'à tout moment, ça va peter ? À un obscure paquet qui va pas être plus maintenu que le paquet de wheezy avant qu'il dégage ?
C'est cela oui, c'est cela. Ça se voit que tu as vraiment aucune idée de quoi tu parles, si c'était automatique, ça fait longtemps que les distributions n'auraient plus rien à faire.
À qui ? À des admins incompétents ?
( vu que par définition, les admins compétents vont sous traités, donc il reste que les autres pour faire le taf )
Parce que -10 est le minimum.
[^] # Re: Post grognon ;-)
Posté par Misc (site web personnel) . En réponse à la dépêche Ubuntu 13.04 Raring Ringtail. Évalué à 3.
http://blog.mageia.org/en/2010/12/13/they-speak-about-mageia/
une simple comparaison entre les noms sur la page et mon login te monteras que pendant que tu connais l'histoire, moi, je l'ai vécu et j'aurais tendance à dire que je l'ai fait.
y a en effet plein de choses que tu ignores, à commencer par savoir quand t’arrêter.
bah tu peux, j'ai envoyé 3 patches y a 2 jours à Debian ( #707293 #707247 #707243 ). Rappelle moi, à quoi tu as contribué ?
( parce que bon, tu sembles parler de compétence, mais que je sache, j'ai fait preuve de ma compétence en gérant les machines de Mageia de façon bénévole, et toi, tu as juste fait preuve de ridicule en parlant sur linuxfr )
Une entreprise n'a pas besoin de mise à jour ? C'est nouveau, j'aurais cru qu'une entreprise avaiet justement besoin de correctif de bug, de support, de ce genre de choses. Je dois pas bosser dans les bonnes boites alors.
Ah oui, c'est vrai. Par exemple, rackspace, c'est pas du tout du RHEL :
http://www.internetnews.com/blog/skerner/red-hat-defends-rackspaces-defeats-linux-patent-trolls.html
Et RH, c'est pas du tout un des plus gros contribs à openstack :
http://www.openstack.org/foundation/companies/profile/red-hat-inc
Et pis EC2, c'est pas non plus du RHEL :
http://www.zdnet.com/blog/open-source/amazon-ec2-cloud-is-made-up-of-almost-half-a-million-linux-servers/10620
Pendant ce temps, Debian sur le cloud, c'est en cours de mise en place mais comme l'a dit le DPL il y a 6 mois :
http://upsilon.cc/~zack/talks/2012/20121125-minidc-cloud.pdf
y a pas grand chose encore. Tout est en dehors de la distribution, avec chacun qui refait le travail.
En fait non, y a des gens qui veulent que ça marche et aussi que ça soit certifié pour faire tourner certains softs, certifiés vis à vis de certains standards ( exemple, fips 140 pour les USAs ), y en a qui veulent aussi être sur que les 300 servuers qui sont commandés sont certifiés pour marcher, etc. Y aussi des clients qui veulent pas refaire toute la formation de leurs employés et se foute pas trop de ce qu'il y a en dessous.
Et la réponse est "sans doute que non". Par exemple, j'ai mis une Debian pour remplacer mes 2 serveurs chez OVH et j'ai déjà trouvé 4 soucis avec SELinux. Et que je sache, y a aucune garantie nulle part, c'est même dans la GPL et la plupart des licenses, alors que par exemple, RH va aller avec toi devant le tribunal ( cf histoire avec rackspace déjà pointé plus haut ). Tu as aucune garantie de durée du support pour ta stable, ça va durer "un certain temps", ce qui parfois est fâcheusement vague.
[^] # Re: On engage
Posté par Misc (site web personnel) . En réponse au journal Et si on faisait un "Who's hiring" à la linuxFr ?. Évalué à 3.
Y a pas de techos en france ?
[^] # Re: Solution
Posté par Misc (site web personnel) . En réponse au journal Méthode de calcul. Évalué à 6.
Tu veux dire "on va mettre un appareil avec une puce gsm dans la poche des gens, et on demande aux opérateurs de faire comme pour les bouchons et d'estimer le nombre de personne" ?
On pourrait. Bon bien sur, ensuite, on va dire qu'il y a des gens avec plusieurs tels portables, et ceux qui n'ont pas de portables. Mais je doute que ça varie plus que du simple au double comme c'est le cas actuellement.
[^] # Re: artillerie
Posté par Misc (site web personnel) . En réponse au journal Fin des RPS et choix cornélien. É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: Conservatisme
Posté par Misc (site web personnel) . En réponse à la dépêche Debian : Épisode VII. Évalué à 5.
En même temps, le noyau est un logiciel les plus forkés. Toute les distros ont des patches qui changent le comportement, certaines dépendent même de module qui n'ont pas été admis upstream ( genre les livecds ), d'autres font leur beurre sur ça ( genre openvz ), voir rajoute des API qui font des noyaux impacompatible ( khof android khof )
Je vais pas défendre Ulrich Drepper car je pense qu'il avait un comportement de merde, mais on a évité le même genre de souci sur la glibc en partie grâce à lui.
[^] # Re: Conservatisme
Posté par Misc (site web personnel) . En réponse à la dépêche Debian : Épisode VII. Évalué à 2.
s/utilisateurs/empaqueteurs/
la plupart des utilisateurs savent à peine que la glibc existe.
( et puis, en matière de tête de lard, y a linus, y a theo de raadt, mais bon, pour eux, c'est normal d'être colérique alors on accepte )
[^] # Re: Ma petite expérience en la matière...
Posté par Misc (site web personnel) . En réponse au journal Fin des RPS et choix cornélien. É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: Séparation par utilisateurs/groupes ?
Posté par Misc (site web personnel) . En réponse au journal Fin des RPS et choix cornélien. É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.
[^] # Re: FreeBSD
Posté par Misc (site web personnel) . En réponse au journal Fin des RPS et choix cornélien. É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: NetworkManager
Posté par Misc (site web personnel) . En réponse au sondage Quel gestionnaire de connexions réseau utilisez-vous ?. Évalué à 5.
NM peut aussi stocker les mots de passes dans gnome-keyring, mais à ce moment, le réseau n'est disponible que si tu es connecté et que pour toi.
[^] # Re: Moinssage
Posté par Misc (site web personnel) . En réponse au journal Fin des RPS et choix cornélien. É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: Séparation par utilisateurs/groupes ?
Posté par Misc (site web personnel) . En réponse au journal Fin des RPS et choix cornélien. É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: FreeBSD
Posté par Misc (site web personnel) . En réponse au journal Fin des RPS et choix cornélien. É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: Séparation par utilisateurs/groupes ?
Posté par Misc (site web personnel) . En réponse au journal Fin des RPS et choix cornélien. É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: artillerie
Posté par Misc (site web personnel) . En réponse au journal Fin des RPS et choix cornélien. É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: Moinssage
Posté par Misc (site web personnel) . En réponse au journal Fin des RPS et choix cornélien. É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: NetworkManager
Posté par Misc (site web personnel) . En réponse au sondage Quel gestionnaire de connexions réseau utilisez-vous ?. Évalué à 4.
Et wicd a des bugs amusants :
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=692417
[^] # Re: "Gnome livre des versions avec des modifications faites à moitié"
Posté par Misc (site web personnel) . En réponse à la dépêche Ubuntu 13.04 Raring Ringtail. Évalué à 2.
Personnellement, je pense que je serais au courant si le prince du Qatar avait effectué une opération gigantesque de rachat de RH. Et tu te ridiculises de jour en jour en t'acharnant dans ton déni de réalité.
J'ai déjà répondu à la plupart des points que tu réitéres, donc je ne pense pas te convaincre plus en ressortant le même argumentaire, si tu n'es pas d'accord la première fois, tu va pas comprendre la seconde.
Mais quand même :
Exemple typique d'application moderne ? On doit pas parler du même webmin avec du code perl qui continue de suivre les conventions de perl 4 ( à savoir mettre un & pour les fonctions ), et qui continue encore à se baser sur une technologie d'il y a 20 ans comme les cgis.
Et même si l'exemple est mal trouvé, le reste du point est foireux car la plupart des applis avec une interface web intégré sont soit des applications webs ( exemple, jive, sharepoint, nagios, oracle truc, drupal ), soit des applications non webs avec un serveur web en bundle ( exemple : ejabberd, couchdb ), soit des applications webs fournit à part.
Et dans tout les cas, c'est des applications que soit tu n'exposes pas sur le web ( donc hors du pool qui sort de l'étude que tu cites ), soit des applications qui ont globalement besoin de tourner sur apache et qui donc vont tourner globalement sur n'importe quel distro.
Tu veux dire que Ubuntu va virer openwrt ou android de leur place ?
Alors donc, si une majeur partie des magazines que je vois chez mon buraliste parle d'installer des softs windows, je doit conclure quoi vis à vis de ton raisonnement ? Est ce qu'il ne s'applique que quand il est favorable à ta définition de supériorité ?
Si les clients payent pour le support, Microsoft peut continuer pendant 50 ans.
Je suis content de voir que tu ne me classes pas dans "admin compétent" malgré le fait que ça soit mon travail. Parce que moi, je ne me fout pas de la durée de vie, et faire ses paquets, ça va 5 minutes mais faire le suivi des soucis des sécurité et les correctifs de bugs, c'est vite chiant ( encore une fois, je le sais, j'ai fait ça pendant un bout de temps pour des distros sur mon temps libre ). Donc j'aurais tendance à dire qu'un admin a mieux à faire que le travail d'une distribution dans son coin ( ie, faire ses propres paquets ), et qu'il apporte plus de valeur en laissant les autres faire ça, et qu'il se focalise sur les besoins plus direct. Ensuite, c'est vrai qu'il faut être compétent pour faire ses paquets, mais quand même un peu con pour ne pas mutualiser.
Je suis sur que c'est pas ton cas, et que tu peux nous montrer tout tes paquets que tu distribues sans doute ( sauf si tu n'as pas le temps et qu'au lieu d'aider, tu préfères poster sur linuxfr )
En fait, non, je passe pas mon temps à retenir ta prose incohérente. Y répondre me prends déjà assez de temps libre, et encore, je fait ça uniquement dans un but scientifique, voir à combien tu peux descendre.