Nico C. a écrit 667 commentaires

  • [^] # Re: En biologie

    Posté par (page perso) . En réponse au journal Culte du Cargo et développement informatique. Évalué à 10 (+8/-0).

    Y'a aussi l'histoire de l'experience avec des singes qui est du meme acabit. Idem, je sais pas si c'est une vraie experience ou une legende urbaine mais c'est marrant de la raconter à une bande d'utilisateurs "qui ont toujours fait comme ça" :

    C'est un labo de recherche qui fait une etude comportementale avec un groupe de singes. Chaque singe possède un gilet qui peut lancer des decharges electriques. Il y a un tas de bananes au milieu de la piece et si un singe du groupe touche a cette banane, tout le groupe reçoit une decharge electrique.
    Evidemment, très vite, ils ont compris qu'il ne faut pas toucher aux bananes.
    Lorsqu'un nouvel individu est introduit, il est très vite mis au parfum par le groupe qu'il ne faut pas toucher les bananes sinon il se prend une branlée.
    Et a chaque nouvel individu est "formé" pour pas toucher les bananes. Et ça perdure même lorsqu'il n'y a plus un seul singe du groupe initial et qu'aucun "nouveau" n'a connu la moindre decharge electrique.
    Et même lorsqu'on leur enleve les gilets, ils ne touchent pas les bananes car le groupe fait ce qu'il faut pour bloquer les initiatives individuelles et les "innovations".

    C'est une petite fable aussi pour faire comprendre les defauts de la formation "sur le tas" des nouveaux et la perte d'information au fil des remplacements ainsi que l'entretien de la soit-disante "culture d'entreprise".

  • [^] # Re: star wars et réalisme

    Posté par (page perso) . En réponse au journal Parlons un peu de Star Wars VIII - Les derniers Jedi (Attention : SPOILERS). Évalué à 4. Dernière modification le 17/12/17 à 23:46.

    Moi pas. Certes, la scène en question a bien été enjolivée mais buter d'un coup la princesse Leïa des origines de la Saga de cette façon, ça aurait paru un peu trop rapide aux fans et ils auraient eu raison.

    Je suis d'accord mais tout le monde aurait compris, je pense…

    Sans compter qu'ils ont fait exactement le même coup à Han Solo (qui, dans la vie réelle, devait en avoir marre) et que c'est une des principales faiblesses de l'épisode VII.

    J'ai bien aimé ce petit coté "Game of Thrones" :)

    N'empêche qu'à ce stade, c'est Luke Skywalker, Han Solo et Leïa (en vrai) qui sont partis. Si on suit cette logique, ils leur reste à buter C3PO et R2D2. Ce serait décevant mais inattendu. :)

    R2D2 en est pas loin, la batterie ne tient plus très longtemps visiblement…
    Il reste Chewie sinon

  • [^] # Re: star wars et réalisme

    Posté par (page perso) . En réponse au journal Parlons un peu de Star Wars VIII - Les derniers Jedi (Attention : SPOILERS). Évalué à 4.

    Ce qui est dommage dans cette histoire, c'est qu'ils auraient pu en profiter pour tuer Leia et éviter de se galérer à trouver un pretexte pour le 9.
    Après la scene superwoman, le perso ne sert plus a rien dans l'histoire. Ca n'aurait pas été difficile de l'enlever au montage je pense…

    Mais non, ils ont preferé la garder jusqu'au bout. A mon avis, c'est une belle occas' manquée…

  • [^] # Re: Stars Wars, yeux d'enfants, yeux d'adultes

    Posté par (page perso) . En réponse au journal Parlons un peu de Star Wars VIII - Les derniers Jedi (Attention : SPOILERS). Évalué à 3.

    Snoke étant mort, il n'y a plus de "grand méchant" à affronter et défaire. Il reste la question de ses motivations et de son histoire, mais ça aurait dû déjà être raconté.

    Le grand méchant, c'est Kylo Ren maintenant.
    Snoke faisait le mariole en pensant le manipuler (et il l'a probablement fait pendant un temps) mais il semblerait que Kylo Ren a réussit à s'en rendre compte, passer au delà et finir sa formation de Sith en tuant son maitre.
    Après, a savoir si il est crédible ou pas dans ce rôle, c'est une autre question…

  • [^] # Re: C'est pas vendredi

    Posté par (page perso) . En réponse au journal Debian sur mon serveur plus jamais, de chez jamais.. Évalué à 1. Dernière modification le 16/12/17 à 10:43.

    Oui mais ça, ça entre dans ce que j'appelle "les cas très particuliers"…

  • [^] # Re: C'est pas vendredi

    Posté par (page perso) . En réponse au journal Debian sur mon serveur plus jamais, de chez jamais.. Évalué à 10. Dernière modification le 14/12/17 à 15:48.

    Dans tous tes messages, ce qui me gêne le plus dans ton discours est résumé dans cette phrase :

    J'aime le robuste et le solide, le sur et le fiable, bref je fais de l'informatique de production pas de la bidouille.

    Or, dans tous les exemples que tu donnes, pour toi, robuste/fiable/production = figé pendant des années.
    exemple :

    En gros j'utilise quoi moi pour être tranquille pour 10 ans ?!!

    Moi, j'appelle pas ça de la production. Ou alors seulement dans une boite elle-même figée.
    Une boite qui grandit, qui évolue, qui bouge quoi, rien n'est figé, au contraire même. On est tout le temps en train de remplacer des choses, ajouter et mettre à jour.
    Alors je sais pas comment tu bosses ni quel est ton job exact mais si tu es sysadmin, j'ai vraiment l'impression que tu fais partie de ces gens qui font tout à la main, aux petits oignons certes, mais avec des outils qui leurs conviennent à eux et pas nécessairement aux besoins des utilisateurs et du reste de l'équipe. Ces gens qui ne se préoccupent pas de savoir qui sera en charge après eux ou avec eux, ces gens qui râlent au moindre changement car il va falloir toucher au chateau de cartes qu'ils ont patiemment monté de leurs petits doigts d’orfèvres…

    En vrai, le problème de la version d'un OS n'en est pas un. Quand tout bouge tout le temps, on automatise beaucoup le provisionnement des serveurs/VM et l'install des softs. L'OS entre dans le tronc commun et n'est plus vraiment un point différenciant (sauf dans des cas très particuliers).
    Quand on veut mettre à jour un OS, on monte une nouvelle VM en 5 ou 6 min, on réinstalle le soft et les données en 10min et on bascule le load balancer ou l'IP virtuelle.
    Rien à foutre que la MAJ de Debian 8 à Debian 9 se fasse bien ou pas. Rien à foutre que Debian supporte ses OS 3 ans, 5 ans ou 20 ans. Tant que ça tient 1 ou 2 ans max, c'est suffisant.
    Rien à foutre que la syntaxe de machin ou truc soit comme ceci ou comme cela, mon outil de provisonning/déploiement masque les différences entre les versions de Debian et même entre les différentes distribs…

    Aujourd'hui, au niveau pro, je reste sur Debian car c'est une des distribs les plus utilisées et possédant un des écosystèmes les plus gros et varié. Contrairement à FreeBSD, justement.
    Et ça, c'est une différence nette entre les 2 qui rend la 1ère bien plus "professionnelle" que le second…

    Mais après, chacun voit midi à sa porte et les défauts que tu relèves sont réels. Aucun doute la dessus.

  • # et moi et moi et moi

    Posté par (page perso) . En réponse au journal Votre rapport à l’anglais ?. Évalué à 5.

    Moi aussi, je vais donner mon avis car j'ai l'impression d'être le plus proche de tes ennuis par rapport aux autres témoignages… :)

    Contexte : j'ai fait toute ma carrière en France dans des boites françaises où l'anglais n'était absolument pas nécessaire (sauf 1 boite il y a une 10aine d'année pendant 1 an entre son rachat par un groupe italien et ma démission).
    J'ai fait le minimum vital d'anglais à l'école et c'était pas fameux. Un peu de voyages par ci par là ou l'anglais sert essentiellement à manger, boire et raconter d'où on vient sans pour autant faire des conférences philosophiques de 2h.
    Aujourd'hui, je suis à mon compte et j'ai de temps en temps des clients étrangers avec lesquels la conversation se fait exclusivement en anglais… Ça fout un coup de pied au cul mais c'est pas désagréable :)

    Quel est ton rapport à l'anglais ?
    J'aime bien, je fais des efforts

    Comment as-tu fait pour le parler de façon acceptable ?

    Je considère pas que je le parle de façon acceptable mais je considère que je le lis bien et je l'écris pas trop mal même si parfois je m'aide d'un traducteur en ligne pour un mot ou une tournure sur laquelle j'ai un doute (je me fie pas au traducteur, c'est juste que je l'utilise pour valider certains trucs)
    Je lis évidemment BEAUCOUP de contenus en anglais (docs techniques, presse spécialisée et généraliste) et depuis qq années, je regarde de plus en plus de vidéos en anglais. Ma compréhension à l'oral a sérieusement progressé depuis.
    Je perds moins le fil des conversations, je suis plus agile pour capter les blagues, le slang et les changements de sujets impromptus. Et je fatigue moins pour suivre aussi…

    Comment tu fais pour ne pas être stressé avant/pendant un call ?

    Je me prépare.
    Généralement, j'essaie de faire à l'écrit autant que possible car j'ai besoin d'un peu de réflexion pour faire des phrases. C'est mon principal problème. Et c'est pour ça qu'à l'oral je me galère un peu car l'improvisation est très difficile pour moi.
    Donc, je m'assure d'avoir qq pense-bêtes sous la main, je m'assure de bien connaitre mon sujet pour n'avoir que le problème de langue à gérer et je me détends. Je peux foutre en l'air une journée entière pour un call d'1h mais tant pis…

    Est-ce que tu pourrais être dans l'entreprise où tu es aujourd'hui si tu ne parlais pas anglais ?

    Oui, sans problème mais ça ferme des portes donc autant éviter car ce n'est pas un si gros effort en fait… Faut juste que ce "problème" ne te "mange" pas le cerveau…

    Est-ce que tu as dû te farcir des séries américaines en VO alors que tu détestes ça ?

    Moi j'aime bien et ça aide beaucoup pour comprendre les gens et se faire l'oreille. Mais ça n'aide pas pour parler et avoir le bon vocabulaire qui arrive au bon moment dans la bouche. Pour ça, y'a que l'entrainement et la pratique.
    Franchement, pour avoir des potes (et d'autres connaissances) qui bossent dans des boites où l'anglais et la langue de travail, y'a pas de honte à avoir, tout le monde à un anglais de chiotte mais l'important est de se comprendre.
    J'ai déjà eu à discuter avec des Indiens, Italiens, Espagnols, Tcheques, Americains, Anglais et Français qui parlaient en anglais et tout le monde parle mal avec un accent dégueulasse et des anglicismes dans tous les sens (sauf les natifs évidemment). Mais tant que les gens se comprennent ça roule…

    En fait, je crois qu'il n'y a que les Français qui se stressent pour leur niveau d'anglais car on a une approche bien trop littéraire de la langue alors que le reste du monde est vachement plus compréhensif…

  • # Free : RAS

    Posté par (page perso) . En réponse au journal Bouygues et IP fixe... qui change (où l'on parle aussi de fake MX). Évalué à 2. Dernière modification le 02/10/17 à 10:25.

    Je suis chez Free depuis des années et jamais eu de problème de ce genre. La seule fois où mon IP a changé, c'était pour le passage à la fibre mais j'avais été prévenu bien à l'avance et je connaissais même ma future IP avant la bascule (que j'ai effectué moi-même d'ailleurs le jour et à l'heure que je voulais).

    Après, je connais pas Bouygues en tant que FAI mais j'ose imaginer qu'un changement de NRA se fait pas tous les jours donc ça reste un problème minime quand même. Et combien de personnes font de l'autohébergement réellement ? Si ça leur arrive de changer de NRA 1000 lignes par mois (je donne des chiffres au hasard, je suis persuadé que c'est bien moins), le nombre de gens qui s'en rendent compte doit même pas représenter 0,1% et le nombre de gens que ça gène vraiment doit pas dépasser les 50 par an…
    Franchement, ils vont pas s'emmerder à envoyer des mails d'information que 98% des clients concernés ne comprendront même pas et qui risquent de générer plus d'appels au support pour rien que de réels problèmes concrets. Il vaut mieux laisser les 50 pélots se répandre dans des forums spécialisés et laisser filer… En tout cas, c'est ce que je ferais moi aussi :)

  • [^] # Re: (en plus des règles habituelles de sécurité)

    Posté par (page perso) . En réponse au journal De l'exploitation des logs de fail2ban…. Évalué à 10.

    Ca evite d'avoir ses logs blindés de tests faits par des bots…
    Ca augmente pas la sécurité, c'est juste le pas de coté suffisant pour être laissé tranquille par les bots relous.

  • [^] # Re: SSH

    Posté par (page perso) . En réponse au journal Let's Encrypt, OVH et la sécurité. Évalué à 0.

    Ouais effectivement…

    Mais bon, on parle d'une offre à 2 balles par mois vs une offre à 5 balles par mois.
    Voila.

    Si cette problématique de sécurité est si importante pour OP, ça vaut certainement les 30 ou 40€ par AN en plus.

  • # SSH

    Posté par (page perso) . En réponse au journal Let's Encrypt, OVH et la sécurité. Évalué à 10. Dernière modification le 28/07/17 à 00:55.

    Je crois que Nal en pense qu'il y a du ssh même sur les hébergements mutualisés : https://docs.ovh.com/fr/fr/web/hosting/mutualise-le-ssh-sur-les-hebergements-mutualises/

    Et si Nal se souvient bien, ça fait au moins 5 ou 6 ans que c'est dispo (Nal dirait bien 10 mais il ose pas…)

  • [^] # Re: GlusterFS

    Posté par (page perso) . En réponse au journal Système de fichiers clusterisé - OCFS2, GFS2, GlusterFS, autres. Évalué à 10. Dernière modification le 26/06/17 à 18:45.

    Si tu as un peu de temps, aurais-tu l'amabilité de détailler stp? (j'ai du mal à digérer la documentation de glusterfs qui est volumineuse et uniquement anglophone ^ ^ )

    Un "split brain" arrive quand les 2 noeuds d'un cluster actif-actif sont toujours UP mais c'est le lien réseau entre les 2 (qui leur sert pour les synchro) est rompu. On se retrouve dans ce cas avec potentiellement des données neuves (mais différentes) sur les 2 noeuds à la fois car chaque noeud se croit maître du cluster et avec une impossibilité pour les réconcilier.

    Pour régler ce problème, il y a plusieurs méthodes :
    - le STONITH (“Shoot The Other Node In The Head”) qui part du principe que tu disposes d'un système de monitoring externe capable de prendre la décision d'arrêter aussi vite que possible un des 2 noeuds le temps que le système de syncho soit de nouveau UP. Solution de bourrin, pas toujours très efficace et assez risquée au final car si le monitoring se trouve lui-même isolé, c'est la merde.
    - Ne pas faire de cluster actif-actif mais actif-passif comme la plupart des bases de données relationnelles le conseillent. La bascule se fait de préférence manuellement après diagnostique de la situation. C'est lent, pas automatique mais l'intégrité des données est garantie du moment que les admins font bien leur boulot et suivent les procédures.
    - Mettre en place un 3e noeud (ou plus du moment que le total est impair) et laisser le cluster procéder à une élection d'un nouveau maitre en cas de panne d'un noeud. Celui qui dispose de la majorité+1 (le "quorum") est le nouveau maitre. Celui qui est minoritaire se place de lui-même en isolement le temps de revoir ses petits copains.

    GlusterFS fonctionne avec 3 noeuds. D'autres font pareil comme MongoDB pour donner un exemple très connu mais on pourrait en trouver des tas d'autres encore…

  • [^] # Re: GlusterFS

    Posté par (page perso) . En réponse au journal Système de fichiers clusterisé - OCFS2, GFS2, GlusterFS, autres. Évalué à 2.

    Parce que les noeuds GlusterFS vont par 3 pour empêcher les "split-brain". Par contre, je suis pas certain qu'il soit nécessaire de dupliquer autant de fois les données.
    Il me semble qu'il existe un mécanisme "d'Arbiter" qui possède une voix dans l'élection du nouveau maitre (après incident sur un noeud) sans faire partie "fonctionnellement" du cluster et donc sans copie des données.

  • # Essentiel

    Posté par (page perso) . En réponse au journal Système de fichiers clusterisé - OCFS2, GFS2, GlusterFS, autres. Évalué à 4.

    Elles sont interessantes tes questions :

    • Ressentez-vous le besoin de clusteriser Samba ou autre serveur de fichiers ?
    • Ou assumez-vous le fait de pouvoir perdre un moteur de serveur de fichiers ?
    • Ou avez-vous dupliqué les données, et donc les moteurs ?

    Mais ça suppose de revenir à l'essentiel de ton problème :

    • quels sont les volumes concernées (en données, en réseau, en users, en accès concurrents)
    • quel est le risque à couvrir (RPO/RTO ?, SLA ?) ?

    Sans ça, c'est difficile de te dire si tu fais bien ou pas de t'emmerder avec tout ce bazar…

  • [^] # Re: Tout essayé?

    Posté par (page perso) . En réponse au journal Libérer un Mac/Intel. Évalué à 2. Dernière modification le 02/03/17 à 18:14.

    Pour info, à l'époque ou le firewire était encore présent sur les macs, on pouvait même booter sur le disque d'un 2e mac relié avec un simple cable.
    Je crois que ça a marché pendant un certain temps en réseau aussi mais je ne sais pas si c'est encore le cas

  • [^] # Re: Ne pas raconter n'importe quoi non plus...

    Posté par (page perso) . En réponse à la dépêche Matériel libre : état des lieux après l’échec de la campagne de financement Talos. Évalué à 7.

    Sans aller jusqu'à tout mettre à la poubelle, je me dis surtout que cette expérience et les qq autres sur le matériel libre montrent juste que la maitrise totale et absolue d'un équipement n'est qu'une caractéristique appréciable parmi d'autres pour un produit et que c'est TRES loin d'être un saint graal pour la grosse majorité des consommateurs… Et visiblement, le manque de liberté du matériel actuel ne semble pas gêner grand monde…

    Les jours où un programmeur solitaire ou un groupe de codeurs amateurs pouvaient changer le monde ont disparu depuis longtemps, principalement à cause du verrouillage du matériel discuté plus haut.

    Si c'est toujours largement possible mais pas sur le plan du matos. Le matériel est devenu un consommable (pour le meilleur ou pour le pire) et c'est devenu un marché de masse qui ne peut être bouleversé que par un énorme apport d'argent. Ce qui exclut d'office les popols dans un garage effectivement…
    Mais les possibilités de bouleverser le monde existent toujours dans le logiciel et on a pas fini d'en voir le bout…
    Et puis je me dis que pour bouleverser un marché, faut pas essayer de refaire ce qui existe déjà avec juste un détail qui change, ça n'a pas de sens. Il faut faire un truc vraiment nouveau, pas une resucée de carte mère en moins bien.

  • [^] # Re: MISC c'est bien mais ...

    Posté par (page perso) . En réponse au sondage Quel est votre magazine papier préféré ?. Évalué à 7.

    Moi, j'adore MISC car ça réveille mon coté maso en me rappelant à quel point je suis nul dans certains domaines…
    Mais ça a l'avantage d'ouvrir les horizons aussi :)

  • [^] # Re: Un logiciel pour les sauvegarder tous

    Posté par (page perso) . En réponse au journal [Tuto/HowTo] Sauvegarder la Base de données de phpBB sur ubuntu/debian/raspbian avec automysqlbackup. Évalué à 3.

    Moi, j'utilise avec bonheur backupmanager depuis des années et ça marche au poil. Il gère aussi les backups fichiers en plus des bases (mysql et pgsql), les rotations d'une manière un peu basique mais suffisante dans la grande majorité des cas et il prend aussi en charge l'externalisation sur un FTP, rsync, S3 et qq autres trucs.

    Bref, un petit soft parfaitement adapté pour sauvegarder des sites web.

  • [^] # Re: Agentless, danger

    Posté par (page perso) . En réponse au journal Déploiement et automatisation avec Ansible - partie 1. Évalué à 3.

    Après, y'en qui gèrent les agents Puppet avec Ansible :D

  • [^] # Re: Agentless, danger

    Posté par (page perso) . En réponse au journal Déploiement et automatisation avec Ansible - partie 1. Évalué à 2.

    Puppet fait du dry-run relativement propre mais ne peut pas faire de magie non plus. Si une étape a besoin d'un élément généré ou récupéré par l'étape précédente, forcément, ça va finir en erreur. Encore plus si c'est une commande qui est exécutée et non pas une directive interne.
    Mais Ansible aurait fait la même chose…

  • [^] # Re: Agentless, danger

    Posté par (page perso) . En réponse au journal Déploiement et automatisation avec Ansible - partie 1. Évalué à 3.

    L'avantage des agents ne se situe carrément pas là. Que ce soit Puppet ou Ansible, si tu fais une erreur avec la conf de ton firewall ou un autre truc sensible alors tu dis au revoir à ton serveur. Je vois pas de différence fondamentale à ce niveau.

    Non, la GROSSE différence entre Puppet et Ansible, c'est la vitesse d'exécution : Ansible est leeeeeeeeent à coté de Puppet…
    Mais bon, le coté plus "facile" et l'absence d'install d'agent d'Ansible le rend quand même vachement pratique mais c'est affreusement leeeeeeeent.
    Un autre truc aussi mais c'est pas tellement lié à l'agent mais plutot à la façon dont le machin est branlé, c'est quand on fait un "dry-run" en Puppet, c'est une vraie simulation relativement propre et assez fiable dans son ensemble. Un "--check" sous Ansible (qui est l'équivalent) va quand même faire certains trucs pour de vrai (notamment les installs de packages - hé oui ! surprise ! ). C'est absurde mais c'est comme ça.
    Idem pour les messages d'erreur ou d'alerte, Ansible s'est amélioré mais il reste quand même assez nul globalement…

    Mais bon, malgré tout ça, j'utilise Ansible quotidiennement et j'ai laché Puppet depuis plus d'1 an (car il fallait bien choisir à un moment)…

  • [^] # Re: plein de questions :)

    Posté par (page perso) . En réponse au journal Déploiement et automatisation avec Ansible - partie 1. Évalué à 2.

    1 . c'est pas necessaire
    2. ansible a specifiquement besoin que les serveurs soient déclarés dans l'inventory (ou alors on peut juste lancer des commandes en live mais on perd l'interet du playbook)
    3. pas necessaire
    4. l'utilisateur que tu veux. Tu peux aussi definir un utilisateur sudo
    5. n'importe quelle méthode d'authentification du moment que ca marche avec SSH

  • # inventory

    Posté par (page perso) . En réponse au journal Déploiement et automatisation avec Ansible - partie 1. Évalué à 3.

    Voici ma configuration actuelle, à noter que j'ai modifié mon /etc/hosts et mon .ssh/config pour que ça pointe vers les bons serveurs avec les bonnes clés SSH :

    C'est pas nécessaire de bricoler son host, toutes les options existent pour donner les informations utiles dans l'inventory directement : user de connexion, port, ip, user "become" (sudo), clé, etc

  • [^] # Re: Zerobin

    Posté par (page perso) . En réponse au journal PrivateBin sécurise vos partages de texte en version 1.1. Évalué à 2.

    Super nouvelle ! Si ton instance est publique, n'hésite pas à l'ajouter à la liste :-)

    Non désolé, je la garde en mode privé exclusivement pour des échanges avec des clients…

  • [^] # Re: Zerobin

    Posté par (page perso) . En réponse au journal PrivateBin sécurise vos partages de texte en version 1.1. Évalué à 2.

    C'est pas du Node non plus :)

    Et je confonds pas Java et Javascript… c'est juste que j'étais persuadé que c'était vraiment fait en Java. Je sais pas pourquoi…