Verständnisfrage zum zusammenwirken von Samba und Cups

[TomL]

Moin

Mein kleiner Pi fungiert gleichzeitig als Fileserver und als Printserver. Ich weiss mittlerweile, dass die Clients sich via Samba und entsprechenden Protokoll am Server bedienen. Das ist für mich auch nachvollziehbar

Was ich aber noch nicht verstanden habe, ist das drucken vom Client. Kommuniziert z.b. unter Windows der Spoolerdienst mit Linux-Cups über Sambaprotokolle? Oder geht das direkt ohne Samba ? Oder mein eigener Ubuntu-PC...geht das auch über Samba zum Server?

Treibens auf dem Server die beiden Dienste Samba und Cups munter miteinander ...?....also Cups tuts alleine, wenn lokal gedruckt werden würde, und zusammen mit Samba, wenn vom Netz gedruckt wird?

Mir ist die Logik dessen was da abläuft noch nicht so ganz klar. Ich hoffe, jemand kann ein bisschen aufklären ....

Gruß, Thomas

[TomL]

Moin @ alle

Ich bin ein wenig verunsichert... ich schwanke zwischen 2 Überlegungen.... ist meine frage zu dumm oder zu blöde, um sie zu beantworten? Oder ist sie gar zu schwer für dieses Forum?

Bezüglich "dumm" kann ich was dazu sagen. Ich bin relativ neu bei Linux, etwa 6 Wochen. Ich habe im Moment einige Probleme, die ich allein deshalb nicht lösen kann , weil ich die Zusammenhänge, Wechselwirkungen und möglicherweise gegenseitige Beeinflussung nicht durchblicke.

Wenn also meine frage hier unpassend ist, würde ich mich trotzdem über einen Tipp freuen, wo ich vielleicht alternativ kompetente und hilfsbereite Leute finde.

Gruß Thomas

[NAB]

Du wirfst da einige Sachen zusammen, und man denkt, du erwartest eine komplexe Antwort über mehrere Seiten ... aber vielleicht tust du das ja gar nicht

Lassen wir eventuelle Besonderheiten des Pi mal außen vor, damit kenne ich mich nicht aus.

"CUPS" ist das "Common Unix Printing System" und läuft, wie der Name schon sagt, unter Linux/Unix, nicht aber unter Windows. Es kann aber auch Daten per IPP annehmen, und Windows kann per IPP drucken..

CUPS ist netzwerkfähig, das bedeutet, du kannst problemlos von Rechner A aus drucken, auf einem Drucker, der an Rechner B angeschlossen ist. Ganz ohne Samba. Auf Rechner A darf dabei sogar Windows laufen ... Windows muss den Drucker dann per IPP ansprechen. Dazu braucht Windows einen passenden Treiber ... CUPS reicht die Daten dann einfach an den Drucker durch.

Nun kommt Samba ins Spiel. Samba ist vorrangig eine Dateifreigabe ... und läuft dann vermutlich auf Rechner B, an dem auch der Drucker hängt. Samba kann so praktische Sachen, wie den Windows-Rechner gleich mit den nötigen Druckertreibern zu versorgen. Nun kann man das Drucken auch über Samba abwickeln ... hierbei empfängt Samba (statt CUPS) die Druckerdaten auf Rechner B, und leitet sie lokal an CUPS (auf Rechner B) weiter.

Der Hauptvorteil, das Drucken über Samba abzuwickeln, ist, dass Samba die umfangreiche Rechtevergabe von Windows unterstützt. Das macht in größeren Netzwerken Sinn, wo du administrieren willst, welche Abteilung oder Benutzergruppe auf welchen Drucker zugreifen darf. Für Heimnetze/kleinere Büros druckt man lieber direkt über CUPS und lässt Samba außen vor. Oder man hat gleich einen netzwerkfähigen Drucker. Spannend wird es bei Sachen wie "Druckaufträge abbrechen" oder "Druckkopf reinigen" ... damit kenne ich mich nicht aus, was Samba angeht.

Für die vielen Details verweise ich mal auf die deutsche Anleitung von Ubuntu:
http://wiki.ubuntuusers.de/CUPS
von der ich nicht weiß, ob sie sich 1:1 auf Debian umsetzen lässt.

[TomL]

