[gelöst]Drucker druckt v. Win-Clients, nicht Debian-Clients

[TomL]

Moin

Ich habe heute morgen meinen "neuen" Server in Betrieb genommen und als letzte Handlung den lokal am Server angschlossenen Drucker mit Cups in Betrieb genommen. Das hat auch binnen kürzester Zeit funktioniert... nach einem Reboot wurde sofort ohne zu Meckern die Testseite ausgedruckt. Ich habe mehrere Windows-Clients verbunden (jeweils mit lokalem Client-Drucker-Treiber) und alle konnten auf Anhieb über den Server drucken.

Dann war mein PC an der Reihe... und wie gestern bereits mit den Samba-Zugriffen, die auch von Windows auf Anhieb funktionierten, nur mit meinem Jessie-PC erst mal nicht, klappte natürlich auch das Drucken nicht. Ich habe mal schnell Windows gebootet, neuen Drucker eingerichtet, mit einem Treiber vom Server ... und der Ausdruck klappt sofort. Keine Ahnung, was da wieder auf meinem Jessie-PC falsch ist und warum das nicht funktioniert. Eigentlich kann man ja beim Hinzufügen des Druckers mit Cups unter http://localhost:631/ ja nix verkehrt machen.... das ist ja völlig easy, aber trotzdem gehts nicht. Drucke ich von Jessie aus, sehe ich in der Warteschlange den Fehler: "/usr/lib/cups/filter/foomatic-rip failed"

Wenn ich ehrlich bin, bin ich ja schon manchmal ein wenig angenervt, weil das gesamte Zusammenspiel zwischen allen Windows-Clients und dem Debian-Raspian-Server so einfach und problemlos funktioniert, aber Linux und Linux soviel unnötige Probleme macht. Linux und Linux zusammenzubringen ist im Moment das, was die meiste Zeit benötigt. Aber egal... hat vielleicht jemand eine Idee, zu meinem Druckerproblem?

[Six]

Das kann mehrere Gründe haben. Prüfe,

1. ob der User Mitglied in der Gruppe lp und/oder lpadmin ist (weiß nicht, wie die Gruppe bei Debian heißt. Vielleich gibt es auch beide.)

• ob das Paket foomatic-filters installiert ist.

• ob Perl installiert ist.

• ob das Paket net-snmp installiert ist.

[TomL]

Moin

Ich bin auf beiden Rechnern in der Gruppe lpadmin enthalten. Und ich kann mich auf beiden Rechner via Browser als Admin in Cups anmelden und alles mit den Druckern machen. Auf meinem Jessie-Client ist net-snmp nicht installiert, in den Quellen gibts auch kein Paket mit explizit diesem Namen. Aber die anderen Pakete sind installiert. BTW, mein Pc hat sich ja nicht geändert, da ist ja alles geblieben, wie es war. Ich habe lediglich nen Server ausgetauscht, damit hängt also der Drucker an einem neuen Server. BTW: Natürlich habe ich den "alten" Drucker auf meinem Client-PC entfernt und mit Cups einen neuen Drucker angelegt.... nur leider funktioniert dieser nicht.

Code: Alles auswählen

dpkg --get-selections | grep perl
perl                                            install
perl-base                                       install
perl-modules                                    install

dpkg --get-selections | grep foo
foomatic-db-compressed-ppds                     install
foomatic-db-engine                              install
printer-driver-foo2zjs                          install
printer-driver-foo2zjs-common                   install

[KP97]

In der Fehlermeldung wird aber eindeutig die Datei foomatic-rip benötigt, die in dem Paket foomatic-filters steckt.
Dieses Paket sehe ich nicht in Deiner Abfrage.
Six hat es doch schon gesagt.

[TomL]

Ja, sorry....ist leider nicht alles so leicht zu verstehen .... weil ich nicht entnehmen konnte, wo es fehlt..

