EXP C08 — Et maintenant, est-ce vraiment un serveur d’impression ?

EXP C08 — Et maintenant, est-ce vraiment un serveur d’impression ?

Le moment de vérité

Nous avions maintenant franchi une étape importante.

La Canon LBP-810 fonctionnait avec le Raspberry Pi Zero 2 W.

Windows savait la découvrir et imprimer dessus.

Kubuntu pouvait également utiliser la file en IPP.

Mais nous avions appris à nous méfier des apparences.

Une imprimante qui apparaît dans une interface graphique n’est pas nécessairement une imprimante qui fonctionne réellement.

Alors cette fois, nous allons regarder ce que raconte directement CUPS.

Pas une interface graphique.

Pas une supposition.

Le terminal.

CUPS sait-il réellement où se trouve l’imprimante ?

Sur le Raspberry Pi, la commande :

lpstat -l -p Canon_LBP-810

nous donne l’état de la file.

La configuration finale indique notamment :

printer Canon_LBP-810 is idle
enabled
Description: Canon_LBP-810
Location: RbPi0
Connection: direct
Interface: /etc/cups/ppd/Canon_LBP-810.ppd
Users allowed:
    (all)

La file est donc active et accepte les travaux.

Mais l’information la plus intéressante apparaît avec :

lpoptions -p Canon_LBP-810

CUPS nous répond notamment :

device-uri=file:///dev/null
printer-make-and-model='Canon LBP-810 Foomatic/capt (recommended)'
printer-is-accepting-jobs=true
printer-is-shared=true
printer-state=3
printer-state-reasons=none
printer-uri-supported=ipp://localhost/printers/Canon_LBP-810

Et nous retrouvons donc, dans une seule configuration, plusieurs éléments fondamentaux de notre installation :

IPP
CUPS
Foomatic
CAPT
file:///dev/null

Le fameux file:///dev/null est toujours là.

Cela mérite une précision.

Nous avions expliqué dans le chapitre 06 pourquoi cette URI particulière était nécessaire au fonctionnement du vieux pilote CAPT.

Elle est toujours présente dans la configuration finale :

device-uri=file:///dev/null

Mais dans ce chapitre, nous n’avons pas besoin de refaire toute l’enquête sur EBUSY.

Ce que nous voulons constater maintenant est beaucoup plus simple :

la solution découverte pendant notre dépannage est devenue une partie stable de la configuration du serveur.

Le PPD utilisé est toujours :

Canon LBP-810 Foomatic/capt (recommended)

et la file est toujours partagée par CUPS.

Vérifions les capacités annoncées.

Et encore la commande qui nous permet de voir les options que CUPS associe à la file :

lpoptions -p Canon_LBP-810

Dans la configuration fonctionnelle, nous retrouvons notamment :

media=iso_a4_210x297mm
output-bin=face-down
print-color-mode=monochrome

Autrement dit, CUPS connaît bien une configuration A4 et les paramètres d’impression correspondants.

Ce détail prend encore plus de sens lorsque nous le comparons aux feuilles de test que nous avons conservées.

La première configuration annonçait une limite de média de :

5.85 × 8.26 inches

tandis que la configuration fonctionnelle annonçait :

8.27 × 11.69 inches

soit le format A4.

La Canon n’était donc pas simplement « détectée ».

Elle était correctement décrite par la chaîne d’impression.

Le serveur est réellement partagé.

Un serveur d’impression doit évidemment faire autre chose que posséder une imprimante locale.

Il doit pouvoir la partager.

Notre configuration CUPS indique :

printer-is-shared=true

et la file est accessible à tous les utilisateurs :

Users allowed:
    (all)

Ce dernier détail n’est pas anodin.

Nous avons effectivement rencontré pendant l’enquête une situation où la file était limitée à :

Users allowed:
    admin

Cette restriction provoquait des réponses IPP :

Validate-Job       successful-ok
Create-Job         client-error-not-authorized
Send-Document      successful-ok

Le client Windows arrivait donc bien jusqu’au serveur, mais la création du travail était refusée.

Une fois la file configurée pour accepter tous les utilisateurs, cette restriction disparaissait.

Ce que raconte réellement le journal IPP.

Les journaux CUPS sont particulièrement intéressants parce qu’ils permettent de voir les échanges entre le client et le serveur.

Lors des essais Windows, nous avons vu apparaître :

Validate-Job       successful-ok
Create-Job         client-error-not-authorized
Send-Document      successful-ok

puis ces séquences se répétaient lors des tentatives suivantes.

Même si le Create-Job posait alors problème, une chose était déjà certaine :

Windows communiquait bien avec notre serveur CUPS en IPP.

Le problème n’était donc plus la découverte réseau.

Le serveur était là.

L’imprimante était là.

Le protocole IPP fonctionnait.

Il restait seulement à corriger les permissions de la file.

Une petite commande qui raconte beaucoup.

Sur le Raspberry, une simple commande :

