#prologin-staff mysql/php/drupal/

gistfile1.txt

20:39 <zopieux> seirl: on a pas besoin du mysql pour autre chose que le drupal ?
20:39 <seirl> non
20:41 <Bruce_> le drupal est encore up ? :D
20:41 <seirl> oui
20:41 <seirl> oldsite.prologin.org
20:41 <zopieux> halfr propose de le cloisonner dans une VM et j'approuve
20:41 <zopieux> on devrait pouvoir supprimer apache et php
20:41 <seirl> pourquoi vous voulez spawn des VM pour n'importe quoi
20:41 <zopieux> parce que drupal 
20:42 <seirl> non mais ok mais faites un conteneur alors
20:42 <zopieux> "gnagna c'est sous mot de passe"
20:42 <zopieux> un conteneur, genre tu veux docker ? ou une merde à la main avec nspawn ?
20:42 <seirl> n'importe quoi qui prenne pas une quantité fixe de ram pour rien et qui soit pas infernal à manager
20:47 <Oxian> on a encore besoin de ce drupal ?!
20:48 <seirl> moi je trouve ça rigolo
20:49 <Oxian> moi beaucoup moins vu sa date de dernière mise à jour :s
20:49 <seirl> c'est quoi le problème ? 
20:50 <Oxian> ils ont sorti une énorme alerte, CVSS à 9 ou 10 de mémoire, y'a 15 jours. Après, si c'est derrière htaccess pourquoi pas, mais faut pas se louper et l'enlever un jour
20:51 <seirl> oui enfin si tu pars du principe "les gens peuvent faire de la merde avec la conf nginx", y'a pas que le drupal qui est problématique
20:51 <Oxian> justement, peut-être pas la peine de se rajouter des composants obsolètes
20:53 <seirl> je suis pas du tout d'accord avec cette façon d'approcher la sécurité
20:54 <Oxian> chic, un débat sur mon domaine de compétences. Je t'écoute :)
20:55 <seirl> bah, rien, je trouve ça juste débile de rajouter des couches de sécurité random parce que la vraie sécurité a des chances de rater
20:56 <Oxian> ??? qui parle de rajouter ?
20:56 <seirl> si le thread model c'est "un débile peut toucher à la conf nginx et leak des données", ce qu'il faut renforcer c'est la sécurité de la conf nginx
20:56 <seirl> pas butcher des trucs qu'elle protège en dessous au cas où
20:56 <Oxian> ah je vois. Défense périmétrique contre défense en profondeur
20:57 <Oxian> j'ai peur que ça n'ait déjà été tranché il y a un moment
20:57 <Oxian> ma position est complémentaire bien que légèrement différente
20:58 <Oxian> fermer tout ce qui n'est pas utile, sécuriser tout le reste. Renforcer la protection de la conf nginx ? très bien. Conserver un soft obsolète et troué de manière avérée et grave, just for fun, moins bien
20:58 <halfr> ouais alors mon approche c'était plutôt de bouger le site comme il est dans un endroit ou il pourra continuer à exister en compagnie de toutes les plus belles failles de sécurité du monde
20:59 <halfr> s/comme il est/pour le mettre/ 
20:59 <seirl> Oxian: mec, si quelqu'un fait de la merde avec la conf nginx, il peut juste changer un path et toutes les données personnelles de tous les candidats, y compris ceux qui ont supprimé leur compte, sont publiques avec un index sur la page d'accueil de prologin.org
20:59 <Oxian> c'est une merde différente, tu mixes tout
20:59 <seirl> est-ce que c'est pour ça qu'on devrait exporter nos backups sur un serveur différent et les rm ensuite ?
20:59 <seirl> non, parce que ce qui est important c'est les layers de sécurité avant "quelqu'un fait de la merde avec la conf nginx"
20:59 <Oxian> c'est une bonne mesure issue de ISO27002, oui :)
21:00 <halfr> dans une VM bien protégée des interwebs qu'on ne mettra plus jamais à jour 
21:00 <seirl> Oxian: si tu commences à citer des normes ISO je pense qu'on a pas besoin de continuer cette conversation :D
21:00 <Oxian> seirl: ah ? c'est intéressant comme point de vue ! pourquoi ?
21:00 <seirl> halfr: avoir des VM idle ça a un cout en ram
21:01 <halfr> qui est... ridicule ?
21:01 <seirl> si tu veux isoler un musée prologin, je préfère faire ça dans un conteneur
21:01 <seirl> c'est aussi chiant à manager de façon générale vu que t'as pas un fs shared
21:01 <halfr> dont on a... pas besoin ?
21:02 <seirl> mais pourquoi on aurait besoin d'une VM ? c'est dans l'autre sens que je raisonne
21:02 <halfr> on peut même freeze la VM sur le disque et l'allumer le jour où quelqu'un veut visiter le musée
21:03 <multun>  -- halfr, voix de la raison
21:03 <halfr> spawn une VM sur rosa c'est immédiat avec virt-install, alors qu'on a aucun conteneur sur pour l'instant
21:03 <seirl> oui, et on pourrait changer ça
21:04 <halfr> on gagnerait quoi ? 
21:04 <seirl> on a déjà teardown plusieurs VM parce qu'elles étaient chiantes et qu'elles prenaient de la ram
21:04 <halfr> on est pas contraint en ressources, on peut se permettre d'avoir l'overhead
21:04 <multun> seirl: si ta vm run pas elle prend pas de ram
21:04 <seirl> si on spawn une nouvelle VM à chaque fois que quelqu'un veut installer un truc, on va vite être limité en ressources
21:04 <seirl> multun: sauf que je veux qu'elle run
21:05 <multun> pourquoi ?
21:05 <seirl> parce que j'utilise oldsite.prologin.org ?
21:05 <multun> ah
21:05 <halfr> là on peut avoir deux fois plus de VM qu'actuellement sans soucis
21:08 <seirl> je comprends pas l'obsession avec les VM alors que c'est objectivement plus chiant à utiliser/manager/monitorer/observer/...
21:08 <halfr> qu'est-ce qui te gènes ?
21:08 <seirl> Oxian: contre proposition, je clone toute la base de données de oldsite.prologin.org en local chez moi avec les données candidats et je l'utilise depuis mon ordi
21:08 <seirl> t'en penses quoi 
21:09 <Oxian> que les risques changent
21:09 <seirl> c'était une blague
21:09 <halfr> parce que ça se comporte quand même vachement comme un conteneur pour utiliser/manager/monitorer/observer
21:10 <seirl> halfr: si j'ai un truc que je veux backup régulièrement, j'ai pas besoin de scp, je peux juste le copier coté host
21:10 <halfr> NOPE
21:10 <seirl> j'ai pas besoin d'avoir un réseau qui fonctionne pour changer de la config
21:10 <halfr> pas avec les namepsaces users 
21:10 <seirl> personne utilise les namespaces users et je compte pas commencer
21:10 <halfr> t'as toujours du réseau 
21:10 <halfr> et si t'en a pas ton fallback est exactement le même, à savoir un tty
21:11 <halfr> que tu peux avoir avec 'virsh console' ou 'systemd-run'
21:11 <seirl> ouais enfin entre aller sur le tty avec un machinectl et avec une console virtuelle, euh
21:11 <halfr> virsh console c'est une vraie console
21:12 <halfr> je viens de l'utiliser pour debug buildbot
21:12 <halfr> genre je m'y suis connecté depuis mon ssh
21:12 <halfr> vraie console == un tty unix, pas l'émulation graphique
21:13 <seirl> nan mais quand même c'est complètement incomparable
21:13 <seirl> aussi, lol manager ses tailles de partition
21:14 <seirl> (lol manager son quota CPU ou quoi que ce soit d'autre en fait)
21:14 <halfr> disque dynamiquement alloué, next remarque please
21:14 <seirl> oui, et une fois que tu l'as rempli ?
21:14 <seirl> et puis en plus c'est une grosse blague "disque dynamiquement alloué", tu sais très bien que ça peut que tendre vers un truc 100% rempli
21:14 <halfr> tu peux allouer plus que ton disque physique, à ce moment là c'est ton disque physique le problème
21:15 <halfr> rappel : la VM dont on parle sera freeze dans le temps, pas queestion d'update ou d'avoir plus de 4MB de log par an
21:15 <seirl> oui, mais je dis pas que ce serait difficile avec une VM
21:16 <seirl> je dis que rien ne justifie une VM et qu'il y a suffisamment de complications pour qu'il faille avoir des justifications pour avoir une VM à la place d'un conteneur et pas l'inverse
21:16 <seirl> d'ailleurs je serais très content de passer buildbot dans un conteneur aussi
21:17 <seirl> (et en profiter pour changer la façon dont on utilise buildbot car lol)
21:19 <halfr> bah oui les conteneurs c'est la vie j'entends bien, mais on a décidé d'utiliser des VMs sur rosa parce que les technos de conteneurs sortent à peine de l'âge des cavernes
21:19 <seirl> nan mais users et camisole ça semble bien d'utiliser des VMs pour ça par exemple
21:19 <seirl> mais quand le but c'est de faire tourner genre quelques programmes dans un environnement séparé, c'est useless
21:20 <seirl> tiens sinon vu qu'on est sous github depuis cette année
21:20 <seirl> faudrait faire un build travis pour stechec2 et les jeux 
21:22 <halfr> dans notre cas étant donné qu'on a déjà des VM je préfères perdre un des ressources (lol), plutôt qu'investir à supporter deux technos d'isolation qui ont un but quasi égal
21:26 <seirl> dans notre cas étant donné qu'on a déjà un site qui tourne sur le host je préfère ne rien faire plutôt qu'investir du temps à supporter une VM en plus qui va nécessiter de rajouter du monitoring, du nat, des hostnames et autre dans un but quasi égal :}
21:26 <seirl> si le but c'est de pas se faire chier, y'a pas besoin d'y toucher
21:26 <halfr> mon point : ça coûte beaucoup moins chère de spawn un VM et ne plus y toucher, plutôt qu'avoir un mysql ouvert sur le monde sur rosa
21:27 <seirl> on peut faire écouter mysql sur un socket unix avec les bonnes permissions si tu veux
21:27 <halfr> ah super, je vais faire ça DANS LA NOUVELLE VM 
21:27 <halfr> :)
21:28 <zopieux> seirl: y'a pas besoin de tant de ram que ça
21:28 <zopieux> si ?
21:28 <multun> en effet, 1) on s'en branle 2) ça coûte que dalle
21:29 <halfr> si on veut avoir 100% du dom0 dans ansible, il faut drop les services mineurs et pas à jour comme oldiste
21:29 <halfr> oldsite*
21:29 <seirl> zopieux: bah, tu mets autant de ram que tu veux, mais plus t'en mets et moins t'en as dans le host
21:29 <seirl> avec un conteneur tu partages la ram
21:29 <halfr> https://www.linux-kvm.org/page/Projects/auto-ballooning lalala
21:29 <seirl> halfr: ouais, et on peut aussi utiliser des VM que quand strictement nécessaire et ça nous épargnera plein de soucis relous
21:30 <seirl> oui oui je connais ces projets
21:30 <halfr> seirl: commme ?
21:30 <halfr> y'a quoi comme problème
21:30 <Bruce_> bon alors 
21:30 <seirl> j'en ai listé plein et je peux continuer
21:30 <halfr> d'expérience j'ai plus ragé contre le conteneurs que le VMs oldschool
21:30 <Bruce_> vous tournez en rond.
21:30 <seirl> le nat à respawner
21:30 <halfr> aucune n'est vraiment soutenable imho 
21:31 <seirl> Bruce_: t'es pas obligé de participer !
21:31 <multun> Bruce_: c'est le but, c'est un marathon
21:31 <Bruce_> actuellement je voisun site utilisé par peu de gens, avec des éventuelles failles qui peuvent exposer le derrière, ça ne me semble pas con de passer le vieux site dans une VM.
21:31 <Bruce_> on a 32G sur rosa avec 13G libres actuellement, 1G pour une vm avec le drupal ça suffit non ?
21:31 <seirl> Bruce_: ... qu'est-ce que ça change niveau sécurité de mettre le vieux site dans une VM ?
21:32 <multun> un chouilla, pas de masses
21:32 <seirl> si quelqu'un arrive à le pown il aura toujours accès à tous les données candidats 
21:32 <halfr> je viens de regarder on a jamais vraiment conf le nat de libvirt, ça marche 
21:32 <seirl> est-ce qu'on pourrait arrêter de voir oldsite comme un problème de sécurité ? la seule question qu'on se pose c'est un problème "devops" là, osef du reste
21:33 <halfr> tandis qu'avec un conteneur on devrait soit share le nic, soit faire un subnet pour les containers, pas cool
21:33 <seirl> j'ai pas de problème avec share le nic
21:34 <seirl> et on fait déjà un subnet pour les vms, ça change rien 
21:35 <halfr> si on doit gérer un autre subnet c'est assez reloud
21:35 <seirl> ben, share le nic ça me va très bien aussi
21:36 <halfr> bah pour le coup j'aime bien avoir des nic séparés pour pouvoir monitor facilement le trafic network
21:36 <halfr> ce que tu peux pas faire quand tu share le nic, AFAIK
21:36 <seirl> et rien faire ça me va très bien aussi en fait
21:36 <seirl> de toute façon meme si on met tout dom0 dans ansible, ça change pas que le contenu du conteneur/de la vm/... sera pas automatisé
21:37 <multun> je suis presque sûr que le changement quasi transparent de mettre ça dans une VM t'irait également
21:37 <seirl> ça me va pas qu'on ait des VMs pour n'importe quoi genre buildbot
21:37 <seirl> une de plus ou une de moins, ça changerait effectivement rien
21:38 <seirl> de façon générale je trouve ça dommage de se rajouter du travail sans bonne riason
21:38 <seirl> raison*
21:39 <halfr> jusqu'ici on a plutôt penché du côté VM justement parce que ça rajoute moins de travail que les conteneurs, qui sont objectivement des solutions plus élégantes
21:39 <halfr> mais, dans notre situation, migrer sur des conteneurs c'est plus de travail, sans gain qui le motive vraiment
21:40  * halfr drop the mic
21:40 <-- halfr (~halfr@prologin/halfr) has left #prologin-staff ("WeeChat 1.7")
21:40 -- #prologin-staff: Cannot join channel (+k) - bad key
21:41 --> halfr (~halfr@prologin/halfr) has joined #prologin-staff
21:41 -- Topic for #prologin-staff is "Canal réservé aux organisateurs de Prologin — https://hangouts.google.com/hangouts/_/prologin.org/prologin — Chantiers de FINALE en cours https://goo.gl/HDPS1g"
21:41 -- Topic set by Bruce_ ([email protected]) on Thu, 01 Mar 2018 09:28:31
21:41 -- Channel #prologin-staff: 45 nicks (0 ops, 0 voices, 45 normals)
21:41 -- Channel created on Sun, 31 Jan 2010 13:04:55
21:42 <Bruce_> ils ont tué Rémi !
21:42 <halfr> voilà c'était le club débat #prologin-staff, représentation tous les lundis, mardis, jeudis et mardis
21:42 <multun> *clap clap clap*
21:42 <seirl> halfr: je suis d'accord que ça rajoute du travail, je pense que rien faire > se rajouter du travail avec des conteneurs (comme ça c'est fait) > se rajouter du travail avec des vms
21:43 <Bruce_> bon ah euh au fait, j'ai oublié de le mentionner ici.
21:43 <seirl> flemme driven design
21:43 <multun> seirl: il reste quoi sur oldsite au juste ?
21:43 <Bruce_> multun, Corwin, seirl : pour les modifs réseau on ne pourra rien faire avant le jeudi 17 mai ~midi, y a l'exam cpp le soir d'avant et l'exam des sups le jeudi matin
21:44 <seirl> Bruce_: on le savait déjà ça non ?
21:44 <multun> Bruce_: pas grave
21:44 <Bruce_> pour lexam des sups je l'ai appris ce matin
21:44 <Bruce_> multun: je sais, je préviens juste
21:44 <seirl> je sais pas multun j'ai trop peur de t'embarquer dans un débat avec moi et que tu t'en ailles si je te le dis :(
21:44 <zopieux> :]
21:44 <multun> tg seirl
21:44 <seirl> mais si je mg, je peux pas te dire ce qu'il reste sur oldsite, c'est contre productif
21:45 <halfr> seirl: ouais, mais rien faire ça me laisse comme une gène, voir ce mysql qui tourne, qui passe dans les updates
21:45 <seirl> halfr: si tu veux j'installe mariadb :D
21:45 <halfr> c'est mariadb
21:45 <seirl> non mais ok je suis d'accord que c'est révoltant 
21:45 <halfr> je suis un oldie
21:46 <seirl> seulement je suis pas assez révolté pour y faire quelque chose parce que je vais vouloir faire la chose bien
21:46 <seirl> en nettoyant le drupal
21:46 <seirl> et ça c'est hors de question
21:46 <halfr> on est d'accord
21:46 <multun> seirl: si tu peux pas le dire autant le shutdown
21:46 <zopieux> alors non
21:46 <seirl> je préfère qu'oldsite tienne le plus longtemps possible jusqu'à ce qu'une mise à jour pète
21:46 <halfr> il faudrait réécrire le drupal dans un framework moderne
21:46 <seirl> et qu'on ait tous la flemme de l'updater
21:46 <seirl> et qu'il meure à petit feu
21:47 <zopieux> ou alors on l'immobilise dans la glace avec une VM ou un conteneur lambda avec à peu près les bonnes versions de php, apache, mysql
21:47 <seirl> ou un DOCKER
21:47 <zopieux> oui c'est dans "conteneur"
21:47 <Oxian> zopieux: on s'en fout des bonnes versions de php, apache, mysql, y'a un mot de passe devant
21:47 <Oxian> on t'a dit que c'est un pur problème devops
21:47 <zopieux> Oxian: rendors-toi stp je parle des bonnes versions pour que ça marche, pas pour les CVE
21:47 <seirl> Oxian: tu sais quand zopieux dit "les bonnes versions de XXXX", ça veut dire "les versions vieilles et pas mises à jour"