On Tuesday, 9 February 2021 19:23:41 GMT you wrote: > On 2/9/2021 3:20 AM, Michael wrote: > >> Actually tried that. Got LPD installed, sent a test page. Test page > >> appeared in the Windows Queue, then disappeared without any > >> acknowledgement from the printer. > > > > This would need some troubleshooting/configuring on the Windows end. It's > > a long time ago I tried this and don't recall what I had configured to > > allow clients to print via the Windows PC. It was relatively simple and > > lightweight though, unlike Samba which I wouldn't bother with just for > > printing. > > If it was JUST for printing I'd agree. But the whole samba setup is for > more than that. There's also file sharing (since Windows 10 home doesn't > support NFS), central authentication, things like that.
Ah! Fair enough. Since Samba is running you might as well use it for printing. > >> I finally got it working in samba mode > >> so I'm good with that. And that, again, would skip the whole point of > >> having a central print server. :) > > > > Not really. Athena would remain the CUPS server for itself and any Linux > > or additional OS clients, sending jobs over IPP:// to the Windows print > > server running on the Windows PC. > > Okay, I could see that one. Although I'm totally lost when it comes to > IPP. I've looked but apparently my google-fu is still weak because I > can't find any good documentation on how to setup IPP, how to format the > URLs, etc.... I have found IPP to be straight forward, simpler than other set ups and provided by most (all?) printers on port 631. Setting it up is explained in this section: https://wiki.gentoo.org/wiki/Printing#Installing_the_printer Something like 'ipp://192.168.10.2/ipp' should work - your printer's manual would confirm what it accepts. Anyway, this is not what you're after in your use case. > >>> 3. If the current setup is the right thing for you, increase CUPS log > >>> verbosity and check the logs on Athena to find out what it isn't happy > >>> with > >>> when Janus sends a print job to it. First check the CUPS driver and > >>> printing protocol is the same on Janus as on Athena and the CUPS' config > >>> on Athena allows inbound connections from your LAN, or your Janus' IP > >>> address. > >> > >> I can check on those. Thanks. I do notice one thing strange. Maybe a > >> cups bug. In the web interface when I created the printer in Athena, I > >> checked the box to say it was a shared printer. But when I look at the > >> status it says "not shared". OK, I just tested it here. I ticked to share *both* the CUPS server and a laser printer. The server setting is on the right hand side of the Administration page on the GUI and the printer on the left of the page. I observed the same result like you - although CUPS started listening on port 631 for connections from LAN clients, the GUI continued to show "not shared". NOTE: I did not test printing a page from a client to see if the display on the GUI changes to say "shared". It may be a real time indication of the status of the printer - or it could indeed be a bug. > > Hmm ... what follows the commented line: > > > > # Restrict access to the server... > > <Location /> > > Order Deny,Allow > > ... ? > > > > in the '/etc/cups/cupsd.conf' of Athena? > > Here's the entire file. Although I fail to see what the allow/deny could > mean for a printer showing on Athena. It's not that Janus says it's not > a shared printer. It's ATHENA saying it's not shared, right after I > checked the box to make it shared. Yes, you're right, the indication "not shared" won't change by ticking the box "shared" - I just wanted to confirm the actual configuration of the server was not restricting connections to CUPS for localhost only. However, it seems without having the same setup here, I may have given you a bum steer - my apologies: Reading the wiki page it states - https://wiki.gentoo.org/wiki/Printing#Remote_printer_access "... For other systems to use the printer through IPP, explicit access to the printer must be granted in the /etc/cups/cupsd.conf file. To share the printer using SAMBA, this change is not needed." I note you're using CIDR notation for the LAN subnet, while the wiki is using a "*" wildcard instead. I don't know if it makes a difference, but anyway since you'll be using a Samba shared printer this should not be relevant. [snip ...] > > Similarly, check the "hosts allow" directive in the Samba configuration to > > include Janus' IP address. > > Again, I think you're misunderstood the problem. Forget Janus for a > second. Forget Samba for a minute. I create a pinter via the CUPS web > interface on Athena. When it shows the box to make it shared, I check > the box. When I finish and the printer status appears, it says "not > shared". Other machines and other protocols have not even come into play > yet. I understood you were faced with two problems, really though, one only. Printing from Janus doesn't work. Printing from the other PCs works as intended. The "not shared" printer indication on CUPS GUI on Athena, should not be a problem affecting Janus' ability to print - I expect it is irrelevant. The Samba logs will hopefully indicate where the actual problem lies. 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. The Samba configuration on Athena will deal with the settings for sharing the MSWindows printer. HTH.
signature.asc
Description: This is a digitally signed message part.