lpstat -t

permettait déjà de vérifier l’ensemble de l’infrastructure CUPS.

Nous pouvions notamment obtenir :

scheduler is running

et voir la file :

Canon_LBP-810

avec son état :

accepting requests
printer ... is idle

Lors des premiers essais, l’URI était encore :

usb://Canon/LBP-810?serial=511497ef

Plus tard, la configuration finale avait changé de nature :

device-uri=file:///dev/null

tout en conservant :

Canon LBP-810 Foomatic/capt (recommended)

Cette évolution résume à elle seule une bonne partie de notre enquête.

Et le réseau dans tout ça ?

Nous avons donc maintenant trois niveaux clairement séparés.

Le client

Windows ou Kubuntu.

CLIENT
   │
   │ IPP
   ▼

Le serveur

Le Raspberry Pi Zero 2 W :

PrintLBP
   │
 CUPS
   │
 Foomatic
   │
 CAPT
   │
   ▼

Le matériel

La Canon LBP-810 :

Canon LBP-810

Cette séparation est précisément ce qui transforme notre installation en serveur d’impression.

Le poste client n’a pas besoin d’être physiquement relié à la Canon.

Il n’a même pas besoin de connaître son ancienne interface USB.

Il parle à PrintLBP.

Le Raspberry fait le reste.

Une architecture étonnamment moderne.

Et c’est probablement ce qui est le plus amusant dans toute cette histoire.

La Canon LBP-810 est une imprimante d’une autre génération.

Son pilote CAPT date de 2004.

Et pourtant, notre architecture finale ressemble à quelque chose de parfaitement contemporain :

┌─────────────┐
│   Windows   │
└──────┬──────┘
       │
       │ IPP
       │
┌──────▼──────┐
│             │
│  PrintLBP   │
│ Raspberry   │
│   Pi Zero   │
│             │
│    CUPS     │
│   Avahi     │
│    CAPT     │
└──────┬──────┘
       │
      USB
       │
┌──────▼──────┐
│    Canon    │
│   LBP-810   │
└─────────────┘

Et Kubuntu peut rejoindre exactement la même infrastructure par IPP.

Alors, est-ce vraiment un serveur d’impression ?

À ce stade, la réponse est oui.

Nous avons :

Ce n’est donc plus une expérience théorique.

Le Raspberry Pi Zero 2 W est devenu le serveur d’impression de notre Canon LBP-810.

Et il tient dans quelques centimètres carrés.

Le plus beau test reste pourtant le plus simple.

Après toutes ces commandes, toutes ces traces, tous ces PPD et toutes ces discussions sur IPP, CUPS et CAPT, il reste finalement une méthode de validation beaucoup plus primitive :

imprimer une feuille.

Nous l’avons fait.

Et même mieux qu’une page de test.

À un moment, nous avons envoyé une véritable facture ChatGPT à l’impression.

La Canon l’a sortie normalement, avec des marges correctes.

C’est probablement le test le moins scientifique de toute l’aventure.

Mais aussi l’un des plus satisfaisants.

Une vieille imprimante est devenue une imprimante réseau.

Au début, nous avions simplement une Canon LBP-810 et l’idée de construire :

un serveur d’impression pour un réseau domestique.

Nous avons finalement obtenu :

Windows ──────┐
              │
Kubuntu ──────┼── IPP ──► Raspberry Pi Zero 2 W
              │                    │
              │                  CUPS
              │                    │
              │                  CAPT
              │                    │
              └────────────────── USB
                                   │
                                   ▼
                               Canon LBP-810

Le projet initial est donc atteint.

Mais il reste quelque chose.

Nous avons accumulé le pilote, les fichiers, les commandes, les configurations et toutes les connaissances nécessaires pour reproduire cette installation.

Il serait dommage de laisser tout cela dormir dans un dossier de notre laboratoire.

À suivre …

(C09) — Quand le serveur fonctionne… mais qu’on ne lui fait plus tout à fait confiance

Le serveur fonctionne.

La Canon imprime.

Windows imprime.

Kubuntu imprime.

Mais une question reste ouverte :

le serveur est-il réellement stable sur la durée ?

Les problèmes de Wi-Fi rencontrés avec Raspberry Pi OS Bookworm nous ont conduits à examiner différentes hypothèses, sans que nous puissions établir avec certitude la cause exacte des dysfonctionnements.

Nous allons donc changer de méthode : conserver exactement le même Raspberry Pi Zero 2 W, mais tester une autre image Linux.

Notre recherche nous conduira vers Armbian, puis vers Ubuntu 26.04 Minimal, avec une expérience comparative menée sans ping permanent ni modification inutile.

La question devient alors très simple :

est-ce que la même Pi peut enfin rester tranquille sur le réseau ?

Et si elle y arrive, il faudra ensuite transformer cette installation fonctionnelle en quelque chose de beaucoup plus précieux :

une configuration stable, sauvegardée et réellement reproductible.

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