1 |
On Thursday, 11 February 2021 20:32:47 GMT Dan Egli wrote: |
2 |
> On 2/11/2021 7:05 AM, Michael wrote: |
3 |
> > On Wednesday, 10 February 2021 23:03:18 GMT Dan Egli wrote: |
4 |
> >> On 2/10/2021 4:30 AM, Michael wrote: |
5 |
> >>> This is how I understand the printing process ought to work in your use |
6 |
> >>> case: |
7 |
> >>> |
8 |
> >>> The Samba server, Athena, will use the MSWindows Network Printer |
9 |
> >>> identified as "Windows Printer via SAMBA" in its CUPS GUI. |
10 |
> >>> |
11 |
> >>> Printing jobs will be submitted from Athena's CUPS to the MSWindows PC & |
12 |
> >>> its attached printer, via the corresponding smb:// URI. CUPS which will |
13 |
> >>> use the Samba server on Athena to authenticate and send the data for |
14 |
> >>> printing to the MSWindows PC and its shared printer. |
15 |
> >>> |
16 |
> >>> The same process will need to be followed by Janus; i.e. the CUPS server |
17 |
> >>> on Janus will have to use the same smb:// URI to submit the data to be |
18 |
> >>> printed to Athena's Samba server and as long as authentication is |
19 |
> >>> successful Athena will forward it to the Windows PC. |
20 |
> >> |
21 |
> >> Forgive me, but if I use the SAME url, then it's not Athena acting as |
22 |
> >> the print server, it's the windows client that the printer is hooked up |
23 |
> >> to. |
24 |
> > |
25 |
> > Sorry, I meant to say on Janus use the smb://Athena/<printer> URI and see |
26 |
> > if Athena then forwards the request via the shared Samba printer service |
27 |
> > onward to the MSWindows PC. Of course if you try to print directly to |
28 |
> > the MSWindows PC with smb://IRIS/<printer> it will work, just as it works |
29 |
> > from Athena - but that's not what you're after. |
30 |
> |
31 |
> That may work. I guess I'm just a bit worried about back and forth. i.e. |
32 |
> Janus tries to print, then Athena asks for permission to let it happen, |
33 |
> and that request goes right back to Janus. I'm VERY unfamiliar with AD |
34 |
> so I can't be 100% certain this will work. I can't see any reason why it |
35 |
> wouldn't, but that's not the same thing as saying there ISN'T a reason |
36 |
> why it wouldn't work. |
37 |
|
38 |
The transaction for AD authentication to access the domain is taking place |
39 |
over different applications, threads, protocols and ports to those used for |
40 |
printing. There should be no confusion. |
41 |
|
42 |
[snip ...] |
43 |
|
44 |
> > The shared printer advertised by CUPS in Athena should pop up on |
45 |
> > Janus as an available printer via mDNS. |
46 |
> |
47 |
> I know nothing of mDNS. |
48 |
|
49 |
mDNS (multicast DNS) is a protocol used to resolve hostnames to IP addresses |
50 |
in LANs without the need to use a local DNS server. Client devices trying to |
51 |
resolve a name send UDP multicasts using port 5353 over the LAN subnet to ask |
52 |
for a named host to identify itself. The target host responds with its IP |
53 |
address and the client updates its mDNS cache. Linux, Apple and Windows 10 |
54 |
use mDNS to discover printers. If you see zeroconf, avahi, or Apple's Bonjour |
55 |
service, they are all referring to this mechanism. If you use IP addresses to |
56 |
manually configure printer server/clients, then this service is not necessary. |
57 |
|
58 |
Samba uses the native MSWindows 'Active Directory Domain Services' over TCP |
59 |
port 445 to resolve IP addresses when printing over Samba. |
60 |
|
61 |
|
62 |
> I tried IPP to no avail, but then again perhaps |
63 |
> I formed the URLs wrong. I tried ipp://athena/ipp/<PRINTER> and it |
64 |
> didn't work. I tried http/https mode too. That ALMOST worked. |
65 |
|
66 |
When you select the HTTP protocol it still sends IPP packets in MIME format. |
67 |
I'm not sure of the difference between the two - I guess IPP is native to CUPS |
68 |
and most/all printers. |
69 |
|
70 |
|
71 |
> But I get |
72 |
> an error on Janus saying "Filter Failed" and a lot of messages in my |
73 |
> error_log (debug mode) that really make no sense to me. Here's a |
74 |
> sample. I'll put the full log on my web server if you want to see it. |
75 |
> It's 77k nearly with debug turned on and that's only for trying to print |
76 |
> ONE test page and failing. The url is |
77 |
> https://www.newideatest.site/cups_error_log |
78 |
|
79 |
I had a quick look, this is what I see: |
80 |
|
81 |
Your client sends IPP commands over HTTP to Athena. CUPS server on Athena |
82 |
accepts these and processes them. So the comms appear to be working fine |
83 |
between the two. :-) |
84 |
|
85 |
Then we have this on line 292: |
86 |
|
87 |
D [11/Feb/2021:13:08:36 -0700] [Job 11] hpcups (application/vnd.cups-raster to |
88 |
printer/ENVY, cost 0) |
89 |
|
90 |
This is the hplip printer driver in action, using a MIME format for CUPS to |
91 |
transmit and print raster imaged pages. |
92 |
|
93 |
Question: Why is this driver in play? |
94 |
|
95 |
Even if the physical printer is an HP, it is neither connected to Janus, nor |
96 |
Athena. |
97 |
|
98 |
On lines 331 & 332: |
99 |
|
100 |
I [11/Feb/2021:13:08:36 -0700] [Job 11] Started filter /usr/libexec/cups/ |
101 |
filter/hpcups (PID 92258) |
102 |
I [11/Feb/2021:13:08:36 -0700] [Job 11] Started backend /usr/libexec/cups/ |
103 |
backend/smb (PID 92259) |
104 |
|
105 |
Although the CUPS back end on Athena is using SMB - as it should, the input |
106 |
filter is hpcups. |
107 |
|
108 |
Then on lines 461, 462 we have the outcome of using the wrong filter: |
109 |
|
110 |
D [11/Feb/2021:13:08:39 -0700] [Job 11] prnt/hpcups/HPCupsFilter.cpp 581: |
111 |
cupsRasterOpen failed, fd = 5 |
112 |
D [11/Feb/2021:13:08:39 -0700] [Job 11] PID 92258 (/usr/libexec/cups/filter/ |
113 |
hpcups) stopped with status 1. |
114 |
|
115 |
CUPS on athena can't use it and subsequently, the SMB connection fails too on |
116 |
lines 689, 690: |
117 |
|
118 |
E [11/Feb/2021:13:08:45 -0700] [Job 11] Connection failed: |
119 |
NT_STATUS_IO_TIMEOUT |
120 |
E [11/Feb/2021:13:08:45 -0700] [Job 11] SMB connection failed! |
121 |
|
122 |
|
123 |
I suggest you configure CUPS in Janus to use a different print driver: |
124 |
|
125 |
First try 'IPP everywhere' the latest /driverless/ printing option. With 'IPP |
126 |
everywhere' CUPS will communicate with IPP enabled printers and interrogate |
127 |
them on the fly to generate and use the requisite PPD capabilities |
128 |
configuration. |
129 |
|
130 |
If this doesn't work, then try 'RAW' and leave it to Athena's CUPS server to |
131 |
submit the raw data for printing to its back end (Windows Printer via SAMBA). |
132 |
|
133 |
The logs should indicate if there is a problem somewhere along the chain. |