| SUSE LINUX – Administrationshandbuch Kapitel 5. Druckerbetrieb / 5.9. Drucken im TCP/IP-Netzwerk | ||||
|---|---|---|---|---|
 | 5.8. Kommandozeilentools für das CUPS-Drucksystem | Kapitel 6. Weiterführende Hinweise zum Druckerbetrieb |  | |
| SUSE LINUX – Administrationshandbuch Kapitel 5. Druckerbetrieb / 5.9. Drucken im TCP/IP-Netzwerk | ||||
|---|---|---|---|---|
| 5.8. Kommandozeilentools für das CUPS-Drucksystem | Kapitel 6. Weiterführende Hinweise zum Druckerbetrieb | | |
Für den LPRng Druckerspooler finden sich ausführliche Informationen im LPRng-Howto unter file:/usr/share/doc/packages/lprng/LPRng-HOWTO.html Für CUPS siehe das CUPS Software Administrators Manual unter file:/usr/share/doc/packages/cups/sam.html
Als Print-Server wird hier nur ein vollständiger Rechner mit genügend Rechenleistung und Speicherkapazität bezeichnet.
Bei einer Printserver-Box handelt es sich um ein kleines Gerät mit TCP/IP-Netzwerkanschluss und lokaler Anschlussmöglichkeit für einen Drucker. Es gibt auch Router-Boxen, die über eine lokale Anschlussmöglichkeit für einen Drucker verfügen und wie eine Printserver-Box zu behandeln sind.
Ein Netzwerkdrucker hat einen eigenen TCP/IP-Netzwerkanschluss. Das ist letztlich ein Drucker mit eingebauter Printserver-Box. Netzwerkdrucker und Printserver-Boxen sind also gleich zu behandeln.
Es besteht ein erheblicher Unterschied zwischen einem Netzwerkdrucker bzw. einer Printserver-Box und einem echten Print-Server. Es gibt auch große Drucker, bei denen zum Drucken im Netzwerk ein kompletter Rechner als Print-Server mitgeliefert wird. Aber hier wird beim Drucken nicht der eigentliche Drucker, sondern nur der mitgelieferte Print-Server angesprochen.
Ein LPD-Server ist ein Print-Server, der über das LPD-Protokoll ansprechbar ist. Das ist der Fall, wenn auf dem Print-Server das LPRng/lpdfilter Drucksystem (genaugenommen der lpd) läuft oder wenn das CUPS Drucksystem läuft und dieses so konfiguriert wurde, dass der Rechner auch über das LPD-Protokoll ansprechbar ist (genaugenommen über den cups-lpd).
Ein IPP-Server bzw. CUPS-Server ist ein Print-Server, der über das IPP-Protokoll ansprechbar ist. Das ist der Fall, wenn auf dem Print-Server das CUPS Drucksystem (genaugenommen der cupsd) läuft.
Als CUPS-Netzwerk-Server wird hier ein CUPS-Server bezeichnet, der speziell so konfiguriert wurde, dass er seine Warteschlangen per UDP-Broadcast (via UDP-Port 631) anderen Rechnern im Netzwerk mitteilt.
Ein Client-Rechner im Netzwerk verfügt normalerweise über keinen lokal angeschlossenen Drucker, Ausdrucke werden vom Client-Rechner an einen Print-Server geschickt. Wenn Sie einen Print-Server haben und am Client-Rechner ist zusätzlich ein Drucker lokal angeschlossen, dann machen Sie neben der Client-Konfiguration auch die Konfiguration für einen lokal angeschlossenen Drucker. Sie sollten das Drucksystem auf dem Client-Rechner passend zum Drucksystem auf dem Print-Server wählen.
Wenn es im Netzwerk keinen CUPS-Netzwerk-Server gibt, sondern nur einen LPD-Server, dann sollten Sie auf dem Client-Rechner das LPRng/lpdfilter Drucksystem verwenden. Eine weitere Konfiguration des Client-Rechners ist dann nicht erforderlich, denn beim LPRng-Spooler können direkt mit dem lpr-Befehl auch entfernte Warteschlangen angesprochen werden.
Voraussetzung ist, dass der LPD-Server so konfiguriert wurde, dass der Client-Rechner auf dessen Warteschlangen drucken darf. Zum Druck aus Anwendungsprogrammen ist im Anwendungsprogramm als Druckbefehl lpr -Pwarteschlange@print-server einzutragen.
Manche Anwendungsprogramme sind auf CUPS voreingestellt und müssen für LPRng umgestellt werden. Insbesondere KDE und das KDE-Druckprogramm kprinter sind auf umzustellen, weil sonst obiger Druckbefehl nicht eingegeben werden kann.
Wenn der Print-Server ein CUPS-Netzwerk-Server ist, dann können Sie mit der YaST2-Druckerkonfiguration auf und dann klicken und zwischen folgenden Möglichkeiten wählen:
Wenn kein Drucker lokal angeschlossenen ist, wurde keine lokale Warteschlange mit YaST2 konfiguriert. In diesem Fall wird der cupsd nicht automatisch gestartet. Damit der cupsd gestartet wird, ist der Dienst zu aktivieren (normalerweise für die Runlevel 3 und 5).
Eine weitere Konfiguration auf dem Client-Rechner ist nicht notwendig, denn ein CUPS-Netzwerk-Server teilt in regelmäßigen Abständen per Broadcast allen Rechnern im Netzwerk seine Warteschlangen mit, so dass nach kurzer Wartezeit auf dem Client-Rechner die Warteschlangen des CUPS-Netzwerk-Servers automatisch zur Verfügung stehen.
Voraussetzung ist, dass der CUPS-Netzwerk-Server so konfiguriert ist, dass die Broadcast-Funktion eingeschaltet ist und eine zum Client-Rechner passende Broadcast-Adresse verwendet wird und dass der Client-Rechner berechtigt ist, auf den Warteschlangen des CUPS-Netzwerk-Servers zu drucken.
Wenn man nur über die Warteschlangen des CUPS-Netzwerk-Servers drucken möchte, genügt es, wenn CUPS ausschließlich als Client läuft. Dazu ist bei der YaST2 Client-only Druckerkonfiguration nur der Name des CUPS-Netzwerk-Servers anzugeben.
Hierbei läuft auf dem Client-Rechner kein cupsd und deswegen gibt es keine Datei /etc/printcap. Anwendungsprogramme, die nicht auf die Verwendung von CUPS umgestellt werden können, bieten aber nur die Warteschlangen an, die in der lokalen /etc/printcap stehen. In diesem Fall ist es besser, wenn CUPS als Server läuft, denn der dann lokal laufende cupsd legt automatisch eine /etc/printcap mit den Namen der Warteschlangen des CUPS-Netzwerk-Servers an.
Es gibt die verschiedene Möglichkeiten, in einem TCP/IP Netzwerk zu drucken, die sich weniger nach der verwendeten Hardware, sondern nach dem jeweils verwendeten Protokoll unterscheiden. Daher wird auch bei der YaST2-Druckerkonfiguration nicht nach der Hardware, sondern nach dem Protokoll unterschieden.
Dennoch wird in der YaST2-Druckerkonfiguration zuerst ausgewählt, über welche Art "Hardware" der Druck erfolgen soll (z. B. via CUPS-Netzwerk-Server, via LPD-Netzwerk-Server oder Druck direkt auf einem Netzwerkdrucker bzw. einer Printserver-Box). Dementsprechend werden nur die dann möglichen Protokolle angeboten, wobei das Protokoll vorausgewählt ist, welches in den meisten Fällen funktionieren sollte; wenn nur ein Protokoll möglich ist, gibt es keine Auswahl. Beispiele:
Druck via CUPS-Netzwerk-Server
IPP-Protokoll (einzige Möglichkeit)
Druck via LPD-Netzwerk-Server
LPD-Protokoll (einzige Möglichkeit)
Druck direkt auf einem Netzwerkdrucker bzw. einer Printserver-Box:
TCP-Socket
LPD-Protokoll
IPP-Protokoll
Damit Daten vom Sender zum Empfänger gemäß dem jeweiligen Protokoll übertragen werden können, müssen Sender und Empfänger das jeweilige Protokoll unterstützen. Die Software, die auf dem Sender und Empfänger läuft, muss das jeweilige Protokoll unterstützen.
Letztlich ist es egal, welche Hardware und welche Software verwendet wird, es kommt nur darauf an, dass sowohl Sender als auch Empfänger das jeweilige Protokoll unterstützen. Je nach Protokoll werden Druckaufträge oder nur rohe Daten übertragen.
Ein Druckauftrag enthält neben den zu druckenden Daten noch Zusatzinformationen — etwa von welchem Benutzer auf welchem Rechner der Druckauftrag erzeugt wurde und gegebenenfalls welche speziellen Druckoptionen gewünscht sind (z. B. welche Papiergröße beim Ausdruck verwendet werden soll und/oder ob der Ausdruck im Duplex-Modus erfolgen soll usw.).
Hierbei wird vom Sender ein Druckauftrag via LPD-Protokoll an eine Warteschlange auf dem Empfänger geschickt. Gemäss LPD-Protokoll nimmt der Empfänger die Druckaufträge am Port 515 an. Es wird also auf dem Empfänger-Rechner immer ein Dienst benötigt, der die Druckaufträge am Port 515 annimmt (normalerweise heißt ein solcher Dienst lpd) und es wird außerdem immer eine Warteschlange benötigt, in die angenommene Druckaufträge abgelegt werden können.
LPRng unterstützt das Senden via LPD-Protokoll über den lpd. Es wird auch eine Warteschlange auf dem Sender-Rechner benötigt, aus der der lpd des Senders den Druckauftrag nimmt und an den lpd des Empfängers weiterleitet.
Bei LPRng geht das Senden via LPD-Protokoll auch ohne lokalen lpd. Das lpr-Programm aus dem lprng Paket kann den Druckauftrag via LPD-Protokoll direkt an den lpd des Empfängers weiterleiten.
CUPS unterstützt das Senden via LPD-Protokoll über den CUPS-Daemon (cupsd). Es wird eine Warteschlange auf dem Sender-Rechner benötigt, aus der der cupsd den Druckauftrag nimmt und an den lpd des Empfängers weiterleitet.
Das Senden via LPD-Protokoll wird beim CUPS-Client-Drucksystem nicht unterstützt.
Das LPD-Protokoll ist uralt, so dass jedes Betriebssystem dieses Protokoll zumindest als Sender unterstützen sollte. Eventuell ist die Unterstützung nicht standardmäßig vorhanden, so dass geeignete Software nachzuinstallieren ist.
LPRng unterstützt das Empfangen via LPD-Protokoll über den lpd.
CUPS unterstützt das Empfangen via LPD-Protokoll über den cups-lpd. Der cups-lpd ist via inetd bzw. xinetd zu aktivieren.
Das Empfangen via LPD-Protokoll ist beim CUPS-Client-Drucksystem nicht unterstützt.
Das LPD Protokoll ist uralt, so dass jeder normale Print-Server und jede normale Printserver-Box bzw. jeder normale Netzwerkdrucker dieses Protokoll unterstützen sollte.
Bei Printserver-Boxen bzw. Netzwerkdruckern ist der Name der Warteschlange von Modell zu Modell verschieden bzw. es gibt mehrere Warteschlangen mit unterschiedlichem Verhalten.
Hierbei wird vom Sender ein Druckauftrag via IPP-Protokoll an eine Warteschlange auf dem Empfänger geschickt. Gemäß IPP-Protokoll nimmt der Empfänger die Druckaufträge am Port 631 an. Es wird also auf dem Empfänger-Rechner immer ein Dienst benötigt, der die Druckaufträge am Port 631 annimmt (bei CUPS heisst dieser Dienst cupsd) und es wird außerdem immer eine Warteschlange benötigt, in die angenommene Druckaufträge abgelegt werden können.
LPRng unterstützt das IPP Protokoll nicht.
CUPS unterstützt das Senden via IPP Protokoll auch ohne lokalen cupsd. Die Programme lpr oder lp aus dem cups-client Paket oder das Programm xpp oder das KDE-Programm kprinter können den Druckauftrag via IPP Protokoll direkt an den Empfänger weiterleiten.
Das IPP-Protokoll ist relativ neu, so dass die Unterstützung von jeweiligen Fall abhängt.
LPRng unterstützt das IPP Protokoll nicht.
CUPS unterstützt das Empfangen via IPP-Protokoll über den cupsd. Es wird eine Warteschlange auf dem Empfänger-Rechner benötigt, in die der cups-lpd den Druckauftrag, den er vom Sender bekommen hat, ablegen kann.
Das Empfangen via IPP Protokoll ist beim CUPS-Client-Drucksystem nicht unterstützt.
Das IPP Protokoll ist relativ neu, so dass die Unterstützung von jeweiligen Fall abhängt.
Hierbei wird kein Druckauftrag an eine entfernte Warteschlange geschickt, denn es gibt hier kein Protokoll (LPD oder IPP), welches mit Druckaufträgen und Warteschlangen umgehen kann. Stattdessen werden hier rohe Daten direkt via TCP-Socket an einen entfernten TCP-Port geschickt. Üblicherweise wird das verwendet, um druckerspezifische Daten zu Printserver-Boxen und Netzwerkdruckern zu übertragen. In vielen Fällen wird dazu der TCP-Port 9100 verwendet.
LPRng unterstützt das Senden direkt via TCP-Socket über den lpd. Es wird eine Warteschlange auf dem Sender-Rechner benötigt, aus der der lpd des Senders den Druckauftrag nimmt und die zu druckenden Daten an den TCP-Port des Empfängers schickt.
Bei LPRng geht es auch ohne lokalen lpd. Das lpr-Programm aus dem lprng Paket kann bei Verwendung der Option -Y die zu druckenden Daten direkt via TCP-Socket an den TCP-Port des Empfängers schicken. Siehe die man-Page zu lpr.
CUPS unterstützt das Senden direkt via TCP-Socket über den cupsd. Es wird eine Warteschlange auf dem Sender-Rechner benötigt, aus der der cupsd den Druckauftrag nimmt und die zu druckenden Daten an den TCP-Port des Empfängers schickt.
Das Senden direkt via TCP-Socket ist beim CUPS-Client-Drucksystem nicht unterstützt.
Dennoch kann man immer mit etwa folgendem Kommando Daten an einen Port auf einem Rechner schicken:
cat <filename> | netcat -w 1 <host> <port>
Zum Empfangen direkt via TCP-Socket ist kein Drucksystem nötig, und keines der Drucksysteme unterstützt es direkt, denn es ist im allgemeinen nicht sinnvoll, rohe Daten zu schicken, wenn es ein Drucksystem gibt, was richtige Druckaufträge und ein dazu passendes Protokoll (LPD oder IPP) unterstützt.
Dennoch kann man z. B. beim CUPS-Drucksystem auch Daten via Port 9100 Daten annehmen und an eine Warteschlange weiterleiten, indem man in /etc/inetd.conf einträgt:
9100 stream tcp nowait lp /usr/bin/lp lp -d <queue>
Wenn keine Filterung erfolgen soll, ist -o raw anzufügen.
Man kann auch das Verhalten einer Printserver-Box emulieren, die via Port 9100 Daten annimmt und direkt an den Drucker weiterleitet, indem man in /etc/inetd.conf eine Zeile der Art einträgt:
9100 stream tcp nowait lp /bin/dd dd of=/dev/lp0
Die Unterstützung hängt vom jeweiligen Fall ab.
Insbesondere welcher Port der richtige ist, ist von Modell zu Modell verschieden. Bei HP Netzwerkdruckern bzw. bei HP JetDirect Printserver-Boxen ist das standardmäßig der Port 9100 bzw. bei JetDirect Printserver-Boxen mit zwei oder drei lokalen Druckeranschlüssen die Ports 9100, 9101 und 9102. Diese Ports werden auch von vielen anderen Printserver-Boxen verwendet. Konsultieren Sie das Handbuch der Printserver-Box und fragen Sie im Zweifelsfall den Hersteller der Printserver-Box bzw. des Netzwerkdruckers, unter welchem Port der Drucker direkt angesprochen werden kann. Informationen dazu finden sich im LPRng-Howto unter file:///usr/share/doc/packages/lprng/LPRng-HOWTO.html und dort insbesondere unter file:///usr/share/doc/packages/lprng/LPRng-HOWTO.html#SECNETWORK, file:///usr/share/doc/packages/lprng/LPRng-HOWTO.html#SOCKETAPI und file:///usr/share/doc/packages/lprng/LPRng-HOWTO.html#AEN4858
Mehrere Workstations, ein Print-Server und ein oder mehrere Printserver-Boxen bzw. Netzwerkdrucker:
Die Workstations sollten auch das LPRng-Drucksystem verwenden.
Für jeden an einer Printserver-Box angeschlossenen Drucker bzw. für jeden Netzwerkdrucker gibt es auf dem Print-Server eine eigene Warteschlange.
Die Workstations übertragen die Druckaufträge via LPD Protokoll in die zum Drucker gehörende Warteschlange auf dem Print-Server.
Je nachdem, welche Printserver-Box bzw. welcher Netzwerkdrucker welches Protokoll unterstützt, verwendet der Print-Server das LPD Protokoll oder die direkt Datenübertragung via TCP-Socket, um die zu druckenden Daten an die Printserver-Box bzw. den Netzwerkdrucker zu schicken.
Die Workstations sollten auch das CUPS-Drucksystem verwenden. Das CUPS-Client-Drucksystem ist in diesem Fall völlig ausreichend.
Für jeden an einer Printserver-Box angeschlossenen Drucker bzw. für jeden Netzwerkdrucker gibt es auf dem Print-Server eine eigene Warteschlange.
Die Workstations übertragen die Druckaufträge via IPP Protokoll in die zum Drucker gehörende Warteschlange auf dem Print-Server.
Je nachdem, welche Printserver-Box bzw. welcher Netzwerkdrucker welches Protokoll unterstützt, verwendet der Print-Server das LPD Protokoll oder die direkt Datenübertragung via TCP-Socket, um die zu druckenden Daten an die Printserver-Box bzw. den Netzwerkdrucker zu schicken.
Einige wenige Workstations, kein Print-Server und ein oder mehrere Printserver-Boxen bzw. Netzwerkdrucker:
Für jeden an einer Printserver-Box angeschlossenen Drucker bzw. für jeden Netzwerkdrucker gibt es auf jeder Workstation eine eigene Warteschlange. Da auf jeder Workstation alle Warteschlangen eingerichtet werden müssen, ist das nur bei wenigen Workstations sinnvoll.
Je nachdem, welche Printserver-Box bzw. welcher Netzwerkdrucker welches Protokoll unterstützt, verwendet die Workstation das LPD Protokoll oder die direkt Datenübertragung via TCP-Socket, um die zu druckenden Daten an die Printserver-Box bzw. den Netzwerkdrucker zu schicken.
Wenn mehrere Workstations gleichzeitig Daten an dieselbe Printserver-Box bzw. an denselben Netzwerkdrucker schicken, kann es zu Datenverlust und allen möglichen anderen Problemen kommen — insbesondere wenn zur Datenübertragung das LPD-Protokoll verwendet wird, denn die Implementierung des LPD-Empfängers in der Printserver-Box bzw. im Netzwerkdrucker ist oft mangelhaft, weil es dort zumeist nicht genug Speicherplatz gibt, um mehrere Druckaufträge annehmen und zwischenspeichern zu können. Erfolgt dagegen die Datenübertragung ausschliesslich via TCP-Socket, so kann das je nach Printserver-Box bzw. Netzwerkdrucker auch sehr zuverlässig funktionieren.
Im vorigen Abschnitt wurde beschrieben, wie Druckaufträge bzw. wie rohe Daten von der Workstation zum Drucker übertragen werden. Etwas ganz anderes ist es, wie die Filterung (also das Umwandeln der ursprünglichen Daten in druckerspezifische Daten) beim Drucken im Netzwerk erfolgen kann. Die Umwandlung in druckerspezifische Daten beim Drucken im Netzwerk erfolgt ganz genau so, wie bei einem lokal an einem Einzelplatzsystem angeschlossenen Drucker. In Hinblick auf den Druckerfilter gibt es überhaupt keinen Unterschied zwischen Netzwerkdruck und Einzelplatzsystem. Lediglich der Datenstrom von der Workstation zum Drucker ist komplizierter und läuft über mehrere Stationen; z. B. folgendermaßen:
Workstation -> Print-Server -> Printserver-Box -> Drucker
An genau einer Stelle dieser Kette muss die Ausgangsdatei in das Format umgewandelt werden, das der Drucker letztlich drucken kann (PostScript, PCL, ESC/P).
Die Umwandlung wird vom Druckerfilter erledigt und dieser kann nur auf einem Rechner mit genügend Rechenleistung und Speicherkapazität laufen, also entweder auf der Workstation, oder auf einem Print-Server, aber weder in einer Printserver-Box noch in einem Netzwerkdrucker. Printserver-Boxen und Netzwerkdrucker haben normalerweise keinen Druckerfilter eingebaut, sie können nur druckerspezifische Daten annehmen und an den Drucker bzw. an das eigentliche Druckwerk weiterleiten.
Eine Warteschlange kann mit Filterung oder ohne angelegt werden. Da in der YaST2-Druckerkonfiguration zuerst ausgewählt wird, über welche Art Hardware der Druck erfolgen soll (z. B. via CUPS-Netzwerk-Server, via LPD-Netzwerk-Server oder Druck direkt auf einem Netzwerkdrucker bzw. einer Printserver-Box), ist die Voreinstellung, ob Filterung erfolgen soll oder nicht, so, dass es normalerweise funktionieren sollte — bei Bedarf ist die Voreinstellung in der YaST2-Druckerkonfiguration passend zu ändern.
Die Voreinstellungen sind:
keine Filterung (da diese normalerweise auf dem CUPS-Netzwerk-Server erfolgt)
keine Filterung (da diese normalerweise auf dem LPD-Netzwerk-Server erfolgt)
Filterung
Wird die Warteschlange mit Filterung angelegt, dann werden in der Warteschlange die ursprünglichen Daten zwischengespeichert. Erst wenn die Daten an den Empfänger gesendet werden, durchlaufen sie dabei auf dem Rechner, auf dem die Warteschlange liegt, den Filter. Dem eigentlichen Senden der Daten wird also der Filter vorgeschaltet, so dass beim Empfänger die umgewandelten Daten ankommen (Abbildung 5.2. “Überblick über den Ablauf beim Filtern”).
Im folgenden werden die Möglichkeiten der Filterung bei den obigen Beispielen aufgezeigt.
Mehrere Workstations, ein Print-Server und ein oder mehrere Printserver-Boxen bzw. Netzwerkdrucker:
Am einfachsten und sinnvollsten ist die folgende Konfiguration in Abbildung 5.3. “Konfiguration 1”.
Man kann für jede Warteschlange mit Filterung auf dem Print-Server eine entsprechend konfigurierte Warteschlange ohne Filterung auf jeder Workstation anlegen, damit bei einem vorübergehenden Ausfall oder bei Überlast des Print-Servers die Druckaufträge auf den Workstations zwischengespeichert werden können. Dadurch können auf den Workstations jederzeit Ausdrucke erzeugt werden ohne warten zu müssen, bis der Print-Server wieder verfügbar ist. Der Nachteil hierbei ist, dass nun alle Warteschlangen auch auf jeder Workstation zu konfigurieren sind (allerdings ohne die Filterung) und dass bei gewissen Änderungen der Warteschlangen auf dem Print-Server (z.B. Namensänderung oder neu hinzugekommene bzw. gelöschte Warteschlangen, aber nicht bei Änderungen der Filterung) die Konfigurationen auf allen Workstations anzupassen sind.
Diese hochentwickelte Konfiguration sieht dann wie in Abbildung 5.4. “Konfiguration 2” aus.
Theoretisch könnte die Filterung auf jeder Workstation erfolgen und der Print-Server leitet die druckerspezifische Daten nur noch an die Printserver-Boxen bzw. an die Netzwerkdrucker weiter. Aber damit würde der Print-Server zu einer Art grosse Printserver-Box kastriert, was in der Praxis normalerweise keinen Sinn macht, es sei denn, der Print-Server ist so leistungsschwach, dass die Filterung dort zur Überlastung führt. Der Nachteil hierbei ist, dass nun alle Warteschlangen auch auf jeder Workstation zu konfigurieren sind (jeweils mit Filterung) und dass bei jeder Änderung die Konfigurationen auf allen Workstations anzupassen sind.
Diese Konfiguration sieht dann wie in Abbildung 5.5. “Konfiguration 3” aus.
Einige wenige Workstations, kein Print-Server und ein oder mehrere Printserver-Boxen bzw. Netzwerkdrucker:
Die einzig mögliche Konfiguration ist auf jeder Workstation für jeden Drucker eine Warteschlange mit Filterung zu haben. Der Nachteil hierbei ist, dass nun alle Warteschlangen auf jeder Workstation zu konfigurieren sind (jeweils mit Filterung) und dass bei jeder Änderung die Konfigurationen auf allen Workstations anzupassen sind.
Die Konfiguration sieht dann wie in Abbildung 5.6. “Konfiguration 4” aus.
Der vorige Fall sieht schon fast genauso aus, wie die Konfiguration auf einem Einzelplatzsystem mit lokal angeschlossenem Drucker.
Zum Vergleich die Konfiguration in Abbildung 5.7. “Konfiguration 5” für ein Einzelplatzsystem:
Wenn man die obigen Fälle von hier aus nacheinander rückwärts betrachtet, sieht man die Fortentwicklung von der Konfiguration auf einem Einzelplatzsystem mit lokal angeschlossenem Drucker zur hochentwickeltsten bzw. sinnvollsten Konfiguration für mehrere Workstations mit einem Print-Server für mehrere Printserver-Boxen bzw. Netzwerkdrucker.
Das TCP/IP-Netzwerk inklusive Namensauflösung muss ordnungsgemäß funktionieren.
Schließen Sie den Drucker direkt an der ersten parallelen Schnittstelle am Rechner an. Konfigurieren Sie den Drucker nur zum Test als lokalen Drucker, um etwaige Netzprobleme auszuschließen. Wenn der Drucker lokal funktioniert, haben Sie den passenden Ghostscript-Treiber und die anderen Parameter für die Konfiguration des Filters erhalten.
Mit den folgenden Kommando kann man testen, ob überhaupt eine TCP-Verbindung zum lpd (Port 515) auf dem Rechner host möglich ist:
netcat -z <host> 515 && echo ok || echo failed
Wenn keine Verbindung zum lpd möglich ist, dann läuft entweder der lpd nicht, oder grundlegende Netzwerkprobleme sind die Ursache.
Als Benutzer root kann man mit folgendem Kommando einen (ggf. sehr langen) Statusbericht für die Warteschlange queue auf dem (entfernten) Rechner host abfragen, sofern der dortige lpd läuft und Anfragen dorthin geschickt werden können:
echo -e "\004<queue>" \ | netcat -w 2 -p 722 <host> 515
Wenn keine Antwort vom lpd kommt, dann dann läuft entweder der lpd nicht, oder grundlegende Netzwerkprobleme sind die Ursache. Wenn eine Antwort vom lpd kommt, sollte diese klären, warum auf der Warteschlange queue auf dem Rechner host nicht gedruckt werden kann – Beispiele:
Beispiel 5.1. Fehlermeldung von lpd
lpd: your host does not have line printer access lpd: queue does not exist printer: spooling disabled printer: printing disabled
Wenn eine derartige Antwort vom lpd kommt, liegt das Problem beim entfernten lpd.
Mit folgendem Kommando kann man testen, ob es im Netzwerk einen CUPS-Netzwerk-Server gibt, denn dieser sollte über den UDP Port 631 seine Warteschlange standardmäßig alle 30 Sekunden broadcasten:
netcat -u -l -p 631 & PID=$! ; sleep 40 ; kill $PID
Nach 40 Sekunden Wartezeit sollte es eine Ausgabe in der folgenden Art geben, wenn ein CUPS-Netzwerk-Server broadcastet:
Mit folgendem Kommando testet man, ob überhaupt eine TCP-Verbindung zum cupsd (Port 631) auf dem Rechner host möglich ist:
netcat -z <host> 631 && echo ok || echo failed
Wenn keine Verbindung zum cupsd möglich ist, dann läuft entweder der cupsd nicht, oder grundlegende Netzwerkprobleme sind die Ursache.
lpstat -h <host> -l -t
Damit erhält man einen (ggf. sehr langen) Statusbericht für alle Warteschlangen auf dem Rechner host, sofern der dortige cupsd läuft und Anfragen dorthin geschickt werden können.
echo -en "\r" \ | lp -d <queue> -h <host>
Damit kann man testen, ob die Warteschlange queue auf dem Rechner host einen Druckauftrag annimmt, wobei der Druckauftrag hier aus einem einzelnen Carriage-Return-Zeichen besteht — d. h. hierbei wird nur getestet, aber normalerweise sollte nichts gedruckt werden — und wenn, dann nur ein leeres Blatt.
Die grundlegende Funktion kann mit folgendem Befehl getestet werden:
echo -en "\r" \
| smbclient '/<HOST>/<SHARE>' '<PASSWORD>' \
-c 'print -' -N -U '<USER>' \
&& echo ok || echo failed
Für HOST ist der Rechnernamen des Samba-Servers, für SHARE der Namen der entfernten Warteschlange (d. h. der Namen des Samba-Shares), für PASSWORD das Passwort und für USER den Benutzernamen einzusetzen. Hierbei wird nur getestet, aber normalerweise sollte nichts gedruckt werden — und wenn, dann nur ein leeres Blatt.
Mit folgendem Befehl können die frei verfügbaren Shares auf dem Rechner host angezeigt werden — siehe die Manualpage von smbclient:
smbclient -N -L <host>
Es gibt mitunter Probleme mit dem Druckerspooler, der in einer Printserver-Box läuft, sobald ein höheres Druckaufkommen vorliegt. Da es am Druckerspooler in der Printserver-Box liegt, kann man das nicht ändern. Man kann aber den Druckerspooler in der Printserver-Box umgehen, indem man den an der Printserver-Box angeschlossenen Drucker direkt via TCP-Socket anspricht.
Dadurch arbeitet die Printserver-Box nur noch als Umwandler zwischen den verschiedenen Formen der Datenübertragung (TCP/IP-Netzwerk und lokaler Druckeranschluss). Somit verhält sich der an der Printserver-Box angeschlossenen Drucker wie ein lokal angeschlossener Drucker. So bekommt man auch direktere Kontrolle über den Drucker, als wenn der Spooler auf der Printserver-Box zwischengeschaltet wäre. Dazu muss der entsprechende TCP-Port auf der Printserver-Box bekannt sein. Bei angeschlossenem und eingeschaltetem Drucker an der Printserver-Box kann dieser TCP-Port normalerweise einige Zeit nach dem Einschalten der Printserver-Box mit dem Programm nmap aus dem Paket nmap ermittelt werden.
So liefert nmap IP-address bei einer Printserver-Box beispielsweise:
Port State Service 23/tcp open telnet 80/tcp open http 515/tcp open printer 631/tcp open cups 9100/tcp open jetdirect
Diese Ausgabe bedeutet:
Man kann sich via telnet auf der Printserver-Box anmelden. So können dort grundlegende Informationen abfragt und grundlegende Konfigurationen vorgenommen werden.
Via HTTP kann ein in der Printserver-Box laufender Web-Server angesprochen werden. Dieser liefert normalerweise detaillierte Informationen und ermöglicht detaillierte Konfigurationen.
Über den Port 515 ist der in der Printserver-Box laufende Druckerspooler via LPD-Protokoll ansprechbar.
Über den Port 631 ist der in der Printserver-Box laufende Druckerspooler via IPP-Protokoll ansprechbar.
Über den Port 9100 ist der an der Printserver-Box angeschlossene Drucker via TCP-Socket ansprechbar.
Standardmässig prüft nmap nur eine gewisse Liste von allgemein bekannten Ports, die in /usr/share/nmap/nmap-services verzeichnet sind. Um alle möglichen Ports zu überprüfen, verwenden Sie nmap -p from_port-to_port IP-address (das kann dann sehr lange dauern) — vergleichen Sie dazu die Manual-Page man nmap.
Mit Befehlen der Art
echo -en "\rHello\r\f" | netcat -w 1 <IP-address> <port> cat <file> | netcat -w 1 <IP-address> <port>
können Zeichenfolgen oder Dateien direkt an den betreffenden Port geschickt werden, um zu testen, ob der Drucker über diesen Port ansprechbar ist.
Standardmäßig unterstützt ein CUPS-Server nur das IPP-Protokoll. Aber das Programm /usr/lib/cups/daemon/cups-lpd aus dem Paket cups ermöglicht es, dass ein CUPS-Server auch Druckaufträge annehmen kann, die ihm via LPD-Protokoll an den Port 515 geschickt werden. Dazu ist der entsprechende Dienst für den xinetd zu aktivieren — normalerweise mit YaST2 oder manuell, indem die entsprechende Zeile in der Datei /etc/xinetd.d/cups-lpd aktiviert wird.
Es mag der Wunsch bestehen, beide Drucksysteme LPRng/lpdfilter und CUPS auf demselben Rechner laufen zu haben, etwa weil ein bestehender LPD-Print-Server durch CUPS erweitert werden soll, oder weil für gewisse Spezialfälle das LPRng/lpdfilter Drucksystem benötigt wird.
Grundsätzlich gibt es Schwierigkeiten, wenn beide Drucksysteme auf demselben Rechner laufen sollen. Hier werden die Problemstellen und die damit verbundenen Einschränkungen kurz angesprochen. Das Thema ist aber zu komplex, als dass hier eine Lösung beschrieben werden könnte.
Die Druckerkonfiguration sollte nicht mit YaST2 erfolgen, denn die YaST2-Druckerkonfiguration ist für diesen Fall nicht ausgerichtet.
Die Pakete lprng und cups-client stehen in Konflikt miteinander, denn sie enthalten Dateien, die denselben Namen haben z. B. /usr/bin/lpr und /usr/bin/lp. Das Paket cups-client darf daher nicht installiert sein. Die Folge ist, dass keine CUPS-Kommandozeilentools zur Verfügung stehen, sondern nur die für den LPRng. Dennoch kann unter der graphischen Oberfläche mit xpp oder kprinter auf CUPS-Warteschlangen gedruckt werden und auch von allen Anwendungsprogrammen, die CUPS direkt unterstützen.
Standardmäßig legt der cupsd beim Starten die Datei /etc/printcap neu an, die nur die Namen aller CUPS-Warteschlangen enthält. Dies geschieht aus Kompatibilitätsgründen, denn viele Anwendungsprogramme lesen die Warteschlangennamen aus /etc/printcap, um diese im Drucken-Menü anbieten zu können. Das muss für den cupsd abgeschaltet werden, so dass /etc/printcap zur alleinigen Verwendung für das LPRng/lpdfilter Drucksystem dient. Die Folge ist, dass Anwendungsprogramme, die nur die Warteschlangennamen aus /etc/printcap verwenden, auch nur diese lokalen Warteschlangen anzeigen, aber nicht die netzwerkweit verfügbaren CUPS-Warteschlangen.