Das verwirrende ist die Tatsache, daß sich an meinem PC ja nichts geändert hat. Er hat ja vorher am alten Raspian-Server problemlos gedruckt. Deswegen hatte ich angenommen, dass mein PC "komplett" ist. Der Server ist zwar neu, aber Windowsclients drucken problemlos... also scheint der doch auch "komplett" zu sein.

Ich starte jetzt noch mal den alten Raspi und prüfe, ob ich da dieses foo-dingens finde.Vielleicht gabs ja Änderungen im Image und im neuen fehlt es. Aber im Moment habe ich noch nicht wirklich verstanden, an welcher Maschine ich prüfen muss, ob was fehlt.

[TomL]

Ich habe mir das gerade mal angesehen. Wenn ich foomatic-filters installieren will, entfernt er Cups, Druckertreiber und andere Pakete.... das kann ja eigentlich nicht sein....der Fehler muss eine andere Ursache haben, weils ja genau mit den vorhandenen Paketen vorher funktioniert hat.

Code: Alles auswählen

root@ThomasPC:/home/thomas# apt-get install  foomatic-filters
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.       
Statusinformationen werden eingelesen.... Fertig
Das folgende Paket wurde automatisch installiert und wird nicht mehr benötigt:
  hp-ppd
Verwenden Sie »apt-get autoremove«, um es zu entfernen.
Die folgenden Pakete werden ENTFERNT:
  cups cups-filters hplip printer-driver-gutenprint printer-driver-hpcups printer-driver-postscript-hp printer-driver-splix task-print-server

[NAB]

Die foomatic-filters werden bereits von "cups-filters" bereitgestellt, und diese sind schon installiert:
https://packages.debian.org/jessie/foomatic-filters

(So ganz richtig sieht mir die Ausgabe von apt-get aber auch nicht aus ... vielleicht ist da ein dist-upgrade fällig)

TomL, kann es sei, dass du den "neuen" Drucker so erstellt hast, dass er sich auf eine andere Art mit dem CUPS-Server unterhält ... z.B. IPP statt Cups?

[TomL]

TomL, kann es sei, dass du den "neuen" Drucker so erstellt hast, dass er sich auf eine andere Art mit dem CUPS-Server unterhält ... z.B. IPP statt Cups?

Ich habe 2 mal den Drucker vorhanden... einmal den automatisch von Jessie erkannten, als Netzwerks-Remote-Variante. Und einmal den, den ich mit lokalem Treiber selber installiert habe. Das ist die Cups-Liste meiner Drucker auf meinem Jessie-PC:

Code: Alles auswählen

Queue/Name              Beschreibung               Ort          Marke und Modell                                        Status
CLX-3175                CLX-3175                                Samsung CLX-3175 Foomatic/foo2qpdl (recommended)        Beschäftigt - "/usr/lib/cups/filter/foomatic-rip failed"

Samsung-CLX-3170-Series Samsung CLX-3170 Series    1.1.1.2      Remote Printer                                          Im Leerlauf - "Sending data to printer."

Wie man hier an der Druck-Warteschlange sieht, ist der Remote-Drucker erfolgreich, meiner mit Treiber aber nicht:

Code: Alles auswählen

ID                              Name            Benutzer                        Grösse  Seiten          Status                  
CLX-3175-18                     Unbekannt       {job_originating_user_name}     1k      Unbekannt       verarbeitet seit
                                                                                                        Mon Feb 23 21:14:06 2015 
                                                                                                        "/usr/lib/cups/filter/foomatic-rip failed"      
Samsung-CLX-3170-Series-17      Unbekannt       {job_originating_user_name}     49k     Unbekannt       beendet am
                                                                                                        Mon Feb 23 21:07:33 2015 

Der (nicht-funktionierende) Drucker mit Treiber ist so verbunden:

Code: Alles auswählen

