SDB:CUPS in breve


Questo articolo è rivolto a utenti di Linux esperti. Esso non fornisce spiegazioni dettagliate: tutti gli argomenti legati a CUPS di rilevanza sono presentati in una forma concisa.

Indice

Panoramica sul sistema di stampa CUPS

Nei concetti di stampa sono esposti i concetti alla base dell'operazione di stampa.

Per una panoramica generale si può consultare la pagina "Panoramica di CUPS" (Overview of CUPS, dato che il contenuto molto probabilmente sarà in inglese) all'interfaccia web dell'istanza di CUPS in esecuzione sulla propria macchina locale, oppure leggere la documentazione, per la versione di CUPS effettivamente in uso, nel sito CUPS.org

Pagina principale del sito di CUPS: http://www.cups.org/

Fasi della lavorazione del processo di stampa:

Questo passaggio ha luogo sia sul sistema del client che su quello del server. Esso è inoltre l'unico passaggio ad essere eseguito sui client, non essendo presenti code di stampa su questi ultimi.

Creazione di un processo di stampa

Il programma di un'applicazione, o uno strumento da riga di comando, genera un processo di stampa e lo passa allo spooler.

Un processo di stampa è costituito da: le istruzioni per lo spooler di stampa, i dati di stampa (si vedano la definizione di PostScript e i concetti di stampa) e le istruzioni, opzionali, per il filtro (filter).

Esempio con strumento da riga di comando:

lp -d coda -t titolo -o option1=valore1 -o option2=valore2 file1 file2
  • "coda" (queue) e "titolo" (title) sono le informazioni per lo spooler (di stampa).
  • "option1=valore1" e "option2=valore2" sono le informazioni per il filtro.
  • "file1" e "file2" sono i dati di stampa.

I passi seguenti vengono eseguiti soltanto su un server CUPS. Un host su cui abbiano luogo i seguenti passaggi è un server. Un host su cui sia effettivamente presente una coda di stampa è un server (in contrasto con i client, nei quali esistono soltanto i riferimenti alle reali code di stampa).

Lo spooler di stampa (demone cupsd) esegue i seguenti passaggi:

Salvataggio del processo di stampa nella directory spool

  • Salvataggio delle informazioni per lo spooler, nonché per il filtro, nel file di controllo /var/spool/cups/c<processo-numero>
  • Salvataggio dei dati dai file da stampare nel file di dati /var/spool/cups/d<processo-numero>-<file-numero>

Filtraggio dei dati di stampa e invio alla stampante dei dati, specifici per il modello di stampante

  • Avvio del sistema di filtraggio:
    • Rilevamento di quali filtri sono necessari per generare i dati specifici per il modello di stampante e per instaurare la cosiddetta catena di filtri ("filter chain" o "filter pipe").
    • Avvio dei programmi della catena di filtri con i parametri appropriati.
  • Avvio del programma interfaccia (backend) per inviare i dati specifici della stampante dalla catena dei filtri (filter pipe) alla stampante.

Completamento del processo di stampa

  • Attesa che il backend concluda le sue attività.
  • Eliminazione dalla directory spool dei file relativi al processo di stampa in questione.

Lo Spooler

Funzioni dello spooler di stampa

Lo scopo principale del sistema spooler di stampa è di spostare dati dal mittente al ricevente.

  1. Accettazione dei dati (solo da mittenti autorizzati).
  2. Salvataggio temporaneo dai dati (in un buffer, per tutto il tempo in cui il destinatario non è ancora pronto per accettarli).
  3. Invio dei dati ai destinatari autorizzati (dopo aver applicato i filtri opportuni, se necessario).
  4. Fornire informazioni relative allo stato corrente dei dati (p.es., in riposta al comando "lpstat -W completed -o").

Dettagli:

/usr/sbin/cupsd

  • cupsd è il server per il protocollo IPP
  • cupsd è in ascolto sulla porta TCP 631, in attesa di richieste di attività via IPP, per esempio tramite comandi come { lp -d coda file; } o { lpstat -t; }
  • cupsd è in ascolto sulla porta TCP 631, per richieste di compiti via HTTP, coma gestire le stampanti con http://localhost:631/printers/
  • cupsd utilizza la porta UDP 631 per inviare e ricevere informazioni che riguardano la modalità "Browsing di CUPS" (si veda la sezione sul "funzionamento intrinseco di CUPS per stampare in una rete" più sotto). Per estrarre tali informazioni si possono usare comandi come { netcat -u -l -p 631; } (a condizione che la porta UDP 631 non sia già occupata da un'attività di cupsd)
  • Il file di configurazione per cupsd è: /etc/cups/cupsd.conf

/usr/lib/cups/daemon/cups-lpd

  • cups-lpd è il server per il protocollo LPD (RFC 1179)
  • cups-lpd accetta i processi di stampa che giungono in entrata alla porta TCP 515 tramite il protocollo LPD
  • Come wrapper per cups-lpd viene usato xinetd, oppure inetd
  • File di configurazione:
    • /etc/xinetd.d/cups-lpd
    • oppure, rispettivamente, la riga cups-lpd nel file /etc/inetd.conf

I file PPD

Cosa sono i file PPD e come funzionano

Vedere la sezione sui file PPD nei Concetti di stampa.

Per le stampanti PostScript, il file PPD contiene le opzioni specifiche per la stampante (e nient'altro), assieme ai corrispondenti frammenti di codice PostScript che devono essere inviati all'interprete PostScript al fine di attivare una certa opzione.

Per le stampanti non ti tipo PostScript, il file PPD contiene le informazioni aggiuntive che devono essere usate dal programma driver della stampante, assieme alle opzioni che sono disponibili per il particolare driver. Se per una certa stampante si possono usare più driver diversi, allora sono disponibili più file PPD.

A seconda delle opzioni specifiche della stampante impostate per un certo processo di stampa (p.es., "-o PageSize=A4"), il sistema di filtraggio legge i frammenti di codice PostScript appropriati (i cosiddetti valori di invocazione PostScript - "PostScript invocation values") dal file PPD e li inserisce nel flusso di dati PostScript.

La sintassi per la voce nel file PPD relativa ad un'opzione è come quella riportata qui di seguito, nelle due voci di esempio:

* Parola chiave Opzione/stringa equivalente "Valore invocazione PostScript"
*PageSize Letter/letter paper: "<</PageSize[612 792]/ImagingBBox null>>setpagedevice"
*PageSize A4/A4 paper: "<</PageSize[595 842]/ImagingBBox null>>setpagedevice"

Maggiori informazioni sono disponibili nel documento "Adobe PostScript Printer Description File Format Specification, Version 4.3".

Dettagli:

/etc/cups/ppd/

  • Questa directory contiene i file PPD effettivamente usati cupsd.
  • Le voci (in particolare le voci "*Default...") all'interno di uno dei file PPD contenuti in /etc/cups/ppd/ possono essere diverse dalle voci contenute nel file PPD originale, quello che è stato specificato mentre veniva configurata la coda.

/usr/share/cups/model/

  • Questa directory contiene i file PPD originali che vengono usati per configurare le nuove code di stampa. Si veda la sezione sui pacchetti forniti da openSUSE per i driver delle stampanti nei concetti di stampa per sapere da quali pacchetti sono forniti i vari tipi di file PPD.
  • In questa directory si possono copiare i file PPD aggiuntivi (p.es., i file PPD forniti dai produttori delle stampanti), al fine di renderli disponibili agli strumenti di configurazione delle stampanti.

Il database stampanti di OpenPrinting/LinuxPrinting.org

I filtri (e i driver)

A cosa serve il sistema di filtri e come funziona

Lo scopo principale del sistema di filtri (Filter) è di convertire i dati all'origine del processo di stampa (ASCII, PostScript, PDF) nei dati specifici per la stampante (PostScript, PCL, ESC/P), attraverso vari passaggi.

Solitamente l'ultimo passaggio consiste in un programma, che è il driver della stampante, che fornisce come risultato i dati finali specifici per la stampante, si veda la sezione su come effettivamente si "fa stampare una stampante" nei Concetti di stampa.

Normalmente, il filtraggio ha luogo per mezzo dei seguenti passaggi:

  1. Conversione dei dati originali nel formato PostScript.
    1. Determinazione del tipo di formato MIME dai dati di origine: Questo avviene in conformità a /usr/share/cups/mime/mime.types o a /etc/cups/mime.types.
    2. Conversione in PostScript (qualora i dati non siano già in tale formato): Qualora il tipo MIME dei dati all'origine non sia "application/postscript", si procede allora alla conversione di questi in PostScript, in accordo a /usr/share/cups/mime/mime.convs oppure a /etc/cups/mime.convs. In particolare, i dati originali del tipo MIME "text/plain" vengono convertiti in PostScript con (il programma) /usr/lib/cups/filter/texttops. A partire da CUPS 1.3.4 è supportato soltanto il testo con codifica UTF-8 (la quale include la codifica testo ASCII a 7 bit). Il testo con codifica ISO-8859 non è invece più supportato, dato che non è possibile rilevare automaticamente la codifica in modo tale che CUPS possa processare in maniera affidabile i file in testo semplice (plain) con codifica arbitraria, consultare en:SDB:Plain Text versus Locale. Per stampare testo non codificato in UTF-8, dovrà essere convertito dalla sua codifica ad UTF-8 prima di essere inviato al server CUPS. Ad esempio, per stampare un file di testo ISO-8859-1, su può usare:
      iconv -f ISO-8859-1 -t UTF-8 nomefile | lp -d coda

      Per informazioni su iconv si veda "iconv --help".

      La stampa di PDF o di file grafici (JPEG, PNG, etc.) funziona invece coma al solito.
  2. Inserimento dei valori di invocazione PostScript nel flusso di dati PostScript. Questo avviene in accordo con le seguenti righe in /usr/share/cups/mime/mime.convs o in /etc/cups/mime.convs:
    Tipo MIME sorgente Tipo MIME destinazione Costo Filtro
    application/postscript application/vnd.cups-postscript 66 pstops
  3. Conversione dei dati PostScript in dati specifici per la stampante. Nel caso in cui venga usata una stampante non PostScript assieme ad un file PPD Foomatic, i data PostScript vengono convertiti nei dati specifici per la stampante in accordo con le seguenti righe in ogni file PPD Foomatic (versione 3.x), se presenti:
    Parola chiave Tipo MIME sorgente Costo Filtro
    *cupsFilter: "application/vnd.cups-postscript foomatic-rip"

    Se una stampante non di tipo PostScript viene usata con un file PPD Foomatic, allora foomatic-rip svolgerà, assieme a Ghostscript, la funzione di interprete PostScript.

    Al fine di convertire i dati PostScript in dati specifici della stampante, foomatic-rip esegue le seguenti operazioni:

    1. Generazione del comando per Ghostscript: foomatic-rip crea un comando per Ghostscript con il driver della stampante Ghostscript necessario, assieme a parametri aggiuntivi in accordo con le opzioni specifiche per la stampante e impostate per il processo di stampa corrispondente. In alcuni casi, dopo il comando Ghostscript viene inserito in sequenza (con una pipe) un post-filtro (postfilter). Per esempio, per alcune stampanti PCL, alcune opzioni sono attuate per mezzo di catene (di comandi/filtri) inseriti nel flusso di dati PCL (p.es., selezione del vassoio della carta con "perl -e").
    2. Messa in esecuzione del comando Ghostscript (o della pipe): foomatic-rip esegue il comando Ghostscript. Nel caso in cui un file PPD non di Foomatic (cioè, per esempio, un file PPD Gutenprint/Gimp-Print dalla directory /usr/share/cups/model/gutenprint o da /usr/share/cups/model/stp) venga utilizzato per una stampante non PostScript, le voci con "*cupsFilter" nel file PPD si presenteranno probabilmente simili a quelle qui di seguito: *cupsFilter: "application/vnd.cups-raster 100 rastertogutenprint" oppure *cupsFilter: "application/vnd.cups-raster 100 rastertoprinter" con le voci corrispettive in /usr/share/cups/mime/mime.convs o in /etc/cups/mime.convs, da cui risulterà un processo di filtraggio differente. In questo caso particolare il programma driver della stampante sarà /usr/lib/cups/filter/rastertogutenprint o /usr/lib/cups/filter/rastertoprinter.

Per ulteriori informazioni di carattere generale sui filtri si veda la pagina di manuale "man 7 filter". Maggiori informazioni specifiche riguardo il filtraggio sono disponibili nell'articolo wiki del Database di supporto: en:SDB:Using Your Own Filters to Print with CUPS.

Dettagli:

/usr/lib/cups/filter/

Questa directory contiene i vari programmi filtro usati dal sistema di filtri di CUPS qualora sia stato specificato un file PPD mentre si configurava la rispettiva coda di stampa.

  • /usr/lib/cups/filter/*tops (p.es., /usr/lib/cups/filter/texttops) per convertire i dati originali (p.es., "text/plain" - solo testo) in PostScript.
  • /usr/lib/cups/filter/pstops per inserire i valori di invocazione PostScript e, se necessario, per riformattare i dati PostScript (p.es., per ridurre di dimensioni e stampare due pagine su un unico foglio).
  • /usr/lib/cups/filter/foomatic-rip per convertire i dati PostScript nei dati specifici per la stampante (p.es., PCL oppure ESC/P).

/etc/cups/interfaces/

Questa directory contiene il filtro usato da CUPS qualora si sia specificato uno "script interfaccia in stile System V" ("System V style Interface Script"), invece di un file PPD, mentre si configurava la rispettiva coda di stampa. Uno "script interfaccia in stile System V" ("System V style Interface Script") è un singolo programma filtro, o uno script filtro, che può generare i dati specifici della stampante a partire da tutti i formati di dato in cui i dati di stampa originali potrebbero essere stati inviati. Maggiori informazioni riguardo lo "script interfaccia in stile System V" ("System V style Interface Script") sono disponibili nell'articolo del Database di supporto: "Using Your Own Filters to Print with CUPS".

"raw" (dati grezzi)

Qualora non siano stati specificati né un file PPD né uno "script interfaccia in stile System V" ("System V style Interface Script"), mentre si configurava la rispettiva coda di stampa, allora non verrà effettuato alcun filtraggio. I dati di stampa originali verranno inviati direttamente dall'interfaccia sorgente (backend) alla destinazione (solitamente la stampante), così come sono (ovvero in formato "raw", grezzo). In tal caso non sarà possibile convertire i caratteri di interruzione di linea (p.es., LF -> CR+LF) o aggiungervi in fondo un carattere di "inizio pagina" (form feed). Per tale scopo si potrà invece usare uno "script interfaccia in stile System V" ("System V style Interface Script").

I backend

Cosa sono i backend di CUPS e come funzionano

Normalmente il backend riceve i dati specifici per la stampante dal filtro (filter) e li inoltra verso la stampante o un'altra destinazione.

Le differenze tra il backend e il filtro sono le seguenti:

  • Per processare un lavoro di stampa vengono attivati un solo backend ma, solitamente, svariati filtri (una catena di filtri, o filter chain). Eccezioni: "script interfaccia in stile System V" ("System V style Interface Script") (un unico filtro) e la stampa diretta (cioè senza filtri, "raw").
  • Nella catena delle operazioni, il backend è sempre l'ultimo programma ad essere eseguito per processare il lavoro di stampa.

Il sistema di stampa considera il processo di stampa terminato quando il backend ha completato le operazioni. Il backend ha terminato quando il trasferimento dei dati verso il destinatario è completato. Nel caso in cui le successive operazioni a carico della destinazione non dovessero andare a buon fine (p.es., se la stampante non fosse in grado di stampare i dati specifici per le stampanti), ciò avverrà senza che il sistema di stampa possa accorgersene.

Nel caso in cui il trasferimento dei dati alla destinazione non vada a buon fine (di solito dopo numerosi tentativi da parte del backend), il backend segnalerà un errore al sistema di stampa (più precisamente a cupsd). Il backend determinerà se e quanti tentavi sia opportuno fare prima di segnalare che il trasferimento non è andato a buon fine. Dato che tentativi ulteriori sarebbero unitili, cupsd procede a disattivare la stampa alla coda interessata. Una volta eliminata la causa del problema, l'amministratore del sistema dovrà nuovamente abilitare la stampa, con /usr/bin/enable (per CUPS 1.1 - cioè fino a Suse Linux 10.1), oppure con cupsenable (a partire da CUPS 1.2 - cioè da openSUSE 10.2 in avanti).

Per maggiori informazioni sui backend si vedano la pagina di manuale "man 7 backend", per quanto concerne strettamente i backend, e la pagina "man 7 filter", per informazioni generali riguardanti i filtri (i backend sono un tipo particolare di filtro). Informazioni più specifiche sui backend sono disponibili nell'articolo del Database di supporto en:SDB:Using Your Own Backends to Print with CUPS.

Dettagli:

/usr/lib/cups/backend/

Questa directory contiene i vari backend.

Il backend opportuno da usare deve essere scelto in base alla modalità con cui si può accedere alla stampante dall'host in cui è in esecuzione il sistema CUPS è al tipo di destinatario.

La destinazione a cui un backend può inviare i dati può essere un qualunque identificatore di risorsa (URI, Uniform Resource Identifier) per il quale sia disponibile un backend adeguato. La prima parte della voce "DeviceURI" (URI del dispositivo) nel file /etc/cups/printers.conf definisce il backend, le altre voci servono come parametri per il backend.

Backend Sintassi URI Esempio URI
parallel parallel:/dev/lp* parallel:/dev/lp0
usb (tradizionale) usb:/dev/usb/lp* usb:/dev/usb/lp0
usb (nuovo) usb://<costruttore>/<modello>?serial=<numero> usb://ACME/FunPrinter%201000?serial=A1B2C3
ipp ipp://<ipp-server.domain>/printers/<coda> ipp://cups-server.domain/printers/funprinter1000
lpd lpd://<lpd-server.domain>/<coda> lpd://192.168.101.202/lpt1
socket socket://<host.domain>:<porta> socket://192.168.101.202:9100
smb vedi la pagina man smbspool(8) smb://user:password@workgroup/smb-server/share

Nel caso in cui siano necessari "user" (utente) e "password" per il backend smb, allora proprietario, gruppo e permessi di accesso per il file /etc/cups/printers.conf dovranno essere sufficientemente restrittivi. Le impostazioni di "user" e "password" non sono visualizzate con il comando "lpstat -v".

Ciascun backend può anche essere richiamato direttamente. Per esempio, i backend "parallel" e "usb" restituiscono la stringa di identificazione IEEE-1284 delle stampanti collegate.

# /usr/lib/cups/backend/parallel 
direct parallel:/dev/lp0 "ACME FunPrinter 1000" "Parallel Port #1"
# /usr/lib/cups/backend/usb 
direct usb://ACME/USB%20Printer?serial=1234 "ACME USB Printer" "USB Printer #1"
direct usb:/dev/usb/lp1 "Unknown" "USB Printer #2"
...

Una volta avviato, cupsd esegue tutti i backends presenti in /usr/lib/cups/backend/, al fine di determinare quali backend sono disponibili in quel particolare sistema. Gli unici backend che si possono usare per la configurazione delle code sono i backend disponibili, visualizzabili con il comando "lpinfo -v".

Strumenti a riga di comando

Informazioni generiche sugli strumenti a riga di comando

Generalmente non è il caso di modificare a mano i file di configurazione in /etc/cups/, quando siano disponibili per tale scopo gli appositi strumenti a riga di comando.

Eccezione: /etc/cups/cupsd.conf.

Dopo aver apportato modifiche a /etc/cups/cupsd.conf, è necessario infatti riavviare cupsd, per far sì che possa usare la nuova configurazione.

Invece di modificare a mano i file spool di CUPS (in /var/spool/cups/) è meglio usare gli strumenti da riga di comando.

In particolare, non si dovranno mai modificare i file di CUPS manualmente, mentre il demone cupsd è in esecuzione.

Al contrario, gli strumenti da riga di comando per CUPS si limitano ad inviare a cupsd il compito da eseguire, che cupsd potrà poi espletare in modo appropriato.

Motivi:

I file di configurazione di CUPS non vengono in nessun caso riletti, né aggiornati istantaneamente. Al contrario, cupsd mantiene gran parte delle informazioni nella memoria principale e le scrive nei file di configurazione in momenti più o meno arbitrari (si veda la direttiva di configurazione per cupsd "DirtyCleanInterval").

Per esempio, per ripulire tutte le code di stampa si può eseguire "cancel -a", che elimina completamente tutti i (vecchi) (inclusa la cronologia dei lavori) in tutte le code di stampa.

Evitare di copiare i file di configurazione da un altro sistema su quelli in uso nel proprio sistema, a meno che si sia perfettamente consapevoli di ciò che si sta facendo. Usare invece gli strumenti a riga di comando.

Ad esempio, per impostare le stesse code di stampa su più macchine diverse (p.es., per un server di backup), invece di copiare i file /etc/cups/printers.conf e /etc/cups/ppd/* su ogni macchina, è consigliabile scrivere i relativi comandi in uno script (di solito una sequenza di comandi per lpadmin) ed eseguire lo script sulle varie macchine. In tal modo, ogni messaggio di errore verrà mostrato sulla macchina che lo riguarda (p.es., se un file PPD non è disponibile su una certa macchina, oppure se non è disponibile un backend o non pronto per l'uso). Inoltre, grazie a un tale script, si ha la possibilità di ripristinare le impostazioni in esso contenute ogni volta che sia necessario, semplicemente eseguendo nuovamente lo script medesimo.</li>

Quando non si è certi su quale applicazione grafica sia più opportuno usare per certe configurazioni particolari, risulta utile ricorrere invece agli strumenti a riga di comando.

Si osservi che, in gran parte dei casi, l'ordine con cui compaiono le opzioni è significativo, sarà allora opportuno leggere le pagine di man per i comandi. Ad esempio, i comandi seguenti producono tutti risultati diversi tra loro: 

lpadmin -E -p coda,
lpadmin -p coda -E
lpadmin -E -p coda -E

Dettagli:

Strumenti a riga di comando per creare o modificare le code

Ecco come configurare una coda di stampa in modo pienamente compatibile con CUPS:

  1. Ottenere dal demone cupsd l'elenco delle stampanti rilevate automaticamente, ciascuna con il rispettivo identificatore di dispositivo (URIdispositivo - DeviceURI) ad essa associato: lanciare (come root) "lpinfo -l -v"
  2. Ottenere dal demone cupsd l'elenco delle descrizioni dei driver di stampa disponibili: lanciare (come root) "lpinfo -l -m"
  3. Scegliere una stampante/URIdispositivo dal primo elenco e un driver della stampante dal secondo elenco. Scegliere un nome appropriato per la coda di stampa.
  4. Impostare la coda: lanciare (come root) "lpadmin -p nome_coda -v URIdispositivo -m driver_stampante -E", oppure "lpadmin -p nome_coda -v URIdispositivo -P /usr/share/cups/model/driver_stampante -E"

Non è necessario riavviare il demone cupsd per aggiungere, modificare, o eliminare una coda di stampa (è necessario riavviare cupsd solo quando si apportano modifiche alla configurazione di cupsd stesso).

Esempio per creare una coda:

# lpadmin -h localhost -p funprinter1000 -v parallel:/dev/lp0 -P /usr/share/cups/model/Postscript.ppd.gz -E

Per verificare le caratteristiche della coda appena creata:

$ lpstat -h localhost -a funprinter1000 -p funprinter1000 -v funprinter1000 
funprinter1000 accepting requests since Jan 01 00:00
printer funprinter1000 is idle.  enabled since Jan 01 00:00
device for funprinter1000: parallel:/dev/lp0

In alternativa a quest'ultimo comando, si può controllare il file /etc/cups/printers.conf: 

<Printer funprinter1000>
Info funprinter1000
DeviceURI parallel:/dev/lp0
State Idle
Accepting Yes
JobSheets none none
QuotaPeriod 0
PageLimit 0
KLimit 0
</Printer>

O ancora, si può interrogare il sistema usando il frontend web (interfaccia per il browser): http://localhost:631/printers/funprinter1000

Per modificare la coda (cioè, ad esempio, modificare descrizione e ubicazione) usare:

# lpadmin -h localhost -p funprinter1000 -D "ACME FunPrinter 1000" -L "2. floor: room 3"

Comando per visualizzare le opzioni specifiche della stampante e i valori predefiniti ad esse assegnati in /etc/cups/ppd/funprinter1000.ppd:

$ lpoptions -h localhost -p funprinter1000 -l 
Resolution/Output Resolution: 150dpi *300dpi 600dpi 1200dpi 2400dpi
PageSize/Media Size: Letter Legal Executive *A4 A5
...

La sintassi del risultato del comando mostrato è la seguente: 

nome_opzione/stringa esplicativa: valore_opzione valore_opzione valore_opzione ...

Il valore impostato come predefinito è quello contrassegnato da un asterisco "*" davanti al "valore_opzione".

Per modificare le impostazioni preimpostate specifiche della stampante in /etc/cups/ppd/funprinter1000.ppd:

# lpadmin -h localhost -p funprinter1000 -o Resolution=600dpi -o PageSize=Letter

La sintassi è la seguente: 

lpadmin -h localhost -p coda -o nome_opzione1=valore_opzione1 -o nome_opzione2=valore_opzione2 ...

Per questa operazione non si faccia riferimento a lpoptions, usare bensì l'articolo del Database di supporto: Print Settings with CUPS. Ciascun utente con privilegi normali utenti può usare lpoptions per salvare le sue personali impostazioni predefinite in ~/.cups/lpoptions (a partire da CUPS 1.2 / openSUSE 10.2, con CUPS 1.1 era ~/.lpoptions). Maggiori informazioni su questo argomento sono riportate nel suddetto articolo del Database di supporto.

Usare "accept" e "reject" rispettiva per accettare e per rifiutare i processi di stampa per una coda.

Usare /usr/bin/enable (se disponibile, ma non solo "enable" che è incorporato nella bash) o piuttosto /usr/sbin/cupsenable e "disable" (se c'è) o piuttosto /usr/sbin/cupsdisable, per abilitare e disabilitare la stampa in una coda (p.es., allo scopo di evitare che i processi di stampa vadano persi mentre si fanno lavori di manutenzione sulla stampante).

Per eliminare la coda:

# lpadmin -h localhost -x funprinter1000

Strumenti a riga di comando per l'utilizzo normale

Conviene evitare i comandi tipici di BSD (lpr, lpq, lprm), dato che supportano solo un numero limitato di opzioni generiche; usare invece i comandi propri di System V (lp, lpstat, cancel).

Per salvare i valori personali delle opzioni specifiche della stampante in ~/.cups/lpoptions (a partire da CUPS 1.2 / openSUSE 10.2, con CUPS 1.1 era ~/.lpoptions). Esempio:

$ lpoptions -o Resolution=1200dpi -p funprinter1000

Le opzioni di stampa disponibili per ogni utente sono descritte nella pagina "Command-Line Printing and Options", all'interno della sezione "Getting Started", sotto a "Documenti di guida in linea", accedendo all'interfaccia web di CUPS da un browser in esecuzione sulla propria macchina locale, oppure consultando la documentazione ("Documentation") per la versione di CUPS effettivamente in uso sul sito CUPS.org

Frontend web di cupsd

Ogni demone cupsd in esecuzione nella rete è dotato di un frontend web accessibile via HTTP. L'indirizzo URL per un'istanza di cupsd eseguita localmente è http://localhost:631 mentre l'indirizzo URL per un cupsd eseguito in remoto su "host.domain" è http://host.domain:631, a condizione che il cupsd remoto (o il server su cui è in esecuzione) consenta l'accesso ai client locali.

Dettagli:

Per le normali operazioni di tutti i giorni, di solito il frontend web è la fonte migliore da cui ottenere informazioni su code e processi di stampa. Per esempio, http://localhost:631/printers/ fornisce una panoramica di tutte le code in lavorazione su un'istanza locale di cupsd.

Il frontend web è il modo migliore per documentarsi sulla rispettiva versione di cupsd. Per esempio, la documentazione per la versione di CUPS installata in locale è disponibile la solito http://localhost:631 mentre la documentazione per la versione di CUPS installata su un server remoto è disponibile all'indirizzo http://host.domain:631, a condizione che il server remoto consenta l'accesso.

Anche ai file PPD in /etc/cups/ppd/ è possibile accedere per mezzo del frontend web. Per esempio, per accedere al file PPD relativo alla coda "funprinter1000" nell'host locale (/etc/cups/ppd/funprinter1000.ppd) si può usare l'indirizzo URL http://localhost:631/printers/funprinter1000.ppd e, di conseguenza, al file PPD relativo a "coda" su "host.domain" si potrà accedere con un URL della forma http://host.domain:631/printers/coda.ppd, a condizione che il server remoto consenta l'accesso.

Configurazione di CUPS <= 1.5 in una rete

CUPS >= 1.6 risulta incompatibile causa modifiche rilevanti

Dopo un aggiornamento di versione a CUPS >= 1.6, stampare in una rete non funzionerà più come aveva fatto fino a CUPS 1.5.

Per una panoramica su cosa c'è di nuovo in CUPS 1.6 si vedano http://www.cups.org/documentation.php/doc-1.6/whatsnew.html e http://www.cups.org/documentation.php/doc-1.7/whatsnew.html

Per i dettagli sulle modifiche in CUPS 1.6 e superiori che lo rendono incompatibile consultare https://bugzilla.novell.com/show_bug.cgi?id=735404 e seguire i collegamenti là riportati.

A partire dalla versione 10.8 "Mountain Lion", Mac OS X utilizza CUPS 1.6 (ma non OS X 10.7 "Lion", in cui è installato CUPS 1.5). Pare che i client con OS X 10.8 necessitino di un server CUPS 1.6 in grado di supportare la modalità con cui i client OS X 10.8 stampano via rete per impostazione predefinita. Di conseguenza reti che annoverano tra i client anche Mac OS X 10.8 richiederanno probabilmente la presenza di un server CUPS 1.6.

Gli utenti che necessitino di retro-compatibilità dovrebbero eseguire una versione di CUPS minore o uguale a 1.5 su un server e quelli che necessitano delle nuove funzionalità di CUPS 1.6 dovrebbero eseguire, in aggiunta, CUPS 1.6 su un altro server.

In particolare si noti che CUPS 1.6 richiede di solito i filtri del software cups-filters che è fornito da OpenPrinting.org.

Funzionamento intrinseco di CUPS <= 1.5 per stampare in una rete

Server di rete CUPS (host sui quali sono implementati spooler di stampa e sistema di filtri)

  • Il demone cupsd di un server di rete CUPS invia le informazioni relative alle code di sua competenza ad un elenco di indirizzi IP (indirizzi di host e/o indirizzi di broadcast). Per impostazione predefinita l'elenco è vuoto.
  • La trasmissione viene ripetuta ad intervalli di tempo prefissati. Il valore preimpostato è pari a 30 secondi.

Client (host che soltanto inviano i processi di stampa al server)

  • Per impostazione predefinita, cupsd si pone in ascolto per le informazioni provenienti dai server. Di conseguenza, su ogni client dovrebbe essere in esecuzione un'istanza locale di cupsd. È inoltre presente un elenco di server dai quali vengono accettate le informazioni in ingresso; l'impostazione predefinita è di accettare le informazioni provenienti da tutti i server.
  • Le informazioni relative ad una certa coda di stampa vengono cancellate dal client se non sopraggiunge alcuna nuova informazione, relativa alla coda, nel corso di un predeterminato intervallo di tempo. L'intervallo predefinito è di 300 secondi.

In tal modo, le code del server sono disponibili direttamente sul client. Gli utenti dei client sono in grado di esplorare (browsing) le code presenti sui vari server. Di conseguenza l'intera procedura è nota come (modalità) "Browsing".

La modalità Browsing è attiva per impostazione predefinita. Tutte le informazioni di browsing in ingresso vengono accettate, ma non viene inviata alcuna informazione di browsing (vedere sopra).

Configurazione di un server CUPS <= 1.5

  1. Configurare le code di stampa per le stampanti assegnate al server.
  2. Consentire ai client di accedere alle code.
  3. Attivare l'invio delle informazioni di browsing ai client.

Per rendere più semplice il lavoro di configurazione si dovrebbero fare ricorso a sotto-reti. Qualora si usino sotto-reti, sarà sufficiente inviare le informazioni di browsing sempre al solito indirizzo di broadcast, invece di mantenere costantemente aggiornato l'elenco con gli indirizzi dei singoli host.

L'accesso alle code presenti su un server è gestito in modo indipendente, indipendentemente da quali siano gli host a cui il server invii le informazioni di browsing. Un server può concedere l'accesso alle code su di esso presenti a tutti i client della rete, ma inviare le informazioni di browsing soltanto al alcuni dei suddetti client. In ogni caso, un server non dovrebbe inviare alcuna informazione di browsing ai client che non hanno accesso alle code su di esso presenti.

In una grossa azienda, non è possibile avere soltanto un unico grosso server che invia le informazioni di browsing, per alcune delle code, ai client di un dipartimento o di un edificio e le informazioni di browsing per le restanti code agli altri client.

Per una tale sistemazione sono necessari più server (uno per ciascun dipartimento o edificio).

Dettagli:

Configurazione delle code di stampa su un server CUPS <= 1.5

Qui le stampanti per le quali avviene il filtraggio sul server sono quelle che appartengono al server.

  1. Configurare le stampanti in modo tale che il servizio di stampa sia funzionante sul server.
    • Impostare le code di stampa per le stampanti associate al server.
    • Verificare che la stampa funzioni correttamente quando un semplice utente stampi direttamente dal server. In case di problemi ispezionare i messaggi di debug emessi da CUPS sul server, si veda più sotto.
  2. Consentire ai client di accedere alle code. Modificare manualmente il file /etc/cups/cupsd.conf o servirsi di YaST. A partire da openSUSE 11.1 utilizzare, in YaST, la procedura "Condividi le stampanti", vedere Stampante di YaST.
    1. Mettere dapprima il demone cupsd in ascolto sulla rete: Per impostazione predefinita il demone cupsd, a partire dalla versione 1.2 di CUPS (quindi da openSUSE 10.2 in poi), è configurato soltanto per restare in ascolto sulle interfacce della rete interna ("localhost") (e anche su un socket Unix domain), in /etc/cups/cupsd.conf per CUPS 1.2 e successivi: 
      Listen localhost:631
Listen /var/run/cups/cups.sock

      Per un server di rete con CUPS 1.2 (e successivi), è necessario modificare il file in modo tale che il server sia in ascolto anche sulla rete esterna. Aggiungere in tal senso una voce della forma "Listen IP.del.tuo.server".

      Se il server CUPS fosse accessibile da una qualche rete non fidata, assicurarsi di utilizzare un firewall per proteggere il suddetto server.
    2. Consentire quindi ai client di accedere al server: La configurazione preimpostata nel file /etc/cups/cupsd.conf è la seguente: 
      <Location />
Order allow,deny
Allow 127.0.0.2
</Location>

      L'accesso da "localhost" (127.0.0.1) è consentito in ogni caso, in mancanza di una voce apposita, mentre 127.0.0.2 potrebbe essere assegnato al nome host del server, in modo tale che sia anche consentito l'accesso tramite il nome host (hostname) del server.

      Per consentire l'accesso a tutti gli host presenti nell'intera rete locale, aggiungere una riga come la seguente: 

      Allow @LOCAL

      Questa impostazione permette a tutti gli host locali (LOCAL) di avere accesso a cupsd. Gli host LOCAL sono quegli host (locali) il cui indirizzo IP non è associato a interfacce di tipo PPP (più precisamente, le interfacce per le quali non è impostato il flag IFF_POINTOPOINT) e i cui indirizzi IP appartengono alla stessa rete di cui fa parte il server CUPS. Ciò significa che, solitamente, l'interfaccia di rete "Internet" che è connessa ai comuni modem risulta esclusa. Ma se invece è connessa ad un cable modem, allora non è un'interfaccia point-to-point, per cui in questo caso non si può usare "@LOCAL".

      Per consentire l'accesso da alcuni host particolari o da specifiche reti, aggiungere righe come le sottostanti: 

      Allow 192.168.100.1
Allow 192.168.200.0/255.255.255.0

      L'utilizzo degli indirizzi IP è da preferirsi a quello dei nomi.

      Differenze rispetto alle versioni di SUSE LINUX più vecchie:

      Da SUSE LINUX 9.0 fino a SUSE LINUX 10.1, la configurazione predefinita /etc/cups/cupsd.conf era: 

      BrowseAllow @LOCAL
.
.
.
<Location />
...
Allow @LOCAL
</Location>

      Con queste impostazioni era consentito a tutti gli host locali (LOCAL) di accedere a cupsd e, inoltre, i pacchetti da tutti gli altri host venivano rifiutati immediatamente.

      Fino a SUSE LINUX 10.1 era fornito CUPS 1.1 e, a partire da openSUSE 10.2, CUPS 1.2, il quale non è pienamente retro-compatibile con CUPS 1.1.

      Quindi (in caso di aggiornamento) si raccomanda di non usare l'obsoleto cupsd.conf per una precedente installazione di CUPS 1.1, bensì di partire dalla versione inalterata del file cupsd.conf, installata assieme al pacchetto RPM di CUPS 1.2 (or successivi).

      Per esempio "RunAsUser" non è più supportato, per cui a partire da openSUSE 10.2 / CUPS 1.2 il demone cupsd viene eseguito da root e, di conseguenza, si ha di nuovo a che fare con al sua "autenticazione di base" predefinita, via utenti e password di sistema (in /etc/shadow), per cui è di nuovo possibile autenticarsi come root e usare la password abituale per l'utente root del sistema.
  3. Attivare l'invio ai client delle informazioni di browsing In /etc/cups/cupsd.conf, impostare la voce "BrowseAddress @LOCAL" per inviare le informazioni di browsing a tutti gli host locali (LOCAL), oppure aggiungere voci nella forma "BrowseAddress client.host.IP.indirizzo" o "BrowseAddress network.broadcast.IP.indirizzo". L'invio delle informazioni di browsing è in una certa misura opzionale:
    • Se viene omesso, i client non riceveranno automaticamente le informazioni sulle code nel server;
    • Tuttavia, grazie al passaggio precedente, i client saranno in grado accedere alle code sul server.
    Specialmente nel caso di reti estese, può avere senso concedere l'accesso a tutti i client, ma inviare le informazioni di browsing soltanto ad alcuni client (p.es., solo ai client collocati nello stesso dipartimento o edificio del server).
  4. Riavviare il demone cupsd.

Ottenere i messaggi di debug di CUPS quando non funziona

Il "registro" (file log) di CUPS /var/log/cups/error_log contiene i messaggi di log che possono essere utili per risolvere eventuali problemi, ma per impostazione predefinita non contiene i messaggi di debug.

Per ottenere i messaggi di debug di CUPS, vedere la sezione "Usually provide CUPS debug messages" in en:SDB:How to Report a Printing Issue.

Nel caso in cui si disponga dei messaggi di debug di CUPS, ma questi non siano di aiuto nel trovare la causa alla base del suo malfunzionamento, si può chiedere aiuto nelle modalità descritte nella pagina apposita.

Configurazione dei client con CUPS <= 1.5

Parte raccomandata:

  1. Abilitare /etc/init.d/cups, cosicché cupsd venga avviato quando viene avviato il client.
  2. avviare cupsd.

A partire da SUSE LINUX 9.1, tutto questo avviene automaticamente, in maniera predefinita. Se necessario, lo si può fare usando l'editor per i Runlevel (Servizi di Sistema) di YaST, o con insserv. In circostanze normale, non sarà necessario configurare nient'altro, in particolare:

  • nessuna coda locale sui client
  • nessuna modifica alle impostazione predefinite di cupsd sui client.

Casi speciali di configurazione di CUPS <= 1.5 sui client

Parte facoltativa:

Inserire voci nella forma "BrowseAllow IP.del.server.desiderato" e "BrowseDeny IP.del.server.indesiderato" in /etc/cups/cupsd.conf, al fine di rifiutare tutti i tipi di pacchetto (informazioni di browsing incluse) dai server non desiderati. Si raccomanda di usare gli indirizzi IP al posto dei nomi. In alcuni casi, potrebbe essere utile modificare per le proprie esigenze la voce "BrowseOrder".

Se sono presenti server che non inviano alcuna informazione di browsing ma che consentono di accedere alle loro code (p.es., server in altri dipartimenti o edifici), si potrebbe voler interrogare (poll) i server per ottenere le informazioni di browsing. Per farlo, aggiungere nel file /etc/cups/cupsd.conf una voce nella forma "BrowsePoll IP.di.quel.server:631" per ciascun server da interrogare. Si raccomanda di usare gli indirizzi IP al posto dei nomi. Per impostazione predefinita, la porta sul server è la 631. Dopo aver riavviato cupsd, verrà avviata una istanza di cups-polld per ogni direttiva "BrowsePoll" inserita.

Procedere o modificando manualmente /etc/cups/cupsd.conf oppure usando YaST. A partire da openSUSE 11.3 usare da YaST la procedura "Stampa via rete", si veda l'articolo Stampante di YaST.

Se il browsing non è ammesso in generale:

Impostare "Browsing Off" in /etc/cups/cupsd.conf. Ciò non significa che non sarà più possibile accedere alla code sul server. Si potranno comunque ancora usare utilità come gli strumenti a riga di comando; tuttavia, sarà necessario specificare esplicitamente il server (solitamente con l'opzione "</code>-h</code>", si faccia riferimento alle relative pagine di man).

Configurazione solo client:

Se il browsing non è ammesso in generale, non c'è ragione per avere un'istanza di cupsd in esecuzione sul client. In questo caso, è opportuno usare una configurazione solo cliente (client-only). La si può configurare a mano come descritto qui sotto, oppure usando YaST. A partire da openSUSE 11.1 usare in YaST la finestra "Stampa via rete", vedere l'articolo Stampante di YaST.

  1. Arrestare e disabilitare cupsd (usando l'editor dei Runlevel (Servizi di Sistema) di YaST o insserv).
  2. In /etc/cups/client.conf, aggiungere una voce nella forma "ServerName IP.di.quel.server".

Tale voce non dovrebbe essere presente in /etc/cups/client.conf qualora vi sia cupsd in esecuzione il locale. Dato che è ammessa una sola voce di questo tipo, sarà opportuno inserirvi il server preferito. Per accedere a un server diverso, lo si dovrà specificare esplicitamente (opzione "-h") mentre si utilizzano gli strumenti a riga di comando, oppure si dovrà impostare opportunamente la variabile d'ambiente CUPS_SERVER. Alcune applicazioni ignorano la direttiva "ServerName". In tal caso, può essere utile impostare la variabile CUPS_SERVER, oppure potrebbe essere possibile specificare esplicitamente il server nella applicazione (p.es., con l'opzione "-h" nel comando per stampare).

Installazioni lato client minime:

Il numero minimo di componenti necessari per interfacciarsi in maniera standard con i server CUPS si ottiene installando i pacchetti "cups-libs" e "cups-client". In questo caso, per comunicare con i server si possono usare gli strumenti a riga di comando.

Tuttavia in assoluto il minimo strettamente necessario per comunicare con un server CUPS consiste nell'installare il solo pacchetto "cups-libs". In questo caso, solo i programmi che usano direttamente le librerie CUPS saranno in grado di stampare.

Considerazioni sul firewall

Se il server CUPS e i sistemi client si trovano in una rete interna, e quando tutti i sistemi presenti nella rete interna sono fidati, allora si può assegnare l'interfaccia di rete del proprio sistema alla "zone interna".

Non ha infatti senso avere una rete configurata nell'ambito di una rete interna fidata, ma con un'interfaccia di rete assegnata alla "zona esterna" non fidata (impostazione predefinita per ragioni di sicurezza).

A tal proposito si raccomanda di non disabilitare la protezione del firewall per CUPS (cioè per gli indirizzi IPP che usano le porta TCP 631 e la porta UDP 631) per la "Zona esterna" non fidata.

Si veda l'articolo del Database di supporto sulle impostazioni del Firewall con CUPS e SANE.

Consentire le attività di amministrazione stampanti ad un utente normale

A partire da openSUSE 10.2 / CUPS 1.2 con un file cupsd.conf creato per CUPS 1.2 (o successivi) (ovvero installato con una versione che supporta le politiche operative - o operation policies - di CUPS) è possibile consentire a un comune utente di eseguire operazioni di amministrazione di stampa, modificando il suddetto file come qui di seguito: 

<Policy default>
...
<Limit ... CUPS-Add-Modify-Printer ...>
Require user @SYSTEM utente-normale

In cui si dovrà sostituire "utente-normale" con il nome utente definito nel sistema (cioè il nome utente in /etc/passwd) dell'utente normale a cui si vuole consentire di eseguire operazioni di amministrazione stampanti e di riavviare cupsd.

Per i dettagli relativi alle politiche operative ("Operation Policies") consultare la documentazione sul sito di CUPS (alcune politiche operative sono anche configurabili nella scheda "Politiche" in YaST - Stampante).

Si tenga presente che un utente a cui sia consentito eseguire compiti di amministrazione di stampa è in grado di modificare le code di stampa a proprio piacimento. Per esempio potrebbe far sì che i processi di stampa (eventualmente confidenziali) vengano stampati come al solito (per non destare sospetti) ma in aggiunta inviare una copia di ciò che viene stampato verso una destinazione esterna.

Vedere inoltre

Portale di Stampa

Installare una stampante

en:SDB:Purchasing a Printer and Compatibility

en:SDB:Printing via TCP/IP network

en:SDB:CUPS and SANE Firewall settings

Stampante di YaST

Estratto da "https://it.opensuse.org/index.php?title=SDB:CUPS_in_breve&oldid=11918"