5.4 KiB

Raw Blame History

Administration du serveur

⚠ Si tu veux installer ton propre serveur, tu peux sauter à la section Installation.

Les principaux paramètres du serveur sont configurés dans le fichier host_vars/127.0.0.1.yml. Ensuite, le dossier roles abrite des recettes pour le système de base (common), pour le serveur web et les utilitaires associés (webserver) et pour le DNS (nameserver). Ces recettes sont appelées dans site.yml qui définit leurs paramètres spécifiques.

Gestion des utilisateurices

Pour créer un nouveau compte utilisateurice, il faut le déclarer dans la configuration du serveur:

  - name: username
 (- sudo: true)
  - key: "clé publique SSH (format ~/.ssh/authorized_keys)"

Configuration

Les principales directives de configuration du serveur sont expliquées dans cette section.

hostname

Définit le nom de domaine principal associé au serveur.

hostname: fr.tild3.org

users

Définit une liste d'utilisateurices configuréEs sur la machine. Chaque utilisateurice est un dictionnaire comprenant une clé 'name' portant son pseudonyme, une clé 'key' portant sa clé publique, et une clé optionnelle sudo contenant un booléen (true/false) pour définir si l'utilisateurice doit pouvoir exécuter des commandes admin.

users:
  - name: user1
    key: "-- REMPLACEZ MOI PAR UNE CLÉ SSH --"
  - name: new_admin
    sudo: true
    key: "-- REPLACEZ MOI PAR UNE CLÉ SSH --"

peers

Définit les serveurs amis, et nous permet de stocker des informations à leur propos et notamment des clés publiques. Chaque peer est un dictionnaire contenant les clés suivantes :

peers:
  - name: ns1.tildeverse.org
    key: "-- REMPLACEZ MOI PAR UNE CLÉ SSH --"
    fingerprint: "-- REMPLACEZ MOI PAR UNE FINGERPRINT SSH --"

La clé SSH définie ici ouvre automatiquement un accès SSH chrooté aux serveurs pairs, pour leur permettre de mettre à jour leurs secrets sur notre serveur. Ce processus est notamment utilisé par le rôle nameserver pour échanger de façon sécurisée les clés (symmétriques) TSIG afin de sécuriser les mises à jour des zones DNS.

L'empreinte de clé définie dans la clé fingerprint correspond à la clé publique du serveur SSH du serveur pair. Cela nous permet de vérifier qu'une tierce personne n'est pas en train d'extirper nos secrets.

Installation

Alors tu veux monter ton petit serveur? Chouette, on espère que tu vas trouver ici des recettes pour te permettre d'avancer. Pour appliquer notre recette, il te faut un serveur sous Debian 10 (buster). Comme on utilise Ansible, on peut soit appliquer les recettes à distance par SSH, soit en local en installant ansible directement sur le serveur.

Installation à distance

Pour pouvoir appliquer la recette à distance, il faut que le serveur ait SSH d'installé et configuré. Il faut que tu puisses te connecter au serveur en tant que root, et il est conseillé d'utiliser l'authentification par clé publique.

Ensuite, il faut créer un fichier hosts à la racine du dépot pour qu'Ansible trouve le serveur auquel se connecter:

nomDuServeur ansible_host=monserveur.example.com ansible_user=root

👍 Si tu souhaites utiliser Tor pour configurer ton serveur, il te suffit de configurer ton client SSH pour passer par Tor. Ansible ne fait rien d'autre qu'exécuter des commandes en SSH. En pratique, c'est suffisamment lent pour te donner envie de faire une installation locale.

Installation locale

Pour appliquer la recette localement, il faut que ton serveur ait ansible d'installé. Si tu dois cloner le dépot directement sur le serveur, alors il faut aussi installer git.

Par exemple:

root@server:~ # apt install ansible git
...
root@server:~ # git clone https://tildegit.org/tilde-fr/infra

Appliquer la recette

Pour pouvoir appliquer la recette, il faut modifier le fichier de configuration config.yml. Celui fourni dans le dépot est le fichier de configuration de ~fr, mais il y a un fichier de config par défaut qu'il suffit de copie à la place :

$ cp config.default.yml config.yml

Pour une configuration minimale, il faut au moins changer le hostname (en mettant ton nom de domaine) et la clé SSH (voire le nom) de l'utilisateurice. Le reste de la configuration est décrit dans la section Configuration.

Enfin, pour appliquer les changements, il faut lancer le playbook ansible. On utilise pour cela le script deploy.sh. Par défaut, la recette est appliquée localement et il faut donc la lancer en root. Si un argument "remote" est trouvé, alors la recette est exécuté sur le serveur défini dans le fichier hosts.

# Exécuter la recette à distance
user@client:~/infra $ ./deploy.sh remote
...
# Appliquer la recette localement
root@server:~/infra $ ./deploy.sh

Additionnellement, deploy.sh accepte un argument check qui déclenche une simple vérification de la syntaxe Ansible. Enfin, la commande accepte également un argument "debug" ou "-vvv" qui envoie "-vvv" à Ansible, et un argument "verbose" ou "-b" qui envoie "-v" à ansible. En résumé :

deploy.sh [remote|check|debug(-vvv)|verbose(-v)] ..
  check: vérifie la syntaxe ansible
  remote: applique la recette sur un serveur distant (défini dans ./hosts)
  debug: active le mode debug de ansible (afficher TOUT)
  verbose: active le mode verbose (afficher les résultats des tâches modifiées)

5.4 KiB Raw Blame History