Unterabschnitte



10. Systemarchitektur: Theoretische Grundlagen
zu Servern, Clients, und CUPS-Drucken im Netzwerk


10.1 Was versteht man unter Server und Client bei CUPS?

Ein ,,Server`` ist bei CUPS und ESP Print Pro jeder Rechner, der direkt mit einem Drucker kommuniziert (sei es über das Netzwerk, oder über serielle, parallele oder USB-Schnittstellen). Ein Server braucht entsprechende PPDs und Filter, um die Druckdatei druckergerecht aufzubereiten.

Ein Client ist ein Rechner dann, wenn er Druckdateien an einen Server weiterschickt. Ein Client braucht keine Filter oder PPDs installiert zu haben. Wenn auf dem Client festgelegt werden soll, welche Druckerfeatures man beim Drucken (Duplex, Heften...) benutzt, kriegt der Client die PPD vom Server überspielt; CUPS und ESP PrintPro (und auch die anderen grafischen Benutzerschnittstellen) verwenden die ausgelesene Server-PPD dann,

Wird ein Rechner als ,,standalone`` Version von CUPS oder ESP PrintPro konfiguriert, ist er ,,sein eigener Server``, muss also die PPDs und die (ghostscript-)Filter lokal installiert haben.


10.2 Wo wird festgelegt, ob ein CUPS-Rechner Client oder Server ist?

CUPS-Rechner können ihre Rolle jederzeit ändern. Ein Server, der einen Druckjob über einen anderen Server abwickelt, ist in diesem Moment Client.

Der CUPS-Daemon cupsd, auch scheduler genannt, spielt hierbei die zentrale Rolle. Aus der Konfigurationsdatei /etc/cups/cupsd.conf  liest er bei jedem Neustart aus, nach welchen Direktiven er arbeiten soll.


10.3 Was ist ,,Browsing``?

Unter Browsing versteht man die Tatsache, dass die CUPS- und ESP PrintPro-Server ihre installierten Drucker im LAN (d.h. bis zu den Grenzstationen, die von Routern o.ä. gebildet werden) aktiv und von sich aus publizieren, so dass die Clients ,,wissen``, welche Geräte ihnen über welche Server zur Verfügung stehen.

Über die Server-Direktiven Browsing On bzw. Browsing Off kann in der Konfigurationsdatei /etc/cups/cupsd.conf diese Funktion grundsätzlich an- oder ausgeschaltet werden. Seit CUPS 1.1.5 und ESP PrintPro 4.1.5 ist Voreinstellung, dass Browsing ausgeschaltet ist. Das hat zur Folge, dass keine CUPS-Neuinstallation mehr von vorneherein als Server konfiguriert ist

Speziell zu ESP PrintPro: Ohne eine installierte Server-/Multiuser-Lizenz werden keine Broadcast-Packete ausgeschickt. Eine Standalone-/Einzelplatzlizenz erlaubt kein Broadcasting, gleichgültig, was in der Konfigurationsdatei steht...


10.4 Was ist ,,Broadcasting``?

Unter Broadcasting versteht man die Methode, wie die CUPS- und ESP PrintPro-Server ihre installierten Drucker zum Zweck des Client-Browsing publizieren: sie schicken in regelmässigen Abständen (z.B. 30 Sekunden, einstellbar) einen allgemeinen Rundspruch über das Netz, der die Druckernamen, Statusinformationen und einige zugehörige Informationen (z.B. die Kommentare, die der Administrator bei der Installation zu Standort etc. eingegeben hat) enthält.

Pro Drucker sind in jedem Rundspruch maximal 1024 Bytes möglich, in der Praxis sind es im Schnitt ca. 100 Bytes.

Der Rundspruch findet standardmässig über UDP-Protokoll, den Port 631 und über alle konfigurierten Netzwerkkarten statt (d.h. es werden als Broadcastziel alle erreichbaren Rechner, über alle Schnittstellen, verwendet; in der /etc/cups/cupsd.conf ist dies in der Direktive BrowseAdress 255.255.255.255:631 festgelegt).


10.5 Hat das Broadcasting Nachteile oder unerwünschte Auswirkungen?

