[gentoo-user] Sharing printers via Cups

[gentoo-user] Sharing printers via Cups

[Dan Egli]

Hey folks, I'm a bit lost on this, so I hope you can help me out.

I have a computer I want to act as the central print server for a 
network. It would spool all jobs for all printers, and send them out to 
the actual computers the printers are connected to, or to the printer 
itself in the event of a printer directly connected to the network. To 
start with, I have setup the server and added the printer connected to a 
Windows 10 Home computer to it. After a bit of work, I managed to get it 
so I can print a test page from cups and it comes out on the printer. 
But when I try to connect another computer to the printer via the print 
server, the other computer never sends it out. Just says the printer is 
busy.

How can I set this up correctly? To describe exactly what I'm trying to 
do, let's just use four computers in this example. A is the central 
print server. B is the windows client with the printer. C and D are 
linux machines. What I want is if either C or D print something, they 
both send it to A, and then A sends it to B.

Thanks!

Re: [gentoo-user] Sharing printers via Cups

[Wols Lists]

On 08/02/21 05:40, Dan Egli wrote:
> Hey folks, I'm a bit lost on this, so I hope you can help me out.

Dunno how much help I'll be ...
> 
> I have a computer I want to act as the central print server for a
> network. It would spool all jobs for all printers, and send them out to
> the actual computers the printers are connected to, or to the printer
> itself in the event of a printer directly connected to the network. To
> start with, I have setup the server and added the printer connected to a
> Windows 10 Home computer to it.

Is this wise? Windows 10 Home is rather castrated - networking is a PITA
because it assumes you won't ...

 After a bit of work, I managed to get it
> so I can print a test page from cups and it comes out on the printer.
> But when I try to connect another computer to the printer via the print
> server, the other computer never sends it out. Just says the printer is
> busy.

This is typical. In my linux setup, the printer is always busy. Stuff
still prints fine, though.
> 
> How can I set this up correctly? To describe exactly what I'm trying to
> do, let's just use four computers in this example. A is the central
> print server. B is the windows client with the printer. C and D are
> linux machines. What I want is if either C or D print something, they
> both send it to A, and then A sends it to B.
> 
I'd try moving the printer to A, or configuring C & D to print directly
to B. I dunno how you set up smbprint, but that should send straight to
a shared printer on B no problem.

Cheers,
Wol

Re: [gentoo-user] Sharing printers via Cups

[Dan Egli]

On 2/8/2021 2:14 AM, Wols Lists wrote:
>
> This is typical. In my linux setup, the printer is always busy. Stuff
> still prints fine, though.


Mine won't print. Says the printer is busy, and nothing else happens. It 
just sits there. Let me give better names because even I can get 
confused. So, we have three machines. Win10 Home = IRIS, Linux Server = 
Athena, Linux Workstation = Janus

If I print directly from Iris, it obviously works fine. If I print from 
Athena it works fine. If I print from Janus, it never goes anywhere.

>> How can I set this up correctly? To describe exactly what I'm trying to
>> do, let's just use four computers in this example. A is the central
>> print server. B is the windows client with the printer. C and D are
>> linux machines. What I want is if either C or D print something, they
>> both send it to A, and then A sends it to B.
>>
> I'd try moving the printer to A, or configuring C & D to print directly
> to B. I dunno how you set up smbprint, but that should send straight to
> a shared printer on B no problem.

Unfortunately, moving the printer is a no-go right now, for various 
reasons. Otherwise I'd just move it to be a network printer. The printer 
itself is designed to be network capable. But Iris is technically not MY 
Computer, and the printer isn't technically MINE either. They belong to 
someone else in the house, and I simply have permission to use them.  So 
my only two options are 1) Configure EVERYTHING to print to Iris. That's 
doable I suppose, but really not what I want, or B) Use Athena as a 
central print server just as it already acts as a central file server. 
That is FAR more preferable because then if something changes instead of 
updating EVERY computer I update ONE.

--
Dan Egli

Re: [gentoo-user] Sharing printers via Cups

[Michael]

[-- Attachment #1: Type: text/plain, Size: 2851 bytes --]

On Monday, 8 February 2021 19:08:11 GMT Dan Egli wrote:
> On 2/8/2021 2:14 AM, Wols Lists wrote:
> > This is typical. In my linux setup, the printer is always busy. Stuff
> > still prints fine, though.
> 
> Mine won't print. Says the printer is busy, and nothing else happens. It
> just sits there. Let me give better names because even I can get
> confused. So, we have three machines. Win10 Home = IRIS, Linux Server =
> Athena, Linux Workstation = Janus
> 
> If I print directly from Iris, it obviously works fine. If I print from
> Athena it works fine. If I print from Janus, it never goes anywhere.
> 
> >> How can I set this up correctly? To describe exactly what I'm trying to
> >> do, let's just use four computers in this example. A is the central
> >> print server. B is the windows client with the printer. C and D are
> >> linux machines. What I want is if either C or D print something, they
> >> both send it to A, and then A sends it to B.
> > 
> > I'd try moving the printer to A, or configuring C & D to print directly
> > to B. I dunno how you set up smbprint, but that should send straight to
> > a shared printer on B no problem.
> 
> Unfortunately, moving the printer is a no-go right now, for various
> reasons. Otherwise I'd just move it to be a network printer. The printer
> itself is designed to be network capable. But Iris is technically not MY
> Computer, and the printer isn't technically MINE either. They belong to
> someone else in the house, and I simply have permission to use them.  So
> my only two options are 1) Configure EVERYTHING to print to Iris. That's
> doable I suppose, but really not what I want, or B) Use Athena as a
> central print server just as it already acts as a central file server.
> That is FAR more preferable because then if something changes instead of
> updating EVERY computer I update ONE.
> 
> --
> Dan Egli

Some ideas:

1. If the printer is network capable, why don't you connect it to the router 
and they it will accessible directly by all devices over the LAN, irrespective 
of their OSs?

2. Last time I set up a Windows XP as a printer-server, I installed-enabled 
Unix Print Service Windows Component (really an LPD/LPR service).  Then Linux 
PCs were able to print directly to it.  No need to configure SMB and what not, 
just for printing.  This randomly selected article describes the principle:

https://support.printmanager.com/hc/en-us/articles/202835449-Linux-printing-via-the-Windows-Print-Server-
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.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] Sharing printers via Cups

[Dan Egli]

