Chapter 12. Processo di stampa / 12.5. Particolarità di | ||||
|---|---|---|---|---|
 | 12.4. Configurazione della stampante | 12.6. Possibili difficoltà e la loro risoluzione |  | |
Chapter 12. Processo di stampa / 12.5. Particolarità di | ||||
|---|---|---|---|---|
| 12.4. Configurazione della stampante | 12.6. Possibili difficoltà e la loro risoluzione | | |
CUPS è stato rivisitato in alcune delle sue parti per poter essere eseguito su . Per comprenderne l'integrazione tratteremo di seguito le modifiche di maggior rilevanza.
Vi sono svariati modi di configurare CUPS come client di un server di rete.
Sussiste la possibilità di creare per ogni coda di stampa sul server di rete una coda di stampa locale e di inviare quindi tramite questa tutti gli incarichi alle rispettive code sul server di rete. Questo approccio viene sconsigliato perché dato che si modifica la configurazione del server di rete e di conseguenza si devono riconfigurare anche tutti i client.
Si potrà anche inoltrare gli incarichi di stampa direttamente ad un server di rete. Per una configurazione del genere non è necessario che giri un demone CUPS; lpr (o le corrispondenti chiamate di libreria di altri programmi) possono inviare gli incarichi direttamente al server di rete. Una configurazione del genere però non funziona se si vuole stampare tramite la stampante connessa localmente.
Si potrà anche mettere in ascolto di broadcast IPP. Il daemon CUPS si potrà mettere in ascolto di pacchetti IPP del genere che vengono inviati dagli altri server di rete per indicare le code di stampa disponibili sulla rete. Si tratta della miglior configurazione CUPS possibile- se si vuole stampare tramite server CUPS remoti. Nel caso di una configurazione del genere vi è però il pericolo che un aggressore riesca a intrufolare di soppiato delle code di stampa negli IPP broadcast e che il demone locale accede alle code di stampa del server dell' aggressore. Se si vuole ricorrere a questo metodo la porta 631/UDP deve essere aperta per pacchetti in entrata.
conosce due modi per rilevare il server CUPS:
Scandire la rete (ingl. “scan”), quindi chiedere ai sistemi sulla rete se offrono questo servizio.
Mettersi in ascolto di IPP-broadcast (come descritto sopra ). Questo metodo viene applicato anche durante l'installazione per rilevare i server CUPS da proporre.
Questo secondo metodo richiede che la porta 631/UDP sia aperta per pacchetti in entrata.
In tema di firewall va aggiunto quanto segue: l'impostazione di default del firewall (finestra proposta) è di non consentire dei broadcast IPP sull'interfaccia. Ciò vuol dire che il metodo due per rilevare e indirizzare code di stampa remote secondo il metodo tre non può funzionare. Quindi va modificata la configurazione del firewall: o si contrassegna una delle interfacce come internal, in tal modo la porta viene aperta di default o si apre in modo mirato la porta di un'interfaccia che punta verso l'esterno (external); poiché tutte le porte devono essere chiuse di default per motivi di sicurezza. Anche l'apertura esclusivamente ai fini di rilevamento (per indirizzare di code remote in base al metodo 2) rappresenta un problema di sicurezza — non è da escludere che gli utenti non leggendo attentamente le proposte incappano in un server di un aggressore.
Riassumendo: l'utente deve modificare la configurazione del firewall proposta per poter consentire a CUPS di rilevare code di stampa remote durante il processo di installazione () e per poter in seguito nel modo operativo normale indirizzare i vari server remoti dal sistema locale. Un'alternativa: l'utente incarica il sistema di rilevare il server CUPS eseguendo uno scan dei sistemi presenti sulla rete locale o configura manualmente tutte le code di stampa (per motivi suddetti questa alternativa non è consigliata).
Per poter eseguire l'amministrazione tramite il web frontend (CUPS) o tramite lo strumento di amministrazione della stampante (KDE) va creato l'utente root quale amministratore CUPS del gruppo di amministrazione CUPS sys corredato di una password CUPS; ciò può venir realizzato dando come root il seguente comando:
lppasswd -g sys -a root
Altrimenti non è possibile eseguire l'amministrazione tramite interfaccia web o strumento di amministrazione, visto che se manca l'amministratore CUPS fallisce il processo di autenticazione. Al posto di root si può anche stabilire un altro utente come amministratore CUPS; cfr. la sezione successiva Section 12.5.3, “Modifiche che interessano cupsd”.
Sotto sono state apportate delle modifiche al pacchetto originario cups che illustreremo brevemente di seguito. Per maggiori informazioni consultate l'articolo incluso nella banca dati di supporto “Printer configuration from 9.0 on” sotto http://portal.suse.com oppure degli altri articoli che trattano questa tematica eseguendo una ricerca tramite la parola Printer.
Dopo l'avvio, cupsd passa dall'utente root all'utente lp. In tal modo aumenta il livello di sicurezza visto che il servizio di stampa CUPS non gira con permessi illimitati, ma solo con quei permessi richiesti per il servizio di stampa.
Uno svantaggio però è rappresentato dal fatto che l'autenticazione (più precisamente: la verifica del password) non avviene tramite /etc/shadow dato che lp non ha accesso a /etc/shadow. Invece si deve ricorrere all'autenticazione specifica di CUPS tramite /etc/cups/passwd.md5. A tal fine va inserito l'amministratore CUPS, il gruppo di amministrazione CUPS sys ed una password CUPS in /etc/cups/passwd.md5; immettete come root:
lppasswd -g sys -a <CUPS-admin-name>
Altre conseguenze:
Se cupsd gira come lp, non si può generare /etc/printcap per il fatto che lp non ha il permesso di generare dei file in /etc/. Per questo motivo cupsd genera /etc/cups/printcap ed affinché sia garantito il corretto funzionamento delle applicazioni che leggono i nomi delle code di stampa solo da /etc/printcap, vi è un link simbolico che punta su /etc/cups/printcap.
Non appena cupsd gira come lp non è più possibile accedere alla porta 631 e così non è più possibile eseguire un reload del cups tramite un rccups reload. Ricorrete invece a rccups restart.
Le condizioni di accesso stabilite con BrowseAllow e BrowseDeny valgono per ogni tipo di pacchetto inviato a cupsd. Le impostazioni di default in /etc/cups/cupsd.conf sono:
BrowseAllow @LOCAL BrowseDeny All
e
<Location /> Order Deny,Allow Deny From All Allow From 127.0.0.1 Allow From 127.0.0.2 Allow From @LOCAL </Location>
In tal modo solo i sistemi LOCAL accedono al cupsd in esecuzione sul server CUPS. I sistemi LOCAL sono quelli con un indirizzo IP appartenente ad una interfaccia cosiddetta non point-to-point (più precisamente: interfacce senza un flag IFF_POINTOPOINT settato) e il cui indirizzo IP appartiene alla stessa rete del server CUPS. Pacchetti provenienti da altri host vengono subito rifiutati.
Nel corso di una installazione standard cupsd viene abilitato automaticamente. Questo consente di accedere comodamente, senza dover intervenire manualmente, a code di stampa dei server di rete CUPS. I due punti precedenti sono delle condizioni necessarie per realizzare una attivazione automatica di cupsd in tutta sicurezza.
Quando si esegue la configurazione della stampante tramite , le code di stampa per CUPS vengono generate ricorrendo esclusivamente ai file PPD, installati sotto /usr/share/cups/model/, del rispettivo sistema. individua i file PPD adatti per una determinata stampante comparando il nome del modello ed il nome del produttore, rilevati durante il processo di riconoscimento hardware, con quelli del produttore e del modello dei file PPD dei rispettivi sistemi reperibili sotto /usr/share/cups/model/. A tal fine, durante il processo di configurazione della stampante eseguito con , viene generata una banca dati composta da informazioni, riportati nei file PPD, riguardanti il produttore ed il modello in questione. In modo vi è possibile selezionare la vostra stampante tramite il nome del modello e del produttore e ottenere dei file PPD adatti per il modello in questione.
Eseguire la configurazione avvalendosi esclusivamente ai file PPD senza ricorrere ad ulteriori fonti di informazioni comporta il vantaggio di poter modificare a piacimento i file PPD residenti in /usr/share/cups/model/. Il rispettivo modulo di riconosce le modifiche apportate e genera una nuova banca dati composta dai dati sulla casa produttrice e modello della stampante. Se ad esempio disponete solo di stampanti PostScript solitamente non dovete ricorrere né ai file PPD Foomatic reperibili nel pacchetto cups-drivers né ai file PPD GimpPrint che trovate nel pacchetto cups-drivers-stp, ma solo copiare i file PPD tagliati per le vostre stampanti PostScript sotto /usr/share/cups/model/ (se non sono già inclusi nel pacchetto manufacturer-PPDs) e in tal maniera configurare la vostra stampante in modo ineccepibile.
I file PPD generici del pacchetto cups sono stati integrati con i seguenti file PPD Foomatic appropriati per stampanti PostScript level 2 e level 1:
/usr/share/cups/model/Postscript-level1.ppd.gz
/usr/share/cups/model/Postscript-level2.ppd.gz
Per stampanti PostScript di solito si ricorre al filtro di stampa Foomatic "foomatic-rip" accanto a Ghostscript. I file PPD appropriati Foomatic sono contraddistinti da "*NickName: ... Foomatic/Driver Ghostscript " e "*cupsFilter: ... foomatic-rip". Questi file PPD si trovano nel pacchetto cups-drivers.
dà la preferenza ad un file PPD Foomatic se sono date le seguenti condizioni:
Vi è un file PPD Foomatic "recommended" adatto al modello della stampante contraddistinto da quanto segue: "*NickName: ... Foomatic ... (recommended)".
Non vi è alcun file PPD tra i manufacturer-PPDs che sia più appropriato (si veda sotto).
Molte stampanti non PostScript consentono utilizzo del filtro CUPS "rastertoprinter" di GimpPrint al posto di "foomatic-rip". Questo filtro e i file PPD GimpPrint sono reperibili nel pacchetto cups-drivers-stp. I file PPD GimpPrint si trovano sotto /usr/share/cups/model/stp/ e sono contraddistinti da "*NickName: ... CUPS+Gimp-Print" e "*cupsFilter: ... rastertoprinter".
Il pacchetto manufacturer-PPDs contiene dei file PPD messi a disposizione dalle case produttrici coperti da una licenza gratuita. Stampanti PostScript dovrebbero essere configurate ricorrendo al file PPD appropriato del produttore, visto che il file PPD del produttore consente di sfruttare tutte le funzionalità della stampante PostScript. preferisce utilizzo di un file PPD preso dai manufacturer-PPDs, se sono date le seguenti condizioni:
Il nome del modello e del produttore rilevato durante il riconoscimento hardware sono identici a quelli contenuti nel file PPD preso da manufacturer-PPDs.
Il file PPD prelevato da manufacturer-PPDs è l'unico ad essere adatto al modello della stampante o vi è anche un file PPD Foomatic adatto che reca la seguente voce: "*NickName: ... Foomatic/Postscript (recommended)".
Nei casi riportati di seguito non ricorre a dei file PPD reperibili in manufacturer-PPDs:
Il file PPD non collima con il manufacturer PPDs per quel che riguarda il nome della casa produttrice e nome del modello. Cosa che spesso si verifica se vi è solo un file PPD in manufacturer-PPDs per modelli tra loro simili (ad es. nel caso in cui per la serie di un modello non è stato generato un file PPD per ogni modello della serie e come nome del modello nel file PPD vi è una indicazione del tipo "Funprinter 1000 series").
Il file PDD Postscript Foomatic non è del tipo “recommended”, per motivi dovuti al fatto che per esempio il modello della stampante non funziona bene nel modo PostScript, ovvero in modo inaffidabile poiché la stampante dispone di insufficente memoria oppure di un processore troppo lento, oppure infine perché non supporta PostScript di default (ad es. perché il supporto a PostScript è disponibile solo sotto forma di modulo opzionale).
Se per una stampante PostScript vi è un file PPD appropriato in manufacturer-PPDs ma , per i motivi citati sopra non è in grado di gestirli, allora il modello di stampante adatto va selezionato manualmente.
