EXP C07 — De l’imprimante USB au véritable serveur réseau
EXP C07 — De l’imprimante USB au véritable serveur réseau
Une imprimante qui n’est plus attachée à un ordinateur.
Jusqu’ici, nous avions réussi quelque chose qui paraissait déjà assez improbable :
Une Canon LBP-810 fonctionne sous Linux.
Le Raspberry Pi Zero 2 W faisait tourner Raspberry Pi OS Bookworm 32 bits, CUPS, Avahi et le pilote CAPT.
La Canon était reliée physiquement au Raspberry par USB.
Mais notre objectif initial était plus ambitieux.
Nous ne voulions pas simplement avoir :
computer
│
│ USB
▼
Canon LBP-810Nous voulions pouvoir installer la Canon dans le réseau domestique et permettre à plusieurs ordinateurs de l’utiliser.
Le Raspberry devait donc devenir quelque chose de beaucoup plus intéressant :
un véritable serveur d’impression.
Le Raspberry avait déjà tout ce qu’il fallait.
À ce stade du projet, l’infrastructure était déjà en place.
Nous avions :
Raspberry Pi Zero 2 W
│
├── Raspberry Pi OS Bookworm
├── ARMHF 32 bits
├── Wi-Fi
├── Avahi
└── CUPSLe Raspberry possédait également une identité sur le réseau :
PrintLBP.local
Avahi permettait notamment de publier les services réseau du serveur et CUPS était accessible depuis les autres machines.
Il ne manquait donc plus qu’une chose :
faire passer les travaux d’impression par le réseau.
Le choix du protocole : IPP
Nous n’avions finalement pas besoin de construire un système compliqué.
Le protocole d’impression utilisé allait être :
IPP — Internet Printing Protocol.
L’architecture devenait :
Network computer
│
│ IPP
▼
PrintLBP.local
│
▼
CUPS
│
▼
Foomatic
│
▼
CAPT
│
▼
Canon LBP-810Et c’est une différence fondamentale.
Le poste client n’a plus besoin de connaître les détails du matériel ancien.
Il parle au serveur.
Le Raspberry se charge du reste.
Une première surprise : Windows
Nous avons commencé par vérifier quelque chose d’assez important.
Est-ce qu’un ordinateur Windows pouvait réellement utiliser notre serveur ?
Nous nous attendions à devoir :
- saisir une adresse IP ;
- choisir un protocole ;
- indiquer un port ;
- éventuellement installer un pilote.
Mais Windows avait une autre idée.
Il a simplement découvert l’imprimante.
Et il l’a ajoutée.
Tout seul.
Nous n’avions rien eu à lui demander.
Et puis Windows a imprimé.
La découverte automatique était déjà amusante.
Mais elle ne suffisait pas.
Une imprimante peut parfaitement être visible sans être réellement utilisable.
Nous avons donc lancé une page de test.
Et la Canon l’a imprimée.
Aussitôt.
La chaîne complète était désormais :
Windows 11
│
│ IPP
▼
Raspberry Pi Zero 2 W
│
├── Avahi
├── CUPS
└── CAPT
│
│ USB
▼
Canon LBP-810
│
▼
TEST PAGECette fois, nous avions une preuve physique que toute la chaîne fonctionnait.
La feuille de test Windows identifiait notamment :
Canon_LBP-810 @ PrintLBP Microsoft IPP Class Driver
avec :
Processeur d'impression : winprint Environnement : Windows x64 Emplacement : RbPi0
À cet instant, quelque chose avait changé.
Nous n’étions plus en train d’essayer de fabriquer un serveur d’impression.
Nous en avions un.
Et Samba dans tout ça ?
Il faut préciser un détail, parce qu’il est facile de réécrire l’histoire après coup.
Nous avions envisagé Samba au cours de nos réflexions. C’était logique : une vieille imprimante, des PC Windows, un serveur Linux… le réflexe naturel aurait été de construire un partage SMB.
Mais Windows disposait de son propre Microsoft IPP Class Driver et pouvait donc dialoguer avec notre serveur sans avoir besoin de connaître les détails du pilote CAPT.
C’est exactement le genre d’architecture que nous espérions obtenir au début du projet.
Mais nous n’avons finalement pas installé Samba.
Ni pour Windows.
Ni pour Kubuntu.
Ce n’était tout simplement pas nécessaire.
Notre chemin était :
Windows │ │ IPP ▼ CUPS │ ▼ CAPT │ ▼ Canon LBP-810
et non :
Windows │ │ SMB / Samba ▼ Raspberry │ ▼ CUPS
C’est une petite différence dans le schéma, mais une grande différence dans la philosophie du projet.
Nous avions construit un serveur d’impression IPP, pas un serveur de fichiers auquel on aurait ajouté une imprimante.
Mais il y eut quand même une petite enquête.
La première découverte de Windows ne signifiait pas que tout avait été simple.
À un moment, les journaux CUPS nous ont donné une information particulièrement intéressante :
Validate-Job successful-ok Create-Job client-error-not-authorized Send-Document successful-ok
Windows envoyait donc bien ses requêtes au serveur.
Le problème se situait ailleurs.
En examinant la configuration de la file d’impression, nous avons finalement découvert :
Shared Yes AllowUser admin OpPolicy default
La configuration limitait la soumission des travaux à l’utilisateur admin.
Windows, lui, n’était évidemment pas connecté à CUPS sous cet utilisateur.
Cette petite restriction expliquait donc pourquoi nous pouvions avoir une communication IPP correcte tout en obtenant un mystérieux :
client-error-not-authorized
Une fois cette restriction supprimée, le flux pouvait fonctionner normalement.
Et c’est probablement l’un des meilleurs exemples de ce projet :
quand quelque chose ne marche pas, il faut regarder les traces plutôt que recommencer toute l’installation.
Le Raspberry est devenu le véritable serveur.
À partir de là, notre architecture n’était plus théorique.
Elle fonctionnait.
LOCAL NETWORK
┌───────────────┐
│ Windows 11 │
└───────┬───────┘
│
│ IPP
│
┌───────▼───────┐
│ │
│ PrintLBP │
│ │
│ Raspberry Pi │
│ Zero 2 W │
│ │
│ CUPS │
│ Avahi │
│ CAPT │
│ │
└───────┬───────┘
│
│ USB
▼
Canon LBP-810Le Raspberry était donc devenu une sorte de petite appliance d’impression.
Il pouvait rester dans un coin, connecté au Wi-Fi, avec la Canon branchée en USB.
Le PC n’avait plus besoin d’être allumé pour que l’imprimante soit disponible.
Une imprimante conçue à la fin des années 1990 et des ordinateurs modernes connectés en réseau.
Kubuntu : le pilote CAPT fonctionne.
Windows avait maintenant démontré que le serveur d’impression était accessible depuis le réseau.
Il restait à vérifier le comportement de notre côté Linux.
Sur la station Kubuntu, le pilote CAPT de Nicolas Boichat avait été compilé à partir des sources capt-0.1.
L’installation avait placé les éléments nécessaires aux emplacements attendus :
/usr/bin/capt /usr/bin/capt-print /usr/share/cups/model/Canon-LBP-810-capt.ppd
Le pilote était donc installé directement dans l’environnement d’impression de Kubuntu.
CUPS reconnaît alors la LBP-810 comme une imprimante Foomatic/capt
Le modèle proposé par l’environnement d’impression était :
LBP-810 Foomatic/capt (recommended)
Cette identification est importante : Kubuntu disposait non seulement du binaire capt, mais également du PPD Canon LBP-810 permettant à CUPS/Foomatic de présenter les caractéristiques de l’imprimante.
Les options d’impression étaient accessibles normalement, notamment :
A4 A4.Borderless Normal Grayscale FaceDown
La Canon pouvait donc être utilisée depuis l’environnement d’impression de Kubuntu avec ses paramètres propres.
Puis Kubuntu a rejoint le serveur.
Une fois le serveur d’impression installé sur le Raspberry Pi, la Canon n’avait plus besoin d’être considérée comme une imprimante directement attachée à la station Kubuntu.
La file d’impression pouvait utiliser le serveur CUPS du Raspberry par IPP :
ipp://192.168.1.40:631/printers/Canon_LBP-810
La chaîne devenait alors :
Kubuntu │ │ IPP ▼ Raspberry Pi Zero 2 W │ │ CUPS / CAPT ▼ Canon LBP-810
Le poste Kubuntu envoyait donc ses travaux au serveur, tandis que le Raspberry Pi assurait le traitement nécessaire à la Canon.
Cette configuration fonctionnait avec les options d’impression de la LBP-810 disponibles côté Kubuntu.
Un pilote ancien dans une architecture moderne.
C’est probablement l’aspect le plus intéressant de cette configuration.
Le pilote CAPT date d’une époque où cette Canon était encore une imprimante courante.
Pourtant, après compilation et installation sur une distribution Linux moderne, il pouvait toujours être utilisé par l’intermédiaire de CUPS et Foomatic.
Nous avions donc, d’un côté :
Kubuntu CUPS Foomatic CAPT
et de l’autre :
Raspberry Pi CUPS CAPT USB Canon LBP-810
avec IPP comme liaison réseau entre les deux.
Le résultat était particulièrement élégant : le poste Kubuntu conservait une véritable configuration d’impression LBP-810, tandis que le Raspberry Pi devenait le point central chargé de communiquer physiquement avec l’imprimante.
Et c’est là que les deux mondes se rejoignent.
Nous avions finalement deux clients très différents :
┌──────────────┐
│ Windows │
│ IPP Class │
│ Driver │
└──────┬───────┘
│
│ IPP
│
┌──────▼───────┐
│ │
│ PrintLBP │
│ Raspberry Pi │
│ │
│ CUPS + CAPT │
│ │
└──────┬───────┘
│
│ USB
▼
Canon LBP-810
▲
│
│ IPP
┌──────┴───────┐
│ Kubuntu │
│ CUPS/Foomatic│
│ + CAPT │
└──────────────┘Windows utilise son pilote IPP générique.
Kubuntu dispose du pilote CAPT et de son PPD.
Et au centre, le Raspberry Pi Zero 2 W assure désormais le rôle de serveur d’impression.
C’est à ce stade que la Canon LBP-810 cesse définitivement d’être simplement une vieille imprimante USB pour devenir une imprimante réseau multi-OS.
À suivre …
(C08) — Et maintenant, est-ce vraiment un serveur d’impression ?
La Canon LBP-810 est maintenant accessible depuis le réseau.
Windows l’a découverte sans pilote Canon ni partage Samba, et Kubuntu communique lui aussi avec notre serveur en IPP.
Mais une imprimante qui apparaît dans une liste n’est pas encore forcément un véritable serveur d’impression.
Il reste donc une dernière chose à faire :
tester la chaîne complète.
Dans le prochain chapitre, nous allons examiner plus précisément ce qui se passe sur le réseau et sur le Raspberry Pi, à partir des commandes et des traces que nous avons conservées pendant nos essais.
Nous vérifierons notamment :
- les files d’impression CUPS ;
- les connexions IPP ;
- la découverte du serveur par le réseau ;
- les travaux envoyés depuis Windows et Kubuntu ;
- et surtout les informations que nous donnent directement les commandes Bash.
AxehGo & DebIA
Independent Research & Experiments in Linux, AI and Statistical Computing
// discussion
No comments