Du wirfst da einige Sachen zusammen, und man denkt, du erwartest eine komplexe Antwort über mehrere Seiten ... aber vielleicht tust du das ja gar nicht

nein .... bloß nicht ... du hast es genau richtig Interpretiert... mir geht's um das wesentliche....danke für die Erklärung.

Ick wusste wohl , was Samba macht und welche Rolle es zwischen Client und Server hinsichtlich Dateizugriffe spielt. Und mir war klar, was und wofür Cups auf dem Server installiert ist.

Was mir nicht klar war, wenn vom Client (egal ob Windows oder Ubuntu) gedruckt wird, wie dabei der Client mit dem Server-Cups kommuniziert. Und ob es Abhängigkeiten auf dem Server zwischen Samba und Cups gibt. Ja, die gibt es tatsächlich .
Und ich glaube, ich habe das jetzt nach deinen Erläuterungen kapiert. Beide Clients verwenden die Samba-Protokolle zum Drucken auf dem freigegebenen Server-Drucker. Da war mir überhaupt nicht bewusst. Ich hatte die ganze Zeit keinen Zusammenhang von Samba und Drucken gesehen.

Mein grossen Probleme beim einrichten beruhten darauf, dass ich erstens auf dem Ubuntu -Client auch Cups installiert habe. Ich hatte 5 tut's und alle sagten das so. Und zweites musste ich in der smb.conf den spoolpfad eintragen. Und als ich dann den Client -Cups gelöscht hatte, lief es.

Noch mal danke.

Gruß, Thomas

[NAB]

Ich spekuliere dann noch ein wenig, wenn's beliebt

Und ob es Abhängigkeiten auf dem Server zwischen Samba und Cups gibt. Ja, die gibt es tatsächlich .

Also der Server macht ja anscheinend, was er soll. Das tut er mit CUPS und Samba. Und da Samba selber nicht drucken kann, tut Samba das wohl per CUPS. Nur was du über die Clients schreibst, wundert mich etwas ...

Beide Clients verwenden die Samba-Protokolle zum Drucken auf dem freigegebenen Server-Drucker.

Aha? Bei einem Windows-Client klingt das logisch. Wenn der per "Datei und Drucker Freigabe" druckt, dann druckt er per Samba-Protokoll. Andernfalls hättest du einen IPP-Drucker eingestellt und wüsstest das.

Aber bei Ubuntu? Dann müsste Ubuntu einen Schritt zur Windows-Kompatibilitätsebene machen, die Daten würden per SMB-Protokoll an den Server geschickt, und dort müsste Samba sie an CUPS weiterreichen. Das geht ... wenn ich auch nicht genau weiß wie ... die Ubuntu-Anleitung beschränkt sich hier auf ein paar Klicks in der Desktop-Konfiguration und nennt keine Hintergründe:
http://wiki.ubuntuusers.de/Windows_Netzwerkdrucker

So ganz sicher wär ich mir da nicht, ob dein Ubuntu nich doch über CUPS direkt mit dem Server spricht, deiner Beschreibung nach:

Mein grossen Probleme beim einrichten beruhten darauf, dass ich erstens auf dem Ubuntu -Client auch Cups installiert habe. Ich hatte 5 tut's und alle sagten das so. Und zweites musste ich in der smb.conf den spoolpfad eintragen. Und als ich dann den Client -Cups gelöscht hatte, lief es.

Das klingt etwas unglücklich, weil es von CUPS ein "client" und ein "server"-Paket gibt, während dein "Client-Cups" wohl das CUPS auf dem Ubuntu-Client meint. Ich denke, der Client-Teil von CUPS dürfte automatisch installiert werden, im Interesse der Benutzerfreundlichkeit. Da an dem Ubuntu-Rechner aber kein Drucker hängt, wäre es falsch, den Server-Teil zu installieren - damit könntest du in der Tat etwas kaputt machen, egal was die Tutorials sagen.

Also so ganz klar ist mir das nicht, wie der Ubuntu-Rechner nun druckt.

Und bitte - nix ändern! Es funktioniert ja alles, das muss man nicht ändern. Es geht ja nur um die Frage, wie es funktioniert.

[TomL]

Moin

Du hast es erneut genau richtig erkannt und noch mal für einen Lichtblitz bei mir gesorgt.

