Journal Faciliter la configuration d'un ordinateur portable (ou fixe) sous Debian GNU/Linux 10 (Suite)

Posté par  . Licence CC By‑SA.
12
24
mai
2020

Bonjour à tous,

Dans un journal précédent j'évoquais un projet nommé my-deb-laptop-bash développé en bash et permettant de faciliter la configuration d'un ordinateur portable (ou fixe) sous Debian GNU/Linux 10 Buster.

Aujourd'hui, je viens vous parler d'un nouveau projet similaire nommé my-deb-laptop-ansible, et développé avec ansible.

En résumé, il s'agit de :
- faire une installation classique d'une Debian 10 Buster
- installer des pré-requis (ansible, openssh, clé ssh, git, etc.)
- télécharger le code du projet avec git
- éventuellement paramétrer les éléments optionnels
- lancer la commande make pour dérouler le code ansible

note: L'ordinateur est à la fois le client et le serveur ansible

j'ai détaillé l'ensemble de la procédure et les actions réalisées dans le fichier README.md du projet.

Ce projet me permet:
- d'apprendre à développer avec ansible,
- de consigner dans un endroit unique l'ensemble des actions que je réalise à l'issue de l'installation de Debian,
(pour moi, ansible est plus lisible, maintenable et beaucoup plus rapide à développer que avec bash)
- de pourvoir réinstaller mon système facilement et rapidement,
- de pouvoir expliquer et échanger autour des configurations que je réalise et identifier tout ce qui pourrait être amélioré,
- de pouvoir facilement installer un parc de plusieurs poste de travail sous Debian,
- de pouvoir intervenir sur des "install party" avec debian.

Pour l'instant, je ne l'ai testé que sur mon ordinateur. (Dell XPS 13 9350)
Il devrait normalement fonctionner sur d'autres ordinateurs x86-64 (même récents)

Évidemment, c'est un peu plus compliqué et plus long que d'installer directement une Ubuntu ou un Mint Debian Edition, mais cela permet d'être plus prêt de Debian, et d'avoir plus de paramétrages de manière automatisée.

Par exemple:
- retrouver les configurations de gnome à l'identique, (extensions, raccourcis, etc.)
- avoir usbguard installé et configuré pour protéger les ports usb,
- avoir dnscrypt-proxy installé et configuré,
- restaurer les connexions wifi,
- restaurer les bookmarks de Firefox,
- installer les packages supplémentaires,
- installer des paramétrages de sécurité, (nftables, apparmor, seccomp, etc.)
- appliquer des contournements spécifique au matériel,
- etc.

N’hésitez-pas à tester et à me faire part de vos remarques.