Beschreibung:	CLX-3175
Treiber:	Samsung CLX-3175 Foomatic/foo2qpdl (recommended) (color, 2-sided printing)
Verbindung:	dnssd://Samsung%20CLX-3170%20Series%20%40%20RaspiServer._ipp._tcp.local/cups

Der funktionierende Drucker ist "REMOTE" so verbunden: (Eigentlich zeigt er hier den am Server lokal angeschlossenen Drucker an, obwohl das die Cups-Ausgabe an meinem PC ist)

Code: Alles auswählen

Beschreibung:	Samsung CLX-3170 Series
Treiber:	Samsung CLX-3175 Foomatic/foo2qpdl (recommended) (color, 2-sided printing)
Verbindung:	usb://Samsung/CLX-3170%20Series?serial=14AHBAHZ401248Y&interface=1

Wie ich das jetzt richtig vestehe, ist der Druck übers Netz via Cups ja grundsätzlich möglich, da ich ja remote über den Server drucken kann. Das soll aber letzten Endes nicht sein, weil genau der fürs rendern umfangreicher Drucke eigentlich zu unterdimensioniert ist - deswegen ist ja auch der lokale Druckertreiber notwendig. Aber mit dem funktionierts eben nicht... *hmmm*

Das ist meine Printers.conf:

Code: Alles auswählen

 Printer configuration file for CUPS v1.7.5
# Written by cupsd
# DO NOT EDIT THIS FILE WHEN CUPSD IS RUNNING
<DefaultPrinter CLX-3175>
UUID urn:uuid:59a83bb5-eccd-35b4-650f-b6b470b40e4e
AuthInfoRequired none
Info CLX-3175
DeviceURI dnssd://Samsung%20CLX-3170%20Series%20%40%20RaspiServer._ipp._tcp.local/cups
State Idle
StateTime 1424722446
Reason cups-remote-stopped
Type 8425484
Accepting Yes
Shared No
JobSheets none none
QuotaPeriod 0
PageLimit 0
KLimit 0
OpPolicy default
ErrorPolicy stop-printer
</Printer>

<Printer Samsung-CLX-3170-Series>
UUID urn:uuid:98cb53e4-cdfd-394c-646e-52c5de642436
AuthInfoRequired none
Info Samsung CLX-3170 Series
Location 1.1.1.2
DeviceURI ipp://1.1.1.2:631/printers/Samsung_CLX-3170_Series
State Idle
StateTime 1424722053
Type 6
Accepting Yes
Shared No
JobSheets none none
QuotaPeriod 0
PageLimit 0
KLimit 0
OpPolicy default
ErrorPolicy stop-printer
Option cups-browsed true
</Printer>

Ich habe den Drucker jetzt mehrfach unterschiedlich angelegt. Sobald ich einen lokalen Treiber verwende, druckt er nicht. Ich habe auch mal diese funktionierende Verbindung DeviceURI ipp : //1.1.1.2:631/printers/Samsung_CLX-3170_Series mit lokalem Treiber getestet, funktioniert nicht. Remote kann ich drucken, mit lokalem Treiber nicht.

[NAB]

Eh ... ich bin verwirrt. Das liegt vorallem daran, dass ich dnssd:// nicht kenne bzw. nur vom Mac kenne.

Aber ... sag mal ...

Code: Alles auswählen

<Printer Samsung-CLX-3170-Series>
DeviceURI ipp://1.1.1.2:631/printers/Samsung_CLX-3170_Series

Das ist der Drucker, der funktioniert, ja?

Sprechen die Windows-PCs über dieselbe Adresse mit dem Drucker? Und haben die Windows-PCs einen Treiber für den Samsung-Drucker? Dann dürften die Windows-PCs "raw"-Daten senden, das Rendern findet also auf den Windows-PCs statt und Cups reicht die Daten unverändert an den Drucker weiter, hat also nichts zu tun.