Ja, der Windows-Client druckt heute ganz normal unter Verwendung seines Spoolerdienstes resp der Druckerwarteschlange. Ich kann den Drucker dort auch ohne Warteschlange einstellen, da gabs dann aber vereinzelt irgendwelche Probleme. Jetzt drucken die Win-Clients über ihren Queue ... und damit über Samba und es funktioniert.

Und der Ubuntu-Client druckt natürlich fehlerfrei über seinen Cups-Client. Das Problem hier war, dass ich zu dem Zeitpunkt nicht wusste, dass es für Cups anscheinend 2 Pakete gibt (Server und Client) und ich habe deshalb gemäß dem ungenauen Tut auf beiden Maschinen den gleichen apt-get install cups durchgeführt und dabei aus Unkenntnis ignoriert, dass der Client auf dem Ubuntu bereits als Systembestandteil installiert war. Das hat eben nicht funktioniert. Aber den Fehler habe ich jetzt auch verstanden.

Danke!

BTW
Im Augenblick habe allerdings ein neues Drucker-Problem-Phänomen .... ein wenig unerklärlich.

Auf unseren Windows-Clients nutzen wir Sumatra als PDF-Viewer. Dieses Programm ist genau so, wie ich mir ein Programm vorstelle. Es macht nur das, was es soll, und das Blitzschnell. Keine zusätzliche Anzeige von Kochrezepten, keine Wetter-News, kein Medienplayer-Müll ....nur blitzschnell PDF anzeigen.
Der Kracher ist. ... es druckt nicht mehr. Der Druck kommt nicht mal in der Warteschlange an....er führt alles normal durch, ohne Fehlermeldungen, die Anzeigen am Bildschirm während des Drucks sind ganz normal ... nur es kommt nix in der Warteschlange an.... und damit natürlich auch nicht beim Cupsserver.

Interessant daran ist, dass das funktionierte, als der Server noch Windows war. Und noch interessanter ist, dass auf diesem Windows-Client alle anderen Programme drucken.

Gruss, Thomas

[NAB]

hmmm ... vorweg: was das Sumatra-Problem angeht, bin ich ratlos.

Hilfreich wäre es, wenn es irgend eine Fehlermeldung gäbe. Schau doch mal in die Windows-Ereignisanzeige, ob du da irgendwas findest, warum das Drucken nicht klappt. Eventuell legt Sumatra auch irgendwo ne log-Datei an.

Es mag auch sein, dass sich das Problem Samba-seitig lösen lässt. Eventuell muss man Samba per Konfigurationsoptionen erst beibringen, dass es bestimmte neuere Features des Windows-Druckdienstes unterstützen soll. Aber da stochere ich im Nebel.

Und letztendlich wäre es einen Versuch wert, Samba komplett zu umgehen, und Windows per IPP drucken zu lassen (siehe Anleitung von Ubuntu).

Aber vielleicht fällt noch jemandem ne zielgenauere Lösung ein

[TomL]

Moin

Und letztendlich wäre es einen Versuch wert, Samba komplett zu umgehen, und Windows per IPP drucken zu lassen (siehe Anleitung von Ubuntu).

Ich habe das Sumatra-Problem gelöst ....und zwar indem ich einen anderen Viewer installiert habe. Ich habe aber ne Vermutung. Sumatra ist wirklich blitzschnell. Möglicherweise bedient sich der Programmierer nicht komplett an den MS-Classes und dem API, sondern geht da irgendwie "direkter" ran.... und verliert da vereinzelt ein wenig die kompatibilität. Nun ja, egal, es läuft ja jetzt.

Aber mit dem Ipp-Drucker ist merkwürdig. Auf meinem Ubuntu-PC steht der auf IPP, obwohl ich 1000% sicher bin, dass ich beim Setup in Cups nicht IPP gewählt habe und der auf DNS-stand. Wieso hat sich das von alleine geändert?

Ebenso ist mir aufgefallen, dass auch LibreOffice und Firefox regelmäßig Customizing-Einstellungen vergessen.

LO vergisst von einem zum nächsten Start die eingetragenen Datenbanken und die Einstellung zur Datensicherheit.

