mai a longtemps été mon serveur à tout faire, animé par un beaglebone black, avec comme gros défaut l’utilisation d’une carte SD pour suppporter le système. Pour des raisons que je n’ai as élucidées, le système de fichier avait tendance à se corompre, rendant le serveur inaccessible.
De nos jours, Raspberry semble avoir gagné en popularité et en fiabilité proposant pour sa version 5 un port PCIe pour connecter un SSD sur lequel on peut démarrer et installer le système et tout ce qu’on veut. J’en ai déjà un pour la bureautique familiale, j’en ai racheté un autre pour ressuciter mai avec pour ambition d’en faire aussi un serveur web et surtout d’héberger un service nextcloud.
Boîtier#
J’ai choisi un boîtier Argon ONE V3 M.2 NVME PCIE en aluminium noir anodisé à refroidissement actif, incluant une extension NVME, un poussoir marche/arrêt, deux connecteurs HDMI plein format (pas très utiles ici) et un transferts des GPIO vers le dessus du boitier. Attention il existe un boîtier Argon V3 non NVME qui n’est pas compatible physiquement.
Le magazine officiel Raspberry Pi en a fait une revue.
À la réception, l’ensemble donne une impression de solidité, toutes les vis se vissent dans des inserts métalliques…
{width=50%}
Le montage ne présente pas de difficulté malgré une documentation sommaire, en particulier il faut penser qu’une fois le boîtier monté, la carte µSD sera inaccessible donc il faut choisir de ne pas en utiliser ou d’en laisser une à demeure (j’ai choisi de ne pas en utiliser). Par ailleurs, la documentation mentionne que l’on peut mettre à jour le firmware du RP2040 qui pilote en particulier le ventilateur et l’alimentation en utilisant un connecteur USB qui n’est plus accessible une fois que le raspberry est monté.
{width=50%}
Le binaire du firmware se recopie dans le stockage USB émulé par le RP2040 quand on presse le poussoir marche/arrêt.
Une fois l’ensemble monté, il reste un peu de configuration à faire à l’aide de deux scripts fournis par Argon :
La documentation demande de rebooter après chaque script mais un seul reboot suffit.
Système de base#
RPI imager, debian bookworm 64 full
Mise à jour vers trixie…
On trouve deux versions du noyau : rpi-v8 et rpi-2712 ce qui pose quelques problèmes de cohabitation. La différence entre les deux:
the 2712 kernel is just v8 but with 16k pages for the BCM2712 CPU in the Pi5. The v8 kernel uses 4k pages and will run on any of the 3, 4 or 5. The default 64-bit installs include both v8 and 2712 kernels (forum rpi)
donc :
frv@mai:~ $ sudo apt purge \
linux-image-6.12.34+rpt-rpi-v8 linux-image-6.12.47+rpt-rpi-v8 \
linux-headers-6.12.34+rpt-rpi-v8 linux-headers-6.12.47+rpt-rpi-v8 \
linux-image-6.12.34+rpt-rpi-v8 linux-image-6.12.47+rpt-rpi-v8 Nous aurons besoin de quelques outils réseaux donc :
frv@mai:~ $ sudo apt install asncockpit#
Installer les paquets cockpit cockpit-networkmanager cockpit-storaged udisks2-btrfs udisks2-lvm2 cockpit-doc cockpit-sosreport
frv@mai:~ $ sudo apt install cockpit cockpit-networkmanager cockpit-storaged \
udisks2-btrfs udisks2-lvm2 cockpit-doc cockpit-sosreportDNS/DHCP#
Serveur de noms de domaines#
J’avais l’habitude de bind mais sa configuration est complexe et ses fonctionnalités surdimensionnées pour un réseau domestique. Couplé à isc-dhcp-server, il permet de mettre à jour les noms d’hôtes à partir des baux DHCP même pour des hôtes inconnus (au dépends d’une configuration un peu complexe pour mettre à jour les fichiers de zone sur la base du protocole chiffré et authentifiant TSIG), mais isc-dhcp-server est en fin de vie au profit de kea. C’est l’occasion d’utiliser dnsmasq qui assume intelligemment et sobrement les deux rôles et sert directement et indirectement les adresses des noms d’hôtes présents dans les baux DHCP.
La documentation officielle, un peu aride se compose de la page man bien mise en page en français par archlinux, un peu moins bien par debian et de l’exemple de fichier de configuration (dnsmasq.conf.example) très bien commenté.
Quelque ressources :
- tuto permet de bien démarrer (en fait non)
- on peut aussi voir ce tuto pour la partie
dhcp - surtout, bien sûr, ce qu’en dit archlinux
Commençons par la partie DHCP, pour l’activer il faut et il suffit de déclarer une plage d’adresses que le serveur utilisera de façon statique ou dynamique, comme pour isc-dhcp-server (mais contrairement à ce dernier qui s’arrête en générant une erreur si l’on a pas définit de sous-réseau, dnsmasq ne fera rien et ne s’en plaindra pas). L’option dédiée est dhcp-range qui prend de multiples formes. Pour déclarer une plage statique on ne peut qu’indiquer l’adresse réseau et éventuellement un masque de sous-réseau :
dhcp-range=192.168.50.0,static,255.255.255.128,24hCette directive autorise la déclaration de baux statiques pour les adresses comprises entre 192.168.65.1 et 192.168.65.126, les déclarations hors de cette zone empêcheront le serveur de démarrer. Son effet n’est pas complètement clair lorsqu’on déclare plusieurs (sous-)réseaux avec des adresses qui se recouvrent.
La fonction première de dnsmasq, comme son nom l’indique est de cacher les demandes dns de la machine sur laquelle il est installé (ainsi que de toutes les machines qui le sollicitent) et de les mémoriser pour les resservir sans appel aux serveurs extérieurs, ce qu’il fait dans sa configuration d’installation pour peu qu’on lui adresse les requêtes dns.
On crée le fichier ether-hosts.conf et on charge la table arp avec tout ce que l’on trouve sur le réseau :
NETADDR=192.168.65
echo "dhcp-range=$NETADDR.0,static,255.255.255.128,24h">ether-hosts.conf
nmap -sP ${NETADDR}.0/24On peut alors remplir le fichier ether-hosts.conf :
/usr/sbin/arp -n |\
tail -n +2 |grep -v '(incomplete)'|\ # On élimine l'entête et les adresses incomplètes
sort -k4 -t. -g|\ # on trie par ordre croissant d'adresse ip
awk '{print "dhcp-host="$3","$1}'\ # on ecrit au format de conf de dnsmasq
>>ether-hosts.confsort -k4 -t. -g pour trier les entrées de la table arp par adresses ip croissantes :
⚠️ Attention
On peut fixer la durée de bail de plusieurs façons : en paramètre dhcp (option 51), dans la déclaration de ‘range’ ip ou dans chaque déclaration d’ip. Si on le fixe à la fois dans l’option 51 et dns la déclaration de ‘range’,
dyndnsenvoie deux fois l’option 51 lors de la négociation du bail mais n’en retient qu’une. On peut donc avoir des baux qui sont considérés comme valide par la machine mais libérés et oubliés au sens dns pardyndns. Il vaut mieux s’assurer de déclarations cohérentes.
Les baux sont rangés dans le fichier /var/lib/misc/dnsmasq.leases sous la forme :
timestamp MACaddr IPAddr name DHCPidSi l’un des deux derniers champs est vide, il est remplacé par une astérisque.
Pour trier les baux par ordre d’échéance avec la date formatée :
sort -h /var/lib/misc/dnsmasq.leases|awk '{ print strftime("%d/%m/%Y %H:%M:%S", $1),$3,"\t"$4 }'Docker ou podman ?#
Nextcloud#
Partages NFS#
Il existe un nombre considérable de possibilités pour créer et utiliser des partages NFS, en particulier pour la sécurité. En utlisant les options par défaut dans trixie on optient un minimum qui peut être suffisant. Comme souvent, archlinux fait une bonne synthèse
frv@mai:~ $ sudo apt install nfs-kernel-server puis, sans rentrer dans le détail des options :
frv@mai:~ $ sudo mkdir /srv/homes
frv@mai:~ $ sudo chmod 777 /srv/homes # ⚠ option hyper permissive !!!
frv@mai:~ $ echo "/srv/homes 192.168.65.0/24(rw,sync,no_subtree_check)" | sudo tee -a /etc/exportsEnfin
frv@mai:~ $ sudo exportfs -rav
exporting 192.168.65.0/24:/srv/homesSur un client :
frv@cavalas:~ $ sudo showmount -e mai
Export list for mai:
/srv/homes 192.168.65.0/24frv@cavalas:~ $ sudo mount mai:/srv/homes /mnt
frv@cavalas:~ $ mount|grep mai
mai:/srv/homes on /mnt type nfs4 (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.65.34,local_lock=none,addr=192.168.65.10)Le système a utilisé la version 4 de NFS et l’option sys pour la sécurité, donc les identités des utilisateurs clients seront reçues sans modification :
frv@cavalas:~ $ touch /mnt/home/frv
frv@cavalas:~ $ sudo -u marieln touch /mnt/marieln
frv@cavalas:~ $ sudo touch /mnt/root
frv@cavalas:~ $ ls -al /mnt
total 8
drwxrwxrwx 2 root root 4096 24 nov. 15:11 .
drwxr-xr-x 18 root root 4096 18 nov. 06:24 ..
-rw-r--r-- 1 frv users 0 24 nov. 15:09 frv
-rw-r--r-- 1 marieln users 0 24 nov. 15:10 marieln
-rw-r--r-- 1 nobody nogroup 0 24 nov. 15:11 rootIci frv correspond bien à un utilisateur du serveur avec le bon numéro (uid), tout va bien, marieln n’a pas de correspondance sue le serveur mais celui-ci utilise le numéro du système client, ça va à peu près. Par contre le serveur tranforme les droits root en nobody:nobody (habituellement 65534:65534), c’est une option par défaut côté client comme serveur et ce n’est pas si mal.
frv@cavalas:~$ cat >/mnt/test.sh <<EOF
#!/bin/bash
whoami
EOF
frv@cavalas:~$ chmod +x /mnt/test.sh
frv@cavalas:~$ /mnt/test.sh
frvOn voit l’interêt de l’option root-squash, sans celle-ci un utilisateur ayant les droits root sur une machine pourrait les obtenir sur le serveur.