Dann könnte der Jessie-PC das gleiche machen, also schon einen Treiber benutzen. Im Zweifelsfall solltest du dem Server sagen, dass er nur "raw" Daten akzeptieren soll.

Aus dieser Zeile:

Code: Alles auswählen

DeviceURI dnssd://Samsung%20CLX-3170%20Series%20%40%20RaspiServer._ipp._tcp.local/cups

werde ich halt nicht so recht schlau. Sowas hab ich noch nie gesehen. Und du meinst, das ist ein lokaler Drucker, auf den du per lokalem Treiber druckst, und das CUPS Backend soll die Daten dann an den CUPS Server schicken?

[TomL]

Moin Nab

Die Windowsrechner sind so verbunden: //RaspiServer/Samsung_CLX-3170_Series (entspricht also //1.1.1.2/Samsung_CLX-3170_Series)

Mein Jessie-PC verbindet sich unterschiedlich.
1. Die Einrichtung über Cups: http:/ /localhost:631/ verbindet mit Vorschlagswerten zu:
dnssd://Samsung%20CLX-3170%20Series%20%40%20RaspiServer._ipp._tcp.local/cups

1. Die Einrichtung über Jessie->Systemeinstellungen->Drucker verbindet ebenfalls mit Vorschlagswerten zu:
ipp://1.1.1.2:631/printers/Samsung_CLX-3170_Series

Beide Verbindungen sind "Remote" und beide Verbindungen funktionieren. Sobald ich aber den passenden Samsung-Druckertreiber auswähle, um lokal zu "rendern", ist es vorbei und es kommt diese Fehlermeldung in der Warteschlange. Auf den Windows-Clients hingegen funktioniert der "lokale" Druckertreiber mit Ausgabe auf //1.1.1.2/Samsung_CLX-3170_Series.

Kann es nicht vielleicht auch einfach ein Jessie-Testing-Problem sein

[NAB]

Kann es nicht vielleicht auch einfach ein Jessie-Testing-Problem sein

Aber klar kann es daran liegen ... das wäre sogar die beste Erklärung für den foomatic-rip-Fehler. Aber soweit ich dich verstanden habe, lief es vorher mit Jessie, und du hast nur am RasPi was geändert.

Eigentlich würd ich jetzt zwecks Fehlersuche den Drucker zum Jessie-Rechner tragen und dort lokal testen.

[TomL]

Das Problem an der Stelle ist, dass ich nicht meine Hand dafür ins Feuer legen würde, dass das vorher schon mal mit Debian geklappt hat..... ja, es hat mit lokalem Treiber geklappt, das weiss ich... aber war das mit Trusty Tahr? Oder mit Utopic Unicorn? Oder mit Wheezy...? ... ich habs vergessen. Drucken ging IMMER, ich weiss nur nicht mehr, wann es auch mit lokalem Treiber geklappt hat. Und es ist durchaus möglich, dass es bei Wheezy auch nur "Remote" war. *hmmmm* Und weil ich eigentlich nicht viel zu drucken habe, schon gar nicht mit großem Umfang, kann es sein, dass ich zuletzt mit Debian immer unbemerkt Remote gedruckt habe.

Ich vermute mal, dass das ein Problem mit dem Gutenprint-Treiber ist. Ich weiss, dass ich damit schon früher Probleme hatte. Und ich erinnere mich, dass ich irgendwann mal mit dem Treiber von http://www.bchemnet.com/ experimentiert habe... kann mich aber kaum noch dran erinnern. Zu dem Zeitpunkt quälten mich wesentlich mehr die Sound und Video-Fehler. Aber diese Seite hat nicht mal ein Impressum.... und ich will meine Jessie nicht schon wieder strubbelig machen... weil jetzt läuft sie ja ansonsten richtig gut.

Und was ich gerne mal testen würde, wie das mit dem Drucken über Samba geht, so wie die Windowsdrucker das anscheinend auch machen. .... habe aber keine Ahung, wie ich das einstellen müsste. Oder wendet sich der Windows-Druckspooler direct an Cups....?... kann ich mir gar nicht vorstellen.

