J'ai en effet pas cherché, j'ai juste vu le mail de Florian.
J'utilise pas Debian pour docker et je pense que docker est pas sec, pour reprendre les termes consacrés, mais je regarde un peu les choses de loin, et de mon point de vue de packageur, je sais que c'est une plaie pour la securité sur le long terme, principalement à cause de go.
Donc il y a:
- besoin du compilo go, avec l'upstream qui pousse vers la derniére release du language ( donc ça implique de backporter aussi un compilo ). Que je sache, ça tourne pas encore avec gcc-go.
( ou plutot, ça tourne avec gcc 5.0 et quelques crashs )
sans doute besoin des dernières libs (pareil, backports). Peut être des snapshots git des dites libs.
et ça compile tout en statique, ce qui rends le tracking des soucis de sécu un chouia plus compliqué.
Et encore, docker est pas si problématique, car il suffit de voir kubernetes ou openshift origin ( qui embarque etcd et kubernetes ) pour se dire que ça va être assez vite relou quand un souci va arriver. Et il faut aussi rajouter les trucs comme flannel, les autres bouts de docker, etc, pour avoir un truc qui va servir à la prod.
Debian offre les aussi la possibilité d'installer un chroot de
n'importe quelle version de Debian sur le même serveur en une
seule ligne de commande, ce qui est très pratique pour faire
tourner de vieux programmes sur un serveur récent.
Y a mock, y a docker, y a lxc pour faire ça sur les distros RH like, et je suis globalement sur qu'il y a partout le même genre de trucs, ne serait ce que pour permettre une compilation propre. Un chroot en soit est sans doute une solution pour certains problèmes, mais pour lancer des serveurs, tu as souvent besoin de plus d'isolation ( parce qu'un chroot de base, ça bloque pas les signaux ni rien d'autres ), et parfois, tu as des soucis de communication userspace/kernelspace, etc etc.
Je rajouterais aussi que dire "on peut faire tourner des vieux trucs avec une ligne de commande", c'est aussi juste se voiler la face quant au manque de compatibilité abyssal des distributions linux d'une version à une autre, surtout quand on compare à des choses comme solaris ou netbsd.
Les changements de version Debian sont simples.
Sauf quand tout d'un coup, apache change sa config et faut tout refaire. Ou que d'un coup, dovecot a dit "je change tout". Ou qu'on passe à systemd ( ce que perso, j'ai pas trouvé compliqué, mais comme tant de gens ont raler sur le sujet, je suppose que tout le monde partage pas cette avis ). Ou ce genre de détails qu'on a tendance à ranger dans la case "facile".
( attention, opinion non populaire devant )
Les gens ont aussi un manque de recul critique sur la question de la mise à jours de distribution. La principal raison de vouloir ça, c'est pour palier à la difficulté de mise en place de façon répétable d'un système. C'est souvent manuel et non documenté, et donc chiant.
En pratique, tu as plein de raison de réinstaller qui existe.
Ton serveur tombe en panne et prends feu ? Tu va devoir réinstaller.
Tu veux déplacer les machines sur un DC à 500 km ? Tu réinstalles le système à l'identique sur une nouvelle bécane et tu bouges l'ancienne sans avoir un downtime de 24 à 48h sur les services.
Tu veux un serveur de QA comme la prod ? Tu fait une installation à l'identique.
Et tu veux un upgrade ? Tu installes en changeant juste la distro de base, et tu corriges ce qui casses, sur autre chose que la prod.
Mais tout ça, ça implique d'automatiser l'installation et le déploiement, et la plupart des gens sont encore à faire les choses à la main, par manque de temps (ce qui est soit du bullshit, soit le signe d'un taf ou les gens sont toujours en mode pompier ce qui est un autre souci à régler du coté de la hiérarchie), par manque de compétence ou par ignorance.
Et donc, pour palier à ça, on se retrouve à celebrer la possibilité de faire des upgrades, au lieu d'oublier que c'est un contournement datant d'un temps ou l'automatisation était de la science fiction.
Bien sur, tout automatiser est relou. Faut commencer directement par ça ( sinon, tu te retrouves à oublier des choses, faut avoir du temps à faire le travail ( ce qui est parfois pas une mince affaire ), et soyons franc, tout les softs ne s'y prêtent pas.
A long-running problem in Debian is that several of our core teams are severely under-staffed.
Et je pense que "supporter un upgrade path presque parfait de stable à stable" rentre dans la catégorie des choses qui prennent du temps aux équipes cores, tout comme "supporter des tas d'archis", ou "avoir des milliers d'alternatives". On peut pas éviter la complexité, et je ne dit pas que ça n'apporte pas rien. Encore une fois, même si ça reste un workaround, ça corrige un souci pour une partie des utilisateurs.
La solution traditionnelle dans le logiciel libre, c'est de tenter de recruter plus de gens. Dire non, c'est super mal vu ( suffit de voir les réactions vis à vis de gnome ). Mais la solution traditionnel pour le reste du monde, c'est juste de faire moins.
par contre aucuns de nos serveurs CentOS 5 n'a été migré en 6
ou en 7.
Mais tu reçois encore des updates de sécurité dessus donc c'est pas un si gros souci ( mais je reconnais que c'est relou d'avoir des vieux trucs à gérer ). Et pour rebondir sur la solution d'utiliser un chroot, il se passe quoi si tu as un vieux bash ou un vieux openssl dans le chroot ( que tu va pas mettre à jour, si la distro est plus maintenu ) ?
De ce que j'ai vu, y a de tout dans la nature. Debian est très présent mais aussi du Centos/RHEL, et je vois de temps en temps de l'opensuse. j'ai plus rarement vu du *bsd, mais il me parait aussi évident que je vais pas en croiser vu que je fait surtout du linux :)
Mais je pense que tu as d'autres raisons que "tu as pas le choix" pour prendre autre chose que Debian. Par exemple, j'ai eu des surprises chez un client ( genre, du matos acheté sans vérifier la compatibilité, et donc qui ne marchait pas sans devoir bidouillé et mettre le serveur à moité en testing ). À minima, les certifs hardwares évitent ça et même si dans mon cas, c'était 2 serveurs internes d'infra, ça aurait pu être 40 sur internet. Et autant, 2 à 3 ans de support sécu, c'est déjà bien, autant, je comprends que plus, c'est aussi pas mal ( dit-il en pensant au serveur VPN en RHEL 5 de son taf ).
Il y a aussi des différences technologiques parfois assez importantes. Si tu veux déployer un truc comme freeipa ( qui est de la bombe, ça déchire de déployer kerberos/ldap/etc via 1 commande ), ou les choses produites par des communautés ou RH est un gros ou le seul sponsor important comme openshift, kubernetes, les trucs autour de docker ( surtout que le dit docker a été viré de jessie ), Debian est pas forcément le choix le plus probant ( Ubuntu à la rigueur, mais ils poussent aussi pas mal leur stack en priorité, genre lxc, maas, juju ).
À contrario, si tu veux des trucs un peu exotiques ou spécifiques, Debian propose sans doute un paquet ( genre dans le monde scientifique, ou j'ai le sentiment qu'il y a une tonne de paquets, de part l'attachement des scientifiques à ses idéaux non commerciaux ).
Par exemple, ansible tourne par dessus funcd, ou supporte d'entrer dans une zone, un lxc, ou un chroot.
Et j'ai un bout de code qui le fait marcher par dessus salt, modulo le dernier bug que je doit corriger ( je sais pas si c'est du coté de salt ou du coté d'ansible, mais la ligne de commande shell que ansible utilise coince avec salt )
Tu es pas obligé. Tu as comme dit "ansible-pull", ou tu peux utiliser mon role de bastion ( https://github.com/OSAS/ansible-role-ansible_bastion ), ou tu commites via git et ça déclenche la mise à jour sélective depuis une machine central ( et idéalement mieux sécurisé ).
J'ai tenté de travailler sur un setup avec ansible-pull , mais j'ai encore le souci de distribution des secrets ( ie, comment je m'assure qu'un serveur compromis n'a pas d'accés au mot de passe des autres serveurs,
J'utilise assez souvent le cache des facts pour avoir une vue globale de mon infra, et ça utilise le fait d'avoir un seul serveur pour ça. Mais je pense que le partage des données en cache devrait être reglé par : https://github.com/ansible/ansible/pull/9804 ), j'ai juste pas tenté.
Ansible est un moteur d'execution de modules via ssh. Tu décrit un tache ( 'installer un paquet via yum' ), et tu lances la tache sur X machines décrit dans un fichier d'inventaire. C'est le mode le plus simple.
Ensuite, tu as "décrire plusieurs taches, et les lancer sur une ou plusieurs machines", ce qui est un playbook. La, tu peut soit faire de la convergence de configuration ( ie, relancer le playbook qui indique comment ton serveur doit être installé, et miser sur le fait que les taches soient idempotentes pour que ça marche ), soit faire de l'orchestration ( genre je prends 3 serveurs, je les retire de nagios et du load balancer, j'upgrade, je reboote, je remets dans nagios, le load balancer, et je passe aux 3 suivants ).
Et comme ansible est flexible, tu peux faire plus que du ssh. Par exemple, considerer que "chroot /foo" est une connexion à un os différent. Ou dans le cas de l'article, que lxc ou docker le soit. Et donc, tu peut preparer une arborescence pour usage futur. Genre pour usage dans une image docker. Ou comme j'ai tenté de le faire, pour une image ostree.
Moi, je crois que c'est un plan de Lennart Poettering pour diviser le monde des browsers libres afin d'imposer browserd pour unifier le monde du libre autour d'une seul implémentation.
La preuve la plus flagrante est qu'on ne trouve aucun lien avec systemd, ce qui prouve bien qu'ils ont un truc à cacher.
De ce qu'on m'a dit que c'est assez dépendant des équipes et de leur manager, y en a ou il y a du temps, d'autre pas. Je connais quelqu'un qui a fait du volontariat pour un événement, et Google a versé de l'argent parce qu'il a fait du volontariat. Je connais quelqu'un qui a codé sur un outil que Google n'utilise pas (ou du moins, pas pour leur serveur) de façon assez conséquente, sur son temps de travail.
Vu la croissance de la boite, c'est pas non plus surprenant que ça soit moins uniforme qu'on l'imagine, et le coté magique de Google, c'est aussi de faire croire que c'est radicalement différent d'une autre grosse boite. C'est peut être le cas sur d'autres choses, mais il y a sans doute aussi des trucs tout à fait terre à terre ou des machins qui ont changés depuis pour diverses raisons ( ou des gens qui ont mal compris ).
Ils ont lancé le service en 2010. Donc en ~3 ans, ils ont réalisé le même chiffre d'affaire que Red hat en plus de 15 ans.
Ou 5 fois plus qu'OVH en 2013, sur un segment similaire.
Alors c'est pas mon genre de défendre microsoft, mais ils ont des centres de recherches qui produisent des tonnes de trucs.
Par exemple, Leslie Lamport bosse chez eux, il a quasiment inventé Paxos et divers variantes, et ça, c'est utilisé à fond par Google ( parmi tant d'autres ).
De ce que je sais, y a pas mal de projets juste en france avec l'inria, et l'innovation, c'est pas juste "refaire un os pour telephone en java", ou "refaire un navigateur web"….
C'est pas un ou exclusif. Tu peux faire un procès et changer de FAI. Tout comme tu peux aller aux prud'hommes et changer de taf. Tu peux remplir un rapport de bug et changer de logiciel.
Autre cas d'usage, tu as la création de microservice, avec les promesses de "ça scale à mort si c'est bien fait, et ça mutualise les ressources", mais surtout "les gens vont pas avoir besoin d'avancer à la même vitesse" ( ie, une solution à des soucis qu'on peut qualifier de social ).
Tu as aussi les histoires de mutualisation, cad diviser tes machines sans avoir la lourdeur des VMs ( lourdeur dans le sens ou il faut gérer les serveurs même virtuels ). J'ai prévu quand j'aurais du temps de jouer avec openshift v3, une surcouche sur kubernetes, qui est lui même un système d'orchestration de containers pour faire de l’hébergement des projets sur lequel je bosse. L'idée de faire des rollbaks rapidement est à mon sens utile pour que les gens puissent pousser sans risque, le fait de pouvoir tester chez toi sur docker est aussi pas mal pour ça.
Donc bon, je me voit pas déployer tout ( loin de la ), mais y a des trucs ou ça peut se révéler pas mal.
Dans mon souvenir, l'usage de l'UTF8 dans tex/latex est toujours un peu tendu, mais j'imagine qu ça compte pas comme bug, mais comme évolution.
Des gens vont te dire que tex est pas facile à utiliser, mais vu le mépris qu'on a pour les gens qui veulent rendre les choses plus simples, j'imagine que ça ne compte pas comme bug non plus.
Les bureaux sont en région parisienne, à la défense ( tour Franklin, sauf erreur de ma part ), mais la boite est ouverte au télétravail (on peut citer Vincent Untz comme superstar bossant depuis Grenoble, par exemple, mais j'en connais d'autre).
Ceci dit, il y a des travaux sur le fait d'avoir la pile tcp/ip en userspace, et avoir des interpréteurs directement lancé à la place du kernel (notamment sur des VM, voir le projet Mirage, erlang on xen, etc).
Donc la question de la séparation kernelspace/userspace est en effet remis en cause. Après tout, pendant longtemps, on a eu les drivers graphiques en dehors du kernel. ( et on a encore des drivers en dehors pour l'USB, par exemple, ou les imprimantes ).
Le type ne dit pas que Linux va disparaître, le mec dit que
Linux va être approprié par RedHat.
ce qui prouve qu'il y a quand même toute une éducation à refaire.
Parce que d'une part, ça fait des années que Red hat contribue sur des tonnes de projets ( http://community.redhat.com/software/ ), ça fait des années que Red hat est dans le top des contributeurs kernels, et du système de base ( gcc, glibc, coreutils, etc ).
Donc si tout d'un coup, la personne s'en rends compte, c'est soit qu'il avait pas la moindre idée de comment c'était fait avant et donc, un manque d'éducation sur la chaine de production, un peu comme le fait qu'on ne sait pas d’où vient la bouffe ou nos chaussures. Ou le fait d'attribuer incorrectement l'origine uniquement au distributeur, auquel cas on peut se poser la question de l'impact de certaines distribs qui se positionnent comme "linux = nous" (je parle d'Ubuntu, pour être clair.. )
systemd est un choix stratégique pour, à priori, amener les
systèmes Linux vers une adoption plus importante dans le
contexte du desktop.
Le terme que tu cherches est peut être "intégration" plus que "adoption".
Ensuite, ouais, Gnome ne sa cache pas de vouloir s'intégrer dans la plateforme, et de s'appuyer sur les APIs existantes pour se focaliser sur les couches les plus hautes. La coopération entre projets libres, c'est aussi ça et Si KDE et GNOME délègue la gestion du suspend à un composant externe, ça fait toujours ça de moins comme code à dupliquer et à corriger 2 fois.
La liberté de bénéficier gratos du travail d'intégration des gens qui font le boulot bien sur. En fait, il a toujours la liberté, c'est juste que l'intégration lui plait pas, donc il doit la refaire. Et c'est plus gratos, faut investir de son temps.
Tu as le droit de te plaindre, mais ça veut pas dire que les gens vont pas te répondre. Le droit de râler s'applique aussi à tes propos, et si tu estimes ça chiant, fait preuve d'un peu d'empathie et dit toi qu'il y a des devs qui se prennent ça pour le moindre changement qu'ils font.
Et si tu te dit que ça n'apporte rien au débat, pose toi la question de savoir ce que redire ce qui a été dit 100 fois apporte aussi.
Alors je rajoute un bémol, il y a des nuances entre "ne fait rien du tout" et "mets tout son pognon dessus". Le desktop pour RH est entre les 2. Il y a un produit ( cf site web, chercher "RHEL Workstation" ), il y a des clients ( cf site web également, genre pixar ). Il y a des gens payés dessus ( cf les gens dont on trouve le nom dans les changelog et les gens payé sur gnome ).
Ensuite, ouais, y a pas besoin d'aller éplucher les rapports donnés à la SEC pour dire que c'est pas le produit qui ramène le plus de pognon ( et ça en ramène assez pour autofinancer l'équipe, d'après le chef de l'équipe Desktop chez eux que j'ai croisé au Guadec à Strasbourg ).
Donc ça pourrait trés bien être un truc sponso par RH et utile sur le desktop.
Le fait est que systemd offre des fonctions utiles pour le serveur:
- le fait de tuer de manière sure un service
- les limitations de ressources via cgroups
- la gestion des containers
- le fait de placer chaque service dans un environnement propre et répétable
- un système de HA rudimentaire (via la relance automatique, chose qu'on demande parfois à un opérateur humain de faire)
- l'activation par socket, ce qui permet de faire du "à la demande", et donc d'augmenter la densité des services par serveur
- l'isolation des services, pour une plus grande sécurité d'un service exposé sur le réseau (PrivatTmp, blacklist de syscall, etc )
C'est des fonctions qui répondent plus à des problématiques "serveur" que des problématiques 'desktop'.
Et il semble que ça requiert un patch non trivial sur le kernel ( des histoires avec openat et chmod entre temps ) et que les discussions pour faire ça dans la glibc n'ont pas aboutit à un patch. Et que les gens de musl semblent pousser aussi pour le support kernel.
Un autre exemple est :
"mkdir a; ln -s a b; rmdir b/"
Et il a donné que 2 exemples, mais je suis sur qu'on peut en trouver des tonnes.
Donc à partir du moment ou le monde Linux se fout globalement de la norme POSIX depuis des années, je trouve assez curieux les gens qui disent "il faut la respecter", et je crois que ton vœu est donc déjà réalisé
Je vois pas ou est marqué "du texte brut" dans ce qui est cité, c'est une interprétation de ta part sur ce que tu estime être clair. Techniquement, du xml serait aussi du texte brut, ça n'a rien de clair en pratique.
C'est marqué "des moyens de communication clair". Des appels RPC définis (exemple, l'API qu'un process doit implémenter pour un filesystem sur le hurd) sont des moyens clairs de communication ( sauf si tu penses que l'API posix, à base de grosso modo les mêmes primitves, n'est pas clair et donc ne respecte pas l'esprit UNIX.
On peut quand même voi comment une simple phrase sorti de son contexte et répété advitam eternam en guise d’épitome d'un ouvrage exposant l'état de l'art de la recherche d'il y a 40 ans dans un domaine bougant à toute vitesse est encore trop compliqué pour que les gens l'utilisent pour exprimer une idée clair.
Je commence à trouver ça curieux qu'un groupe fortement imprégné par l'esprit scientifique en revienne presque à des méthodes shamanique de vénération des textes "anciens" sans avoir le moindre recul vis à vis d'eux et de leur propre position.
Il est mal formulé, mais ce qu'il veut dire, c'est que pour lui, le bash est plus accessible que le C. Ensuite, autant je suis d'accord avec ça pour certaines personnes, autant je suis pas sur que ça soit généralisable d'une part, et si important d'autre part.
C'est pas généralisable car je pense que python serait plus accessible sur le principe que bash, et que du point de vue des nombres de devs, des choses comme javascript ou php serait sans doute plus important, ce qui veut pas dire que c'est une bonne idée. Sur la population ciblé des sysadmins, des choses comme perl ou ruby me semble aussi connu que bash (surtout ruby avec la montée de puppet/chef), et fournisse de meilleurs libs et un écosystème plus haut niveau. Mais quand tu connais que le bash, forcément, tu te dit que ç'est ce qu'il faut utiliser.
Et l'argument est aussi celui qui a été utilisé pour justifier que les softs de l'OLPC soient écrit en python et modifiable par les utilisateurs directement dans l'interface.
Et c'est pas si important d'autre parce que globalement, tout est écrit en autre chose que bash. Le libre n'a pas vraiment été bloqué par le fait que beaucoup de choses étaient en C avant, et j'aurais même tendance à dire que les sysadmins de l'époque des débuts d'unix savaient faire du C, vu le nombre de soft écrit en C à ce moment la par des admins ( typiquement, des trucs comme cron/atd, sendmail, et autres trucs historiques ).
Donc oui, y a des gens pour qui bash est naturel et ils voient ça comme une privation de la liberté de comprendre et d'étudier de la GPL. Mais c'est une privation lié à une limitation de leur savoir sur le moment plus qu'une limitation absolu, donc pour moi, l'argument ne suffit pas à justifier de ne pas changer.
Ce que je retiens, c'est surtout que si ce point de la philosophie unix était important, on tournerais plus sous qnx ou le hurd. Voir même sur darwin, si je me souviens bien.
Voir même celui de NT, qui est une espace de micro noyau aussi, sauf erreur de ma part.
Donc bon, c'est bien joli de citer des textes sacralisés sans les comprendre et sans savoir, mais ça fait quand même passé les gens pour des rigolos.
[^] # Re: Bon, tu l'as cherché mais on est vendredi
Posté par Misc (site web personnel) . En réponse au journal Debian Jessie, release prévue le 25 Avril avec deux nouvelles architectures. Évalué à 6.
J'ai en effet pas cherché, j'ai juste vu le mail de Florian.
J'utilise pas Debian pour docker et je pense que docker est pas sec, pour reprendre les termes consacrés, mais je regarde un peu les choses de loin, et de mon point de vue de packageur, je sais que c'est une plaie pour la securité sur le long terme, principalement à cause de go.
Donc il y a:
- besoin du compilo go, avec l'upstream qui pousse vers la derniére release du language ( donc ça implique de backporter aussi un compilo ). Que je sache, ça tourne pas encore avec gcc-go.
( ou plutot, ça tourne avec gcc 5.0 et quelques crashs )
sans doute besoin des dernières libs (pareil, backports). Peut être des snapshots git des dites libs.
et ça compile tout en statique, ce qui rends le tracking des soucis de sécu un chouia plus compliqué.
Et encore, docker est pas si problématique, car il suffit de voir kubernetes ou openshift origin ( qui embarque etcd et kubernetes ) pour se dire que ça va être assez vite relou quand un souci va arriver. Et il faut aussi rajouter les trucs comme flannel, les autres bouts de docker, etc, pour avoir un truc qui va servir à la prod.
[^] # Re: Bon, tu l'as cherché mais on est vendredi
Posté par Misc (site web personnel) . En réponse au journal Debian Jessie, release prévue le 25 Avril avec deux nouvelles architectures. Évalué à 7.
Y a mock, y a docker, y a lxc pour faire ça sur les distros RH like, et je suis globalement sur qu'il y a partout le même genre de trucs, ne serait ce que pour permettre une compilation propre. Un chroot en soit est sans doute une solution pour certains problèmes, mais pour lancer des serveurs, tu as souvent besoin de plus d'isolation ( parce qu'un chroot de base, ça bloque pas les signaux ni rien d'autres ), et parfois, tu as des soucis de communication userspace/kernelspace, etc etc.
Malgré ce qu'on croit, l'userspace est pas 100% indépendant du kernel http://www.fewbytes.com/docker-selinux-and-the-myth-of-kernel-indipendence/
Je rajouterais aussi que dire "on peut faire tourner des vieux trucs avec une ligne de commande", c'est aussi juste se voiler la face quant au manque de compatibilité abyssal des distributions linux d'une version à une autre, surtout quand on compare à des choses comme solaris ou netbsd.
Sauf quand tout d'un coup, apache change sa config et faut tout refaire. Ou que d'un coup, dovecot a dit "je change tout". Ou qu'on passe à systemd ( ce que perso, j'ai pas trouvé compliqué, mais comme tant de gens ont raler sur le sujet, je suppose que tout le monde partage pas cette avis ). Ou ce genre de détails qu'on a tendance à ranger dans la case "facile".
( attention, opinion non populaire devant )
Les gens ont aussi un manque de recul critique sur la question de la mise à jours de distribution. La principal raison de vouloir ça, c'est pour palier à la difficulté de mise en place de façon répétable d'un système. C'est souvent manuel et non documenté, et donc chiant.
En pratique, tu as plein de raison de réinstaller qui existe.
Ton serveur tombe en panne et prends feu ? Tu va devoir réinstaller.
Tu veux déplacer les machines sur un DC à 500 km ? Tu réinstalles le système à l'identique sur une nouvelle bécane et tu bouges l'ancienne sans avoir un downtime de 24 à 48h sur les services.
Tu veux un serveur de QA comme la prod ? Tu fait une installation à l'identique.
Et tu veux un upgrade ? Tu installes en changeant juste la distro de base, et tu corriges ce qui casses, sur autre chose que la prod.
Mais tout ça, ça implique d'automatiser l'installation et le déploiement, et la plupart des gens sont encore à faire les choses à la main, par manque de temps (ce qui est soit du bullshit, soit le signe d'un taf ou les gens sont toujours en mode pompier ce qui est un autre souci à régler du coté de la hiérarchie), par manque de compétence ou par ignorance.
Et donc, pour palier à ça, on se retrouve à celebrer la possibilité de faire des upgrades, au lieu d'oublier que c'est un contournement datant d'un temps ou l'automatisation était de la science fiction.
Bien sur, tout automatiser est relou. Faut commencer directement par ça ( sinon, tu te retrouves à oublier des choses, faut avoir du temps à faire le travail ( ce qui est parfois pas une mince affaire ), et soyons franc, tout les softs ne s'y prêtent pas.
Mais voila, ça reste couteux en ressources. Le DPL dit d'ailleurs dans une interview ( http://www.itwire.com/business-it-news/open-source/67512-surviving-systemd-lucas-nussbaum-satisfied-with-init-system-outcome ) :
Et je pense que "supporter un upgrade path presque parfait de stable à stable" rentre dans la catégorie des choses qui prennent du temps aux équipes cores, tout comme "supporter des tas d'archis", ou "avoir des milliers d'alternatives". On peut pas éviter la complexité, et je ne dit pas que ça n'apporte pas rien. Encore une fois, même si ça reste un workaround, ça corrige un souci pour une partie des utilisateurs.
La solution traditionnelle dans le logiciel libre, c'est de tenter de recruter plus de gens. Dire non, c'est super mal vu ( suffit de voir les réactions vis à vis de gnome ). Mais la solution traditionnel pour le reste du monde, c'est juste de faire moins.
Mais tu reçois encore des updates de sécurité dessus donc c'est pas un si gros souci ( mais je reconnais que c'est relou d'avoir des vieux trucs à gérer ). Et pour rebondir sur la solution d'utiliser un chroot, il se passe quoi si tu as un vieux bash ou un vieux openssl dans le chroot ( que tu va pas mettre à jour, si la distro est plus maintenu ) ?
[^] # Re: Bon, tu l'as cherché mais on est vendredi
Posté par Misc (site web personnel) . En réponse au journal Debian Jessie, release prévue le 25 Avril avec deux nouvelles architectures. Évalué à 10.
De ce que j'ai vu, y a de tout dans la nature. Debian est très présent mais aussi du Centos/RHEL, et je vois de temps en temps de l'opensuse. j'ai plus rarement vu du *bsd, mais il me parait aussi évident que je vais pas en croiser vu que je fait surtout du linux :)
Mais je pense que tu as d'autres raisons que "tu as pas le choix" pour prendre autre chose que Debian. Par exemple, j'ai eu des surprises chez un client ( genre, du matos acheté sans vérifier la compatibilité, et donc qui ne marchait pas sans devoir bidouillé et mettre le serveur à moité en testing ). À minima, les certifs hardwares évitent ça et même si dans mon cas, c'était 2 serveurs internes d'infra, ça aurait pu être 40 sur internet. Et autant, 2 à 3 ans de support sécu, c'est déjà bien, autant, je comprends que plus, c'est aussi pas mal ( dit-il en pensant au serveur VPN en RHEL 5 de son taf ).
Il y a aussi des différences technologiques parfois assez importantes. Si tu veux déployer un truc comme freeipa ( qui est de la bombe, ça déchire de déployer kerberos/ldap/etc via 1 commande ), ou les choses produites par des communautés ou RH est un gros ou le seul sponsor important comme openshift, kubernetes, les trucs autour de docker ( surtout que le dit docker a été viré de jessie ), Debian est pas forcément le choix le plus probant ( Ubuntu à la rigueur, mais ils poussent aussi pas mal leur stack en priorité, genre lxc, maas, juju ).
À contrario, si tu veux des trucs un peu exotiques ou spécifiques, Debian propose sans doute un paquet ( genre dans le monde scientifique, ou j'ai le sentiment qu'il y a une tonne de paquets, de part l'attachement des scientifiques à ses idéaux non commerciaux ).
[^] # Re: Oubli…
Posté par Misc (site web personnel) . En réponse au journal Ansible ton conteneur !. Évalué à 4.
Sauf que salt-ssh ne fait que du ssh.
Ansible propose ça :
https://github.com/ansible/ansible/tree/devel/lib/ansible/runner/connection_plugins
Par exemple, ansible tourne par dessus funcd, ou supporte d'entrer dans une zone, un lxc, ou un chroot.
Et j'ai un bout de code qui le fait marcher par dessus salt, modulo le dernier bug que je doit corriger ( je sais pas si c'est du coté de salt ou du coté d'ansible, mais la ligne de commande shell que ansible utilise coince avec salt )
[^] # Re: Oubli…
Posté par Misc (site web personnel) . En réponse au journal Ansible ton conteneur !. Évalué à 4.
Tu es pas obligé. Tu as comme dit "ansible-pull", ou tu peux utiliser mon role de bastion ( https://github.com/OSAS/ansible-role-ansible_bastion ), ou tu commites via git et ça déclenche la mise à jour sélective depuis une machine central ( et idéalement mieux sécurisé ).
J'ai tenté de travailler sur un setup avec ansible-pull , mais j'ai encore le souci de distribution des secrets ( ie, comment je m'assure qu'un serveur compromis n'a pas d'accés au mot de passe des autres serveurs,
J'utilise assez souvent le cache des facts pour avoir une vue globale de mon infra, et ça utilise le fait d'avoir un seul serveur pour ça. Mais je pense que le partage des données en cache devrait être reglé par : https://github.com/ansible/ansible/pull/9804 ), j'ai juste pas tenté.
[^] # Re: Oubli…
Posté par Misc (site web personnel) . En réponse au journal Ansible ton conteneur !. Évalué à 6.
Ça depend ou tu situes ton spectre.
Ansible est un moteur d'execution de modules via ssh. Tu décrit un tache ( 'installer un paquet via yum' ), et tu lances la tache sur X machines décrit dans un fichier d'inventaire. C'est le mode le plus simple.
Ensuite, tu as "décrire plusieurs taches, et les lancer sur une ou plusieurs machines", ce qui est un playbook. La, tu peut soit faire de la convergence de configuration ( ie, relancer le playbook qui indique comment ton serveur doit être installé, et miser sur le fait que les taches soient idempotentes pour que ça marche ), soit faire de l'orchestration ( genre je prends 3 serveurs, je les retire de nagios et du load balancer, j'upgrade, je reboote, je remets dans nagios, le load balancer, et je passe aux 3 suivants ).
Et comme ansible est flexible, tu peux faire plus que du ssh. Par exemple, considerer que "chroot /foo" est une connexion à un os différent. Ou dans le cas de l'article, que lxc ou docker le soit. Et donc, tu peut preparer une arborescence pour usage futur. Genre pour usage dans une image docker. Ou comme j'ai tenté de le faire, pour une image ostree.
[^] # Re: Pour résumé / Point d'étape
Posté par Misc (site web personnel) . En réponse au journal Google: je sais, je sais... mais tout de même, j'ai les boules !. Évalué à 10.
Moi, je crois que c'est un plan de Lennart Poettering pour diviser le monde des browsers libres afin d'imposer browserd pour unifier le monde du libre autour d'une seul implémentation.
La preuve la plus flagrante est qu'on ne trouve aucun lien avec systemd, ce qui prouve bien qu'ils ont un truc à cacher.
[^] # Re: Je confirme
Posté par Misc (site web personnel) . En réponse au journal Google: je sais, je sais... mais tout de même, j'ai les boules !. Évalué à 6.
C'est pas parce que c'est un bug que tu va réussir à le déclencher à coup sur. C'est un bug, par définition, c'est un comportement inattendu :)
[^] # Re: C'est le jeu ma pauvre lucette!
Posté par Misc (site web personnel) . En réponse au journal Google: je sais, je sais... mais tout de même, j'ai les boules !. Évalué à 7.
Sans doute ça :
http://www.wired.com/2013/08/20-percent-time-will-never-die/
ou ça :
http://www.businessinsider.com/mayer-google-20-time-does-not-exist-2015-1
De ce qu'on m'a dit que c'est assez dépendant des équipes et de leur manager, y en a ou il y a du temps, d'autre pas. Je connais quelqu'un qui a fait du volontariat pour un événement, et Google a versé de l'argent parce qu'il a fait du volontariat. Je connais quelqu'un qui a codé sur un outil que Google n'utilise pas (ou du moins, pas pour leur serveur) de façon assez conséquente, sur son temps de travail.
Vu la croissance de la boite, c'est pas non plus surprenant que ça soit moins uniforme qu'on l'imagine, et le coté magique de Google, c'est aussi de faire croire que c'est radicalement différent d'une autre grosse boite. C'est peut être le cas sur d'autres choses, mais il y a sans doute aussi des trucs tout à fait terre à terre ou des machins qui ont changés depuis pour diverses raisons ( ou des gens qui ont mal compris ).
[^] # Re: TCPA/Palladium
Posté par Misc (site web personnel) . En réponse au journal parait que ca manque de troll. Évalué à 10.
Azure a fait 1 milliard de chiffres d'affaire en 2013.
http://www.journaldunet.com/solutions/cloud-computing/chiffre-d-affaires-azure-en-2013.shtml
Ils ont lancé le service en 2010. Donc en ~3 ans, ils ont réalisé le même chiffre d'affaire que Red hat en plus de 15 ans.
Ou 5 fois plus qu'OVH en 2013, sur un segment similaire.
Pour donner une comparaison de la croissance, l'Appstore d'Apple a fait ça en 2 ans ( http://www.macworld.com/article/1157957/app_store_market_share.html , ouvrture en 2008, chiffre d'affaire en en 2009 de 800 millions ).
Donc bon, pour une boite moribonde, ils ont visiblement réussi à faire un peu d'affaire, face à la concurrence de Amazon et d'une tonne d'acteurs.
[^] # Re: TCPA/Palladium
Posté par Misc (site web personnel) . En réponse au journal parait que ca manque de troll. Évalué à 10.
Alors c'est pas mon genre de défendre microsoft, mais ils ont des centres de recherches qui produisent des tonnes de trucs.
Par exemple, Leslie Lamport bosse chez eux, il a quasiment inventé Paxos et divers variantes, et ça, c'est utilisé à fond par Google ( parmi tant d'autres ).
De ce que je sais, y a pas mal de projets juste en france avec l'inria, et l'innovation, c'est pas juste "refaire un os pour telephone en java", ou "refaire un navigateur web"….
[^] # Re: Certes
Posté par Misc (site web personnel) . En réponse au journal L'autohébergement, c'est pas gagné. Évalué à 5.
C'est pas un ou exclusif. Tu peux faire un procès et changer de FAI. Tout comme tu peux aller aux prud'hommes et changer de taf. Tu peux remplir un rapport de bug et changer de logiciel.
[^] # Re: Des usages à cerner
Posté par Misc (site web personnel) . En réponse au journal Docker, la plateforme à la mode. Évalué à 4.
Alors parmi les cas d'usage, c'est deja le fait d'avoir un truc self contained à déployer. IE, ce que tu testes est exactement ce que tu déploies.
Ça, c'est globalement la théorie, la pratique est plus compliqué car la platforme est pas correctement isolé :
http://www.fewbytes.com/docker-selinux-and-the-myth-of-kernel-indipendence/
Autre cas d'usage, tu as la création de microservice, avec les promesses de "ça scale à mort si c'est bien fait, et ça mutualise les ressources", mais surtout "les gens vont pas avoir besoin d'avancer à la même vitesse" ( ie, une solution à des soucis qu'on peut qualifier de social ).
Tu as aussi les histoires de mutualisation, cad diviser tes machines sans avoir la lourdeur des VMs ( lourdeur dans le sens ou il faut gérer les serveurs même virtuels ). J'ai prévu quand j'aurais du temps de jouer avec openshift v3, une surcouche sur kubernetes, qui est lui même un système d'orchestration de containers pour faire de l’hébergement des projets sur lequel je bosse. L'idée de faire des rollbaks rapidement est à mon sens utile pour que les gens puissent pousser sans risque, le fait de pouvoir tester chez toi sur docker est aussi pas mal pour ça.
Donc bon, je me voit pas déployer tout ( loin de la ), mais y a des trucs ou ça peut se révéler pas mal.
[^] # Re: TU
Posté par Misc (site web personnel) . En réponse à la dépêche systemd : l’init martyrisé, l’init bafoué, mais l’init libéré !. Évalué à 2.
Dans mon souvenir, l'usage de l'UTF8 dans tex/latex est toujours un peu tendu, mais j'imagine qu ça compte pas comme bug, mais comme évolution.
Des gens vont te dire que tex est pas facile à utiliser, mais vu le mépris qu'on a pour les gens qui veulent rendre les choses plus simples, j'imagine que ça ne compte pas comme bug non plus.
[^] # Re: Empire français
Posté par Misc (site web personnel) . En réponse au journal SUSE Linux se prépare à recruter 150 personnes !. Évalué à 2.
Les bureaux sont en région parisienne, à la défense ( tour Franklin, sauf erreur de ma part ), mais la boite est ouverte au télétravail (on peut citer Vincent Untz comme superstar bossant depuis Grenoble, par exemple, mais j'en connais d'autre).
[^] # Re: Pourquoi un composant aussi essentiel ne fait-il pas partie du noyau ?
Posté par Misc (site web personnel) . En réponse à la dépêche systemd : l’init martyrisé, l’init bafoué, mais l’init libéré !. Évalué à 3.
Ceci dit, il y a des travaux sur le fait d'avoir la pile tcp/ip en userspace, et avoir des interpréteurs directement lancé à la place du kernel (notamment sur des VM, voir le projet Mirage, erlang on xen, etc).
Donc la question de la séparation kernelspace/userspace est en effet remis en cause. Après tout, pendant longtemps, on a eu les drivers graphiques en dehors du kernel. ( et on a encore des drivers en dehors pour l'USB, par exemple, ou les imprimantes ).
[^] # Re: Z spotted
Posté par Misc (site web personnel) . En réponse à la dépêche systemd : l’init martyrisé, l’init bafoué, mais l’init libéré !. Évalué à 2.
ce qui prouve qu'il y a quand même toute une éducation à refaire.
Parce que d'une part, ça fait des années que Red hat contribue sur des tonnes de projets ( http://community.redhat.com/software/ ), ça fait des années que Red hat est dans le top des contributeurs kernels, et du système de base ( gcc, glibc, coreutils, etc ).
Donc si tout d'un coup, la personne s'en rends compte, c'est soit qu'il avait pas la moindre idée de comment c'était fait avant et donc, un manque d'éducation sur la chaine de production, un peu comme le fait qu'on ne sait pas d’où vient la bouffe ou nos chaussures. Ou le fait d'attribuer incorrectement l'origine uniquement au distributeur, auquel cas on peut se poser la question de l'impact de certaines distribs qui se positionnent comme "linux = nous" (je parle d'Ubuntu, pour être clair.. )
[^] # Re: Moins de liberté, pour plus de sécurité
Posté par Misc (site web personnel) . En réponse à la dépêche systemd : l’init martyrisé, l’init bafoué, mais l’init libéré !. Évalué à 7.
Le terme que tu cherches est peut être "intégration" plus que "adoption".
Ensuite, ouais, Gnome ne sa cache pas de vouloir s'intégrer dans la plateforme, et de s'appuyer sur les APIs existantes pour se focaliser sur les couches les plus hautes. La coopération entre projets libres, c'est aussi ça et Si KDE et GNOME délègue la gestion du suspend à un composant externe, ça fait toujours ça de moins comme code à dupliquer et à corriger 2 fois.
[^] # Re: Moins de liberté, pour plus de sécurité
Posté par Misc (site web personnel) . En réponse à la dépêche systemd : l’init martyrisé, l’init bafoué, mais l’init libéré !. Évalué à 4. Dernière modification le 28 février 2015 à 11:09.
La liberté de bénéficier gratos du travail d'intégration des gens qui font le boulot bien sur. En fait, il a toujours la liberté, c'est juste que l'intégration lui plait pas, donc il doit la refaire. Et c'est plus gratos, faut investir de son temps.
[^] # Re: Moins de liberté, pour plus de sécurité
Posté par Misc (site web personnel) . En réponse à la dépêche systemd : l’init martyrisé, l’init bafoué, mais l’init libéré !. Évalué à 3.
Tu as le droit de te plaindre, mais ça veut pas dire que les gens vont pas te répondre. Le droit de râler s'applique aussi à tes propos, et si tu estimes ça chiant, fait preuve d'un peu d'empathie et dit toi qu'il y a des devs qui se prennent ça pour le moindre changement qu'ils font.
Et si tu te dit que ça n'apporte rien au débat, pose toi la question de savoir ce que redire ce qui a été dit 100 fois apporte aussi.
[^] # Re: Cela confirme mon avis sur cette brique système: sympa sur les dekstop , incensée sur un serveur
Posté par Misc (site web personnel) . En réponse à la dépêche systemd : l’init martyrisé, l’init bafoué, mais l’init libéré !. Évalué à 7.
Alors je rajoute un bémol, il y a des nuances entre "ne fait rien du tout" et "mets tout son pognon dessus". Le desktop pour RH est entre les 2. Il y a un produit ( cf site web, chercher "RHEL Workstation" ), il y a des clients ( cf site web également, genre pixar ). Il y a des gens payés dessus ( cf les gens dont on trouve le nom dans les changelog et les gens payé sur gnome ).
Ensuite, ouais, y a pas besoin d'aller éplucher les rapports donnés à la SEC pour dire que c'est pas le produit qui ramène le plus de pognon ( et ça en ramène assez pour autofinancer l'équipe, d'après le chef de l'équipe Desktop chez eux que j'ai croisé au Guadec à Strasbourg ).
Donc ça pourrait trés bien être un truc sponso par RH et utile sur le desktop.
Le fait est que systemd offre des fonctions utiles pour le serveur:
- le fait de tuer de manière sure un service
- les limitations de ressources via cgroups
- la gestion des containers
- le fait de placer chaque service dans un environnement propre et répétable
- un système de HA rudimentaire (via la relance automatique, chose qu'on demande parfois à un opérateur humain de faire)
- l'activation par socket, ce qui permet de faire du "à la demande", et donc d'augmenter la densité des services par serveur
- l'isolation des services, pour une plus grande sécurité d'un service exposé sur le réseau (PrivatTmp, blacklist de syscall, etc )
C'est des fonctions qui répondent plus à des problématiques "serveur" que des problématiques 'desktop'.
[^] # Re: Quelqu'un devrait modifier l'API de linux pour autre chose que POSIX...
Posté par Misc (site web personnel) . En réponse à la dépêche systemd : l’init martyrisé, l’init bafoué, mais l’init libéré !. Évalué à 10.
Mais le fait est que de manière amusante, aucune distrib Linux moderne n'est certifié POSIX, et que le kernel ne le permet pas.
On a eu la discussion au travail, et les exemples cités sont assez obscures, mais montre bien le souci.
Par exemple, posix defini O_SEARCH
http://pubs.opengroup.org/onlinepubs/9699919799/functions/open.html
Et il semble que ça requiert un patch non trivial sur le kernel ( des histoires avec openat et chmod entre temps ) et que les discussions pour faire ça dans la glibc n'ont pas aboutit à un patch. Et que les gens de musl semblent pousser aussi pour le support kernel.
Un autre exemple est :
"mkdir a; ln -s a b; rmdir b/"
Sur linux, ça fait un message d'erreur.
D'après la norme POSIX, le / indique de s'appliquer à la cible du symlink :
http://cygwin.com/ml/cygwin/2005-04/msg00566.html
https://unix.stackexchange.com/questions/29769/trailing-slashes-on-symbolic-links-to-directories
Et sur OS X, qui est certifié Posix, ça passe.
Et il a donné que 2 exemples, mais je suis sur qu'on peut en trouver des tonnes.
Donc à partir du moment ou le monde Linux se fout globalement de la norme POSIX depuis des années, je trouve assez curieux les gens qui disent "il faut la respecter", et je crois que ton vœu est donc déjà réalisé
[^] # Re: Le bon chasseur et le mauvais chasseur
Posté par Misc (site web personnel) . En réponse à la dépêche systemd : l’init martyrisé, l’init bafoué, mais l’init libéré !. Évalué à 5.
Je vois pas ou est marqué "du texte brut" dans ce qui est cité, c'est une interprétation de ta part sur ce que tu estime être clair. Techniquement, du xml serait aussi du texte brut, ça n'a rien de clair en pratique.
C'est marqué "des moyens de communication clair". Des appels RPC définis (exemple, l'API qu'un process doit implémenter pour un filesystem sur le hurd) sont des moyens clairs de communication ( sauf si tu penses que l'API posix, à base de grosso modo les mêmes primitves, n'est pas clair et donc ne respecte pas l'esprit UNIX.
On peut quand même voi comment une simple phrase sorti de son contexte et répété advitam eternam en guise d’épitome d'un ouvrage exposant l'état de l'art de la recherche d'il y a 40 ans dans un domaine bougant à toute vitesse est encore trop compliqué pour que les gens l'utilisent pour exprimer une idée clair.
Je commence à trouver ça curieux qu'un groupe fortement imprégné par l'esprit scientifique en revienne presque à des méthodes shamanique de vénération des textes "anciens" sans avoir le moindre recul vis à vis d'eux et de leur propre position.
[^] # Re: Moins de liberté, pour plus de sécurité
Posté par Misc (site web personnel) . En réponse à la dépêche systemd : l’init martyrisé, l’init bafoué, mais l’init libéré !. Évalué à 10.
Il est mal formulé, mais ce qu'il veut dire, c'est que pour lui, le bash est plus accessible que le C. Ensuite, autant je suis d'accord avec ça pour certaines personnes, autant je suis pas sur que ça soit généralisable d'une part, et si important d'autre part.
C'est pas généralisable car je pense que python serait plus accessible sur le principe que bash, et que du point de vue des nombres de devs, des choses comme javascript ou php serait sans doute plus important, ce qui veut pas dire que c'est une bonne idée. Sur la population ciblé des sysadmins, des choses comme perl ou ruby me semble aussi connu que bash (surtout ruby avec la montée de puppet/chef), et fournisse de meilleurs libs et un écosystème plus haut niveau. Mais quand tu connais que le bash, forcément, tu te dit que ç'est ce qu'il faut utiliser.
Et l'argument est aussi celui qui a été utilisé pour justifier que les softs de l'OLPC soient écrit en python et modifiable par les utilisateurs directement dans l'interface.
Et c'est pas si important d'autre parce que globalement, tout est écrit en autre chose que bash. Le libre n'a pas vraiment été bloqué par le fait que beaucoup de choses étaient en C avant, et j'aurais même tendance à dire que les sysadmins de l'époque des débuts d'unix savaient faire du C, vu le nombre de soft écrit en C à ce moment la par des admins ( typiquement, des trucs comme cron/atd, sendmail, et autres trucs historiques ).
Donc oui, y a des gens pour qui bash est naturel et ils voient ça comme une privation de la liberté de comprendre et d'étudier de la GPL. Mais c'est une privation lié à une limitation de leur savoir sur le moment plus qu'une limitation absolu, donc pour moi, l'argument ne suffit pas à justifier de ne pas changer.
[^] # Re: Le bon chasseur et le mauvais chasseur
Posté par Misc (site web personnel) . En réponse à la dépêche systemd : l’init martyrisé, l’init bafoué, mais l’init libéré !. Évalué à 5. Dernière modification le 26 février 2015 à 10:58.
Ce que je retiens, c'est surtout que si ce point de la philosophie unix était important, on tournerais plus sous qnx ou le hurd. Voir même sur darwin, si je me souviens bien.
Voir même celui de NT, qui est une espace de micro noyau aussi, sauf erreur de ma part.
Donc bon, c'est bien joli de citer des textes sacralisés sans les comprendre et sans savoir, mais ça fait quand même passé les gens pour des rigolos.