On 2/8/2021 5:01 PM, Michael wrote:
> On Monday, 8 February 2021 19:08:11 GMT Dan Egli wrote:
>> On 2/8/2021 2:14 AM, Wols Lists wrote:
>>> This is typical. In my linux setup, the printer is always busy. Stuff
>>> still prints fine, though.
>> Mine won't print. Says the printer is busy, and nothing else happens. It
>> just sits there. Let me give better names because even I can get
>> confused. So, we have three machines. Win10 Home = IRIS, Linux Server =
>> Athena, Linux Workstation = Janus
>>
>> If I print directly from Iris, it obviously works fine. If I print from
>> Athena it works fine. If I print from Janus, it never goes anywhere.
>>
>>>> How can I set this up correctly? To describe exactly what I'm trying to
>>>> do, let's just use four computers in this example. A is the central
>>>> print server. B is the windows client with the printer. C and D are
>>>> linux machines. What I want is if either C or D print something, they
>>>> both send it to A, and then A sends it to B.
>>> I'd try moving the printer to A, or configuring C & D to print directly
>>> to B. I dunno how you set up smbprint, but that should send straight to
>>> a shared printer on B no problem.
>> Unfortunately, moving the printer is a no-go right now, for various
>> reasons. Otherwise I'd just move it to be a network printer. The printer
>> itself is designed to be network capable. But Iris is technically not MY
>> Computer, and the printer isn't technically MINE either. They belong to
>> someone else in the house, and I simply have permission to use them.  So
>> my only two options are 1) Configure EVERYTHING to print to Iris. That's
>> doable I suppose, but really not what I want, or B) Use Athena as a
>> central print server just as it already acts as a central file server.
>> That is FAR more preferable because then if something changes instead of
>> updating EVERY computer I update ONE.
>>
>> --
>> Dan Egli
> Some ideas:
>
> 1. If the printer is network capable, why don't you connect it to the router
> and they it will accessible directly by all devices over the LAN, irrespective
> of their OSs?
>
Like I said, not my printer or my computer. I just have permission to 
USE them. So making a config change like that is out. Besides, that 
defeats the point I made at the end of what you quoted above. "That is 
FAR more preferable because then if something changes instead updating 
EVERY computer I update ONE.

> 2. Last time I set up a Windows XP as a printer-server, I installed-enabled
> Unix Print Service Windows Component (really an LPD/LPR service).  Then Linux
> PCs were able to print directly to it.  No need to configure SMB and what not,
> just for printing.  This randomly selected article describes the principle:
>
> https://support.printmanager.com/hc/en-us/articles/202835449-Linux-printing-via-the-Windows-Print-Server-

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. 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. :)


> 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".


-- 
Dan Egli
On my test server

Re: [gentoo-user] Sharing printers via Cups

[Michael]

[-- Attachment #1: Type: text/plain, Size: 4267 bytes --]

On Tuesday, 9 February 2021 00:59:01 GMT Dan Egli wrote:
> On 2/8/2021 5:01 PM, Michael wrote:
> > On Monday, 8 February 2021 19:08:11 GMT Dan Egli wrote:
> >> On 2/8/2021 2:14 AM, Wols Lists wrote:
> >>> This is typical. In my linux setup, the printer is always busy. Stuff
> >>> still prints fine, though.
> >> 
> >> Mine won't print. Says the printer is busy, and nothing else happens. It
> >> just sits there. Let me give better names because even I can get
> >> confused. So, we have three machines. Win10 Home = IRIS, Linux Server =
> >> Athena, Linux Workstation = Janus
> >> 
> >> If I print directly from Iris, it obviously works fine. If I print from
> >> Athena it works fine. If I print from Janus, it never goes anywhere.
> >> 
> >>>> How can I set this up correctly? To describe exactly what I'm trying to
> >>>> do, let's just use four computers in this example. A is the central
> >>>> print server. B is the windows client with the printer. C and D are
> >>>> linux machines. What I want is if either C or D print something, they
> >>>> both send it to A, and then A sends it to B.
> >>> 
> >>> I'd try moving the printer to A, or configuring C & D to print directly
> >>> to B. I dunno how you set up smbprint, but that should send straight to
> >>> a shared printer on B no problem.
> >> 
> >> Unfortunately, moving the printer is a no-go right now, for various
> >> reasons. Otherwise I'd just move it to be a network printer. The printer
> >> itself is designed to be network capable. But Iris is technically not MY
> >> Computer, and the printer isn't technically MINE either. They belong to
> >> someone else in the house, and I simply have permission to use them.  So
> >> my only two options are 1) Configure EVERYTHING to print to Iris. That's
> >> doable I suppose, but really not what I want, or B) Use Athena as a
> >> central print server just as it already acts as a central file server.
> >> That is FAR more preferable because then if something changes instead of
> >> updating EVERY computer I update ONE.
> >> 
> >> --
> >> Dan Egli
> > 
> > Some ideas:

[snip ...]

> > 2. Last time I set up a Windows XP as a printer-server, I
> > installed-enabled
> > Unix Print Service Windows Component (really an LPD/LPR service).  Then
> > Linux PCs were able to print directly to it.  No need to configure SMB
> > and what not, just for printing.  This randomly selected article
> > describes the principle:
> > 
> > https://support.printmanager.com/hc/en-us/articles/202835449-Linux-printin
> > g-via-the-Windows-Print-Server-
>
> 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.


> 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.


> > 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".

Hmm ... what follows the commented line:

# Restrict access to the server...
<Location />
Order Deny,Allow
... ?

in the '/etc/cups/cupsd.conf' of Athena?

Similarly, check the "hosts allow" directive in the Samba configuration to 
include Janus' IP address.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] Sharing printers via Cups

[Dan Egli]

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.
>
>> 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....
>>> 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".
> 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.

# Configuration file for the CUPS scheduler.  See "man cupsd.conf" for a
# complete description of this file.
#

# Log general information in error_log - change "warn" to "debug"
# for troubleshooting...
LogLevel debug
PageLogFormat

# Only listen for connections from the local machine.
Listen 192.168.10.2:631
Listen /run/cups/cups.sock

# Show shared printers on the local network.
Browsing On
BrowseLocalProtocols

# Default authentication type, when authentication is required...
DefaultAuthType Basic

# Web interface setting...
WebInterface Yes

# Restrict access to the server...
<Location />
   Order allow,deny
   allow 192.168.10.0/24
</Location>

# Restrict access to the admin pages...
<Location /admin>
   Order allow,deny
   allow 192.168.10.0/24
</Location>

# Restrict access to configuration files...
<Location /admin/conf>
   AuthType Default
   Require user @SYSTEM
   Order allow,deny
</Location>

# Restrict access to log files...
<Location /admin/log>
   AuthType Default
   Require user @SYSTEM
   Order allow,deny
</Location>

# Set the default printer/job policies...
<Policy default>
   # Job/subscription privacy...
   JobPrivateAccess default
   JobPrivateValues default
   SubscriptionPrivateAccess default
   SubscriptionPrivateValues default

   # Job-related operations must be done by the owner or an administrator...
   <Limit Create-Job Print-Job Print-URI Validate-Job>
     Order deny,allow
     Allow 192.168.10.0/24
   </Limit>

   <Limit Send-Document Send-URI Hold-Job Release-Job Restart-Job 