[NAB]

Mir ist immer noch unklar, wie und wo du den "lokalen Treiber" einstellst. Meines Wissens brauchst du zum Drucken ein CUPS Backend, müsstest also über das lokale Backend drucken, in dem der richtige Treiber eingestellt ist, und das lokale Backend müsste die gerenderten Daten dann "raw" an das CUPS auf dem Server schicken, welches sie nur noch an den Drucker weiterleitet.

Dazu wäre es erst mal hilfreich zu wissen, ob der Drucker überhaupt druckt, wenn er direkt an Wheezy angeschlossen ist.

Das ist im Prinzip das selbe, was Windows jetzt macht. Samba leitet die Daten auch nur unbearbeitet an CUPS weiter, und CUPS schickt sie dann unbearbeitet an den Drucker. Von Samba hast du also keine Vorteile, nur mehr Konfigurationsaufwand.

[TomL]

Mir ist immer noch unklar, wie und wo du den "lokalen Treiber" einstellst. Meines Wissens brauchst du zum Drucken ein CUPS Backend, müsstest also über das lokale Backend drucken, in dem der richtige Treiber eingestellt ist, und das lokale Backend müsste die gerenderten Daten dann "raw" an das CUPS auf dem Server schicken, welches sie nur noch an den Drucker weiterleitet.

Das ist egal, weil es beides mal der gleiche "lokal eingestellte" Drucker ist. Ändere ich Cups, sehe ich es bei Jessie. Ändere ich bei Jessie, sehe ich es bei Cups. Ich ändere nur "Remote Printer" in dem ich einen passenden Treiber auswähle.
*guckstuhier*

Dazu wäre es erst mal hilfreich zu wissen, ob der Drucker überhaupt druckt, wenn er direkt an Wheezy angeschlossen ist.

Ja, das müsste ich mal testen.... *hmmm*...….

Das ist im Prinzip das selbe, was Windows jetzt macht. Samba leitet die Daten auch nur unbearbeitet an CUPS weiter, und CUPS schickt sie dann unbearbeitet an den Drucker. Von Samba hast du also keine Vorteile, nur mehr Konfigurationsaufwand.

Tja, weiss nicht... Cups auf dem Server meckert ja nur, wenn der Druck von Jessie kommt, aber nicht wenn von Windows gedruckt wird. Wer weiss, wenn Jessie den gleichen Drucker-Daten-Weg über Samba nimmt, meckert Cups vielleicht nicht mehr.

[TomL]

Nachtrag:

Ich glaube ... jetzt gerade hat was bei mir "klick" gemacht.... irgendein Blitzgedanke... Cups auf dem Server sieht nämlich *so* aus....

Code: Alles auswählen

Samsung_CLX-3170_Series (Frei, Aufträge werden akzeptiert, freigegeben)
Beschreibung:	Samsung CLX-3170 Series
Ort:	Local Printer
Treiber:	Samsung CLX-3175 Foomatic/foo2qpdl (recommended) (color, 2-sided printing)
Verbindung:	usb://Samsung/CLX-3170%20Series?serial=14AHBAHZ401248Y&interface=1
Einstellungen:	job-sheets=none, none media=iso_a4_210x297mm sides=one-sided

Kann es sein, dass ich von Jessie lokal gerenderte Daten an den o.g. Server-Treiber zum erneuten Rendern sende......? ... ... Das wäre ja dann wirklich eine denkbare Fehlerursache. Ich teste morgen mal, ob ich auf dem Server den gleichen Drucker mit anderem Namen und OHNE Treiber noch mal anlegen kann. Dann würde ich bei Jessie einfach diesen Drucker ohne Treiber mal versuchen....*hmmm*. Ist nur wiederum merkwürdig, dass das von Windows aus keine Probleme macht, denn die Windows-Clients rendern definitiv auf dem Client.

