Misc a écrit 6254 commentaires

Il y a surement des divas mais il y a aussi des gens qui savent > mieux faire du design que les développeurs. Et vu la gueule de
quasiment la totalité des applis libres c'est assez flagrant.

Le simple fait que l'interface utilisateur soit une branche à part avec des spécialistes (voir des boites dédiés, des livres, des confs, etc) montre qu'il y a en effet sans doute des gens qui passent plus de temps sur ça que des développeurs (qu'on continue de croire comme étant l'alpha et l'omega du libre)

La question ne se pose pas pour la traduction, la documentation, l'admin système ou le marketing (entre autres). Donc je ne vois pas pourquoi ça serait différent pour le design d'interface utilisateur.

Et je pige pas non plus pourquoi on accepte parfaitement de recevoir des bugs reports pour dire "tel truc marche pas", pourquoi c'est parfaitement normal de dire "faut refaire tel lib en rust/go", mais quelqu'un qui tente de changer un truc dans le design, c'est la catastrophe.

Alors je sais pas comment ça marche pour Docker que tu cites
aussi, mais j'imagine bien qu'y a pas de mise-à-jour automatique
(surtout parce que c'est fait pour les serveurs et on veut pas
voir des trucs genre maj auto en prod!).

En fait, si tu regardes dans tout les systémes de CD, c'est un peu justement ce qui se passe. Tu pousses ton code, il passe les tests, et paf, il est déployé.

L'industrie va de plus en plus vers le fait de déployer juste en automatique. Certes, tu as des risques mais j'ai l'impression que le modèle inverse (ie, pas de mise à jour) cause plus de soucis mais de manière moins visible (ie, le cout des piles technologiques qui lagguent, le non déploiement de systèmes plus sur et plus efficaces, etc). Peut être que c'est juste aussi parce qu'il est plus répandu.

Oui, mais deltarpm a eu pendant longtemps un cout non négligeable coté serveur. Je suis pas sur que maintenant que les serveurs sont suffisament rapide pour les petits paquets, ça passe aussi bien pour les gros paquets, et qu'on se retrouve pas avec le même souci qu'avant.

Ni celui de la vérification des licences et autre trucs qu'on oublie un peu facilement jusqu'à ce qu'un SCO 2 sorte du bois et qu'on se dise "oups".

Il y a aussi de la valeur ajouté des distributions à faire un peu de vérification de sécurité (en général, je fait une passe rapide sur les paquets quand je fait une revue Fedora, histoire de pas trouver trop d'horreur).

Mais bon, tout ça, ça requiert de faire du travail, pas de reprendre les trucs upstream. Et c'est pas rpm qui rends ce travail plus complexe, ni docker/flatpack qui va le rendre plus rapide.

Alors, ayant fait une partie du portage:

• tout le code est compatible python3 à la compilation

• les modules les plus classiques sont fonctionnels. J'ai réussi à installer Openshift (95 roles via openshift-ansible) avec python 3 de bout en bout en octobre 2016.

• la liste des bugs sur python 3: https://github.com/ansible/ansible/issues?q=is%3Aopen+is%3Aissue+label%3Apython3

• la TODO list: https://github.com/ansible/ansible/projects/1

Dans la mesure ou tester la version git et tester python 3 sont assez simple ( git clone ; cd ansible ; source hacking/env-setup )
et -e ansible_python_interpreter=/usr/bin/python3, j'invite les gens à tester et à remplir des rapports de bugs. J'ai vraiment testé tout les modules des playbooks que j'utilise, j'ai mếme été jusqu'à installer un openbsd et un freebsd pour trouver des bugs potentielles avec python3.

Mais pour moi, ça marche sans souci dans la version git.

Ou ara: https://github.com/openstack/ara

Screenshot:

https://dmsimard.com/2016/11/09/visualizing-kolla-ansible-playbooks-with-ara/

Ou via the foreman:
https://theforeman.org/plugins/foreman_ansible/0.x/index.html

Ansible rends ce phénomène plus fréquent et visible, car le
mécanisme de notifications (via les handlers) est très
spécialisé et pas utilisable en toutes circonstances (par
opposition au notify/subscribe de puppet, qui permet de
coordonner n'importes quelles actions).

Pour compléter ça, il y a aussi le système de listener maintenant:
https://github.com/ansible/proposals/issues/11

J'ai pas encore utilisé, mais ça rajoute un peu de souplesse dans la gestion des handlers.

Ansible est leeeeeeeeent à coté de Puppet…

bah, y a pas de secret, ansible fait les opérations une par une, puppet envoie tout sur l'agent pour qu'il fasse 1) juste ce qu'il faut 2) en même temps. Puppet (et les autres) seront sans doute toujours plus rapide qu'Ansible.

Ensuite, James Shubin, estimé collègue et auteur de mgmt (https://github.com/purpleidea/mgmt) n’arrête pas de présenter l'outil (mgmt) partout en expliquant comment il arrive à faire un truc qui converge plus vite que Puppet et sans les soucis de Puppet (notament de version), et comment ça va révolutionner les choses. Y a des vidéos de lui sur youtube, et il va être présent au FOSDEM à Bruxelles, au config mgmt camp à Gent, et à Devconf à Brno. Son design a l'air en effet correct, et je sais qu'il a passé beaucoup de temps dessus pour avoir un bon truc.

Un "--check" sous Ansible (qui est l'équivalent) va quand même
faire certains trucs pour de vrai (notamment les installs de
packages - hé oui ! surprise ! )

Si c'est le cas, c'est un bug. Le code du module yum n'est pas censé le faire, par exemple, pkgin non plus, apt, etc, etc.

Si tu as un cas précis, je peux essayer de regarder.

Alors, c'est pas parce que par défaut, c'est agentless que tu dois t'y tenir.

Par exemple, tu peux mettre func ou salt qui ont des plugins de connexion ansible ( https://github.com/OSAS/ansible-role-salt_transport ), ( https://github.com/ansible/ansible/blob/devel/lib/ansible/plugins/connection/funcd.py ) à la place de ssh.

Tu peux aussi utiliser le mode pull, ou tu as un cron qui va faire un git pull et execution local via ansible -c local.

Tu peux vérifier que la config de ssh est bonne avant de relancer, par exemple.

Et bon, si tu vautres le réseau ou le firewall (genre paf, tu mets OUTPUT en DROP au lieu d'ACCEPT), en fonction de comment tu te vautres, Puppet ne va pas te sauver même si il a un agent, le risque n'est pas non plus nul.

Sauf erreur de ma part, certains serveurs ntp (chrony par exemple) sont capable de stocker la date/heure sur le disque pour la reprendre quand ça redémarre. Ce qui fait que sauf si tu éteint la raspberry pi pendant longtemps (ie plus que quelques minutes), ça contourne le fait de ne pas avoir de RTC.

Une autre solution, c'est de mettre un GPS dessus:
http://www.satsignal.eu/ntp/Raspberry-Pi-NTP.html

Ou d'acheter une add on pour la raspberry pi. J'ai une cryptocape pour beaglebone (plus pour le TPM que pour le RTC), et y a la puce dont tu parles plus loin dessus: https://cryptotronix.com/products/cryptocape/

(mais intégré pour les boulets qui savent pas faire d’électronique comme moi)

Une liste (AMHA) plus complète se trouve aussi ici: https://diyisp.org/dokuwiki/doku.php?id=technical:dnsresolver

Tor permet de faire passer le DNS à travers le réseau.

Il suffit d'ajouter par exemple dans le fichier torrc:

DNSPort 127.0.0.125:53

Et de mettre 127.0.0.125 dans la config. J'ai rajouté par dessus ça systemd-resolvd pour faire de la verif dnssec, mais je suis pas sur que ça soit déployer en pratique à beaucoup d'endroit.

AppArmor marche sur xen, mais il est possible que ça ne marche pas sur xen de la façon dont c'est mis en place chez OVH. AppArmor a besoin d'un support kernel, donc prendre un VPS me parait prendre des risques par rapport à une machine physique à ce niveau la (vu qu'on sans doute pas trop toucher au kernel).

Et J'avais souvenir que les VPS d'OVH était des chroots openvz, mais ça a du changer visiblement.

Mais sinon, oui, l'histoire ne fait que rappeler la base des hébergeurs à bas prix, à savoir les humains du support coute de l'argent. Si le tarif est de 3€ par mois, ça fait 36€ par an, ou 360€ sur 10 ans. Une panne qui requiert d'appeler le support tout les 10 ans va bouffer la majorité du bénéfice fait sur les 360€ (car tu dois retirer de tout ça le prix du serveur à amortir, le réseau, l’électricité, la place dans le DC).

J'ai pas trop d'idée des prix de 2017, mais si je regarde les tarifs 2015 que j'ai dans ma boite mail:
un dell Poweredge R630, avec 128G de ram, 3.2T en SSD, 2 xeon E5-2690 à 2.6Ghz, ça a couté (aprés remise) ~14 000$.

On va doubler la ram pour aujourd'hui, et supposer que le cpu et le disque sont suffisant. Si tu files 2G à tout les clients dessus, tu peux en mettre 128 par serveur. Comme tu sais que tout le monde utilise pas tout, on va monter à 200 utilisateurs par machine. Chaque utilisateur doit te rapporter 70$ pour que ça soit rentable. Si on fait une grosse conversion à la louche 1$ = 1€ (parce que c'est mes calculs, les gens sont libres de faire du plus précis en réponse), ton serveur sera payé au bout de 2 ans… si l’électricité est gratuite (ce qui est pas le cas), si la place dans le DC est gratuit (ce qui est pas le cas), si l'accès internet est gratuit (ce qui est pas le cas), et que personne n'appelle le support (ce qui est pas le cas).

Si chacun a une panne en 2 ans, et que le support passe 30 minutes dessus, ça nous fait 100h de travail. Soit 3 semaines, on va rajouter par dessus la formation, les congés, les meetings etc, et on arrive à une personne à temps plein du support par serveur si il y a une panne tout les 2 ans. Donc tu va payer quelqu'un pendant 1 mois. Je laisse les gens pinaillé sur le tarif du support sur 1 mois, je vais dire 3000€ en cout pour la boite au pif (cotisations sociales comprise), ça fait une surcharge de 15€ par client.

IE, à peu prés 5 mois d'utilisation sont la juste pour traiter un incident d'une demi heure.

Donc ouais, le moyen d'être aussi bas, c'est
1) réduire le nombre d'incident via l'automatisation
2) réduire le temps passé sur chaque ticket
3) payer moins le support

si le support est pourri, c'est sans doute les conséquences de 2 et 3.

Ce qui permettrais aussi de les faire tourner avec un user différent et des privilèges non partagés. Et ce qui est le fonctionnement de tout faut mod_php, sauf erreur de ma part.

Ce qui permet aussi d'isoler les crashs à une application, etc, etc.

Et de séparer l'espace mémoire du truc avec la clé ssl de l'espace mémoire du truc avec du code complexe qui tourne.

Ça a le même intérêt que pour toute application : installation
facile et standardisée, mises à jour de sécurité gérées par la
distribution. L'intérêt est même supérieur à la moyenne vu que
les applications web sont particulièrement affectées par les
problèmes de sécurité.

Tu peux préciser "gestion des dépendances" (car mine de rien, ça commence à tirer des paquets de partout), et "installation saine". Par installation saine, je veux dire "sans que le serveur web puisse modifier son propre code car il a le droit d'écrire sur son dossier", par exemple.

Le fait aussi de placer ça au bonne endroit permet de s'assurer que selinux donne les bons labels (même si je reconnait qu'on est loin de ce qu'on pourrait faire à ce niveau la).

Et tu as aussi le fait de pouvoir vérifier ce qui est installé (rpm -Va, debsums).

Et la vérification que la licence est correct aussi.

Oui, il y a eu un système de vote, mais les systèmes de votes
sur ce genre de décisions restent problématique, et, ça met de
côté beaucoup d'utilisateurs finaux.

Ok, je vais mordre (j'ai largement répondu sur systemd depuis 4 ans, donc on va changer ).

1) en quoi c'est problématique ?

2 a) en quoi les utilisateurs finaux sont mis de coté

2 b) en quoi c'est un souci de manière pratique ?

D'après https://devuan.org/os/team/, il y a Roger Leigh, le mainteneur de sysvinit.

Je pense qu'à un moment, j'ai vu passer aussi Thorsten Glaser (qui était contre systemd, cf https://www.mirbsd.org/permalinks/wlog-10-tg_e20141119-tg.htm#e20141119-tg_wlog-10-tg )

Sinon, les autres noms ne me disent rien.

Ceci dit, au risque d'alimenter les complotistes, l’état de l'art, c'est des choses comme ça:

http://sharps.org/wp-content/uploads/BECKER-CHES.pdf

"Stealthy dopant-level hardware trojans"

Avec la réponse 2 ans plus tard:

http://eprint.iacr.org/2014/508.pdf

"Reversing Stealthy Dopant-Level Circuits"

Autre papier intéressant dans la même veine:

"Threshold-Dependent Camouflaged Cells to Secure
Circuits Against Reverse Engineering Attacks"

http://arxiv.org/pdf/1605.00684

Je propose d'adopter le même système que l’élection du doge de Venise.

Pour info: https://fr.wikipedia.org/wiki/Doge_de_Venise#.C3.89lection

Regarde les arcanes de sysvinit ou le rc de NetBSD (je ne sais
pas les différences qu'il y a sur les autres BSD), c'est pas
vraiment pas incroyable. Cette simplicité est même certaine
fierté face à la sophistication d'upstart/systemd. On a tourné
des dizaines d'années avec ces choses relativement triviales.

Alors au risque de paraitre vaniteux, je vais citer un commentaire que j'ai déjà écrit sur le sujet en 2014:

https://linuxfr.org/nodes/101472/comments/1527828

Y a rien de simple dans les initscripts de sysvinit en pratique, en tout cas, sur ceux qui font plus que lancer un démon sur Debian. Les scripts que je vois sur les divers BSD sont en effet mieux que ce qu'on trouve sur sysvinit, tout comme les initscripts de Gentoo. Mais c'est aussi ceux fourni avec le système, j'ai jamais pris le temps de regarder ceux qui viennent des ports.

Et du coup, je vais aussi reciter un autre commentaire sur le sujet (encore de moi, quitte à être vaniteux):

https://linuxfr.org/nodes/101472/comments/1527896

(et on a testé, ça marche sur OpenBSD, mais pas trop sur les autres OS, vu qu'on peux renommer les process la bas, ie, faut un truc spécial dans le kernel pour faire marcher ça, et encore, je pense que y a toujours moyen de faire des trucs amusants en compilant son binaire "sshd" qui fait qu'un sleep).

1. Le modèle pipeline sur lequel est basé systemd me laisse perplexe et je lui préfère, par expérience, le modèle par événements

Je suppose que tu veux dire "le modèle de dépendance" plus que le modèle en pipeline.

C'est un modèle par événement en interne tout comme upstart.

Mais à la différence d'upstart, c'est pas remonté au niveau de la configuration qui en effet ne permet que d'exprimer de "j'ai besoin de ça et ça", et systemd gére en interne sa sauce.

Parce que quand c'est pas le cas, tu as des soucis. Exemple avec upstart qui fait les choses via des réactions à des événements, tu remontes tout les soucis du modèle sur l'utilisateur/intégrateur, ce qui aboutit à ça:

https://bugs.launchpad.net/upstart/+bug/447654

Le bug est marqué corrigé, mais parce qu'il y a plus un workaround qu'un correctif, car utiliser "et" pose toujours souci à upstart:
https://bugs.launchpad.net/upstart/+bug/447654/comments/6

En utilisant des dépendances simple "en pipeline", systemd évite le souci.

Et des soucis liés au coté asynchrone des événements, y en a d'autres dans le bug tracker.

Par exemple:
https://bugs.launchpad.net/upstart/+bug/516713 , https://bugs.launchpad.net/upstart/+bug/539175

C'est connu depuis longtemps qu'il y a des races conditions à ce genre d'architecture (exemple, les signaux unix https://lwn.net/Articles/414618/ ). Donc mettre ça entre les mains des utilisateurs qui sont moins au courant de tout ce qui peut arriver de mal, c'est chercher les emmerdes.

Mais je lui préfère le bon vieux schéma Unix dans lequel
chaque outil ne fait qu'une et une unique chose et le fait
bien et jusqu'au bout et c'est par assemblage de ceux-ci que
sont accomplis des tâches plus complexes (ha et aussi dans
lequel tout est texte).

Tout n'est pas texte, loin de la. C'est un fantasme. Les ioctls, c'est pas du texte par exemple, alors que ça pourrait.

Les outils ne font pas non plus qu'une chose. sort peut remplacer uniq, par exemple. ls peut faire du tri sans passer par sort. tr peut être remplacer par sed. more existe encore, faisant moins que less. zcat intégre gzip dans cat, ce qui fait du coup 2 choses.

Y a plein de cas comme ça ou on voit que les outils en ligne de commandes ont été plus le résultat du hasard qu'un design précis.

Et les scripts d'init n'utilisent pas vraiment les primitives de passages de flux d'unix, c'est juste des enchainements de commande bash (dont un paquet sont pas des binaires séparés, donc on repassera pour "faire une chose et le faire bien", vu que ça fait pas une chose, et ça le fait pas bien dans la mesure ou y a 2 façon différentes de faire les tests, etc, etc)

Et une préférence n'est pas vraiment un argument technique en tant que tel. Ça serait comme dire "je préfère que ça soit écrit en majuscule".

le dernier point est peut-être le plus important pour moi :
je me sens imposé systemd. En fait, au lieu d'avoir un systemd
qui évolue dans son coin chez RedHat et petit à petit s'impose
pour ses qualités fonctionnelles et techniques, son adoption a
été rapide sans aucune commune mesure alors même que celui-ci
n'était pas encore abouti.

Je me gausse. Systemd a mis 4 ans à arriver, Fedora a mis 2 release à faire le changement, Debian aussi et propose , Ubuntu l'a pris y a 6 mois.

Je sais pas dans quel référentiel temporel tu vis, mais un projet qui mets 6 ans à être adopté, ç'est pas ce que j'appelle "rapidement". Pour te remettre dans le contexte, en 2010, KDE était encore en version 4, le kernel était encore 2.6, gcc 4.5 était sorti. Goalgn avait été annoncé 1 an avant. Docker n’était pas la, Openstack venait juste d'être crée, Nicolas Sarkozy était président, Steve Jobs était encore en vie, tout comme Dennis Richie.

Quand à dire "non abouti", c'est du logiciel libre. Le travail est jamais fini. Et pour un truc non abouti, il n'a pas vraiment causé de dégâts à grande échelle. On nous avez promis des départs massifs d'utilisateurs de Debian, j'ai pas vu ça.
On avait promis le départ des developpeurs pour des plateformes autre que Linux, et des migrations à BSD, et j'ai pas vu ça. Il suffit de voir les stats:
https://www.openhub.net/p/netbsd
https://www.openhub.net/p/freebsd
https://www.openhub.net/p/openbsd

NetBSD perds un peu, OpenBSD gagne un peu, FreeBSD reste stable.

Ou juste voir que Devuan galére à sortir sa version stable alors que tout le travail est fait par Debian.

Quand à se sentir imposé, bienvenue dans le monde réel. À partir du moment ou tu es en bout de la chaine de production, c'est un cadeau que tu reçoit, tu as juste le choix de ne pas le prendre. Personne n'a d'obligation de te filer autre chose, et visiblement, le consensus va plus vers l'usage de systemd que vers le fait d'aider Devuan a sortir une version sans systemd.

Pas vraiment. En relisant les listes internes de RH ou le sujet a été discuté par le passé, Lennart a dit qu'il a eu au moins 2 appels sur son répondeur pour l'insulter (en septembre 2014, et il a donné un lien vers l'enregistrement), au moins une personne venu pour le menacer de mort sur #systemd le lendemain, un appel à donner des bitcoins pour embaucher un tueur à gage (sur github, retiré rapidement par github).

Et il y a toujours les videos creepy d'un troll bien connu sur Youtube (https://www.youtube.com/watch?v=2toVPMHRo8M&feature=youtu.be ), qui n'ont pas été retiré par Google.

Si quelqu'un veut pas regarder, la video commence par la conf au 27C3 de Wolfgang Draxinger, sur "27c3 - Desktop on the Linux… (and BSD, of course)",) en insultant bien sur Lennart, et en disant qu'il arrête pas d'interrompre Wolfgang et c'est mal. Pour avoir été à la conf ce jour la, je confirme que Wolfgang a bien dit n'importe quoi, et il été d'accord pour être interrompu). Ensuite, il parle de comment systemd est forcé sur les gens, comment tout doit être fait à sa façon, le tout mixé avec des petits cris et des petits passages creepys, comme à 8 minutes 10:
"system v, the previous system, called sysv, kinda make sense, sys, a girl, does what you tell it to do. Or you can get in there and force it too."

Ou le passage ou il parle de la femme de Linus Torvalds et celle de Bill Gates (vers 10"). Et ensuite il parle aussi de comment il a jamais entendu Lennart dire qu'il aime les filles, mais qu'il bosse qu'avec des hommes vers la minute 11, etc.

Bien sur, c'est infiniment moins que ce que d'autres ont reçus (l'exemple le plus connu étant Anita Sarkisian, qui a eu l'audace de critiquer des jeux vidéos sur youtube, ce qui a déclenché l'ire de certains gamers), mais je pense qu'il faut remettre ça à l'échelle du libre et des personnes qui savent ce qu'est un systéme d'init.

En fait, je pense que la raison de pas avoir de menace sur twitter, c'est plus qu'il a pas l'air d'avoir un compte twitter.

Alors je me suis dit "ok, prendre le premier message, c'est pas terrible". Du coup, j'ai cherché un truc plus pointu, et je suis tombé sur ce thread:
https://lists.dyne.org/lurker/message/20161106.161554.447dc0eb.en.html

Alors bien sur, faut pas aller loin pour trouver des insultes:
https://lists.dyne.org/lurker/message/20161106.203151.c86d18ea.en.html

Mais regardons la technique:

Donc premier mail avec des trucs intéressants:

https://lists.dyne.org/lurker/message/20161106.174507.45553586.en.html

Donc "le comportement fait sens, mais juste pour des trucs dynamiques, donc faudrait pas le faire sur le PCI". Alors, bien sur, personne ne vient dire "le PCI est hot pluggable". C'est juste supporté depuis facile 8 ans. So much pour "Veteran Unix Admins".

Ensuite, bien sur, quelqu'un dit "non mais y a une autre solution":

https://lists.dyne.org/lurker/message/20161108.160010.7d942413.en.html

Solution qui consiste à attendre que tout les périphériques soient détecté (ce qui globalement reviens à mettre une limite arbitraire de temps à la détection, donc à ralentir le boot sans doute pour rien), puis à charger les modules 1 par 1. Et c'est pas grave si y a un module qui mets 10 secondes à s'initialiser. C'est pas grave si justement, y a aucune garantie de l'ordre de chargement parce que les divers bus répondent pas toujours dans l'ordre.

Et puis, c'est pas grave si le système (tel qu'il est implementé) compte sur le fait que le wrapper ne se plante jamais, vu qu'il est celui qui donne le signal au suivant de se charger.

Bref, ça, c'est un exemple de la technique sur la liste devuan. Des gens avec en général assez de compétences pour mal régler le problème qu'ils ont avec une solution qui marche mais qui ne leur plait pas.

Et bon, si on regarde d'autres trucs, on voit que globalement, l'esprit "conservateur" commence même à décourager les bonnes volontés:

https://lists.dyne.org/lurker/message/20161115.074322.4509d655.en.html

https://lists.dyne.org/lurker/message/20161123.110634.fa6f2f28.en.html

Je pense qu'avoir un système maintenu (ce qui est globalement pas le cas des autres en règle général, que ça soit upstart ou sysv) est une bonne raison.

Ensuite, si tu as fait des recherches et tout ce que tu as trouvé, c'est "ça m'apporte rien", tu sembles oublier que le choix d'un pile logiciel, c'est avant tout le choix des mainteneurs par rapport au travail que ça leur prends et ce que ça apporte. Et visiblement, les mainteneurs des divers distributions ont choisi dans leur grande majorité.

Je ne sais pas ce que tu utilises comme distro, mais sur RHEL, il y a un repertoire /usr/libexec/initscripts/legacy-actions qui sert exactement à ça.

Du coup, tu peux juste faire "service foo truc", comme avant.