«Si j'ai bon caractère...
c'est pour faire bonne impression»

par Pascal Le Meur, SIC-Logiciels, e-mail: lemeur@sic.epfl.ch

Cette maxime chère aux imprimeurs, mon père ­qui en fut­ me la citait voilà bientôt trente ans. Je ne pensais pas alors, que trois décennies plus tard, elle serait au coeur de mes principales préoccupations: et Périphérix fut !

La mission de Péripherix

Tout d'abord rappelons la mission générale de ce groupe de travail: banaliser l'accès aux imprimantes. En d'autres termes tenter d'une part d'identifier un certain nombre d'outils y relatifs, d'autre part de gérer l'existant. C'est avant tout ce deuxième point qui retint notre attention afin de trouver des solutions, qu'elles soient matérielles ou logicielles, qui rendent possible l'impression depuis des plates-formes Unix ou PC sur les imprimantes présentes dans le monde Apple (archi-majoritaires sur notre site). Les dernières conclusions de Périphérix ­publiées dans les News fin 1993­ furent le choix de produits supportés par les différentes lignes de produits du site (ceci contrairement au choix du seul produit Xinet a priori présent sur les trois principales plates-formes de référence à savoir Sun, SG et HP mais de fait ne donnant totale satisfaction sur aucune d'elles). Par ailleurs dans le cadre des projets Cognac et SUSP les services de base tels que ceux liés à l'impression relèvent des départements. La situation actuelle peut donc être résumée ainsi: dans la mesure du possible les instituts sont encouragés à se rattacher à un serveur de département gérant ces problèmes d'impression. Le choix du logiciel implémenté sur ce dernier dépendant alors du type de plate-forme: CAP pour Sun et Dec Alpha, Xinet pour SG enfin Pacer pour HP (Pathwork restant bien sûr la solution Dec pour les quelques Vax encore présents sur le site).

Un certain nombre de licences Pacer et Xinet ont d'ores et déjà été acquises et distribuées par le SIC.

lpr ou lp, il faut choisir

De même certains départements ont déjà mis en place leur serveur d'impression basé en partie sur ces solutions: ainsi en est-il des DGR, DMX, DGM, DMT et autre DA. Certains instituts ont - par la force des choses - implémenté leur propre serveur: le cas n'est par exemple pas rare au DI. La présence de plate-forme Sun pouvant servir de passerelle ayant fortement influencé cela: CAP, produit gratuit, est officieusement supporté par le SIC depuis bientôt trois ans et officiellement par Périphérix. On notera au passage que ces produits permettent aussi l'accessibilité à l'espace disque des plates-formes Unix depuis les Macintosh.

Le choix d'un serveur ayant été arrêté... les différents clients restent à configurer, les problèmes liés à l'interopérabilité des systèmes peuvent faire leur entrée en scène!

Il existe dans le monde Unix deux systèmes d'impression: celui des machines de type BSD, par exemple Sun OS 4.x, pour lesquelles des requêtes de type lpr, lpq sont effectuées en s'appuyant sur le daemon lpd et celui des machines tournant un Unix Système V, SG et HP notamment, pour lesquelles des requêtes de type lp, lpstat, etc. sont à employer. L'implémentation de filtres, les manières d'opérer et de communiquer étant sensiblement différentes pour ces deux protocoles, le choix de celui à employer en fonction du serveur et des clients nous amène ici à faire quelques remarques.

Tout d'abord ce qui va être évoqué n'est pas lié aux produits cités précédemment mais seulement au caractère non unifié du système d'exploitation Unix. Ainsi, si la façon d'opérer du système lpr, en ce qui concerne l'impression distribuée, est relativement unique: un daemon lpd écoute les requêtes qui lui sont soumises par des clients distants et les réalise si ces derniers sont autorisés (cette authentification se faisant à l'aide du fichier /etc/hosts.lpd), il n'en est pas de même pour le système lp. L'implémentation de network printer s'y fait par l'utilisation des processus rlp côté client et rlpdaemon côté serveur sur les machines HP, tandis qu'un système basé sur des commandes de type rcp file et rsh lp file est employé sur les machines SG.

Cette dernière façon de faire étant pour le moins cavalière (puisqu'elle nécessite l'existence sur les clients et le serveur, de compte pour le user lp avec obligation côté serveur d'avoir un fichier .rhosts pour ce user permettant l'accès pour des commandes précitées) elle tendrait à nous faire croire que le mot socket n'est pas universellement reconnu dans la Vallée du silicone comme dirait Mr AllGood!