Purge-Jobs Set-Job-Attributes Create-Job-Subscription Renew-Subscription 
Cancel-Subscription Get-Notifications Reprocess-Job Cancel-Current-Job 
Suspend-Current-Job Resume-Job Cancel-My-Jobs Close-Job CUPS-Move-Job 
CUPS-Get-Document>
     Require user @OWNER @SYSTEM
     Order deny,allow
   </Limit>

   # All administration operations require an administrator to 
authenticate...
   <Limit CUPS-Add-Modify-Printer CUPS-Delete-Printer 
CUPS-Add-Modify-Class CUPS-Delete-Class CUPS-Set-Default CUPS-Get-Devices>
     AuthType Default
     Require user @SYSTEM
     Order deny,allow
   </Limit>

   # All printer operations require a printer operator to authenticate...
   <Limit Pause-Printer Resume-Printer Enable-Printer Disable-Printer 
Pause-Printer-After-Current-Job Hold-New-Jobs Release-Held-New-Jobs 
Deactivate-Printer Activate-Printer Restart-Printer Shutdown-Printer 
Startup-Printer Promote-Job Schedule-Job-After Cancel-Jobs 
CUPS-Accept-Jobs CUPS-Reject-Jobs>
     AuthType Default
     Require user @SYSTEM
     Order deny,allow
   </Limit>

   # Only the owner or an administrator can cancel or authenticate a job...
   <Limit Cancel-Job CUPS-Authenticate-Job>
     Require user @OWNER @SYSTEM
     Order deny,allow
   </Limit>

   <Limit All>
     Order deny,allow
   </Limit>
</Policy>

# Set the authenticated printer/job policies...
<Policy authenticated>
   # Job/subscription privacy...
   JobPrivateAccess default
   JobPrivateValues default
   SubscriptionPrivateAccess default
   SubscriptionPrivateValues default

   # Job-related operations must be done by the owner or an administrator...
   <Limit Create-Job Print-Job Print-URI Validate-Job>
     AuthType Default
     Order deny,allow
   </Limit>

   <Limit Send-Document Send-URI Hold-Job Release-Job Restart-Job 
Purge-Jobs Set-Job-Attributes Create-Job-Subscription Renew-Subscription 
Cancel-Subscription Get-Notifications Reprocess-Job Cancel-Current-Job 
Suspend-Current-Job Resume-Job Cancel-My-Jobs Close-Job CUPS-Move-Job 
CUPS-Get-Document>
     AuthType Default
     Require user @OWNER @SYSTEM
     Order deny,allow
   </Limit>

   # All administration operations require an administrator to 
authenticate...
   <Limit CUPS-Add-Modify-Printer CUPS-Delete-Printer 
CUPS-Add-Modify-Class CUPS-Delete-Class CUPS-Set-Default>
     AuthType Default
     Require user @SYSTEM
     Order deny,allow
   </Limit>

   # All printer operations require a printer operator to authenticate...
   <Limit Pause-Printer Resume-Printer Enable-Printer Disable-Printer 
Pause-Printer-After-Current-Job Hold-New-Jobs Release-Held-New-Jobs 
Deactivate-Printer Activate-Printer Restart-Printer Shutdown-Printer 
Startup-Printer Promote-Job Schedule-Job-After Cancel-Jobs 
CUPS-Accept-Jobs CUPS-Reject-Jobs>
     AuthType Default
     Require user @SYSTEM
     Order deny,allow
   </Limit>

   # Only the owner or an administrator can cancel or authenticate a job...
   <Limit Cancel-Job CUPS-Authenticate-Job>
     AuthType Default
     Require user @OWNER @SYSTEM
     Order deny,allow
   </Limit>

   <Limit All>
     Order deny,allow
   </Limit>
</Policy>

# Set the kerberized printer/job policies...
<Policy kerberos>
   # Job/subscription privacy...
   JobPrivateAccess default
   JobPrivateValues default
   SubscriptionPrivateAccess default
   SubscriptionPrivateValues default

   # Job-related operations must be done by the owner or an administrator...
   <Limit Create-Job Print-Job Print-URI Validate-Job>
     AuthType Negotiate
     Order deny,allow
   </Limit>

   <Limit Send-Document Send-URI Hold-Job Release-Job Restart-Job 
Purge-Jobs Set-Job-Attributes Create-Job-Subscription Renew-Subscription 
Cancel-Subscription Get-Notifications Reprocess-Job Cancel-Current-Job 
Suspend-Current-Job Resume-Job Cancel-My-Jobs Close-Job CUPS-Move-Job 
CUPS-Get-Document>
     AuthType Negotiate
     Require user @OWNER @SYSTEM
     Order deny,allow
   </Limit>

   # All administration operations require an administrator to 
authenticate...
   <Limit CUPS-Add-Modify-Printer CUPS-Delete-Printer 
CUPS-Add-Modify-Class CUPS-Delete-Class CUPS-Set-Default>
     AuthType Default
     Require user @SYSTEM
     Order deny,allow
   </Limit>

   # All printer operations require a printer operator to authenticate...
   <Limit Pause-Printer Resume-Printer Enable-Printer Disable-Printer 
Pause-Printer-After-Current-Job Hold-New-Jobs Release-Held-New-Jobs 
Deactivate-Printer Activate-Printer Restart-Printer Shutdown-Printer 
Startup-Printer Promote-Job Schedule-Job-After Cancel-Jobs 
CUPS-Accept-Jobs CUPS-Reject-Jobs>
     AuthType Default
     Require user @SYSTEM
     Order deny,allow
   </Limit>

   # Only the owner or an administrator can cancel or authenticate a job...
   <Limit Cancel-Job CUPS-Authenticate-Job>
     AuthType Negotiate
     Require user @OWNER @SYSTEM
     Order deny,allow
   </Limit>

   <Limit All>
     Order deny,allow
   </Limit>
</Policy>

> 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.

-- 
Dan Egli
On my test server

Re: [gentoo-user] Sharing printers via Cups

[Michael]

