Il est bon. J'ai déjà donné des confs en Amérique du Nord, je fait des confcalls 3 fois par semaine dans la langue, je fait des jeux de mots pourris assez régulièrement. Je suis fatigué après une journée, mais moins qu'avant.
Comment as-tu fait pour le parler de façon acceptable ?
En pratiquant. D'abord, la lecture, ce que tu sembles deja réussir. Ensuite à l'écrire. Puis, à force de l'écouter (par exemple, des vidéos de conférence sur youtube) et de tenter de le parler, ça s'améliore. Le truc, c'est d'avoir des gens compréhensifs face à toi, et de persévérer.
Je sais que ç'est pas simple et c'était pas simple pour moi non plus. Je sais que les gens se sentent ridicule, qu'on se sent con à ne pas trouver ses mots, qu'on est frustré. Je parle bien anglais, mais je galère sur d'autres langues, donc je suis pas étranger à ce que tu vis.
J'ai appris l'anglais à l'école en 3eme langue. J'ai fait 4 mois à l'étranger dans une fac anglophone. J'ai aucun souvenir d'avoir eu des soucis, mais je ne doute pas que j'en ai eu. J'ai juste oublié, et ça finit par passer.
Comment tu fais pour ne pas être stressé avant/pendant un call
?
J'ai l'habitude. Mais oui, au début, c'était pas simple. On est passé à des videos conférence, ce qui permet déjà de voir qui parle, parce qu'en vidéoconférence audio uniquement, c'était horrible.
Est-ce que tu pourrais être dans l'entreprise où tu es
aujourd'hui si tu ne parlais pas anglais ?
Non. Je bosse pour une boite US, les 3 gens entre moi et le PDG ont tous l'anglais US comme langue maternelle. Le PDG aussi. Et je pense plus de 75% de mon département.
Mon entretien d'embauche était en anglais.
Si je parlait pas anglais, j'aurais pas pu rentrer dans la boite il y a 6 ans. J'aurais sans doute eu du mal à parler à des gens sur les projets libres à l'époque y a 10 ans.
Est-ce que tu as dû te farcir des séries américaines en VO
alors que tu détestes ça ?
Non. Si tu détestes ça, tu as plusieurs autres choix. Tu peux prendre un film que tu aimes bien, que tu connais par coeur et le revoir, en anglais.
Tu peux regarder des vidéos de conférence sur youtube sur un sujet que tu aimes, même au ralenti, tu as le droit. Si tu piges pas un mot, tu as le droit d'arrêter. Tu as le droit de revenir en arrière, de demander à quelqu'un, de mettre les sous titres. De regarder que 5 minutes à la fois parce que tu es trop fatigué.
Mais ça, ça n'aide que pour la compréhension, ce qui est déjà bien, mais ça va pas t'aider à surmonter ta peur.
Pour parler, bah, faut se lancer.
Tu peux aller à des groupes de discussions (y en sur meetup.com), tu peux (sous réserve de pognon/liberté) aller t'expatrier un temps. Tu peux demander des cours dans la cadre du droit à la formation. Tu peux utiliser duolingo ou autre applications. Tu peux faire un karaoké. Tu peux parler avec quelqu'un qui parle anglais pour t'entrainer.
Mais c'est comme tout, c'est qu'une question de pratique. Crois moi, ça s'améliore à la fin. Pas forcément au bout d'une semaine, ni même d'un mois, mais ça s'améliore.
Et non, tu n'es pas seul. Même si c'est pas mon cas, je connais plein de gens qui ont du mal avec l'anglais.
Je suis d'accord qu'une cause c'est ça, mais ce qui est
intéressant c'est que Red Hat aurait pu avoir le même problème
sur le serveur, mais a réussit à le contourner par la
certification fabricant. (certains n'aiment pas ça d'ailleurs,
mais globalement on peut quand même dire que ça a fait avancer
le libre, surtout que RedHat a eu une stratégie long terme en
étant un gros contributeur du logiciel libre).
C'est marrant, parce qu'il y a une demande pour avoir du matos qui marche sous Linux. Et c'est quoi du matos qui marche sous Linux si c'est pas du matos certifié ?
Il y a une demande, mais pas suffisante pour payer ça (parce que des machines certifiés desktop, y a eu des tentatives d'aussi loin que je me souvienne, Mandrakesoft en a eu, Red hat en a eu, Suse en a eu, Canonical en a eu, et en a encore via Dell). Et pourtant, j'en croise très rarement. Encore une fois, la demande ne suit pas les moyens, parce que quand les gens disent "je veux tel truc", c'est "je veux tel truc mais sans payer trop cher" (ce que je peux comprendre, l'argent pousse pas sur les arbres).
Dans le b2c il faut investir en amont et attendre une réponse
du public qui sera en plus longue à venir et avec des besoins
plus hétérogènes et donc un écosystème plus riche qu'il faut
réussir à emporter avec soi.
Il faut surtout avoir la logistique qui va avec. Il y a 15 ans, c'était passer par la Fnac, Surcouf, etc. Il y a 5 ans, c’était ce que Mozilla a tenté avec Firefox OS. On sait comment ça s'est fini hélas, et c'est pas faute d'avoir tenté de faire au mieux de la part des acteurs du libre.
Aujourd'hui, les seules qui se débrouillent sur le marché, c'est des petites boites comme system76 ou purism. Et je pense principalement parce qu'elles ont du matériel reconditionné et pas besoin de magasin physique (merci le web).
Et quand on regarde ce qui est arrivé, ceux qui ont réussi à mettre du Linux pour le grand publique, c'est Google. Et ils ont réussi en créant un écosystème de zéro, mais surtout en créant un écosystème proprio et générateur d'argent. Personnellement, j’abhorre Android et son écosystème (parce que grandement proprio, parce que grandement non maintenu, parce que rempli de mouchard, etc, etc), mais je reconnait qu'ils ont rendu ça attractif d'une façon qui n'arriverais sans doute pas sur le bureau pour nos distributions classiques.
Son journal semble dire que la les moyens ont été mis.
Je ne dit pas que les moyens ne sont pas mis dans le cas présenté, et pour être franc, je ne parle même pas de ce cas en particulier. Mais mettre les moyens ne suffit pas toujours, ni même ne décrit grand chose, car mettre les moyens ne dit pas "mettre les moyens suffisant".
Tu peux mettre les moyens pour faire marcher quelque chose, ça veut pas dire que ça va améliorer les choses pour tout le monde. C'est typiquement tout le souci d'avoir une version custom d'une distribution Linux. Les moyens sont mis pour que ça marche chez l'utilisateur final, en ayant des admins pour que la plateforme marche, en faisant des backports et des modifs. Mais ça rends rarement la migration et/ou le support des autres plus simples et moins couteux. Donc ça fait pas avancer le schmilblick.
Les fabricants ne s'intéressent que peu a la plateforme. D'une
part parce qu'elle est minoritaire et, dans une moindre mesure,
car aucun commercial / programme de certification ne leur donne
un joli logo ou autre. Bref il y a peu d'incentive (motivation
par la récompense)
Pas vraiment, y a des programmes de certifs pour un certains nombres de distributions avec un acteur commercial (exemple, RHEL, SLES, et Ubuntu ). Ça reste minoritaire, mais pas parce que personne ne donne de logo.
pour pas mal de logiciels, il y a une difficulté de financement /
modèle économique,
ce qui est mon point. On vends le truc comme étant pas cher, ben y a pas d'argent qui rentre.
la pluralité des solutions et de leur composition multiplient
les chances d'anomalies
Encore une fois, il y a des distributions qui vont faire des choix. Mais curieusement, les gens convaincu du libre ne veulent pas de ça, voir boude l'idée. Juste sur les environnement de bureau, tout le monde veut avoir son favori dans chaque distribution. Et tout le monde veut tout avoir à jour, mais stable. Et gratos. Avec des changements, mais sans avoir à changer la doc et/ou changer l'UX. Et j'ai dit sans bugs ?
Redhat a réussi ça sur le serveur, mais pour le bureau, le
marché semble plus difficile à attaquer et satisfaire…
Parce que les examples de desktop qu'on donne sont surtout des examples ou l'argent ne remonte pas vers les éditeurs.
Prenons les divers projets phares de migration sur Linux sur le desktop.
L'assemblée nationale en France, c'est Linagora qui a eu le marché à l'époque, la boite a mis 1 personne qui a fait un dérivé de Kubuntu, et pas un centime n'est sans rien payer à Canonical que je sache.
La province autonome d'Estramadura, ils sont parti sur un dérivé de Debian (GNU/Linex)
La ville de Munich, ils sont parti sur une distro custom, encore une Debian.
3 cas, 3 fois ou l'argent n'a pas été filé à un éditeur, avec un intermédiaire qui a du se financer pas mal. Quand l'éditeur reverse son obole au libre, ça donne un secteur sain, mais en général, on te file des thunes pour un service, et ce qui pourrait aller au logiciel libre, c'est ce qui reste. Pire encore, vu qu'on parle à chaque fois d'une distro custom, il y a pas de partage des améliorations, cf ce que j'ai dit plus haut.
Ensuite, y en a qui font les choses proprement, par exemple Google. L'entreprise a une distro custom (surprise), mais payent (ou payaient) Canonical pour le support. Et c'est plus parce que Google a du pognon à perdre et pour financer le libre de façon indirect qu'autre chose, AMHA.
Et pourtant, des clients sur le desktop, y en a. La division Desktop de RH est auto suffisante si j'en croit les gens qui bossent la bas (e.g., ça rapporte assez pour embaucher du monde et faire des choses). Et c'est pas non plus rare d'avoir des stations de travail dans certains secteurs spécialisés (exemple, Pixar a des stations de travail sous RHEL, ma fac à Montreal en avait, l'université de Caroline du Nord aussi) si j'en croit une rapide recherche sur le web (exemple: https://www.reddit.com/r/linux/comments/71mx9s/how_many_of_you_actually_use_red_hat_enterprise/ ). Et pas que RH, je sais que Qualcomm avait des postes sous Ubuntu, et je suis sur que quelqu'un peut me donner des examples de client sous SLES pour le desktop.
Mais la différence entre les examples que j'ai donné au début et ceux la, c'est qu'il s'agit de postes bureautiques vs des stations de travail. Et quand je dit "station de travail", je parle de trucs qui étaient sous Unix il y a 20 ou 30 ans (Irix, Solaris), dans des secteurs ou on s'attend à dépenser de l'argent pour ça.
On voit directement les secteurs qui sont soutenus par les
entreprises.
Je pense que c'est le noeud du problème. On vends l'idée d'utiliser Linux pour économiser de l'argent, ce qui aboutit juste à un secteur économique anémique, vu que les gens dépensent moins pour ça la ou je pense qu'il faut dépenser plus.
Je comprends bien que le prix soit un levier puissant, mais sur le long terme, ça n'aide pas à atteindre un équilibre.
C'est pas juste Glusterfs, c'est les systèmes de fichiers distribués et réseaux. Lire 100G par fichier de 1k, ça implique d elire une tonne de meta données et de faire une tone d'aller retour. Lire 100G d'un coup, c'est juste ça, 100G de transfert.
Ensuite, il y a du tuning à faire sans doute pour améliorer les choses, mais il y a des moments ou la latence réseau est visible, et le cas des petits fichiers en fait parti.
Oui, ça viendrait à personne d'utiliser des arbres de Merkel pour des choses comme la gestion du code source ou ce genre de trucs au lieu d'une base de données.
En fait tout cela me fait m'interroger sur le concept même
d'Ethereum. La blockchain c'est cool pour enregistrer des données
statiques comme des transactions, mais pour du code ? Par son
concept même, on en pourra jamais mettre à jour le code. Il faut
donc être sacrément sûr de son code pour commencer à l'utiliser,
parce qu'on ne pourra alors plus le changer. Et même si on prouve
le code à 100%, on n'est pas à l'abri d'une erreur humaine (ici,
oublier d'appeler une méthode d'initialisation).
Ce qui en soit est pas si différent du type de déploiement qu'on voit pour de l'embarqu^W IOT. Et dire qu'on peut pas mettre à jour, c'est aussi un peu trompeur. Tu pourrais si tu avais le controle de la blockchain entiére. C'est certes sans doute impossible pour une blockchain publique, mais je suis sur qu'il existe des applications ou tu as ta propre blockchain privé et ou c'est faisable, ce qui limite quand même les risques (un peu comme faire un git push -f, ça passe mieux quand tu es seul)
Tout d'abord, au niveau local il peut y avoir une sécurisation
des données grâce à du RAID
Le RAID, j'ai pas tendance à voir ça comme une sécurité des données plus que s'assurer de la disponibilité et que l'uptime ne prends pas un coup si un disque tombe (en partant du principe que tu as un niveau de raid différent de 0). Parce que le RAID sécurise pas vraiment contre un effaçage par erreur ou contre un bug du FS :/
En fait, j'ai vraiment tendance à ne pas aimer qu'on parle de sécurisation sans dire "contre quoi", parce que ç'est indispensable pour savoir ce qui manque, surtout si c'est à destination des membres, qui vont pas forcément avoir le réflexe de penser "ok, qu'est ce qui se passe si tel truc arrive".
Entre site, la réplication des VM ne se fera qu'en asynchrone.
Pour la réplication, le plus simple est de faire un snapshot de
la VM puis de la répliquer.
Plus simple oui, mais je suis pas sur que ça marche à 100%. Encore une fois, tu peux avoir le disque dans un état non consistant. Et ça, c'est quand tu as pas des données sur plusieurs disques (exemple, un serveur sql partagé et X serveurs webs avec des applis différentes), parce que ça devient vite compliqué Ensuite, je donne le pire cas possible, il est possible que ça marche suffisamment bien et que tu puisses corriger à la main le reste du temps (e.g, aller tripoter dans la DB si besoin), donc je suppose qu'il ne faut pas faire une usine à gaz.
7 serveurs physiques, ça me parait un chouia trop. Tu peux t'en sortir avec moins si tu mets les OSD et les moniteurs sur les mêmes machines, en partant du principe que tu as dimensionné ça de façon à ce que ça passe (genre, avoir un disque, asse de ram et un CPU par OSD, et donc un CPU et assez de ram pour le moniteur, avec "assez" documenté sur ceph.com).
Ensuite, ça dépend aussi de la topologie réseau que tu va mettre des patterns d'accès, de la volumétrie, des perfs que tu veux avoir.
Par exemple, ça parle de réplication, mais est ce que l'idée est d'avoir une réplication en temps réel (et donc synchrone) auquel cas les performances vont chuter si tu fait ça sur un site distant, ou d'avoir des trucs asynchrones et de la magie pour revenir quand ça explose ?
Il n'y a pas spécialement de discussion sur la volumétrie non plus ou la question du lien entre les sites.
Le type de données va aussi importer. L'utilisation de GlusterFS pour stocker des images de VM fait parti des cas supportés par le projet (vu que c'est des gros fichiers, ç'est assez performant), et le projet ovirt le supporte. Mais de la même façon, des gens placent le stockage en mode bloc dans Ceph.
Mais si le but est d'avoir des machines dont tu fait des snapshot, je pense que tu peux pas éviter d'aller dans la VM et faire des choses pour que les données sur le disque soit cohérentes.
J'ai par exemple du mal à voir comment une synchro des blocs ne va pas corrompre une base de données et une appli web si ça pête au mauvais moment, vu que c'est rarement atomique (sauf à tout mettre dans la base de données, et à avoir des transactions, mais je pense que pas grand monde vérifie ça, et qu'à choisir entre une appli qui va exploser sous un cas critique, et pas d'appli, les gens prennent l'appli quand même).
Du coup, si tu fait la redondance au niveau au dessus, tu as moins besoin au niveau en dessous.
Donc les besoins vont dépendre des applis. Est ce qu'il faut avoir de la HA automatique, ou remonter rapidement suffit ? Comment le systéme va devoir se débrouillé en mode dégradé ?
Pour reprendre l'appli d'exemple de toute à l'heure, une solution de stockage classique avec une base SQL répliqué suffirait, avec des frontends sans état, pas besoin de sortir des trucs complexes (pour peu que les VMs soit identiques)
Et sinon, on est en 2017, les archis à base de conteneurs ont le vent en poupe, et ont le bon gout de pousser à séparer données et codes, ce qui permet aussi de se focaliser sur ce qui AMHA importe, les données. Je dit pas que c'est une bonne idée, mais je pense que c'est pas déconnant de regarder. Et pas regarder docker tout nu, plus des choses comme kubernetes/openshift ou mesos, avec idéalement une stack supporté.
Et la partie "pas de java" me parait quand même restrictive et sans doute mal exprimé. Parce que je suis sur que pour certaines choses, y a sans doute d'autres languages qui vont faire pire que java (cough golang et rust pour du statique, ruby pour tirer 5T de deps), donc je suis sur qu'il y a plus précis comme demande.
Ben si c'est justement parce qu'on bosse dans l'IT qu'on bondit sur notre chaise.
Arrête ton char, tu sais très bien que dans l'IT, tu as toujours un delta énorme entre ce que tu voudrais faire, et ce que tu peux faire dans les temps.
Et la, c'est pareil, sauf qu'en plus, tu as moins de monde et de temps.
Vous bossez dans quel boite pour que tout les serveurs soient tous sur la dernière version, pour ne pas avoir des tonnes d'autres trucs à faire ?
Parce que les clients dont j'entends parler, c'est migration à RHEL 7 2 ou 3 ans après la release, parfois certains envisagent passer à RHEL 6. C'est des serveurs encore en 12.04 ou 10.04 que les gens peuvent pas migrer rapidement, parce que tout à changer et y a pas de budget.
Y a aucun des admins qui est sur le projet à temps plein, et pire encore, aucun qui est uniquement contributeur à l'admin de l'infra.
Et même au delà de ça, tu regardes quand Gitlab a eu un gros souci, des gens ont dit "ça arrive à tous" (sur twitter) et ça a globalement été positif. Ici, c'est juste du fiel et du purin sur des bénévoles en sous effectif à cause du stress, pour un souci qui n'a pas eu lieu.
Mais c'est quoi comme ambiance de merde dans ce coin du logiciel libre ?
Au passage, pour avoir regarder le fonctionnement des dits bots qui se baladent (c'est pas dur, tu peux juste mettre un pauvre honeypot ssh, y en a des tonnes et c'est facile d'en écrire un avec twisted), la majorité des bots vont tentés d'exploiter des failles archi courantes.
Soit des mots de passes par défaut et/ou faibles (cas des bots ssh, genre mirai), soit des failles connus dans des softs classiques (style wordpress), soit shellshock.
Que je sache, rien de tout ça ne s'applique à ce serveur:
- c’était du mod_perl, on évite globalement shellshock via mod_cgi
- pas de wordpress dessus (que je me souvienne)
- le ssh est par clé uniquement dans mon souvenir
Donc sauf erreur de ma part et sur la base des bots que je voit sur mes serveurs, le risque est globalement faible.
Ensuite, tu as peut être sans doute d'autres infos qui te permettent d'être plus affirmatif que moi, auquel cas je suis sur que tu peux les partager pour faire avancer le débat de façon constructive.
La gestion d’une infrastructure c’est un métier, n’importe qui
ne peut pas le faire. Vu les commentaires, on est clairement
face à n’importe qui.
C'est assez hautain et puant comme commentaire, j'aurais honte de parler sans savoir à ta place.
L'équipe d'admin sys de Mageia au début, ç'était 10 personnes. Sur les 10, je compte 7 admins de profession (2 dans une université, 1 chez un telco, 2 dans 2 multinationals du secteur informatique bien connus).
Donc non, je pense pas qu'on est face à n'importe qui.
C'est pas le manque de compétence. C'est le manque de temps et de personne, vu qu'au fur et à mesure des années, 3 (ou plus) ont eu des gamins, 3 sont parti en burnout et/ou depressions (parfois pas à cause du projet) et parfois revenus, 3 ont changés de taf (et on arrêté le projet). Et comme tu dis, l'admin sys, c'est un métier, et personne n'est venu faire un métier gratuitement sur son temps libre pour aider (chose plus dur qu'être désobligeant envers les autres, je le conçoit).
C'est peut-être la le problème : ne pas avoir su s'arrêter avant
que ça devienne dangereux au niveau sécurité.
S’arrêter de faire quoi ?
S’arrêter de filer du temps gratos ?
S'arrêter de faire le travail en risquant de se faire insulter sur linuxfr ? Qu'est qui aurait du être arrêter ?
Je crois qu'il y a un problème de compréhension : le sujet
n'est pas que les bénévoles doivent être des esclaves, mais
qu'il font croire qu'ils font ce qu'il faut pour protéger un
minimum, le sujet est qu'il semble impossible de se dire "ok,
on n'a plus assez de monde, on ferme avant que ça casse".
Ça se voit quand même que tu as jamais bossé dans un projet d'envergure avec du monde, voir même fait de la gestion de risque. Deja, tu va pas dire "on ferme le projet, on a un serveur pas à jour", surtout quand, comme dit par Pascal, un plan pour la mise à jour est en cours. Peut être qu'envoyer chier le monde est trivial pour toi, mais c'est pas le cas de tout le monde. Donc oui, les gens vont pas arrêter quand il est trop tard, et surtout pour Mageia (j'ai pas besoin de parler de l'histoire de la distribution).
De surcroit, c'est quand "trop tard" ? Y a pas de moment exact pour ça
Pire, une fois que ça a été public, ça n'a pas été coupé dans > l'heure.
Ça a toujours été publique pour qui sait regarder. Et encore une fois, l'attente que les bénévoles doivent réagir dans l'heure et rapidement est une source de stress. Et le stress et le burnout dans le libre est un souci.
ça ce n'est pas la faute de ceux qui ont montré le problème.
Mais le souci est pas de signaler un problème.
Le souci, c'est de signaler un problème connu depuis longtemps et de croire qu'aller insulter les gens pour forcer la migration va aider.
Coquelicot-bleu a bien dit qu'ielle utilise pas la distribution, donc ielle n'a même pas l'excuse de faire ça pour son propre bénéfice. Les admins étaient déjà au courant. Il ne faut pas non plus prendre la profession pour des idiots, on sait exactement ce qui est pas à jour, on sait ce qui est risqué, la dette technique, on a ça en tête tout les jours.
Donc ce que ça va donner, c'est une migration potentiellement rushé, des attaques sur Linuxfr sur les gens qui font le travail, et sans doute un pas de plus vers le burn out pour eux.
Tout ça pour une attaque qui n'a pas eu lieu, pour un serveur qui n'est pas si critique que ce qu'il veut faire croire (et moi, je sais comment est architecturer le système, je sais ou sont les points faibles qu'on a pas pu renforcer de mon temps, vu que j'ai été un de ces architectes). Oui, ça aurait du être mis à jour plus tôt, mais "c'est la vie", surtout si les bénévoles sont pas des esclaves (parce que bon, dire "faut faire ça, et fait ça gratos et plus vite", ç'est quand même une forme de pression psychologique assez mauvaise).
Un serveur troué qui gère l'interface d'admin des comptes ainsi
que leurs clefs ssh et toi tu vois pas où est le problème ?
Le serveur est juste un client ldap élaboré. Donc si jamais tu prends le contrôle du dit serveur, tu va pas avoir plus de contrôle que si tu attaques le ldap directement. Tu va avoir en effet une vue sur ce qui se passe, mais c'est autre chose.
Au hasard ? Une petite modif dans le code de l'appli de
gestion de comptes utilisateurs pour logger les
logins/password, ne reste plus qu'à attendre qu'un admin se
connecte et le tour est joué
Puppet va reverter le changement (déploiement auto depuis git/svn), et/ou le signaler. Tu devrais pas faire tes attaques au hasard, ça a pas l'air de marcher dans la vraie vie.
Ok, on modifie la conf apache pour logger les données POST, et
voila.
Puppet va reverter le changement, et/ou le signaler (c'est le but de puppet).
Bien sur, tu peux couper puppet, mais dans ce cas, ça va lancer une alerte assez vite sur le monitoring pour dire que "tel client n'a plus puppet qui tourne"
Donc la fenêtre de tir est assez courte (grosso modo, puppet se lance toutes les heures), il faut que tu fasses une attaque et que dans l'heure, un des 5 ou 6 admins se connecte pour changer sa clé sur l'interface (et pas ldapvi).
Ou que tu attaques de façon plus spécifique pour pas te faire choper (ce qui est faisable, même si j'ai plus les détails en tête, j'ai tenté de fermer ça autant que possible).
Je ne dit pas que c'est impossible, mais on sort très clairement des attaques de script kiddies. De mon expérience (ie, à dealer avec des vraies attaques et à faire du forensic), puppet est déjà au delà des capacités des admins moyens (sinon, je pense qu'il y aurait eu plus de patch), et donc du script kiddie moyen. J'ai eu à dealer avec des serveurs compromis, et en général, la ligne de commande classique est souvent déjà au delà des capacités de l'attaquant lambda, comme n'importe qui qui a pu lire un .bash_history d'un serveur compromis ou d'un honeypot a pu le constater.
Soit tu tombes sur des gens motivés et avec des ressources, et c'est globalement foutu si tu as pas autant de ressources en face (une équipe legere d'attaquant, ça se chiffre dans les 2 millions par an, cf https://medium.com/@thegrugq/cyber-ignore-the-penetration-testers-900e76a49500 ). Soit tu va tomber sur des attaquants moins staffés, et en général, c'est des boulets qui vont faire du bruteforce classique. Il y a fort peu de cas entre les 2 (ou personne n'en parle, mais c'est un autre débat).
Donc si le but est de rajouter une backdoor, c'est infiniment plus sur et plus rapide de juste devenir packageur et de rajouter ça dans la distribution. Genre en changeant un tarball d'un soft utilisé partout mais pas signé (y en a un paquet). Ça ne serait pas pérenne, mais sans doute discret.
Ou voir même, de devenir admin. Il y a tellement besoin d'aide que je suis sur qu'une personne en 2 mois peut devenir root.
Et quand j'étais admin sur le projet, j'avais fini par abandonner l'idée de sécuriser quoi que ce soit contre moi même au vue du manque de ressources chroniques. Et encore une fois, mon expérience montre que c'est globalement pareil partout (vu que j'ai fini par faire de l'admin pour projet libre mon activité professionnel, parce que j'estime qu'il vaut mieux bosser pour corriger un problème que de chouiner sur linuxfr, ce qui n'est pas le cas de tout le monde).
sinon, pas compris l’intérêt de l'anti-spam en lecture.
C'est une feature de base de sympa. Personne n'a envoyé de patch pour la retirer (sur sympa, ou sur le dépôt puppet de mageia), et j'ai déjà eu asse de mal à faire passer sympa dans puppet à l'époque.
J'ai appris ceci dit que le travail pour une nouvelle interface est en cours (cf https://listes.renater.fr/sympa/arc/sympa-fr/2017-04/msg00000.html ), donc à défaut d'envoyer du code (je ne me fait plus d'espoir), tu peux sans doute aller ouvrir un bug (et c'est en français, donc pas de souci avec la langue).
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.
[^] # Re: Je pense que tu va pas aimer mes réponses
Posté par Misc (site web personnel) . En réponse au journal Votre rapport à l’anglais ?. Évalué à 5.
En effet, (pour ma defense, j'ai pas dormi de la nuit)
# Je pense que tu va pas aimer mes réponses
Posté par Misc (site web personnel) . En réponse au journal Votre rapport à l’anglais ?. Évalué à 5.
Il est bon. J'ai déjà donné des confs en Amérique du Nord, je fait des confcalls 3 fois par semaine dans la langue, je fait des jeux de mots pourris assez régulièrement. Je suis fatigué après une journée, mais moins qu'avant.
En pratiquant. D'abord, la lecture, ce que tu sembles deja réussir. Ensuite à l'écrire. Puis, à force de l'écouter (par exemple, des vidéos de conférence sur youtube) et de tenter de le parler, ça s'améliore. Le truc, c'est d'avoir des gens compréhensifs face à toi, et de persévérer.
Je sais que ç'est pas simple et c'était pas simple pour moi non plus. Je sais que les gens se sentent ridicule, qu'on se sent con à ne pas trouver ses mots, qu'on est frustré. Je parle bien anglais, mais je galère sur d'autres langues, donc je suis pas étranger à ce que tu vis.
J'ai appris l'anglais à l'école en 3eme langue. J'ai fait 4 mois à l'étranger dans une fac anglophone. J'ai aucun souvenir d'avoir eu des soucis, mais je ne doute pas que j'en ai eu. J'ai juste oublié, et ça finit par passer.
J'ai l'habitude. Mais oui, au début, c'était pas simple. On est passé à des videos conférence, ce qui permet déjà de voir qui parle, parce qu'en vidéoconférence audio uniquement, c'était horrible.
Non. Je bosse pour une boite US, les 3 gens entre moi et le PDG ont tous l'anglais US comme langue maternelle. Le PDG aussi. Et je pense plus de 75% de mon département.
Mon entretien d'embauche était en anglais.
Si je parlait pas anglais, j'aurais pas pu rentrer dans la boite il y a 6 ans. J'aurais sans doute eu du mal à parler à des gens sur les projets libres à l'époque y a 10 ans.
Non. Si tu détestes ça, tu as plusieurs autres choix. Tu peux prendre un film que tu aimes bien, que tu connais par coeur et le revoir, en anglais.
Tu peux regarder des vidéos de conférence sur youtube sur un sujet que tu aimes, même au ralenti, tu as le droit. Si tu piges pas un mot, tu as le droit d'arrêter. Tu as le droit de revenir en arrière, de demander à quelqu'un, de mettre les sous titres. De regarder que 5 minutes à la fois parce que tu es trop fatigué.
Mais ça, ça n'aide que pour la compréhension, ce qui est déjà bien, mais ça va pas t'aider à surmonter ta peur.
Pour parler, bah, faut se lancer.
Tu peux aller à des groupes de discussions (y en sur meetup.com), tu peux (sous réserve de pognon/liberté) aller t'expatrier un temps. Tu peux demander des cours dans la cadre du droit à la formation. Tu peux utiliser duolingo ou autre applications. Tu peux faire un karaoké. Tu peux parler avec quelqu'un qui parle anglais pour t'entrainer.
Mais c'est comme tout, c'est qu'une question de pratique. Crois moi, ça s'améliore à la fin. Pas forcément au bout d'une semaine, ni même d'un mois, mais ça s'améliore.
Et non, tu n'es pas seul. Même si c'est pas mon cas, je connais plein de gens qui ont du mal avec l'anglais.
[^] # Re: Le noeud du problème
Posté par Misc (site web personnel) . En réponse au journal Retour d'expérience d'une petite administration sous linux depuis 8 ans qui fait marche arrière. Évalué à 4.
C'est marrant, parce qu'il y a une demande pour avoir du matos qui marche sous Linux. Et c'est quoi du matos qui marche sous Linux si c'est pas du matos certifié ?
Il y a une demande, mais pas suffisante pour payer ça (parce que des machines certifiés desktop, y a eu des tentatives d'aussi loin que je me souvienne, Mandrakesoft en a eu, Red hat en a eu, Suse en a eu, Canonical en a eu, et en a encore via Dell). Et pourtant, j'en croise très rarement. Encore une fois, la demande ne suit pas les moyens, parce que quand les gens disent "je veux tel truc", c'est "je veux tel truc mais sans payer trop cher" (ce que je peux comprendre, l'argent pousse pas sur les arbres).
Il faut surtout avoir la logistique qui va avec. Il y a 15 ans, c'était passer par la Fnac, Surcouf, etc. Il y a 5 ans, c’était ce que Mozilla a tenté avec Firefox OS. On sait comment ça s'est fini hélas, et c'est pas faute d'avoir tenté de faire au mieux de la part des acteurs du libre.
Aujourd'hui, les seules qui se débrouillent sur le marché, c'est des petites boites comme system76 ou purism. Et je pense principalement parce qu'elles ont du matériel reconditionné et pas besoin de magasin physique (merci le web).
Et quand on regarde ce qui est arrivé, ceux qui ont réussi à mettre du Linux pour le grand publique, c'est Google. Et ils ont réussi en créant un écosystème de zéro, mais surtout en créant un écosystème proprio et générateur d'argent. Personnellement, j’abhorre Android et son écosystème (parce que grandement proprio, parce que grandement non maintenu, parce que rempli de mouchard, etc, etc), mais je reconnait qu'ils ont rendu ça attractif d'une façon qui n'arriverais sans doute pas sur le bureau pour nos distributions classiques.
[^] # Re: Le noeud du problème
Posté par Misc (site web personnel) . En réponse au journal Retour d'expérience d'une petite administration sous linux depuis 8 ans qui fait marche arrière. Évalué à 7.
Je ne dit pas que les moyens ne sont pas mis dans le cas présenté, et pour être franc, je ne parle même pas de ce cas en particulier. Mais mettre les moyens ne suffit pas toujours, ni même ne décrit grand chose, car mettre les moyens ne dit pas "mettre les moyens suffisant".
Tu peux mettre les moyens pour faire marcher quelque chose, ça veut pas dire que ça va améliorer les choses pour tout le monde. C'est typiquement tout le souci d'avoir une version custom d'une distribution Linux. Les moyens sont mis pour que ça marche chez l'utilisateur final, en ayant des admins pour que la plateforme marche, en faisant des backports et des modifs. Mais ça rends rarement la migration et/ou le support des autres plus simples et moins couteux. Donc ça fait pas avancer le schmilblick.
Pas vraiment, y a des programmes de certifs pour un certains nombres de distributions avec un acteur commercial (exemple, RHEL, SLES, et Ubuntu ). Ça reste minoritaire, mais pas parce que personne ne donne de logo.
ce qui est mon point. On vends le truc comme étant pas cher, ben y a pas d'argent qui rentre.
Encore une fois, il y a des distributions qui vont faire des choix. Mais curieusement, les gens convaincu du libre ne veulent pas de ça, voir boude l'idée. Juste sur les environnement de bureau, tout le monde veut avoir son favori dans chaque distribution. Et tout le monde veut tout avoir à jour, mais stable. Et gratos. Avec des changements, mais sans avoir à changer la doc et/ou changer l'UX. Et j'ai dit sans bugs ?
Parce que les examples de desktop qu'on donne sont surtout des examples ou l'argent ne remonte pas vers les éditeurs.
Prenons les divers projets phares de migration sur Linux sur le desktop.
L'assemblée nationale en France, c'est Linagora qui a eu le marché à l'époque, la boite a mis 1 personne qui a fait un dérivé de Kubuntu, et pas un centime n'est sans rien payer à Canonical que je sache.
La province autonome d'Estramadura, ils sont parti sur un dérivé de Debian (GNU/Linex)
La ville de Munich, ils sont parti sur une distro custom, encore une Debian.
3 cas, 3 fois ou l'argent n'a pas été filé à un éditeur, avec un intermédiaire qui a du se financer pas mal. Quand l'éditeur reverse son obole au libre, ça donne un secteur sain, mais en général, on te file des thunes pour un service, et ce qui pourrait aller au logiciel libre, c'est ce qui reste. Pire encore, vu qu'on parle à chaque fois d'une distro custom, il y a pas de partage des améliorations, cf ce que j'ai dit plus haut.
Ensuite, y en a qui font les choses proprement, par exemple Google. L'entreprise a une distro custom (surprise), mais payent (ou payaient) Canonical pour le support. Et c'est plus parce que Google a du pognon à perdre et pour financer le libre de façon indirect qu'autre chose, AMHA.
Et pourtant, des clients sur le desktop, y en a. La division Desktop de RH est auto suffisante si j'en croit les gens qui bossent la bas (e.g., ça rapporte assez pour embaucher du monde et faire des choses). Et c'est pas non plus rare d'avoir des stations de travail dans certains secteurs spécialisés (exemple, Pixar a des stations de travail sous RHEL, ma fac à Montreal en avait, l'université de Caroline du Nord aussi) si j'en croit une rapide recherche sur le web (exemple: https://www.reddit.com/r/linux/comments/71mx9s/how_many_of_you_actually_use_red_hat_enterprise/ ). Et pas que RH, je sais que Qualcomm avait des postes sous Ubuntu, et je suis sur que quelqu'un peut me donner des examples de client sous SLES pour le desktop.
Mais la différence entre les examples que j'ai donné au début et ceux la, c'est qu'il s'agit de postes bureautiques vs des stations de travail. Et quand je dit "station de travail", je parle de trucs qui étaient sous Unix il y a 20 ou 30 ans (Irix, Solaris), dans des secteurs ou on s'attend à dépenser de l'argent pour ça.
Pas sur le poste bureautique moyen.
# Le noeud du problème
Posté par Misc (site web personnel) . En réponse au journal Retour d'expérience d'une petite administration sous linux depuis 8 ans qui fait marche arrière. Évalué à 9.
Je pense que c'est le noeud du problème. On vends l'idée d'utiliser Linux pour économiser de l'argent, ce qui aboutit juste à un secteur économique anémique, vu que les gens dépensent moins pour ça la ou je pense qu'il faut dépenser plus.
Je comprends bien que le prix soit un levier puissant, mais sur le long terme, ça n'aide pas à atteindre un équilibre.
[^] # Re: Abandon de GlusterFS ?
Posté par Misc (site web personnel) . En réponse au journal Retour d'expérience d'une petite administration sous linux depuis 8 ans qui fait marche arrière. Évalué à 2.
C'est pas juste Glusterfs, c'est les systèmes de fichiers distribués et réseaux. Lire 100G par fichier de 1k, ça implique d elire une tonne de meta données et de faire une tone d'aller retour. Lire 100G d'un coup, c'est juste ça, 100G de transfert.
Ensuite, il y a du tuning à faire sans doute pour améliorer les choses, mais il y a des moments ou la latence réseau est visible, et le cas des petits fichiers en fait parti.
[^] # Re: on vit une époque formidable
Posté par Misc (site web personnel) . En réponse au journal Comment bloquer 280M de dollars en éther . Évalué à 3.
Oui, ça viendrait à personne d'utiliser des arbres de Merkel pour des choses comme la gestion du code source ou ce genre de trucs au lieu d'une base de données.
[^] # Re: on vit une époque formidable
Posté par Misc (site web personnel) . En réponse au journal Comment bloquer 280M de dollars en éther . Évalué à 3.
Merci pour l'explication.
J'ajouterais qu'il existe un outil pour vérifier ça:
https://github.com/b-mueller/mythril
[^] # Re: on vit une époque formidable
Posté par Misc (site web personnel) . En réponse au journal Comment bloquer 280M de dollars en éther . Évalué à 3. Dernière modification le 09 novembre 2017 à 11:12.
Ce qui en soit est pas si différent du type de déploiement qu'on voit pour de l'embarqu
^WIOT. Et dire qu'on peut pas mettre à jour, c'est aussi un peu trompeur. Tu pourrais si tu avais le controle de la blockchain entiére. C'est certes sans doute impossible pour une blockchain publique, mais je suis sur qu'il existe des applications ou tu as ta propre blockchain privé et ou c'est faisable, ce qui limite quand même les risques (un peu comme faire un git push -f, ça passe mieux quand tu es seul)[^] # Re: ça manque de données
Posté par Misc (site web personnel) . En réponse au journal FAI associatif / FDN / Hébergement et stockage. Évalué à 2.
Le RAID, j'ai pas tendance à voir ça comme une sécurité des données plus que s'assurer de la disponibilité et que l'uptime ne prends pas un coup si un disque tombe (en partant du principe que tu as un niveau de raid différent de 0). Parce que le RAID sécurise pas vraiment contre un effaçage par erreur ou contre un bug du FS :/
En fait, j'ai vraiment tendance à ne pas aimer qu'on parle de sécurisation sans dire "contre quoi", parce que ç'est indispensable pour savoir ce qui manque, surtout si c'est à destination des membres, qui vont pas forcément avoir le réflexe de penser "ok, qu'est ce qui se passe si tel truc arrive".
Plus simple oui, mais je suis pas sur que ça marche à 100%. Encore une fois, tu peux avoir le disque dans un état non consistant. Et ça, c'est quand tu as pas des données sur plusieurs disques (exemple, un serveur sql partagé et X serveurs webs avec des applis différentes), parce que ça devient vite compliqué Ensuite, je donne le pire cas possible, il est possible que ça marche suffisamment bien et que tu puisses corriger à la main le reste du temps (e.g, aller tripoter dans la DB si besoin), donc je suppose qu'il ne faut pas faire une usine à gaz.
[^] # Re: Glusterfs / Proxmox
Posté par Misc (site web personnel) . En réponse au journal FAI associatif / FDN / Hébergement et stockage. Évalué à 2.
7 serveurs physiques, ça me parait un chouia trop. Tu peux t'en sortir avec moins si tu mets les OSD et les moniteurs sur les mêmes machines, en partant du principe que tu as dimensionné ça de façon à ce que ça passe (genre, avoir un disque, asse de ram et un CPU par OSD, et donc un CPU et assez de ram pour le moniteur, avec "assez" documenté sur ceph.com).
Ensuite, ça dépend aussi de la topologie réseau que tu va mettre des patterns d'accès, de la volumétrie, des perfs que tu veux avoir.
[^] # Re: Glusterfs / Proxmox
Posté par Misc (site web personnel) . En réponse au journal FAI associatif / FDN / Hébergement et stockage. Évalué à 2.
Il suffit de répliquer les images de VM stocké sur le disque.
# ça manque de données
Posté par Misc (site web personnel) . En réponse au journal FAI associatif / FDN / Hébergement et stockage. Évalué à 4.
Le draft manque AMHA d'info.
Par exemple, ça parle de réplication, mais est ce que l'idée est d'avoir une réplication en temps réel (et donc synchrone) auquel cas les performances vont chuter si tu fait ça sur un site distant, ou d'avoir des trucs asynchrones et de la magie pour revenir quand ça explose ?
Il n'y a pas spécialement de discussion sur la volumétrie non plus ou la question du lien entre les sites.
Le type de données va aussi importer. L'utilisation de GlusterFS pour stocker des images de VM fait parti des cas supportés par le projet (vu que c'est des gros fichiers, ç'est assez performant), et le projet ovirt le supporte. Mais de la même façon, des gens placent le stockage en mode bloc dans Ceph.
Mais si le but est d'avoir des machines dont tu fait des snapshot, je pense que tu peux pas éviter d'aller dans la VM et faire des choses pour que les données sur le disque soit cohérentes.
J'ai par exemple du mal à voir comment une synchro des blocs ne va pas corrompre une base de données et une appli web si ça pête au mauvais moment, vu que c'est rarement atomique (sauf à tout mettre dans la base de données, et à avoir des transactions, mais je pense que pas grand monde vérifie ça, et qu'à choisir entre une appli qui va exploser sous un cas critique, et pas d'appli, les gens prennent l'appli quand même).
Du coup, si tu fait la redondance au niveau au dessus, tu as moins besoin au niveau en dessous.
Donc les besoins vont dépendre des applis. Est ce qu'il faut avoir de la HA automatique, ou remonter rapidement suffit ? Comment le systéme va devoir se débrouillé en mode dégradé ?
Pour reprendre l'appli d'exemple de toute à l'heure, une solution de stockage classique avec une base SQL répliqué suffirait, avec des frontends sans état, pas besoin de sortir des trucs complexes (pour peu que les VMs soit identiques)
Et sinon, on est en 2017, les archis à base de conteneurs ont le vent en poupe, et ont le bon gout de pousser à séparer données et codes, ce qui permet aussi de se focaliser sur ce qui AMHA importe, les données. Je dit pas que c'est une bonne idée, mais je pense que c'est pas déconnant de regarder. Et pas regarder docker tout nu, plus des choses comme kubernetes/openshift ou mesos, avec idéalement une stack supporté.
Et la partie "pas de java" me parait quand même restrictive et sans doute mal exprimé. Parce que je suis sur que pour certaines choses, y a sans doute d'autres languages qui vont faire pire que java (cough golang et rust pour du statique, ruby pour tirer 5T de deps), donc je suis sur qu'il y a plus précis comme demande.
# Des goodies tout fait
Posté par Misc (site web personnel) . En réponse à la dépêche Updates-warner : pour être alerté d’une modification de ressource Web. Évalué à 6.
Je sais déjà ce que tu peux offrir comme goodies:
Des brosses, pour dire "c'est une updates-warner brosse".
[^] # Re: A ceux qui critiquent....
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.
Arrête ton char, tu sais très bien que dans l'IT, tu as toujours un delta énorme entre ce que tu voudrais faire, et ce que tu peux faire dans les temps.
Et la, c'est pareil, sauf qu'en plus, tu as moins de monde et de temps.
Vous bossez dans quel boite pour que tout les serveurs soient tous sur la dernière version, pour ne pas avoir des tonnes d'autres trucs à faire ?
Parce que les clients dont j'entends parler, c'est migration à RHEL 7 2 ou 3 ans après la release, parfois certains envisagent passer à RHEL 6. C'est des serveurs encore en 12.04 ou 10.04 que les gens peuvent pas migrer rapidement, parce que tout à changer et y a pas de budget.
Y a aucun des admins qui est sur le projet à temps plein, et pire encore, aucun qui est uniquement contributeur à l'admin de l'infra.
Et même au delà de ça, tu regardes quand Gitlab a eu un gros souci, des gens ont dit "ça arrive à tous" (sur twitter) et ça a globalement été positif. Ici, c'est juste du fiel et du purin sur des bénévoles en sous effectif à cause du stress, pour un souci qui n'a pas eu lieu.
Mais c'est quoi comme ambiance de merde dans ce coin du logiciel libre ?
[^] # 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é à 4.
Au passage, pour avoir regarder le fonctionnement des dits bots qui se baladent (c'est pas dur, tu peux juste mettre un pauvre honeypot ssh, y en a des tonnes et c'est facile d'en écrire un avec twisted), la majorité des bots vont tentés d'exploiter des failles archi courantes.
Soit des mots de passes par défaut et/ou faibles (cas des bots ssh, genre mirai), soit des failles connus dans des softs classiques (style wordpress), soit shellshock.
Que je sache, rien de tout ça ne s'applique à ce serveur:
- c’était du mod_perl, on évite globalement shellshock via mod_cgi
- pas de wordpress dessus (que je me souvienne)
- le ssh est par clé uniquement dans mon souvenir
Donc sauf erreur de ma part et sur la base des bots que je voit sur mes serveurs, le risque est globalement faible.
Ensuite, tu as peut être sans doute d'autres infos qui te permettent d'être plus affirmatif que moi, auquel cas je suis sur que tu peux les partager pour faire avancer le débat de façon constructive.
[^] # Re: A ceux qui critiquent....
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.
C'est assez hautain et puant comme commentaire, j'aurais honte de parler sans savoir à ta place.
L'équipe d'admin sys de Mageia au début, ç'était 10 personnes. Sur les 10, je compte 7 admins de profession (2 dans une université, 1 chez un telco, 2 dans 2 multinationals du secteur informatique bien connus).
Donc non, je pense pas qu'on est face à n'importe qui.
C'est pas le manque de compétence. C'est le manque de temps et de personne, vu qu'au fur et à mesure des années, 3 (ou plus) ont eu des gamins, 3 sont parti en burnout et/ou depressions (parfois pas à cause du projet) et parfois revenus, 3 ont changés de taf (et on arrêté le projet). Et comme tu dis, l'admin sys, c'est un métier, et personne n'est venu faire un métier gratuitement sur son temps libre pour aider (chose plus dur qu'être désobligeant envers les autres, je le conçoit).
[^] # 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é à 9.
S’arrêter de faire quoi ?
S’arrêter de filer du temps gratos ?
S'arrêter de faire le travail en risquant de se faire insulter sur linuxfr ? Qu'est qui aurait du être arrêter ?
Ça se voit quand même que tu as jamais bossé dans un projet d'envergure avec du monde, voir même fait de la gestion de risque. Deja, tu va pas dire "on ferme le projet, on a un serveur pas à jour", surtout quand, comme dit par Pascal, un plan pour la mise à jour est en cours. Peut être qu'envoyer chier le monde est trivial pour toi, mais c'est pas le cas de tout le monde. Donc oui, les gens vont pas arrêter quand il est trop tard, et surtout pour Mageia (j'ai pas besoin de parler de l'histoire de la distribution).
De surcroit, c'est quand "trop tard" ? Y a pas de moment exact pour ça
Ça a toujours été publique pour qui sait regarder. Et encore une fois, l'attente que les bénévoles doivent réagir dans l'heure et rapidement est une source de stress. Et le stress et le burnout dans le libre est un souci.
Mais le souci est pas de signaler un problème.
Le souci, c'est de signaler un problème connu depuis longtemps et de croire qu'aller insulter les gens pour forcer la migration va aider.
Coquelicot-bleu a bien dit qu'ielle utilise pas la distribution, donc ielle n'a même pas l'excuse de faire ça pour son propre bénéfice. Les admins étaient déjà au courant. Il ne faut pas non plus prendre la profession pour des idiots, on sait exactement ce qui est pas à jour, on sait ce qui est risqué, la dette technique, on a ça en tête tout les jours.
Donc ce que ça va donner, c'est une migration potentiellement rushé, des attaques sur Linuxfr sur les gens qui font le travail, et sans doute un pas de plus vers le burn out pour eux.
Tout ça pour une attaque qui n'a pas eu lieu, pour un serveur qui n'est pas si critique que ce qu'il veut faire croire (et moi, je sais comment est architecturer le système, je sais ou sont les points faibles qu'on a pas pu renforcer de mon temps, vu que j'ai été un de ces architectes). Oui, ça aurait du être mis à jour plus tôt, mais "c'est la vie", surtout si les bénévoles sont pas des esclaves (parce que bon, dire "faut faire ça, et fait ça gratos et plus vite", ç'est quand même une forme de pression psychologique assez mauvaise).
[^] # Re: Tu ne sais pas
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.
Le serveur est juste un client ldap élaboré. Donc si jamais tu prends le contrôle du dit serveur, tu va pas avoir plus de contrôle que si tu attaques le ldap directement. Tu va avoir en effet une vue sur ce qui se passe, mais c'est autre chose.
Puppet va reverter le changement (déploiement auto depuis git/svn), et/ou le signaler. Tu devrais pas faire tes attaques au hasard, ça a pas l'air de marcher dans la vraie vie.
Puppet va reverter le changement, et/ou le signaler (c'est le but de puppet).
Bien sur, tu peux couper puppet, mais dans ce cas, ça va lancer une alerte assez vite sur le monitoring pour dire que "tel client n'a plus puppet qui tourne"
Donc la fenêtre de tir est assez courte (grosso modo, puppet se lance toutes les heures), il faut que tu fasses une attaque et que dans l'heure, un des 5 ou 6 admins se connecte pour changer sa clé sur l'interface (et pas ldapvi).
Ou que tu attaques de façon plus spécifique pour pas te faire choper (ce qui est faisable, même si j'ai plus les détails en tête, j'ai tenté de fermer ça autant que possible).
Je ne dit pas que c'est impossible, mais on sort très clairement des attaques de script kiddies. De mon expérience (ie, à dealer avec des vraies attaques et à faire du forensic), puppet est déjà au delà des capacités des admins moyens (sinon, je pense qu'il y aurait eu plus de patch), et donc du script kiddie moyen. J'ai eu à dealer avec des serveurs compromis, et en général, la ligne de commande classique est souvent déjà au delà des capacités de l'attaquant lambda, comme n'importe qui qui a pu lire un .bash_history d'un serveur compromis ou d'un honeypot a pu le constater.
Soit tu tombes sur des gens motivés et avec des ressources, et c'est globalement foutu si tu as pas autant de ressources en face (une équipe legere d'attaquant, ça se chiffre dans les 2 millions par an, cf https://medium.com/@thegrugq/cyber-ignore-the-penetration-testers-900e76a49500 ). Soit tu va tomber sur des attaquants moins staffés, et en général, c'est des boulets qui vont faire du bruteforce classique. Il y a fort peu de cas entre les 2 (ou personne n'en parle, mais c'est un autre débat).
Donc si le but est de rajouter une backdoor, c'est infiniment plus sur et plus rapide de juste devenir packageur et de rajouter ça dans la distribution. Genre en changeant un tarball d'un soft utilisé partout mais pas signé (y en a un paquet). Ça ne serait pas pérenne, mais sans doute discret.
Ou voir même, de devenir admin. Il y a tellement besoin d'aide que je suis sur qu'une personne en 2 mois peut devenir root.
Et quand j'étais admin sur le projet, j'avais fini par abandonner l'idée de sécuriser quoi que ce soit contre moi même au vue du manque de ressources chroniques. Et encore une fois, mon expérience montre que c'est globalement pareil partout (vu que j'ai fini par faire de l'admin pour projet libre mon activité professionnel, parce que j'estime qu'il vaut mieux bosser pour corriger un problème que de chouiner sur linuxfr, ce qui n'est pas le cas de tout le monde).
[^] # Re: Ha, ouais.
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é à 6.
C'est une feature de base de sympa. Personne n'a envoyé de patch pour la retirer (sur sympa, ou sur le dépôt puppet de mageia), et j'ai déjà eu asse de mal à faire passer sympa dans puppet à l'époque.
J'ai appris ceci dit que le travail pour une nouvelle interface est en cours (cf https://listes.renater.fr/sympa/arc/sympa-fr/2017-04/msg00000.html ), donc à défaut d'envoyer du code (je ne me fait plus d'espoir), tu peux sans doute aller ouvrir un bug (et c'est en français, donc pas de souci avec la langue).
[^] # 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é à 5.
Surtout pour un compte ouvert hier juste pour poster ça.
[^] # 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.
Euh non, ça va être corrigé grâce aux gens qui font le taf.
Encore une fois, on se retrouve à masquer le travail des admins, faut pas s'étonner que les gens se découragent.
[^] # 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.