Firefox vergisst das (mein) Downloadverzeichnis und den Datenschutz. Das heißt, "nicht verfolgt werden" und die Einstellungen zum Löschen des Verlauf sind unvorhersehbar nach irgendeiner Anzahl Programmstarts wieder verstellt.

Was sind das für Phänomene? Hat sowas schon mal jemand beobachtet?

vg, Thomas

[TomL]

Nachtrag:

Ich habe gerade mal nachgesehen, der Drucker steht wieder auf ipp://ServerRPI.local:631/printers/Samsung_CLX-3170_Series und remote-printer. Eigentlich habe ich den nicht als IPP ausgewählt und dennoch steht er jetzt so. Ich bin jetzt völlig unsicher, wie das zu interpretieren ist. Eigentlich möchte ich, dass "lokal" gerendert wird, und nicht auf dem langsamen PI, an dem der Drucker angeschlossen ist. Beim Drucken von meinem Ubuntu-PC oder von den Win-Clients soll eigentlich immer jeweils der lokale Druckertreiber verwendet werden und nicht der auf dem Pi vorhandene Treiber.

Bedeutet "remote-printer", dass der Druck vom Client-Treiber erstellt wird, oder das der Druck "raw" gesendet wird und auf dem PI gerendert wird?

vg, Thomas

[NAB]

Also zu deinen sich mysteriöser Weise selbstständig ändernden Einstellungen fällt mir nichts ein, außer "bei Debian ist mir das noch nie passiert". Bei Ubuntu eigentlich auch nicht, aber ich weiß nicht, ob Ubuntu da nicht vielleicht ne merkwürdige Datenwiederherstellungsfunktion hat, die bei dir irgendwie zuschlägt. Gibt es irgendwelche Auffälligkeiten im "dmesg"? Irgendwelche Dateisystem- oder Festplattenprobleme?

Das wäre aber ggf. einen neuen Thread wert - eventuell in einem Ubuntu-Forum.

der Drucker steht wieder auf ipp://ServerRPI.local:631/printers/Samsung_CLX-3170_Series

Wenn er da einigermaßen den richtigen Drucker ausgewählt hat, dann müsste der doch sogar netzwerkfähig sein? Dann könntest du ihn direkt an den Router hängen und hättest einige Probleme weniger (und vielleicht andere neue Probleme, siehe unten)

dass ich beim Setup in Cups nicht IPP gewählt habe und der auf DNS-stand.

Wo auch immer du das eingestellt hast ... "DNS" würde dazu dienen, einen "Namen" wie "ServerRPI.local" aufzulösen zu einer IP-Adresse wie "192.168.0.X". Er macht also immer noch "DNS", wenn er den Server per "ServerRPI.local" anspricht. Eigentlich muss man das aber nirgendwo einstellen *kopfkratz*

Ansonsten werden "IPP" und "HTTP" wohl gelegentlich synonym benutzt ... es mag also sein, dass du "HTTP" eingestellt hast, und er daraus einfach "IPP" gemacht hat.

Außerdem hat CUPS wohl inzwischen eine automatische Druckererkennung ... wenn du also im Setup etwas eingestellt hast, was nicht funktioniert, und CUPS selbstständig eine funktionierende Druckerverbindung erkannt hat, dann mag es sein, dass er dir diese funktionierende Verbindung als möglichen Drucker anzeigt, obwohl du sie nie eingestellt hast. Das funktioniert sogar bei Netzwerkdruckern.

Eigentlich möchte ich, dass "lokal" gerendert wird, und nicht auf dem langsamen PI, an dem der Drucker angeschlossen ist. Beim Drucken von meinem Ubuntu-PC oder von den Win-Clients soll eigentlich immer jeweils der lokale Druckertreiber verwendet werden und nicht der auf dem Pi vorhandene Treiber.

Ich muss zugeben, so richtig habe ich mich noch nie damit beschäftigt, was genau nun wo gerendert wird. Ich war immer froh, wenn es funktioniert. Ganz so einfach ist das auch nicht, wie dieser Text ganz gut umreißt (leider auf Ausländisch):
https://en.opensuse.org/SDB:Printing_fr ... s_to_Linux
Kurz zusammengefasst: Windows scheint immer für den spezifischen Drucker aufbereitete Daten zu schicken, Linux schickt immer Daten in Formaten wie PostScript, die ggf. noch aufbereitet werden müssen. Da siehst du auch, dass es nicht so einfach ist, den Rendering-Aufwand zu bestimmen ... LibreOffice z.B. muss seinen Text erst mal in PostScript umwandeln, um ihn an CUPS schicken zu können, und solange dein Drucker PostScript versteht, bleibt für den CUPS-Server kaum noch was zu tun. Bei einem JPEG-Bild könnte es genau anders herum aussehen, je nachdem, wie schlau der Druckertreiber ist.

