Chapitre 12. Utilisation de l'imprimante / 12.7. Particularités de SUSE LINUX | ||||
|---|---|---|---|---|
 | 12.6. Configuration des applications | 12.8. Problèmes éventuels et leurs solutions |  | |
Chapitre 12. Utilisation de l'imprimante / 12.7. Particularités de SUSE LINUX | ||||
|---|---|---|---|---|
| 12.6. Configuration des applications | 12.8. Problèmes éventuels et leurs solutions | | |
De nombreuses fonctionnalités CUPS ont été adaptées pour être SUSE LINUX. Quelques-unes des modifications les plus importantes sont couvertes ici.
Il y a de nombreuses manières de configurer CUPS en tant que client d'un serveur réseau.
On peut, pour chaque file d'attente sur le serveur réseau, mettre en place une file d'attente locale et transmettre par son intermédiaire tous les travaux d'impression au serveur réseau correspondant. En règle générale, cette méthode n'est pas conseillée, car si la configuration du serveur réseau est modifiée, cela nécessite de reconfigurer tous les clients.
Il est possible de relayer des travaux d'impression directement sur un serveur réseau en particulier. Pour une telle configuration, il n'est pas nécessaire d'exécuter un démon CUPS local. La commande lp ou tout appel de la bibliothèque correspondante par d'autres programmes, permet d'envoyer des travaux directement au serveur réseau. Toutefois, une telle configuration ne fonctionne pas si l'on souhaite imprimer aussi sur une imprimante locale.
Le démon CUPS peut se tenir à l'écoute de paquets de diffusion IPP envoyés par d'autres serveurs réseau qui souhaitent signaler la mise à disposition de files d'attentes. C'est la meilleure manière de régler CUPS lorsque l'on souhaite pouvoir imprimer sur des serveurs CUPS distants. Une telle configuration comporte toutefois le risque qu'un attaquant envoie au démon des diffusions IPP mentionnant des files d'attentes. Le démon local accède ensuite à ces files d'attentes contrefaites et, lorsque l'attaquant propose une file d'attente portant le même nom qu'une autre file du serveur local, et que le paquet IPP a été reçu plus tôt, alors l'utilisateur croit avoir transmis un travail au serveur local alors qu'en réalité, le travail parvient au serveur de l'attaquant. Pour utiliser cette méthode, le port UDP 631 doit être ouvert aux paquets entrants.
YaST peut trouver les serveurs CUPS en scrutant tous les hôtes réseau pour voir si elles proposent ce service ou en surveillant les diffusions IPP. Cette deuxième méthode est utilisée pendant l'installation du système pour trouver les serveurs CUPS proposés. Pour cela, le port UDP 631 doit être ouvert aux paquets entrants.
La configuration par défaut du pare-feu telle qu'elle est affichée dans le dialogue
de suggestions est de rejeter les diffusions IPP sur toutes les interfaces. Cela signifie
que la deuxième méthode de détection des files d'attente distantes ainsi que la
troisième méthode d'accès aux files d'attente distantes ne pourront pas fonctionner.
Il est donc impératif de modifier la configuration du pare-feu en marquant l'une des
interfaces comme internal ce qui ouvre le port par défaut ou
en ouvrant de façon explicite le port d'une des interfaces ouvertes vers l'extérieur
(external). En effet, pour des raisons de sécurité, aucun des
ports n'est ouvert par défaut. Ouvrir un port afin de pouvoir configurer l'accès
aux files d'attente distantes suivant la deuxième méthode peut constituer un
problème de sécurité étant donné qu'un attaquant envoie des diffusions et que des
utilisateurs acceptent ainsi le serveur d'un agresseur.
L'utilisateur doit modifier la configuration du pare-feu qui lui est proposée de manière à permettre à CUPS de trouver les files d'attente distantes au cours de l'installation et par la suite, en fonctionnement normal, à permettre l'accès aux différents serveurs distants depuis le système local. On peut aussi envisager que l'utilisateur détecte les serveurs CUPS en scrutant activement les ordinateurs du réseau local ou qu'il configure à la main toutes les files d'attente. Cependant, nous ne conseillons pas cette possibilitée pour les raisons évoquées auparavant.
Afin de pouvoir utiliser l'administration avec le frontal web (CUPS) ou avec l'outil
d'administration d'imprimante (KDE), l'utilisateur root doit être déclaré en tant qu'administrateur
CUPS avec le groupe d'administration de CUPS sys et un mot de passe pour CUPS. Pour cela,
saisissez en tant que root la
commande suivante :
lppasswd -g sys -a root
Si vous ne procédez pas ainsi, l'administration depuis le frontal web ou depuis l'outil
d'administration ne sera pas possible car l'authentification échoue lorsqu'aucun
administrateur CUPS n'a été configuré. Au lieu de root, on peut également définir un autre
utilisateur en tant qu'administrateur CUPS (voir Section 12.7.3, « Modifications du service d'impression CUPS
(cupsd) »).
À l'origine, ces modifications ont été apportées pour SUSE LINUX 9.1.
Au démarrage, cupsd passe de l'utilisateur
root à l'utilisateur
lp. Ceci augmente le niveau
de sécurité car le service d'impression CUPS ne fonctionne pas avec des droits
illimités mais uniquement avec les droits nécessaires au service d'impression.
L'inconvénient résulte cependant dans le fait que l'authentification (la vérification
du mot de passe) ne peut pas s'effectuer par le biais de
/etc/shadow étant donné que
lp n'a pas accès à
/etc/shadow. Ainsi, l'authentification spécifique de
CUPS via /etc/cups/passwd.md5 doit être utilisée.
Pour ce faire, il faut entrer l'administrateur CUPS avec le groupe d'administration
CUPS sys et le mot de passe
CUPS dans /etc/cups/passwd.md5. Pour cela,
saisissez en tant que root la
commande suivante :
lppasswd -g sys -a <nom admin CUPS>
Lorsque cupsd fonctionne en tant que
lp, le fichier
/etc/printcap ne peut pas être créé, car
lp n'est pas autorisé à
créer des fichiers dans /etc/. C'est la raison pour laquelle cupsd crée
/etc/cups/printcap.
/etc/printcap est un lien symbolique vers
/etc/cups/printcap afin que les programmes
applicatifs qui ne peuvent lire le nom de la file d'attente que depuis
/etc/printcap puissent continuer à fonctionner
correctement.
Dès que cupsd fonctionne en tant que
lp il est impossible d'ouvrir
le port 631. C'est pourquoi cupsd ne peut plus être rechargé par le
biais de rccups reload. Il convient dont d'utiliser
rccups restart.
Les conditions d'accès configurées pour BrowseAllow et
BrowseDeny se réfèrent à tous les types de paquets envoyés
au démon cupsd. Les réglages par défaut dans
/etc/cups/cupsd.conf sont :
BrowseAllow @LOCAL BrowseDeny All
et
<Location /> Order Deny,Allow Deny From All Allow From 127.0.0.1 Allow From 127.0.0.2 Allow From @LOCAL </Location>
On peut ainsi accéder exactement aux ordinateurs de type
LOCAL sur le démon cupsd à un serveur CUPS. Les
ordinateurs de type LOCAL sont des ordinateurs dont
l'adresse IP n'appartient pas à une interface point-à-point (interface dont le flag
IFF_POINTOPOINT n'est pas à 1) et dont l'adresse IP
appartient au même réseau que le serveur CUPS. Tous les autres
ordinateurs rejettent immédiatement quelque paquet que ce soit.
Lors d'une installation standard, cupsd est activé
automatiquement, ce qui permet d'accéder confortablement aux files d'attente des
serveurs réseau CUPS sans avoir recours à d'autres opérations manuelles.
Les deux premiers points (voir Section 12.7.3.1, « cupsd fonctionne en tant qu'utilisateur lp » et
Section 12.7.3.2, « Fonctionnalité généralisée pour BrowseAllow et
BrowseDeny ») en sont les conditions
nécessaires. Dans le cas contraire, la sécurité ne serait pas suffisante pour
activer automatiquement cupsd.
Lors de la configuration de l'imprimante avec YaST, les files d'attente
de CUPS ne sont créées qu'avec les fichiers PPD installés sur le
système correspondant dans /usr/share/cups/model/.
Pour un modèle d'imprimante particulier, YaST relève les fichiers PPD
appropriés en comparant le nom du fabricant et celui du modèle relevé
lors de la reconnaissance de matériel avec les noms des fabricants et ceux des
modèles dans tous les fichiers PPD présents dans le système dans
/usr/share/cups/model/. Pour ce faire, la
configuration de l'imprimante avec YaST génère une base de données à
partir des informations concernant le fabricant et le modèle se trouvant
dans les fichiers PPD. Cela vous permet de choisir votre imprimante par le
biais des noms de fabricant et de modèle et d'obtenir par conséquent
les fichiers PPD correspondant aux noms du fabricant et du modèle.
L'avantage d'une configuration exécutée uniquement à l'aide de fichiers PPD et
sans aucune autre source d'informations est que les fichiers PPD sont modifiables
à volonté dans /usr/share/cups/model/. La configuration
de l'imprimante avec YaST relève les modifications et génère à nouveau la base
de données comprenant les noms des fabricants et des modèles. Si vous utilisez
uniquement des imprimantes PostScript, vous n'avez normalement besoin ni des
fichiers PPD Foomatic du paquetage cups-drivers
ni des fichiers PPD GimpPrint du paquetage
cups-drivers-stp. Vous pouvez copier les fichiers
PPD adaptés exactement à vos imprimantes PostScript dans
/usr/share/cups/model/ (si ceux-ci n'existent pas déjà
dans le paquetage manufacturer-PPDs) et configurer
vos imprimantes de manière optimale.
Les fichiers PPD génériques du paquetage cups ont
été spécialement complétés pour les imprimantes PostScript Niveau 2 et Niveau 1
avec les fichiers PPD Foomatic adaptés suivants :
/usr/share/cups/model/Postscript-level1.ppd.gz
/usr/share/cups/model/Postscript-level2.ppd.gz
Pour les imprimantes non PostScript, on utilise normalement le filtre d'impression
Foomatic foomatic-rip en même temps que Ghostscript.
Les fichiers PPD Foomatic adéquats sont caractérisés par les entrées
*NickName: ... Foomatic/Ghostscript driver et
*cupsFilter: ... foomatic-rip. Ces fichiers PPD se
trouvent dans le paquetage cups-drivers.
YaST utilise de préférence un fichier PPD Foomatic si un fichier PPD avec l'entrée
*NickName: ... Foomatic ... (recommended) correspond
au modèle d'imprimante et s'il n'existe aucun fichier PPD plus adapté dans le paquetage
manufacturer-PPDs (voir ci-dessous).
Pour beaucoup d'imprimantes non PostScript, il est possible d'utiliser comme
alternative à foomatic-rip le filtre CUPS
rastertoprinter de GimpPrint. Ce filtre et les fichiers
PPD GimpPrint appropriés se trouvent dans le paquetage
cups-drivers-stp. Les fichiers PPD GimpPrint se trouvent
dans /usr/share/cups/model/stp/ et sont caractérisés
par les entrées *NickName: ... CUPS+Gimp-Print et
*cupsFilter: ... rastertoprinter.
Le paquetage manufacturer-PPDs contient des
fichiers PPD de fabricants d'imprimantes couverts par une licence assez libre. Il
convient de configurer les imprimantes PostScript avec le fichier PPD adéquat du
fabricant d'imprimantes, celui-ci permettant d'utiliser toutes les fonctions de
l'imprimante PostScript. YaST utilise de préférence un fichiers PPD du paquetage
manufacturer-PPDs si les conditions suivantes sont
remplies :
Les noms de fabricant et de modèle déterminés lors de la reconnaissance du matériel
correspondent aux noms de fabricant et de modèle dans un fichier PPD du paquetage
manufacturer-PPDs.
Le fichier PPD du paquetage manufacturer-PPDs
est le seul fichier PPD adapté au modèle d'imprimante ou il existe un fichier PPD
Foomatic avec l'entrée *NickName: ... Foomatic/Postscript
(recommended) qui s'adapte également au modèle d'imprimante.
Dans les cas suivants, YaST n'utilise donc aucun fichier PPD du paquetage
manufacturer-PPDs :
Le fichier PPD du paquetage manufacturer-PPDs ne
correspond pas au nom du fabricant et du modèle. Ceci est surtout le cas si, pour des
modèles similaires, il n'existe qu'un seul fichier PPD du paquetage
manufacturer-PPDs, par exemple, si pour une série
de modèles, il n'existe pas un fichier PPD pour chaque modèle, mais que le nom de
modèle est spécifié sous la forme Funprinter 1000
series dans le fichier PPD.
Le fichier PPD Foomatic Postscript n'est pas recommandé parce que le modèle d'imprimante ne fonctionne pas suffisamment correctement en mode PostScript, par exemple l'imprimante peut fonctionner de manière peu fiable dans ce mode parce qu'elle a trop peu de mémoire ou bien elle est trop lente parce que son processeur n'est pas assez puissant. En outre, l'imprimante peut ne pas prendre en charge PostScript par défaut, par exemple parce que la prise en charge de PostScript n'est disponible que comme module optionnel.
Si, pour ces raisons, il existe un fichier PPD du paquetage
manufacturer-PPDs correspondant à cette
imprimante PostScript que YaST n'est pas à même de configurer, il
faut alors choisir à la main dans YaST le modèle d'imprimante adapté.
