On 2/10/2021 4:30 AM, Michael wrote:
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.
Seems that way to me. L)
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.
Yea, but due to the funky setup I have here, sending via IPP isn't going
to be an option. I tried that last night, and it completely refused to
work. So now I'm trying to go back to the Samba configuration.
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.
"... 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 ...]
zSimilarly, check the "hosts allow" directive in the Samba configuration to
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.
Kind of. More like printing from the windows host works, and printing
from Athena works. Printing from anywhere else does not.
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.
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. I tried to use the LPD to print to Athena and have Athena print to
the printer via Samba. That's where I was running into problems. I
suppose I can try IPP. I don't know of a smb:// url would work goinf
from Janus (or anyone else) to Athena. After all, the printer isn't
connected to Athena. It's connected to the windows 10 home PC. I suppose
IPP might work if I configure that. As far as listening on 631, Athena's
cups was ALREADY listening on that port because that's where the web
interface is. the url I use to manage the printers is
https://athena:631. I guess that somehow Cups can tell the difference
between https, http, and ipp all coming on the same port.
The Samba configuration on Athena will deal with the settings for sharing the
MSWindows printer.
Okay, so basically you're saying that Athena would connect via
smb://windows/<PRINTER> and that Janus or other computers would connect
via smb://Athena/<PRINTER>? Okay, that may work. I'll have to do a bit
of digging because Athena and Janus are actually connected to an AD
Domain run by samba. In fact, Janus is the DC while Athena is the
location of the files/printers to be shared in the domain.
--
Dan Egli
On my test server
