David Madore's WebLog: Encore une râlerie sur CUPS

Index of all entries / Index de toutes les entréesXML (RSS 1.0) • Recent comments / Commentaires récents

Entry #2327 [older|newer] / Entrée #2327 [précédente|suivante]:

(lundi)

Encore une râlerie sur CUPS

J'ai déjà dit que je détestais CUPS ? Ah oui, et plus d'une fois.

Le contexte : Télécom ParisSaclayPloumTech a mis en place un nouveau système d'impression : maintenant, pour imprimer un document, il ne nous est plus possible de simplement l'envoyer à l'imprimante et aller le chercher un peu plus tard : à la place, il faut l'envoyer à un serveur centralisé, puis marcher jusqu'à l'imprimante, badger avec notre carte RFID, sélectionner le document qui est censé être apparu dans une liste de travaux d'impression, et poireauter le temps que l'imprimante fasse son travail. Le motif officiel du changement est que c'est tellement plus simple, plus commode, plus confidentiel et globalement plus mieux comme ça. Le motif réel est sans doute de contrôler la dépense de consommables : ce qui est parfaitement légitime, parce que vu que j'ai déjà gâché une centaine de pages juste pour réussir à faire fonctionner tout ce foutoir, j'imagine effectivement qu'il y a beaucoup de pertes, et le fait de devoir attendre devant l'imprimante pour que le document sorte limitera sans doute le zèle dont on peut faire preuve en matière de consommation de papier.

Maintenant, pour imprimer avec ce système centralisé, il faut soumettre le document au serveur CUPS central (qui va ensuite l'envoyer à l'imprimante qui le demande, je ne sais pas par quel protocole). Il faut donc convaincre mon serveur CUPS local (celui qui tourne sur mon ordinateur de bureau) d'envoyer les documents que je veux imprimer au serveur CUPS central de l'école. Jusque là, pas de difficulté : il suffit de déclarer une imprimante ipps://le-serveur-centralise.telecom-parissaclayploumtech.tld/printers/Central_Printer et d'y envoyer tout. • La difficulté, en revanche, c'est que mon nom d'utilisateur n'est pas le même sur ma machine locale (où c'est mon prénom) que sur le système d'authentification de l'école dont dépend le serveur centralisé (c'est mon nom de famille). En principe, il devrait suffire de changer l'adresse ci-dessus en ipps://monlogin@le-serveur-centralise.telecom-parissaclayploumtech.tld/printers/Central_Printer pour que ça marche. Sauf que cet imbécile de CUPS ignore purement et simplement la partie monlogin@ de l'adresse sans me dire ni que l'adresse est incompréhensible ni qu'il ne peut pas utiliser de login différent ni quoi que ce soit. Pas de panique : on peut aussi changer les options job-originating-user-name ou requesting-user-name dans les réglages de l'imprimante. Sauf qu'en fait non : soit je n'ai pas réussi à trouver comment les changer, soit ça n'a aucun effet (de nouveau, ces paramètres sont ignorés silencieusement, ils ne provoquent pas d'erreur ou d'avertissement quelconque). • Bon, alors que conseille le service informatique ? Une solution affreuse : au lieu de changer le login auquel le document sera envoyé sur leur serveur à eux, ils proposent de le changer dès le serveur local (i.e., envoyer les documents à mon serveur CUPS local sous mon nom de login distant). Cette solution est affreuse, parce que ça suppose que je ne parlerai jamais à d'autre serveur CUPS (ce qui est sans doute vrai de ma machine de bureau, mais beaucoup plus incertain pour ce qui est de mon portable), ou en tout cas d'autre serveur CUPS sur lequel j'aurais un login différent. Elle est affreuse, aussi, parce que ça veut dire que je dois la répéter pour chacun des comptes sur mon ordinateur local sur lequel je peux avoir envie d'imprimer. Et elle est affreuse parce que ça signifie que tous les mécanismes de configuration de CUPS par l'interface Web ne vont pas en tenir compte (par exemple, ça casse la possibilité d'imprimer une page de test simplement). Mais admettons, je me résous à cette solution affreuse. Je modifie donc mon $HOME/.cups/client.conf pour y ajouter User monlogin (et je redémarre tout ce qui a un rapport avec CUPS). Est-ce que ça marche ? Non, bien sûr : de nouveau, la précision est purement et simplement ignorée. Finalement, ce qui a marché est d'ajouter une variable d'environnement CUPS_USER=monlogin (et ajouter une variable d'environnement dans les environnements graphiques d'Unix, i.e., convaincre tout le labyrinthe de programmes Gnome, KDE ou autres de propager la valeur de cette variable, ce n'est d'ailleurs pas du gâteau).

Bon, à la limite, je ne me plains pas du fait qu'on doive changer une variable d'environnement ou autre chose. Mais ce qui est franchement insupportable, c'est toutes ces tentatives qui ne font tout simplement rien. Si le serveur ne comprend pas une adresse en ipps://login@server, il devrait la refuser, pas ignorer silencieusement la partie qu'il ne comprend pas ! Si les programmes ne comprennent pas la directive User dans le .cups/client.conf, ils devraient le signaler, pas l'ignorer silencieusement.

Et l'autre chose pénible, c'est que même si maintenant j'ai quelque chose qui marche, est évident que cette solution n'est pas robuste du tout : tôt ou tard, je vais me retrouver dans une situation où la variable CUPS_USER aura disparu (par exemple parce qu'Ubuntu aura changé une fois de plus son mécanisme de démarrage des sessions graphiques et donc cassé mon code) ou bien elle va cesser de fonctionner, ou encore je vais oublier qu'elle est là et vouloir me connecter à un autre serveur et ne pas comprendre pourquoi mon login est madore plutôt que david, ou je ne sais quoi encore. Forcément, ce truc va revenir me mordre un jour ou un autre, et je ne vois vraiment pas comment l'éviter.

[Références : ce bug Ubuntu et ce thread sur serverfault.]

Et hop, une entrée de plus pour le Unix-Haters Handbook.

↑Entry #2327 [older|newer] / ↑Entrée #2327 [précédente|suivante]

Recent entries / Entrées récentesIndex of all entries / Index de toutes les entrées