Le foutage de gueule c'est de venir parler de risque zéro quand son infra est toute trouée.
Venir agresser des bénévoles par le biais de LinuxFr, c'est pas terrible comme comportement. L'infrastructure de Mageia a le bon gout d'être ouverte depuis le début, et quand j’étais un des admins la bas, j'ai reçu epsilon patchs de la communauté. Soit, faire l'administration système, c'est compliqué et c'était pas vraiment une des compétences des utilisateurs dans la communauté. J'ai bien conscience que puppet (l'outil choisi à l'époque) est un outil non trivial pour le péquin moyen (voir même les concepts modernes de gestion de serveurs). Et si je devais le refaire maintenant, je referais ça autrement (et je le refait autrement justement).
Mais c'est pas le propos. Le propos, c'est que sans aide et sous la charge de travail (bénévole), j'ai quitté le projet pour éviter le burnout. Burnout qui a failli me couter mon taf à mi-temps et qui m'a couté la relation avec ma copine de l'époque. Je suis pas non plus le seul, car d'autres admins ont lachés l'équipe pour divers raisons (parfois de santé, parfois autres). Mais curieusement, y a pas grand monde qui est venu remplacer les départs depuis la communauté.
Donc arriver en donneur de leçon la bouche en cœur, c'est totalement contre productif et passablement odieux vu que ça va juste dégouter les gens de filer du travail gratuitement à des gens dont la gratitude semble inexistante.
Si quelqu'un estime pouvoir donner son avis sur le taf à faire par des bénévoles, y a plusieurs solutions. Soit la personne a les compétences et je m'attends à minimum de voir un patch arriver. Soit la personne n'a pas les compétences, et je m'attends à ce que les gens aient la décence de ne pas se comporter de façon hautaine à expliquer à ceux qui font le travail comment le faire en étant insultant.
Ou si la personne n'a pas le temps, je m'attends aussi à ce que les gens comprennent que le temps des autres aussi n'est pas infini.
Je ne veux pas minimiser les soucis d'attaques sur les infras, ça arrive en moyenne une fois tout les 3 mois d’après mes recherches (moyenne fait sur les 10 dernières années). Mais ce genre de soucis, c'est aussi arrivé à beaucoup de projets et pas des moindres :
J'ai une liste de 50 compromissions, je peux continuer toute la nuit.
Tantôt c'est du vol de compte. Tantôt c'est du bruteforce de login ssh. Parfois, on sait pas car personne n'a fait de forensic (parce que oui, la sécurité, c'est un métier, c'est pas juste aller crier sur les gens sur un site web, au cas ou les gens auraient des doutes).
Parfois les détails sont pas publiques, et j'ai eu beaucoup de mal à retrouver des infos. J'ai pas encore pu tomber sur des 0days de folies ou des exploits complexes, et pourtant j'ai fait le tour des confs pour parler aux gens impliqués dans certains cas, je me suis tapé facile 30 à 40 rapports sur les différentes attaques pour comprendre (https://github.com/aptnotes/data ).
Mais la cause à la base, c'est souvent toujours pareil. C'est des systèmes oubliés, mal sécurisés et souvent un manque d'admin sur des projets, parfois pendant plusieurs années. Des admins qui sont pas forcément formé sur les bonnes pratiques en cours, parce que ça reste quand même difficile à en trouver.
Donc si en plus, faut en trouver qui sont d'accord pour bosser gratuitement, en plus de l'activité normal et en plus se faire pourrir par des inconnus sur le web, c’est plus du recrutement, c'est une chasse au dahu.
Je pourrais aussi parler pendant des heures sur les mécanismes et dynamiques de récompenses autour du logiciel libre et comment le travail d'un admin passe à la trappe, vu que faire le travail correctement implique que ça soit invisible.
Mais ce commentaire est déjà trop long, donc je vais juste conclure pour dire que venir agresser les gens comme tu le fait, c'est aggraver le problème. Et c'est clairement une raison de plus de pas se bouger. De ne pas se bouger par épuisement aprés avoir fait souvent plus que la moyenne, et que ça soit pas suffisant. De ne pas se bouger à cause de l'ingratitude manifeste. De ne pas se bouger par le paternalisme du ton employé.
C'est facturé par cpu, et c'est libre. Va relire ce que dit le contrat de souscription, (si tu l'as lu, car je suppose que sinon, tu commencerais pas à m'affirmer ce qui est marquer dedans, ni à tenter de m'expliquer ce que vends mon employeur)
Tu dois parler de support (rien à voir avec le libre),
Non, je parle pas de support, sinon, j'aurais dit "support".
pas le livrable (qui et libre).
Je suppose que je dois lire "qui est libre".
Rien à voir, le résultat est libre pas par CPU (ils filent
même CentOS maintenant).
Sans vouloir trop pinailler, Centos est fourni par l'équipe Centos, pas par RH. Karanbir Singh (le fondateur) y tient beaucoup, et même si il est payé par RH (en tant qu'Architect dans une équipe d'outil pour dev), il veut que le projet reste séparé. L'infra est physiquement séparé dans des DC différents (sauf 1), et RH intervient pas dessus. La clé de signature est différente, les binaires sont différents, la taille des équipes est différente. L'équipe Centos chez RH est minuscule (5 personnes), et fait grosso modo la même chose qu'avant, à savoir recompiler RHEL.
Faire du support par CPU est une façon de faire rentrer le
fric, ça reste toutefois une façon de diviser le coût et pas
"je te facture le coût, mais en plus je te facture en plus
pour la diffusion".
Encore une fois, c'est pas du support, c'est une souscription qui donne accès aux binaires des mises à jours, avec du support en option (en option car tu as aussi des offres sans, et qui sont pas pour autant gratuite), à une assurance en cas de litige autour des brevets (exemple, RH a suivi Rackspace en 2013 sur le sujet exactement à cause de ça) et divers trucs qu'un commercial bien au courant doit pouvoir t'expliquer (genre les certifications logiciels, qui doivent sans doute pas t'intéresser, mais qui visiblement importe pas mal à des clients).
Quand au cout de diffusion, il est facturé dans tout les cas, sauf à croire que la bande passante, les serveurs et tout ça sont gratuit (et on peut compter aussi le coût des commerciaux, des jursites pour la rédaction des contrats, des comptables, les frais bancaires). C'est juste suffisamment faible et industrialisé pour que ça soit oubliable.
Je n'ai pas créé les règles du libre, et le libre interdit de
limiter la diffusion (par CPU, par support…) par définition.
Pourquoi vouloir centrer sur moi quand ça ne te plait pas?
Parce que tu as un ton péremptoire et que tu dis des choses fausses. Et tu continues.
Par exemple, juste la. Si tu regardes quelques licences libres, t va voir que "le libre interdit de limiter la diffusion" est une simplification trompeuse (et ça, c'est en dehors du fait que tu précises pas de quoi ça interdit de limiter la diffusion). À part une paire plus proches du domaine publique ou équivalent, elles vont toutes limiter la diffusion si tu ne remplis pas certaines conditions. Exemple, la MIT te donne le droit de distribuer sous condition, et si tu remplis pas les conditions, alors tu perds le droit de distribuer.
Il y a aussi un gros flou juridique qui fait que tu va pas pouvoir mélanger du code et le diffuser n'importe comment. E.g si je prends du code sous une licence GPL avec du code sous une licence non compatible (CDDL), et que je le compile pour moi, ça semble passer mais je suis pas sur d'avoir le droit de distribuer les binaires (cf zfs, canonical, etc).
Donc ouais, les règles du libre, c'est bien joli, mais la CDDL et la GPL sont libres, la MIT est libre, et pourtant, mes 2 exemples montre bien que la simplification tient pas la route.
Et c'est aussi oublier que le droit du copyright et des marques déposés s'applique aussi, de manière transverse à la notion de code libre.
Maintenir 2 interfaces, ç'est un cout loin d'être négligeable. Il y a tout un travail de QA à faire en double, écrire plus de documentation, diviser les gens qui font du support sur les listes, etc.
Donc sauf si il y a assez de gens qui sont la pour absorber ce coût en donnant du temps libre et/ou du pognon, je suis pas sur que ça arrive.
Red Hat ne facture pas de la réalisation mais du support (même
si les deux sont liés).
D'une part, il a a plus que le support, il y a les certifications avec les partenaires, la maintenance. D'autre part, la facturation à la réalisation, ça s'appelle du consulting aussi. Et bien que RH ne fasse pas trop de développement à façon (en dehors des scripts pondus par les consultants), d'autres boites le font (exemple, Canonical a eu ça comme offre pour les partenaires OEM)
Comment tu fais du support avec le design ? C'est plutôt du one
shot, avec des corrections par moment peut être mais tu factures > par pallier pour la réalisation.
Ça dépend du design de quoi. Un site web, ça se rafraichit de temps par exemple.
Le souci aussi, c'est que tu n'entends les gens que quand ça leur plait pas. Tu entends ni les nouveaux utilisateurs à qui ça plait, ni les anciens à qui ça plait. Tu vois pas si il y a eu moins d'appels au support, si les tests ont montrés que c'était plus facile, si les gens ont plus rapidement compris.
En gros, on parle que des problèmes, jamais des améliorations. C'est comme conclure qu'un logiciel est vachement bugué parce qu'il y a plein de bugs ouverts, c'est pas regarder la bonne métrique.
je ne connais personnellement aucun exemple de tel logiciel.
Gnuradio compagnon me semble coller avec ce que tu dis. (ironie, il est la justement parce que le texte ne suffit pas pour traiter du binaire)
les autres sont vraiment des daubes en matière d'ergonomie ou de
productivité.
Alors autant pour le libre que pour le proprio, je pense qu'il faut arrêter de balancer sans justifier "c'est des daubes". Sans savoir ce que tu veux faire avec le logiciel, ni comment le logiciel te bloque ou comment il réduit ta productivité, ç'est une opinion qui n'apporte pas grand chose et qui a plus tendance à démoraliser et à démotiver.
Et autant, je doute que grand monde de Google te lise et corrige Gmail (pour ne citer que lui), autant je pense que prendre les bonnes habitudes va permettre justement d'avoir plus de chances d'attirer des designers.
On est ici dans l'opposition complète au libre, qui ne
s’intéresse pas à la diffusion (combien, support etc)
Tu généralises par rapport à ta situation, mais y a pas que des PMEs et des petites boites dans le libre. Dans la pratique, les boites plus grosse (et qui marche, genre Red Hat, ou Suse) facture pas le libre "à la réalisation", mais bien à l'usage par processeur.
Donc bon, l'opposition au libre, faudra repasser, sauf à vouloir dire "l'opposition au libre suivant Zenitram", ce qui est une assez grosse nuance.
Rien ne bouge ? De ton point de vue peut-être. Pourtant
d'années en années, il y a de plus en plus de libre. T'as ptet
un noyau libre dans la poche en ce moment même. Ta box adsl y
a quoi dedans ? Ton blog sous Dotclear c'est du propriétaire
En gros, oui, le libre est la ou y a pas d'interface. L'exception dans ta liste, c'est dotclear. Mais sinon, l'interface de la box ADSL est sans doute non libre, la majorité du code qui tourne par dessus linux est non libre (que ça soit sur les serveurs webs, ou sur un tel android).
Donc ouais, cool, le libre a permis au propriétaire de monter d'un cran.
Mais dans le cas de Twitter (que j'utilise pas, mais que je vais lire à la mano), j'aurais tendance à dire que l'ergonomie et l'UX marchent comme on leur demande de marcher, avec "on" étant "les patrons de Twitter". Pas "on" étant les utilisateurs de la plateforme. Et c'est le nœud du problème.
Twitter, comme beaucoup de réseau sociaux, a une interface dont le but est de retenir les gens sur la plateforme, et de rendre les choses virales (par design). Les raisons pour ça sont assez claires (utilisateurs qui passent du temps => afficher des pubs => argent => payer les employés/la piscine du CEO).
Et on voit que par exemple, comme la protection des utilisateurs n'est pas une priorité (en partie parce que ça réduit l'usage de la plateforme, en partie parce que les créateurs de Twitter n'ont pas du subir de soucis assez souvent pour que ça leur vienne à l'idée que ça arrive aux autres), alors l'interface est naze pour ça, malgré des propositions concrètes comme https://artplusmarketing.com/putting-out-the-twitter-trashfire-3ac6cb1af3e?source=user_profile---------1----------
L'UX du web de nos jours utilise fortement les méthodes tel que l'A/B testing pour vérifier les hypothèses (voir https://www.behave.org/tests-of-the-week/ pour des tas d'exemple instructifs). Donc si quelqu'un dit à l'équipe en charge du design "qu'est ce qu'on peut faire pour que les gens passent plus de temps sur le site", alors quelqu'un va trouver et mettre l'interface pour ça.
Et donc, oui, l'interface de Twitter est bien faite, mais pour ses propriétaires, avec ce qu'ils veulent en faire. Pas pour ses utilisateurs, avec ce qu'ils veulent en faire.
Et c'est la ou le logiciel libre a une carte à jouer, en proposant des interfaces qui vont aller beaucoup plus dans le sens de l'utilisateur, tout comme un logiciel libre va aller beaucoup plus dans le sens du respect de la vie privée de son utilisateur que dans le sens inverse.
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.
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.
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.
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).
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.
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.
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)
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.
[^] # Re: Et ils continuent de nier le problème ...
Posté par Misc (site web personnel) . En réponse au journal Pas de mises à jour de sécurité depuis 5 ans sur l’infrastructure Mageia. Est‐ce bien raisonnable ?. Évalué à 10.
Venir agresser des bénévoles par le biais de LinuxFr, c'est pas terrible comme comportement. L'infrastructure de Mageia a le bon gout d'être ouverte depuis le début, et quand j’étais un des admins la bas, j'ai reçu epsilon patchs de la communauté. Soit, faire l'administration système, c'est compliqué et c'était pas vraiment une des compétences des utilisateurs dans la communauté. J'ai bien conscience que puppet (l'outil choisi à l'époque) est un outil non trivial pour le péquin moyen (voir même les concepts modernes de gestion de serveurs). Et si je devais le refaire maintenant, je referais ça autrement (et je le refait autrement justement).
Mais c'est pas le propos. Le propos, c'est que sans aide et sous la charge de travail (bénévole), j'ai quitté le projet pour éviter le burnout. Burnout qui a failli me couter mon taf à mi-temps et qui m'a couté la relation avec ma copine de l'époque. Je suis pas non plus le seul, car d'autres admins ont lachés l'équipe pour divers raisons (parfois de santé, parfois autres). Mais curieusement, y a pas grand monde qui est venu remplacer les départs depuis la communauté.
Donc arriver en donneur de leçon la bouche en cœur, c'est totalement contre productif et passablement odieux vu que ça va juste dégouter les gens de filer du travail gratuitement à des gens dont la gratitude semble inexistante.
Si quelqu'un estime pouvoir donner son avis sur le taf à faire par des bénévoles, y a plusieurs solutions. Soit la personne a les compétences et je m'attends à minimum de voir un patch arriver. Soit la personne n'a pas les compétences, et je m'attends à ce que les gens aient la décence de ne pas se comporter de façon hautaine à expliquer à ceux qui font le travail comment le faire en étant insultant.
Ou si la personne n'a pas le temps, je m'attends aussi à ce que les gens comprennent que le temps des autres aussi n'est pas infini.
Je ne veux pas minimiser les soucis d'attaques sur les infras, ça arrive en moyenne une fois tout les 3 mois d’après mes recherches (moyenne fait sur les 10 dernières années). Mais ce genre de soucis, c'est aussi arrivé à beaucoup de projets et pas des moindres :
Php.net, 2013: https://barracudalabs.com/2013/10/php-net-compromise/
Rubygem: http://blog.rubygems.org/2013/01/31/data-verification.html
Ou des distros/OS:
Debian: https://lwn.net/Articles/191744/
https://www.debian.org/devel/debian-installer/News/2003/3
FreeBSD (2012):
https://www.freebsd.org/news/2012-compromise.html
Red Hat/Fedora (2008):
https://www.cnet.com/news/red-hat-fedora-servers-compromised/
J'ai une liste de 50 compromissions, je peux continuer toute la nuit.
Tantôt c'est du vol de compte. Tantôt c'est du bruteforce de login ssh. Parfois, on sait pas car personne n'a fait de forensic (parce que oui, la sécurité, c'est un métier, c'est pas juste aller crier sur les gens sur un site web, au cas ou les gens auraient des doutes).
Parfois les détails sont pas publiques, et j'ai eu beaucoup de mal à retrouver des infos. J'ai pas encore pu tomber sur des 0days de folies ou des exploits complexes, et pourtant j'ai fait le tour des confs pour parler aux gens impliqués dans certains cas, je me suis tapé facile 30 à 40 rapports sur les différentes attaques pour comprendre (https://github.com/aptnotes/data ).
Mais la cause à la base, c'est souvent toujours pareil. C'est des systèmes oubliés, mal sécurisés et souvent un manque d'admin sur des projets, parfois pendant plusieurs années. Des admins qui sont pas forcément formé sur les bonnes pratiques en cours, parce que ça reste quand même difficile à en trouver.
Donc si en plus, faut en trouver qui sont d'accord pour bosser gratuitement, en plus de l'activité normal et en plus se faire pourrir par des inconnus sur le web, c’est plus du recrutement, c'est une chasse au dahu.
Je pourrais aussi parler pendant des heures sur les mécanismes et dynamiques de récompenses autour du logiciel libre et comment le travail d'un admin passe à la trappe, vu que faire le travail correctement implique que ça soit invisible.
Mais ce commentaire est déjà trop long, donc je vais juste conclure pour dire que venir agresser les gens comme tu le fait, c'est aggraver le problème. Et c'est clairement une raison de plus de pas se bouger. De ne pas se bouger par épuisement aprés avoir fait souvent plus que la moyenne, et que ça soit pas suffisant. De ne pas se bouger à cause de l'ingratitude manifeste. De ne pas se bouger par le paternalisme du ton employé.
[^] # Re: Pour savoir où on met les pieds
Posté par Misc (site web personnel) . En réponse au journal Le libre et l'expérience utilisateur. Évalué à 2.
C'est facturé par cpu, et c'est libre. Va relire ce que dit le contrat de souscription, (si tu l'as lu, car je suppose que sinon, tu commencerais pas à m'affirmer ce qui est marquer dedans, ni à tenter de m'expliquer ce que vends mon employeur)
Non, je parle pas de support, sinon, j'aurais dit "support".
Je suppose que je dois lire "qui est libre".
Sans vouloir trop pinailler, Centos est fourni par l'équipe Centos, pas par RH. Karanbir Singh (le fondateur) y tient beaucoup, et même si il est payé par RH (en tant qu'Architect dans une équipe d'outil pour dev), il veut que le projet reste séparé. L'infra est physiquement séparé dans des DC différents (sauf 1), et RH intervient pas dessus. La clé de signature est différente, les binaires sont différents, la taille des équipes est différente. L'équipe Centos chez RH est minuscule (5 personnes), et fait grosso modo la même chose qu'avant, à savoir recompiler RHEL.
Encore une fois, c'est pas du support, c'est une souscription qui donne accès aux binaires des mises à jours, avec du support en option (en option car tu as aussi des offres sans, et qui sont pas pour autant gratuite), à une assurance en cas de litige autour des brevets (exemple, RH a suivi Rackspace en 2013 sur le sujet exactement à cause de ça) et divers trucs qu'un commercial bien au courant doit pouvoir t'expliquer (genre les certifications logiciels, qui doivent sans doute pas t'intéresser, mais qui visiblement importe pas mal à des clients).
Quand au cout de diffusion, il est facturé dans tout les cas, sauf à croire que la bande passante, les serveurs et tout ça sont gratuit (et on peut compter aussi le coût des commerciaux, des jursites pour la rédaction des contrats, des comptables, les frais bancaires). C'est juste suffisamment faible et industrialisé pour que ça soit oubliable.
Parce que tu as un ton péremptoire et que tu dis des choses fausses. Et tu continues.
Par exemple, juste la. Si tu regardes quelques licences libres, t va voir que "le libre interdit de limiter la diffusion" est une simplification trompeuse (et ça, c'est en dehors du fait que tu précises pas de quoi ça interdit de limiter la diffusion). À part une paire plus proches du domaine publique ou équivalent, elles vont toutes limiter la diffusion si tu ne remplis pas certaines conditions. Exemple, la MIT te donne le droit de distribuer sous condition, et si tu remplis pas les conditions, alors tu perds le droit de distribuer.
Il y a aussi un gros flou juridique qui fait que tu va pas pouvoir mélanger du code et le diffuser n'importe comment. E.g si je prends du code sous une licence GPL avec du code sous une licence non compatible (CDDL), et que je le compile pour moi, ça semble passer mais je suis pas sur d'avoir le droit de distribuer les binaires (cf zfs, canonical, etc).
Donc ouais, les règles du libre, c'est bien joli, mais la CDDL et la GPL sont libres, la MIT est libre, et pourtant, mes 2 exemples montre bien que la simplification tient pas la route.
Et c'est aussi oublier que le droit du copyright et des marques déposés s'applique aussi, de manière transverse à la notion de code libre.
[^] # Re: Raisonnement débile ...
Posté par Misc (site web personnel) . En réponse au journal Le libre et l'expérience utilisateur. Évalué à 4.
Maintenir 2 interfaces, ç'est un cout loin d'être négligeable. Il y a tout un travail de QA à faire en double, écrire plus de documentation, diviser les gens qui font du support sur les listes, etc.
Donc sauf si il y a assez de gens qui sont la pour absorber ce coût en donnant du temps libre et/ou du pognon, je suis pas sur que ça arrive.
[^] # Re: Pour savoir où on met les pieds
Posté par Misc (site web personnel) . En réponse au journal Le libre et l'expérience utilisateur. Évalué à 4.
D'une part, il a a plus que le support, il y a les certifications avec les partenaires, la maintenance. D'autre part, la facturation à la réalisation, ça s'appelle du consulting aussi. Et bien que RH ne fasse pas trop de développement à façon (en dehors des scripts pondus par les consultants), d'autres boites le font (exemple, Canonical a eu ça comme offre pour les partenaires OEM)
Ça dépend du design de quoi. Un site web, ça se rafraichit de temps par exemple.
[^] # Re: Mon positionnement
Posté par Misc (site web personnel) . En réponse au journal Le libre et l'expérience utilisateur. Évalué à 4.
Dans le même genre d'idée, en 2002, je pense que mon pc avait déjà 256 de ram (donc 24 en 2001, c’était déjà un pc vieux de 5 ans)
[^] # Re: Raisonnement débile ...
Posté par Misc (site web personnel) . En réponse au journal Le libre et l'expérience utilisateur. Évalué à 6.
Le souci aussi, c'est que tu n'entends les gens que quand ça leur plait pas. Tu entends ni les nouveaux utilisateurs à qui ça plait, ni les anciens à qui ça plait. Tu vois pas si il y a eu moins d'appels au support, si les tests ont montrés que c'était plus facile, si les gens ont plus rapidement compris.
En gros, on parle que des problèmes, jamais des améliorations. C'est comme conclure qu'un logiciel est vachement bugué parce qu'il y a plein de bugs ouverts, c'est pas regarder la bonne métrique.
[^] # Re: Exemple de réponse
Posté par Misc (site web personnel) . En réponse au journal Le libre et l'expérience utilisateur. Évalué à 4.
Gnuradio compagnon me semble coller avec ce que tu dis. (ironie, il est la justement parce que le texte ne suffit pas pour traiter du binaire)
Alors autant pour le libre que pour le proprio, je pense qu'il faut arrêter de balancer sans justifier "c'est des daubes". Sans savoir ce que tu veux faire avec le logiciel, ni comment le logiciel te bloque ou comment il réduit ta productivité, ç'est une opinion qui n'apporte pas grand chose et qui a plus tendance à démoraliser et à démotiver.
Et autant, je doute que grand monde de Google te lise et corrige Gmail (pour ne citer que lui), autant je pense que prendre les bonnes habitudes va permettre justement d'avoir plus de chances d'attirer des designers.
[^] # Re: Pour savoir où on met les pieds
Posté par Misc (site web personnel) . En réponse au journal Le libre et l'expérience utilisateur. Évalué à 3.
Tu généralises par rapport à ta situation, mais y a pas que des PMEs et des petites boites dans le libre. Dans la pratique, les boites plus grosse (et qui marche, genre Red Hat, ou Suse) facture pas le libre "à la réalisation", mais bien à l'usage par processeur.
Donc bon, l'opposition au libre, faudra repasser, sauf à vouloir dire "l'opposition au libre suivant Zenitram", ce qui est une assez grosse nuance.
[^] # Re: C'est pas qu'une histoire d'ergo
Posté par Misc (site web personnel) . En réponse au journal Le libre et l'expérience utilisateur. Évalué à 7.
En gros, oui, le libre est la ou y a pas d'interface. L'exception dans ta liste, c'est dotclear. Mais sinon, l'interface de la box ADSL est sans doute non libre, la majorité du code qui tourne par dessus linux est non libre (que ça soit sur les serveurs webs, ou sur un tel android).
Donc ouais, cool, le libre a permis au propriétaire de monter d'un cran.
[^] # Re: .
Posté par Misc (site web personnel) . En réponse au journal Le libre et l'expérience utilisateur. Évalué à 10.
J'utilise pas Netflix, donc je ne peux pas juger.
Mais dans le cas de Twitter (que j'utilise pas, mais que je vais lire à la mano), j'aurais tendance à dire que l'ergonomie et l'UX marchent comme on leur demande de marcher, avec "on" étant "les patrons de Twitter". Pas "on" étant les utilisateurs de la plateforme. Et c'est le nœud du problème.
Twitter, comme beaucoup de réseau sociaux, a une interface dont le but est de retenir les gens sur la plateforme, et de rendre les choses virales (par design). Les raisons pour ça sont assez claires (utilisateurs qui passent du temps => afficher des pubs => argent => payer les employés/la piscine du CEO).
Et on voit que par exemple, comme la protection des utilisateurs n'est pas une priorité (en partie parce que ça réduit l'usage de la plateforme, en partie parce que les créateurs de Twitter n'ont pas du subir de soucis assez souvent pour que ça leur vienne à l'idée que ça arrive aux autres), alors l'interface est naze pour ça, malgré des propositions concrètes comme https://artplusmarketing.com/putting-out-the-twitter-trashfire-3ac6cb1af3e?source=user_profile---------1----------
L'UX du web de nos jours utilise fortement les méthodes tel que l'A/B testing pour vérifier les hypothèses (voir https://www.behave.org/tests-of-the-week/ pour des tas d'exemple instructifs). Donc si quelqu'un dit à l'équipe en charge du design "qu'est ce qu'on peut faire pour que les gens passent plus de temps sur le site", alors quelqu'un va trouver et mettre l'interface pour ça.
Un article qui a fait beaucoup de bruit à ce sujet l'année dernière explique mieux que moi le souci:
https://medium.com/swlh/how-technology-hijacks-peoples-minds-from-a-magician-and-google-s-design-ethicist-56d62ef5edf3#.yatff74k1
Et donc, oui, l'interface de Twitter est bien faite, mais pour ses propriétaires, avec ce qu'ils veulent en faire. Pas pour ses utilisateurs, avec ce qu'ils veulent en faire.
Et c'est la ou le logiciel libre a une carte à jouer, en proposant des interfaces qui vont aller beaucoup plus dans le sens de l'utilisateur, tout comme un logiciel libre va aller beaucoup plus dans le sens du respect de la vie privée de son utilisateur que dans le sens inverse.
[^] # Re: Passe à côté de tout
Posté par Misc (site web personnel) . En réponse au journal Le libre et l'expérience utilisateur. Évalué à 10.
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.
[^] # Re: Flatpak pour les paquets de logiciels de bureau
Posté par Misc (site web personnel) . En réponse au journal La multiplicité des gestionnaires de paquets. Évalué à 3.
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.
[^] # Re: tendance
Posté par Misc (site web personnel) . En réponse au journal La multiplicité des gestionnaires de paquets. Évalué à 3. Dernière modification le 31 janvier 2017 à 11:13.
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.
[^] # Re: tendance
Posté par Misc (site web personnel) . En réponse au journal La multiplicité des gestionnaires de paquets. Évalué à 7.
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.
[^] # Re: Python 3
Posté par Misc (site web personnel) . En réponse au journal Déploiement et automatisation avec Ansible - partie 1. Évalué à 6.
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.
[^] # Re: Ansible Semaphore
Posté par Misc (site web personnel) . En réponse au journal Déploiement et automatisation avec Ansible - partie 1. Évalué à 2.
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
[^] # Re: Agentless, danger
Posté par Misc (site web personnel) . En réponse au journal Déploiement et automatisation avec Ansible - partie 1. Évalué à 2.
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.
[^] # Re: Agentless, danger
Posté par Misc (site web personnel) . En réponse au journal Déploiement et automatisation avec Ansible - partie 1. Évalué à 2.
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.
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.
[^] # Re: Agentless, danger
Posté par Misc (site web personnel) . En réponse au journal Déploiement et automatisation avec Ansible - partie 1. Évalué à 2.
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.
[^] # Re: Un résolveur à la maison
Posté par Misc (site web personnel) . En réponse au journal DNS anonyme. Évalué à 2.
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)
[^] # Re: Quelques tests
Posté par Misc (site web personnel) . En réponse au journal DNS anonyme. Évalué à 2.
Une liste (AMHA) plus complète se trouve aussi ici: https://diyisp.org/dokuwiki/doku.php?id=technical:dnsresolver
# Sinon, y a tor
Posté par Misc (site web personnel) . En réponse au journal DNS anonyme. Évalué à 2.
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.
[^] # Re: J'ai rien compris
Posté par Misc (site web personnel) . En réponse au journal Retour d'expérience sur un hébergeur Français. Évalué à 8.
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.
[^] # Re: PPA pour Debian?
Posté par Misc (site web personnel) . En réponse au journal Owncloud viré de Debian. Évalué à 2.
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.
[^] # Re: PPA pour Debian?
Posté par Misc (site web personnel) . En réponse au journal Owncloud viré de Debian. Évalué à 3.
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.