EXP C04 — Construire le serveur : CUPS, Avahi et PrintLBP

EXP C04 — Construire le serveur : CUPS, Avahi et PrintLBP

Le Raspberry commence à devenir un serveur.

Après avoir abandonné Debian Trixie 64 bits et réinstallé Raspberry Pi OS Bookworm 32 bits, nous avions enfin une base qui nous semblait adaptée à notre vieille Canon.

Mais installer un système d’exploitation ne suffit pas à fabriquer un serveur d’impression.

Il fallait maintenant construire l’infrastructure.

Notre objectif était simple :

Network computer
        │
        │ Wi-Fi / local network
        ▼
┌──────────────────────┐
│ Raspberry Pi Zero 2 W│
│                      │
│ CUPS                 │
│ Avahi                │
│ PrintLBP.local       │
└──────────┬───────────┘
           │
          USB
           │
           ▼
      Canon LBP-810

À ce stade, la Canon n’était même pas encore branchée.

Et c’était volontaire.

Nous voulions d’abord construire et tester le serveur, puis nous occuper de l’imprimante.

Première étape : CUPS.

Le cœur du projet allait être CUPS, le Common UNIX Printing System.

C’est lui qui devait gérer les files d’impression et recevoir les travaux provenant des ordinateurs du réseau.

Nous avons commencé par vérifier que le service était correctement lancé :

systemctl status cups

Le résultat était sans ambiguïté :

Active: active (running)

avec notamment :

Status: "Scheduler is running..."

Le démon cupsd fonctionnait donc correctement.

Une deuxième vérification permettait de confirmer l’état du scheduler :

lpstat -r

qui répondait :

scheduler is running

Le cœur du serveur était opérationnel.

Mais nous allions rapidement découvrir que faire fonctionner CUPS et rendre CUPS accessible sur le réseau sont deux choses différentes.

Mais CUPS ne voulait pas encore parler au réseau.

Nous avons alors essayé d’accéder à l’interface CUPS depuis une autre machine :

http://PrintLBP.local:631

Mais la connexion ne fonctionnait pas.

Plutôt que de modifier immédiatement plusieurs fichiers de configuration, nous avons commencé par regarder ce que faisait réellement CUPS.

La commande :

ss -tln | grep :631

nous a donné :

LISTEN 0 128 127.0.0.1:631 0.0.0.0:*
LISTEN 0 128 [::1]:631      [::]:*

La réponse était claire.

CUPS fonctionnait, mais il n’écoutait que sur localhost.

Autrement dit : le serveur était vivant, mais il refusait encore les connexions venant du reste du réseau.

Voilà exactement le genre de petit détail qui peut faire perdre beaucoup de temps lorsqu’on construit un serveur :

Le service est actif.
Le port est ouvert.
Mais seulement sur localhost.

Une solution plus simple que de modifier cupsd.conf

Nous aurions pu éditer manuellement :

/etc/cups/cupsd.conf

Mais pour notre petit serveur domestique, nous avons finalement choisi une méthode beaucoup plus simple.

Nous avons d’abord donné à notre utilisateur les droits d’administration CUPS :

sudo usermod -aG lpadmin admin

Puis nous avons demandé à CUPS d’accepter les connexions distantes :

sudo cupsctl --remote-any

Et enfin :

sudo systemctl restart cups

La première commande concerne les droits d’administration de CUPS. La seconde modifie la configuration afin que CUPS puisse être contacté depuis le réseau. La troisième redémarre proprement le service.

Nous avons ensuite vérifié de nouveau l’écoute du port 631 :

ss -tln | grep :631

CUPS pouvait désormais être utilisé depuis le réseau.

Deuxième étape : Avahi

Nous avions maintenant une adresse IP :

192.168.1.40

Mais nous ne voulions pas devoir mémoriser cette adresse pour accéder au serveur.

Nous voulions un véritable nom réseau :

PrintLBP.local

C’est le rôle d’Avahi.

Avahi fournit les mécanismes de découverte réseau mDNS/DNS-SD, ce qui permet notamment à une machine d’être accessible par un nom en .local sur le réseau local.

Nous avons installé les paquets nécessaires :

sudo apt update
sudo apt install avahi-daemon avahi-utils

Une petite erreur de nom de paquet.

Nous avons d’ailleurs eu droit à notre première petite mésaventure.

Nous avions essayé :