En tout cas, j'espère que cela pourra servir à certains d'entre vous…

  • # pas besoin de ssh

    Posté par  . Évalué à 10 (+10/-0).

    Si tu veux exécuter ton playbook localement, tu n'as pas besoin de te connecter à localhost en SSH.

    sudo apt install ansible git
    git clone https://gitlab.com/stephane.gambus/my-deb-laptop-ansible.git
    cd my-deb-laptop-ansible
    ansible-playbook -b --connection=local playbook.yml
    

    Voir aussi : ansible-pull

    Par ailleurs, plutôt que de faire un sed sur /etc/ansible/ansible.cfg, tu peux faire un ansible.cfg à la racine de ton repo. Par contre il faudra être dans le dossier quand tu exécute ansible-playbook pour qu'il soit lu, cf ansible configuration settings location

    • [^] # Re: pas besoin de ssh

      Posté par  . Évalué à 1 (+1/-1).

      Pour la gestion d'une seule machine en local, le ssh peut en en effet sembler un peu beaucoup too much, mais pour avoir eu le loisir de jouer un peu avec ansible, j'ai pu constater que la connexion n'est pas toujours évidente et qu'un mode de connexion harmonisé aux différents hôtes est pratiquement indispensable pour un fonctionnement normal d'ansible (sans quoi la délégation peut avoir des ratés, notamment). Donc, à mon sens, que ce soit pour gérer plusieurs machines ou garder la possibilité de séparer le contrôleur ansible, la connexion ssh n'est pas dénuée d'intérêt (et réserver la notion de "local" aux opérations propres au contrôleur ansible).

      ++
      Gi)

    • [^] # Re: pas besoin de ssh

      Posté par  . Évalué à 1 (+1/-0).

      Merci de vos retours particulièrement enrichissants !

      Voici ce que j'ai réalisé:
      - ajout de l'option "--connection=local" sur l'appel de ansible-playbook dans le fichier Makefile.
      - ajout du fichier ansible.cfg à la racine du projet
      - modif du fichier README.md

      Cela fonctionne à merveille en local.

      Par contre, j'ai regardé docker-pull, et je n'ai pas encore bien saisi le fonctionnement.

      De ce que je comprends, pour que cela fonctionne à la fois en localhost et sur un client ansible distant, il faudrait:
      - préciser dans le fichier host
      [remote]
      192.168.10.24 ansible_connection=ssh ansible_user=foo

      [local]
      127.0.0.1

      • remplacer dans le Makefile "ansible-playbook" par "ansible-pull"
      • installer un serveur ssh + générer clé plublique/privée
      • faire des actions sur 192.168.10.24 sur host [local]
        • installer un client ssh
        • ajout de clé ssh publique du serveur ansible (celle du host [local] )
        • initier une première connexion ssh sens [remote] --> [local] et répondre 'yes'
        • faire quelque chose dans dans crontab ?

      En tout cas, cela simplifie grandement la liste des actions pré-requises !

      • [^] # Re: pas besoin de ssh

        Posté par  . Évalué à 4 (+2/-0).

        En fait ansible-pull c'est juste un script de fainéant qui va cloner ton repo et exécuter localement le playbook avec une seule commande. Mais c'est équivalent aux commandes que j'ai posté dans mon précédent commentaire.

        En fait, quand tu utilises --connection=local, il exécute le playbook localement. Donc si ton playbook contient :

        - hosts: foo
        

        Il va considérer que l'hôte local est foo. Il va chercher foo dans ton fichier hosts et trouver ainsi les variables correspondantes dans group_vars/ et host_vars/. Si tu n'as qu'une seule machine dans ton inventaire, tu peux utiliser all dans ton playbook comme c'est le cas actuellement.

        Personnellement, j'ai toujours utilisé des noms d'hôtes, donc je ne sais pas ce que ça donne si tu mets directement des adresses IP dans ton inventaire.

        J'étais parti du principe que tu l'utilisais juste localement à l'install.

        Si tu veux utiliser à la fois les connections locales et SSH, il faudra soit avoir un playbook dédié à l'utilisation locale, soit utiliser ansible_connection dans ton inventaire pour cibler ta machine locale (et ne pas utiliser l'argument --ansible-connection=local)

        Attention, comme dit le commentaire plus haut, ça peut poser problème de mixer les connections SSH et locales avec plusieurs machines à gérer, notamment si tu utilises des délégations, ou certains modules comme synchronise.

        <ma vie>
        Je gère mes machines perso avec ansible. 2 VPS et 2 laptops (boulot et perso). C'est pour des besoins assez simple, toutes mes machines sont différentes (pas de LB/failover) donc j'ai un playbook par machine et je n'utilise pas de délégation.
        J'utilise SSH pour les serveurs. Pour les laptops, j'ai un cron qui récupère mon repo et exécute localement le playbook correspondant à la machine. Si je fais une modif je la pousse sur les serveurs et les laptops l'appliqueront lorsqu'ils seront allumés.

        Par contre, actuellement je ne vois pas le résultat des exécutions cronées. Faut que je me décide entre :
        * une bête alerte renvoyée par le cron si l'exécution renvoie une erreur
        * rediriger l'output dans un log et centraliser les logs sur un serveur
        * utiliser ARA
        </ma vie>

        • [^] # Re: pas besoin de ssh

          Posté par  . Évalué à 0 (+0/-0).

          Personnellement, j'ai toujours utilisé des noms d'hôtes, donc je ne sais pas ce que ça donne si tu mets directement des adresses IP dans ton inventaire.

          Ça marche très bien aussi les adresses IP :) Ou même des alias en tout genre, définis au niveau de ton /etc/hosts ou au niveau de ton ~/.ssh/config …parce-qu'au final, Ansible s'appuie sur ton SSH (du moins pour ce type de connexion, le local par exemple étant légèrement différent)

          Pour aller plus loin, tu peux utiliser des alias Ansible… le nom défini dans l'inventaire sera utilisé comme item/host affiché lors du déroulement, mais le nom/adresse/alias (complet ou court) utilisé en vrai (donc passé à l'appel SSH sous-jacent) est donné alors par la variable d'hôte ansible_host

        • [^] # Re: pas besoin de ssh

          Posté par  . Évalué à 0 (+0/-0).

          Petite remarque intéressante

          Par contre, actuellement je ne vois pas le résultat des exécutions cronées. Faut que je me décide entre :
          * une bête alerte renvoyée par le cron si l'exécution renvoie une erreur
          * rediriger l'output dans un log et centraliser les logs sur un serveur
          * utiliser ARA

          Pour le premier point, il me semble que c'était le cas par défaut (je mets l'imparfait parce-que je ne jure de rien avec systemd) Quand il y a une erreur, ou si une sortie est générée, alors tu en auras une trace dans les journaux. De plus, les systèmes traditionnels, pourvu que tu actives l'option (une variable à positionner), un mail est alors envoyé au propriétaire de la crontab en cas d'erreur ou si une sortie est générée. Par contre, si l'envoie de messages n'est pas configuré, ces messages vont juste se retrouver dans le fichier de messages localement. (les gens ne le savent pas toujours et laissent le spool gonfler ad vitam eternam…)

          Pour le second point, Ansible a une directive prévue à rajouter dans le ansible.cfg dans la section [default] : log_path = chemin/vers/le/fichier/de/log …Il faut juste que ce fichier puisse être écrit par le compte avec lequel tu lances les commandes ansible*
          C'est presque comparable au fait de faire suivre l'exécution de son playbook par des redirections (ou mieux | tee quand on est devant), mais en mieux car ça a une vraie tête de journal : les lignes sont précédées de l'horodatage ainsi que le compte et le PId exécutant ; ce qui est pratique bien des fois.

          ARA est l'étape au dessus : ça défini juste une autre sortie parallèle qui enregistre les informations dans une base de données et permet ensuite de consulter la métrologie via une interface web (bon, en vrai il y a une API pas mal aussi ce qui fait que les usages peuvent être repensés/démultipliés) Cette couche supplémentaire a de l'intérêt quand on travaille quotidiennement et en équipe avec Ansible et qu'on n'est pas prêt à des solutions plus lourdes comme Tower/AWX.

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n’en sommes pas responsables.