Administration du serveur

Cette page donne des informations sur la partie “base” du système de Tchack, les couches basses. Pour l'administration des services, voir adminsys:apps

Les services tchack sont assurés par 4 machines, réparties comme suit :

Depuis Aout 2018, le serveur principal est secondé d'un VPS hébergé chez PulseHeberg. Les sauvegardes sont effectuées sur un NAS à distance, et sur une seconde VM louée en Bulgarie (espace disque pas cher).

Le serveur matériel est constitué par :

• un NUC Intel i7 - 8Go de RAM
• 1 SSD 120Go(système) et 1 HDD 750Go
• Virtualisation Proxmox avec image Debian/Ynh située sur le HDD.

Le tout est hébergé à domicile, connecté via une Box Numéricable avec un débit câble moyen (40/26Mbps en sept 20). Une recherche de meilleure connexion est en cours. Il n'y a pas de système de secours d'alimentation.

Le matériel a été migré à l'été 2020 : migration hardware. Auparavant, le serveur principal était :

• Un Raspberry Pi modèle 3-B
• Un pack de stockage WDLabs composé de :
  • Une carte SD en mode “BerryBoot”
  • Un disque dur externe 2.5“ Western Digital de 1To

• mise à jour ProxMox : en gros, toujours utiliser 'dist-upgrade'.

Le domaine tchack.xyz est géré chez OVH, qui fournit également les serveurs de DNS. La zone DNS est sauvegardée à la main ici.

La réponse aux noms de domaines est gérée par les services dnsmasq et resolvconf. Si le fichier /etc/resolv.conf est en dur (erreur sur le VPS en juin 2019), rétablir le lien par rm /etc/resolv.conf puis ln -s /etc/resolvconf/run/resolv.conf /etc/resolv.conf.

Voir l'article dédié : sauvegardes

Plusieurs mécanismes complémentaires :

• Sauvegardes effectuées manuellement avec yunohost backup create ⇒ fichiers résultants copiés manuellement sur d'autres disques : Freebox maison…
• Sauvegarde chiffrée des fichiers avec l'application borg, sur un VPS dédié à la sauvegarde.
• Automatisation avec CRON et copie rsync vers le NAS distant d'Hervé. ( en panne depuis 2022)

Les éléments du système hors Yunohost, tels l'appli RPi-Monitor, les clés SSH, les comptes utilisateurs du serveur, les journaux d'installation, les BDD… ne sont pas sauvegardés par Yunohost. Le Plan de Reprise d'Activité est donc plus complexe pour retrouver un fonctionnement à 100%.

Les services de base de yunohost sont bien entendus activés. De plus, en suivant les conseils ici, le port SSH est modifié à 2222. Cela impacte également la connexion en SFTP pour les applications web utilisant cet accès.

La connexion SSH par mot de passe est désactivée, seule la clé publique (sur l'ordinateur de l'adminsys) permet une connexion.

La clé id_rsa de p@rpi donne accès à jaxadmin@VPS.

Chaque serveur doit être régulièrement mis à jour (apps et paquets) en utilisant yunohost tools update|upgrade. pour éviter les déconnexions SSH intempestives, penser à lancer ces commandes après un screen, que l'on peut re-joindre via screen -r -d.

Pour vérifier le contenu d'une image disque qcow (qui peut être plus grand que la taille configurée), voir la commande qemu-img info vm-1002-disk-0.qcow2 .

image: vm-1002-disk-0.qcow2
file format: qcow2
virtual size: 500G (536870912000 bytes)
disk size: 988G
cluster_size: 65536
Snapshot list:
ID        TAG                 VM SIZE                DATE       VM CLOCK
2         sauv181019                0 2019-10-18 08:12:42   20:45:15.988
3         pass_201020               0 2020-10-20 12:49:48 2017:57:27.767
4         upgrade_buster            0 2021-03-31 19:00:49 5912:09:11.846
Format specific information:
    compat: 1.1
    lazy refcounts: false
    refcount bits: 16
    corrupt: false

Pour éviter de saturer le disque physique avec les images virtuelles des VM :

1. activer TRIM : https://www.digitalocean.com/community/tutorials/how-to-configure-periodic-trim-for-ssd-storage-on-linux-servers
2. enable timer + modifier /etc/fstab + réglage de l'option dans la config proxmox de chaque VM.

Ce fil du forum indique que les anciennes versions de Node JS ne sont pas supprimées. Pour libérer l'espace disque inutile, on peut suivre cette procédure :

1. Lister les versions utilisées : grep -nr “nodejs_version:” /etc/yunohost/apps/*/settings.yml
2. Supprimer les autres dossiers dans /opt/node_n/n/versions/node ainsi que /usr/local/n/versions/node

Il est possible de configurer l'espace disque consommé par les fichiers de logs de journald : https://askubuntu.com/questions/1238214/big-var-log-journal

cf Outils d'administration système

La suite de cette page n'est plus d'actualité.

Le serveur utilise le système d'exploitation Raspbian Stretch (qui correspond à Debian 9 adapté au raspberry pi). Les applications, à l'exception de celles ci-dessous, sont installées au travers de l'infrastructure Yunohost.

La migration a été réalisée depuis Jessie en octobre 2018.

Cette configuration “à bas coût” était suffisante pour la qualité de service attendue, tant en terme de débit que de disponibilité. Des coupures électriques, en l'absence d'onduleur de secours, peuvent corrompre la carte SD et empêcher le redémarrage du serveur.

Les principales modifications au système sont les suivantes :

• Envoi de SMS à la connexion SSH : script utilisant l'API de FreeMobile, appelé par /etc/ssh/sshrc retiré car incompatible Ansible.
• Extinction automatique à la perte du réseau : daemon UPSD conçu pour la gestion d'onduleur à autonomie limitée retiré car connexion instable
• Suppression de la sortie rsyslog → /dev/xconsole en commentant la fin de /etc/rsyslog.conf d'après ce lien.
• Installation des outils mailutils pour envoi de mail par script (utilisé dans l'installation d'un application).

Bien que rejetée par le développeur de BerryBoot, le serveur a besoin de swap,notamment pour réussir une mise à jour de Nextcloud. Le filesystem de type aufs ne le permettant pas (swapon swap.file renvoie une erreur d'E/S), voici le moyen de contourner le problème :

1. Créer un fichier de swap à l'aide de dphys-swap sur la carte SD. Celle-ci est montée sur /boot avec un autre type de FS, qui autorise la swap. Voir les réglages dans le fichier /etc/dphys-swap.
2. Monter ce fichier au sein de aufs en mode Bind là où on souhaite placer la swap, en l'occurrence : mount –bind /boot/swap.file /var/swap.file
3. Activer la swap à l'aide de la commande : swapon /var/swap.file

* Ajout sécurité : Alerte sur les connexions SSH via un script appelé à la connexion (d'après ce fil) * mises à jour : Le fonctionnement unattended-upgrades de Debian est activé sur le Rpi (tout est mis à jour car Raspbian n'a pas de dépôt distinct dédié à la sécurité) ainsi que sur le VPS (uniquement les MàJ de sécurité Debian). Cf ce post et la documentation Debian.