Ce site et quelques autres services personnels étaient hébergés chez OVH, spécialement dans le datacenter SBG. Ce datacenter a connu un "incident" le 10 Mars 2021 vers 0:40.
J'ai pu restaurer des sauvegardes un peu anciennes et reconstruire le reste à partir de sauvegardes partielles, mais je profiterais sûrement de cet évênement pour faire quelques modifications à ce site.
Le serveur précédent commence à avoir des performances limitées (il date quand même de 2000), et j'ai pu récupérer un HP Compaq DC5800 de 2009 en bon état.
Hardware
La machine a un processeur Intel Pentium E5200 (2-Core, 2.5GHz, LGA775) et deux barrettes de 1Gio de DDR2 (avec deux slots libres), mais le disque dur et le lecteur optique/disquette manquent ou sont hors-service.
On commence par tout vérifier, nettoyer, puis remettre en état tout ce qui en a besoin :
Memtest avec la mémoire,
Flash du dernier BIOS à jour,
Nettoyage des ventilateurs/radiateurs,
Remplacement de la pâte thermique du processeur,
Face avant
Le lecteur de disquette est manquant et le lecteur optique ne fonctionne pas, du coup je les ai enlevés. Sauf que le refroidissement de la machine est fait de telle sorte que l'air doit être aspiré par le côté avant droit, et soufflé par le côté arrière gauche. Quand le boitier est ouvert ou que la face avant manque, le disque dur est mal refroidi, mais il est possible de découper une plaque de plexiglass pour remplacer les caches d'origine.
Disque dur
Le disque dur était manquant quand j'ai récupéré la machine, mais les vis, clips et bushings manquaient aussi, ce qu'il a fallu adapter.
J'ai pris des vis 6-32 "long sleeve" d'un rack à disques de serveur IBM et des bushings de lecteur CD. L'ensemble rentre dans l'emplacement d'origine et se clipse fermement (pas de vibration).
Software
Mot-de-passe BIOS
Les machines d'entreprises ont souvent des BIOS différents de ceux des PCs habituels. Ici, le mot-de-passe protégeant BIOS est stocké dans une mémoire EEPROM au lieu d'être dans une SRAM. Dans ce cas, enlever la pile quelques secondes n'affecte que l'horloge RTC.
Débrancher le secteur,
Ouvrir le capot,
Attendre que les LEDs de la carte-mère soient éteintes,
Enlever le cavalier vert PSWD (à côté des ports SATA),
Brancher le secteur et démarrer la machine,
Débrancher le secteur et attendre que les LEDs soient éteintes,
Remettre le cavalier PSWD,
Refermer le capot et rebrancher le secteur.
Boot-Menu
Certaines options du BIOS concernant la "sécurité" sont grisées et indisponibles. Ainsi, on ne peut booter que sur le disque SATA HDD0, alors qu'un lecteur optique, USB ou la ROM PXE (réseau) sont disponibles.
Pour cela, il est nécessaire de "protéger" l'accès au BIOS par un mot-de-passe. Le "boot menu" est aussi affecté, et permet de booter sans problème sur un serveur PXE quand un mot-de-passe est entré.
Debian Linux
Je me suis contenté d'échanger le disque dur de l'ancien serveur au nouveau, quasiment sans toucher l'installation de Debian Jessie (8.4) i386.
L'unique bricolage concerne udev et sa façon de détecter les cartes réseau par leur adresses MAC. Si l'on ne change rien, le réseau ne fonctionnera pas et sera à reconfigurer (peu pratique pour un serveur sans écran ni clavier).
Il faut commencer par trouver l'adresse MAC de la carte réseau avec l'ancien serveur en fonctionnement : # ifconfig |grep HWaddr
eth0 Link encap:Ethernet HWaddr 00:d0:b7:xx:xx:xx
eth1 Link encap:Ethernet HWaddr 00:1e:2a:xx:xx:xx
Ici, c'est l'adresse de eth0 qui nous intéresse, mais la configuration de udev est séparée en plusieurs fichiers de configuration que l'on va chercher : # grep -rni '00:d0:b7:xx:xx:xx' /etc/ /etc/udev/rules.d/70-persistent-net.rules:8:SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:d0:b7:xx:xx:xx", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
La recherche peut renvoyer plusieurs fichiers (DHCP, ARP, scripts d'init bricolés), mais c'est ceux qui concernent udev qui nous intéressent et que l'on va éditer :
# PCI device 0x8086:0x1229 (e100)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:d0:b7:xx:xx:xx", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
Dans tous les cas, il faudra supprimer l'association entre chaque carte et son adresse MAC, les cartes réseau suivantes seront ajoutées à la suite (la première carte réseau sera eth2 si l'on ne touche à rien).
Pour être sûr que le réseau fonctionne du premier coup, on va remplacer l'adresse MAC de l'interface eth0 par celle de la nouvelle carte réseau (affichée à l'écran pendant une tentative de boot par PXE).
Performances
Test
HP Compaq dc5800 (new)
IBM PC-300GL 6288 (old)
nbench Mem
18.583
2.649
nbench Int
17.233
2.793
nbench Float
32.444
4.942
Transfert NFS
11.20 Mio/s
11.18 Mio/s
Transfert SaMBa
11.21 Mio/s
11.00 Mio/s
Transfert SSH
11.2 Mio/s
4.05 Mio/s
Génération PHP/Blogotext
7.6 ms
61.9 ms
Compression gzip
15.43 Mio/s
1.31 Mio/s
Décompression gzip
112.48 Mio/s
10,65 Mio/s
Compression bzip2
3.28 Mio/s
0.32 Mio/s
Déompression bzip2
7.18 Mio/s
1.19 Mio/s
Débit disque dur
185.81 Mo/s
40.33 Mo/s
Débit ethernet
94.4 Mbit/s
94.6 Mbit/s
La plupart des débits sont limités à 100Mbit/s par le switch. Mais il faut aussi voir que les tests ont été faits avec des gros fichiers (247Mio).
La différence la plus visible vient du processeur et du contrôleur SATA, la lenteur de l'ancien serveur posait surtout des problèmes en multitâches ou en transférant de nombreux petits fichiers (sauvegardes).
Il est possible de booter une machine sans disque dur, ni lecteur cd (ni même de clé usb).
Beaucoup de cartes réseaux (j'utilise des 3com 3C905CX) ont une EEPROM qui contient un chargeur de boot réseau.
Il y a donc plusieurs parties:
Serveur DHCP
Serveur TFTP
Image(s) PXE
Boot du noyau
Il faut d'abord configurer le serveur DHCP, pour qu'il donne les paramètres de boot à la machine qui va le lui demander. Pour l'instant, je n'ai pas réussi à configurer dnsmasq pour avoir un serveur tftp sur une autre machine que le serveur dhcp, alors j'ai adapté...
Comme le bootloader embarqué dans la carte va charger un autre bootloader (undionly.kpxe), qui lui, va charger le noyau, on va interroger le serveur DHCP deux fois. Ces deux accès sont distingués par le flag "userclass"
dnsmasq est tellement bien fait qu'il a aussi un serveur tftp embarqué. Il suffit de rajouter les lignes suivantes dans le fichier /etc/dnsmasq.conf
enable-tftp
tftp-root=/tmp
Comme le routeur a peu de flash, j'ai mis la raçine du serveur tftp dans /tmp (tmpfs) pour éviter les problèmes. Mais il faut rajouter un script qui télécharge l'image au boot de la machine. undionly.kpxe est une image de gPXE qui permet de booter sur n'importe quel protocole (même http).
Pas mal d'hébergeurs de pub n'hébergent que de la pub sur le même hostname. Du coup, on ne perd pas grand chose à filtrer leurs domaines.
En même temps, quasiment tous les routeurs ont un cache DNS, mes routeurs (OpenWRT) utilisent dnsmasq.
Dans la config de dnsmasq, /etc/dnsmasq.conf, on fait des redirections arbitraires avec l\'instruction suivante : address=/hostname/adresse
À grande échelle, on arrive à une petite commande : for i in $(cat list); do echo "address=/$i/127.0.0.1" >> /etc/dnsmasq.conf ; done
Il ne suffit plus que de redémarrer le service dnsmasq, et ça fonctionne.
Pour trouver la liste, on peut récupérer les listes d'adblock et les trier (les bouts d'url et toutes les regexp n'intéressent pas dnsmasq). On a aussi des listes toutes faites comme ici.
Pour upgrader la liste, on peut rajouter ce qui manque : for i in $(cat nouvelle_liste); do if !(grep -q dnsmasq.conf) ; then echo >> dnsmasq.conf ; fi; done
Avoir un serveur @home, ce n'est pas très compliqué, ni très coûteux, et c'est aussi pratique que formateur.
Utilisation
Un serveur "de maison" va servir à partager des fichiers entre les différentes machines, et à pouvoir les rendre disponibles depuis internet, et éventuellement héberger plus de services.
Pour ça, il y a quelques contraintes :
Le serveur doit rester connecté et allumé quand on va y accéder
Le serveur doit être fiable, aussi bien au niveau logiciel que matériel
Le serveur ne doit absolument pas rendre toutes vos données publiques
Bien sûr, pourquoi ne pas utiliser d'autres services, "gratuits" ? Parfois on peut être rebuté par des conditions d'utilisation trop restrictives trop de publicité, des droits d'auteur non respectés, ou même lorsqu'il n'existe pas de service équivalent gratuit et fiable.
Hardware
On va avoir un serveur qui va être allumé pendant de longues périodes, avec de longues périodes d'inactivité, et d'activité intense. Là aussi, on va imposer quelques contraintes :
Machine peu-chère
Faible consommation électrique
Faible bruit
Matériel fiable
Grande capacité de stockage
Le premier critère impose directement une machine d'occasion ou de récupération. Les second, troisième et quatrième critères renvoient vers les machines d'entreprise (HP Compaq, Dell Optiplex), très répandues.
En s'attardant sur la fiabilité et le bruit, on peut remarquer que ces machines sont souvent usées après une dizaine d'années : les premiers composants usés sont mécaniques : ventilateurs (encrassés, et roulements usés), et disques durs.
J'ai ainsi récupéré un IBM PC-300GL de 2000 en 2007.
Nettoyage complet de la machine, au compresseur
Changement des ventilateurs (utilisation de patins anti-vibration)
Upgrades basiques
Changement du disque dur (8Go -> 320Go)
Réglages dans le BIOS : activation du reboot en cas de coupure de secteur, désactivation du test du clavier
Ainsi, on a un serveur coûtant 100€ (pièces neuves), qui consomme peu (40~50W à la prise), quasiment inaudible et fiable (plusieurs années sans interuption). Par contre, le matériel n'est pas tout jeune, mais on verra que ça ne pose pas tant de problèmes que ça.
Upgrades
2007 : Disque dur 8Go IDE -> 320Go IDE, 64Mio de RAM -> 256Mio, ventilateurs
2011 : Contrôleur SATA, carte réseau Gigabit, disque dur 320Go IDE -> 2To SATA
2016 : Disque dur 2To (remplacement avant panne), remplacement
OS
Comme il faut un système d'exploitation peu cher, fiable et facile à maintenir, le choix se porte tout de suite vers Linux.
J'ai choisi la distribution Debian, pour son installation et sa maintenance automatisable.
Comme on a un serveur, il ne faut pas perdre de vu quelques rudiments :
Pas d'interface graphique
Partitionnement du/des disques séparant les données du système
Une interface graphique consomme des ressources système, pas illimitées avec ce genre de machine, rajoute des problèmes de sécurité potentiels, et ne sert à rien sur un serveur (puisqu'on a pas de clavier ni d'écran).
Le schéma de partitions suivant :
sda1 : /boot ~100Mo
sda5 : swap 200~500Mo
sda6 : / 2~5Go
sda7 : /stuff (tout le reste)
La partition /boot pourra être montée en lecture seule pour éviter les problèmes. La séparation des documents et du système facilite grandement la maintenance (changement de disque dur, sauvegardes et restorations...).
Services
On va mettre quelques services :
SSH : administration et utilisation à distance (et transferts de fichiers)
Apache : serveur web "usine à gaz"
lighttpd : serveur web "light"
vsftpd : serveur FTP : transferts de fichiers
SaMBa et NFS : partage de fichiers en réseau local
On peut y rajouter quelques uns, comme un serveur DNS avec bind ou dnsmasq, l'extension PHP, des bases de données mySQL, un serveur mail...
Pour une machine connectée h24, ça peut être très utile pour partager des torrents (torrentflux) ou pour rester connecté sur IRC ou jabber (ssh + screen + client im).
Configuration
On va connecter le serveur au réseau local, pour celà, il faut configurer le serveur avec une adresse statique, sur la même plage que le routeur, hors de sa réserve DHCP. Le serveur est ainsi utilisable en réseau local.
On va configurer les routes et le DNS:
Mais comme ce n'est pas persistant, il faut le forcer dans /etc/network/interfaces. Le serveur peut maintenant accéder à internet.
Ensuite, on configure le routeur pour qu'il redirige les ports voulus de l'adresse publique (internet) vers l'adresse privée (réseau local). Les ports 21 (FTP), 22 (SSH), 80 (HTTP), 433 (HTTPs) sont utiles. Mais attention, il y a beaucoup d'attaques sur les protocoles FTP et SSH, assurez-vous de bien les avoir configurés avant de les rendre publics, et dans certains cas (brute-force ou firewall "fasciste"), il est utile de changer les ports (mettre SSH sur le port 443 permet d'accèder à son serveur depuis n'importe où.