certes, mais comment ce code malicieux arrive juste que sur ma machine. C'est ça que je n'arrive pas à comprendre. C'est si courant que ça d'avoir un remote root exploit dans nginx, ssh, haproxy (c'est tout ce qui écoute sur mes serveurs) ? Je n'en ai vraiment pas l'impression.
Pour commencer j'insiste sur le fait que ce n'est vraiment pas du troll et que j'essaie de comprendre à côté de quoi je passe sachant que je n'ai rien de tout ça sur les serveurs que j'administre.
Mais la question est "est ce que ça doit se passer dans le kernel", ce qui implique de
savoir ce que "ça" recouvre exactement. De ce que je comprends, Falcon sensor est un >outil >de monitoring pour la sécurité. Par exemple, tu as un process qui commence à ouvrir des >connexions tcp vers tout ton lan sur tout les ports, la plateforme est censé le voir, et >c'est signe soit qu'une machine s'est fait pourrir et que les attaquants scannent le lan, >soit qu'un salarié faire n'imp. pour faire ça, faut pouvoir intercepter des appels systémes. >Y a qu'un endroit pour faire ça, le kernel.
Je suis perplexe. J'ai un outil de monitoring qui me remonte en temps réel les users connecté et les commandes exécuté sur la machine par un user connecté. Le tout sur un serveur hors de l'infra. Autre pays, autre DC autre range d'ip. Tout est remonté dans une console de monitoring. J'ai dans la console qui est connecté où et qui fait quoi et bien sur devant cette console il y a 3 personnes et chaque alerte génère la création d'un ticket.
Ici pas besoin d'attaquer le kernel pour faire ça.
J'ai ce même outil qui me remonte à intervalle régulier (1min) la liste des processus qui tourne, les ports et les connexions ouvertes. De la même manière uniquement les processus, les ports et les connexions autorisé ne déclenchent pas d'alerte. Tout ce qui n'est pas explicitement autorisé déclenche une alerte et ça remonte dans la console et ouvre un ticket.
Tout ça sans module kernel.
La seule chose que je vois pour contourner ce système ce serait de remplacer les binaires (ps, ss etc) et donc que la personne soit root sur une machine dont le ssh n'est accessible que via un lan et ou chaque personne et chaque commande lancé est tracé dans un outil externe. Toutes les applications tournent avec un user non root. Mais c'est vrai que ça tourne dans un crio qui lui tourne en root.
Une personne pourrait arriver à injecter du code dans une application web (on ne fait que du web), sortir du serveur d'application, rentrer dans le container, passer root, sortir du container, rester root et remonter sur une des machines du cluster. Sur le papier c'est un chemin qui me semble possible mais vraiment pas simple. Ca fait un paquet de zéro day à exploiter.
Mais pour moi ce genre de chose c'est une attaque ciblée. Et il est bien plus simple de troller un des salariés pour avoir son mdp que de monter un truc aussi complexe.
Donc que pourrait m'apporter ce système ? Sur twitter on m'a dit que ça permettait de découvrir des 0day inconnu et ceci grâce à l'IA. Là j'y vois surtout de la com. Je vois aussi surtout un binaire dont j'ai pas le code, qui se loge dans le kernel, qui est root et qui se connecte à internet. Dans le temps on appelait ça un trojan.
Si les 2 partis (en l’occurrence OVH et Microsoft) arrivent à un accord, je ne vois pas > de quel droit la justice devrait aller contre leur souhait dans une dispute économique.
A préciser que cet accord doit être légal avant tout. Je ne sais pas trop de quoi il s'agit réellement mais la loi est au dessus des accords entre entreprise. Et encore heureux. Si "l'institution" est mise au courant d'un problème de légalité elle peut s'auto saisir et enquêter.
dans ma boite on a remplace le vieillissant et bloated zimbra par https://modoboa.org/fr/. Nous faisons déjà du django et nous sommes francais alors ca l'a fait de suite. Ca juste marche, j'aime beaucoup.
J'adhère pour Amazon. Par contre il me semble suboptimal de crawler plusieurs fois le web pour l'indexer. Mutualiser l'effort dans ce cas me semble pertinent.
Après je ne m'étais pas rendu compte que Google était devenu nul. Il me trouve toujours les messages d'erreur cryptique de certains outils utilisés par mes clients. Pour le reste, dans mon utilisation d'internet Google ne fait pas vraiment partie du paysage. Je vais sur les sites qui m'intéressent et quand je cherche quelque chose je passe souvent pas wikipédia puis de lien en lien.
J'y pense depuis un moment mais mon avis est que effectivement on ne peut plus lutter contre Google ou Amazon. Ces entreprises sont trop en avance pour être contrées. Par contre on pourrait les rendre publique. Mon idée serait de mondialiser , une nationalisation mais au niveau mondial, ces entreprises et les mettre sous l'égide d'une entité responsable dans le giron de l'ONU par exemple.
Certes l'ONU n'est pas la panacée mais ce serait un moindre mal et une nouvelle direction qui me semble importante.
Cette idée vient d'une conférence sur le déploiement de la paire de cuivre en France. Le type disait que en 5ans le déploiement avait était fait dans 100% des bâtiments français.
Quand je vois qu'on paye une fibre 'PRO' des centaines d'euros par mois en plein Boulogne Billancourt, je me dis que France Telecom aurait pu faire beaucoup mieux, il y a déjà longtemps.
oui les cpu nvidia sont bien supportés. La seule galère que j'ai eu c'est que les drivers pour les cartes h100 ne sont pas les mêmes que pour ma gtx de gamer et j'ai mis un moment à comprendre …
Qui n'est quand même pas si lointain que ça, EDF avait les moyens d'avoir sa propre it. Pourquoi avoir besoin d'amazon ? Que fait amazon que EDF ne pourrait pas faire ?
j'en suis arrivé aux même conclusions oui. Percona. Mais avec un backup à froid. Je n'ai pas encore suffisamment d'exp et donc de confiance pour me lancer dans des acrobaties surtout quand la doc dit :
mongodump and mongorestore cannot be part of a backup strategy for 4.2+ sharded clusters that have sharded transactions in progress, as backups created with mongodump do not maintain the atomicity guarantees of transactions across shards.
dans les 3/4 des clients dont je fais la prod, qui sont des pme on va dire avec une grosse douzaine de dev qui font les choix technique parce qu'en vrai il n'y a que des dev dans ces boites. Et la plupart pour pas dire la totalité sont des jeunes prestas de 25ans qui ne sont que de passage. Alors est ce que c'est maintenable ? Ce n'est pas la question. En vrai plus c'est pourri plus longtemps ils gardent leur mission. Et donc oui c'est mal géré.
Après j'ai passé pas mal de temps dans des très grosses boites et les problèmes étaient différents mais tout aussi pénible pour moi qui faisait de la prod. Vmware/Windows/apache/mysql ou Vmware/windows/websphere/oracle ? Non debian/python/postgres … J'ai finis pas me faire dégager :) Alors maintenant c'est moi qui comment qu'on fait :)
moi mon père il me parlait de cartes perforées, de fortran et il mettait son code au coffre le soir. :)
J'essaie juste de dire. Attendre, prendre son temps, soupeser les besoins, mettre les avantages et les inconvénients et ne pas réécrire la roue avant de mettre en prod des technos ingérables.
C'est surtout que les jeunes ont été éduqués par les vieux.
la on tombe sur le cœur du problème, la formation et dans mon cas le recrutement. Je ne dirais pas que les jeunes ont été mal éduqués par les vieux, je dirais plutôt que les jeunes n'ont pas été éduqué tout cours sur l'histoire de leur métier. En terme d'informatique je parle. Et puis l’adage qui dis "quand on sait faire on fait, quand on sait pas faire on enseigne" marche pas mal :) (blague tout ça, enseigner c'est avant tout la pédagogie. Pédagogie qu'un expert dans un domaine n'aura pas forcément etc etc)
Ayant énormément de mal à recruter je prend maintenant des jeunes en stage pendant leurs études et je les forme. J'en garde moins d'un quart chaque année. Et certaines années aucun.
Entre ceux qui sont là sans savoir pourquoi ils sont la, ceux qui veulent "devenir riche", ceux qui veulent pas parler aux clients, ceux qui ne veulent pas parler tout court, ceux qui veulent pas faire d'astreintes, ceux qui partent en vacances sans prévenir. C'est vraiment pas simple.
Ensuite j'entends tout à fait que aujourd'hui la relation au travail "des jeunes" est différentes de la mienne. Je n'ai pas de problème avec ça.
Bref le sujet c'était les backups :) par les jeunes c'était mieux avant, moi de mon temps etc.
Qu'il y ait des gens qui innovent c'est super et c'est tant mieux. Par contre moi qui dois faire tenir de la prod de plus en plus grosse avec des coûts de maintenance de plus en plus faible je préfère me reposer sur des technos stable, très stable. Par exemple debian et postgres.
Pour ceph j'ai attendu 5ans avant de le passer en prod. Pour kubernetes, 3 ans. Pour le framework js front pratiquement 10ans et pour celui que j'ai choisi (vuejs) 5ans.
Bref l'innovation c'est nécessaire. Passer en prod des produits hype et pas terminé c'est dangereux.
Apprendre du passé bien sûr, être persuadé que les difficultés d’hier sont exactement
les mêmes que celle d’aujourd’hui c’est vraiment être vieux con et ignorant.
Et me faire dire ce que je ne dis pas c'est … ?
Je ne dis pas que tout était mieux avant, que uniquement les anciennes technos sont bonnes. Sinon je n'aurais pas dans ma stack kubernetes, ceph ou kafka. Jamais de la vie.
Je dis simplement que pour faire des choix et surtout pour ne pas ré inventer cette satanée roue il est pertinent de regarder ce qui a été fait avant et qui fonctionne pour éviter de faire des mauvais choix. Par mauvais choix j'entends des choix basés sur des technos hype propulsé par une tonne de communique qui sont très souvent difficiles et donc très couteuses à maintenir en prod et rarement pertinente. Genre mongodb.
je suis surpris de voir que ce mot n'apparait pas dans les commentaires. En tant que responsable de la prod de plusieurs boites c'est la première chose à laquelle on réfléchit avant de choisir un produit.
Comment on le backup, on le restaure, on le monitore, on le réplique. Est-il possible de faire du PITR ? Il est nécessaire de pouvoir faire tout ça facilement.
Par exemple ces derniers temps je récupère des clients avec mongodb et microservice en js.
Question : comment on backup mongodb. Eh bien on peut pas de ce que j'en comprends, enfin si on peut mais c'est pas consistant. Alors la nuit on passe le base en read only, on snapshot les fs, on repasse en read write et on copie les données sur le serveur de backup. Et au lieu d'avoir un seul fichier, j'en ai autant que de noeud de la base. J'ai l'impression de retourner en 2004 avec mysql …
Mais alors, pourquoi mongodb ? Qui y a-t-il comme données dans cette base pour nécessiter un mongodb ? Une simple base utilisateur qui permet l'authentification à l'application en question. Les dev de cette application ont donc réécrit ldap en js.
Point vieux con : les jeunes n'ont plus aucune culture en informatique, ils ne connaissent que la surface et les trucs à la mode. Jamais il ne se disent que avant eux on a déjà résolu tout ces problèmes. L'arrivée de chatgp n'ajoute rien de bon à tout ca.
Bref pour terminer : le bon outil pour le bon besoin. C'est primordial. Quiconque a déjà bricolé avec un couteau suisse comprendra.
je rebondis sur la partie IA et notebooks Jupyter. Depuis 2015 je bosse avec des "data scientist". Leur principal point commun c'est d'utiliser et donc de livrer leur code sous forme de notebooks Jupyter. J'avais donc, à priori, deux voie pour passer leurs livrables en production. Soit apprendre à des ds à coder correctement et à livrer du code que l'on peut directement mettre en prod (ils adorent les csv avec des chemins en dur …).
On ne peut pas dire que ça a échoué, on dira que ça n'a pas marché. Alors on a décidé de prendre des dev pyton pour faire de la datascience. Ça a marché un temps. Mais depuis deux ans on fabrique nos propres algo de traitement du langage et là ça coince. Un dev python ne sait plus faire.
Résultat des courses j'ai deux équipes une de ds qui nous livre du code pas vraiment utilisable et une équipe de dev python qui ré-écris toute ou partie du code pour la faire rentrer sur la plateforme.
Pour limiter les réécritures on essaie de packager un maximum de chose. En particulier nos structures de données et l'accès aux dites données, pour enfin ne plus voir de chemin en dur vers un csv …
Et je termine donc : nous utilisons pyenv, pdm et docker pour le dev, comme ça on isole bien notre env dans docker. Et gitlab pour la publication de nos packages.
je ne crois pas l'avoir vu mais :b string avec string étant tout ou partie d'un nom de fichier permet facilement de circuler entre les buffers. Ajouter :vs :sp pour cinder l'affichage et je n'ai besoin de rien de plus. A oui :e file pour ouvrir un fichier.
[^] # Re: L'informatique
Posté par oau . En réponse au journal Ford: Quand les brevets ne sont pas pensés par les informaticiens. Évalué à 5.
C'est fait. Pour moi c'est le cantal avec la fibre, la 5g et de l'immobilier vraiment pas cher. Et franchement on est bien :). Viendez !
[^] # Re: Pourquoi la voiture propose une maj en roulant...
Posté par oau . En réponse au lien il paralyse Sète en lançant une mise à jour Tesla au feu rouge. Évalué à 3.
la boite de dialogue dit explicitement que la mise à jour peut prendre jusqu’à 20min. Mais qui lit les boites de dialogue :) ?
# journal d'excellente qualité
Posté par oau . En réponse au journal Fin d’OCSP chez Let’s Encrypt : quid ?. Évalué à 6.
Voilà c'est tout. Merci beaucoup.
[^] # Re: Toujours la même rengaine
Posté par oau . En réponse au lien Every Microsoft employee is now being judged on their security work - OSnews. Évalué à 2.
Et moi qui pensait que j'étais un peu vache avec ms. Sacré article au vitriol.
[^] # Re: Microsoft -> CrowdStrike
Posté par oau . En réponse au lien Une panne géante de Microsoft paralyse de nombreuses entreprises dans le monde. Évalué à 2.
Bonjour,
certes, mais comment ce code malicieux arrive juste que sur ma machine. C'est ça que je n'arrive pas à comprendre. C'est si courant que ça d'avoir un remote root exploit dans nginx, ssh, haproxy (c'est tout ce qui écoute sur mes serveurs) ? Je n'en ai vraiment pas l'impression.
[^] # Re: Microsoft -> CrowdStrike
Posté par oau . En réponse au lien Une panne géante de Microsoft paralyse de nombreuses entreprises dans le monde. Évalué à 9.
Pour commencer j'insiste sur le fait que ce n'est vraiment pas du troll et que j'essaie de comprendre à côté de quoi je passe sachant que je n'ai rien de tout ça sur les serveurs que j'administre.
Je suis perplexe. J'ai un outil de monitoring qui me remonte en temps réel les users connecté et les commandes exécuté sur la machine par un user connecté. Le tout sur un serveur hors de l'infra. Autre pays, autre DC autre range d'ip. Tout est remonté dans une console de monitoring. J'ai dans la console qui est connecté où et qui fait quoi et bien sur devant cette console il y a 3 personnes et chaque alerte génère la création d'un ticket.
Ici pas besoin d'attaquer le kernel pour faire ça.
J'ai ce même outil qui me remonte à intervalle régulier (1min) la liste des processus qui tourne, les ports et les connexions ouvertes. De la même manière uniquement les processus, les ports et les connexions autorisé ne déclenchent pas d'alerte. Tout ce qui n'est pas explicitement autorisé déclenche une alerte et ça remonte dans la console et ouvre un ticket.
Tout ça sans module kernel.
La seule chose que je vois pour contourner ce système ce serait de remplacer les binaires (ps, ss etc) et donc que la personne soit root sur une machine dont le ssh n'est accessible que via un lan et ou chaque personne et chaque commande lancé est tracé dans un outil externe. Toutes les applications tournent avec un user non root. Mais c'est vrai que ça tourne dans un crio qui lui tourne en root.
Une personne pourrait arriver à injecter du code dans une application web (on ne fait que du web), sortir du serveur d'application, rentrer dans le container, passer root, sortir du container, rester root et remonter sur une des machines du cluster. Sur le papier c'est un chemin qui me semble possible mais vraiment pas simple. Ca fait un paquet de zéro day à exploiter.
Mais pour moi ce genre de chose c'est une attaque ciblée. Et il est bien plus simple de troller un des salariés pour avoir son mdp que de monter un truc aussi complexe.
Donc que pourrait m'apporter ce système ? Sur twitter on m'a dit que ça permettait de découvrir des 0day inconnu et ceci grâce à l'IA. Là j'y vois surtout de la com. Je vois aussi surtout un binaire dont j'ai pas le code, qui se loge dans le kernel, qui est root et qui se connecte à internet. Dans le temps on appelait ça un trojan.
[^] # Re: Pusillanimité ou corruption ?
Posté par oau . En réponse au lien Microsoft signs antitrust truce with OVHcloud . Évalué à 4.
A préciser que cet accord doit être légal avant tout. Je ne sais pas trop de quoi il s'agit réellement mais la loi est au dessus des accords entre entreprise. Et encore heureux. Si "l'institution" est mise au courant d'un problème de légalité elle peut s'auto saisir et enquêter.
[^] # Re: Microsoft -> CrowdStrike
Posté par oau . En réponse au lien Une panne géante de Microsoft paralyse de nombreuses entreprises dans le monde. Évalué à 8.
On pourrait se demander par contre pourquoi il y a besoin de ce genre de logiciel qui n'est pas un driver sur un windows, non ?
# modoboa
Posté par oau . En réponse au journal Gérer votre propre serveur de courrier électronique. Évalué à 10.
Hello
dans ma boite on a remplace le vieillissant et bloated zimbra par https://modoboa.org/fr/. Nous faisons déjà du django et nous sommes francais alors ca l'a fait de suite. Ca juste marche, j'aime beaucoup.
[^] # Re: Quelques explications
Posté par oau . En réponse au lien coup de force de broadcom sur les licences vmware : appel à la commission européenne. Évalué à 7.
c'est bien fait pour eux ? Oui je pense, même si c'est pas très charitable ça me fait bien rigoler.
[^] # Re: Je suis pas un grand fan pourtant
Posté par oau . En réponse au lien En fait, l'IA ne sert à rien. Évalué à 6.
Ca reste tout de même une quantité stratosphérique d'énergie consommée pour pas souvent grand-chose.
[^] # Re: service publique
Posté par oau . En réponse au journal Traduction : Payer ne permet pas d'échapper aux monopoles. Évalué à 3.
J'adhère pour Amazon. Par contre il me semble suboptimal de crawler plusieurs fois le web pour l'indexer. Mutualiser l'effort dans ce cas me semble pertinent.
Après je ne m'étais pas rendu compte que Google était devenu nul. Il me trouve toujours les messages d'erreur cryptique de certains outils utilisés par mes clients. Pour le reste, dans mon utilisation d'internet Google ne fait pas vraiment partie du paysage. Je vais sur les sites qui m'intéressent et quand je cherche quelque chose je passe souvent pas wikipédia puis de lien en lien.
# service publique
Posté par oau . En réponse au journal Traduction : Payer ne permet pas d'échapper aux monopoles. Évalué à 3.
Bonjour,
J'y pense depuis un moment mais mon avis est que effectivement on ne peut plus lutter contre Google ou Amazon. Ces entreprises sont trop en avance pour être contrées. Par contre on pourrait les rendre publique. Mon idée serait de mondialiser , une nationalisation mais au niveau mondial, ces entreprises et les mettre sous l'égide d'une entité responsable dans le giron de l'ONU par exemple.
Certes l'ONU n'est pas la panacée mais ce serait un moindre mal et une nouvelle direction qui me semble importante.
Cette idée vient d'une conférence sur le déploiement de la paire de cuivre en France. Le type disait que en 5ans le déploiement avait était fait dans 100% des bâtiments français.
Quand je vois qu'on paye une fibre 'PRO' des centaines d'euros par mois en plein Boulogne Billancourt, je me dis que France Telecom aurait pu faire beaucoup mieux, il y a déjà longtemps.
oau
[^] # Re: Support des GPU
Posté par oau . En réponse au journal Introduction pratique aux grands modèles de langage / LLM. Évalué à 2.
oui les cpu nvidia sont bien supportés. La seule galère que j'ai eu c'est que les drivers pour les cartes h100 ne sont pas les mêmes que pour ma gtx de gamer et j'ai mis un moment à comprendre …
# de mon temps
Posté par oau . En réponse au lien EDF - contrat avec Amazon pour gérer la planification de la maintenance des centrales nucléaires. Évalué à 1.
Qui n'est quand même pas si lointain que ça, EDF avait les moyens d'avoir sa propre it. Pourquoi avoir besoin d'amazon ? Que fait amazon que EDF ne pourrait pas faire ?
[^] # Re: backup ?
Posté par oau . En réponse au journal Tour d'horizon de l'état des bases NoSQL. Évalué à 3.
j'en suis arrivé aux même conclusions oui. Percona. Mais avec un backup à froid. Je n'ai pas encore suffisamment d'exp et donc de confiance pour me lancer dans des acrobaties surtout quand la doc dit :
https://www.mongodb.com/docs/manual/core/backups/#back-up-with-mongodump
le reste de la description fait un peu flipper je trouve.
[^] # Re: backup ?
Posté par oau . En réponse au journal Tour d'horizon de l'état des bases NoSQL. Évalué à 2. Dernière modification le 25 décembre 2023 à 18:47.
hello
dans les 3/4 des clients dont je fais la prod, qui sont des pme on va dire avec une grosse douzaine de dev qui font les choix technique parce qu'en vrai il n'y a que des dev dans ces boites. Et la plupart pour pas dire la totalité sont des jeunes prestas de 25ans qui ne sont que de passage. Alors est ce que c'est maintenable ? Ce n'est pas la question. En vrai plus c'est pourri plus longtemps ils gardent leur mission. Et donc oui c'est mal géré.
Après j'ai passé pas mal de temps dans des très grosses boites et les problèmes étaient différents mais tout aussi pénible pour moi qui faisait de la prod. Vmware/Windows/apache/mysql ou Vmware/windows/websphere/oracle ? Non debian/python/postgres … J'ai finis pas me faire dégager :) Alors maintenant c'est moi qui comment qu'on fait :)
[^] # Re: backup ?
Posté par oau . En réponse au journal Tour d'horizon de l'état des bases NoSQL. Évalué à 1.
moi mon père il me parlait de cartes perforées, de fortran et il mettait son code au coffre le soir. :)
J'essaie juste de dire. Attendre, prendre son temps, soupeser les besoins, mettre les avantages et les inconvénients et ne pas réécrire la roue avant de mettre en prod des technos ingérables.
[^] # Re: backup ?
Posté par oau . En réponse au journal Tour d'horizon de l'état des bases NoSQL. Évalué à 3.
la on tombe sur le cœur du problème, la formation et dans mon cas le recrutement. Je ne dirais pas que les jeunes ont été mal éduqués par les vieux, je dirais plutôt que les jeunes n'ont pas été éduqué tout cours sur l'histoire de leur métier. En terme d'informatique je parle. Et puis l’adage qui dis "quand on sait faire on fait, quand on sait pas faire on enseigne" marche pas mal :) (blague tout ça, enseigner c'est avant tout la pédagogie. Pédagogie qu'un expert dans un domaine n'aura pas forcément etc etc)
Ayant énormément de mal à recruter je prend maintenant des jeunes en stage pendant leurs études et je les forme. J'en garde moins d'un quart chaque année. Et certaines années aucun.
Entre ceux qui sont là sans savoir pourquoi ils sont la, ceux qui veulent "devenir riche", ceux qui veulent pas parler aux clients, ceux qui ne veulent pas parler tout court, ceux qui veulent pas faire d'astreintes, ceux qui partent en vacances sans prévenir. C'est vraiment pas simple.
Ensuite j'entends tout à fait que aujourd'hui la relation au travail "des jeunes" est différentes de la mienne. Je n'ai pas de problème avec ça.
Bref le sujet c'était les backups :) par les jeunes c'était mieux avant, moi de mon temps etc.
[^] # Re: backup ?
Posté par oau . En réponse au journal Tour d'horizon de l'état des bases NoSQL. Évalué à 6.
Qu'il y ait des gens qui innovent c'est super et c'est tant mieux. Par contre moi qui dois faire tenir de la prod de plus en plus grosse avec des coûts de maintenance de plus en plus faible je préfère me reposer sur des technos stable, très stable. Par exemple debian et postgres.
Pour ceph j'ai attendu 5ans avant de le passer en prod. Pour kubernetes, 3 ans. Pour le framework js front pratiquement 10ans et pour celui que j'ai choisi (vuejs) 5ans.
Bref l'innovation c'est nécessaire. Passer en prod des produits hype et pas terminé c'est dangereux.
[^] # Re: backup ?
Posté par oau . En réponse au journal Tour d'horizon de l'état des bases NoSQL. Évalué à 4.
Et me faire dire ce que je ne dis pas c'est … ?
Je ne dis pas que tout était mieux avant, que uniquement les anciennes technos sont bonnes. Sinon je n'aurais pas dans ma stack kubernetes, ceph ou kafka. Jamais de la vie.
Je dis simplement que pour faire des choix et surtout pour ne pas ré inventer cette satanée roue il est pertinent de regarder ce qui a été fait avant et qui fonctionne pour éviter de faire des mauvais choix. Par mauvais choix j'entends des choix basés sur des technos hype propulsé par une tonne de communique qui sont très souvent difficiles et donc très couteuses à maintenir en prod et rarement pertinente. Genre mongodb.
# backup ?
Posté par oau . En réponse au journal Tour d'horizon de l'état des bases NoSQL. Évalué à 10.
bonjour,
je suis surpris de voir que ce mot n'apparait pas dans les commentaires. En tant que responsable de la prod de plusieurs boites c'est la première chose à laquelle on réfléchit avant de choisir un produit.
Comment on le backup, on le restaure, on le monitore, on le réplique. Est-il possible de faire du PITR ? Il est nécessaire de pouvoir faire tout ça facilement.
Par exemple ces derniers temps je récupère des clients avec mongodb et microservice en js.
Question : comment on backup mongodb. Eh bien on peut pas de ce que j'en comprends, enfin si on peut mais c'est pas consistant. Alors la nuit on passe le base en read only, on snapshot les fs, on repasse en read write et on copie les données sur le serveur de backup. Et au lieu d'avoir un seul fichier, j'en ai autant que de noeud de la base. J'ai l'impression de retourner en 2004 avec mysql …
Mais alors, pourquoi mongodb ? Qui y a-t-il comme données dans cette base pour nécessiter un mongodb ? Une simple base utilisateur qui permet l'authentification à l'application en question. Les dev de cette application ont donc réécrit ldap en js.
Point vieux con : les jeunes n'ont plus aucune culture en informatique, ils ne connaissent que la surface et les trucs à la mode. Jamais il ne se disent que avant eux on a déjà résolu tout ces problèmes. L'arrivée de chatgp n'ajoute rien de bon à tout ca.
Bref pour terminer : le bon outil pour le bon besoin. C'est primordial. Quiconque a déjà bricolé avec un couteau suisse comprendra.
[^] # Re: Avis d'un utilisateur / dev
Posté par oau . En réponse à la dépêche L'installation et la distribution de paquets Python (2/4). Évalué à 5. Dernière modification le 24 décembre 2023 à 11:06.
hello
je rebondis sur la partie IA et notebooks Jupyter. Depuis 2015 je bosse avec des "data scientist". Leur principal point commun c'est d'utiliser et donc de livrer leur code sous forme de notebooks Jupyter. J'avais donc, à priori, deux voie pour passer leurs livrables en production. Soit apprendre à des ds à coder correctement et à livrer du code que l'on peut directement mettre en prod (ils adorent les csv avec des chemins en dur …).
On ne peut pas dire que ça a échoué, on dira que ça n'a pas marché. Alors on a décidé de prendre des dev pyton pour faire de la datascience. Ça a marché un temps. Mais depuis deux ans on fabrique nos propres algo de traitement du langage et là ça coince. Un dev python ne sait plus faire.
Résultat des courses j'ai deux équipes une de ds qui nous livre du code pas vraiment utilisable et une équipe de dev python qui ré-écris toute ou partie du code pour la faire rentrer sur la plateforme.
Pour limiter les réécritures on essaie de packager un maximum de chose. En particulier nos structures de données et l'accès aux dites données, pour enfin ne plus voir de chemin en dur vers un csv …
Et je termine donc : nous utilisons pyenv, pdm et docker pour le dev, comme ça on isole bien notre env dans docker. Et gitlab pour la publication de nos packages.
[^] # Re: Ajout
Posté par oau . En réponse au journal travailler sur de nombreux fichiers avec Vim et NeoVim, sur une seule vue. Évalué à 3.
Je code avec vi depuis 1997. Aujourd'hui c'est même mon métier et ça marche très bien. Python/Django/vuejs/k8s.
Je ne manque de rien 🤗
# Ajout
Posté par oau . En réponse au journal travailler sur de nombreux fichiers avec Vim et NeoVim, sur une seule vue. Évalué à 2.
hello,
je ne crois pas l'avoir vu mais :b string avec string étant tout ou partie d'un nom de fichier permet facilement de circuler entre les buffers. Ajouter :vs :sp pour cinder l'affichage et je n'ai besoin de rien de plus. A oui :e file pour ouvrir un fichier.
vim c'est bien pour coder mangez en :)