[-- Attachment #1: Type: text/plain, Size: 6152 bytes --]

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.


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[gentoo-user] Re: Sharing printers via Cups

[Grant Edwards]

On 2021-02-10, Dan Egli <dan@newideatest.site> wrote:
> 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
[...]
> 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.

I think I probably would have just bought a printer long before this
point...

--
Grant

Re: [gentoo-user] Re: Sharing printers via Cups

[Dan Egli]

On 2/10/2021 4:44 PM, Grant Edwards wrote:
>
> I think I probably would have just bought a printer long before this
> point...
>

I guess you have money. As the old joke saying goes "I'm so broke I 
can't afford to pay attention."

Fact is, though, that a new printer would solve nothing because at the 
moment all that I'm doing is in VMWare on the Win 10 box that I stated 
before is not mine but I have permission to use. I'm trying to get it 
all set for eventual transfer to real computers. And the issue I am 
facing is an issue I'd face no matter what. I am _NOT_ buying a printer 
for each computer that will be there. So it's a matter of having a 
printer connected to one computer and having the others connect to that 
first server. Great. That's just what I'm trying to accomplish!

I even tried sending the job via HTTP and HTTPS. At that point the logs 
on Athena show a LOT of output like this:

D [10/Feb/2021:17:44:46 -0700] [Client 77] Server address is "192.168.10.2".
D [10/Feb/2021:17:44:46 -0700] [Client 77] Accepted from 
192.168.10.3:35684 (IPv4)
D [10/Feb/2021:17:44:46 -0700] [Client 77] Waiting for request.
D [10/Feb/2021:17:44:46 -0700] [Client 77] POST /printers/ENVY HTTP/1.1
D [10/Feb/2021:17:44:46 -0700] cupsdSetBusyState: newbusy="Active 
clients", busy="Active clients"
D [10/Feb/2021:17:44:46 -0700] [Client 77] Read: status=200, state=6
D [10/Feb/2021:17:44:46 -0700] [Client 77] No authentication data provided.
D [10/Feb/2021:17:44:46 -0700] [Client 77] 2.0 Get-Job-Attributes 132
D [10/Feb/2021:17:44:46 -0700] Get-Job-Attributes 
http://athena:631/printers/ENVY
D [10/Feb/2021:17:44:46 -0700] [Client 77] Returning IPP successful-ok 
for Get-Job-Attributes (http://athena:631/printers/ENVY) from 192.168.10.3.
D [10/Feb/2021:17:44:46 -0700] [Client 77] Content-Length: 284
D [10/Feb/2021:17:44:46 -0700] [Client 77] cupsdSendHeader: code=200, 
type="application/ipp", auth_type=0
D [10/Feb/2021:17:44:46 -0700] [Client 77] con->http=0x561443dbc990
D [10/Feb/2021:17:44:46 -0700] [Client 77] cupsdWriteClient error=0, 
used=0, state=HTTP_STATE_POST_SEND, data_encoding=HTTP_ENCODING_LENGTH, 
data_remaining=284, response=0x561443df8940(IPP_STATE_DATA), pipe_pid=0, 
file=-1
D [10/Feb/2021:17:44:46 -0700] [Client 77] Writing IPP response, 
ipp_state=IPP_STATE_DATA, old wused=0, new wused=0
D [10/Feb/2021:17:44:46 -0700] [Client 77] bytes=0, http_state=0, 
data_remaining=284
D [10/Feb/2021:17:44:46 -0700] [Client 77] Flushing write buffer.
D [10/Feb/2021:17:44:46 -0700] [Client 77] New state is HTTP_STATE_WAITING
D [10/Feb/2021:17:44:46 -0700] [Client 77] Waiting for request.
D [10/Feb/2021:17:44:46 -0700] cupsdSetBusyState: newbusy="Not busy", 
busy="Active clients"
D [10/Feb/2021:17:44:47 -0700] [Client 77] POST /printers/ENVY HTTP/1.1
D [10/Feb/2021:17:44:47 -0700] cupsdSetBusyState: newbusy="Active 
clients", busy="Not busy"
D [10/Feb/2021:17:44:47 -0700] [Client 77] Read: status=200, state=6
D [10/Feb/2021:17:44:47 -0700] [Client 77] No authentication data provided.
D [10/Feb/2021:17:44:47 -0700] [Client 77] 2.0 Get-Printer-Attributes 133
D [10/Feb/2021:17:44:47 -0700] Get-Printer-Attributes 
http://athena:631/printers/ENVY
D [10/Feb/2021:17:44:47 -0700] [Client 77] Returning IPP successful-ok 
for Get-Printer-Attributes (http://athena:631/printers/ENVY) from 
192.168.10.3.
D [10/Feb/2021:17:44:47 -0700] [Client 77] Content-Length: 1853
D [10/Feb/2021:17:44:47 -0700] [Client 77] cupsdSendHeader: code=200, 
type="application/ipp", auth_type=0
D [10/Feb/2021:17:44:47 -0700] [Client 77] con->http=0x561443dbc990
D [10/Feb/2021:17:44:47 -0700] [Client 77] cupsdWriteClient error=0, 
used=0, state=HTTP_STATE_POST_SEND, data_encoding=HTTP_ENCODING_LENGTH, 
data_remaining=1853, response=0x561443de64a0(IPP_STATE_DATA), 
pipe_pid=0, file=-1
D [10/Feb/2021:17:44:47 -0700] [Client 77] Writing IPP response, 
ipp_state=IPP_STATE_DATA, old wused=0, new wused=0
D [10/Feb/2021:17:44:47 -0700] [Client 77] bytes=0, http_state=0, 
data_remaining=1853
D [10/Feb/2021:17:44:47 -0700] [Client 77] Flushing write buffer.
D [10/Feb/2021:17:44:47 -0700] [Client 77] New state is HTTP_STATE_WAITING
D [10/Feb/2021:17:44:47 -0700] [Client 77] Waiting for request.
D [10/Feb/2021:17:44:47 -0700] cupsdSetBusyState: newbusy="Not busy", 
busy="Active clients"
D [10/Feb/2021:17:44:47 -0700] [Client 77] HTTP_STATE_WAITING Closing 
for error 32 (Broken pipe)
D [10/Feb/2021:17:44:47 -0700] [Client 77] Closing connection.

-- 
Dan Egli
On my test server

Re: [gentoo-user] Sharing printers via Cups

[Michael]

[-- Attachment #1: Type: text/plain, Size: 4381 bytes --]

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.


> 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 ports listened to by CUPS are as follows:

https://www.cups.org/doc/firewalls.html

When the printer URI used is http, then the MIME type used by IPP will be 
"application/ipp" to transact printing commands.  A browser will access the 
admin GUI over http also on port 631.

LPD/LPR is limited in functionality and deprecated, although if it could be 
made to work for now there'd be no argument against using it.  ;-)

IPP is well supported, however, without trying it out I wouldn't know if it 
will work in your particular use case.  In theory a shared CUPS server on 
Athena, plus its shared printer, should allow Janus to submit print jobs to 
it.  The shared printer advertised by CUPS in Athena should pop up on Janus as 
an available printer via mDNS.


> > 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.

Yes, under this configuration scenario the printing service served by Samba on 
Athena is a shared Windows printer and would be accessed via the smb:// 
protocol.  So, the Janus CUPS server will connect to the printer service 
provided by the Samba server on Athena.  Again, without trying it out and 
troubleshooting it I wouldn't know if it'd 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.

As long as Janus (the Samba client) is authenticated to use Samba services 
being served by Athena, it /should/ work.  You would need to configure 
firewalls accordingly to keep ports available, if you have firewalls enabled.

Grant's comment about buying a printer is opportune, depending on the value of 
(your) time.  The cost of printers and especially 2nd hand printers with so 
many companies going bust, should approximate zero.  The expense of running a 
printer is in the overinflated ink price, which is a multiple of the upfront 
cost of buying the device.

On the other hand, if cashflow itself is zero, options are understandably 
limited.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] Sharing printers via Cups

[Dan Egli]

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.
>> 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 ports listened to by CUPS are as follows:
>
> https://www.cups.org/doc/firewalls.html
>
> When the printer URI used is http, then the MIME type used by IPP will be
> "application/ipp" to transact printing commands.  A browser will access the
> admin GUI over http also on port 631.
>
> LPD/LPR is limited in functionality and deprecated, although if it could be
> made to work for now there'd be no argument against using it.  ;-)
>
> IPP is well supported, however, without trying it out I wouldn't know if it
> will work in your particular use case.  In theory a shared CUPS server on
> Athena, plus its shared printer, should allow Janus to submit print jobs to
> it.  The shared printer advertised by CUPS in Athena should pop up on Janus as
> an available printer via mDNS.
>
I know nothing of mDNS. 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. 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

---- CUT HERE ----
D [11/Feb/2021:13:08:33 -0700] [Client 1] Server address is "192.168.10.2".
D [11/Feb/2021:13:08:33 -0700] [Client 1] Accepted from 
192.168.10.3:38830 (IPv4)
D [11/Feb/2021:13:08:33 -0700] [Client 1] Waiting for request.
D [11/Feb/2021:13:08:33 -0700] [Client 1] POST /printers/ENVY HTTP/1.1
D [11/Feb/2021:13:08:33 -0700] [Client 1] Read: status=200, state=6
D [11/Feb/2021:13:08:33 -0700] [Client 1] No authentication data provided.
D [11/Feb/2021:13:08:33 -0700] [Client 1] 2.0 Get-Printer-Attributes 1
D [11/Feb/2021:13:08:33 -0700] [Client 1] Returning IPP successful-ok 
for Get-Printer-Attributes (http://athena:631/printers/ENVY) from 
192.168.10.3.
D [11/Feb/2021:13:08:33 -0700] [Client 1] Content-Length: 1840
D [11/Feb/2021:13:08:33 -0700] [Client 1] cupsdSendHeader: code=200, 
type="application/ipp", auth_type=0
D [11/Feb/2021:13:08:33 -0700] [Client 1] con->http=0x5642ebffaad0
D [11/Feb/2021:13:08:33 -0700] [Client 1] cupsdWriteClient error=0, 
used=0, state=HTTP_STATE_POST_SEND, data_encoding=HTTP_ENCODING_LENGTH, 
data_remaining=1840, response=0x5642ebfda600(IPP_STATE_DATA), 
pipe_pid=0, file=-1
D [11/Feb/2021:13:08:33 -0700] [Client 1] Writing IPP response, 
ipp_state=IPP_STATE_DATA, old wused=0, new wused=0
D [11/Feb/2021:13:08:33 -0700] [Client 1] bytes=0, http_state=0, 
data_remaining=1840
D [11/Feb/2021:13:08:33 -0700] [Client 1] Flushing write buffer.
D [11/Feb/2021:13:08:33 -0700] [Client 1] New state is HTTP_STATE_WAITING
D [11/Feb/2021:13:08:33 -0700] [Client 1] Waiting for request.
D [11/Feb/2021:13:08:33 -0700] [Client 1] POST /printers/ENVY HTTP/1.1
D [11/Feb/2021:13:08:33 -0700] [Client 1] Read: status=200, state=6
D [11/Feb/2021:13:08:33 -0700] [Client 1] No authentication data provided.
D [11/Feb/2021:13:08:33 -0700] [Client 1] 2.0 Validate-Job 2
D [11/Feb/2021:13:08:33 -0700] [Client 1] Returning IPP successful-ok 
for Validate-Job (http://athena:631/printers/ENVY) from 192.168.10.3.
D [11/Feb/2021:13:08:33 -0700] [Client 1] Content-Length: 75
D [11/Feb/2021:13:08:33 -0700] [Client 1] cupsdSendHeader: code=200, 
type="application/ipp", auth_type=0
D [11/Feb/2021:13:08:33 -0700] [Client 1] con->http=0x5642ebffaad0
D [11/Feb/2021:13:08:33 -0700] [Client 1] cupsdWriteClient error=0, 
used=0, state=HTTP_STATE_POST_SEND, data_encoding=HTTP_ENCODING_LENGTH, 
data_remaining=75, response=0x5642ebfda720(IPP_STATE_DATA), pipe_pid=0, 
file=-1
D [11/Feb/2021:13:08:33 -0700] [Client 1] Writing IPP response, 
ipp_state=IPP_STATE_DATA, old wused=0, new wused=0
D [11/Feb/2021:13:08:33 -0700] [Client 1] bytes=0, http_state=0, 
data_remaining=75
D [11/Feb/2021:13:08:33 -0700] [Client 1] Flushing write buffer.
D [11/Feb/2021:13:08:33 -0700] [Client 1] New state is HTTP_STATE_WAITING
D [11/Feb/2021:13:08:33 -0700] [Client 1] Waiting for request.
D [11/Feb/2021:13:08:33 -0700] [Client 1] POST /printers/ENVY HTTP/1.1
D [11/Feb/2021:13:08:33 -0700] [Client 1] Read: status=200, state=6
D [11/Feb/2021:13:08:33 -0700] [Client 1] No authentication data provided.
D [11/Feb/2021:13:08:33 -0700] [Client 1] 2.0 Create-Job 4
D [11/Feb/2021:13:08:33 -0700] [Client 1] Returning IPP successful-ok 
for Create-Job (http://athena:631/printers/ENVY) from 192.168.10.3.
D [11/Feb/2021:13:08:33 -0700] [Client 1] Content-Length: 201
D [11/Feb/2021:13:08:33 -0700] [Client 1] cupsdSendHeader: code=200, 
type="application/ipp", auth_type=0
D [11/Feb/2021:13:08:33 -0700] [Client 1] con->http=0x5642ebffaad0
D [11/Feb/2021:13:08:33 -0700] [Client 1] cupsdWriteClient error=0, 
used=0, state=HTTP_STATE_POST_SEND, data_encoding=HTTP_ENCODING_LENGTH, 
data_remaining=201, response=0x5642ebfda680(IPP_STATE_IDLE), pipe_pid=0, 
file=-1
D [11/Feb/2021:13:08:33 -0700] [Client 1] Writing IPP response, 
ipp_state=IPP_STATE_DATA, old wused=0, new wused=0
D [11/Feb/2021:13:08:33 -0700] [Client 1] bytes=0, http_state=0, 
data_remaining=201
D [11/Feb/2021:13:08:33 -0700] [Client 1] Flushing write buffer.
D [11/Feb/2021:13:08:33 -0700] [Client 1] New state is HTTP_STATE_WAITING
D [11/Feb/2021:13:08:33 -0700] [Client 1] Waiting for request.
D [11/Feb/2021:13:08:33 -0700] [Client 1] POST /printers/ENVY HTTP/1.1
D [11/Feb/2021:13:08:33 -0700] [Client 1] Read: status=200, state=6
D [11/Feb/2021:13:08:33 -0700] [Client 1] No authentication data provided.
D [11/Feb/2021:13:08:33 -0700] [Client 1] 2.0 Send-Document 5
D [11/Feb/2021:13:08:34 -0700] [Client 1] Read: status=100, state=6
D [11/Feb/2021:13:08:34 -0700] [Client 1] Read: status=100, state=6
D [11/Feb/2021:13:08:34 -0700] [Client 1] Read: status=100, state=6
D [11/Feb/2021:13:08:34 -0700] [Client 1] Read: status=100, state=6
D [11/Feb/2021:13:08:34 -0700] [Client 1] Read: status=100, state=6
D [11/Feb/2021:13:08:34 -0700] [Client 1] Read: status=100, state=6
D [11/Feb/2021:13:08:34 -0700] [Client 1] Read: status=100, state=6
D [11/Feb/2021:13:08:34 -0700] [Client 1] Read: status=100, state=6
D [11/Feb/2021:13:08:34 -0700] [Client 1] Read: status=100, state=6
D [11/Feb/2021:13:08:34 -0700] [Client 1] Read: status=100, state=6
D [11/Feb/2021:13:08:34 -0700] [Client 1] Read: status=100, state=6
D [11/Feb/2021:13:08:34 -0700] [Client 1] Read: status=100, state=6
D [11/Feb/2021:13:08:34 -0700] [Client 1] Read: status=100, state=6
D [11/Feb/2021:13:08:34 -0700] [Client 1] Read: status=100, state=6
D [11/Feb/2021:13:08:34 -0700] [Client 1] Read: status=100, state=6
D [11/Feb/2021:13:08:34 -0700] [Client 1] Read: status=100, state=6
D [11/Feb/2021:13:08:34 -0700] [Client 1] Read: status=100, state=6
D [11/Feb/2021:13:08:34 -0700] [Client 1] Read: status=100, state=6
D [11/Feb/2021:13:08:34 -0700] [Client 1] Read: status=100, state=6
D [11/Feb/2021:13:08:34 -0700] [Client 1] Read: status=100, state=6
D [11/Feb/2021:13:08:34 -0700] [Client 1] Read: status=100, state=6
D [11/Feb/2021:13:08:34 -0700] [Client 1] Read: status=100, state=6
D [11/Feb/2021:13:08:34 -0700] [Client 1] Read: status=100, state=6
D [11/Feb/2021:13:08:34 -0700] [Client 1] Read: status=100, state=6
D [11/Feb/2021:13:08:34 -0700] [Client 1] Read: status=100, state=6
D [11/Feb/2021:13:08:34 -0700] [Client 1] Read: status=100, state=6
D [11/Feb/2021:13:08:34 -0700] [Client 1] Read: status=100, state=6
D [11/Feb/2021:13:08:34 -0700] [Client 1] Read: status=100, state=6
D [11/Feb/2021:13:08:34 -0700] [Client 1] Read: status=100, state=6
D [11/Feb/2021:13:08:34 -0700] [Client 1] Read: status=100, state=6
D [11/Feb/2021:13:08:35 -0700] [Client 1] Read: status=100, state=6
D [11/Feb/2021:13:08:35 -0700] [Client 1] Read: status=100, state=6
D [11/Feb/2021:13:08:35 -0700] [Client 1] Read: status=100, state=6
D [11/Feb/2021:13:08:35 -0700] [Client 1] Read: status=100, state=6
D [11/Feb/2021:13:08:35 -0700] [Client 1] Read: status=100, state=6
D [11/Feb/2021:13:08:35 -0700] [Client 1] Read: status=100, state=6
D [11/Feb/2021:13:08:35 -0700] [Client 1] Read: status=100, state=6
D [11/Feb/2021:13:08:35 -0700] [Client 1] Read: status=100, state=6
D [11/Feb/2021:13:08:35 -0700] [Client 1] Read: status=100, state=6
D [11/Feb/2021:13:08:35 -0700] [Client 1] Read: status=100, state=6
D [11/Feb/2021:13:08:35 -0700] [Client 1] Read: status=100, state=6
D [11/Feb/2021:13:08:35 -0700] [Client 1] Read: status=100, state=6
D [11/Feb/2021:13:08:35 -0700] [Client 1] Read: status=100, state=6
D [11/Feb/2021:13:08:35 -0700] [Client 1] Read: status=100, state=6
D [11/Feb/2021:13:08:35 -0700] [Client 1] Read: status=100, state=6
D [11/Feb/2021:13:08:35 -0700] [Client 1] Read: status=100, state=6
D [11/Feb/2021:13:08:35 -0700] [Client 1] Read: status=100, state=6
D [11/Feb/2021:13:08:35 -0700] [Client 1] Read: status=100, state=6
D [11/Feb/2021:13:08:36 -0700] [Client 1] Read: status=100, state=6
D [11/Feb/2021:13:08:36 -0700] [Client 1] Read: status=100, state=6
D [11/Feb/2021:13:08:36 -0700] [Client 1] Read: status=100, state=6
D [11/Feb/2021:13:08:36 -0700] [Client 1] Read: status=100, state=6
D [11/Feb/2021:13:08:36 -0700] [Client 1] Read: status=100, state=6
D [11/Feb/2021:13:08:36 -0700] [Client 1] Returning IPP successful-ok 
for Send-Document (http://athena:631/printers/ENVY) from 192.168.10.3.
D [11/Feb/2021:13:08:36 -0700] [Client 1] Content-Length: 171
D [11/Feb/2021:13:08:36 -0700] [Client 1] cupsdSendHeader: code=200, 
type="application/ipp", auth_type=0
D [11/Feb/2021:13:08:36 -0700] [Client 1] con->http=0x5642ebffaad0
D [11/Feb/2021:13:08:36 -0700] [Client 1] cupsdWriteClient error=0, 
used=0, state=HTTP_STATE_POST_SEND, data_encoding=HTTP_ENCODING_LENGTH, 
data_remaining=171, response=0x5642ebfdadd0(IPP_STATE_DATA), pipe_pid=0, 
file=-1
D [11/Feb/2021:13:08:36 -0700] [Client 1] Writing IPP response, 
ipp_state=IPP_STATE_DATA, old wused=0, new wused=0
D [11/Feb/2021:13:08:36 -0700] [Client 1] bytes=0, http_state=0, 
data_remaining=171
D [11/Feb/2021:13:08:36 -0700] [Client 1] Flushing write buffer.
D [11/Feb/2021:13:08:36 -0700] [Client 1] New state is HTTP_STATE_WAITING
D [11/Feb/2021:13:08:36 -0700] [Client 1] Waiting for request.
D [11/Feb/2021:13:08:36 -0700] [Client 1] POST /printers/ENVY HTTP/1.1
D [11/Feb/2021:13:08:36 -0700] [Client 1] Read: status=200, state=6
D [11/Feb/2021:13:08:36 -0700] [Client 1] No authentication data provided.
D [11/Feb/2021:13:08:36 -0700] [Client 1] 2.0 Get-Printer-Attributes 10
D [11/Feb/2021:13:08:36 -0700] [Client 1] Returning IPP successful-ok 
for Get-Printer-Attributes (http://athena:631/printers/ENVY) from 
192.168.10.3.
D [11/Feb/2021:13:08:36 -0700] [Client 1] Content-Length: 1840
D [11/Feb/2021:13:08:36 -0700] [Client 1] cupsdSendHeader: code=200, 
type="application/ipp", auth_type=0
D [11/Feb/2021:13:08:36 -0700] [Client 1] con->http=0x5642ebffaad0
D [11/Feb/2021:13:08:36 -0700] [Client 1] cupsdWriteClient error=0, 
used=0, state=HTTP_STATE_POST_SEND, data_encoding=HTTP_ENCODING_LENGTH, 
data_remaining=1840, response=0x5642ebfda680(IPP_STATE_DATA), 
pipe_pid=0, file=-1
D [11/Feb/2021:13:08:36 -0700] [Client 1] Writing IPP response, 
ipp_state=IPP_STATE_DATA, old wused=0, new wused=0
D [11/Feb/2021:13:08:36 -0700] [Client 1] bytes=0, http_state=0, 
data_remaining=1840
D [11/Feb/2021:13:08:36 -0700] [Client 1] Flushing write buffer.
D [11/Feb/2021:13:08:36 -0700] [Client 1] New state is HTTP_STATE_WAITING
D [11/Feb/2021:13:08:36 -0700] [Client 1] Waiting for request.
D [11/Feb/2021:13:08:36 -0700] [Client 1] HTTP_STATE_WAITING Closing for 
error 32 (Broken pipe)
D [11/Feb/2021:13:08:36 -0700] [Client 1] Closing connection.
---- CUT HERE ----

>>> 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.
> Yes, under this configuration scenario the printing service served by Samba on
> Athena is a shared Windows printer and would be accessed via the smb://
> protocol.  So, the Janus CUPS server will connect to the printer service
> provided by the Samba server on Athena.  Again, without trying it out and
> troubleshooting it I wouldn't know if it'd work.
>
With the above stated worry excluded, I can't see a reason why it 
wouldn't. I'll check it out.


> As long as Janus (the Samba client) is authenticated to use Samba 
> services
> being served by Athena, it /should/ work.  You would need to configure
> firewalls accordingly to keep ports available, if you have firewalls enabled.
There are no internal firewalls. Only the internet <-> lan firewall.
>
> Grant's comment about buying a printer is opportune, depending on the value of
> (your) time.  The cost of printers and especially 2nd hand printers with so
> many companies going bust, should approximate zero.  The expense of running a
> printer is in the overinflated ink price, which is a multiple of the upfront
> cost of buying the device.
>
> On the other hand, if cashflow itself is zero, options are understandably
> limited.

Yea. Money is more than essentially zero. It's basically negative at the 
moment.  So a new printer, even a 2nd hand one, isn't an option. And as 
I also mentioned, it's exceptionally difficult to hook a PHYSICAL 
printer to a VIRTUAL computer. Not saying that it can't be done, but 
it's not easy. And even then, since it's all virtual, the computer is 
actually hooked to the windows host. Windows just doesn't USE it except 
for relaying messages to/from the VMs.

-- 
Dan Egli
On my test server

Re: [gentoo-user] Sharing printers via Cups

[Michael]

[-- Attachment #1: Type: text/plain, Size: 5813 bytes --]

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.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] Sharing printers via Cups

[Grant Taylor]

On 2/12/21 4:00 AM, Michael wrote:
> Samba uses the native MSWindows 'Active Directory Domain Services' 
> over TCP port 445 to resolve IP addresses when printing over Samba.

I question the veracity of this.

My understanding is that name to ip resolution, particularly in Active 
Directory environments, is that it is all DNS based.



-- 
Grant. . . .
unix || die

Re: [gentoo-user] Sharing printers via Cups

[Dan Egli]

On 2/12/2021 4:00 AM, Michael wrote:
[snip]
> 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.
No, it's not. But the windows printer driver expects the client to do 
all the rendering and deliver only finalized printer instructions when 
it receives network jobs. I suppose I could change it to a generic 
PostScript driver and tell Windows to do the rendering...
> 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.
>
Hmmm. Didn't see IPP everywhere as a "driver" but i really didn't look 
past the HP drivers. But I question if even that will work. Sounds like 
when Athena tries to render the page into printer instructions it's 
dying, with the cupsRasterOpen failed (and what kind of an error message 
is that? Tell me something I might be able to use to FIX the issue!).
> 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.

I'll try this and let you know. I'm actually about to head for bed as  I 
write this, so I'll check on it Tomorrow (Sunday).

-- 
Dan Egli
On my test server

Re: [gentoo-user] Sharing printers via Cups

[Michael]

[-- Attachment #1: Type: text/plain, Size: 1233 bytes --]

On Saturday, 13 February 2021 22:11:49 GMT Grant Taylor wrote:
> On 2/12/21 4:00 AM, Michael wrote:
> > Samba uses the native MSWindows 'Active Directory Domain Services'
> > over TCP port 445 to resolve IP addresses when printing over Samba.
> 
> I question the veracity of this.
> 
> My understanding is that name to ip resolution, particularly in Active
> Directory environments, is that it is all DNS based.

You are probably right.  My knowledge of MSWindows environments has been on a 
need to know basis, when I can't avoid it.  ;-)

Active Directory Domain Services use port 445 to store and communicate domain 
names, IP addresses, list of services available, etc. for a domain.  I suppose 
initial name to IP resolution happens over port 53, or UDP 5355 if there is no 
local DNS resolver configured and the MSWindows setup uses LLMNR.  Microsoft-
ds listens on TCP 445 and communicates stored DNS information to clients 
regarding domain names, domain controller(s) and services.  I don't know to 
what extent microsoft-ds is integrated with the basic TCP-IP DNS service, but 
expect there would be some logical linkage in there.

Anyhow, I think the OPs problem is down to the wrong CUPS driver used in 
remote client(s).

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] Sharing printers via Cups

[Michael]

[-- Attachment #1: Type: text/plain, Size: 2356 bytes --]

On Sunday, 14 February 2021 06:43:55 GMT Dan Egli wrote:
> On 2/12/2021 4:00 AM, Michael wrote:

> > 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.
> 
> No, it's not. But the windows printer driver expects the client to do
> all the rendering and deliver only finalized printer instructions when
> it receives network jobs. I suppose I could change it to a generic
> PostScript driver and tell Windows to do the rendering...

I think the problem arises if you layer one printer driver over another.


> > 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.
> 
> Hmmm. Didn't see IPP everywhere as a "driver" but i really didn't look
> past the HP drivers. But I question if even that will work. Sounds like
> when Athena tries to render the page into printer instructions it's
> dying, with the cupsRasterOpen failed (and what kind of an error message
> is that? Tell me something I might be able to use to FIX the issue!).

Heh! Devs' messages are usually clear in their meaning.  Mostly to devs.  :-)

Since the printer is not physically attached to and driven by Athena, I think 
the rendering is taking place by the MSWindows printer driver, at the Windows 
OS.

Athena functions as a router in this case pushing what it receives over 
smb://.

Have a look here for the 'IPP Everywhere' configuration option:

https://wiki.gentoo.org/wiki/Driverless_printing


> > 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.
> 
> I'll try this and let you know. I'm actually about to head for bed as  I
> write this, so I'll check on it Tomorrow (Sunday).

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[gentoo-user] Re: TCP port 445

[Grant Taylor]

On 2/14/21 4:42 AM, Michael wrote:
> You are probably right.  My knowledge of MSWindows environments has 
> been on a need to know basis, when I can't avoid it.  ;-)

Fair enough.

I've managed to avoid more Windows in the last 10 years than I could in 
the previous 10 years.

> Active Directory Domain Services use port 445 to store and communicate 
> domain names, IP addresses, list of services available, etc. for 
> a domain.

TCP port 445 is not directly related to AD DS.  Sure, AD DS /uses/ TCP 
port 445, but so do computers that are not participating in AD DS.

TCP port 445 is the port that SMB runs over natively.  Historically, SMB 
would use TCP ports 137, 138, and 139 when it was still using the 
NetBIOS over TCP (NBT).

> I suppose initial name to IP resolution happens over port 53, or UDP 
> 5355 if there is no local DNS resolver configured and the MSWindows 
> setup uses LLMNR.  Microsoft- ds listens on TCP 445 and communicates 
> stored DNS information to clients regarding domain names, domain 
> controller(s) and services.  I don't know to what extent microsoft-ds 
> is integrated with the basic TCP-IP DNS service, but expect there 
> would be some logical linkage in there.

I do not recall seeing anything about name resolution running over TCP 
port 445.

...

Even the venerable WINS (NetBIOS Name Service) ran over TCP port 137.

If you have any authoritative information that you can point to where 
name resolution, of any type, runs over TCP port 445, please share it as 
I'd like to read it.

> Anyhow, I think the OPs problem is down to the wrong CUPS driver used 
> in remote client(s).

Agreed.



-- 
Grant. . . .
unix || die

Re: [gentoo-user] Re: TCP port 445

[Michael]

[-- Attachment #1: Type: text/plain, Size: 2447 bytes --]

On Sunday, 14 February 2021 17:16:33 GMT Grant Taylor wrote:
> On 2/14/21 4:42 AM, Michael wrote:
> > You are probably right.  My knowledge of MSWindows environments has
> > been on a need to know basis, when I can't avoid it.  ;-)
> 
> Fair enough.
> 
> I've managed to avoid more Windows in the last 10 years than I could in
> the previous 10 years.
> 
> > Active Directory Domain Services use port 445 to store and communicate
> > domain names, IP addresses, list of services available, etc. for
> > a domain.
> 
> TCP port 445 is not directly related to AD DS.  Sure, AD DS /uses/ TCP
> port 445, but so do computers that are not participating in AD DS.

These are the services using port 445:

445	TCP	SMB	Fax Service
445	TCP	SMB	Print Spooler
445	TCP	SMB	Server
445	TCP	SMB	Remote Procedure Call Locator
445	TCP	SMB	Distributed File System Namespaces
445	TCP	SMB	Distributed File System Replication
445	TCP	SMB	License Logging Service
445	TCP	SMB	Net Logon


> TCP port 445 is the port that SMB runs over natively.  Historically, SMB
> would use TCP ports 137, 138, and 139 when it was still using the
> NetBIOS over TCP (NBT).
> 
> > I suppose initial name to IP resolution happens over port 53, or UDP
> > 5355 if there is no local DNS resolver configured and the MSWindows
> > setup uses LLMNR.  Microsoft- ds listens on TCP 445 and communicates
> > stored DNS information to clients regarding domain names, domain
> > controller(s) and services.  I don't know to what extent microsoft-ds
> > is integrated with the basic TCP-IP DNS service, but expect there
> > would be some logical linkage in there.
> 
> I do not recall seeing anything about name resolution running over TCP
> port 445.

Right, it isn't.  My bad.  FS Namespaces mapping uses port 445, a different 
function - see URL at the bottom.

> ...
> 
> Even the venerable WINS (NetBIOS Name Service) ran over TCP port 137.
> 
> If you have any authoritative information that you can point to where
> name resolution, of any type, runs over TCP port 445, please share it as
> I'd like to read it.

All I found from a random search in the interwebs, is the following link.  
Port 445 is used for file/printer data sharing as discussed.  It is also used 
for 'Distributed File System Namespaces' across different domains - but this 
is not DNS-IP resolution.

https://docs.microsoft.com/en-us/troubleshoot/windows-server/networking/
service-overview-and-network-port-requirements

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] Re: TCP port 445

[Grant Taylor]

On 2/14/21 11:26 AM, Michael wrote:
> These are the services using port 445:
> 
> 445	TCP	SMB	Fax Service
> 445	TCP	SMB	Print Spooler
> 445	TCP	SMB	Server
> 445	TCP	SMB	Remote Procedure Call Locator
> 445	TCP	SMB	Distributed File System Namespaces
> 445	TCP	SMB	Distributed File System Replication
> 445	TCP	SMB	License Logging Service
> 445	TCP	SMB	Net Logon

ACK

> Right, it isn't.  My bad.  FS Namespaces mapping uses port 445, 
> a different function - see URL at the bottom.

Ah.  Maybe a term collision between "Namespaces" and "name (to IP) 
resolution".

> All I found from a random search in the interwebs, is the following 
> link.  Port 445 is used for file/printer data sharing as discussed. 
> It is also used for 'Distributed File System Namespaces' across 
> different domains - but this is not DNS-IP resolution.

Yep.  DFS, being a pseudo / logical server, needs to be found just like 
actual servers.  That makes complete sense.  \\DFS\LogicalServer is 
really at \\CorpServer\ShareA and \\BranchServer\ShareB, take your pick. 
  By the way, CorpServer is at the corporate HQ through the WAN link and 
BranchServer is at the same branch office as you.

> https://docs.microsoft.com/en-us/troubleshoot/windows-server/networking/ 
> service-overview-and-network-port-requirements

Thank you for the link.  I will read it in the coming days as time permits.



-- 
Grant. . . .
unix || die