Re: [gentoo-user] Sharing printers via Cups

[Dan Egli]

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