[NAB]

Warte mal ... bleiben wir doch erst mal bei dem, was Six gesagt hat.
Existiert denn die Datei "/usr/lib/cups/filter/foomatic-rip" unter Jessie? Und ist es eine Datei, oder ein Link?
Nach der Debian-Suche sollte die Datei nur in "foomatic-filters" vorhanden sein, und das Paket fehlt ja bei dir:
https://packages.debian.org/search?sear ... omatic-rip

Und was noch merkwürdiger ist ... auf dem RasPi nimmt er ja anscheinend den foo2qpdl-Treiber. Der steckt bei Debian im Paket printer-driver-foo2zjs, welches bei dir installiert ist. Und das braucht zwingend "foomatic-filters":
https://packages.debian.org/wheezy/prin ... er-foo2zjs

Da scheint irgendwas mit deinem Jessie nicht zu stimmen.

[JTH]

Nach der Debian-Suche sollte die Datei nur in "foomatic-filters" vorhanden sein, und das Paket fehlt ja bei dir:
https://packages.debian.org/search?sear ... omatic-rip

Seit Jessie gibt es foomatic-rip auch im Paket cups-filters, dass daher mit foomatic-filters im Konflikt steht. Dem Changelog von cups-filters nach ist foomatic-filters anscheinend überholt/nicht mehr notwendig:

...
* Add "Conflicts/Replaces/Provides: foomatic-filters" for the
cups-filters binary package. Now foomatic-rip is part of
cups-filters and the foomatic-filters package is obsolete and should
get automatically uninstalled by the cups-filters binary package.
...
-- Didier Raboud <odyx@debian.org> Fri, 06 Dec 2013 23:36:33 +0100

[NAB]

Shit, ich war mir sicher, dass ich auf "Jessie" geklickt habe. Ich hab mich schon gewundert. JTH hat natürlich recht *hüstel*

[JTH]

Und das zu der Uhrzeit

[TomL]

Moin

Es gibt ein paar neue Erkenntnisse. Ich bin der Meinung, dass es ein Treiberproblem auf meinem Jessie-PC ist. Vom Windows-Client kann ich beide Drucker auswählen und von beiden Druckern passt der Ausdruck. Unmittelbar nach dem Druckstart meldet (*) sich auf dem Server smbd, was wohl bedeutet, dass die "Kommunikation" über samba stattfindet. Kurz danach meldet sich Cups und wiederum kurz danach kommt der Ausdruck raus. Während dessen lag KEINE CPU-Last auf dem Server an, was wiederum bedeutet, dass der Windows-Druckspooler selber gerendert hat. Also genau so, wie es sein muss.

Das habe ich jetzt festgestellt:

Code: Alles auswählen

                     | Server CLX-3170              | Server CLX-3170_RAW
                     | mit Samsung-Treiber          | ohne Treiber (RAW)
---------------------+------------------------------+------------------------
Windows-Client       |                              |
Mit lokalem Treiber  | Ausdruck OK!                 | Ausdruck OK!
                     |                              |
                     |                              |
Debian8-Client       |                              | 
Remote/RAW           | Ausdruck OK!                 | ./.
                     |                              | 
                     |                              |
Debian8-Client       |                              | Keine Fehlermeldung,
Mit lokalem Treiber  | "/usr...foomatic-rip failed" | aber auch kein Druck
                     |                              | Warteschlangen sind abgearbeitet!

Keine Ahnung, wie ich das lösen soll... ich denke und hoffe, dass das mit Jessie Stable vielleicht vom Tisch ist... ... Was vielleicht noch fehlt, ist der Test des Druckers direkt an Jessie. Das muss ich aber zurückstellen, bis ich meinen Laptop mit Jessie (XFCE) fertig habe. Ich kann den Drucker nicht hier "rauf" schleppen... das ist mir zu aufwendig... vor allem vor dem Hintergrund, dass es "Remote" ja klappt.


