Fw: Probleme mit Swat (Fokussierung auf Druckereinbindung)
Hallo Leute, ich habe gerade mal folgendes in einer Dos-Box auf meinem Laptop probiert: dir > \\matrix\lp und siehe da, er druckt. Wieso geht das? Kann das irgendwie mit dem Treiber zusammenhängen??? Thx. Stephan
* Sonntag, 05. Januar 2003 um 18:56 (+0100) schrieb Stephan Rehlein:
ich habe gerade mal folgendes in einer Dos-Box auf meinem Laptop probiert:
dir > \\matrix\lp
und siehe da, er druckt. Wieso geht das? Kann das irgendwie mit dem Treiber zusammenhängen???
Ja, mit dem auf dem Linux-Rechner. Das ist das "übliche"
Samba-Drucker-Problem:
Wenn man mit einem Original-Drucker-Treiber von Windows auf einen
Samba-Drucker drucken will, dann *muss* der Samba-\CUPS-Drucker die
Datem "roh" an den Drucker weiterleiten. Dazu entweder mit CUPS einen
(zusätzlichen) RAW-Drucker erstellen und den unter Windows benutzen
oder in der smb.conf unter "[printers]" ein
"print command = lpr -r -o raw -P%p %s" einfügen.
Gruß
Andreas
--
Andreas Könecke "Andreas Koenecke
Moin, Andreas Koenecke schrieb:
Wenn man mit einem Original-Drucker-Treiber von Windows auf einen Samba-Drucker drucken will, dann *muss* der Samba-\CUPS-Drucker die Datem "roh" an den Drucker weiterleiten.
Da meld ich mich auch noch mal. Hier hängt ein DeskJet 990 an einem Linux-Client und wird per CUPS angesteuert. Der Drucker wird per Broadcast an alle Rechner im Netzwerk freigegeben, auch an den Samba-Server. Von diesem lasse ich die Drucker mit "load printers = yes" einbinden und als [printers]-Sektion habe ich: [printers] comment = Drucker path = /var/spool/samba browseable = yes Auf dem Win98-Client ist der von Windows mitgelieferte Drucker- Treiber für einen DeskJet 895 installiert. Und dieser druckt nun ganz normal auf die Queue, auf der auch alle Linux-Kisten drucken. Und unter WinNT habe ich einfach den dort mitgelieferten Druckertreiber für einen Postscript-fähigen Apple Laserjet installiert. Der druckt auch ganz normal auf der CUPS-Queue. Hm, also ich habe noch nie eine RAW-Queue dafür gebraucht. Gruß, Patrick
* Sonntag, 05. Januar 2003 um 23:02 (+0100) schrieb Patrick Hess:
Andreas Koenecke schrieb:
Wenn man mit einem Original-Drucker-Treiber von Windows auf einen Samba-Drucker drucken will, dann *muss* der Samba-\CUPS-Drucker die Datem "roh" an den Drucker weiterleiten.
Hier hängt ein DeskJet 990 an einem Linux-Client und wird per CUPS angesteuert. Der Drucker wird per Broadcast an alle Rechner im Netzwerk freigegeben, auch an den Samba-Server.
Von diesem lasse ich die Drucker mit "load printers = yes" einbinden und als [printers]-Sektion habe ich:
[printers] comment = Drucker path = /var/spool/samba browseable = yes
Auf dem Win98-Client ist der von Windows mitgelieferte Drucker- Treiber für einen DeskJet 895 installiert. Und dieser druckt nun ganz normal auf die Queue, auf der auch alle Linux-Kisten drucken.
Hast du vielleicht in '/etc/cups/mime.convs' den "Raw Filter"-Eintrag "aktiviert"? Das ist eine weitere Möglichkeit mit einem Original-Drucker-Treiber auf eine "Filter"-CUPS-Queue zu drucken. (Wenn du es nicht warst, hat SuSE evtl. den Eintrag in ihren CUPS-Paketen gesetzt. Standard-Vorgabe bei CUPS ist der auskommentierte "Raw-Filter".)
Und unter WinNT habe ich einfach den dort mitgelieferten Druckertreiber für einen Postscript-fähigen Apple Laserjet installiert. Der druckt auch ganz normal auf der CUPS-Queue.
Mit "Original-Drucker-Treiber" meine ich Nicht-Postscript-Treiber.
Gruß
Andreas
--
Andreas Könecke "Andreas Koenecke
Moin, Andreas Koenecke schrieb:
* Sonntag, 05. Januar 2003 um 23:02 (+0100) schrieb Patrick Hess:
Andreas Koenecke schrieb:
Wenn man mit einem Original-Drucker-Treiber von Windows auf einen Samba-Drucker drucken will, dann *muss* der Samba-\CUPS-Drucker die Datem "roh" an den Drucker weiterleiten.
Auf dem Win98-Client ist der von Windows mitgelieferte Drucker- Treiber für einen DeskJet 895 installiert. Und dieser druckt nun ganz normal auf die Queue, auf der auch alle Linux-Kisten drucken.
Hast du vielleicht in '/etc/cups/mime.convs' den "Raw Filter"-Eintrag "aktiviert"?
Nein, der ist dort auskommentiert. Auch auf dem FreeBSD-Samba-Server ist er in der entsprechenden Datei nicht aktiviert. Komisch, hier funktioniert was und keiner weiß warum ;-) Jaja, wenn drei Betriebssysteme an der gleichen Sache rumfummeln...
Und unter WinNT habe ich einfach den dort mitgelieferten Druckertreiber für einen Postscript-fähigen Apple Laserjet installiert. Der druckt auch ganz normal auf der CUPS-Queue.
Mit "Original-Drucker-Treiber" meine ich Nicht-Postscript-Treiber.
Ok, ist eigentlich auch logisch, da CUPS Postscript interpretieren kann. Gruß, Patrick
* Sonntag, 05. Januar 2003 um 23:44 (+0100) schrieb Patrick Hess:
Andreas Koenecke schrieb:
Hast du vielleicht in '/etc/cups/mime.convs' den "Raw Filter"-Eintrag "aktiviert"?
Nein, der ist dort auskommentiert. Auch auf dem FreeBSD-Samba-Server ist er in der entsprechenden Datei nicht aktiviert.
Hm, das ist interessant... Wenn du mal Zeit und Lust hast, wäre es schön, wenn du bei CUPS den "LogLevel" auf "debug" setzen könntest und dann nach einem Druck von dem Win98-Client die Zeilen des Druck-Jobs aus dem CUPS-Error-Log mailen würdest (evtl. PM).
Komisch, hier funktioniert was und keiner weiß warum ;-)
Das ist IMHO das zweitschlechteste nach "Funktioniert nicht und keiner
weiss warum". ;-) -- Außerdem haben wir doch keinen Apple...
Gruß
Andreas
--
Andreas Könecke "Andreas Koenecke
Hallo, Andreas Koenecke schrieb:
* Sonntag, 05. Januar 2003 um 23:44 (+0100) schrieb Patrick Hess:
Andreas Koenecke schrieb:
Hast du vielleicht in '/etc/cups/mime.convs' den "Raw Filter"-Eintrag "aktiviert"?
Nein, der ist dort auskommentiert. Auch auf dem FreeBSD-Samba-Server ist er in der entsprechenden Datei nicht aktiviert.
Wenn du mal Zeit und Lust hast, wäre es schön, wenn du bei CUPS den "LogLevel" auf "debug" setzen könntest und dann nach einem Druck von dem Win98-Client die Zeilen des Druck-Jobs aus dem CUPS-Error-Log mailen würdest (evtl. PM).
Momentan habe ich leider ganz wenig Zeit, aber ich habe mir das mal für's Wochenende vorgemerkt. Den Error-Log werde ich am besten ins Netz stellen, das ist wohl am unkompliziertesten - dann kann auch jeder, der sich dafür interessiert, das ansehen. Ich melde mich dann Ende der Woche nochmal.
Komisch, hier funktioniert was und keiner weiß warum ;-)
Das ist IMHO das zweitschlechteste nach "Funktioniert nicht und keiner weiss warum". ;-) -- Außerdem haben wir doch keinen Apple...
Wenn die Dinger nicht so unverschämt teuer (und seit neuestem auch noch laut) wären, hätte ich mir schon längst einen angeschafft. Naja. Gruß, Patrick
Hat eine erfahrungen mit ACPI und der 2.4.20ér Kernel? Soweit ich weiß, hat SuSE bei deren Standardkernel einige Patches eingebracht, die stabile ACPI unterstützung mitbringen. Mein Intelboard jedenfalls meldet ACPI fehler wenn ich bei der Kompilierung der ungepatchte vanilla Kernel 2.4.20 ACPI aktiviere. Muss mans etwa patchen? thx nader
Nader Yasseri wrote:
[...] Mein Intelboard jedenfalls meldet ACPI fehler wenn ich bei der Kompilierung der ungepatchte vanilla Kernel 2.4.20 ACPI aktiviere. Muss mans etwa patchen?
Nein, nein, nein,... Wenn es Fehlermeldungen vom Compiler gibt oder der Linker sich beschwert oder depmod sich ueber fehlende Referenzen beschwert, dann ist meist eine falsche Konfiguration Schuld. Wenn Du compilierst, dann kann es ja noch kein Fehler vom ACPI sein, der ist ja da noch gar nicht im Spiel - erst wenn Du den Kernel installiert hast und bootest und dann Fehlermeldungen bekommst, dann hat evtl. der Kernel Probleme mit Deinem System, oder umgekehrt, wie man es nimmt. Also, hier compiliert der 2.4.20 mit xfs-Patch ohne Probleme. CU, Th. -- Thomas Hertweck, Dipl.-Geophys., GPI Universitaet Karlsruhe === First they ignore you, then they laugh at you, then === === they fight you, then you win. (M. Ghandi) ===
Am Montag, 6. Januar 2003 11:04 schrieb Thomas Hertweck:
Mein Intelboard jedenfalls meldet ACPI fehler wenn ich bei der Kompilierung der ungepatchte vanilla Kernel 2.4.20 ACPI aktiviere. Muss mans etwa patchen?
Nein, nein, nein,... Wenn es Fehlermeldungen vom Compiler gibt oder der Linker sich beschwert oder depmod sich ueber fehlende Referenzen beschwert, dann ist meist eine falsche Konfiguration Schuld. Wenn Du compilierst, dann kann es ja noch kein Fehler vom ACPI sein, der ist ja da noch gar nicht im Spiel - erst wenn Du den Kernel installiert hast und bootest und dann Fehlermeldungen bekommst, dann hat evtl. der Kernel Probleme mit Deinem System, oder umgekehrt, wie man es nimmt. Also, hier compiliert der 2.4.20 mit xfs-Patch ohne Probleme.
Sorry, ich hab mich nicht klar genung ausgedruckt. Die Fehler passiert natürlich beim Booten mit dem Kompilierten Kernel und nicht während des Kompilieren.
Am Montag, 6. Januar 2003 20:49 schrieb Nader Yasseri:
Am Montag, 6. Januar 2003 11:04 schrieb Thomas Hertweck:
Mein Intelboard jedenfalls meldet ACPI fehler wenn ich bei der Kompilierung der ungepatchte vanilla Kernel 2.4.20 ACPI aktiviere. Muss mans etwa patchen?
Nein, nein, nein,... Wenn es Fehlermeldungen vom Compiler gibt oder der Linker sich beschwert oder depmod sich ueber fehlende Referenzen beschwert, dann ist meist eine falsche Konfiguration Schuld. Wenn Du compilierst, dann kann es ja noch kein Fehler vom ACPI sein, der ist ja da noch gar nicht im Spiel - erst wenn Du den Kernel installiert hast und bootest und dann Fehlermeldungen bekommst, dann hat evtl. der Kernel Probleme mit Deinem System, oder umgekehrt, wie man es nimmt. Also, hier compiliert der 2.4.20 mit xfs-Patch ohne Probleme.
Sorry, ich hab mich nicht klar genung ausgedruckt. Die Fehler passiert natürlich beim Booten mit dem Kompilierten Kernel und nicht während des Kompilieren.
Hab mir die Sache nochmal genauer angeschaut. Auf mein Intel Board 845pe meldet der 2.4.20ér vanilla Kernel bei aktivierte ACPI Fehler (**Error could nor find ACPI Table) . Hab mir ein ACPI Patch von der Hackerkernel besorgt (http://members.optusnet.com.au/ckolivas/kernel/) Jetzt funktuniert ACPI ohne Probleme. Auch SuSE bietet ein gepachte Update deren Standardkernel, was den selben ACPI Patch enthält.
participants (5)
-
Andreas Koenecke -
NYasseri＠t-online.de -
patrick_hess＠t-online.de -
Stephan Rehlein -
Thomas Hertweck