Bis CUPS-Version 1.1.4 und ESP PrintPro 4.1.4 hat jedes neu installierte CUPS seine Drucker-Bekanntmachungen per Voreinstellung über alle Netzwerkschnittstellen abgesetzt; d.h. es war automatisch Server und jeder CUPS-Rechner im Netz konnte Drucker sofort nach ihrer Installation auf irgendeinem anderen CUPS-Rechner auch für sich selbst nutzen. Eigentlich ein schönes Feature...

In jüngster Vergangenheit hat dies jedoch dazu geführt, dass Linux-Neulinge Schwierigkeiten begegneten, weil das voreingestellte Broadcasting im Zusammenhang mit ISDN-Karten unerwünschte Nebenwirkungen hat: bei Linux-Mandrake 7.2 wunderten sich die Anwender über die ständigen Versuche des Rechners, sich unaufgefordert zum Internet-Provider einzuwählen (er wollte ,,nur`` das CUPS-Broadcast auch über die ISDN-Karte weitergeben...)

Seit CUPS 1.1.5 und ESP PrintPro 4.1.5 ist das Broadcasting in der Anfangskonfiguration abgeschaltet, d.h. die Rechner können nur als Clients oder in ihrer Standalone-Funktion drucken; Wer die Serverfuktionalität eines neu-installierten CUPS-Systems nutzen möchte, muss kurz selbst Hand anlegen: entweder alle entsprechenden Clients auf ,,Polling des Servers`` umstellen oder auf dem Server das Broadcasting in geeigneter Weise aktivieren.

Das Broadcasting kann auch mittels geeignet gewählter Adresse und/oder Netzmaske eingeschränkt werden: nimmt man z.B. 10.160.16.255:631 als Adresse, wird der Rundspruch nur an die entsprechenden Adressen weitergeleitet. Über die Direktive BrowseAddress 10.160.16.45:631 wird die Browsing-Information gar nur an einen einzigen Rechner weitergegeben. BrowseAddress-Direktiven können mehrfach in der Konfigurationsdatei stehen.


10.6 Was ist ,,Polling``?

Sollte aus irgeneinem Grund kein Broadcasting möglich oder erwünscht sein, lässt sich sich der Rechner trotzdem als Server nutzen: die Clients müssen dann umgestellt werden und per ,,Polling`` selbst beim Server nachfragen, welche Drucker er hat. Wenn kein Server broadcastet, kann kein neu installierter Client ,,automatisch`` einen Drucker finden. Dann muss der Client ,,von Hand`` auf Polling umgestellt werden.

Jeder allgemeine Broadcast endet an der Grenze zu einem anderen; Router leiten keine broadcast-Packete weiter. Darum kann mittels broadcasting kein Client einen Server (und dessen Drucker) nutzen, der ,,hinter`` einem Router angesiedelt ist. Hier kann das Polling helfen: bei dieser Einstellung wartet der Client nicht passiv auf Informationen vom Server, sondern fragt diese bei Bedarf selbst ab.

Die Direktive BrowsePoll 10.160.16.40:631 gibt den Server an, bei dem die Druckinformationen abgeholt werden sollen. BrowsePoll-Direktiven können mehrfach angewiesen werden; dann fragt der Client mehrere Server ab.

Mit Polling kann ein Client Druckserver nutzen, die an beliebiger Stelle im Intranet oder im Internet angesiedelt sind. Denn diese Informationen werden gezielt ausgesendet und somit über Router weitergeleitet.


10.7 Was ist ein ,,BrowseRelay``?

Ein Server im lokalen Netz kann angewiesen werden, einen oder mehrere Server in anderen Netzen per Polling nach dort verfügbaren Druckern abzufragen und diese Information an die eigenen Clients (per Broadcast oder per Polling) weiterzureichen. Auf diese Weise ist prinzipiell jeder Drucker im WAN für jeden Client im LAN erreichbar.

Die Konfigurationsdirektive für einen Server, der andere Server ausserhalb des eigenen Subnetzes pollt und diese Informationen im eigenen Subnetz an alle per broadcast erreichbaren Clients weitergibt (in /etc/cups/cupsd.conf) lautet z.B.:

BrowseRelay 127.0.0.1 255.255.255.255


10.8 Muss ein Client jede Information eines broadcastenden Servers annehmen?

Nein.

