cups - client.conf deprecato, o forse no?

Per anni, per installare le stampanti aziendali sui client Linux, mi sono limitato a:

  • Disabilitare (e mascherare) avahi-daemon, cups-browsed e cups.
  • Creare il file client.conf in /etc/cups/.
  • Indicare, all'interno di questo file, il server a cui inviare i vari job e, volendo, la versione del protocollo ipp da utilizzare (e altro, man client.conf).

Questa modalità funziona ancora e probabilmente continuerà a funzionare in futuro. A riprova di questo, molti dei programmi grafici di configurazione delle stampanti nelle distro Linux, hanno la possibilità di specificare un server remoto.

cups server remoto - centos 7
cups server remoto - centos 7

Peraltro, ho sempre pensato che questa fosse la modalità più "logica" e semplice da utilizzare. In realtà non è così.

https://www.cups.org/dcupsoc/man-client.conf.html

La documentazione ufficile dice che in macOs, la direttiva ServerName, non è più supportata da una certa versione in avanti e il file stesso non sarà più supportato nelle future release di CUPS (quest'ultima frase non si capisce se si riferisce solo a macOs o a CUPS in generale).

https://lists.cups.org/pipermail/cups/2015-October/027229.html

Leggendo questo interessantissimo link,  mi son reso conto che in effetti ci sono motivi validi per non utilizzare questa modalità di configurazione anche in un ambiente Linux. Andando a riassumere viene detto che:

  1. L'architettura di CUPS è pensata per avere un server cups installato sul client,   che  comunichi con un server remoto e che si occupi di una prima fase di gestione della coda di stampa e di filtraggio del job.
  2. La sottomissione diretta di job da un client a un server remoto può risultare difficoltosa in caso di problemi di rete. Avendo invece un server locale, i job arriveranno sempre e poi sarà lui stesso a reinviarli quando la rete tornerà attiva.
  3. Spesso mi è capitato che l'applet di sistema*, che mi presenta l'elelenco delle stampanti, si inchidasse e mandasse in crash anche il programma che l'aveva lanciata. Questo perchè, probabilmente, il server CUPS non era momentaneamente disponbile, oppure c'erano problemi di rete etc. Col server locale sempre disponibile, e di un ordine di grandezza più veloce (unix socket vs network socket), l'applet di stampa non si inchioderà (si spera).
  4. Avere un server solo, con un'unica configurazione per tutte le stampanti, a cui arrivano job diretti da dispositivi molto diversi (mobile, laptop, desktop), con sistemi operativi molto diversi (Android, Linux, macOs, iOs etc), può non essere una buona idea. Meglio avere sui singoli client un server CUPS (o un server di gestione delle stampanti) che conosca il sistema su cui sta girando e che mandi al server remoto dei job "pre-lavorati".
  5. Piccola esperienza personale: configurare le stampanti su un laptop/notebook di un ospite della mia struttura, utilizzando client.conf e la direttiva ServerName, significa condannare il malcapitato a non poter "mai" più stampare quando dalla mia struttura se ne andrà. Il server cups è ovviamente dietro firewall e non si potrà contattare da fuori, per cui l' ospite, quando sarà tornato a casa e proverà a stampare, nella migliore delle ipotesi non ci riuscirà e nella peggiore gli si inchiderà l'applet.

Detto questo,  qual è l'alternativa per dei client Linux che vogliono stampare sulle stampanti aziendali condivise su un server CUPS remoto?
Utilizzare cups-browsed e il demone avahi. Le configurazioni da fare sono però SICURAMENTE più complesse rispetto a quelle del metodo che utilizzavo precedentemente, che consisteva nel disabilitare 3 servizi e scrivere una riga in un file.

CLIENT

cupsd.conf

Sul client dove ho installato il server CUPS, non voglio nè pubblicizzare le stampanti che verranno create localmente, nè che esse siano condivise tramite alcun protocollo sulla rete.

***Se vuoi amministrare il server da un altro pc e accedere all'interfaccia web temporaneamente da ovunque***
Listen 631
e in tutte le location
Order allow,deny
Allow all

cups-browsed.conf

Qui riporto uno stralcio della documentazione ufficiale.

Per effettuare il debug e vedere che code di stampa aggiunge in tempo reale.

Queste le direttive da modificare, con la spiegazione lasciata in bella vista.

cups-browsed deve cercare remotamente le stampanti tramite il protocollo dnssd (e il vecchio cups), NON condividere le stampanti che andiamo a creare localmente, accettare i pacchetti di condivisione della stampanti solo da un determinato server e infine andare a contattare solo quel determinato server per avere l'elenco delle stampanti.

avahi-daemon.conf

Qui mi limito  a togliere ipv6.

Il comando per vedere cosa browsa avahi è
avahi-browse -a | grep Printer
(se non va al primo colpo, restarta)
systemctl restart avahi-daemon.service


Si attivano tutti  e 3 i servizi cups, cups-browsed, avahi-daemon e "magicamente" le stampanti condivise sul server appariranno dopo qualche secondo sul client.

NOTE

DEFAULT - PRINTER

https://github.com/apple/cups/issues/4412

https://bugs.launchpad.net/ubuntu/+source/cups-filters/+bug/1313748

Riporto uno stralcio di uno di questi link:

The default printer bit was not included in the Bonjour broadcasts intentionally as it can get confusing if there is more than one server advertising
What you can do is marking any printer, the ones discovered by cups-browsed included, as default printer. As cups-browsed does not remove the local default printer when it shuts down (or when the printer disappears), the default setting once done stays conserved until changed. printers.

In sostanza, la stampante di default del server non viene riportata di default sul client (come invece accadeva con client.conf e la direttiva ServerName). Per ovviare a questo problema  si va nell'interfaccia web -> printers -> seleziono la stampante che voglio come default, Administration -> Set as Server Default.

Questa operazione non fa altro che mettere
<DefaultPrinter nome_coda></DefaultPrinter>
in printers.conf al posto dello standard creato
<Printer nome_coda> </Printer>

Questa modifica è persistente ai riavvii del server (e del computer), anche se, quando fermi cups-browsed, printers.conf si svuota. Il motivo è che cups-browsed si salva le configurazioni precedenti in
/var/cache/cups/cups-browsed-*
In particolare, per quanto riguarda la stampante di default, viene creato un file
cups-browsed-remote-default-printer
che contiene il nome della coda di default.
Questo lo si impara guardando il debug di cups-browsed.

 

ERROR POLICY

Anche se sul server tutte le code di stampa hanno

sul client, le code create da cups-brosed hanno

Per ovviare a questo problema è sufficente mettere in cups-browsed

che da documentazione

Peccato che però io non sia riuscito in alcun modo a far funzionare questa opzione.

PERSONALIZZAZIONE DELLE OPZIONI DELLA CODA

Con questa modalità di configurazione,  le code possono essere personalizzate localmente.

Questo è un bene perchè così ciascuno può modificarsi, sul suo client, le opzioni che vuole. L'amministratore sul server metterà  una configurazione standard che può andar bene a tutti e poi ciascuno se la modifica come preferisce.
Per personalizzazioni si intendono le opzioni tipo fronte/retro di default, tipo e qualità della carta,  vassoi, filigrane etc. Queste opzioni sono memorizzate nel ppd. Il ppd viene preso dal server e copiato in locale, per cui mi ritrovo sul client tutte le opzioni volute dall'amministratore, e le posso modificare localmente come preferisco.

*APPLET DI STAMPA

Per applet di stampa intendo questo (esempio con gedit).

SERVER

Della configurazione di un server cups ne ho già parlato diffusamente molte volte. Qui mi limitio a riportare qualche appunto.

  • Blocco sia cups-browsed che avahi-daemon tenendo attivo solo cups
  • Browsing off perchè non voglio pubblicizzare sulla rete le stampanti condivise
  • BrowseLocalProtocols dnssd è attivo per permettere lo sharing
  • Ciascuna stampante create in printers.conf ha la direttiva shared=yes

 

cupsd.conf

printers.conf -> esempio di una stampante

 

Print Friendly, PDF & Email