sudo apt-get install Avahi

Debian a répondu :

E: Unable to locate package Avahi

Le logiciel s’appelle bien Avahi, mais les paquets Debian portent leurs vrais noms :

avahi-daemon
avahi-utils

Une petite différence de nomenclature qui suffit à faire perdre quelques minutes lorsqu’on travaille directement dans le terminal.

PrintLBP apparaît sur le réseau.

Une fois Avahi installé, nous avons vérifié le service :

systemctl status avahi-daemon

Il était bien :

Active: active (running)

Et surtout, le processus annonçait :

avahi-daemon: running [PrintLBP.local]

Les journaux montraient également l’enregistrement de l’adresse :

Registering new address record for 192.168.1.40

sur l’interface Wi-Fi.

Notre Raspberry avait maintenant une identité sur le réseau :

PrintLBP.local

Et cela allait simplifier énormément la suite.

Et CUPS devient accessible.

Nous avons alors réessayé depuis un autre ordinateur :

http://PrintLBP.local:631

Cette fois, la page CUPS s’est ouverte.

L’accès direct par l’adresse IP fonctionnait également :

http://192.168.1.40:631

Le serveur pouvait donc maintenant être administré depuis le réseau.

C’était une étape importante.

Nous avions maintenant :

Le serveur d’impression existait désormais avant même que l’imprimante soit connectée.

Pourquoi nous n’avons pas installé Samba.

À un moment de notre réflexion, nous avions envisagé Samba pour partager l’imprimante avec Windows.

Mais il est important de raconter l’expérience telle qu’elle s’est réellement déroulée :

Nous n’avons finalement pas installé Samba.

Nous avons continué avec :

CUPS + IPP + Avahi.

Samba aurait ajouté une couche supplémentaire alors que notre serveur disposait déjà de ce dont nous avions besoin.

Notre philosophie était simple :

Ne pas ajouter un composant tant qu’il n’est pas nécessaire.

Le réseau fonctionnait.

CUPS était accessible.

Avahi permettait la découverte du serveur.

Nous pouvions donc arrêter là la construction de l’infrastructure et passer à l’étape suivante.

Un serveur… sans imprimante.

À ce moment-là, notre situation était presque amusante.

Nous avions construit un serveur d’impression…

sans imprimante.

Mais ce n’était pas du temps perdu.

Nous avions volontairement séparé les différentes couches :

Raspberry Pi
     ↓
Bookworm
     ↓
ARMHF
     ↓
Wi-Fi
     ↓
Avahi
     ↓
CUPS
     ↓
network access
     ↓
         ← WE ARE HERE
     ↓
USB
     ↓
Canon LBP-810
     ↓
CAPT
     ↓
driver

Si quelque chose échouait maintenant, nous saurions que le problème se trouvait probablement à partir de la Canon, et non dans l’infrastructure de base.

C’était exactement l’approche que nous voulions adopter pour ce projet :

Une étape à la fois, avec une vérification avant de continuer.

Le serveur est prêt.

Notre Raspberry Pi Zero 2 W était maintenant devenu un véritable petit serveur réseau.

Il avait :

Raspberry Pi OS Bookworm
ARMHF 32 bits
Wi-Fi
Avahi
CUPS
PrintLBP.local

et CUPS était accessible depuis un autre ordinateur du réseau.

Mais il manquait toujours le personnage principal de cette histoire.

La Canon LBP-810.

Et maintenant, nous allions enfin pouvoir la brancher.

Le câble est là.

Le petit adaptateur que nous avions choisi allait permettre de relier la vieille Canon au Raspberry Pi Zero 2 W :

deleyCON MK738 — adaptateur USB HighSpeed

Cette fois, nous allions passer de la configuration théorique au diagnostic matériel réel.

Mais nous n’allions pas encore essayer d’imprimer.

Nous allions d’abord demander quelque chose de beaucoup plus simple à Linux :

lsusb

« Qu’est-ce que tu vois ? » :)

À suivre …

(05) — Le moment où la Canon entre dans l’enquête.

Le serveur est maintenant construit.

La prochaine étape sera entièrement consacrée à la connexion USB de la LBP-810, à son identification par Linux et à ce que CUPS voit réellement lorsqu’on branche cette vieille Canon.

AxehGo & DebIA
Independent Research & Experiments in Linux, AI and Statistical Computing