Und IPP schickt meines Wissens immer "raw" Daten, also Daten, die schon für den Drucker aufbereitet sind und vom Druckerserver nicht mehr angefasst werden müssen. Du könntest also auch unter Ubuntu per IPP drucken, dazu braucht aber jede Ubuntu-Installation seinen eigenen Druckertreiber.

Bei meiner kurzen Recherche bin ich noch auf diese Seite gestoßen:
http://wiki.ubuntuusers.de/Samsung-Laserdrucker

Das klingt etwas nervig ... falls das auch auf deinen Drucker zutrifft. Ich würd mir die Arbeit mit der Treiber-Installation ja lieber einmal machen, auf dem CUPS-Server, statt bei jedem Client. Insbesondere ist bei Distributions-fremden Treibern ungewiss, wie gut sie die nächste Systemaktualisierung überstehen - das wäre bei Ubuntu alle 6 Monate.

[joe2017]

Hallo zusammen,

ich bin gerade auf diesen alten Beitrag gestoßen und bin sehr dankbar für die ganze Erklärung.
In unserer Infrastruktur haben wir ca 100 Printer welche immer lokal als Netzwerkdrucker an den einzelnen Clients installiert sind.

Ich bin gerade dabei zu überlegen ob wir nicht lieber mit einem Samba Printserver arbeiten.
Wir möchten gerene alles auf Debian umstellen, aber das wird noch eine Weile dauern. Somit werden wir noch für eine längere Zeit mit Windows/Debian (Clients/Server) arbeiten.

Habe ich das jetzt richtig verstanden, dass ich für meine Windows Server/Clients SAMBA verwende und für Debian Server/Clints CUPS?
Oder kann man das für beide Plattformen über SAMBA Freigaben lösen?

Eine weitere Frage... Aktuell sind die Netzwerkprinter Lokal an den Clients/Server installiert. Somit befindet sich der Spooler auch lokal.
Wenn ich das jetzt auf einen Samba Printer Share umstelle, würde der Spooler auf dem Samba Server liegen. Richtig? Oder kann man diesen auch nach wie vor auf den Client konfigurieren.
Bei 100 Druckern kommen schon dutzende Drucke in der Minute am Server an und ich befürchte, dass die Verarbeitung zu lange dauern wird.

[TomL]

Habe ich das jetzt richtig verstanden, dass ich für meine Windows Server/Clients SAMBA verwende und für Debian Server/Clints CUPS?
Oder kann man das für beide Plattformen über SAMBA Freigaben lösen?

Samba (SMB) ist ein Protokoll für eine Aufgabe, Internet Printing Protocol (IPP) ist ebenfalls ein Protokoll für eine Aufgabe. Man braucht fürs Drucken über/mit Cups kein Samba. Ich nutze dafür auch kein Samba und ich vermute, man kann mit Samba lediglich die Freigaben verwalten, ohne weitere echte Vorteile zu erhalten.... aber da kann ich nur mutmaßen.

Ich persönlich bin da deshalb eher der Meinung, die Mitarbeiter wählen sich schon selber den am Besten für ihre Sachen geeigneten Drucker aus.... das wird dann auch keiner sein, der irgendwo j.w.d. angeschlossen ist.... also regelt sich das von alleine, auch ohne Prüfungen durch Samba. Ich wüsste auch gar nicht, welche Vorteile eine Rechteverwaltung mit Samba hätte, wenn das schlimmstenfalls sogar verhindert, dass Mitarbeiter bei einer Störung ihres Drucker nicht mal kurz auf den der oberen Etage zugreifen sollten können. Meines Erachtens würde mit Samba nur wieder eine neue Verwaltungsebene eingefügt, die Arbeiten und Ressourcen bindet, ohne wirkliche Vorteile zu beinhalten. So ist auch meine Erinnerung an unsere früheren 1000den installierten Druckern.

