zaft a écrit 30 commentaires

  • [^] # Re: pourquoi BlueBanquise ?

    Posté par  . En réponse à la dépêche Pile de logiciels libres de déploiement et gestion de grappes de serveurs ou de parc. Évalué à 2.

    Ha ben non, si c'est l'âme de poète qui parle faut laisser. Ce qui me fait user de ces mots sévères, c'est :
    - la présentation sur le site web semble attribuer des qualités (la modularité, la flexibilité) à BlueBanquise, alors qu'elles me semblent plutôt inhérentes à ansible.
    - le fait que ça me fait penser à la tendance qu'on observe par exemple en sécurité, où dès qu'une faille est trouvée, on y consacre un nom de domaine, un site web et un logo…

    Présenter explicitement BlueBanquise comme une collection pour Ansible

    Merci beaucoup !
    Je vais reprendre le site web avec ces commentaires. Effectivement, après relecture, le site n'est pas assez précis sur ces points, et sur l'aspect collection de roles Ansible.
    Et puis je venais de découvrir le framework css Bulma au moment de coder ce site, et je me suis un peu lâché…

    j'ai bossé pour une fameuse entreprise française qui pour son HPC prenait soin de faire des surcouches à Yum et Puppet pour rendre le truc moins efficace et déposer du brevet

    Si j'avais eu ce genre de truc à l'époque où je déployais des (tout petits) clusters HPC, ça m'aurait épargné les procédures de 400 pages qui permettaient même pas d'aboutir =D

    Idem ici, on est tous passé par là j'ai l'impression ;)

  • [^] # Re: ah tien ça fait comme GLPI ?

    Posté par  . En réponse à la dépêche Pile de logiciels libres de déploiement et gestion de grappes de serveurs ou de parc. Évalué à 1.

    Merci de l'info ! Je vais regarder du coté de NetBox aussi.

    Je me demande par contre comment, sans avoir 2 inventories Ansible empilés, ce qui est faisable mais peu ergonomique, comment mettre des variables à des groupes d'équipements (types) du coté de NetBox.

  • [^] # Re: Encore de l'Ansible...

    Posté par  . En réponse à la dépêche Pile de logiciels libres de déploiement et gestion de grappes de serveurs ou de parc. Évalué à 1.

    Oups, merci :)

  • [^] # Re: ah tien ça fait comme GLPI ?

    Posté par  . En réponse à la dépêche Pile de logiciels libres de déploiement et gestion de grappes de serveurs ou de parc. Évalué à 1.

    Merci pour le tuyau :-)

    Je vais aller regarder du coté de GLPI et fouiller dans leur documentation.

  • [^] # Re: pourquoi BlueBanquise ?

    Posté par  . En réponse à la dépêche Pile de logiciels libres de déploiement et gestion de grappes de serveurs ou de parc. Évalué à 3.

    A Auray :-)

    On tente une approche différente : en tant que FabLab, on ne croule pas sous l'or, donc on a pris le parti de recycler des calculateurs usagés, souvent retirés de production faute de maintenance / support.
    Nous leur donnons une seconde vie en mode "on fait ce qu'on peut", et partant du principe que lorsqu'un serveur tombe en panne, il devient pièces détachées pour les autres. La machine sert aussi à chauffer nos locaux.

    Pour notre premier calculateur, le CINES de Montpellier nous a fait don d’une machine en Sandy Bridge (si vous lisez ceci, merci encore !!!!). Ce n’est pas de toute jeunesse, mais largement suffisant comme calculateur d’échelle locale.

    La machine a vocation à être accessible aux universités, aux PME, et aux autres FabLabs. Pour le moment, elle a surtout fait du rendu Blender et des calculs durant le confinement (https://www.ouest-france.fr/sante/virus/coronavirus/algoric-un-supercalculateur-breton-contre-le-covid-19-6811820), mais on monte en charge. L'idée est aussi de former au calcul parallèle et à l’administration système Linux de base.

  • [^] # Re: pourquoi BlueBanquise ?

    Posté par  . En réponse à la dépêche Pile de logiciels libres de déploiement et gestion de grappes de serveurs ou de parc. Évalué à 3.

    Oui, c'est un ensemble cohérent de roles Ansible. On peut donc y brancher d'autres roles ou modifier les existants.

    Le nom, le site web, et le logo… Fantaisie de concepteur, par "amour" pour sa création, rien de plus.
    Il y a comme premier objectif derrière cette stack le besoin de faire tourner le calculateur d'un FabLab en Bretagne, surtout pas d'en faire du business. Donc si le site fait bullshit marketing, alors le coup est raté et je dois le reprendre. Des suggestions ?

    Le concept est effectivement de ne pas faire de surcouche, pour permettre d'utiliser les documentations en ligne, ou trouver facilement sur le web en cas de bug / soucis / besoin de développement. Et aussi pour des raisons de maintenance : surcouche = besoin de maintenance à chaque mise à jours des outils sous la surcouche.

    Concernant le déploiement du premier noeud, il faut déposer les répos "vitaux" (OS + BlueBanquise), les configurer en mode file:///, et monter l'interface réseau principale afin que Ansible puisse ssh vers la bonne ip. Ensuite, tout se fait via Ansible.

    Donc étape 1, effectivement manuelle: https://bluebanquise.com/documentation/install_first_management.html
    Puis étape 2, cette fois via Ansible: https://bluebanquise.com/documentation/deploy_bluebanquise.html#management-configuration

    Tu suggérerais de remplacer aussi l'étape 1 par un bootstrap via Ansible ?

  • [^] # Re: ah tien ça fait comme GLPI ?

    Posté par  . En réponse à la dépêche Pile de logiciels libres de déploiement et gestion de grappes de serveurs ou de parc. Évalué à 2.

    J'avoue mal connaître GLPI, impossible de répondre avec certitude.

    BlueBanquise ne gère pas de CMDB. C'est a design, et aussi par rejet des databases overkill que l'on croise dans le HPC. L'ensemble des données sont stockées dans l'inventaire Ansible (~= pillars Salt), au format text (YAML). Cela donne des inventaires certes lourds, mais qui ont le mérite de rester éditables par des néophytes.

    BlueBanquise me sert aussi de base pour la formation de jeunes admin système. Ils peuvent démanteler les différents roles, et comprendre comment se déploient un DHCP, un DNS, comment fonctionne le PXE, etc. Tout doit donc être "lisible" via un coup de cat/vi. Nous tentons de tout garder au plus simple et de nous conformer aux standards.

    Le HPC ressemble un peu au cloud : des centaines de serveurs clones, et surtout des soucis de réseau et de hardware. La particularité va aussi résider dans la présence d'un ordonnanceur (le job scheduler, ici Slurm (Linux mag 185, super article dessus)) qui va dispatcher les "jobs" (des scripts à executer, des programmes à executer, etc) des utilisateurs sur les différentes ressources disponibles et permettre un usage partagé et si possible équitable du calculateur.

  • [^] # Re: Encore de l'Ansible...

    Posté par  . En réponse à la dépêche Pile de logiciels libres de déploiement et gestion de grappes de serveurs ou de parc. Évalué à 5.

    Oui, remyd1 a raison, la première version de ce projet reposait sur Salt Stack. J'utilise Salt, Puppet et Ansible dans mon emploi, sans réelle préférence. Chacun a ses avantages et inconvénients.

    Mais je me suis heurté à deux gros soucis avec la première monture:

    1. La grande majorité des utilisateurs qui avaient testé la stack se heurtaient à la difficulté de Slack. Bien que je trouve Slack puissant et flexible, il semble que cet outils soit plus complexe de premier abord pour des néophytes.

    2. Le support. J'ai tenté plusieurs fois de proposer la stack sur Slack à des professionnels, et à chaque fois le retour était : "Pas de support RedHat, pas intéressant". RedHat est particulièrement bien implanté dans le HPC.

    Souhaitant pouvoir faire usage de Banquise dans mon emploi aussi, j'ai donc migré vers Ansible, qui semble plus simple (mais plus limité, on a rien sans rien) et qui bénéficie du support RedHat.
    J'ai donc ré-implémenté Banquise, ce qui a donné BlueBanquise. Voilà pour la raison du choix d'Ansible.

    Ces outils sont des tentatives de proposer des alternatives aux lourdes stacks existantes dans le monde du HPC. Ce sont (je l'espère, on s'y efforce) des micro stacks, sans surcouches, et très modulaires.

  • # Lien mort, mise à jours

    Posté par  . En réponse à la dépêche Outil de déploiement et de configuration d'un cluster HPC ou d'un réseau de machines : Banquise. Évalué à 1.

    Si le lien sur Slack ne fonctionne plus, en voici un nouveau:

    Conversation Banquise sur Slack

  • [^] # Re: Moi y en a bien parler la France

    Posté par  . En réponse à la dépêche Outil de déploiement et de configuration d'un cluster HPC ou d'un réseau de machines : Banquise. Évalué à 4.

    Dans une démarche d'amélioration, car j'ai conscience qu'à force de travailler en milieux anglophone on peut dériver, voici ce que j'ai pu trouver :

    "manager" existe bel et bien, sous forme de verbe ou de nom. Il est référencé dans le dictionnaire Larousse.

    Pour les autres, je reconnais l’usage de la langue de Shakespeare en lieu et place de celle de Molière, et si cela a pu surprendre je m’en excuse, tel n’était pas l’objectif :-)

  • [^] # Re: Donc besoin d'une passerelle quelque part

    Posté par  . En réponse au message Vlan local derrière box pour isoler pc safes. Évalué à 1.

    La doc telnet du tg788vn fait 1561 pages. Ca promet. Mais apparemment il y a ce que je cherche.

    https://lafibre.info/images/materiel/201302_thomson_tg788_guide_reference_telnet.pdf

    eth vlan
    Following commands are available :
    add : Add a new virtual LAN.
    delete : Delete a virtual LAN.
    list : Display all virtual LAN's.
    flush : Flush all virtual LAN's.

    Je reviens vers vous dés que j'ai réussi à configurer quelque chose.

  • # Donc besoin d'une passerelle quelque part

    Posté par  . En réponse au message Vlan local derrière box pour isoler pc safes. Évalué à 1.

    Merci pour vos réponses.

    Je comprend donc que sans rajouter une passerelle, la box est trop limitée pour faire des VLAN comme je le souhaite (quoi que à vérifier, je ne savais pas pour les commandes telnet, merci pour l'info, je vais explorer la chose, surtout si il est possible d'isoler le wifi de l'ethernet).

    Étant donné le débit ridicule que j'ai sur mon ADSL, un Raspberry avec 1-2 cartes réseau USB à 4€ suffira pour faire le lien. Je n'ai besoin du Gb qu'entre les PC safes.

    Concernant le Vlan 1 (que j'appelais Vlan 0), ce n'est pas ce qu'on appel le Vlan natif ? J'avoue, je débute dans les VLAN.

  • [^] # Re: Le FTP est un protocole sale

    Posté par  . En réponse au message Règle iptables pour serveur vsftpd. Évalué à 1.

    Un peu à la bourre.

    C'est noté. Je vais donc être prudent avec ces protocoles et tenter de les éviter (remplacer le ftp par http par exemple).

    Merci beaucoup !!

  • [^] # Re: Le FTP est un protocole sale

    Posté par  . En réponse au message Règle iptables pour serveur vsftpd. Évalué à 1.

    En retard.

    Bon, ca ne marche toujours pas en rajoutant la chaine.

    Le log :
    [ 2991.605932] iptables_INPUT_denied: IN=enp0s3 OUT= MAC=08:00:27:a6:8f:9f:08:00:27:7c:85:5b:08:00 SRC=172.16.0.3 DST=172.16.0.2 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=18738 DF PROTO=TCP SPT=50209 DPT=57719 WINDOW=14600 RES=0x00 SYN URGP=0

    Ca bloque donc sur les ports 50000 et des poussières. Si j'ouvre ces ports ca marche.
    Mon iptable :

    # Generated by iptables-save v1.4.21 on Mon Nov  2 05:43:07 2015
    *filter
    :INPUT ACCEPT [0:0]
    :FORWARD ACCEPT [0:0]
    :OUTPUT ACCEPT [43:46568]
    -A INPUT -p icmp -j ACCEPT
    -A INPUT -i lo -j ACCEPT
    -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
    -A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
    -A INPUT -i enp0s3 -p tcp -m state --state NEW -m tcp --dport 21 -j ACCEPT
    -A INPUT -i enp0s3 -p tcp -m tcp --dport 1024:65535 -m helper --helper ftp -m conntrack --ctstate RELATED -j ACCEPT
    -A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables_INPUT_denied: " --log-level 7
    -A INPUT -j REJECT --reject-with icmp-port-unreachable
    -A FORWARD -m limit --limit 5/min -j LOG --log-prefix "iptables_FORWARD_denied: " --log-level 7
    -A FORWARD -j REJECT --reject-with icmp-port-unreachable
    COMMIT
    # Completed on Mon Nov  2 05:43:07 2015
    

    Mais en y regardant de plus près, la chaine utilise le helper ftp, et le module nf_coontrack_ftp a besoin d'être chargé pour ça.
    Donc un modprobe nf_conntrack_ftp, et là ça marche avec la chaine que tu m'as donné.
    Impeccable donc, j'ai mon serveur avec SELinux et Iptables de up, c'est pas mal.

    Après j'avoue ne pas connaitre ce système de helper. Ca s'utilise pour d'autres choses que les cas particuliers comme le ftp passif ? Parceque j'ai encore pas mal de serveurs à poser et je débute encore dans la matière, autant que je prenne le temps d'explorer la chose si ça vaut le coup… :-)

  • [^] # Re: Log

    Posté par  . En réponse au message Règle iptables pour serveur vsftpd. Évalué à 1.

    Merci pour l'info. J'ai cherché pas mal de temps, et finalement chez moi par défaut (Centos 7), ca tombe dans la console donc dans dmesg. Je vais modifier ça pour que rsyslog le pose dans un /var/log/iptables.log.

  • [^] # Re: Log

    Posté par  . En réponse au message Règle iptables pour serveur vsftpd. Évalué à 1.

    Merci du conseil. Un truc dans ce genre (google) ?

    -A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables_INPUT_denied: " --log-level 7

    Je vais essayer. Je suppose que ca tombe dans /var/log/messages.

  • [^] # Re: Peut être salt-call

    Posté par  . En réponse au message Obtenir des logs/debug plus exploitables avec SaltStack. Évalué à 1.

    Effectivement, salt-call permet un tracé précis à partir du minion.

    Si cela peu aider d'autres personnes :-)

    Sujet résolu.

    Zaft

  • # Peut être salt-call

    Posté par  . En réponse au message Obtenir des logs/debug plus exploitables avec SaltStack. Évalué à 5.

    Apparemment (après beaucoup de recherches), il faut utiliser salt-call, mais la commande ne fonctionne qu'en local, sur un minion et non sur le master (salt-call -l debug state.highstate).

    Ce sera en principe suffisant cependant pour comprendre l'origine du problème, je teste ça et je reviens poster ce que ça donne, au cas où d'autres cherchent la même chose que moi.

  • [^] # Re: nom de domaine de recherche dans /etc/resolv.conf

    Posté par  . En réponse au message Serveur DNS, pb de résolution sans nom du domaine. Évalué à 1.

    Effectivement, avec ping ça fonctionne (idem avec ssh et autre) :

    # ping pxe
    PING pxe.sphenclust.local (10.0.0.4) 56(84) bytes of data.
    64 bytes from pxe.sphenclust.local (10.0.0.4): icmp_seq=1 ttl=64 time=0.470 ms
    64 bytes from pxe.sphenclust.local (10.0.0.4): icmp_seq=2 ttl=64 time=0.546 ms
    ^C
    --- pxe.sphenclust.local ping statistics ---
    2 packets transmitted, 2 received, 0% packet loss, time 1001ms
    rtt min/avg/max/mdev = 0.470/0.508/0.546/0.038 ms

    J'en ai presque honte, j'aurais du pinger pour voir. J'ai bien testé sur les clients, RAS.

    Merci beaucoup pour votre aide, ca fonctionne parfaitement maintenant :-)

  • [^] # Re: mise en forme

    Posté par  . En réponse au message Serveur DNS, pb de résolution sans nom du domaine. Évalué à 1.

    Compris, merci pour l'info ;-)

  • [^] # Re: nom de domaine de recherche dans /etc/resolv.conf

    Posté par  . En réponse au message Serveur DNS, pb de résolution sans nom du domaine. Évalué à 1.

    Merci du retour.

    Ca ne donne toujours rien (j'ai relancé le service au cas où j'avais oublié de le faire avant) :

        [root@dnsmaster ~]# cat /etc/resolv.conf 
        # Generated by NetworkManager
        search sphenclust.local
        nameserver 10.0.0.5
    
        # No nameservers found; try putting DNS servers into your
        # ifcfg files in /etc/sysconfig/network-scripts like so:
        #
        # DNS1=xxx.xxx.xxx.xxx
        # DNS2=xxx.xxx.xxx.xxx
        # DOMAIN=lab.foo.com bar.foo.com
        [root@dnsmaster ~]# dig pxe
    
        ; <<>> DiG 9.9.4-RedHat-9.9.4-18.el7 <<>> pxe
        ;; global options: +cmd
        ;; Got answer:
        ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 21336
        ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
        ;; WARNING: recursion requested but not available
    
        ;; OPT PSEUDOSECTION:
        ; EDNS: version: 0, flags:; udp: 4096
        ;; QUESTION SECTION:
        ;pxe.               IN  A
    
        ;; Query time: 0 msec
        ;; SERVER: 10.0.0.5#53(10.0.0.5)
        ;; WHEN: mar. août 18 11:15:48 CEST 2015
        ;; MSG SIZE  rcvd: 32
    
        [root@dnsmaster ~]# dig pxe.sphenclust.local
    
        ; <<>> DiG 9.9.4-RedHat-9.9.4-18.el7 <<>> pxe.sphenclust.local
        ;; global options: +cmd
        ;; Got answer:
        ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3713
        ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2
        ;; WARNING: recursion requested but not available
    
        ;; OPT PSEUDOSECTION:
        ; EDNS: version: 0, flags:; udp: 4096
        ;; QUESTION SECTION:
        ;pxe.sphenclust.local.      IN  A
    
        ;; ANSWER SECTION:
        pxe.sphenclust.local.   86400   IN  A   10.0.0.4
    
        ;; AUTHORITY SECTION:
        sphenclust.local.   86400   IN  NS  dnsmaster.sphenclust.local.
    
        ;; ADDITIONAL SECTION:
        dnsmaster.sphenclust.local. 86400 IN    A   10.0.0.5
    
        ;; Query time: 0 msec
        ;; SERVER: 10.0.0.5#53(10.0.0.5)
        ;; WHEN: mar. août 18 11:15:56 CEST 2015
        ;; MSG SIZE  rcvd: 105
    
        [root@dnsmaster ~]# 

    Un souci dans les fichiers de conf peut être ?

  • [^] # Re: over the rainbow

    Posté par  . En réponse au message Programme opensource - hash par rainbow tables. Évalué à 3.

    Nop, mais j'ai 128 coeurs à dispo pour faire mes tests ;-)
    L'idée est que comme la taille des rainbow grimpe rapidement, la scinder sur de multiples machines pourrait être intéressant. Idée comme ça, je n'en ai pas vraiment l'usage, c'est plus "marrant", et ca permettra de tester si les mdp que nous avons ne sont pas trop faibles (pour le moment, John The ripper, mais ca ressemble plus à un brute force basique).

    Effectivement, le sel rend les choses plus complexes, je vais étudier la chose, mais je doute que tous les softs utilisent un sel.

    Joyeuses fêtes a toi aussi ! :-)

  • [^] # Re: pistes

    Posté par  . En réponse au message Synchronisation de type P2P via ssh. Évalué à 1.

    Effectivement, d'autant que j’apprécie la robustesse des outils GNU.

    Par contre, de ce que j'ai pu voir, seul RetroShare permet une synchronisation des répertoires, les autres softs ne l'on pas encore implémenté.
    Il est en effet possible de suivre un channel : chaque utilisateur peut ajouter un nouveau fichier qui sera automatiquement envoyé aux autres. Une forme de synchronisation si bien utilisé.

    Merci de la remarque dans tous les cas :)

  • [^] # Re: pistes

    Posté par  . En réponse au message Synchronisation de type P2P via ssh. Évalué à 1.

    Mouche !

    Retroshare, c'est exactement ce que je cherchait !
    Je ne connaissait pas l'appellation Friend 2 Friend, du coup je suis passé à coté.

    Merci beaucoup, c'est parfait.

    Reste à m'assurer que le soft est clean, car il faut bien qu'il y ai un serveur quelque part pour assurer les liens entres amis…

  • [^] # Re: pistes

    Posté par  . En réponse au message Synchronisation de type P2P via ssh. Évalué à 0.

    J'ai effectivement pensé au Torrent, mais les échanges ne sont pas chiffrés, et surtout il y a ce soucis de tracker :/
    Il faudrait échanger les listes de fichiers, les comparer, et régénérer un tracker à chaque fois. Compliqué.

    Bonnes idée les GFS, mais le soucis c'est que seul le serveur peut monter/démonter des fichiers car les clients n'écoutent pas. Du coup, tout transite par le serveur, et la bande passante ne suffira pas.

    Simple question de curiosité : est-il possible, de connecter en ssh A et B à C, puis que C les aident à se connecter ensemble sans qu'ils aient de ports d'ouverts ?