On Sat 15 Jun 2019 at 12:09:51 -0400, Gary Dale wrote:
On 2019-06-15 9:49 a.m., Brian wrote:
On Fri 14 Jun 2019 at 19:08:02 -0400, Gary Dale wrote:
On 2019-06-14 7:15 a.m., Brian wrote:
Very useful. As confirmation (or not) of an idea, let us have what
cupsfilter -p /etc/cups/ppd/<Samsung_C410_Series_ppd> -m printer/foo \
-e --list-filters /etc/nsswitch.conf
gives (as root). The line is broken for readability.
Reading over the above output, it struck me that my printer setup wasn't
quite what I thought it was, so I went back to basics, deleted the queues on
both my workstation and the server, downloaded and installed the Samsung
driver on both machines then put the print queues back.
The Samsung driver should be installed only on the server. Having
filtering done twice is very strongly discouraged and is hell to
debug.
https://wiki.debian.org/PrintQueuesCUPS#Double_Filtering
Printing to a network attached printer isn't double-queuing.
No, it is not. It was what you were doing when going through the server
but, as I realise now, the server has no importance in what you want to
do.
Now I seem to be able to print from the workstation to the server via the
USB connector.
I do not follow this and cannot see how a USB cable between client and
server does anything.
You missed the part where the printer is attached to the server via the USB
cable. My grammar was a little unclear but the point is that I always have
been able to print through the server via the USB cable. The server can also
print via the printer's network connection. However the workstation can't
print through the server or directly to the printer's network connection.
I didn't miss it; I was just being a bit slow. I realise now that you
are not interested in using the server.
I stopped sharing the network connected printer from the server since that
really made little sense. Unfortunately I still can't print directly to the
network connection. The job gets processed but I just get an error message
again.
Printing can only take place if the printer is connected by USB to the
client or shared over the network. Not sharing the printer connected to
the server seems counterproductive.
No. The network attached printer is always visible on the network. Putting a
server between the printer and the workstation is adding a layer of
complexity. The problem, which printing through the server doesn't solve, is
printing to the network attached printer from Buster.
I tried switching to the "driverless" driver but CUPS complained about not
being able to copy the PPD file. I noticed an "IPP Anywhere" driver but that
produced the same results as the normal driver.
A shared server queue provides an AirPrint service and the queue is
suitable for a driverless printing system. CUPS should be able to query
the queue for its IPP attributes and construct a PPD.
https://wiki.debian.org/DriverlessPrinting#The_CUPS_PPD_Generator
Yes, but the "IPP anywhere" driver produced the same results as the regular
C410 driver.
The error I got on both print attempts (normal and IPP Anywhere) was:
SPL-C ERROR - Disconnected from host. Please check the connection and try
again.
POSITION : 0x396913 (3762451)
SYSTEM : src/os_hook
LINE : 1981
VERSION : SPL-C 5.59.01 06-19-2013
This was printed by the printer instead of the output I sent.
The lpstat output is now:
Samsung_C410_Series permanent ipp://localhost/printers/Samsung_C410_Series
ipp://SEC30CDA71CB48A.local:631/ipp/printer
This is a queue that has been set up locally on the client using the
Samsung driver. It is likely to bring havoc to printing. Delete the
queue. If you really want to set up a local queue, use the CUPS web
interface with the driverless or everywhere models, or do
lpadmin -p c410 -v ipp://SEC30CDA71CB48A.local:631/ipp/printer -E -m everywhere
Samsung_C410_Series_SEC30CDA71CB48A_ network none
ipp://Samsung%20C410%20Series%20(SEC30CDA71CB48A)._ipp._tcp.local/
This is the printer itself. It would be interesting to see what is given
for 'avahi-browse -rt _ipp._tcp'.
command not found when run as normal use and as root.
https://www.debian.org/distrib/packages#search_packages
For you want do you need (as we both know) the Samsung driver on the
client. When setting up the queue, I suggest you use
socket://<IP_address_of_printer>