Bei 100 Druckern kommen schon dutzende Drucke in der Minute am Server an und ich befürchte, dass die Verarbeitung zu lange dauern wird.

Die Warteschlange ist nie das Problem, sondern nur der Umstand, wo gerendert wird... das heißt, wo ist der spezielle Drucker-Treiber installiert. Ist der Drucker-Treiber auf den Clients installert, findet der Rechenaufwand zum Rendern verteilt auf den Clients statt und somit für den CUPS-Server quasi CPU-Last-Neutral. Via IPP werden also nur bereits gerenderte Daten gesendet, die der Cups-Server einfach an den Drucker-Treiber weiterleiten kann, ohne irgendwas dafür zu tun.

Ist hingegen der Drucker-Treiber auf dem CUPS-Server installiert, so benötigen die Clients keinen Treiber und können einfach Rohdaten an den RAW-Queue, also einen RAW-Treiber, senden. Dann werden die Druckdaten natürlich auch im RAW-Format an den Printerserver gesendet und diese muss sie dann, bevor er sie an den Drucker sendet, selber rendern. Das könnte einen langsamen Printerserver dann schon mal in Not bringen (was früher bei meinem PI der Fall war), wenn sehr viele Druckjobs auflaufen und dabei auch noch viele aufwendige Druckjobs sind. Sind die Mehrzahl textbasierende Inhalte in S/W oder Graustufen wird das imho kaum ein Problem verursachen.

jm2c

[joe2017]

Hi Thomas,

danke für die schnelle Rückmeldung. Du hast mir soeben etwas Licht ins dunkle gebracht.
Ich werde mir mal gedanken machen wie ich das zukünftig angehe.

[TomL]

Unser Drucker ist ein Netzwerkdrucker, der unter der IP 10.0.1.6 erreichbar wäre. Unsere Clients drucken aber allesamt nicht direkt auf den Drucker, sondern via CUPS auf den Printserver 10.0.1.2. Würden sie direkt drucken wollen, müsste jeder Client über einen Druckertreiber verfügen. Aber hier ist dieser Printserver das einzige Gerät, das einen passenden Drucker-Treiber installiert hat:

Der Print-Server:


Der Drucker aus der Sicht 'localhost' meines PCs, der also keinen echten Druckertreiber kennt:


Allerdings gibts hier keine 100 von Druckern mit noch mehr Clients.... insofern ist da auch nicht mit Druckstau zu rechnen, zumal mein NUC dafür noch nicht mal den Schnarchmode so richtig verlässt. Aber für mich als heimischer Admin bei der Einrichtung der Clients ist das 'ne tolle Erleichterung. Bei keinem einzigen Client muss ich mich um den Druckertreiber kümmern.... Drucken ohne lokalen Treiber funktioniert einfach direkt und auf Anhieb.

[weshalb]

@TomL

Ich muss da auch nochmal nachfragen. Wie binde ich denn den Drucker so ein, damit auf dem Cups Server gerendert wird und ich keinen Treiber auf dem Rechner benötige?

Und wie stelle ich dann den Client ein, damit der RAW verschickt?

[fischig]

Unsere Clients drucken aber allesamt nicht direkt auf den Drucker, sondern via CUPS auf den Printserver

Mach' ich seit gefühlt 15 Jahren so. Ok, Windowsrechner habe ich keine. Aber wenn ich recht sehe, dann ging es in diesem Thread um MS auch nur vor sechs Jahren.

[TomL]

Und wie stelle ich dann den Client ein, damit der RAW verschickt?

Du wählst beim Einrichten eines neuen Druckes auf dem Client-Rechner im CUPS-OEM-Listcontrol einfach den Hersteller "RAW" und dann im folgenden Dialog die passende Warteschlange. Schau Dir oberhalb die Screenshots an, da sieht man doch den Unterschied beim Treiber. Aber Achtung, mit dieser Einstellung muss auf dem adressierten Cups-Server zwingend ein Drucker-Treiber eingerichtet sein.

[weshalb]

@TomL

Danke. Ich hatte bisher immer einen Treiber für die Drucker serverseitig und einen Druckertreiber auf Clientseite installiert. Da habe ich wohl die Materie nicht begriffen....