| SUSEDocumentazione LINUX Capitolo 31. Uso della stampante / 31.6. Funzionalità speciali in SUSE Linux | ||||
|---|---|---|---|---|
 | 31.5. Configurazione per le applicazioni | 31.7. Risoluzione dei problemi |  | |
| SUSEDocumentazione LINUX Capitolo 31. Uso della stampante / 31.6. Funzionalità speciali in SUSE Linux | ||||
|---|---|---|---|---|
| 31.5. Configurazione per le applicazioni | 31.7. Risoluzione dei problemi | | |
Alcune funzionalità di CUPS sono state adattate per SUSE Linux. Alcune delle modifiche più importanti sono illustrate in questa sezione.
CUPS può essere configurato come client di un server di rete in vari modi.
Per ogni coda nel server di rete è possibile configurare una coda locale per l'inoltro di tutti i lavori al server di rete corrispondente. Questo approccio non è in genere consigliabile poiché tutti i computer client devono essere riconfigurati ogni volta che la configurazione del server di rete viene modificata.
I lavori di stampa possono anche essere inoltrati direttamente a un server di rete. Per questo tipo di configurazione non eseguire un daemon CUPS locale. lp o la chiamata alla libreria corrispondente di altri programmi possono inviare i lavori direttamente al server di rete. Tuttavia, questa configurazione non è valida se si desidera eseguire una stampa anche su una stampante locale.
Il daemon CUPS può ascoltare i pacchetti di diffusione IPP inviati da altri server di rete per segnalare code disponibili. Per utilizzare questo metodo, è necessario che la porta 631/UDP sia aperta per i pacchetti in entrata.
Questa è la configurazione di CUPS più appropriata alla stampa su server CUPS remoti. Esiste tuttavia il rischio che un attaccante invii diffusioni IPP con code e che il daemon locale acceda a una coda contraffatta. Se tale coda viene quindi visualizzata con lo stesso nome di un'altra coda presente nel server locale, il proprietario del lavoro può credere che il lavoro sia stato inviato a un server locale, mentre è stato inviato al server dell'attaccante.
I server CUPS possono essere individuati da YaST tramite una scansione di tutti gli host di rete per determinare se offrono questo servizio e mediante l'ascolto delle diffusioni IPP. La seconda procedura viene utilizzata durante l'installazione del sistema per individuare server CUPS adatti allo scopo. Per utilizzare questa procedura, è necessario che la porta 631/UDP sia aperta per i pacchetti in entrata. L'apertura di una porta per configurare l'accesso a code remote tramite la seconda procedura può costituire un rischio per la sicurezza poiché un attaccante potrebbe diffondere pacchetti a un server che potrebbe essere accettato dagli utenti.
L'impostazione di default del firewall illustrata nella finestra di dialogo di suggerimento consiste nel rifiutare le diffusioni IPP in qualsiasi interfaccia. Di conseguenza, la seconda procedura per il rilevamento delle code remote e la terza procedura per accedere alle code remote non possono essere utilizzate. La configurazione del firewall deve quindi essere modificata contrassegnando una delle interfacce come interna, scelta che determina l'apertura della porta per default, oppure aprendo esplicitamente la porta di un'interfaccia esterna. Per motivi di sicurezza, nessuna porta è aperta per default.
La configurazione del firewall proposta deve essere modificata per consentire a CUPS di rilevare le code remote durante l'installazione e l'accesso a server remoti dal sistema locale durante il normale funzionamento. In alternativa, l'utente può rilevare i server CUPS eseguendo attivamente una scansione degli host della rete locale o configurando manualmente tutte le code. Questa procedura non è tuttavia consigliata per i motivi illustrati all'inizio di questa sezione.
Queste modifiche sono state inizialmente applicate a SUSE Linux 9.1.
All'avvio cupsd passa da root utente a lp utente. In questo modo viene garantito un livello di sicurezza nettamente più elevato poiché il servizio di stampa CUPS non viene eseguito con autorizzazioni illimitate, ma solo con le autorizzazioni necessarie per il servizio di stampa.
L'autenticazione (controllo della password), tuttavia, non può essere eseguito tramite /etc/shadow poiché lp non ha accesso a /etc/shadow. È necessario quindi utilizzare l'autenticazione specifica per CUPS tramite /etc/cups/passwd.md5. A questo scopo è necessario immettere un amministratore CUPS con il gruppo di amministrazione CUPS sys e una password CUPS in /etc/cups/passwd.md5. Per eseguire questa operazione, immettere quanto segue come root:
lppasswd -g sys -a CUPS-admin-name
Questa impostazione è essenziale anche se si desidera utilizzare il front-end Web di amministrazione (CUPS) o lo strumento di amministrazione della stampante (KDE).
Quando cupsd viene eseguito come lp, /etc/printcap non può essere generato poiché lp non è autorizzato a creare file in /etc/. Pertanto cupsd genera /etc/cups/printcap. Per garantire che le applicazioni che possono leggere i nomi delle code solo da /etc/printcap continuino a funzionare correttamente, /etc/printcap è un collegamento simbolico che punta a /etc/cups/printcap.
Quando cupsd viene eseguito come lp, la porta 631 non può essere aperta. Non è quindi possibile ricaricare cupsd mediante rccups reload, ma è necessario utilizzare rccups restart.
Le autorizzazioni di accesso impostate per BrowseAllow e BrowseDeny si applicano a tutti i tipi di pacchetti inviati a cupsd. Di seguito sono riportate le impostazioni di default in /etc/cups/cupsd.conf:
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 questo modo solo gli host LOCAL possono accedere a cupsd in un server CUPS. Con LOCAL vengono indicati gli host con indirizzi IP che appartengono a un'interfaccia non PPP (interfacce i cui flag IFF_POINTOPOINT non sono impostati) e con indirizzi IP che appartengono alla stessa rete del server CUPS. I pacchetti di tutti gli altri host vengono respinti immediatamente.
In un'installazione standard, cupsd viene attivato automaticamente in modo da consentire l'accesso agevole alle code dei server di rete CUPS senza azioni manuali aggiuntive. Le voci in Sezione 31.6.2.1, «Esecuzione di cupsd come lp utente» e Sezione 31.6.2.2, «Funzionalità generalizzate per BrowseAllow e BrowseDeny» sono condizioni essenziali per questa funzionalità poiché senza di esse la sicurezza non sarebbe sufficiente per l'attivazione automatica di cupsd.
Nella configurazione della stampante YaST vengono impostate le code per CUPS mediante i soli file PPD installati in /usr/share/cups/model/ nel sistema. Per trovare i file PPD appropriati al modello della stampante in uso, in YaST vengono confrontati il fornitore e il modello determinati durante il rilevamento dell'hardware con i fornitori e i modelli in tutti i file PPD disponibili in /usr/share/cups/model/ nel sistema. A questo scopo la configurazione della stampante YaST genera un database sulla base delle informazioni del fornitore e del modello estratte dai file PPD. Quando si seleziona una stampante dall'elenco di fornitori e modelli, si ricevono i file PPD corrispondenti a tale fornitore e modello.
La configurazione mediante i soli file PPD, senza altre fonti di informazione, ha il vantaggio che i file PPD in /usr/share/cups/model/ possono essere modificati liberamente. La configurazione della stampante YaST è in grado di riconoscere le modifiche e rigenerare il database del fornitore e del modello. Se, ad esempio, si utilizzano solo stampanti PostScript, in genere i file PPD Foomatic del pacchetto cups-drivers o i file PPD Gimp-Print nel pacchetto cups-drivers-stp non sono necessari. Diversamente, i file PPD per le stampanti PostScript possono essere copiati direttamente in /usr/share/cups/model/, se non esistono già nel pacchetto manufacturer-PPDs, per ottenere una configurazione ottimale per le stampanti in uso.
I file PPD generici nel pacchetto cups sono stati integrati con file PPD Foomatic adattati per le stampanti PostScript di livello 1 e 2:
/usr/share/cups/model/Postscript-level1.ppd.gz
/usr/share/cups/model/Postscript-level2.ppd.gz
Il filtro della stampante Foomatic foomatic-rip è in genere utilizzato insieme a Ghostscript per le stampanti non PostScript. I file PPD Foomatic validi contengono le voci *NickName: ... Foomatic/Ghostscript driver e *cupsFilter: ... foomatic-rip. Questi file PPD sono inclusi nel pacchetto cups-drivers.
In YaST viene scelto un file PPD Foomatic se un file di questo tipo con la voce *NickName: ... Foomatic ... (recommended) corrisponde al modello della stampante e il pacchetto manufacturer-PPDs non contiene un file PPD più appropriato.
Al posto di foomatic-rip, è possibile utilizzare il filtro CUPS rastertoprinter di Gimp-Print per numerose stampanti non PostScript. Questo filtro e i file PPD Gimp-Print appropriati sono disponibili nel pacchetto cups-drivers-stp. I file PPD Gimp-Print si trovano in /usr/share/cups/model/stp/ e contengono voci *NickName: ... CUPS+Gimp-Print e *cupsFilter: ... rastertoprinter.
Il pacchetto manufacturer-PPDs contiene file PPD dei produttori di stampanti concessi con licenza libera. È consigliabile configurare le stampanti PostScript con il file PPD appropriato del produttore della stampante, poiché tale file consente l'utilizzo di tutte le funzioni della stampante PostScript. In YaST viene selezionato un file PPD del pacchetto manufacturer-PPDs se si riscontrano le seguenti condizioni:
Il fornitore e il modello determinati durante il rilevamento dell'hardware corrispondono al fornitore e al modello indicati in un file PPD del pacchetto manufacturer-PPDs.
Il file PPD del pacchetto manufacturer-PPDs è l'unico file PPD valido per il modello della stampante o esiste anche un file PPD Foomatic con una voce *NickName: ... Foomatic/Postscript (recommended) che corrisponde al modello della stampante.
Di conseguenza, in YaST non viene utilizzato alcun file PPD del pacchetto manufacturer-PPDs nei seguenti casi:
Il file PPD del pacchetto manufacturer-PPDs non corrisponde al fornitore e al modello. Ciò può accadere se il pacchetto manufacturer-PPDs contiene solo un file PPD per modelli simili, ad esempio se non sono disponibili file PPD diversi per i singoli modelli di una serie, mentre il nome del modello è specificato nel formato Funprinter 1000 series nel file PPD.
Il file PPD PostScript Foomatic non è consigliato poiché il modello della stampante potrebbe non funzionare correttamente in modalità PostScript, ad esempio la stampante può risultare inaffidabile in questa modalità poiché non dispone di memoria sufficiente o è troppo lenta perché le capacità del processore non sono adeguate. La stampante, inoltre, potrebbe non supportare la modalità PostScript per default, ad esempio se il supporto PostScript è disponibile solo come modulo facoltativo.
Se un file PPD del pacchetto manufacturer-PPDs è adatto a una stampante PostScript ma in YaST non è possibile configurarlo per i motivi indicati, selezionare manualmente il modello della stampante corrispondente in YaST.
