Kapitel 12. Druckerbetrieb / 12.7. Besonderheiten bei SUSE LINUX | ||||
|---|---|---|---|---|
 | 12.6. Konfiguration für Anwendungsprogramme | 12.8. Mögliche Probleme und deren Lösung |  | |
Kapitel 12. Druckerbetrieb / 12.7. Besonderheiten bei SUSE LINUX | ||||
|---|---|---|---|---|
| 12.6. Konfiguration für Anwendungsprogramme | 12.8. Mögliche Probleme und deren Lösung | | |
CUPS wurde zum Betrieb unter SUSE LINUX an einigen Stellen angepasst. Zum Verständnis der Integration sollen hier einige der wichtigen Änderungen angesprochen werden.
Es gibt zahlreiche Wege, CUPS als Client eines Netzwerkservers einzurichten.
Man kann für jede Warteschlange auf dem Netzwerkserver eine lokale Warteschlange anlegen und über diese dann alle Aufträge an die entsprechenden auf dem Netzwerkserver versenden. Dieser Weg wird in der Regel nicht empfohlen, denn wenn sich die Konfiguration des Netzwerkservers ändert, müssen auch alle Client-Maschinen neu konfiguriert werden.
Man kann Druckaufträge direkt an genau einen Netzwerkserver weiterleiten. Für eine solche Konfiguration ist es nicht erforderlich, einen lokalen CUPS-Daemon laufen zu haben; lp oder entsprechende Bibliotheksaufrufe durch andere Programme können Aufträge direkt an den Netzwerkserver senden. Eine solche Konfiguration funktioniert jedoch nicht, wenn man auch auf einem lokal angeschlossenen Drucker drucken möchte.
Der CUPS-Daemon kann auf solche IPP-Broadcast-Pakete lauschen, die von anderen Netzwerkservern gesendet werden, um zur Verfügung stehende Warteschlangen anzuzeigen. Dies ist die beste CUPS-Konfiguration, wenn man über entfernte CUPS-Server drucken möchte. Bei einer solchen Konfiguration besteht jedoch die Gefahr, dass ein Angreifer dem Daemon IPP-Broadcasts mit Warteschlangen unterschiebt und dass dann auf diese untergeschobenen Warteschlangen von von dem lokalen Daemon zugegriffen wird (und wenn dieser dann die Warteschlange mit demselben Namen als eine andere Warteschlange des lokalen Servers anzeigt und wenn das IPP-Paket früher empfangen wird, dann kann der Benutzer des Auftrags glauben, der Auftrag würde zu einem lokalen Server geschickt — in Wirklichkeit landet der Auftrag jedoch auf dem Server des Angreifers). Wenn man diese Methode verwenden will, muss der Port 631/UDP für hereinkommende Pakete offen sein.
YaST kann CUPS-Server finden, indem es alle Rechner eines Netzwerks abfragt, um zu prüfen ob sie diesen Dienst anbieten, oder indem es auf IPP-Broadcasts lauscht. Die zweite Methode wird auch während der Installation verwendet, um CUPS-Server für den Vorschlag zu finden. Die zweite Methode erfordert, dass der Port 631/UDP für hereinkommende Pakete offen ist.
Zur Firewall ist nun noch folgendes zu sagen: Die Vorgabeeinstellung
der Firewall (gemäß Vorschlags-Dialog) ist es, keine
IPP-Broadcasts auf einer Schnittstelle zu erlauben. Das bedeutet, dass die
zweite Methode zum Finden und das Erreichen der entfernten Warteschlangen
gemäß Methode 3 nicht funktionieren kann. Es ist also erforderlich, die
Firewall-Konfiguration zu ändern: entweder muss man eine der Schnittstellen
als internal markieren, wodurch der Port standardmäßig
geöffnet wird, oder den Port einer nach draußen gehenden Schnittstelle
(external) gezielt öffnen; denn aus Sicherheitsgründen
kann keines von den Vorgabeeinstellungen her offen sein. Auch das Öffnen
zum Auffinden entfernter Warteschlangen gemäß der zweiten
Methode ist ein Sicherheitsrisiko, da die Benutzer den
Server eines Angreifers akzeptieren könnten.
Der Benutzer muss also die vorgeschlagene Firewall-Konfiguration ändern, um CUPS das Finden der entfernten Warteschlangen während der Installation zu erlauben und um später im Normalbetrieb die verschiedenen entfernten Server vom lokalen System aus zu erreichen. Alternativ kann der Benutzer CUPS-Server finden, indem er aktiv die Rechner des lokalen Netzwerks scannt oder alle Warteschlangen von Hand konfiguriert. Aus den oben genannten Gründen ist diese Alternative jedoch nicht empfehlenswert.
Um die Administration mit dem Web-Frontend (CUPS) oder dem
Drucker-Administrationstool (KDE) nutzen zu können, muss der Benutzer
root als CUPS-Administrator mit
der CUPS-Administrationsgruppe sys und einem CUPS-Passwort angelegt
werden; dies erreicht man als root mit folgendem Befehl:
lppasswd -g sys -a root
Andernfalls ist die Administration via
Web-Interface oder via Administrationstool nicht möglich, denn die
Authentisierung schlägt fehl, wenn kein CUPS-Administrator eingerichtet
ist. Anstelle von root kann auch
ein anderer Benutzer als CUPS-Administrator bestimmt werden
(vgl. Abschnitt 12.7.3, „Änderungen beim CUPS-Druckdienst (cupsd)“).
Diese Änderungen wurden ursprünglich in SUSE LINUX 9.1 implementiert.
Der cupsd wechselt nach dem Start vom Benutzer
root zum Benutzer lp. Dadurch erhöht sich die Sicherheit,
weil der CUPS-Druckdienst nicht mit unbeschränkten Rechten läuft, sondern
nur mit solchen Rechten, die für den Druckdienst notwendig sind.
Ein Nachteil ist jedoch, dass die Authentifizierung (die
Passwortprüfung) nicht mittels /etc/shadow erfolgen
kann, denn lp hat auf
/etc/shadow keinen Zugriff. Stattdessen muss die
CUPS-spezifische Authentisierung via
/etc/cups/passwd.md5 verwendet werden. Dazu muss ein
CUPS-Administrator mit der CUPS-Administrationsgruppe sys und einem CUPS-Passwort in
/etc/cups/passwd.md5 eingetragen werden; als
Benutzer root ist einzugeben:
lppasswd -g sys -a CUPS-admin-name
Wenn der cupsd als lp läuft, kann
/etc/printcap nicht erzeugt werden, denn lp darf in /etc/ keine Dateien anlegen.
Deswegen legt cupsd
/etc/cups/printcap an. Damit Anwendungsprogramme, die
die Warteschlangennamen nur aus /etc/printcap lesen
können, weiterhin korrekt funktionieren ist
/etc/printcap ein symbolischer Link auf
/etc/cups/printcap.
Sobald der cupsd als lp läuft, kann der Port 631 nicht geöffnet
werden. Deswegen kann der cupsd nicht mehr mit
rccups reload neu geladen werden. Stattdessen sollte
rccups restart verwendet werden.
Die bei BrowseAllow und BrowseDeny
gesetzten Zugriffsbedingungen beziehen sich auf alle Arten von Paketen,
die an den cupsd geschickt werden. Die
Voreinstellungen in /etc/cups/cupsd.conf sind:
BrowseAllow @LOCAL BrowseDeny All
und
<Location /> Order Deny,Allow Deny From All Allow From 127.0.0.1 Allow From 127.0.0.2 Allow From @LOCAL </Location>
Damit können genau die LOCAL-Rechner auf den
cupsd auf einem CUPS-Server zugreifen.
LOCAL-Rechner sind solche, deren IP-Adresse zu einer
nicht-point-to-point-Schnittstelle gehört (Schnittstellen, deren
IFF_POINTOPOINT Flag nicht gesetzt ist) und deren
IP-Adresse zum gleichen Netzwerk wie der CUPS-Server gehört. Von allen
anderen Rechnern werden jegliche Pakete sofort zurückgewiesen.
Bei einer Standardinstallation wird der cupsd
automatisch aktiviert. Das ermöglicht ohne zusätzliche manuelle Aktionen
den komfortablen Zugriff auf Warteschlangen von CUPS-Netzwerk-Servern. Die
beiden obigen Punkte (vgl.
Abschnitt 12.7.3.1, „Der cupsd läuft als Benutzer lp“ und Abschnitt 12.7.3.2, „Verallgemeinerte Funktionalität für BrowseAllow und
BrowseDeny“) sind dafür notwendige Bedingungen,
denn andernfalls wäre die Sicherheit nicht hinreichend für eine
automatische Aktivierung des cupsd.
Die YaST-Druckerkonfiguration legt die Warteschlangen für CUPS nur mit
den auf dem jeweiligen System unter
/usr/share/cups/model/ installierten PPD-Dateien an.
Für ein bestimmtes Druckermodell ermittelt YaST die passenden
PPD-Dateien, indem der bei der Hardwareerkennung ermittelte Hersteller- und
Modellname mit den Hersteller- und Modellnamen in allen auf dem jeweiligen
System unter /usr/share/cups/model/ vorhandenen
PPD-Dateien verglichen wird. Die YaST-Druckerkonfiguration baut dazu
eine Datenbank aus den Hersteller- und Modellinformationen auf, die in
den PPD-Dateien stehen. Dadurch können Sie Ihren Drucker über die
Hersteller- und Modellbezeichnung auswählen und erhalten somit die
PPD-Dateien, die zu dieser Hersteller- und Modellbezeichnung passen.
Das Konfigurieren nur mit den PPD-Dateien und ohne sonstige
Informationsquellen hat den Vorteil, dass die PPD-Dateien unter
/usr/share/cups/model/ beliebig geändert werden
können. Die YaST-Druckerkonfiguration erkennt Veränderungen und baut
dann die Hersteller/Modell-Datenbank erneut auf. Wenn Sie beispielsweise
nur PostScript-Drucker haben, dann brauchen Sie normalerweise weder die
Foomatic PPD-Dateien im Paket cups-drivers noch die Gimp-Print
PPD-Dateien im Paket cups-drivers-stp, sondern Sie können die
genau zu Ihren PostScript-Druckern passenden PPD-Dateien nach
/usr/share/cups/model/ kopieren (wenn diese nicht
schon im Paket manufacturer-PPDs
vorhanden sind) und so Ihre Drucker optimal konfigurieren.
Die generischen PPD-Dateien im Paket cups wurden speziell für PostScript Level 2
und Level 1 Drucker um folgende angepasste Foomatic PPD-Dateien ergänzt:
/usr/share/cups/model/Postscript-level1.ppd.gz
/usr/share/cups/model/Postscript-level2.ppd.gz
Für Nicht-PostScript-Drucker wird normalerweise der Foomatic Druckerfilter
foomatic-rip zusammen mit Ghostscript verwendet.
Die dazu passenden Foomatic PPD-Dateien sind durch die Einträge
*NickName: ... Foomatic/Ghostscript-Treiber und
*cupsFilter: ... foomatic-rip gekennzeichnet.
Diese PPD-Dateien befinden sich im Paket
cups-drivers.
YaST verwendet bevorzugt eine Foomatic PPD-Datei,
falls eine Foomatic PPD-Datei durch den Eintrag
*NickName: ... Foomatic ... (recommended)
gekennzeichnet ist und das Paket
manufacturer-PPDs enthält
keine PPD-Datei, die besser geeignet ist (siehe unten).
Für viele Nicht-PostScript-Drucker kann statt
foomatic-rip alternativ auch der CUPS-Filter
rastertoprinter von Gimp-Print verwendet werden.
Dieser Filter und die dazu passenden Gimp-Print PPD-Dateien sind im Paket
cups-drivers-stp. Die Gimp-Print PPD-Dateien
liegen unter /usr/share/cups/model/stp/ und sind
durch die Einträge *NickName: ... CUPS+Gimp-Print
und *cupsFilter: ... rastertoprinter.
Das Paket manufacturer-PPDs
enthält PPD-Dateien von Druckerherstellern, die unter einer hinreichend
freien Lizenz stehen. PostScript-Drucker sollten mit der passenden
PPD-Datei des Druckerherstellers eingerichtet werden, denn die PPD-Datei
des Druckerherstellers ermöglicht es, alle Funktionen des
PostScript-Druckers zu nutzen. YaST verwendet bevorzugt eine PPD-Datei
aus manufacturer-PPDs, wenn
folgende Bedingungen erfüllt sind:
Der bei der Hardwareerkennung ermittelte Hersteller- und Modellname
stimmt mit dem Hersteller- und Modellnamen in einer PPD-Datei aus dem
Paket manufacturer-PPDs überein.
Entweder ist die PPD-Datei aus dem Paket
manufacturer-PPDs die einzige zu dem
Druckermodell passende PPD-Datei, oder es passt auch eine Foomatic
PPD-Datei mit folgendem Eintrag zu dem Druckermodell:
*NickName: ... Foomatic/Postscript
(recommended).
YaST verwendet also in den folgenden Fällen keine PPD-Datei aus dem
Paket manufacturer-PPDs:
Die PPD-Datei aus dem Paket manufacturer-PPDs passt hinsichtlich
Hersteller- und Modellname nicht. Das kann insbesondere dann passieren,
wenn es für ähnliche Modelle nur eine PPD-Datei im Paket manufacturer-PPDs gibt (z. B. wenn bei
einer Serie von Modellen nicht für jedes einzelne Modell eine eigene
PPD-Datei existiert, sondern als Modellname etwas in der Art wie
"Funprinter 1000 series" in der PPD-Datei steht).
Die Foomatic Postscript PPD-Datei ist aus folgenden Gründen nicht „recommended“: Das Druckermodell arbeitet nicht gut genug im PostScript-Modus (z. B. unzuverlässig weil der Drucker standardmäßig zu wenig Speicher hat oder zu langsam weil der Prozessor im Drucker zu leistungsschwach ist) oder der Drucker unterstützt PostScript nicht standardmäßig (z. B. weil die PostScript-Unterstützung nur als optionales Modul verfügbar ist).
Wenn für einen PostScript Drucker eine PPD-Datei aus
manufacturer-PPDs geeignet ist, aber YaST aus
obigen Gründen diese nicht einrichten kann, muss das passende
Druckermodell manuell ausgewählt werden.