(*) top -i

[NAB]

Also unter Wheezy würd ich jetzt in /etc/cups/cupsd.conf den LogLevel von "warn" auf "debug" setzen und dann gucken, was sich unter /var/log/cups/ tut. Ich hab nur keine Ahnung, wie das unter Jessie läuft.

[TomL]

Moin

Ich muss mal eben Frust loswerden... "boaar... ist das ne Kacke..." Ich kriegs einfach nicht hin, dass der Drucker ordentlich druckt..... bei jedem Versuch der Inbetriebnahme sind die Ergebnisse anders... alles irgendwie nicht reproduzierbar... nicht mal die Probleme.... mal geht alles, mal geht irgendwas, mal geht gar nix.... völlig unbegreiflich.

Dieser Tage ist sowohl bei Jessie als auch auf meinem Pi mit Wheezy ein richtig dickes Paket per dist-upgrade gekommen. Ich habe gesehen, dass jede Menge Cups enthalten war und auch ein "neuer" Gutenprint-Treibers. Und heute hatte ich mir gedacht, ich versuchs noch mal ganz von vorne und alles neu. Ich habe zuerst den Drucker am Server neu eingerichtet. Testseite drucken und Druck via Konsole klappten sofort. Drucker war freigegeben, Treiber ok.... eigentlich also alles in Ordnung.

Ich habs jedoch in 2 Stunden nicht hinbekommen, dass vom Windows-Client auch nur ein einziger Druck in den Server-Cups-Aufträgen angekommen ist. Windows hat nicht gemeckert, aus Windows-Sicht alles gut. Auf Server-Sicht sehe ich mit "top-i" dass bei Druck vom Client kurz Samba aktiv wird und danach Cups.... und das wars.... mehr passiert nicht. Vermutlich marschiert der Druck in gerader Linie von Windows über Samba nach Cups und von Cups in die Garbage Collection....

Ich habe den Drucker jetzt zum Test mal schnell lokal an einen Windowsclient angeschlossen, im Netz freigegeben und alles funktioniert auf Anhieb. An dem Punkt frage ich mich, warum Debian so einen Mist wie Cups nicht endlich mal entsorgt und was baut, was einfach nur funktioniert.

[KP97]

...warum Debian so einen Mist wie Cups nicht endlich mal entsorgt und was baut, was einfach nur funktioniert.

Cups ist kein Mist und funktioniert immer, vorausgesetzt, man hat es richtig eingerichtet über die Webseite.
Aber das ist ja mit jeder Software so.
Warum benutzt Du Samba und gehst nicht über den Weg ipp-Protokoll. Evtl. wäre das einfacher.
Anleitungen dazu findet man jede Menge im Netz, z.B.
https://www.freebsd.org/doc/en_US.ISO88 ... ients.html

[NAB]

CUPS stammt von Apple und nicht von Debian

Genau darum mache ich einen Bogen um "Testing" ... wenn das Ziel sich dauernd ändert, ist es schwer, eine funktionierende Konfiguration hinzukriegen. Da kann man ja gleich Ubuntu nehmen.

Hast du schon die Log-Dateien von CUPS entdeckt? Bei Wheezy liegen die unter /var/log/cups ... wie es bei Jessie mit Systemd steht, weiß ich nicht.

Und Samba macht die Sache nur komplizierter und nicht einfacher.

[TomL]

Anleitungen dazu findet man jede Menge im Netz, z.B.
https://www.freebsd.org/doc/en_US.ISO88 ... ients.html

Danke für den Link.... das war bisher die beste und kürzeste Version, die auch noch auf Anhieb funktioniert hat. Ich habe etliche Anleitungen in meinen Favoriten gespeichert... und die Variante mit der IP hat nicht eine einzige beschrieben.... den ganzen Müll lösche ich jetzt sofort ....