Aller au contenu

Services

Vous trouverez ici décrites les différentes étapes du cycle de vie d'un service, de la décision de sa création à sa fermeture en passant par sa maintenance.

Création, installation, déploiement

Conditions d'ouverture

Avant de penser à ouvrir un nouveau service, il faut s'assurer d'avoir un objet unique et précis qui corresponde à un besoin très concret. Il faut donc vérifier que le service auquel on pense ne fasse pas entièrement ou en partie doublon avec un autre, ou qu'il ne puisse pas être intégré à une autre unité existante, ou inversement. Une fois ces conditions vérifiées, il faut effectuer les étapes suivantes dans l'ordre :

Protocole

  1. Ouvrir une issue dans https://git.felinn.org/FELINN/infra en utilisant le modèle « création de service ». Le titre doit adopter le format « [service : création] {{ nom de l'unité concernée }} » et la description doit détailler le besoin et l'objectif.
  2. L'issue doit être approuvée au niveau CC-CP-V dans le cas d'un service en production et CC-CV-V dans le cas d'un service en test ou d'un VPS.
  3. Si approuvée, l'issue doit donner lieu à la création de l'unité. L'issue ne peut être fermée que lorsque les décisions suivantes ont été prises :
    • un·e ou des membres responsables de son administration
    • mise place des permissions
    • domaine à appliquer au service :
      • {{ service }}.felinn.org pour les services en production (FELINN core)
      • {{ service }}.labs.felinn.org pour les services en test (FELINN labs)
      • {{ nom }}.{{ domaine }} pour les VPS
    • type de virtualisation :
      • LXC par défaut pour les services de la FELINN
      • KVM uniquement s'il y a besoin d'isoler le noyau (par exemple en cas d'accès root pour des personnes extérieures)
    • ressources allouées
    • logiciel pour le service en question:
      • libre de préférence, open source au minimum (la différence est notamment expliquée ici)
      • bien maintenu
      • avec une communauté active
      • léger
    • dans le cas d'une KVM, le nom d'hôte (hostname) et le login (nom d'utilisateurice régulier) désirés

Création de l'unité

Note

En complément du protocole ci-dessous, ne pas hésiter à consulter la documentation officielle de notre hyperviseur Proxmox.

Protocole

  1. Se loguer en @(ssh) sur felinn.org et mettre à jour les images disponibles avec pveam update (ou vérifier que les images sont à jour).
  2. Télécharger la dernière image disponible et stable de Debian (ou de la distribution désirée), visible sur l'interface PVE dans storage (local) ou avec la commande pveam available | grep debian. Les images sont enregistrées dans /var/lib/vz/template/cache/. S'il y a une version plus à jour, télécharger l'image system avec pveam download local debian-{{ version }}.tar.gz et pensez à supprimer les images obsolètes.
  3. Créer un container (Create CT) sur l'interface PVE (ou en ssh avec la commande pct) avec les paramètres suivants (laisser par défaut ce qui n'est pas précisé) :
    • General
      • CT-ID par défaut (le plus bas disponible). À partir de 100 pour les services FELINN et 200 pour les autres.
      • Hostname nom du service complet (avec URL) tel que décidé dans l'issue dédiée
      • Ressource pool FELINN-core, FELINN-labs ou VPS en fonction du type de service choisi
      • Password le créer dans le répertoire pass de la FELINN (voir la documentation dédiée) avec pass generate -c FELINN/{{ hostname }}/root. Cette commande génère et copie dans le presse papier pendant 45sec.
    • Template
      • choisir le dernier template debian (ou autre OS téléchargé) stable
    • Root disk
      • local-zfs
      • capacité en fonction de ce qui a été décidé (utiliser des puissances de 2, c'est la tradition 😆)
    • CPU
      • en fonction de ce qui a été décidé (il est possible de mettre plus de cœurs juste le temps de l'installation pour aller plus vite )
    • Memoire
      • en fonction de ce qui a été décidé (il est possible de mettre plus de mémoire juste le temps de l'installation pour aller plus vite !)
      • SWAP = RAM
    • Network
      • IPv4
      • 192.168.10.{{ pct_id }}/24 si c'est un service FELINN core
      • 192.168.20.{{ pct_id }}/24 si c'est un service VPS pour isoler les deux sous-réseaux
    • Gateway: 192.168.10.1 ou 192.168.20.1 en fonction de si c'est un service FELINN core ou VPS
    • Confirmation, bien relire et vérifier !
    • vous pouvez lancer le container
  4. Entrer dans le container en ssh avec la commande pct enter {{ pct_id }}.
  5. Nettoyer l'installation debian et installer les outils cool de base avec ce snippet.
    • Vérifier que la TMZ est bien paramétrée sur Europe/Paris
    • Vérifier que les locales par défaut sont bien paramétrées en EN_US.utf8
    • De préférence, activer zsh avec chsh : choisir /bin/zsh

Note

En complément du protocole ci-dessous, ne pas hésiter à consulter la documentation officielle de notre hyperviseur Proxmox.

Tip

Pour simplifier la procédure qui suit, il existe un template basé sur Debian pour les VM accessibles dans proxmox avec le nom VM-TEMPLATE. Il suffit de cloner le template et de modifier en fonction des besoins.

Warning

Assurez vous d'avoir préalablement récupéré toutes les informations nécessaires avant de vous lancer dans l'installation.

Pour créer une VM « from scratch », suivre les indications suivantes :

Préparation

Depuis l'hôte : télécharger la dernière image disponible et stable de Debian (ou de la distribution désirée), visible sur le site officiel (ici de Debian).

Sauf validation d'un option contraire lors de la décision de la création du service, il est préférable d'utiliser une image légère de type netinst.

Les images sont enregistrées dans /var/lib/vz/template/iso/. S'il y a une version plus à jour, télécharger l'image avec wget https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-{{ version }}-amd64-netinst.iso et pensez à supprimer les images obsolètes.

Création de la VM

Créer une VM (Create VM) sur l'interface PVE (ou en ssh avec la commande qm) avec les paramètres suivants (laisser par défaut ce qui n'est pas précisé ci-dessous) :

  • General
    • VM-ID par défaut (le plus bas disponible). À partir de 100 pour les services FELINN et 200 pour les autres.
    • Name nom du service complet (avec sous-domaine) tel que décidé dans l'issue dédiée
    • Ressource pool FELINN-core, FELINN-labs ou VPS en fonction du type de service choisi
  • OS
    • Use CD/DVD disc image file (iso) choisir le dernier iso debian (ou autre OS téléchargé) stable
    • Guest OS décrire le type d'OS utilisé
  • System
    • laisser par défaut
  • Hard Disk
    • local-zfs
    • capacité en fonction de ce qui a été décidé (utiliser des puissances de 2, c'est la tradition 😆)
  • CPU
    • en fonction de ce qui a été décidé (il est possible de mettre plus de cœurs juste le temps de l'installation pour aller plus vite !)
  • Memoire
    • en fonction de ce qui a été décidé (il est possible de mettre plus de mémoire juste le temps de l'installation pour aller plus vite !)
  • Network
    • MAC address générer une adresse MAC avec echo {{ $FQDN }}|md5sum|sed -E 's/^(..)(..)(..).*$/68:e1:66:\1:\2:\3/' ou laisser en auto

  • Confirm : bien relire et vérifier

  • Vous pouvez lancer la VM

Installation de la VM

Il faut désormais installer et configurer la distribution. Entrer dans la VNC de la machine virtuelle via l'interface web de PVE en cliquant sur le nom de la VM dans le menu de gauche, puis >_ Console. Cette action ouvrira une fenêtre pop-up d'un terminal de la machine (noVNC par défaut).

Si on a affaire à Debian, voici la configuration de préférence :

  • l'installation classique (la non graphique) est plus légère
  • English comme langue pour avoir les manuels d'origine.
  • Other dans Country pour éviter les problèmes de comptabilité
  • Français pour le keymap (peu d'importance dans la mesure ou aucun clavier ne sera réellement branché dessus 😆)
  • DNS name server utiliser les serveurs DNS de la FDN
  • le nom d'hôte désiré par la personne (physique ou morale) responsable de la VM
  • le FQDN pour le nom de domaine
  • générer pour root un mot de passe aléatoire de 8 caractères de long le temps de l'installation pour pouvoir l'écrire directement dans la VNC (cf. le tuto sur pass).
  • full name le pseudo désiré par lae futur·e admin
  • générer pour l'utilisateurice un mot de passe aléatoire de 8 caractères de long le temps de l'installation pour pouvoir l'écrire directement dans la VNC.
  • Europe dans continent
  • france dans country (la deuxième fois lorsque ce choix est disponible)
  • en_US.UTF-8 en configuration des locales par défaut
  • le chiffrement de la partition montée sur / implique de connaitre la phrase de passe pendant la séquence de boot. Dans certains cas, il est plus intéressant de chiffrer uniquement la partition avec les données sensible. À discuter avec l'administrateurice responsable de la VM.
  • LVM est un bon choix car on peut modifier la taille de la partition sans redémarrer la machine virtuelle (voir notamment la doc proxmox à ce sujet)
  • ne pas scanner de CD ou DVD additionnel
  • comme la VM n'est pas encore connectée, Go back pour poursuivre l'installation sans choisir de miroir
  • il n'y a pas de proxy pour les connexions sortantes
  • installer GRUB sur la seule partition proposée
Configuration du réseau
  • se loguer en root dans le VNC
  • éditer le fichier de configuration réseau debian vi /etc/network/interfaces avec nano pour configurer l'interface ens18 ou équivalente 
    1
2
3
4
5
6
7
8
    auto lo
iface lo inet loopback

auto ens18
iface ens18 inet static
    address 192.168.20.100
    netmask 255.255.255.0
    gateway 192.168.20.1
  • lancer la commande systemctl restart networking pour prendre en charge la nouvelle configuration réseau
  • tester la connexion avec la commande ping felinn.org
Configuration du dépôt de paquet
  • ajouter le miroir de Rezopole dans /etc/apt/sources.list : 
    1
2
3
    # […]
deb http://ftp.rezopole.net/debian buster main contrib
deb-src http://ftp.rezopole.net/debian buster main contrib
  • faites les mises à jours avec : 
    1
    apt update && apt full-upgrade
Configurer un accès SSH
  • installer OpenSSH sur la VM invitée 
    1
2
3
4
    apt install openssh-server

# vérifier que le service est lancé
ss -tunlp
  • autoriser sur la VM invitée une connexion SSH en root avec mot de passe dans /etc/ssh/sshd_config : 
    1
2
3
4
    # […]
# PermitRootLogin prohibit-password
PermitRootLogin yes
# […]

  • appliquer la nouvelle configuration en relançant le service: service ssh restart

  • configurer une règle NAT sur l'hôte sur un port alternatif libre dans /etc/conf.d/nat/nat.conf : 

    1
2
3
4
    #=== SSH ===#
# […]
77.95.64.26:1822 192.168.20.205:22
#           ↑port           ↑VM-ID

  • recharger la configuration NAT avec run-nat.sh

  • ouvrir une connexion SSH depuis l'extérieur avec ssh -p 1822 root@felinn.org

Sécuriser l'accès SSH

Dès que l'accès SSH est établi, il est possible de copier/coller des mots de passe compliqués. Il faut le faire pour root et le nom de l'utilisateurice.

Le mieux est d'ajouter l'utilisateurice au groupe admin avec sudo, d'ajouter une authentification par clé RSA et de désactiver le login root en SSH.

Tip

Si un enregistrement DNS A pointe vers l'IP de la FELINN 77.95.64.26 pour le domaine dédié à la VM, il est possible de se connecter avec la commande ssh -p 1822 root@domain.tld.

Pour ne plus avoir à préciser le port, il est possible d'ajouter le port alternatif à la configuration du client SSH en local sur votre machine dans $HOME/.ssh/config: 

1
2
Host domain.tld
Port 1822

Pour rendre un service web sur la VM accessible depuis l'exterieur, consulter la section sur le reverse-proxy.

Installation du service

Note

Cette section et les suivantes ne sont obligatoires que pour les services de la FELINN. Pour les VPS, chacun·e est responsable de la gestion de son service. Mais nous vous encourageons tout de même à vous inspirer de ce qui suit !

Attention

RTFM pour être sûr d'installer uniquement ce qui est nécessaire ! Si besoin, suivre des tutoriels non officiels. Ceux de DigitalOcean par exemple sont souvent des références pertinentes. Quelques bonnes pratiques en vrac :

Permissions

Pour les services web, il faut bien faire attention à les faire tourner en user:group www-data ou équivalent et jamais en root, ainsi que l'installation dans la mesure du possible.

Arborescence

  • Par convention, l'installation des services web se fait dans /var/www/{{ hostname }}.
  • Si le code est téléchargé à la main, il est possible de faire un lien symbolique : /var/www/foo.felinn.org -> /var/www/code-v1.23, ça permet de simplifier les mises à jour.

Base de données

  • utiliser postgresql de préférence pour les performance, mariadb sinon, sqlite3 en dernier recours s'il s'agit d'un service très léger et statique
  • mysql est remplacé par mariadb
  • penser à changer le mot de passe root et à créer un user dédié avec des mots de passe générés avec pass

Cache

  • Le proxy gère une partie du cache pour les ressources web.
  • Si l'utilisation d'une instance de Redis est possible, utiliser le container dédié 110 avec les paramètres suivants :
    • IP : 192.168.10.110
    • port : 6379
    • password : tel que généré avec [pass]

Courriel

  • SMTP : container 105, pas d'authentification pour le même sous-réseau
    • IP : 192.168.10.105
    • port : 25
    • tls : True
  • IMAP : container 105, créer un compte sur mail.felinn.org/admin et stocker les identifiants dans pass
    • IP : 192.168.10.105
    • port : 993
    • ssl/tls : True
    • user/password : pass

Proxy

  • notre reverse proxy gère les connexions depuis l'extérieur ainsi que les certificats SSL
  • si besoin d'un serveur web local, utiliser nginx avec un certificat auto signé (ou des copies de ceux du proxy), nul besoin de les renouveler puisqu'ils servent uniquement à chiffrer les connexion internes
  • si besoin de générer un certificat et une clé SSL : mkdir /etc/nginx/ssl && openssl req -x509 -nodes -days 3650 -newkey rsa:2048 -keyout /etc/nginx/ssl/{{ hostname }}.felinn.org.key -out /etc/nginx/ssl/{{ hostname }}.felinn.org.crt
  • pour homogénéiser, on crée le fichier de conf /etc/nginx/sites-available/{{ hostname }}.felinn.org.conf puis un lien symbolique ln -s /etc/nginx/sites-{available,enabled}/{{ hostname }}.felinn.org.conf
  • le nom des logs : {{ hostname }}.felinn.org-access.log {{ hostname }}.felinn.org-error.log
  • pour tester la configuration nginx et recharger le service : nginx -t && nginx -s reload

Configuration

Dans la mesure du possible, stocker les fichiers de configuration des services dans /etc/{{ service }}/{{ foo }}.conf afin qu'ils puissent être versionnés par git avec etckeeper.

Reverse proxy

Le reverse proxy est installé dans le container 100. Il permet de router le trafic depuis l'extérieur vers les bons CT/VM en fonction du nom de domaine. Voici les étapes à suivre afin de configurer le nouveau CT ou la nouvelle VM sur le reverse proxy :

Protocole

  1. entrer dans le container avec pct enter 100 depuis l'hôte
  2. utiliser le script nginx-new-host pour créer le service
  3. vérifier et recharger nginx avec nginx -t && nginx -s reload
  4. visiter le site et adapter les paramètres SCP dans nginx en fonction des erreurs de la console du navigateur

Versionnage du /etc

Le versionnage des fichiers de configuration permet :

  • la traçabilité des changements dans la vie d'un service
  • de documenter la résolution des problèmes avec Gitlab
  • de récupérer une configuration en cas de disparition, migration ou duplication d'un service

Attention

Pour mettre en place le versionnage des configurations, il faut configurer votre connexion SSH de sorte à transmettre vos variables GIT au serveur, afin que Git enregistre l'auteurice des modifications. Pour cela, merci de suivre le tutoriel dédié à la gestion de la traçabilité avec git et ssh.

Protocole

  • Une fois le service configuré, installer Etckeeper (dans les dépôts Debian stable par défaut). Par défaut, un répertoire git est alors automatiquement créé dans /etc.
  • Créer un nouveau projet privé dans Gitlab, dans le groupe approprié (FELINN core, Labs, Friends) portant le nom du domaine complet, ex: {{ service }}.felinn.org et commiter les changements locaux si besoin.
  • Ajouter l'upstream au répertoire git local et pousser les modifications :
1
2
3
4
5
6
7
8
# ajouter le `remote` dans le repo git du service
git remote origin set-url "https://git.felinn.org/{{ group }}/{{ service }}.git"

# /!\ Si aucun remote n'a préalablement été configuré, ce qui est probable lors de l'installation, préférez la commande suivante
git remote add origin "https://git.felinn.org/{{ group }}/{{ service }}.git"

# pousser les modifications, notez que l'option -U ne semble pas être forcément reconnue
git push -U origin master
  • Vérifier que tout les fichiers sont bien présents dans le projet Gitlab.
  • Pour pouvoir ouvrir un projet Gitlab de la FELINN au public, il faut configurer les permissions comme suit :
    • Issues : « Everyone With Access »
    • Repository : « Only Project Members »
    • Wiki : « Only Project Members »

Sécurisation

Protocole

  1. supprimer les logiciels inutilisés (ceux qui auraient été installés par mégarde ou qui sont inutiles de fait, comme Apache)
  2. vérifier que les paquets sont à jour : apt update && apt full-upgrade
  3. vérifier que les services web tournent avec un user autre que root : ps aux | grep <service> ou top
  4. vérifier que seuls les ports nécessaires sont ouverts et vérifier les interfaces d'écoute depuis l'extérieur : ss -tunlp
  5. des outils comme wapiti peuvent aider à vérifier la santé d'un service web
  6. en cas de problème venant du reverse proxy, ouvrir une issue sur le projet

Documentation

Si. Il faut la faire. Voir la documentation de la documentation pour pouvoir bien la faire.

Publication de l'état de fonctionnement

Attention

Voir l'issue à ce sujet.

Maintenance

La personne qui a installé le service en est de fait la principale responsable.

Attention

Voir l'issue à ce sujet.

Durée de vie & fin de vie

Tous les services sont maintenus à durée indéterminée par défaut. Ils peuvent être fermés dans les cas suivants :

  • le service n'est plus utilisé ou ne répond à plus aucun besoin
  • le ou les logiciels utilisés par le service changent de statut et sont incompatibles avec la charte de la FELINN
  • le service induit des failles de sécurité incorrigibles
  • le service utilise trop de ressource par rapport à ce qu'il offre

Pour fermer un service il faut respecter la démarche suivante :

Protocole

  1. Ouvrir une issue dans https://git.felinn.org/FELINN/infra en utilisant le modèle « suppression de service ». Le titre doit adopter le format « [service : suppression] {{ nom de l'unité concernée }} » et la description doit détailler les raisons de la suppression.
  2. L'issue doit être approuvée au niveau CC-CP-V dans le cas d'un service en production et CC-CV-V dans le cas d'un service en test ou d'un VPS.
  3. Si approuvée, l'issue doit donner lieu au choix d'un délai, à une annonce de la fermeture de l'unité auprès des utilisateurices et/ou de la communauté concernée, ainsi qu'à la désignation des membres qui seront responsables de la suppression.
  4. Une fois le délai de fermeture écoulé, éteindre le CT ou la VM.
  5. Si aucun problème n'est survenu dans la semaine suivante, nettoyer les traces du service :
    1. supprimer les fichiers de configuration sur le proxy
    2. supprimer le container ou la machine virtuelle du service en purgeant les fichiers de configuration dans PVE
    3. supprimer les volumes ZFS et les snapshots associés
    4. archiver le projet Gitlab associé pour garder la trace de la vie du service (peut servir à d'autres et évite de refaire certaines erreurs)
Dernière mise à jour: 2021-12-05