Enfin les diverses plates-formes de type système V implémentent en général un moyen de communiquer avec le système BSD, soit en gérant la communication avec le daemon lpd du serveur (par exemple HP, Solaris), soit en implémentant en parallèle les deux systèmes lp et lpr comme le fait SG. Le nombre de configurations possibles étant limité voici les principaux cas de figure observés ainsi que les remarques à faire sur les choix observés:

  1. Sun OS 4, et plus généralement les systèmes BSD, ne connaissent que le lpr. le serveur devra donc être capable de répondre à ce type de requêtes.
  2. SG livre les 2 systèmes bien que le lpr ne soit pas officiellement supporté.
  3. SAM l'utilitaire HP qui permet, entre autres, la configuration des imprimantes donne à l'administrateur le choix du type de protocole BSD ou System V.
  4. Il en est de même pour Solaris 2 sous l'utilitaire admintool. Cependant dans la quasi totalité des cas l'option BSD sera à employer.
  5. Alpha implémente les 2 systèmes mais livre en standard le lpr.
  6. Un client de type lpr a été mis sur \\odin\wlprsp\... par Ch. Zufferey. Pour plus d'informations voir sous Mosaic l'URL http://pcline.epfl.ch/pc/net/prn1.htm
  7. Le système lpr doit forcément être implémenter sur la SG. Les mécanismes du lp sur SG ne permettant pas -contrairement à HP- de résoudre les requêtes d'un lpr distant (voir aussi 2 et 9).
  8. Le rlpdaemon de HP est capable de résoudre les requêtes des deux systèmes.
  9. SG réclame pour certains des logiciels de la distribution l'emploi du système lp (exemple Showcase, Impressario, etc.) on pourra donc être amener à implémenter les deux systèmes en parallèle. Ils cohabitent très bien.
  10. Entre deux HP le système lp est le seul à utiliser. Les clients HP ne connaissent que les requêtes de ce type.
  11. le client HP doit déclarer le serveur SG de type BSD. Le serveur SG doit donc se comporter comme tel. Une implémentation non BSD fait que les requêtes d'un client HP génère l'emploi de la commande rlp par le système, le serveur SG n'ayant pas de processus de type rlpdaemon la requête ne saurait être réalisée. Une tentative d'implémentation de ce type a été tentée à l'IMHEF à l'avenue de Cour: nous avons constaté que le lpd était bien capable de répondre en partie à ce genre de requêtes mais que des interrogations de type lpstat renvoie des informations erronées ce qui est pour le moins perturbant pour l'utilisateur. Le dialogue via le protocole BSD lui a donc été préféré.
  12. un serveur LAN MANAGER du domaine public appelé samba existe qui permet aux clients Windows des sorties sur les imprimantes déclarées dans le système d'impression du serveur. Il est en cours de tests sur les plates-formes Sun et SG. Pour plus d'informations voir sous Mosaic l'URL http://pcline.epfl.ch/pc/net/prn1.htm.
  13. Les stations HP implémentent un serveur Lan Manager (LM/X) qui permet aux clients Windows des sorties sur les imprimantes déclarées dans le système lp de ces stations. voir sous Mosaic l'URL http://siihp.epfl.ch/HPUX/tools/lanman.html.

Le mot de la fin

Comme on peut le voir dans ce résumé la situation n'est pas aussi simple qu'on voudrait le croire et une conclusion du type après tout ce sont deux machines système V... employons donc lp qui est le standard de ce système ne peut pas être énoncé sans avoir regardé à deux fois: le cas le plus flagrant étant, comme on l'a déjà évoqué, lorsque le client est HP et le serveur SG, tous deux système V et se parlant BSD. Mais après tout vivant dans un pays où de part et d'autre de certaines barrières, la langue utilisée est parfois (souvent ?) l'anglais comment s'étonner de telles choses!

L'accès banalisé aux imprimantes entre les différentes plates-formes présentes sur notre site apparaît donc dans certains cas plus proche du bricolage que de l'outil clef en main, ceci tient avant tout à une certaine volonté des différents constructeurs, dans ce domaine comme dans bien d'autres, à préconiser leur solution plutôt que de jouer la carte de la réelle ouverture: le cas Palladium, superbe draftware censé fédérer les différentes approches pour résoudre ces problèmes et produit mort-né avant que d'être, en est une parfaite illustration. Le monde Windows étant de plus en plus présent, il faut savoir aussi que grâce au produit Lan Manager samba évoqué au point (12) il devrait être possible à des clients Unix d'accéder à des imprimantes connectées à des PC (l'information concernant ce produit sera mise à disposition sous Mosaic dans l'URL http://pcline.epfl.ch/pc/net/prn1.htm) .

Enfin une émanation du groupe Périphérix devrait prochainement s'occuper d'identifier, si possible, un ensemble d'imprimantes qui pourrait être recommandées pour le choix de futurs équipements. Au delà des problèmes de résolutions requises, de niveau de PostScript, de qualité des interpréteurs, les types d'interfaces proposées ainsi que les protocoles implémentés sur ces imprimantes seront, soyons en sûr, un des points les plus importants dans le choix de ces dernières.

Les personnes intéressées par plus d'informations sur les problèmes d'impression évoqués dans cet article peuvent consulter sous Mosaic l'URL http://slwww.epfl.ch/SIC/SL/servdist/accesimp.html mais aussi me contacter.


article paru dans le Flash informatique no 6 du 21 juin 1994