On Thursday, 11 February 2021 20:32:47 GMT Dan Egli wrote: > On 2/11/2021 7:05 AM, Michael wrote: > > On Wednesday, 10 February 2021 23:03:18 GMT Dan Egli wrote: > >> On 2/10/2021 4:30 AM, Michael wrote: > >>> This is how I understand the printing process ought to work in your use > >>> case: > >>> > >>> The Samba server, Athena, will use the MSWindows Network Printer > >>> identified as "Windows Printer via SAMBA" in its CUPS GUI. > >>> > >>> Printing jobs will be submitted from Athena's CUPS to the MSWindows PC & > >>> its attached printer, via the corresponding smb:// URI. CUPS which will > >>> use the Samba server on Athena to authenticate and send the data for > >>> printing to the MSWindows PC and its shared printer. > >>> > >>> The same process will need to be followed by Janus; i.e. the CUPS server > >>> on Janus will have to use the same smb:// URI to submit the data to be > >>> printed to Athena's Samba server and as long as authentication is > >>> successful Athena will forward it to the Windows PC. > >> > >> Forgive me, but if I use the SAME url, then it's not Athena acting as > >> the print server, it's the windows client that the printer is hooked up > >> to. > > > > Sorry, I meant to say on Janus use the smb://Athena/<printer> URI and see > > if Athena then forwards the request via the shared Samba printer service > > onward to the MSWindows PC. Of course if you try to print directly to > > the MSWindows PC with smb://IRIS/<printer> it will work, just as it works > > from Athena - but that's not what you're after. > > That may work. I guess I'm just a bit worried about back and forth. i.e. > Janus tries to print, then Athena asks for permission to let it happen, > and that request goes right back to Janus. I'm VERY unfamiliar with AD > so I can't be 100% certain this will work. I can't see any reason why it > wouldn't, but that's not the same thing as saying there ISN'T a reason > why it wouldn't work.
The transaction for AD authentication to access the domain is taking place over different applications, threads, protocols and ports to those used for printing. There should be no confusion. [snip ...] > > The shared printer advertised by CUPS in Athena should pop up on > > Janus as an available printer via mDNS. > > I know nothing of mDNS. mDNS (multicast DNS) is a protocol used to resolve hostnames to IP addresses in LANs without the need to use a local DNS server. Client devices trying to resolve a name send UDP multicasts using port 5353 over the LAN subnet to ask for a named host to identify itself. The target host responds with its IP address and the client updates its mDNS cache. Linux, Apple and Windows 10 use mDNS to discover printers. If you see zeroconf, avahi, or Apple's Bonjour service, they are all referring to this mechanism. If you use IP addresses to manually configure printer server/clients, then this service is not necessary. Samba uses the native MSWindows 'Active Directory Domain Services' over TCP port 445 to resolve IP addresses when printing over Samba. > I tried IPP to no avail, but then again perhaps > I formed the URLs wrong. I tried ipp://athena/ipp/<PRINTER> and it > didn't work. I tried http/https mode too. That ALMOST worked. When you select the HTTP protocol it still sends IPP packets in MIME format. I'm not sure of the difference between the two - I guess IPP is native to CUPS and most/all printers. > But I get > an error on Janus saying "Filter Failed" and a lot of messages in my > error_log (debug mode) that really make no sense to me. Here's a > sample. I'll put the full log on my web server if you want to see it. > It's 77k nearly with debug turned on and that's only for trying to print > ONE test page and failing. The url is > https://www.newideatest.site/cups_error_log I had a quick look, this is what I see: Your client sends IPP commands over HTTP to Athena. CUPS server on Athena accepts these and processes them. So the comms appear to be working fine between the two. :-) Then we have this on line 292: D [11/Feb/2021:13:08:36 -0700] [Job 11] hpcups (application/vnd.cups-raster to printer/ENVY, cost 0) This is the hplip printer driver in action, using a MIME format for CUPS to transmit and print raster imaged pages. Question: Why is this driver in play? Even if the physical printer is an HP, it is neither connected to Janus, nor Athena. On lines 331 & 332: I [11/Feb/2021:13:08:36 -0700] [Job 11] Started filter /usr/libexec/cups/ filter/hpcups (PID 92258) I [11/Feb/2021:13:08:36 -0700] [Job 11] Started backend /usr/libexec/cups/ backend/smb (PID 92259) Although the CUPS back end on Athena is using SMB - as it should, the input filter is hpcups. Then on lines 461, 462 we have the outcome of using the wrong filter: D [11/Feb/2021:13:08:39 -0700] [Job 11] prnt/hpcups/HPCupsFilter.cpp 581: cupsRasterOpen failed, fd = 5 D [11/Feb/2021:13:08:39 -0700] [Job 11] PID 92258 (/usr/libexec/cups/filter/ hpcups) stopped with status 1. CUPS on athena can't use it and subsequently, the SMB connection fails too on lines 689, 690: E [11/Feb/2021:13:08:45 -0700] [Job 11] Connection failed: NT_STATUS_IO_TIMEOUT E [11/Feb/2021:13:08:45 -0700] [Job 11] SMB connection failed! I suggest you configure CUPS in Janus to use a different print driver: First try 'IPP everywhere' the latest /driverless/ printing option. With 'IPP everywhere' CUPS will communicate with IPP enabled printers and interrogate them on the fly to generate and use the requisite PPD capabilities configuration. If this doesn't work, then try 'RAW' and leave it to Athena's CUPS server to submit the raw data for printing to its back end (Windows Printer via SAMBA). The logs should indicate if there is a problem somewhere along the chain.
signature.asc
Description: This is a digitally signed message part.