Über die Direktiven BrowseAllow und BrowseDeny lässt sich einstellen, welche Browse-Packete durch die Clients angenommen werden. Die kombinierten Server-Direktiven BrowseAllow from none und BrowseDeny from all machen CUPS-Recher sogar völlig ,,taub`` gegenüber dem Broadcastverkehr auf dem Netz. Der Rechner druckt dann nur aufgrund von abgefragten Polling-Informationen oder mittels seiner eigenen lokal installierten Drucker.


10.9 Wie konfiguriere ich ,,failover`` / Ausfallsicherheit?

Automagisch: Zwei oder mehr CUPS-Server konfigurieren mit den selben Druckern und Druckernamen. In der /etc/cups/cupsd.conf muss die Direktive ImplicitClasses On vorhanden sein (Default nach Installation). Dann werden auf den CUPS-Servern automatisch implizite Klassen gebildet, die aus den Druckern mit denselben Namen bestehen. Für den Client unbemerkt, übernimmt derjenige Server, der zuerst bereit ist, den Job und schickt ihn an den Drucker.

Manuell: ,,Klassen`` von Druckern bilden, die verschiedene Namen tragen (und auch verschiedenen Ausgabegeräte repräsentieren) können. Dies ist (sowohl bei CUPS als auch bei ESP PrintPro) entweder über die entsprechenden Kommandozeilen-Befehle (siehe man lpadmin) möglich oder über das Web-Interface (http://localhost:631/classes/, dann auf ,,Add classes`` klicken). Bei ESP PrintPro kann zusätzlich über das GUI im ,,Printer Wizard`` der Menüpunkt ,,Add class`` gewählt werden.

In einer Drucker-Klasse können ausser einzelnen Druckern auch anderweitig definierte Klassen Mitglieder sein.

Bei Betrieb von mehreren CUPS-Servern mit geschickt gewählter Konfiguration kann das Druck-System praktisch nicht mehr versagen, da es keinen ,,single point of failure`` mehr gibt.

10.10  Wozu dient die Datei client.conf?

In der Datei /etc/cups/client.conf kann ein ,,default`` Server sowie ein ,,default`` Printer eingetragen werden. Dies kann dazu benutzt werden, einen ,,daemonless`` Client zu konfigurieren. (Normalerweise ist bei CUPS immer localhost der erste Server, der beim Drucken kontaktiert wird. Hat dieser keine Drucker + Treiber installiert, speichert er den Job zwischen und nutzt - jetzt in der Rolle als Client - über Browsing oder Polling verfügbare Drucker auf anderen Servern. Ein daemonless Client kann nur drucken, wenn der default Server sofort verfügbar ist.

Ausser in der systemweit gültigen /etc/cups/client.conf kann diese Einstellung User-bezogen in einer /.clientrc im jeweiligen Homeverzeichnis vorgenommen werden.

 

[fixme]

[to be done]


10.11 Das ,,Filtern`` von PostScript- und anderen Druck-Dateien, d.h. ihre Aufbereitung für einen Nicht-PostScript-Drucker ist doch ein ziemlich rechenaufwändiger Prozess. Wo findet dieser statt, wenn ein CUPS-Client über einen Server druckt: auf dem Client oder auf dem Server?

Standardmässig auf dem Server.

Der Client schickt i.d.R. ,,originale`` PostScript- oder andere Druck-Dateien über das Netz, gespickt mit den Informationen aus der Drucker-PPD (die der Client zuvor vom Server bezogen hat). Der Server übernimmt die komplette Weiterverarbeitung: Spooling, Filterung/RIPpen, Queue-ing. Ein vielbeanspruchter Druckserver sollte deshalb nicht ,,zu schwach auf der Brust sein, wenn er Nicht-PostScript-Drucker beschickt - sonst kann u.U. das RIPpen jeder einzelnen (Farb-)Seite mehrere Minuten in Anspruch nehmen.

Bei Einsatz von PostScript-Druckern ist der Rechenaufwand des Servers erheblich geringer, da das Aufrastern der Daten vom RIP des Druckers übernommen wird.

Man kann die Filterung auch auf die Client-Seite verlegen: dann brauchen die Clients eigene Treiber (=Filter und PPDs) und nutzen den zentralen Server (der dann mittels einer IPP-URI adressiert wird) lediglich als Spool- und Queue-Host...


Kurt Pfeifle, Danka Deutschland GmbH, Feedback und Verbesserungsvorschläge (NOSPAM_ von e-Mail-Adresse entfernen)