Mailing List Archive

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

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

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.

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

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.

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

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.

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

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

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

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.

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

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.

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

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

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

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

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

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

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