Re: cups broken FIXED!!!!

[gene heskett]

On 7/14/22 13:08, Brian wrote:

On Thu 14 Jul 2022 at 11:56:10 -0400, gene heskett wrote:


On 7/14/22 05:19, Brian wrote:


[...]


But now the "add printer" just re-configures the existing one. "Add"
does not make a new profile. I need both profiles to show up in both
firefox's, print dialog, and in the system dialog if you scroll all the
way down in the FF dialog  and select that instead.

How can is this done with this new cups?

Just specify a new destination name: XXX instead of AAA. Keep the same
URI (the connection).

To cups that destination=queuename, so I added _photo to the first 
columns name.

like this:

Brother_MFC-J6920DW_photo 
<http://localhost:631/printers/Brother_MFC-J6920DW_photo>


You're da man, it works! I loaded tray 1 with 40 or so sheets of good glossy
photo paper, face down in the tray cuz it turns it glossy side up to print.
Beautiful test page. Took it about 2 minutes wall time. But I had to cheat
and tell it it was brother paper. More like wallmart's better stuff.

Thank you very much Brian.

Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page<http://geneslinuxbox.net:6309/>

Re: cups broken

[Brian]

On Thu 14 Jul 2022 at 11:56:10 -0400, gene heskett wrote:

> On 7/14/22 05:19, Brian wrote:
> > On Wed 13 Jul 2022 at 21:31:24 -0400, gene heskett wrote:
> > 
> > > On 7/13/22 19:27, Brian wrote:
> > > > On Wed 13 Jul 2022 at 16:10:56 -0400, gene heskett wrote:
> > > > 
> > > > > On 7/13/22 15:14, Brian wrote:
> > > > > > On Wed 13 Jul 2022 at 13:21:07 -0400, gene heskett wrote:
> > > > > > 
> > > > > > [Broken lines mended to give a readable original post.]
> > > > > > 
> > > > > Blame that in tbird.
> > > > Yet another part of the compting experience tou are unable to
> > > > control?
> > > > > > > I give up, the driverless printer cups installs automaticaly 
> > > > > > > cannot be
> > > > > > > deleted and has taken over from the brother drivers that work,
> > > > > > > preventing me from using the printer at all.
> > > > > > > 
> > > > > > > So how do I disable the driverless junk? Is that a separate 
> > > > > > > package
> > > > > > > that is removable?  cups doesn't even offer to disable this
> > > > > > > non-working garbage.  Thanks for any good clues.
> > > > > > Driverless printing is only possible when avahi-daemon is on the
> > > > > > system. Your solution is obvious.
> > > > > > 
> > > > > avahi-daemon 0.8-5 is installed.
> > > > Is this the avahi-daemon that, in the past, you have characterised as
> > > > unfit to be used on a local network and that didn't deserve any of
> > > > your disk space.
> > > True, but that is all, none of its kin is.  And I did find out how to 
> > > defeat
> > > it. But
> > > when I went to look, that file has vanished and its still working.
> > > 
> > > So what happened that got /etc/dhcpcd.conf removed?
> > > It had a fallback stanza near the bottom that I had edited in
> > > the default eth0 config.  That finally got rid of the totally bogus
> > > 169.xx.yy.zz
> > > routing address. Now the file is gone,  and its still working.
> > Good.
> > 
> > > > >   See the ppd driverless attached to 
> > > > > my
> > > > > previous msg it just now made.
> > > > > It looks busted to me.
> > > > Broken files are best not used. Remove and follow my previos advice.
> > > > 
> > > I have. and cups brings it back automatically on the restart that does.
> > > Probably
> > > 20 times I've deleted it. Its back before I can look to see if its gone.
> > That is cups-browsed doing auto-setup. As far as you are concerned
> > that is its sole job. It doesn't do anything else for you or the
> > printing system. Therefore:
> > 
> >apt purge cups-browsed
> Will that then allow brothers drivers to work normally?

The Brother drivers should work normally with or without purging
cups-browsed.

> This printer is normally shared to the rest of my network. So
> I can fire up geany on any of the other 5 machines here,
> make an adjustment to one of the LinuxCNC configuration files,
> and print it right from that machine which might be a minutes
> walk away in another building.
> 
> Done, all versions of this printer are deleted and stay gone.

As predicted!

> Ok, it works, sort of. I did have it setup as two printers before
> this last cups update a week or so back, one for  color photos,
> from thick glossy paper from tray 1 (top tray).
> And another copy setup to do fast utility duplexed printing
> from tray 2, the bottom tray, which can hold 300 sheets of 22 lb.

Any CUPS update on bullseye would be for a secuity issue only. There
shouldn't be any change in its basic operation.

> But now the "add printer" just re-configures the existing one. "Add"
> does not make a new profile. I need both profiles to show up in both
> firefox's, print dialog, and in the system dialog if you scroll all the
> way down in the FF dialog  and select that instead.
> 
> How can is this done with this new cups?

Just specify a new destination name: XXX instead of AAA. Keep the same
URI (the connection).

-- 
Brian.

Re: cups broken

[gene heskett]

On 7/14/22 05:19, Brian wrote:

On Wed 13 Jul 2022 at 21:31:24 -0400, gene heskett wrote:


On 7/13/22 19:27, Brian wrote:

On Wed 13 Jul 2022 at 16:10:56 -0400, gene heskett wrote:


On 7/13/22 15:14, Brian wrote:

On Wed 13 Jul 2022 at 13:21:07 -0400, gene heskett wrote:

[Broken lines mended to give a readable original post.]


Blame that in tbird.

Yet another part of the compting experience tou are unable to
control?

I give up, the driverless printer cups installs automaticaly cannot be
deleted and has taken over from the brother drivers that work,
preventing me from using the printer at all.

So how do I disable the driverless junk? Is that a separate package
that is removable?  cups doesn't even offer to disable this
non-working garbage.  Thanks for any good clues.

Driverless printing is only possible when avahi-daemon is on the
system. Your solution is obvious.


avahi-daemon 0.8-5 is installed.

Is this the avahi-daemon that, in the past, you have characterised as
unfit to be used on a local network and that didn't deserve any of
your disk space.

True, but that is all, none of its kin is.  And I did find out how to defeat
it. But
when I went to look, that file has vanished and its still working.

So what happened that got /etc/dhcpcd.conf removed?
It had a fallback stanza near the bottom that I had edited in
the default eth0 config.  That finally got rid of the totally bogus
169.xx.yy.zz
routing address. Now the file is gone,  and its still working.

Good.


  See the ppd driverless attached to my
previous msg it just now made.
It looks busted to me.

Broken files are best not used. Remove and follow my previos advice.


I have. and cups brings it back automatically on the restart that does.
Probably
20 times I've deleted it. Its back before I can look to see if its gone.

That is cups-browsed doing auto-setup. As far as you are concerned
that is its sole job. It doesn't do anything else for you or the
printing system. Therefore:

   apt purge cups-browsed

Will that then allow brothers drivers to work normally?
This printer is normally shared to the rest of my network. So
I can fire up geany on any of the other 5 machines here,
make an adjustment to one of the LinuxCNC configuration files,
and print it right from that machine which might be a minutes
walk away in another building.

Done, all versions of this printer are deleted and stay gone.

Ok, it works, sort of. I did have it setup as two printers before
this last cups update a week or so back, one for  color photos,
from thick glossy paper from tray 1 (top tray).
And another copy setup to do fast utility duplexed printing
from tray 2, the bottom tray, which can hold 300 sheets of 22 lb.

But now the "add printer" just re-configures the existing one. "Add"
does not make a new profile. I need both profiles to show up in both
firefox's, print dialog, and in the system dialog if you scroll all the
way down in the FF dialog  and select that instead.

How can is this done with this new cups?

Thanks Brian, take care & stay well.

Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/>

Re: cups broken

[Brian]

On Wed 13 Jul 2022 at 21:31:24 -0400, gene heskett wrote:

> On 7/13/22 19:27, Brian wrote:
> > On Wed 13 Jul 2022 at 16:10:56 -0400, gene heskett wrote:
> > 
> > > On 7/13/22 15:14, Brian wrote:
> > > > On Wed 13 Jul 2022 at 13:21:07 -0400, gene heskett wrote:
> > > > 
> > > > [Broken lines mended to give a readable original post.]
> > > > 
> > > Blame that in tbird.
> > Yet another part of the compting experience tou are unable to
> > control?
> > > > > I give up, the driverless printer cups installs automaticaly cannot be
> > > > > deleted and has taken over from the brother drivers that work,
> > > > > preventing me from using the printer at all.
> > > > > 
> > > > > So how do I disable the driverless junk? Is that a separate package
> > > > > that is removable?  cups doesn't even offer to disable this
> > > > > non-working garbage.  Thanks for any good clues.
> > > > Driverless printing is only possible when avahi-daemon is on the
> > > > system. Your solution is obvious.
> > > > 
> > > avahi-daemon 0.8-5 is installed.
> > Is this the avahi-daemon that, in the past, you have characterised as
> > unfit to be used on a local network and that didn't deserve any of
> > your disk space.
> True, but that is all, none of its kin is.  And I did find out how to defeat
> it. But
> when I went to look, that file has vanished and its still working.
> 
> So what happened that got /etc/dhcpcd.conf removed?
> It had a fallback stanza near the bottom that I had edited in
> the default eth0 config.  That finally got rid of the totally bogus
> 169.xx.yy.zz
> routing address. Now the file is gone,  and its still working.

Good.

> > >  See the ppd driverless attached to my
> > > previous msg it just now made.
> > > It looks busted to me.
> > Broken files are best not used. Remove and follow my previos advice.
> > 
> I have. and cups brings it back automatically on the restart that does.
> Probably
> 20 times I've deleted it. Its back before I can look to see if its gone.

That is cups-browsed doing auto-setup. As far as you are concerned
that is its sole job. It doesn't do anything else for you or the
printing system. Therefore:

  apt purge cups-browsed

-- 
Brian.

Re: cups broken

[Gareth Evans]

On Thu 14 Jul 2022, at 02:08, gene heskett  wrote:

> it printed a test page

Good.  I'm afraid I don't know of a workaround for tray selection.

This site 

https://productz.com/en/brother-mfc-j6920dw/p/LZbAV

suggests the printer concerned is airprint/fax-capable, and given:

> On Wed 13 Jul 2022, at 18:21, gene heskett  wrote:
> 
> using the everywhere default, the printer goes busy for about the time the
> print job should take, 20 minutes or so, never moves any thing looking for
> paper, and at the end of the receiving data time, reverts to its idle screen.

I suspect this is the third case we've seen of what seems to be a 
fax+driverless printing bug in cups.

As well as 

$ lpadmin [...] everywhere

"IPP Eveywhere" printers/queues added via cups web interface (localhost:631) 
also seem to work.

I have reported the problem upstream after help from the Debian printing team, 
but no  response from upstream yet.

Best wishes,
Gareth

Re: cups broken

[gene heskett]

On 7/13/22 19:27, Brian wrote:

On Wed 13 Jul 2022 at 16:10:56 -0400, gene heskett wrote:


On 7/13/22 15:14, Brian wrote:

On Wed 13 Jul 2022 at 13:21:07 -0400, gene heskett wrote:

[Broken lines mended to give a readable original post.]


Blame that in tbird.

Yet another part of the compting experience tou are unable to
control?
  

I give up, the driverless printer cups installs automaticaly cannot be
deleted and has taken over from the brother drivers that work,
preventing me from using the printer at all.

So how do I disable the driverless junk? Is that a separate package
that is removable?  cups doesn't even offer to disable this
non-working garbage.  Thanks for any good clues.

Driverless printing is only possible when avahi-daemon is on the
system. Your solution is obvious.


avahi-daemon 0.8-5 is installed.

Is this the avahi-daemon that, in the past, you have characterised as
unfit to be used on a local network and that didn't deserve any of
your disk space.
True, but that is all, none of its kin is.  And I did find out how to 
defeat it. But

when I went to look, that file has vanished and its still working.

So what happened that got /etc/dhcpcd.conf removed?
It had a fallback stanza near the bottom that I had edited in
the default eth0 config.  That finally got rid of the totally bogus 
169.xx.yy.zz

routing address. Now the file is gone,  and its still working.

 See the ppd driverless attached to my
previous msg it just now made.
It looks busted to me.

Broken files are best not used. Remove and follow my previos advice.

I have. and cups brings it back automatically on the restart that does. 
Probably

20 times I've deleted it. Its back before I can look to see if its gone.

Take care and stay well, Brian.

Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/>

Re: cups broken

[gene heskett]

On 7/13/22 18:25, Gareth Evans wrote:

On 13 Jul 2022, at 22:04, gene heskett  wrote:
On 7/13/22 15:15, Gareth Evans wrote:

[...]
Out of interest, which model printer(s) has the issue?

Brother MFC-J6920DW A huge tabloid capable printer/scanner

# lpinfo -v

first off, none of that stuff is available to the user unless he has hacked his 
$PATH

You only have to do this once as root/sudo to set up the queue

QUEUENAME is whatever you want to call the printer queue.

So, eg:

# lpadmin -p J6920 -v  ipp://Brother%20MFC-J6920DW._ipp._tcp.local/  -E -m 
everywhere

Before and after you execute the above, what is output of:

$ driverless


before (after deleting it) ipp://Brother%20MFC-J6920DW._ipp._tcp.local/
and after running that cmd:ipp://Brother%20MFC-J6920DW._ipp._tcp.local/

?
it printed a test page, but when I checked the options and changed it to 
bottom, and
took the 1/4" of paper out of the top tray, its now asking for paper in 
tray #1. So it took

a sheet out of the top tray to do the test page.

Adding an everywhere queue via lpadmin may fix this:


using the everywhere default, the printer goes
busy for about the time the print job should take, 20 minutes or so, never 
moves any
thing looking for paper, and at the end of the receiving data time, reverts to 
its idle screen.

but it will be interesting to see about the tray selection issue.
That is not working so I've put copy paper in the top tray and will try 
to print that
web page I need. It turned out the color images were being blocked by 
FF's pop-up blocker.
Bondtech thinks they are being cute I guess.  And the speed was about 
normal. But that
41 pages is just the beginning, now I have to find the page that shows 
me how to put it

back together with the new, different, parts.

Thanks Gareth, Take care & stay well.

Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: cups broken

[Brian]

On Wed 13 Jul 2022 at 16:10:56 -0400, gene heskett wrote:

> On 7/13/22 15:14, Brian wrote:
> > On Wed 13 Jul 2022 at 13:21:07 -0400, gene heskett wrote:
> > 
> > [Broken lines mended to give a readable original post.]
> > 
> Blame that in tbird.

Yet another part of the compting experience tou are unable to
control?
 
> > > I give up, the driverless printer cups installs automaticaly cannot be
> > > deleted and has taken over from the brother drivers that work,
> > > preventing me from using the printer at all.
> > > 
> > > So how do I disable the driverless junk? Is that a separate package
> > > that is removable?  cups doesn't even offer to disable this
> > > non-working garbage.  Thanks for any good clues.
> > Driverless printing is only possible when avahi-daemon is on the
> > system. Your solution is obvious.
> > 
> avahi-daemon 0.8-5 is installed.

Is this the avahi-daemon that, in the past, you have characterised as
unfit to be used on a local network and that didn't deserve any of
your disk space.

> See the ppd driverless attached to my
> previous msg it just now made.
> It looks busted to me.

Broken files are best not used. Remove and follow my previos advice.

-- 
Brian.

Re: cups broken

[Gareth Evans]

> On 13 Jul 2022, at 22:04, gene heskett  wrote:
> On 7/13/22 15:15, Gareth Evans wrote:
>> [...]
>> Out of interest, which model printer(s) has the issue?
> Brother MFC-J6920DW A huge tabloid capable printer/scanner

>> # lpinfo -v
> first off, none of that stuff is available to the user unless he has hacked 
> his $PATH 

You only have to do this once as root/sudo to set up the queue

QUEUENAME is whatever you want to call the printer queue.

So, eg:

# lpadmin -p J6920 -v  ipp://Brother%20MFC-J6920DW._ipp._tcp.local/  -E -m 
everywhere

Before and after you execute the above, what is output of:

$ driverless

?

Adding an everywhere queue via lpadmin may fix this:

> using the everywhere default, the printer goes
> busy for about the time the print job should take, 20 minutes or so, never 
> moves any
> thing looking for paper, and at the end of the receiving data time, reverts 
> to its idle screen.

but it will be interesting to see about the tray selection issue.

Thanks,
Gareth

 

Re: cups broken

[gene heskett]

On 7/13/22 15:15, Gareth Evans wrote:

On 13 Jul 2022, at 18:21, gene heskett  wrote:
I give up, the driverless printer cups installs automaticaly cannot be deleted 
and has
taken over from the brother drivers that work, preventing me from using the 
printer at all.

So how do I disable the driverless junk? Is that a separate package that is 
removable?
cups doesn't even offer to disable this non-working garbage.
Thanks for any good clues.

Hi Gene,

Out of interest, which model printer(s) has the issue?

Brother MFC-J6920DW A huge tabloid capable printer/scanner


There are options in

/etc/cups/cupsd.conf

to disable automatic queue creation for autodetected IPP/dns-sd/etc/etc 
printers.

You may find that

# lpinfo -v
first off, none of that stuff is available to the user unless he has 
hacked his $PATH statement.

The above produces:
gene@coyote:/etc/cups/ppd$ /usr/sbin/lpinfo -v
file cups-brf:/
network socket
file cups-pdf:/
network ipps
network http
network lpd
network https
network beh
network ipp
direct usb://Brother/MFC-J6920DW?serial=BROG5F229909
direct usb://Brother/HL-L2320D%20series?serial=U63877H0N346913
serial serial:/dev/ttyS0?baud=115200
serial serial:/dev/ttyUSB0?baud=230400
serial serial:/dev/ttyUSB1?baud=230400
file cups-x2go:/
network bjnp
network 
dnssd://Brother%20MFC-J6920DW._ipp._tcp.local/?uuid=e3248000-80ce-11db-8000-30055c8a2dc8

network ipp://Brother%20MFC-J6920DW._ipp._tcp.local/ <---
network lpd://BRN30055C8A2DC8/BINARY_P1
network tea4cups:socket
network tea4cups:lpd
serial tea4cups:serial:/dev/ttyS0?baud=115200
serial tea4cups:serial:/dev/ttyUSB0?baud=230400
serial tea4cups:serial:/dev/ttyUSB1?baud=230400
network tea4cups:ipp
network tea4cups:ipps
network tea4cups:bjnp
network tea4cups:https
network tea4cups:http
network tea4cups:beh
direct tea4cups://


copy the ipp:// url for the printer concerned

Then

# lpadmin -p QUEUENAME -v IPP_URL_HERE -E -m everywhere

produces a functional queue
Using the arrowed return line above, what then does the lpadmin cmd line 
look like?


What is QUEUENAME? Arbitrary/anything?

Thanks Gareth, but I just posted an attcachment of the ppd it generated, 
looks busted to me.
Let me repeat for probably the 20th time, that brothers drivers have 
been working flawlessly
with this printer for several years and many installs since wheezy was a 
puppy.


You'll see that ppd specs the bottom tray, but it actually uses the top 
tray, that I normally keep
$mucho dollars photo paper in. Removed in self defense of my bank 
balance until this behaves.


Thanks Gareth

Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/>

Re: cups broken

[Gareth Evans]

On Wed 13 Jul 2022, at 20:36, Brian  wrote:
> On Wed 13 Jul 2022 at 20:12:28 +0100, Gareth Evans wrote:
[...]
>> 
>> Hi Gene, 
>> 
>> Out of interest, which model printer(s) has the issue?
>> 
>> There are options in
>> 
>> /etc/cups/cupsd.conf
>> 
>> to disable automatic queue creation for autodetected IPP/dns-sd/etc/etc 
>> printers.
>

> No such options exist in cupsd.conf.

Hi Brian,

I meant cups-browsed.conf at least as regards IPP network printer queues, which 
I think might remain helpful despite revision of the problem description.  I 
had momentarily confused DNS-SD as being one of whatever everywhere, driverless 
etc are.

$ cat /etc/cups/cups-browsed.conf

# Set CreateIPPPrinterQueues to "No" to not auto-create print queues
# for IPP network printers.

# CreateIPPPrinterQueues No
# CreateIPPPrinterQueues LocalOnly
# CreateIPPPrinterQueues Everywhere
# CreateIPPPrinterQueues AppleRaster
# CreateIPPPrinterQueues Everywhere AppleRaster
# CreateIPPPrinterQueues Driverless
# CreateIPPPrinterQueues All

Best wishes,
Gareth

Re: cups broken

[gene heskett]

On 7/13/22 15:14, Brian wrote:

On Wed 13 Jul 2022 at 13:21:07 -0400, gene heskett wrote:

[Broken lines mended to give a readable original post.]


Blame that in tbird.


I give up, the driverless printer cups installs automaticaly cannot be
deleted and has taken over from the brother drivers that work,
preventing me from using the printer at all.

So how do I disable the driverless junk? Is that a separate package
that is removable?  cups doesn't even offer to disable this
non-working garbage.  Thanks for any good clues.

Driverless printing is only possible when avahi-daemon is on the
system. Your solution is obvious.

avahi-daemon 0.8-5 is installed. See the ppd driverless attached to my 
previous msg it just now made.

It looks busted to me.

Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/>

Re: cups broken

[gene heskett]

On 7/13/22 13:59, John Conover wrote:

gene heskett writes:

I give up, the driverless printer cups installs automaticaly cannot be
deleted and has
taken over from the brother drivers that work, preventing me from using
the printer at all.

So how do I disable the driverless junk? Is that a separate package that
is removable?
cups doesn't even offer to disable this non-working garbage.
Thanks for any good clues.


Hi Gene. If its a network connected printer, then the driverless
connection will be PROBABLY default to PCL5e/PCL6, (or maybe ipp,)
which the modern Brother printers support.

Older Brother printers do not support PCL and/or ipp, and require a
specific Brother printer set of drivers for network connectivity.

If its an older printer, you might attempt a re-install of the Brother
printer drivers, and cups(1) SHOULD remove any existing PCL/ipp
drivers during installation, (famous last words.) BTW,
x86_64-linux-gnu has to be installed on my machines for the the
Brother printer drivers to compile.

/etc/cups/ppd/* and/or /usr/local/Brother/* and/or /opt/Brother/* may
provide some information.

 John
The problem here would appear to be the ipp everywhere driver used by 
default
ignores the tray 2 src, looks at tray 1, and calls for paper, which I 
have removed
from tray 1 because its 50 cents a sheet photo paper. Cups calls them 
main and
bottom. instead of tray 1 or tray 2 but you can select on the set 
default options
screen, bottom, main or automatic, in all 3 cases the printer looks at 
the top tray only.


The printer also has a net port, assigned a local address, and sane even 
uses it to
drive its scanner, but any attempts to set up a net que are met with a 
no device

found error from cups. ./usr/sbin/lpinfo -v shows:

gene@coyote:~/Downloads/brother-drivers$ /usr/sbin/lpinfo  -v
network socket
file cups-brf:/
file cups-pdf:/
network ipps
network ipp
network https
serial serial:/dev/ttyS0?baud=115200
serial serial:/dev/ttyUSB0?baud=230400
serial serial:/dev/ttyUSB1?baud=230400
network beh
network lpd
direct usb://Brother/MFC-J6920DW?serial=BROG5F229909
network http
direct usb://Brother/HL-L2320D%20series?serial=U63877H0N346913
file cups-x2go:/
network bjnp
network 
dnssd://Brother%20MFC-J6920DW._ipp._tcp.local/?uuid=e3248000-80ce-11db-8000-30055c8a2dc8

network ipp://Brother%20MFC-J6920DW._ipp._tcp.local/
network lpd://BRN30055C8A2DC8/BINARY_P1
network tea4cups:socket
network tea4cups:lpd
serial tea4cups:serial:/dev/ttyS0?baud=115200
serial tea4cups:serial:/dev/ttyUSB0?baud=230400
serial tea4cups:serial:/dev/ttyUSB1?baud=230400
network tea4cups:ipp
network tea4cups:ipps
network tea4cups:bjnp
network tea4cups:https
network tea4cups:http
network tea4cups:beh
direct tea4cups://


I have re-installed the brother drivers 3 times now, and they have 
always worked
flawlessly until the last cups update, but now cups refuses to do 
anything beyond
a test page during the driver install. All I get from 
localhost:631->print test page,

is endless requester's on the printer screen for more paper in tray 1.

I am repairing an $850 Prusa 3d printer by modifying the problem parts 
with better stuff.
But the teardown instructions are 61 pages, using the everywhere 
default, the printer goes
busy for about the time the print job should take, 20 minutes or so, 
never moves any
thing looking for paper, and at the end of the receiving data time, 
reverts to its idle screen.


The other half of the problem is that I've known Mike Sweet since his 
college days in the
later '80's when we were both using color computers. Now I can't even 
subscribe to the

cups.org user mailing list.

I have 2 brother printers here, the other is the workhorse $120 laser, 
and it works.


But it is B and what I want to print is in color and color of wires is 
important for this.


I'll move some duplex copy paper to tray 1 just for S Test page 
works. And so does
the 61 page instructions doc, but single sided, and face up meaning its 
printing the last
page first, will use 61 sheet of paper and take a couple hours. And I 
canceled the job,
it is not printing any of the pix from the web pages. This, using the 
brother drivers, is a

4 pages a minute in full color.

I just found that utilities man page for driverless,
and had it generate a ppd with this commandline:
 driverless cat driverless:ipp://Brother%20MFC-J6920DW._ipp._tcp.local/ 
>MFC-J6920DW.ppd


And that MFC-J6920DW.ppd is attached. If that is what it got from the 
printer, it looks busted to me.


Thanks John.

Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/>


MFC-J6920DW.ppd
Description: application/vnd.cups-ppd

Re: cups broken

[Brian]

On Wed 13 Jul 2022 at 20:12:28 +0100, Gareth Evans wrote:

> 
> > On 13 Jul 2022, at 18:21, gene heskett  wrote:
> > I give up, the driverless printer cups installs automaticaly cannot be 
> > deleted and has
> > taken over from the brother drivers that work, preventing me from using the 
> > printer at all.
> > 
> > So how do I disable the driverless junk? Is that a separate package that is 
> > removable?
> > cups doesn't even offer to disable this non-working garbage.
> > Thanks for any good clues.
> 
> Hi Gene, 
> 
> Out of interest, which model printer(s) has the issue?
> 
> There are options in
> 
> /etc/cups/cupsd.conf
> 
> to disable automatic queue creation for autodetected IPP/dns-sd/etc/etc 
> printers.

No such options exist in cupsd.conf.

-- 
Brian.

Re: cups broken

[Brian]

On Wed 13 Jul 2022 at 10:56:15 -0700, John Conover wrote:

> gene heskett writes:
> > I give up, the driverless printer cups installs automaticaly cannot be 
> > deleted and has
> > taken over from the brother drivers that work, preventing me from using 
> > the printer at all.
> > 
> > So how do I disable the driverless junk? Is that a separate package that 
> > is removable?
> > cups doesn't even offer to disable this non-working garbage.
> > Thanks for any good clues.
> >
> 
> Hi Gene. If its a network connected printer, then the driverless
> connection will be PROBABLY default to PCL5e/PCL6, (or maybe ipp,)
> which the modern Brother printers support.

 * PCL5e/PCL6 are not driverless PDLs and both are irrelevant.
 * ipp is a protocol. Absolutely nothing to do with PCL5e/PCL6.
   (But ipp is essential for  driverless printing).

-- 
Brian.

Re: cups broken

[Gareth Evans]

> On 13 Jul 2022, at 18:21, gene heskett  wrote:
> I give up, the driverless printer cups installs automaticaly cannot be 
> deleted and has
> taken over from the brother drivers that work, preventing me from using the 
> printer at all.
> 
> So how do I disable the driverless junk? Is that a separate package that is 
> removable?
> cups doesn't even offer to disable this non-working garbage.
> Thanks for any good clues.

Hi Gene, 

Out of interest, which model printer(s) has the issue?

There are options in

/etc/cups/cupsd.conf

to disable automatic queue creation for autodetected IPP/dns-sd/etc/etc 
printers.

You may find that

# lpinfo -v

copy the ipp:// url for the printer concerned

Then

# lpadmin -p QUEUENAME -v IPP_URL_HERE -E -m everywhere

produces a functional queue

Thanks
Gareth

> 
> Cheers, Gene Heskett.
> -- 
> "There are four boxes to be used in defense of liberty:
> soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author, 1940)
> If we desire respect for the law, we must first make the law respectable.
> - Louis D. Brandeis
> Genes Web page <http://geneslinuxbox.net:6309/>

Re: cups broken

[Brian]

On Wed 13 Jul 2022 at 13:21:07 -0400, gene heskett wrote:

[Broken lines mended to give a readable original post.]

> I give up, the driverless printer cups installs automaticaly cannot be
> deleted and has taken over from the brother drivers that work,
> preventing me from using the printer at all.
> 
> So how do I disable the driverless junk? Is that a separate package
> that is removable?  cups doesn't even offer to disable this
> non-working garbage.  Thanks for any good clues.

Driverless printing is only possible when avahi-daemon is on the
system. Your solution is obvious.

-- 
Brian.

Re: cups broken

[John Conover]

gene heskett writes:
> I give up, the driverless printer cups installs automaticaly cannot be 
> deleted and has
> taken over from the brother drivers that work, preventing me from using 
> the printer at all.
> 
> So how do I disable the driverless junk? Is that a separate package that 
> is removable?
> cups doesn't even offer to disable this non-working garbage.
> Thanks for any good clues.
>

Hi Gene. If its a network connected printer, then the driverless
connection will be PROBABLY default to PCL5e/PCL6, (or maybe ipp,)
which the modern Brother printers support.

Older Brother printers do not support PCL and/or ipp, and require a
specific Brother printer set of drivers for network connectivity.

If its an older printer, you might attempt a re-install of the Brother
printer drivers, and cups(1) SHOULD remove any existing PCL/ipp
drivers during installation, (famous last words.) BTW,
x86_64-linux-gnu has to be installed on my machines for the the
Brother printer drivers to compile.

/etc/cups/ppd/* and/or /usr/local/Brother/* and/or /opt/Brother/* may
provide some information.

John

-- 

John Conover, cono...@panix.com, http://www.johncon.com/

Re: cups broken

[mick crane]

On 2022-07-13 18:21, gene heskett wrote:

I give up, the driverless printer cups installs automaticaly cannot be
deleted and has
taken over from the brother drivers that work, preventing me from
using the printer at all.

So how do I disable the driverless junk? Is that a separate package
that is removable?
cups doesn't even offer to disable this non-working garbage.
Thanks for any good clues.


I've usually managed once discovered what CUPS thinks the printer is 
called.

Not seen this documentation on github before.
https://openprinting.github.io/cups/doc/admin.html

mick

cups broken

[gene heskett]

I give up, the driverless printer cups installs automaticaly cannot be 
deleted and has
taken over from the brother drivers that work, preventing me from using 
the printer at all.


So how do I disable the driverless junk? Is that a separate package that 
is removable?

cups doesn't even offer to disable this non-working garbage.
Thanks for any good clues.

Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/>

CUPS bugfix vs upgrade?

[Gareth Evans]

After troubleshooting assistance from the Debian Printing team, I was advised 
to report my non-printing driverless printer issue upstream, which I have done.

https://github.com/OpenPrinting/cups-filters/issues/472

Given that driverless printing works in CUPS 2.4 (on Ubuntu 22.04) are they 
likely to fix 2.3.3 in Debian stable, rather than just suggest Debian updates 
cups[-filters/whatever] in stable?

That is, assuming Canonical hasn't just fixed whatever the issue is in Ubuntu.

Does anyone know if cups 2.4 in Debian testing is in a suitable state to 
consider (exceptionally) adding to stable?

Alternatively, is it advisable to downgrade to a known-working version from 
Buster?

Thanks,
Gareth

Re: CUPS and available-printers-list management (was Re: non installed printer can not be removed)

[Gareth Evans]

On Mon 20 Jun 2022, at 23:50, Gareth Evans  wrote:
> On Mon 20 Jun 2022, at 23:31, Gareth Evans  wrote:
>> On Mon 20 Jun 2022, at 17:34, The Wanderer  wrote:
>>> On 2022-06-20 at 12:01, Brian wrote:
>>>
>>>> On Mon 20 Jun 2022 at 09:28:30 -0400, The Wanderer wrote:
>>>> 
>>>>> On 2022-06-20 at 08:59, Brian wrote:
>>>
>>>>>> The ability to print to an IPP printer involves discovering its
>>>>>> URI. CUPS gets the URI via avahi-daemon whether it is an
>>>>>> on-demand or manual queue.
>>>>> 
>>>>> But that discovery doesn't have to be done by CUPS; once the URI is
>>>>> known, it should be possible for CUPS to simply accept the URI and
>>>>> work with it from then on, without discovery entering into the
>>>>> picture.
>>>> 
>>>> "...once the URIis known"? What mechaism does that? Incidentally, a
>>>> URI is required to query a printer for its attributes.
>>>
>>> Any of a number of mechanisms.
>>>
>>> CUPS could run discovery once, then either A: present the discovered URI
>>> with a prompt for whether to add it to its local list of known printers
>>> or B: add it to that list automatically, and then in either case not run
>>> discovery again until something asks it to.
>>>
>>> The user could run discovery manually (e.g. from the command line), then
>>> enter the discovered URI into CUPS.
>>>
>>> The user could look at another computer where the URI is already present
>>> in CUPS, and copy that across to the computer at hand.
>>>
>>> I could probably come up with more options if I thought about it for
>>> long enough.
>>>
>>>>>> Setting up a  manual queue for a moden printer is still available
>>>>>> but is unnecessary. 'lpstat -e' showves every printer on a subnet
>>>>>> and they should (barring bugs) appear in an application's print
>>>>>> dialog without any intervention.
>>>>> 
>>>>> The thing is, though, sometimes this is *undesirable*.
>>>> 
>>>> It is possible that upstream CUPS would agree. The intention is to
>>>> do something about it eventually.
>>>
>>> Depending on what the "something" is, that could be a very positive
>>> development!
>>>
>>>>> Going back to my workplace as an example, we have one subnet per
>>>>> building per floor, and one printer per classroom; we want the
>>>>> computers in each room to be able to see and print to the printer
>>>>> from that classroom, *only*. Having the ones from the other
>>>>> classrooms show up in the applications' print dialog would be a
>>>>> problem.
>>>> 
>>>> DNS-SD doesn't traverse subnets.
>>>
>>> Yes, but we don't have one subnet per classroom, we have one subnet per
>>> floor, with multiple classrooms per floor.
>>>
>>>>>> You can control whether Avahi browses for printers or not but
>>>>>> cannt make it selective in its browsing. DNS-SD is an
>>>>>> all-or-nothing public service discovery protocol. Perhaps think
>>>>>> of the display screens at airports.
>>>>> 
>>>>> That's just about discovery, though. I'm talking about what's done
>>>>> with the discovered information.
>>>>> 
>>>>> It sounds to me as if it's being said that CUPS takes the
>>>>> discovered information and automatically puts every discovered
>>>>> printer into the list of printers that will be made available in
>>>>> the print dialog (or equivalent).
>>>>> 
>>>>> That should not be the only option. It should also be possible to
>>>>> run discovery, manually select zero or more printers from the set
>>>>> discovered, and add *just those printers* to the list of those
>>>>> that will be shown in the print dialog
>>>>> 
>>>>> (It should also be possible to add printers to that list manually,
>>>>> without running discovery, if you know the necessary information.)
>>>> 
>>>> That's certainly possible at present.
>>>
>>> I figured, and seemed to recall, but did not want to assume.
>>>
>>>>> The result would be being able to be sure that the list of printers
>>>>> available i

Re: CUPS and available-printers-list management (was Re: non installed printer can not be removed)

[Gareth Evans]

On Mon 20 Jun 2022, at 23:31, Gareth Evans  wrote:
> On Mon 20 Jun 2022, at 17:34, The Wanderer  wrote:
>> On 2022-06-20 at 12:01, Brian wrote:
>>
>>> On Mon 20 Jun 2022 at 09:28:30 -0400, The Wanderer wrote:
>>> 
>>>> On 2022-06-20 at 08:59, Brian wrote:
>>
>>>>> The ability to print to an IPP printer involves discovering its
>>>>> URI. CUPS gets the URI via avahi-daemon whether it is an
>>>>> on-demand or manual queue.
>>>> 
>>>> But that discovery doesn't have to be done by CUPS; once the URI is
>>>> known, it should be possible for CUPS to simply accept the URI and
>>>> work with it from then on, without discovery entering into the
>>>> picture.
>>> 
>>> "...once the URIis known"? What mechaism does that? Incidentally, a
>>> URI is required to query a printer for its attributes.
>>
>> Any of a number of mechanisms.
>>
>> CUPS could run discovery once, then either A: present the discovered URI
>> with a prompt for whether to add it to its local list of known printers
>> or B: add it to that list automatically, and then in either case not run
>> discovery again until something asks it to.
>>
>> The user could run discovery manually (e.g. from the command line), then
>> enter the discovered URI into CUPS.
>>
>> The user could look at another computer where the URI is already present
>> in CUPS, and copy that across to the computer at hand.
>>
>> I could probably come up with more options if I thought about it for
>> long enough.
>>
>>>>> Setting up a  manual queue for a moden printer is still available
>>>>> but is unnecessary. 'lpstat -e' showves every printer on a subnet
>>>>> and they should (barring bugs) appear in an application's print
>>>>> dialog without any intervention.
>>>> 
>>>> The thing is, though, sometimes this is *undesirable*.
>>> 
>>> It is possible that upstream CUPS would agree. The intention is to
>>> do something about it eventually.
>>
>> Depending on what the "something" is, that could be a very positive
>> development!
>>
>>>> Going back to my workplace as an example, we have one subnet per
>>>> building per floor, and one printer per classroom; we want the
>>>> computers in each room to be able to see and print to the printer
>>>> from that classroom, *only*. Having the ones from the other
>>>> classrooms show up in the applications' print dialog would be a
>>>> problem.
>>> 
>>> DNS-SD doesn't traverse subnets.
>>
>> Yes, but we don't have one subnet per classroom, we have one subnet per
>> floor, with multiple classrooms per floor.
>>
>>>>> You can control whether Avahi browses for printers or not but
>>>>> cannt make it selective in its browsing. DNS-SD is an
>>>>> all-or-nothing public service discovery protocol. Perhaps think
>>>>> of the display screens at airports.
>>>> 
>>>> That's just about discovery, though. I'm talking about what's done
>>>> with the discovered information.
>>>> 
>>>> It sounds to me as if it's being said that CUPS takes the
>>>> discovered information and automatically puts every discovered
>>>> printer into the list of printers that will be made available in
>>>> the print dialog (or equivalent).
>>>> 
>>>> That should not be the only option. It should also be possible to
>>>> run discovery, manually select zero or more printers from the set
>>>> discovered, and add *just those printers* to the list of those
>>>> that will be shown in the print dialog
>>>> 
>>>> (It should also be possible to add printers to that list manually,
>>>> without running discovery, if you know the necessary information.)
>>> 
>>> That's certainly possible at present.
>>
>> I figured, and seemed to recall, but did not want to assume.
>>
>>>> The result would be being able to be sure that the list of printers
>>>> available in the print dialog will only change if someone manually
>>>> modifies it, rather than changing automatically if the set of
>>>> printers discoverable on the network changes.
>>> 
>>> Other would see the automatic change as a definite plus.
>>
>> And in some cases so would I! But not in others. And my interpretation
>> of Gene's original co

Re: CUPS and available-printers-list management (was Re: non installed printer can not be removed)

[Gareth Evans]

On Mon 20 Jun 2022, at 17:34, The Wanderer  wrote:
> On 2022-06-20 at 12:01, Brian wrote:
>
>> On Mon 20 Jun 2022 at 09:28:30 -0400, The Wanderer wrote:
>> 
>>> On 2022-06-20 at 08:59, Brian wrote:
>
>>>> The ability to print to an IPP printer involves discovering its
>>>> URI. CUPS gets the URI via avahi-daemon whether it is an
>>>> on-demand or manual queue.
>>> 
>>> But that discovery doesn't have to be done by CUPS; once the URI is
>>> known, it should be possible for CUPS to simply accept the URI and
>>> work with it from then on, without discovery entering into the
>>> picture.
>> 
>> "...once the URIis known"? What mechaism does that? Incidentally, a
>> URI is required to query a printer for its attributes.
>
> Any of a number of mechanisms.
>
> CUPS could run discovery once, then either A: present the discovered URI
> with a prompt for whether to add it to its local list of known printers
> or B: add it to that list automatically, and then in either case not run
> discovery again until something asks it to.
>
> The user could run discovery manually (e.g. from the command line), then
> enter the discovered URI into CUPS.
>
> The user could look at another computer where the URI is already present
> in CUPS, and copy that across to the computer at hand.
>
> I could probably come up with more options if I thought about it for
> long enough.
>
>>>> Setting up a  manual queue for a moden printer is still available
>>>> but is unnecessary. 'lpstat -e' showves every printer on a subnet
>>>> and they should (barring bugs) appear in an application's print
>>>> dialog without any intervention.
>>> 
>>> The thing is, though, sometimes this is *undesirable*.
>> 
>> It is possible that upstream CUPS would agree. The intention is to
>> do something about it eventually.
>
> Depending on what the "something" is, that could be a very positive
> development!
>
>>> Going back to my workplace as an example, we have one subnet per
>>> building per floor, and one printer per classroom; we want the
>>> computers in each room to be able to see and print to the printer
>>> from that classroom, *only*. Having the ones from the other
>>> classrooms show up in the applications' print dialog would be a
>>> problem.
>> 
>> DNS-SD doesn't traverse subnets.
>
> Yes, but we don't have one subnet per classroom, we have one subnet per
> floor, with multiple classrooms per floor.
>
>>>> You can control whether Avahi browses for printers or not but
>>>> cannt make it selective in its browsing. DNS-SD is an
>>>> all-or-nothing public service discovery protocol. Perhaps think
>>>> of the display screens at airports.
>>> 
>>> That's just about discovery, though. I'm talking about what's done
>>> with the discovered information.
>>> 
>>> It sounds to me as if it's being said that CUPS takes the
>>> discovered information and automatically puts every discovered
>>> printer into the list of printers that will be made available in
>>> the print dialog (or equivalent).
>>> 
>>> That should not be the only option. It should also be possible to
>>> run discovery, manually select zero or more printers from the set
>>> discovered, and add *just those printers* to the list of those
>>> that will be shown in the print dialog
>>> 
>>> (It should also be possible to add printers to that list manually,
>>> without running discovery, if you know the necessary information.)
>> 
>> That's certainly possible at present.
>
> I figured, and seemed to recall, but did not want to assume.
>
>>> The result would be being able to be sure that the list of printers
>>> available in the print dialog will only change if someone manually
>>> modifies it, rather than changing automatically if the set of
>>> printers discoverable on the network changes.
>> 
>> Other would see the automatic change as a definite plus.
>
> And in some cases so would I! But not in others. And my interpretation
> of Gene's original complaint, as you quoted it, would suggest that he is
> in a case where he also would not.
>
> That's why whether or not this discovery-and-updating process is
> performed automatically should be *configurable*.
>
>>>> I beleive filtering of a printer list using LDAP is something
>>>> being considered for inclusion in a future CUPS.
>>> 
>>> Why should LDAP need to

Re: CUPS and available-printers-list management (was Re: non installed printer can not be removed)

[Brian]

On Mon 20 Jun 2022 at 19:49:18 +0100, Brian wrote:

Please forget  about this mai. I pressed the wrong key. Never done that
before!

> On Mon 20 Jun 2022 at 12:34:19 -0400, The Wanderer wrote:
> 
> > On 2022-06-20 at 12:01, Brian wrote:
> >
> > > "...once the URIis known"? What mechaism does that? Incidentally, a
> > > URI is required to query a printer for its attributes.
> > 
> > Any of a number of mechanisms.
> > 
> > CUPS could run discovery once, then either A: present the discovered URI
> > with a prompt for whether to add it to its local list of known printers
> > or B: add it to that list automatically, and then in either case not run
> > discovery again until something asks it to.
> > 
> > The user could run discovery manually (e.g. from the command line), then
> > enter the discovered URI into CUPS.
> > 
> > The user could look at another computer where the URI is already present
> > in CUPS, and copy that across to the computer at hand.
> > 
> > I could probably come up with more options if I thought about it for
> > long enough.
> > 
> > > DNS-SD doesn't traverse subnets.
> > 
> > Yes, but we don't have one subnet per classroom, we have one subnet per
> > floor, with multiple classrooms per floor.
> > 
> > > Other would see the automatic change as a definite plus.
> > 
> > And in some cases so would I! But not in others. And my interpretation
> > of Gene's original complaint, as you quoted it, would suggest that he is
> > in a case where he also would not.
> > 
> > That's why whether or not this discovery-and-updating process is
> > performed automatically should be *configurable*.
> >
> > > My understanding of LDAP is very limited. All I know is that CUPS
> > > will eshew simple filtering. It has been tried, and didn't work.
> > 
> > I don't even know why filtering would be involved. You're not starting
> > with a longer list and filtering it to show only a subset; you're
> > starting with an empty list, populating it (either manually, or
> > automatically but only on demand) from a longer one, storing the
> > resulting list, and later showing it on demand.
> > 
> > Or, at least, that's the way it *should* work.
> > 
> > If there's a reason why filtering needs to be involved, given that "two
> > separate lists" model, I'd be interested in seeing that reason
> > clarified.
> > 
> > (I can see why it would be useful in a model which says that the list
> > which is available to applications is always updated automatically from
> > the list generated by discovery; in that context you'd need some way to
> > tell the system which things from the discovered list should be included
> > or excluded from the made-available list. But since that shouldn't be
> > the only behavior, filtering shouldn't be the starting point for
> > thinking about this.)
> 

Re: CUPS and available-printers-list management (was Re: non installed printer can not be removed)

[Brian]

On Mon 20 Jun 2022 at 12:34:19 -0400, The Wanderer wrote:

> On 2022-06-20 at 12:01, Brian wrote:
>
> > "...once the URIis known"? What mechaism does that? Incidentally, a
> > URI is required to query a printer for its attributes.
> 
> Any of a number of mechanisms.
> 
> CUPS could run discovery once, then either A: present the discovered URI
> with a prompt for whether to add it to its local list of known printers
> or B: add it to that list automatically, and then in either case not run
> discovery again until something asks it to.
> 
> The user could run discovery manually (e.g. from the command line), then
> enter the discovered URI into CUPS.
> 
> The user could look at another computer where the URI is already present
> in CUPS, and copy that across to the computer at hand.
> 
> I could probably come up with more options if I thought about it for
> long enough.
> 
> > DNS-SD doesn't traverse subnets.
> 
> Yes, but we don't have one subnet per classroom, we have one subnet per
> floor, with multiple classrooms per floor.
> 
> > Other would see the automatic change as a definite plus.
> 
> And in some cases so would I! But not in others. And my interpretation
> of Gene's original complaint, as you quoted it, would suggest that he is
> in a case where he also would not.
> 
> That's why whether or not this discovery-and-updating process is
> performed automatically should be *configurable*.
>
> > My understanding of LDAP is very limited. All I know is that CUPS
> > will eshew simple filtering. It has been tried, and didn't work.
> 
> I don't even know why filtering would be involved. You're not starting
> with a longer list and filtering it to show only a subset; you're
> starting with an empty list, populating it (either manually, or
> automatically but only on demand) from a longer one, storing the
> resulting list, and later showing it on demand.
> 
> Or, at least, that's the way it *should* work.
> 
> If there's a reason why filtering needs to be involved, given that "two
> separate lists" model, I'd be interested in seeing that reason
> clarified.
> 
> (I can see why it would be useful in a model which says that the list
> which is available to applications is always updated automatically from
> the list generated by discovery; in that context you'd need some way to
> tell the system which things from the discovered list should be included
> or excluded from the made-available list. But since that shouldn't be
> the only behavior, filtering shouldn't be the starting point for
> thinking about this.)

Re: CUPS and available-printers-list management (was Re: non installed printer can not be removed)

[The Wanderer]

On 2022-06-20 at 12:01, Brian wrote:

> On Mon 20 Jun 2022 at 09:28:30 -0400, The Wanderer wrote:
> 
>> On 2022-06-20 at 08:59, Brian wrote:

>>> The ability to print to an IPP printer involves discovering its
>>> URI. CUPS gets the URI via avahi-daemon whether it is an
>>> on-demand or manual queue.
>> 
>> But that discovery doesn't have to be done by CUPS; once the URI is
>> known, it should be possible for CUPS to simply accept the URI and
>> work with it from then on, without discovery entering into the
>> picture.
> 
> "...once the URIis known"? What mechaism does that? Incidentally, a
> URI is required to query a printer for its attributes.

Any of a number of mechanisms.

CUPS could run discovery once, then either A: present the discovered URI
with a prompt for whether to add it to its local list of known printers
or B: add it to that list automatically, and then in either case not run
discovery again until something asks it to.

The user could run discovery manually (e.g. from the command line), then
enter the discovered URI into CUPS.

The user could look at another computer where the URI is already present
in CUPS, and copy that across to the computer at hand.

I could probably come up with more options if I thought about it for
long enough.

>>> Setting up a  manual queue for a moden printer is still available
>>> but is unnecessary. 'lpstat -e' showves every printer on a subnet
>>> and they should (barring bugs) appear in an application's print
>>> dialog without any intervention.
>> 
>> The thing is, though, sometimes this is *undesirable*.
> 
> It is possible that upstream CUPS would agree. The intention is to
> do something about it eventually.

Depending on what the "something" is, that could be a very positive
development!

>> Going back to my workplace as an example, we have one subnet per
>> building per floor, and one printer per classroom; we want the
>> computers in each room to be able to see and print to the printer
>> from that classroom, *only*. Having the ones from the other
>> classrooms show up in the applications' print dialog would be a
>> problem.
> 
> DNS-SD doesn't traverse subnets.

Yes, but we don't have one subnet per classroom, we have one subnet per
floor, with multiple classrooms per floor.

>>> You can control whether Avahi browses for printers or not but
>>> cannt make it selective in its browsing. DNS-SD is an
>>> all-or-nothing public service discovery protocol. Perhaps think
>>> of the display screens at airports.
>> 
>> That's just about discovery, though. I'm talking about what's done
>> with the discovered information.
>> 
>> It sounds to me as if it's being said that CUPS takes the
>> discovered information and automatically puts every discovered
>> printer into the list of printers that will be made available in
>> the print dialog (or equivalent).
>> 
>> That should not be the only option. It should also be possible to
>> run discovery, manually select zero or more printers from the set
>> discovered, and add *just those printers* to the list of those
>> that will be shown in the print dialog
>> 
>> (It should also be possible to add printers to that list manually,
>> without running discovery, if you know the necessary information.)
> 
> That's certainly possible at present.

I figured, and seemed to recall, but did not want to assume.

>> The result would be being able to be sure that the list of printers
>> available in the print dialog will only change if someone manually
>> modifies it, rather than changing automatically if the set of
>> printers discoverable on the network changes.
> 
> Other would see the automatic change as a definite plus.

And in some cases so would I! But not in others. And my interpretation
of Gene's original complaint, as you quoted it, would suggest that he is
in a case where he also would not.

That's why whether or not this discovery-and-updating process is
performed automatically should be *configurable*.

>>> I beleive filtering of a printer list using LDAP is something
>>> being considered for inclusion in a future CUPS.
>> 
>> Why should LDAP need to be involved? Unless you're using an
>> external print server to get the printer list from (in which case
>> things become in some ways simpler and in other ways considerably
>> more complicated), the list of printers that applications should
>> see is local, and should be able to be maintained locally without
>> bringing external things such as LDAP into the picture.
> 
> My understanding of LDAP is very limited. All I know is that CUPS
> will 

Re: CUPS and available-printers-list management (was Re: non installed printer can not be removed)

[Brian]

On Mon 20 Jun 2022 at 09:28:30 -0400, The Wanderer wrote:

> On 2022-06-20 at 08:59, Brian wrote:
> 
> > On Sun 19 Jun 2022 at 18:01:36 -0400, The Wanderer wrote:
> > 
> >> On 2022-06-19 at 15:47, Brian wrote:
> 
> >>> You (or the OP) would have to say what is meant by "delete".
> >>> CUPS essentially *discover* printers. It is why it exists. Is
> >>> that not wanted?
> >> 
> >> I understand the reason for CUPS' existence to be, not
> >> *discovering printers*, but *facilitating the ability to print*.
> >> That could involve discovering printers and presenting them as
> >> available, or it could involve only presenting as available a list
> >> of printers that have been entered into CUPS or otherwise set up in
> >> CUPS by some more manual means. (Among perhaps other
> >> possibilities.)
> > 
> > The ability to print to an IPP printer involves discovering its URI. 
> > CUPS gets the URI via avahi-daemon whether it is an on-demand or 
> > manual queue.
> 
> But that discovery doesn't have to be done by CUPS; once the URI is
> known, it should be possible for CUPS to simply accept the URI and work
> with it from then on, without discovery entering into the picture.

"...once the URIis known"? What mechaism does that? Incidentally, a URI
is required to query a printer for its attributes.

> >> Certainly at my workplace I understand that our Macs use CUPS for 
> >> (network) printing, but at least at one point in our history
> >> (within the past decade), we had to go in and define each printer
> >> by IP address in CUPS on each Mac (or on the central machine which
> >> would be replicated to the others).
> > 
> > Setting up a  manual queue for a moden printer is still available
> > but is unnecessary. 'lpstat -e' showves every printer on a subnet and
> > they should (barring bugs) appear in an application's print dialog
> > without any intervention.
> 
> The thing is, though, sometimes this is *undesirable*.

It is possible that upstream CUPS would agree. The intention is to
do something about it eventually.
 
> Going back to my workplace as an example, we have one subnet per
> building per floor, and one printer per classroom; we want the computers
> in each room to be able to see and print to the printer from that
> classroom, *only*. Having the ones from the other classrooms show up in
> the applications' print dialog would be a problem.

DNS-SD doesn't traverse subnets.
 
> The set of printers which are discoverable on the network, and the set
> of printers which are available to applications as print destinations,
> should not have to be the same thing; the former should be generated on

Not a bad iea. Others have also asked for it. Upstream have responed
positively.

> demand whenever discovery is performed, and the latter should be
> maintained locally. It should be possible to populate the latter list
> from the former, selectively, but this should not *have* to happen -
> much less always happen automatically in all cases.
> 
> >> I can certainly see it as being reasonable to want to be able to
> >> have CUPS perform printer discovery *on request*, and manually
> >> choose which of the discovered printers to add to the list of ones
> >> that will be remembered and shown as available when printing, but
> >> not have CUPS run discovery *automatically* and *automatically* add
> >> every discovered printer to that list. (I don't know with any
> >> confidence whether CUPS does the latter; I don't run it in enough
> >> environments with enough different available printers to have been
> >> able to make an assessment. However, I do have the impression that
> >> it may.)
> > 
> > You can control whether Avahi browses for printers or not but cannt 
> > make it selective in its browsing. DNS-SD is an all-or-nothing
> > public service discovery protocol. Perhaps think of the display
> > screens at airports.
> 
> That's just about discovery, though. I'm talking about what's done with
> the discovered information.
> 
> It sounds to me as if it's being said that CUPS takes the discovered
> information and automatically puts every discovered printer into the
> list of printers that will be made available in the print dialog (or
> equivalent).
> 
> That should not be the only option. It should also be possible to run
> discovery, manually select zero or more printers from the set
> discovered, and add *just those printers* to the list of those that will
> be shown in the print dialog
> 
> (It should also be possible to add printers to that list 

CUPS and available-printers-list management (was Re: non installed printer can not be removed)

[The Wanderer]

On 2022-06-20 at 08:59, Brian wrote:

> On Sun 19 Jun 2022 at 18:01:36 -0400, The Wanderer wrote:
> 
>> On 2022-06-19 at 15:47, Brian wrote:

>>> You (or the OP) would have to say what is meant by "delete".
>>> CUPS essentially *discover* printers. It is why it exists. Is
>>> that not wanted?
>> 
>> I understand the reason for CUPS' existence to be, not
>> *discovering printers*, but *facilitating the ability to print*.
>> That could involve discovering printers and presenting them as
>> available, or it could involve only presenting as available a list
>> of printers that have been entered into CUPS or otherwise set up in
>> CUPS by some more manual means. (Among perhaps other
>> possibilities.)
> 
> The ability to print to an IPP printer involves discovering its URI. 
> CUPS gets the URI via avahi-daemon whether it is an on-demand or 
> manual queue.

But that discovery doesn't have to be done by CUPS; once the URI is
known, it should be possible for CUPS to simply accept the URI and work
with it from then on, without discovery entering into the picture.

>> Certainly at my workplace I understand that our Macs use CUPS for 
>> (network) printing, but at least at one point in our history
>> (within the past decade), we had to go in and define each printer
>> by IP address in CUPS on each Mac (or on the central machine which
>> would be replicated to the others).
> 
> Setting up a  manual queue for a moden printer is still available
> but is unnecessary. 'lpstat -e' showves every printer on a subnet and
> they should (barring bugs) appear in an application's print dialog
> without any intervention.

The thing is, though, sometimes this is *undesirable*.

Going back to my workplace as an example, we have one subnet per
building per floor, and one printer per classroom; we want the computers
in each room to be able to see and print to the printer from that
classroom, *only*. Having the ones from the other classrooms show up in
the applications' print dialog would be a problem.

The set of printers which are discoverable on the network, and the set
of printers which are available to applications as print destinations,
should not have to be the same thing; the former should be generated on
demand whenever discovery is performed, and the latter should be
maintained locally. It should be possible to populate the latter list
from the former, selectively, but this should not *have* to happen -
much less always happen automatically in all cases.

>> I can certainly see it as being reasonable to want to be able to
>> have CUPS perform printer discovery *on request*, and manually
>> choose which of the discovered printers to add to the list of ones
>> that will be remembered and shown as available when printing, but
>> not have CUPS run discovery *automatically* and *automatically* add
>> every discovered printer to that list. (I don't know with any
>> confidence whether CUPS does the latter; I don't run it in enough
>> environments with enough different available printers to have been
>> able to make an assessment. However, I do have the impression that
>> it may.)
> 
> You can control whether Avahi browses for printers or not but cannt 
> make it selective in its browsing. DNS-SD is an all-or-nothing
> public service discovery protocol. Perhaps think of the display
> screens at airports.

That's just about discovery, though. I'm talking about what's done with
the discovered information.

It sounds to me as if it's being said that CUPS takes the discovered
information and automatically puts every discovered printer into the
list of printers that will be made available in the print dialog (or
equivalent).

That should not be the only option. It should also be possible to run
discovery, manually select zero or more printers from the set
discovered, and add *just those printers* to the list of those that will
be shown in the print dialog

(It should also be possible to add printers to that list manually,
without running discovery, if you know the necessary information.)

The result would be being able to be sure that the list of printers
available in the print dialog will only change if someone manually
modifies it, rather than changing automatically if the set of printers
discoverable on the network changes.

As far as I can tell, that's entirely a matter for CUPS, since CUPS is
the software which would be maintaining such a list and providing such a
list to the applications which need to print.

If that behavior is possible, it must be CUPS that is providing it. If
it is not possible, then by the nature of CUPS' purpose and role (that
of middleman between applications and printers), it must be CUPS that is
at fault for not providing it.

> I beleive filtering of a printer list using

Re: CUPS - how to match autodetected printers to physical ones

[Gareth Evans]

On Mon 11 Apr 2022, at 19:23, Brian  wrote:
> On Mon 11 Apr 2022 at 13:55:03 -0400, Greg Wooledge wrote:
>
>> On Mon, Apr 11, 2022 at 06:47:59PM +0100, Brian wrote:
>> > BTW. I am interested in how using /usr/lib/cups/backend/snmp went.
>> > Its drawback is that not all printers provide an snmp service.
>> 
>> wooledg:~$ /usr/lib/cups/backend/snmp
>> network socket://10.76.172.120 "HP LaserJet 4250" "hp LaserJet 4250" 
>> "MFG:Hewlett-Packard;CMD:PJL,MLC,PCLXL,PCL,PJL,POSTSCRIPT;1284.4DL:4d,4e,1;MDL:hp
>>  LaserJet 4250;CLS:PRINTER;DES:Hewlett-Packard LaserJet 4250;" "W01-0224"
>> network socket://10.76.172.88 "HP LaserJet 4100 Series" "HP LaserJet 4100 
>> Series" "MFG:Hewlett-Packard;CMD:PJL,MLC,PCL,POSTSCRIPT,PCLXL,PJL;MDL:HP 
>> LaserJet 4100 Series ;CLS:PRINTER;DES:Hewlett-Packard LaserJet 4100 Series;" 
>> ""
>> network socket://10.76.173.60:9100 "HP LaserJet P3010 Series" "HP LaserJet 
>> P3010 Series" 
>> "MFG:Hewlett-Packard;CMD:PJL,BIDI-ECP,PJL,POSTSCRIPT,PDF,PCLXL,PCL;MDL:HP 
>> LaserJet P3010 Series;CLS:PRINTER;DES:Hewlett-Packard LaserJet P3010 
>> Series;" ""
>> 
>> Looks like that doesn't contain anything for the Canon printers.
>
> Although used by other vendors, a socket://... URI is really an HP
> thing, used by JetDirect appliances, so not surprising. Anyway, this
> very useful info of yours would prompt me to discard advising the use
> of snmp to match IP address with printer model. We are back to
> avahi-browse.
>
> I appreciate you print to that printer infrequently but would suggest a
> manually set up queue may suit you.
>
> Execute
>
>   driverless
>
> to get its URI. (I am sure you can sort out which one it is).
>
> Then
>
>   lpadmin -p SENSIBLE_PRINTER_NAME -L MYOFFICE -v URI -E -m everywhere
>
> -- 
> Brian.


I've been searching for documentation on CUPS "implicitclass" but can't find 
much.

I did find this:

'CUPS can automatically merge multiple identical network printers into 
"implicit classes". This allows clients to send jobs to the implicit class and 
have them print on the first available printer or server.' [though the doc 
predates CUPS driverless printing by some margin]
https://www.cups.org/test/testfile.pdf (p4)

The above is similar (though possibly quite different) to
https://opensource.apple.com/source/cups/cups-87/doc/sam.shtml#PRINTER_CLASSES
(2nd para under 'The Basics')

Assuming implicitclass is the mechanism of first resort in auto-detection (my 
own setup suggests so), does anyone know if this means that, with multiple 
devices of the same type, there's no guarantee from which device printing from 
the same queue will emerge, or are implicit classes resulting from 
auto-detection implemented as implicit classes of one?

Thanks,
Gareth

Re: CUPS - how to match autodetected printers to physical ones

[Brian]

On Mon 11 Apr 2022 at 13:55:03 -0400, Greg Wooledge wrote:

> On Mon, Apr 11, 2022 at 06:47:59PM +0100, Brian wrote:
> > BTW. I am interested in how using /usr/lib/cups/backend/snmp went.
> > Its drawback is that not all printers provide an snmp service.
> 
> wooledg:~$ /usr/lib/cups/backend/snmp
> network socket://10.76.172.120 "HP LaserJet 4250" "hp LaserJet 4250" 
> "MFG:Hewlett-Packard;CMD:PJL,MLC,PCLXL,PCL,PJL,POSTSCRIPT;1284.4DL:4d,4e,1;MDL:hp
>  LaserJet 4250;CLS:PRINTER;DES:Hewlett-Packard LaserJet 4250;" "W01-0224"
> network socket://10.76.172.88 "HP LaserJet 4100 Series" "HP LaserJet 4100 
> Series" "MFG:Hewlett-Packard;CMD:PJL,MLC,PCL,POSTSCRIPT,PCLXL,PJL;MDL:HP 
> LaserJet 4100 Series ;CLS:PRINTER;DES:Hewlett-Packard LaserJet 4100 Series;" 
> ""
> network socket://10.76.173.60:9100 "HP LaserJet P3010 Series" "HP LaserJet 
> P3010 Series" 
> "MFG:Hewlett-Packard;CMD:PJL,BIDI-ECP,PJL,POSTSCRIPT,PDF,PCLXL,PCL;MDL:HP 
> LaserJet P3010 Series;CLS:PRINTER;DES:Hewlett-Packard LaserJet P3010 Series;" 
> ""
> 
> Looks like that doesn't contain anything for the Canon printers.

Although used by other vendors, a socket://... URI is really an HP
thing, used by JetDirect appliances, so not surprising. Anyway, this
very useful info of yours would prompt me to discard advising the use
of snmp to match IP address with printer model. We are back to
avahi-browse.

I appreciate you print to that printer infrequently but would suggest a
manually set up queue may suit you.

Execute

  driverless

to get its URI. (I am sure you can sort out which one it is).

Then

  lpadmin -p SENSIBLE_PRINTER_NAME -L MYOFFICE -v URI -E -m everywhere

-- 
Brian.

Re: CUPS - how to match autodetected printers to physical ones

[Greg Wooledge]

On Mon, Apr 11, 2022 at 06:47:59PM +0100, Brian wrote:
> BTW. I am interested in how using /usr/lib/cups/backend/snmp went.
> Its drawback is that not all printers provide an snmp service.

wooledg:~$ /usr/lib/cups/backend/snmp
network socket://10.76.172.120 "HP LaserJet 4250" "hp LaserJet 4250" 
"MFG:Hewlett-Packard;CMD:PJL,MLC,PCLXL,PCL,PJL,POSTSCRIPT;1284.4DL:4d,4e,1;MDL:hp
 LaserJet 4250;CLS:PRINTER;DES:Hewlett-Packard LaserJet 4250;" "W01-0224"
network socket://10.76.172.88 "HP LaserJet 4100 Series" "HP LaserJet 4100 
Series" "MFG:Hewlett-Packard;CMD:PJL,MLC,PCL,POSTSCRIPT,PCLXL,PJL;MDL:HP 
LaserJet 4100 Series ;CLS:PRINTER;DES:Hewlett-Packard LaserJet 4100 Series;" ""
network socket://10.76.173.60:9100 "HP LaserJet P3010 Series" "HP LaserJet 
P3010 Series" 
"MFG:Hewlett-Packard;CMD:PJL,BIDI-ECP,PJL,POSTSCRIPT,PDF,PCLXL,PCL;MDL:HP 
LaserJet P3010 Series;CLS:PRINTER;DES:Hewlett-Packard LaserJet P3010 Series;" ""

Looks like that doesn't contain anything for the Canon printers.

Re: CUPS - how to match autodetected printers to physical ones

[Brian]

On Mon 11 Apr 2022 at 13:04:12 -0400, Greg Wooledge wrote:

> On Mon, Apr 11, 2022 at 05:47:07PM +0100, Brian wrote:
> > What does
> > 
> >avahi-browse -rt _ipp._tcp | grep -B3 port
> > 
> > give for this device?
> 
> =   eno1 IPv4 Canon LBP351dn (f9:7a:4a) Internet Printer  
>local
>hostname = [dhcp-10-76-172-100.local]
>address = [10.76.172.100]
>port = [631]
> 
> And for completeness:
> 
> wooledg:~$ avahi-resolve -n dhcp-10-76-172-100.local
> dhcp-10-76-172-100.local  10.76.172.100

Thanks. I completly forgot: CUPS constructs a destination from a
printer's Service (Bonjour) Name by replacing a dash (-) with an
underscore (_). It then adds an underscore (_) to the end. (It
has stopped doing the latter in the most recent version, I thnk).

I will scub the third method. It is too involved to explain how
to reverse what is in the implicitclass URI just for resolving.
avahi-browse seems the way to go for your purpose.

BTW. I am interested in how using /usr/lib/cups/backend/snmp went.
Its drawback is that not all printers provide an snmp service.

-- 
Brian.

Re: CUPS - how to match autodetected printers to physical ones

[Greg Wooledge]

On Mon, Apr 11, 2022 at 05:47:07PM +0100, Brian wrote:
> What does
> 
>avahi-browse -rt _ipp._tcp | grep -B3 port
> 
> give for this device?

=   eno1 IPv4 Canon LBP351dn (f9:7a:4a) Internet Printer
 local
   hostname = [dhcp-10-76-172-100.local]
   address = [10.76.172.100]
   port = [631]

And for completeness:

wooledg:~$ avahi-resolve -n dhcp-10-76-172-100.local
dhcp-10-76-172-100.local10.76.172.100

Re: CUPS - how to match autodetected printers to physical ones

[Brian]

On Mon 11 Apr 2022 at 11:53:38 -0400, Greg Wooledge wrote:

> On Mon, Apr 11, 2022 at 03:40:12PM +0100, Brian wrote:
> > A third way forward:
> > 
> > "implicitclass://Canon_LBP351dn_f9_7a_4a_/" is the URI for this printer.
> > Canon_LBP351dn_f9_7a_4a_ is the printer's Service Name. 
> > 
> >   avahi-resolve -n Canon_LBP351dn_f9_7a_4a_.local
> > 
> > should give the IP address of the host.
> 
> wooledg:~$ time avahi-resolve -n Canon_LBP351dn_f9_7a_4a_.local
> Failed to resolve host name 'Canon_LBP351dn_f9_7a_4a_.local': Timeout reached
> real 5.014  user 0.004  sys 0.004

What does

   avahi-browse -rt _ipp._tcp | grep -B3 port

give for this device?

-- 
Brian. 

Re: CUPS - how to match autodetected printers to physical ones

[Greg Wooledge]

On Mon, Apr 11, 2022 at 03:40:12PM +0100, Brian wrote:
> A third way forward:
> 
> "implicitclass://Canon_LBP351dn_f9_7a_4a_/" is the URI for this printer.
> Canon_LBP351dn_f9_7a_4a_ is the printer's Service Name. 
> 
>   avahi-resolve -n Canon_LBP351dn_f9_7a_4a_.local
> 
> should give the IP address of the host.

wooledg:~$ time avahi-resolve -n Canon_LBP351dn_f9_7a_4a_.local
Failed to resolve host name 'Canon_LBP351dn_f9_7a_4a_.local': Timeout reached
real 5.014  user 0.004  sys 0.004

Re: CUPS - how to match autodetected printers to physical ones

[Brian]

On Fri 08 Apr 2022 at 13:22:26 -0400, Greg Wooledge wrote:

> On Fri, Apr 08, 2022 at 06:03:47PM +0100, Tixy wrote:
> > On Fri, 2022-04-08 at 17:59 +0100, Tixy wrote:
> > > On Fri, 2022-04-08 at 12:10 -0400, Greg Wooledge wrote:
> > > > Unfortunately, I was not able to find ANY way to determine the IP
> > > > addresses of the autodetected printers that were presented to me.
> > > 
> > > If I go to http://localhost:631/printers/
> > 
> > I should say I got to that URL from the CUPs interface at
> > http://localhost:631/ then clicking the 'Admininitation' tab at the top
> > followed by the 'Manage Printers' button on the page that showed.
> 
> Here is what I have on that page:
> 
> =
> Showing 7 of 7 printers.
> 
> Queue NameDescription LocationMake and Model  Status
> Canon_LBP351dn_f9_7a_4a_  CNLBP712C CNLBP712C, 
> driverless, cups-filters 1.28.7Idle
> Canon_LBP712Cdn_db_c0_d3_ Canon_LBP712Cdn_db_c0_d3_   
> CNLBP712C CNLBP712C, driverless, cups-filters 1.28.7Idle
> Cups_PDF_oc3261540276 Cups_PDF_oc3261540276   Local Raw Printer   
> Paused
> HP_LaserJet_4100_Series_0001E6A68D3D_ HP_LaserJet_4100_Series_0001E6A68D3D_   
> HP LaserJet 4100 Series , driverless, cups-filters 1.28.7   Idle
> hp_LaserJet_4250_621E13_  hp_LaserJet_4250_621E13_hp 
> LaserJet 4250, driverless, cups-filters 1.28.7   Idle
> HP_LaserJet_P3010_Series_0FCDD7_  HP_LaserJet_P3010_Series_0FCDD7_
> HP LaserJet P3010 Series, driverless, cups-filters 1.28.7   Idle
> PostScript_oc3261540276   PostScript_oc3261540276 Local Raw 
> Printer   Paused
> =
> 
> Of course it looks like crap when I just paste the text from the web
> page into an email.  But if you ignore the horrible formatting, you
> can see there are NO IP addresses here.

Looks are the least of the deficiencies here. The Queue Name appears
to be being used for the printer Descriptiom and the Location column
is empty. Neither column provides adequate, useful information.
> 
> If I go to a single printer's page, I get text like this:
> 
> =
> Canon_LBP351dn_f9_7a_4a_
> Canon_LBP351dn_f9_7a_4a_ (Idle, Accepting Jobs, Not Shared, Server Default)
> 
> Maintenance
>  
> Administration
> Description:  
> Location: 
> Driver:   CNLBP712C CNLBP712C, driverless, cups-filters 1.28.7 (color, 
> 2-sided printing)
> Connection:   implicitclass://Canon_LBP351dn_f9_7a_4a_/
> Defaults: job-sheets=none, none media=na_letter_8.5x11in sides=one-sided
> =
> 
> Maybe I need to amend the question to "How is one supposed to figure out
> which autodetected printer is which IN A CORPORATE NETWORK OF UNKNOWN
> PROVENANCE?"  I don't know what I need to say to convey to you that
> my workplace's network DOES NOT work like what you see on yours.
> 
> Looking at the stuff that I pasted here, how am I supposed to know whether
> this corresponds to the physical printer with IP address 10.76.172.100?

A third way forward:

"implicitclass://Canon_LBP351dn_f9_7a_4a_/" is the URI for this printer.
Canon_LBP351dn_f9_7a_4a_ is the printer's Service Name. 

  avahi-resolve -n Canon_LBP351dn_f9_7a_4a_.local

should give the IP address of the host.

-- 
Brian.

Re: CUPS - how to match autodetected printers to physical ones

[gene heskett]

On Sunday, 10 April 2022 09:54:34 EDT Brian wrote:
> On Sun 10 Apr 2022 at 09:19:43 -0400, gene heskett wrote:
> > On Sunday, 10 April 2022 08:40:29 EDT Brian wrote:
> > >   /usr/lib/cups/backend/snmp
> > 
> > The only machine I have here that has that file installed, an rpi4,
> > does not expose the printers address, only:
> > pi@rpi4:~ $ sudo  /usr/lib/cups/backend/snmp
> > network lpd://BRN30055C8A2DC8/BINARY_P1 "Brother MFC-J6920DW"
> > "Brother
> > MFC-J6920DW" "MFG:Brother;CMD:HBP,BRPJL,URF;MDL:MFC-
> > J6920DW;CLS:PRINTER;CID:Brother IJ
> > Type3;URF:SRGB24,W8,CP1,IS1-13,MT1-8-11,OB9,PQ4-5,RS200-300,OFU0,V1.2
> > ,DM4;" "coyote.coyote.den"
> > 
> > The only location identifier is the resolved "coyote.coyote.den"
> > which is this machine.
> > 
> > None of the buster boxes have it, so they all report file not found.
> > BUT they were all installed from a buster respin by the linuxcnc
> > folks. But geany the editor, can drive that printer from any
> > locatiom my cat5 cable reaches.
> > 
> > And I just checked because there is a 2nd printer, another brother
> > HL2320 B duplex capable laser, on this machine, and although the
> > above command only shows one printer, I can feed both printers from
> > geany running on any machine, all 6 of the profiles I have defined
> > are available for geany to use as an output device. I suspect the
> > laser doesn't do snmp, its a $120 printer. Probably some brother
> > version of plc5 since its running on brothers own drivers.
> 
> Thank you, Gene. Your investigations are vey useful and point to my
> forgetfulness.
> 
Your forgetfullness Brian? I'm 87, so it is std proceedure for me to 
either repeat the experiment or spend a couple weeks sorting thru the 
sometimmes decades old stuff in my mental attic, and FWIW I also claim 
any references to oldtimers too. Surely you aren't that ancient. ;-)

> The snmp backend is not installed in the location I gave but has
> to be moved there. Do either
> 
>   mv /usr/lib/cups/backend-available/snmp /usr/lib/cups/backend/snmp
> 
> or
> 
>   dpkg-reconfigure cups
> 
> --
> Brian.
> 
> .


Cheers, Gene Heskett.
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis

Re: CUPS - how to match autodetected printers to physical ones

[Brian]

On Sun 10 Apr 2022 at 21:29:30 +0200, to...@tuxteam.de wrote:

> On Sun, Apr 10, 2022 at 08:19:52PM +0100, Brian wrote:
> 
> [...]
> 
> > > forbidden of trying to do network scans, but the sysadmin wants to
> > > know. I can't blame him (I'm on speaking terms with him ;-)
> > 
> > Not forbidden?
> > 
> >   I know a corporate network or two which would get you disconnected
> >   if you do that :
> > 
> > Disconnected? That doesn't sound permissive.
> 
> In my book, forbidden would mean *you* get disconnected from the
> institution. Your machine disconnected from the network and having
> to do "pretty please" to the admin... I'd say "fair enough". Wouldn't
> be *my* policy, but I can live with that.

I wouldn't say "fair enough", but the dictatorial and irrational
decisions of sysadmins might oblige me to live with that. Just
as I live with the agents of survellance capitalism.
 
> > > > I was once reprimamaned by Amazon for nmapping my own network. That's
> > > > what I call real devotion to stamping out network discovery.
> > > 
> > > Now now. No reprimands. The firewall notices and disables that one port,
> > > That's all.
> > 
> > I was controlled by an inaminte agency? Is that any better than being
> > controlled by an agent of survellance capitalism? Either way, my actions
> > are monitored. My communications are intercepted and censorship applied.
> 
> Could be worse, believe me. At a lower protocol level [1] it's even part
> of the protocol, i.e. mandatory :)

OK, I know when I am beaten into the ground. :)

-- 
Brian.

Re: CUPS - how to match autodetected printers to physical ones

[tomas]

On Sun, Apr 10, 2022 at 08:19:52PM +0100, Brian wrote:

[...]

> > forbidden of trying to do network scans, but the sysadmin wants to
> > know. I can't blame him (I'm on speaking terms with him ;-)
> 
> Not forbidden?
> 
>   I know a corporate network or two which would get you disconnected
>   if you do that :
> 
> Disconnected? That doesn't sound permissive.

In my book, forbidden would mean *you* get disconnected from the
institution. Your machine disconnected from the network and having
to do "pretty please" to the admin... I'd say "fair enough". Wouldn't
be *my* policy, but I can live with that.

> > > I was once reprimamaned by Amazon for nmapping my own network. That's
> > > what I call real devotion to stamping out network discovery.
> > 
> > Now now. No reprimands. The firewall notices and disables that one port,
> > That's all.
> 
> I was controlled by an inaminte agency? Is that any better than being
> controlled by an agent of survellance capitalism? Either way, my actions
> are monitored. My communications are intercepted and censorship applied.

Could be worse, believe me. At a lower protocol level [1] it's even part
of the protocol, i.e. mandatory :)

Cheers
[1] https://en.wikipedia.org/wiki/Ethernet#Jabber
-- 
t


signature.asc
Description: PGP signature

Re: CUPS - how to match autodetected printers to physical ones

[Brian]

On Sun 10 Apr 2022 at 20:39:15 +0200, to...@tuxteam.de wrote:

> On Sun, Apr 10, 2022 at 06:47:36PM +0100, Brian wrote:
> > On Sun 10 Apr 2022 at 15:40:28 +0200, to...@tuxteam.de wrote:
> > 
> > > On Sun, Apr 10, 2022 at 01:40:29PM +0100, Brian wrote:
> > > 
> > > [...]
> > > 
> > > > Many printers provide an snmp (Simple Network Management Protocol)
> > > > service on port 9100. Check with
> > > > 
> > > >   nmap 10.76.172.100
> > > 
> > > I know a corporate network or two which would get you disconnected
> > > if you do that :)
> > > 
> > > Then you've got to go to the firewall admin and beg for being reconnected.
> > > So if you try it, first make sure you are on speaking terms with the
> > > network/firewall admins (a good idea, regardless...)
> > 
> > Strange world we live in! One looks at a shop window and the heavy mob
> > appear to harass you. Survellance capitalism in action? Or the sysadmin
> > is so unsure of the network security in place that it requires drastic
> > and immediate action to prevent a peep at services being offered? :)
> 
> No. The sysadmin has seen folks running around with Kali Linux USB
> sticks and has decided to play safe rather than sorry. Folks are not

"safe rather than sorry"? We see the result of that strategy in Europe
today. The sysadmin has overreacted, presumably because he has little
faith in the security of the network he has devised. How would he react
if he saw folks running around with with Windows USB sticks? :)

> forbidden of trying to do network scans, but the sysadmin wants to
> know. I can't blame him (I'm on speaking terms with him ;-)

Not forbidden?

  I know a corporate network or two which would get you disconnected
  if you do that :

Disconnected? That doesn't sound permissive.

> > I was once reprimamaned by Amazon for nmapping my own network. That's
> > what I call real devotion to stamping out network discovery.
> 
> Now now. No reprimands. The firewall notices and disables that one port,
> That's all.

I was controlled by an inaminte agency? Is that any better than being
controlled by an agent of survellance capitalism? Either way, my actions
are monitored. My communications are intercepted and censorship applied.

-- 
Brian.

-- 
Brian.

Re: CUPS - how to match autodetected printers to physical ones

[The Wanderer]

On 2022-04-10 at 14:25, Brian wrote:

> On Sun 10 Apr 2022 at 08:52:09 -0400, The Wanderer wrote:
> 
>> On 2022-04-10 at 08:38, Brian wrote:
> 
> [...]
> 
>>> The CUPS web interface is not designed to show the IP address but
>>> to display the URI.
>> 
>> This, I think, is exactly the detail that's being complained of. If
>> CUPS knows the IP address, it should be possible to get CUPS to
>> reveal that IP address.
>> 
>> If on the other hand CUPS *doesn't* know the IP address, but only
>> the hostname et cetera (because that's part of the URI, and CUPS
>> only knows/stores the URI), then that might be reasonable.
> 
> CUPS uses the standard networking APIs (getaddrinfo, for example)
> for resolving DNS names to get IP addresses, just like every other
> network service on Linux. CUPS rolling its own DNS resolver would
> cause problems on systems with working resolvers. Why reinvent the
> wheel?

I'm not suggesting that CUPS roll its own DNS resolver.

I'm just suggesting (or, rather, was just assuming) that after having
first learned the IP address during the discovery process, which
probably involves using an external DNS resolver (whether automated or
in the form of sysadmin entering IP address manually), it would cache
that IP address and make use of that cached value rather than repeating
the - presumably relatively expensive - discovery lookup every time.

This was based, at least in part, on the expectation that there
would/will not be DNS lookup for the printer's IP address from its
hostname, since I have rarely if ever seen a network where such lookup
was functioning (never mind one where the printer's hostname was
reliably meaningful or discoverable by any other means than connecting
to it by IP address and asking).

If that expectation was out of sync with reality, then so be it.

> Basically, CUPS leaves it to libnss-mdns. Why should it have any
> record of an IP address when it can easily ask libnss-mdns? We do the
> same with avahi-browse.

Because the lookup will be more expensive than connecting to the IP
address, which is unlikely to have changed - and if it *has* changed,
you've got little or no way of telling whether or not the printer you're
connecting to now is the same one as used to be at the previously-known
address.

>> (My previous comments were based on the assumption that all 
>> communication with the printer would be done based on IP address,
>> rather than on symbolic name and on connect-time resolution. That
>> may in turn be based on my experience in the Windows world, where
>> printer hostnames and DNS lookup are in my experience wildly
>> unreliable and as a consequence are very rarely used; I reflexively
>> expect that the parts of a system which communicate with a printer
>> will always know it primarily, if not exclusively, by its IP
>> address.)
> 
> Of corse the IP address is needed, but not by the user. The user is 
> better served by having the queue name matching the printer.

That depends on what information the user is going to be able to access
about the printer.

I have frequently seen printers which have a front-panel display that
will show the IP address.

I have never, that I recall, seen a printer which has a display that
will readily show the queue name, or the hostname, or any other
seemingly-relevant information about the printer's identity. (Besides
the model, which tends to also be displayed as part of the printer's
physical shell.)

In the case which started this thread, the user had the printer's IP
address (via a label which, I imagine, stood in the stead of such a
display; we also sometimes apply such labels in case the printer loses
its IP address in a power outage and has to have it re-applied), but did
not have the queue name.

Whether or not the queue name matches the printer is irrelevant when the
queue name is not what the user can get from the printer itself.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: CUPS - how to match autodetected printers to physical ones

[tomas]

On Sun, Apr 10, 2022 at 06:47:36PM +0100, Brian wrote:
> On Sun 10 Apr 2022 at 15:40:28 +0200, to...@tuxteam.de wrote:
> 
> > On Sun, Apr 10, 2022 at 01:40:29PM +0100, Brian wrote:
> > 
> > [...]
> > 
> > > Many printers provide an snmp (Simple Network Management Protocol)
> > > service on port 9100. Check with
> > > 
> > >   nmap 10.76.172.100
> > 
> > I know a corporate network or two which would get you disconnected
> > if you do that :)
> > 
> > Then you've got to go to the firewall admin and beg for being reconnected.
> > So if you try it, first make sure you are on speaking terms with the
> > network/firewall admins (a good idea, regardless...)
> 
> Strange world we live in! One looks at a shop window and the heavy mob
> appear to harass you. Survellance capitalism in action? Or the sysadmin
> is so unsure of the network security in place that it requires drastic
> and immediate action to prevent a peep at services being offered? :)

No. The sysadmin has seen folks running around with Kali Linux USB
sticks and has decided to play safe rather than sorry. Folks are not
forbidden of trying to do network scans, but the sysadmin wants to
know. I can't blame him (I'm on speaking terms with him ;-)

> I was once reprimamaned by Amazon for nmapping my own network. That's
> what I call real devotion to stamping out network discovery.

Now now. No reprimands. The firewall notices and disables that one port,
That's all.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: CUPS - how to match autodetected printers to physical ones

[Brian]

On Sun 10 Apr 2022 at 08:52:09 -0400, The Wanderer wrote:

> On 2022-04-10 at 08:38, Brian wrote:

[...]
 
> > The CUPS web interface is not designed to show the IP address but to 
> > display the URI.
> 
> This, I think, is exactly the detail that's being complained of. If CUPS
> knows the IP address, it should be possible to get CUPS to reveal that
> IP address.
> 
> If on the other hand CUPS *doesn't* know the IP address, but only the
> hostname et cetera (because that's part of the URI, and CUPS only
> knows/stores the URI), then that might be reasonable.

CUPS uses the standard networking APIs (getaddrinfo, for example) for
resolving DNS names to get IP addresses, just like every other network
service on Linux. CUPS rolling its own DNS resolver would cause problems
on systems with working resolvers. Why reinvent the wheel?

Basically, CUPS leaves it to libnss-mdns. Why should it have any record
of an IP address when it can easily ask libnss-mdns? We do the same with
avahi-browse.

> (My previous comments were based on the assumption that all
> communication with the printer would be done based on IP address, rather
> than on symbolic name and on connect-time resolution. That may in turn
> be based on my experience in the Windows world, where printer hostnames
> and DNS lookup are in my experience wildly unreliable and as a
> consequence are very rarely used; I reflexively expect that the parts of
> a system which communicate with a printer will always know it primarily,
> if not exclusively, by its IP address.)

Of corse the IP address is needed, but not by the user. The user is
better served by having the queue name matching the printer.

-- 
Brian.

Re: CUPS - how to match autodetected printers to physical ones

[Brian]

On Sun 10 Apr 2022 at 15:40:28 +0200, to...@tuxteam.de wrote:

> On Sun, Apr 10, 2022 at 01:40:29PM +0100, Brian wrote:
> 
> [...]
> 
> > Many printers provide an snmp (Simple Network Management Protocol)
> > service on port 9100. Check with
> > 
> >   nmap 10.76.172.100
> 
> I know a corporate network or two which would get you disconnected
> if you do that :)
> 
> Then you've got to go to the firewall admin and beg for being reconnected.
> So if you try it, first make sure you are on speaking terms with the
> network/firewall admins (a good idea, regardless...)

Strange world we live in! One looks at a shop window and the heavy mob
appear to harass you. Survellance capitalism in action? Or the sysadmin
is so unsure of the network security in place that it requires drastic
and immediate action to prevent a peep at services being offered? :)

I was once reprimamaned by Amazon for nmapping my own network. That's
what I call real devotion to stamping out network discovery.

-- 
Brian.

Re: CUPS - how to match autodetected printers to physical ones

[Brian]

On Sun 10 Apr 2022 at 09:31:59 -0400, gene heskett wrote:

> On Sunday, 10 April 2022 08:54:07 EDT Brian wrote:
> > On Sun 10 Apr 2022 at 05:46:35 -0400, gene heskett wrote:
> > 
> > [...]
> > 
> > > This, FWIW, has nothing to do with cups and printer sharing, cups
> > > does
> > > its own advertising. All printers here are attached to this machine,
> > > marked as shareable and I can put stuff on their output trays from
> > > any
> > > machine including the rpi4 on my local network.
> > 
> > Indeed, CUPS does do its own advertising of print queue and uses
> > mDNS/DNS-SD. That is its *only* technique it has available for
> > sharing the queues.
> > 
> > mDNS/DNS-SD requires avahi-daemon to be active. Without it there
> > isn't any sharing and advertising.
> > 
> > So, I do not understand "...has nothing to do with...".
> > 
> The avahi-daemon has either been removed by rm. or by chmod -x on all 
> machines here, yet cups shared printers (plural) can use those shared 
> printers just as if they were plugged into that machine. So IMO removing 
> or disabling avahi-daemon has nothing to do with cups sharing.
> You are saying it won't work, but it does here. What else is there except 
> cups.

You can print from an rpi4 to a printer attached to another machine on
the network. There are only two ways this can happen:

* The rpi4 knows about the print server via mDNS/DNS-SD.
* There is a manual queue set up on the rpi4.

Only you can decide which it is.

-- 
Brian.

Re: CUPS - how to match autodetected printers to physical ones

[Brian]

On Sun 10 Apr 2022 at 10:05:09 -0400, The Wanderer wrote:

> On 2022-04-10 at 09:54, Brian wrote:
> 
> > The snmp backend is not installed in the location I gave but has
> > to be moved there. Do either
> > 
> >   mv /usr/lib/cups/backend-available/snmp /usr/lib/cups/backend/snmp
> > 
> > or
> > 
> >   dpkg-reconfigure cups
> 
> I've never taken specific action in either of these directions, but on
> my machine, this file exists in both of those locations. I suspect that
> they're actually hardlinked together.
> 
> I imagine that this is probably the result of my choosing a particular
> option when configuring CUPS in the first place, but I have no
> recollection of what option that might have been, nor even specifically
> of having been given any CUPS-related prompts when installing this system.
> 
> The point of which is: it's possible that the default for this might
> actually now be to have this enabled.

TBH, I am not in the mood for deciphering postinst files for cups and
cups-daemon. If the snmp backend file is not where it is on ny stable
and unstable machines, it is easy enough to adjust.

OTOH, reports of the technique I suggested are more than welcome.

-- 
Brian.

Re: CUPS - how to match autodetected printers to physical ones

[The Wanderer]

On 2022-04-10 at 09:54, Brian wrote:

> The snmp backend is not installed in the location I gave but has
> to be moved there. Do either
> 
>   mv /usr/lib/cups/backend-available/snmp /usr/lib/cups/backend/snmp
> 
> or
> 
>   dpkg-reconfigure cups

I've never taken specific action in either of these directions, but on
my machine, this file exists in both of those locations. I suspect that
they're actually hardlinked together.

I imagine that this is probably the result of my choosing a particular
option when configuring CUPS in the first place, but I have no
recollection of what option that might have been, nor even specifically
of having been given any CUPS-related prompts when installing this system.

The point of which is: it's possible that the default for this might
actually now be to have this enabled.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: CUPS - how to match autodetected printers to physical ones

[Brian]

On Sun 10 Apr 2022 at 09:19:43 -0400, gene heskett wrote:

> On Sunday, 10 April 2022 08:40:29 EDT Brian wrote:
> >   /usr/lib/cups/backend/snmp
> The only machine I have here that has that file installed, an rpi4, does 
> not expose the printers address, only:
> pi@rpi4:~ $ sudo  /usr/lib/cups/backend/snmp
> network lpd://BRN30055C8A2DC8/BINARY_P1 "Brother MFC-J6920DW" "Brother 
> MFC-J6920DW" "MFG:Brother;CMD:HBP,BRPJL,URF;MDL:MFC-
> J6920DW;CLS:PRINTER;CID:Brother IJ 
> Type3;URF:SRGB24,W8,CP1,IS1-13,MT1-8-11,OB9,PQ4-5,RS200-300,OFU0,V1.2,DM4;" 
> "coyote.coyote.den"
> 
> The only location identifier is the resolved "coyote.coyote.den" which is 
> this machine.
> 
> None of the buster boxes have it, so they all report file not found. BUT 
> they were all installed from a buster respin by the linuxcnc folks. But 
> geany the editor, can drive that printer from any locatiom my cat5 cable 
> reaches.
> 
> And I just checked because there is a 2nd printer, another brother HL2320 
> B duplex capable laser, on this machine, and although the above command 
> only shows one printer, I can feed both printers from geany running on 
> any machine, all 6 of the profiles I have defined are available for geany 
> to use as an output device. I suspect the laser doesn't do snmp, its a 
> $120 printer. Probably some brother version of plc5 since its running on 
> brothers own drivers.

Thank you, Gene. Your investigations are vey useful and point to my
forgetfulness.

The snmp backend is not installed in the location I gave but has
to be moved there. Do either

  mv /usr/lib/cups/backend-available/snmp /usr/lib/cups/backend/snmp

or

  dpkg-reconfigure cups

-- 
Brian.

Re: CUPS - how to match autodetected printers to physical ones

[tomas]

On Sun, Apr 10, 2022 at 01:40:29PM +0100, Brian wrote:

[...]

> Many printers provide an snmp (Simple Network Management Protocol)
> service on port 9100. Check with
> 
>   nmap 10.76.172.100

I know a corporate network or two which would get you disconnected
if you do that :)

Then you've got to go to the firewall admin and beg for being reconnected.
So if you try it, first make sure you are on speaking terms with the
network/firewall admins (a good idea, regardless...)

So careful.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: CUPS - how to match autodetected printers to physical ones

[Brian]

On Sun 10 Apr 2022 at 08:10:17 -0400, gene heskett wrote:

> On Sunday, 10 April 2022 07:17:42 EDT The Wanderer wrote:
> > On 2022-04-10 at 07:08, gene heskett wrote:
> > > On Sunday, 10 April 2022 06:06:31 EDT to...@tuxteam.de wrote:
> > >> I just don't install it.
> > > 
> > > And how do you accomplish that? Its automatically installed AFAIK.
> > > And once installed, apt will not remove it without destroying the
> > > install. rm or chmod -x seems to be the only way, and nothing
> > > complains.
> > 
> > What package(s), by exact name, are you referring to? That is, which
> > package(s) is it that produce this effect when you try to remove them?
> > 
> > On my computer, I have several libavahi* packages, which could not be
> > removed without removing large swaths of packages - but I also have
> > avahi-daemon and avahi-utils, which can be removed with few if any side
> > effects (as far as triggering removal of other packages goes).
> > 
> > And since the subject at hand in this branch of the thread appears to
> > be avahi-daemon, surely removing that single package should be enough
> > to prevent avahi from doing anything undesirable?
> 
> Which IMO It should be but apt will not remove avahi-daemon on any of my 
> buster machines  or on bullseye without taking "large swaths" of stuff 
> with it.
> 
> Tomas just found, and I have now edited /etc/default/avahi-daemon to 
> officialy shut it off, ditto for brytty, leaving a killed orca spewing 20 

I do not think AVAHI_DAEMON_DETECT_LOCAL does what you think it does.
It applies to detection of *unicast* dns servers.

-- 
Brian.

Re: CUPS - how to match autodetected printers to physical ones

[gene heskett]

On Sunday, 10 April 2022 08:54:07 EDT Brian wrote:
> On Sun 10 Apr 2022 at 05:46:35 -0400, gene heskett wrote:
> 
> [...]
> 
> > This, FWIW, has nothing to do with cups and printer sharing, cups
> > does
> > its own advertising. All printers here are attached to this machine,
> > marked as shareable and I can put stuff on their output trays from
> > any
> > machine including the rpi4 on my local network.
> 
> Indeed, CUPS does do its own advertising of print queue and uses
> mDNS/DNS-SD. That is its *only* technique it has available for
> sharing the queues.
> 
> mDNS/DNS-SD requires avahi-daemon to be active. Without it there
> isn't any sharing and advertising.
> 
> So, I do not understand "...has nothing to do with...".
> 
The avahi-daemon has either been removed by rm. or by chmod -x on all 
machines here, yet cups shared printers (plural) can use those shared 
printers just as if they were plugged into that machine. So IMO removing 
or disabling avahi-daemon has nothing to do with cups sharing.
You are saying it won't work, but it does here. What else is there except 
cups.

> --
> Brian.
> 
> .


Cheers, Gene Heskett.
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis

Re: CUPS - how to match autodetected printers to physical ones

[gene heskett]

On Sunday, 10 April 2022 08:40:29 EDT Brian wrote:
>   /usr/lib/cups/backend/snmp
The only machine I have here that has that file installed, an rpi4, does 
not expose the printers address, only:
pi@rpi4:~ $ sudo  /usr/lib/cups/backend/snmp
network lpd://BRN30055C8A2DC8/BINARY_P1 "Brother MFC-J6920DW" "Brother 
MFC-J6920DW" "MFG:Brother;CMD:HBP,BRPJL,URF;MDL:MFC-
J6920DW;CLS:PRINTER;CID:Brother IJ 
Type3;URF:SRGB24,W8,CP1,IS1-13,MT1-8-11,OB9,PQ4-5,RS200-300,OFU0,V1.2,DM4;" 
"coyote.coyote.den"

The only location identifier is the resolved "coyote.coyote.den" which is 
this machine.

None of the buster boxes have it, so they all report file not found. BUT 
they were all installed from a buster respin by the linuxcnc folks. But 
geany the editor, can drive that printer from any locatiom my cat5 cable 
reaches.

And I just checked because there is a 2nd printer, another brother HL2320 
B duplex capable laser, on this machine, and although the above command 
only shows one printer, I can feed both printers from geany running on 
any machine, all 6 of the profiles I have defined are available for geany 
to use as an output device. I suspect the laser doesn't do snmp, its a 
$120 printer. Probably some brother version of plc5 since its running on 
brothers own drivers.

Cheers Brian, Gene Heskett.
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis

Re: CUPS - how to match autodetected printers to physical ones

[Brian]

On Sun 10 Apr 2022 at 05:46:35 -0400, gene heskett wrote:

[...]

> This, FWIW, has nothing to do with cups and printer sharing, cups does 
> its own advertising. All printers here are attached to this machine, 
> marked as shareable and I can put stuff on their output trays from any 
> machine including the rpi4 on my local network.

Indeed, CUPS does do its own advertising of print queue and uses
mDNS/DNS-SD. That is its *only* technique it has available for
sharing the queues.

mDNS/DNS-SD requires avahi-daemon to be active. Without it there
isn't any sharing and advertising.

So, I do not understand "...has nothing to do with...".

-- 
Brian.

Re: CUPS - how to match autodetected printers to physical ones

[The Wanderer]

On 2022-04-10 at 08:38, Brian wrote:

> On Sat 09 Apr 2022 at 20:21:12 -0400, The Wanderer wrote:
> 
>> On 2022-04-09 at 07:56, Brian wrote:

>>> It is straightforward, I don't know about obvious to all users.
>>> 
>>> avahi-browse -rt _ipp._tcp
>> 
>> Does that get the information from CUPS?
>> 
>> It looks to me as if it gets the information from the network, via
>> what are probably the same discovery methods as CUPS used to get
>> it.
>> 
>> That's not the same as getting the information *from CUPS*, which
>> must logically already have that information.
>> 
>> Having a way to get the information at all (and we already seem to
>> have at least two of those, from this thread, one of them being the
>> one you just cited) is not the same as having a way to get the
>> information *from where it must logically already be*, and the
>> apparent lack of the latter is what's bothering me about the
>> described behavior.
> 
> CUPS delegates resolution of hosts and services to mDNS; I am happy 
> to follow in its footsteps.
> 
> CUPS may very well know the IP address but it is not of direct
> interest to the user,

That will very definitely vary depending on the user.

> who is better served by being informed of the URI.

This may be true in some cases, but is very definitely not true in all.

> For various reasons, IP addresses can change, of course; printers
> being moved round the network, for example.

This is based on a set of assumptions which may apply in some cases, but
very definitely do not apply in all cases. I don't want to dive deep
into them, however, since this has already gone on long enough.

>>> CUPS uses mDNS/DNS-sd for discovery. The user does the same:
>>> 
>>> avahi-browse -rt _ipp._tcp
>> 
>> This seems to be confirming the hypothesis above: that this is not 
>> getting CUPS to reveal the information, but performing the same 
>> discovery method that CUPS used to get the information.
> 
> Yes.
> 
>> If, for example, the printer was online when CUPS discovered it and
>> is therefore listed in the CUPS interface, but is offline now
>> (perhaps someone accidentally unplugged the network cable from the
>> printer?), I would be mildly surprised if this would still result
>> in showing the IP address of the printer. CUPS, however, must still
>> have that address, from its past discovery.
> 
> The CUPS web interface is not designed to show the IP address but to 
> display the URI.

This, I think, is exactly the detail that's being complained of. If CUPS
knows the IP address, it should be possible to get CUPS to reveal that
IP address.

If on the other hand CUPS *doesn't* know the IP address, but only the
hostname et cetera (because that's part of the URI, and CUPS only
knows/stores the URI), then that might be reasonable.

(My previous comments were based on the assumption that all
communication with the printer would be done based on IP address, rather
than on symbolic name and on connect-time resolution. That may in turn
be based on my experience in the Windows world, where printer hostnames
and DNS lookup are in my experience wildly unreliable and as a
consequence are very rarely used; I reflexively expect that the parts of
a system which communicate with a printer will always know it primarily,
if not exclusively, by its IP address.)

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: CUPS - how to match autodetected printers to physical ones

[gene heskett]

On Sunday, 10 April 2022 08:02:32 EDT to...@tuxteam.de wrote:
> On Sun, Apr 10, 2022 at 07:46:37AM -0400, gene heskett wrote:
> > On Sunday, 10 April 2022 06:06:31 EDT to...@tuxteam.de wrote:
> > > AVAHI_DAEMON_DETECT_LOCAL=0 into some /etc/default/avahi-daemon.
> > 
> > Checking all my machines, all but one was set to 1, fixed the others
> > and redid the initramfs as it said in 2 of the 5, in that file.
> > 
> > Thank you for that Tomas, now its done by the official way including
> > on this bullseye box. I also took advantage and disabled brltty by
> > similar means. That leaves orca dirtying the logs with about 20
> > lines every 15 seconds. And that leads to a reboot about weekly by
> > filling up the /var partition. Orca however, does not appear in
> > /etc/default. Where is it started so I can officially stop it? That
> > would extend my uptimes I expect.
> 
> As it came out in That Other Thread :) I think this is some rogue USB
> serial adapter fooling udev that it is a Braille input. Find that, fix
> your udev rules (or dump the adapter).
> 
> Background: whenever you stick an USB into your device tree, it tells
> udev "hi, I'm a new mouse". Or a "memory stick". Or "a camera". But
> of course, this comes roundabout: it tells the maker and the maker's
> device model as a pair of numbers.
> 
> There's a lot of things which may go wrong there: from an inexact
> device database to some cheap manufacturer skimping on the USB
> consortium membership and squatting on wrong identifiers.
> 
Or even ducks the issue by all-balling the identifiers. Those most often 
encountered looking like a usb key gismo and soon find the trash can.

But since fdti is the only maker of seriel adaptors that actually works, 
proliic tried but failed miserably, I see no reason not to reach thru the 
adaptor and see if its actually a braille device, rather that blindly 
assuming it is when there are many other often legacy devices that need 
the adaptor. The cm11a to control your lights and appliances interface is 
likely at least 30 years old, and the protocol was known in the mid 80's. 
I wrote software in the late 80's to do that from a trs-80 Color Computer 
running os9-level one, then jim hines and I moved it to amigados using 
ARexx and sold registered copies of it for a few years.  Called it ezhome 
based on something else we wrote called ezcron since amigados had no cron 
utility. We gave that away.
 
> Once we have more details perhaps someone can lead you through the
> process. But test-booting the thing while some USB devices are
> unplugged until you find the culprit is something only you can do.

True Tomas, but my attempts to install w/o it have all failed as it will 
not reboot without it so a reboot turns into a new install, 20 some times 
now, which I'm sick of doing, hence my questions that keep harping on 
getting rid of it gracefully AFTER the install. Basicly, whats done 
should have an undo method and I will keep asking until the magic phrase 
comes out of someones fingertips. In the meantime I am reminded of it by 
the need to reboot weekly in order to have a usable machine.

> Hint: binary search may be helpful (unstick first half of the USBs
> and so on).
> 
> Cheers
> --
> t
Take care and stay well, Tomas.


Cheers, Gene Heskett.
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis

Re: CUPS - how to match autodetected printers to physical ones

[Brian]

On Fri 08 Apr 2022 at 13:22:26 -0400, Greg Wooledge wrote:

> On Fri, Apr 08, 2022 at 06:03:47PM +0100, Tixy wrote:
> > On Fri, 2022-04-08 at 17:59 +0100, Tixy wrote:
> > > On Fri, 2022-04-08 at 12:10 -0400, Greg Wooledge wrote:
> > > > Unfortunately, I was not able to find ANY way to determine the IP
> > > > addresses of the autodetected printers that were presented to me.
> > > 
> > > If I go to http://localhost:631/printers/
> > 
> > I should say I got to that URL from the CUPs interface at
> > http://localhost:631/ then clicking the 'Admininitation' tab at the top
> > followed by the 'Manage Printers' button on the page that showed.
> 
> Here is what I have on that page:
> 
> =
> Showing 7 of 7 printers.
> 
> Queue NameDescription LocationMake and Model  Status
> Canon_LBP351dn_f9_7a_4a_  CNLBP712C CNLBP712C, 
> driverless, cups-filters 1.28.7Idle
> Canon_LBP712Cdn_db_c0_d3_ Canon_LBP712Cdn_db_c0_d3_   
> CNLBP712C CNLBP712C, driverless, cups-filters 1.28.7Idle
> Cups_PDF_oc3261540276 Cups_PDF_oc3261540276   Local Raw Printer   
> Paused
> HP_LaserJet_4100_Series_0001E6A68D3D_ HP_LaserJet_4100_Series_0001E6A68D3D_   
> HP LaserJet 4100 Series , driverless, cups-filters 1.28.7   Idle
> hp_LaserJet_4250_621E13_  hp_LaserJet_4250_621E13_hp 
> LaserJet 4250, driverless, cups-filters 1.28.7   Idle
> HP_LaserJet_P3010_Series_0FCDD7_  HP_LaserJet_P3010_Series_0FCDD7_
> HP LaserJet P3010 Series, driverless, cups-filters 1.28.7   Idle
> PostScript_oc3261540276   PostScript_oc3261540276 Local Raw 
> Printer   Paused
> =

[...]

> Looking at the stuff that I pasted here, how am I supposed to know whether
> this corresponds to the physical printer with IP address 10.76.172.100?

Another idea that may or may not grip you. It's not guaranteed to
work ( whereas the avahi-browse command should be reliable) but it
could be worth a try.

Many printers provide an snmp (Simple Network Management Protocol)
service on port 9100. Check with

  nmap 10.76.172.100

It would be unusual for the service not to be offered because it
dates from the dawn of time and is very simple to implement. There
isn't any reliance on avahi-daemon (just TCP/IP) and it works with
non-ipp printers.

Execute

  /usr/lib/cups/backend/snmp

The output should include an IP address and a printer make and model.

Thanks to The Wanderer for sparking this thought.

-- 
Brian.

Re: CUPS - how to match autodetected printers to physical ones

[Brian]

On Sat 09 Apr 2022 at 20:21:12 -0400, The Wanderer wrote:

> On 2022-04-09 at 07:56, Brian wrote:
> 
> > On Fri 08 Apr 2022 at 19:45:41 -0400, The Wanderer wrote:
> > 
> >> (This is probably both overly long and overly repetitive, among
> >> possibly other undesirable things, but I'm running short on time.)
> > 
> > So I hope you do not mind if I do not reply to every point you make.
> 
> I don't strongly mind that, no. A few of them were probably rephrasings
> of the same thing in different ways.
> 
> >> On 2022-04-08 at 18:44, Brian wrote:
> 
> 
> 
> >> What Greg was asking about, as far as I can tell, is a way to get
> >> CUPS to tell him that network-location information - so that he, as
> >> someone external to the printing system, could then apply that
> >> information to his additional knowledge about the physical location
> >> of the printer with a specific IP address.
> >> 
> >> I'm not sure we (in this thread) have yet found a way to do that 
> >> directly; we've found what appear to be two different ways to find
> >> the IP address of the printer with the name that CUPS is reporting,
> >> but it looks to me as if both of them are getting that information
> >> via an external method (probably similar to how CUPS found the
> >> printer in the first place), rather than getting that information
> >> from CUPS itself.
> >> 
> >> The IP-address (etc.?) information must exist within CUPS, since
> >> CUPS is able to actually send jobs to the printer; why isn't it
> >> straightforward and obvious how to get that information *from*
> >> within CUPS *to* someplace visible?
> > 
> > It is straightforward, I don't know about obvious to all users.
> > 
> > avahi-browse -rt _ipp._tcp
> 
> Does that get the information from CUPS?
> 
> It looks to me as if it gets the information from the network, via what
> are probably the same discovery methods as CUPS used to get it.
> 
> That's not the same as getting the information *from CUPS*, which must
> logically already have that information.
> 
> Having a way to get the information at all (and we already seem to have
> at least two of those, from this thread, one of them being the one you
> just cited) is not the same as having a way to get the information *from
> where it must logically already be*, and the apparent lack of the latter
> is what's bothering me about the described behavior.

CUPS delegates resolution of hosts and services to mDNS; I am happy
to follow in its footsteps.

CUPS may very well know the IP address but it is not of direct interest
to the user, who is better served by being informed of the URI. For
various reasons, IP addresses can change, of course; printers being moved
round the network, for example.
 
> >>> CUPS knows how to route the job. The physical location of the 
> >>> printer is not involved in the routeing.
> >> 
> >> True, and I don't understand why you thought it was involved (as
> >> relates to CUPS) at all.
> >> 
> >> The IP address, however, *is* involved in the routing - and
> >> therefore CUPS must know it. (Or some proxy piece of information,
> >> as above.)
> >> 
> >> The original question as I understand it was how to get CUPS to
> >> reveal that piece of information which it must know.
> > 
> > CUPS uses mDNS/DNS-sd for discovery. The user does the same:
> > 
> > avahi-browse -rt _ipp._tcp
> 
> This seems to be confirming the hypothesis above: that this is not
> getting CUPS to reveal the information, but performing the same
> discovery method that CUPS used to get the information.

Yes.
 
> If, for example, the printer was online when CUPS discovered it and is
> therefore listed in the CUPS interface, but is offline now (perhaps
> someone accidentally unplugged the network cable from the printer?), I
> would be mildly surprised if this would still result in showing the IP
> address of the printer. CUPS, however, must still have that address,
> from its past discovery.

The CUPS web interface is not designed to show the IP address but to
display the URI. However, the URI might give an IP address if it is
a socket://... or lpd://... URI.

An offlin machine would continue to list information for manually
set up queues.

If CUPS retains an address of a previous connection, I am not aware
of a way to extract it

> >>>> What I understood Greg as asking about is how to get CUPS to
> >>>> *tell* you what the IP address it knows about for a given
> >>>> printer object is. That doesn't seem to be an unreasonabl

Re: CUPS - how to match autodetected printers to physical ones

[The Wanderer]

On 2022-04-10 at 08:10, gene heskett wrote:

> On Sunday, 10 April 2022 07:17:42 EDT The Wanderer wrote:
> 
>> On 2022-04-10 at 07:08, gene heskett wrote:

>>> And how do you accomplish that? Its automatically installed
>>> AFAIK. And once installed, apt will not remove it without
>>> destroying the install. rm or chmod -x seems to be the only way,
>>> and nothing complains.
>> 
>> What package(s), by exact name, are you referring to? That is,
>> which package(s) is it that produce this effect when you try to
>> remove them?
>> 
>> On my computer, I have several libavahi* packages, which could not
>> be removed without removing large swaths of packages - but I also
>> have avahi-daemon and avahi-utils, which can be removed with few if
>> any side effects (as far as triggering removal of other packages
>> goes).
>> 
>> And since the subject at hand in this branch of the thread appears
>> to be avahi-daemon, surely removing that single package should be
>> enough to prevent avahi from doing anything undesirable?
> 
> Which IMO It should be but apt will not remove avahi-daemon on any of
> my buster machines  or on bullseye without taking "large swaths" of
> stuff with it.

Based on what Tomas said in his reply, I'm guessing that that's because
you've got GNOME or some similar fancy DE installed, and that DE's
packages declare a dependency on avahi-daemon directly.

I don't use such a DE (preferring, instead, a WM so niche that it's not
even packaged and in the repositories anymore), so it's no surprise that
I wouldn't see that effect - and also, if you do, no surprise that you
would.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: CUPS - how to match autodetected printers to physical ones

[gene heskett]

On Sunday, 10 April 2022 07:17:42 EDT The Wanderer wrote:
> On 2022-04-10 at 07:08, gene heskett wrote:
> > On Sunday, 10 April 2022 06:06:31 EDT to...@tuxteam.de wrote:
> >> I just don't install it.
> > 
> > And how do you accomplish that? Its automatically installed AFAIK.
> > And once installed, apt will not remove it without destroying the
> > install. rm or chmod -x seems to be the only way, and nothing
> > complains.
> 
> What package(s), by exact name, are you referring to? That is, which
> package(s) is it that produce this effect when you try to remove them?
> 
> On my computer, I have several libavahi* packages, which could not be
> removed without removing large swaths of packages - but I also have
> avahi-daemon and avahi-utils, which can be removed with few if any side
> effects (as far as triggering removal of other packages goes).
> 
> And since the subject at hand in this branch of the thread appears to
> be avahi-daemon, surely removing that single package should be enough
> to prevent avahi from doing anything undesirable?

Which IMO It should be but apt will not remove avahi-daemon on any of my 
buster machines  or on bullseye without taking "large swaths" of stuff 
with it.

Tomas just found, and I have now edited /etc/default/avahi-daemon to 
officialy shut it off, ditto for brytty, leaving a killed orca spewing 20 
lines of errors into the log every 15 seconds until it takes so long to 
append the log that the machine is unusable for over 30 seconds at a time 
and must be rebooted about weekly to recover, all because the installer 
thinks ANY usb to seriel adaptor plugged in is driving a braille 
interface. Theres a lot of other reasons to have such on a system, and in 
fact I have 2 of them, one serviceing my ups, and one servicing a cm-11a 
interface for heyu. I dare say that is a more common a use than a braille 
interface. Or a speech synth that isn't understandable, which category 
orca certainly is in.

So I'll repeat my request as to how do I turn off orca AND get rid of the 
every 15 second error spew to the log because its been killed?

> --
>The Wanderer
> 
> The reasonable man adapts himself to the world; the unreasonable one
> persists in trying to adapt the world to himself. Therefore all
> progress depends on the unreasonable man. -- George Bernard
> Shaw


Cheers, Gene Heskett.
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis

Re: CUPS - how to match autodetected printers to physical ones

[tomas]

On Sun, Apr 10, 2022 at 07:46:37AM -0400, gene heskett wrote:
> On Sunday, 10 April 2022 06:06:31 EDT to...@tuxteam.de wrote:
> 
> > AVAHI_DAEMON_DETECT_LOCAL=0 into some /etc/default/avahi-daemon.
> 
> Checking all my machines, all but one was set to 1, fixed the others and 
> redid the initramfs as it said in 2 of the 5, in that file.
> 
> Thank you for that Tomas, now its done by the official way including on 
> this bullseye box. I also took advantage and disabled brltty by similar 
> means. That leaves orca dirtying the logs with about 20 lines every 15 
> seconds. And that leads to a reboot about weekly by filling up the /var 
> partition. Orca however, does not appear in /etc/default. Where is it 
> started so I can officially stop it? That would extend my uptimes I 
> expect.

As it came out in That Other Thread :) I think this is some rogue USB
serial adapter fooling udev that it is a Braille input. Find that, fix
your udev rules (or dump the adapter).

Background: whenever you stick an USB into your device tree, it tells
udev "hi, I'm a new mouse". Or a "memory stick". Or "a camera". But
of course, this comes roundabout: it tells the maker and the maker's
device model as a pair of numbers.

There's a lot of things which may go wrong there: from an inexact device
database to some cheap manufacturer skimping on the USB consortium
membership and squatting on wrong identifiers.

Once we have more details perhaps someone can lead you through the
process. But test-booting the thing while some USB devices are
unplugged until you find the culprit is something only you can do.

Hint: binary search may be helpful (unstick first half of the USBs
and so on).

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: CUPS - how to match autodetected printers to physical ones

[tomas]

On Sun, Apr 10, 2022 at 07:17:42AM -0400, The Wanderer wrote:
> On 2022-04-10 at 07:08, gene heskett wrote:
> 
> > On Sunday, 10 April 2022 06:06:31 EDT to...@tuxteam.de wrote:
> 
> >> I just don't install it.
> > 
> > And how do you accomplish that? Its automatically installed AFAIK.
> > And once installed, apt will not remove it without destroying the
> > install. rm or chmod -x seems to be the only way, and nothing
> > complains.
> 
> What package(s), by exact name, are you referring to? That is, which
> package(s) is it that produce this effect when you try to remove them?
> 
> On my computer, I have several libavahi* packages, which could not be
> removed without removing large swaths of packages - but I also have
> avahi-daemon and avahi-utils, which can be removed with few if any side
> effects (as far as triggering removal of other packages goes).

The lib* things are different. That's the price we pay for a binary
distribution. I have quite a few libsystemd around. The alternative
would be to compile everything.

I'm not that uncompromising :)

> And since the subject at hand in this branch of the thread appears to be
> avahi-daemon, surely removing that single package should be enough to
> prevent avahi from doing anything undesirable?

Yes, that would be the one implementing zeroconf.

As I see, gnome is listed as avahi-daemon dependency. So that could be
what happens to Gene. "I'm going to remove Gnome now" does sound scary :)

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: CUPS - how to match autodetected printers to physical ones

[tomas]

On Sun, Apr 10, 2022 at 07:08:36AM -0400, gene heskett wrote:
> On Sunday, 10 April 2022 06:06:31 EDT to...@tuxteam.de wrote:

[...]

> > be putting AVAHI_DAEMON_DETECT_LOCAL=0 into some
> > /etc/default/avahi-daemon.
> 
> Then whyintarnation does it not say that in what serves as a man page?

Sometimes systems become... complex. I guess (just guess) that avahi-daemon
has some command-line parameters to manage that. Those would be in the
man page.

The /etc/default hierarchy is rather a Debian-specific things to provide
start-up options to system-wide services (and also to the boot process).
Those are picked up from there.

> > No need to rm it. But if it satisfies you, you're your box's boss :)
> 
> Exactly.
>  
> > I just don't install it.
> 
> And how do you accomplish that? Its automatically installed AFAIK. And 
> once installed, apt will not remove it without destroying the install. rm 
> or chmod -x seems to be the only way, and nothing complains. 

There are things depending on avahi. I don't need them. I've to jump
through some hoops to keep systemd or dbus to be installed (but it's
manageable), but avahi hasn't ever tried, yet :-)

Current desktop environments won't like that, mind you. But I don't
particularly like them, either.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: CUPS - how to match autodetected printers to physical ones

[gene heskett]

On Sunday, 10 April 2022 06:06:31 EDT to...@tuxteam.de wrote:

> AVAHI_DAEMON_DETECT_LOCAL=0 into some /etc/default/avahi-daemon.

Checking all my machines, all but one was set to 1, fixed the others and 
redid the initramfs as it said in 2 of the 5, in that file.

Thank you for that Tomas, now its done by the official way including on 
this bullseye box. I also took advantage and disabled brltty by similar 
means. That leaves orca dirtying the logs with about 20 lines every 15 
seconds. And that leads to a reboot about weekly by filling up the /var 
partition. Orca however, does not appear in /etc/default. Where is it 
started so I can officially stop it? That would extend my uptimes I 
expect.

Thanks Tomas.


Cheers, Gene Heskett.
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis

Re: CUPS - how to match autodetected printers to physical ones

[The Wanderer]

On 2022-04-10 at 07:08, gene heskett wrote:

> On Sunday, 10 April 2022 06:06:31 EDT to...@tuxteam.de wrote:

>> I just don't install it.
> 
> And how do you accomplish that? Its automatically installed AFAIK.
> And once installed, apt will not remove it without destroying the
> install. rm or chmod -x seems to be the only way, and nothing
> complains.

What package(s), by exact name, are you referring to? That is, which
package(s) is it that produce this effect when you try to remove them?

On my computer, I have several libavahi* packages, which could not be
removed without removing large swaths of packages - but I also have
avahi-daemon and avahi-utils, which can be removed with few if any side
effects (as far as triggering removal of other packages goes).

And since the subject at hand in this branch of the thread appears to be
avahi-daemon, surely removing that single package should be enough to
prevent avahi from doing anything undesirable?

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: CUPS - how to match autodetected printers to physical ones

[gene heskett]

On Sunday, 10 April 2022 06:06:31 EDT to...@tuxteam.de wrote:
> On Sun, Apr 10, 2022 at 05:46:35AM -0400, gene heskett wrote:
> 
> [...]
> 
> > Then why, after a decade and change of bitching about it because it
> > insists on putting a 169.254.xx,yy address in ones routing table that
> > only removing avahi fixes, has it not been fixed?
> 
> This would be an IPv4 link-local [0] address. Correctly naming
> things is always the first step to taking control over them:
> casting spells and that ;-)
> 
> Setting that up is zeroconf's [1] job, which, AFAIK, is actually
> done by the avahi daemon. I can't check it myself, because my
> box has no avahi.
> 
> But if you know how the thing's called, you can throw your spells
> at a search engine (hopefully not the one of survellance capitalism,
> but I disgress ;-) and find things like [2]. It tells you how to
> convince different systems to not do that; under Debian, this would
> be putting AVAHI_DAEMON_DETECT_LOCAL=0 into some
> /etc/default/avahi-daemon.

Then whyintarnation does it not say that in what serves as a man page?

> No need to rm it. But if it satisfies you, you're your box's boss :)

Exactly.
 
> I just don't install it.

And how do you accomplish that? Its automatically installed AFAIK. And 
once installed, apt will not remove it without destroying the install. rm 
or chmod -x seems to be the only way, and nothing complains. 

> Cheers
> --
> t

Take care and stay well Tomas.

Cheers, Gene Heskett.
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis

Re: CUPS - how to match autodetected printers to physical ones

[tomas]

On Sun, Apr 10, 2022 at 05:46:35AM -0400, gene heskett wrote:

[...]

> Then why, after a decade and change of bitching about it because it 
> insists on putting a 169.254.xx,yy address in ones routing table that 
> only removing avahi fixes, has it not been fixed?

This would be an IPv4 link-local [0] address. Correctly naming
things is always the first step to taking control over them:
casting spells and that ;-)

Setting that up is zeroconf's [1] job, which, AFAIK, is actually
done by the avahi daemon. I can't check it myself, because my
box has no avahi.

But if you know how the thing's called, you can throw your spells
at a search engine (hopefully not the one of survellance capitalism,
but I disgress ;-) and find things like [2]. It tells you how to
convince different systems to not do that; under Debian, this would
be putting AVAHI_DAEMON_DETECT_LOCAL=0 into some /etc/default/avahi-daemon.

No need to rm it. But if it satisfies you, you're your box's boss :)

I just don't install it.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: CUPS - how to match autodetected printers to physical ones

[gene heskett]

On Sunday, 10 April 2022 02:33:21 EDT to...@tuxteam.de wrote:
> On Sat, Apr 09, 2022 at 08:21:12PM -0400, The Wanderer wrote:
> 
> [...]
> 
> > I honestly don't know the subject very well myself, but I'd
> > definitely
> > like to know it better than I do.
> > 
> > One aspect of Windows printer sharing is that it makes it possible to
> > connect a printer not directly to the network, but locally to a
> > particular computer, and then configure that computer to advertise
> > the
> > printer over the network. Other computers can then send jobs to that
> > printer via that computer, which is de-facto a print server for that
> > printer.
> > 
> > Do you know whether CUPS is capable of interacting with printers
> > which
> > are shared in that way? (This is a tangent to the topic of the
> > thread,
> > but it fits this local context and it's a thing I'd be interested
> > in.)
> 
> If that local printer is known to CUPS and the local sysadmin has
> marked it as shareable (however you do that in CUPS), that would,
> as I have understood it, be Avahi's job, which is a service
> (advertisement and) discovery protocol.
 
Then why, after a decade and change of bitching about it because it 
insists on putting a 169.254.xx,yy address in ones routing table that 
only removing avahi fixes, has it not been fixed?  You can spec the 
correct address other places such as in /etc/networking/interfaces.d/
anyfilename, or in the last two paragraphs of /etc/dhcpcd.conf, but if 
avahi is executable, it will override your settings and kill your 
networking setup dead in the water. 

And what I mean is that removing it is done behind apt's back by hunting 
it down and rm-ing it. apt will not remove it w/o destroying the rest of 
the system. 

For those of us using hosts files for networking on our little home 
networks of less that say 16 machines, avahi is the first thing we hunt 
down and rm after the installers reboot. Only then can we spec a 
192.168.xx.yy address to our local gateway and make it stick.

Of note is that NOTHING else in the system considers a missing avahi as a 
loggable event.

ONLY apt thinks it is valuable enough to cause its dependencies to 
destroy the system if you try to remove it with apt as the package 
manager.

Which suits me just fine as its been a headache, looking for a problem 
that does not exist since it came on the scene. Here, at the coyote.den 
domain, it does not exist in executable form.

Except to pull my trigger when someone recommends that broken concept 
utility for anything.

This, FWIW, has nothing to do with cups and printer sharing, cups does 
its own advertising. All printers here are attached to this machine, 
marked as shareable and I can put stuff on their output trays from any 
machine including the rpi4 on my local network.

The missing avahi has nothing to do with that. The only disadvantage is 
the long walk to retrieve the printout, but I probably needed the 
exercise anyway.

> Cheers
> --
> t


Cheers, Gene Heskett.
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis

Re: CUPS - how to match autodetected printers to physical ones

[tomas]

On Sat, Apr 09, 2022 at 08:21:12PM -0400, The Wanderer wrote:

[...]

> I honestly don't know the subject very well myself, but I'd definitely
> like to know it better than I do.
> 
> One aspect of Windows printer sharing is that it makes it possible to
> connect a printer not directly to the network, but locally to a
> particular computer, and then configure that computer to advertise the
> printer over the network. Other computers can then send jobs to that
> printer via that computer, which is de-facto a print server for that
> printer.
> 
> Do you know whether CUPS is capable of interacting with printers which
> are shared in that way? (This is a tangent to the topic of the thread,
> but it fits this local context and it's a thing I'd be interested in.)

If that local printer is known to CUPS and the local sysadmin has
marked it as shareable (however you do that in CUPS), that would,
as I have understood it, be Avahi's job, which is a service (advertisement
and) discovery protocol.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: CUPS - how to match autodetected printers to physical ones

[Teemu Likonen]

* 2022-04-10 03:59:25+0100, mick crane wrote:

> On 2022-04-10 01:21, The Wanderer wrote:
>>> avahi-browse -rt _ipp._tcp
>> 
>> Does that get the information from CUPS?
>
> With printer connected via other PC (CUPS print server) there is no 
> output from "avahi-browse -rt _ipp._tcp"

Should be, if the print server has setting "Share printers connected to
this system". Obviously Cups and Avahi must be running on machines in
the same network.

-- 
/// Teemu Likonen - .-.. https://www.iki.fi/tlikonen/
// OpenPGP: 6965F03973F0D4CA22B9410F0F2CAE0E07608462


signature.asc
Description: PGP signature

Re: CUPS - how to match autodetected printers to physical ones

[mick crane]

On 2022-04-10 01:21, The Wanderer wrote:


avahi-browse -rt _ipp._tcp


Does that get the information from CUPS?


With printer connected via other PC (CUPS print server) there is no 
output from "avahi-browse -rt _ipp._tcp"


mick
--
Key ID4BFEBB31

Re: CUPS - how to match autodetected printers to physical ones

[The Wanderer]

On 2022-04-09 at 07:56, Brian wrote:

> On Fri 08 Apr 2022 at 19:45:41 -0400, The Wanderer wrote:
> 
>> (This is probably both overly long and overly repetitive, among
>> possibly other undesirable things, but I'm running short on time.)
> 
> So I hope you do not mind if I do not reply to every point you make.

I don't strongly mind that, no. A few of them were probably rephrasings
of the same thing in different ways.

>> On 2022-04-08 at 18:44, Brian wrote:



>> What Greg was asking about, as far as I can tell, is a way to get
>> CUPS to tell him that network-location information - so that he, as
>> someone external to the printing system, could then apply that
>> information to his additional knowledge about the physical location
>> of the printer with a specific IP address.
>> 
>> I'm not sure we (in this thread) have yet found a way to do that 
>> directly; we've found what appear to be two different ways to find
>> the IP address of the printer with the name that CUPS is reporting,
>> but it looks to me as if both of them are getting that information
>> via an external method (probably similar to how CUPS found the
>> printer in the first place), rather than getting that information
>> from CUPS itself.
>> 
>> The IP-address (etc.?) information must exist within CUPS, since
>> CUPS is able to actually send jobs to the printer; why isn't it
>> straightforward and obvious how to get that information *from*
>> within CUPS *to* someplace visible?
> 
> It is straightforward, I don't know about obvious to all users.
> 
> avahi-browse -rt _ipp._tcp

Does that get the information from CUPS?

It looks to me as if it gets the information from the network, via what
are probably the same discovery methods as CUPS used to get it.

That's not the same as getting the information *from CUPS*, which must
logically already have that information.

Having a way to get the information at all (and we already seem to have
at least two of those, from this thread, one of them being the one you
just cited) is not the same as having a way to get the information *from
where it must logically already be*, and the apparent lack of the latter
is what's bothering me about the described behavior.

>>> CUPS knows how to route the job. The physical location of the 
>>> printer is not involved in the routeing.
>> 
>> True, and I don't understand why you thought it was involved (as
>> relates to CUPS) at all.
>> 
>> The IP address, however, *is* involved in the routing - and
>> therefore CUPS must know it. (Or some proxy piece of information,
>> as above.)
>> 
>> The original question as I understand it was how to get CUPS to
>> reveal that piece of information which it must know.
> 
> CUPS uses mDNS/DNS-sd for discovery. The user does the same:
> 
> avahi-browse -rt _ipp._tcp

This seems to be confirming the hypothesis above: that this is not
getting CUPS to reveal the information, but performing the same
discovery method that CUPS used to get the information.

If, for example, the printer was online when CUPS discovered it and is
therefore listed in the CUPS interface, but is offline now (perhaps
someone accidentally unplugged the network cable from the printer?), I
would be mildly surprised if this would still result in showing the IP
address of the printer. CUPS, however, must still have that address,
from its past discovery.

>>>> What I understood Greg as asking about is how to get CUPS to
>>>> *tell* you what the IP address it knows about for a given
>>>> printer object is. That doesn't seem to be an unreasonable
>>>> thing to want to know, or to expect CUPS to be able to provide;
>>>> I'd want the same thing, in anything remotely like his place.
> 
> avahi-browse -rt _ipp._tcp

As above.

>>> Finding the IP address is easy:
>>> 
>>> ippfind -T 5 ipp://envy4500.local:631/ipp/print ping -c 3
>>> envy4500.local
>> 
>> That only works if IPP is in use, which isn't guaranteed.
> 
> Communication between CUPS servers is guaranteed to be by IPP.
> Between CUPS and modern printers is only via IPP.

Okay, those are both details which I didn't know.

>> Also, how is that command supposed to be discoverable? Greg
>> certainly doesn't seem to have discovered it in his efforts, and I
>> wasn't aware of its existence either, and it also hasn't previously
>> been mentioned in this thread (despite the mentioning of
>> 'avahi-browse -rt _ipp._tcp', which turned out to also be an
>> adequate way of finding out what is probably the same
>> information).
> 
> I don' think I want to hazard a guess as to users' thought
> processes.

But that's

Re: CUPS - how to match autodetected printers to physical ones

[Brian]

On Fri 08 Apr 2022 at 13:22:26 -0400, Greg Wooledge wrote:

> On Fri, Apr 08, 2022 at 06:03:47PM +0100, Tixy wrote:
> > On Fri, 2022-04-08 at 17:59 +0100, Tixy wrote:
> > > On Fri, 2022-04-08 at 12:10 -0400, Greg Wooledge wrote:
> > > > Unfortunately, I was not able to find ANY way to determine the IP
> > > > addresses of the autodetected printers that were presented to me.
> > > 
> > > If I go to http://localhost:631/printers/
> > 
> > I should say I got to that URL from the CUPs interface at
> > http://localhost:631/ then clicking the 'Admininitation' tab at the top
> > followed by the 'Manage Printers' button on the page that showed.
> 
> Here is what I have on that page:
> 
> =
> Showing 7 of 7 printers.
> 
> Queue NameDescription LocationMake and Model  Status
> Canon_LBP351dn_f9_7a_4a_  CNLBP712C CNLBP712C, 
> driverless, cups-filters 1.28.7Idle
> Canon_LBP712Cdn_db_c0_d3_ Canon_LBP712Cdn_db_c0_d3_   
> CNLBP712C CNLBP712C, driverless, cups-filters 1.28.7Idle
> Cups_PDF_oc3261540276 Cups_PDF_oc3261540276   Local Raw Printer   
> Paused
> HP_LaserJet_4100_Series_0001E6A68D3D_ HP_LaserJet_4100_Series_0001E6A68D3D_   
> HP LaserJet 4100 Series , driverless, cups-filters 1.28.7   Idle
> hp_LaserJet_4250_621E13_  hp_LaserJet_4250_621E13_hp 
> LaserJet 4250, driverless, cups-filters 1.28.7   Idle
> HP_LaserJet_P3010_Series_0FCDD7_  HP_LaserJet_P3010_Series_0FCDD7_
> HP LaserJet P3010 Series, driverless, cups-filters 1.28.7   Idle
> PostScript_oc3261540276   PostScript_oc3261540276 Local Raw 
> Printer   Paused
> =

[...]

> Looking at the stuff that I pasted here, how am I supposed to know whether
> this corresponds to the physical printer with IP address 10.76.172.100?

Let's eliminate Cups_PDF_oc3261540276 and PostScript_oc3261540276
first. These are local, manually set up print queues (not discovered).
The queue name doe not end with an underscore, indicating they are not
physical printers. (oc3261540276 identifies the host, but why that
format?)

The remaining five entries are printers. The "driverless, cups-filters"
indicates that cups-browsed has automatically set up local print queues
for them. They are on the same subnet as your device. 10/10 up to now
for the printing system.

This leaves two Canons and three HPs. What make is the printer in the
room? Canon? Still don't want to guess? Then

  avahi-browse -rt _ipp._tcp | grep -B 2 "10.76.172.100"

Another 10/10 fot the printing system and the tools it uses.

Of course, knowing the queue name in advance would be more desirable and
lead to less frustration.

-- 
Brian.

Re: CUPS - how to match autodetected printers to physical ones

[Greg Wooledge]

On Sat, Apr 09, 2022 at 12:56:12PM +0100, Brian wrote:
> It woould have been far, far more useful to have had the queue name on
> the card. Perhaps it can be added? Printing then becomes a two minute,
> no-fuss job:
> 
>   lp -d DESTINATION FILE

I'm not on site now, so I can't recall all of the information that
was on the "card" (folded sheet of paper actually).  There was
something that looked like a Windows pathname, but it did not match
any of the names presented by CUPS, and I don't remember exactly what
it said.

Re: On IP addresses and bus tripe [was: CUPS - how to match autodetected printers to physical ones]

[tomas]

On Sat, Apr 09, 2022 at 12:47:09PM +0100, Brian wrote:
> On Sat 09 Apr 2022 at 08:33:31 +0200, to...@tuxteam.de wrote:
> 
> > On Fri, Apr 08, 2022 at 08:52:26PM +0100, Brian wrote:
> > 
> > [...]
> > 
> > > You didn't like my bus analogy, did you?
> > 
> > I did like it. Nevertheless, I thought something's missing:
> 
> In general, analogies don't really work, do they?

In a former life, I used to be physicist. We actually thrive from
analogies :)

[...]

> Setting up a queue in some circumstances may require knowledge of
> an IP address. Printing to it doesn't. The wrong path was taken.

That's, strictly speaking, right; in the OP's case, it'd been
helpful to finding the printed rag, though.

> > In the bus's case, perhaps there is a big sign on the parking lot
> > "NEUF-BRISACH". There, that's your IP address.
> > 
> > Back to the printers, I'm horrified at the idea that CUPS doesn't
> > tell you the IP address it thinks the printer is at. It's what
> > I call "authoritarian software", where the software thinks it's
> > smarter than me. Don't get me wrong, I like comfort like the next
> > guy, but I don't like being treated like an idiot.
> 
> What is important for printing is the queue name (the destination)
> an the URI. Cups will take care of all the nitty-gritty in getting
> the job to the printer. A card with the queue name would have saved
> much head scratching.

That didn't help the OP. To back out from analogy land, a piece of
software which makes available to me as much info as it can has
more of my sympathy. Doing it in a well-structured and discoverable
way gets it 100+ points of sympathy. I appreciate the designer's
hard work in this.
> 
> > Look: if some programmer gal thinks she's smarter than me, I go
> > "arrogant gal, but who knows, probably she's right". But if a
> > piece of software does that, I tend to kick it out of my box.
> > My box, my rules :)
> > 
> > And yes: no CUPS (no Avahi either) on my box :-)
> 
> Avahi is not mandatory for printing. However, it does benefit many
> users.

I know, I know. Before kicking out Avahi I looked into what it
does. It was a voluntary decision, which most definitely isn't
right for everyone.

> Plug in a mouse. It wors straightaway. Nobody gives it a secomd
> thought. Nowadays, plug in a modern printer to USB and, with Avahi,
> it is immediately available for printing. What is there to dislike?
> People have been asking for this level of operation for years.

Overgeneralisation works even less than analogies :)

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: CUPS - how to match autodetected printers to physical ones

[Brian]

On Fri 08 Apr 2022 at 19:57:53 -0500, David Wright wrote:

> On Fri 08 Apr 2022 at 23:44:29 (+0100), Brian wrote:
> > On Fri 08 Apr 2022 at 16:20:54 -0400, The Wanderer wrote:
> 
> > > What I understood Greg as asking about is how to get CUPS to *tell* you
> > > what the IP address it knows about for a given printer object is. That
> > > doesn't seem to be an unreasonable thing to want to know, or to expect
> > > CUPS to be able to provide; I'd want the same thing, in anything
> > > remotely like his place.
> > 
> > Finding the IP address is easy:
> > 
> >  ippfind -T 5
> >  ipp://envy4500.local:631/ipp/print
> >  ping -c 3 envy4500.local
> 
> Would the ping output give an IP address like the one quoted
> (10.76.172.100), or would you only get a 169.254/16 one?
> (I've not run an mDNS configured network.)

brian@desktop:$ ping -c 1 envy4500.local
PING envy4500.local (192.168.7.235) 56(84) bytes of data.
64 bytes from 192.168.7.235 (192.168.7.235): icmp_seq=1 ttl=255 time=31.3 ms

-- 
Brian.

Re: CUPS - how to match autodetected printers to physical ones

[Brian]

On Fri 08 Apr 2022 at 19:45:41 -0400, The Wanderer wrote:

> (This is probably both overly long and overly repetitive, among possibly
> other undesirable things, but I'm running short on time.)

So I hope you do not mind if I do not reply to every point you make.

> On 2022-04-08 at 18:44, Brian wrote:
> 
> > On Fri 08 Apr 2022 at 16:20:54 -0400, The Wanderer wrote:
> > 
> >> On 2022-04-08 at 15:52, Brian wrote:
> 
> >> > You didn't like my bus analogy, did you?
> >> > 
> >> > What makes you think that knowing a bus number and destination 
> >> > provudes information for where it departs from?
> >> > 
> >> > What makes you think that knowing an IP address tells you where any
> >> > machine of any description is located?
> >> 
> >> I'm confused as to why you might think anyone involved in this
> >> conversation thought that.
> >> 
> >> There's no reason to expect that knowing an IP address tells you the
> >> location of the device at the other end.
> > 
> > The OP explicitly associated IP address with physical location:
> > 
> >  > "Aha," I thought.  "All I have to do is figure out which one of the
> >  >  autodetected printers on this list has the same IP address as the 
> > printer
> >  >  that I can see and touch over there.
> > 
> > The user may be aware of the printer's location, but is the printing
> > system in possession of the same knowledge?
> 
> ...I do not follow your reasoning in parsing that statement. I do not
> see how that statement leads in any way to the conclusion that the
> printing system has, or must have, any knowledge of the printer's
> location.
> 
> Even if the printing system doesn't have any knowledge of the printer's
> physical location, it must still have some knowledge of the printer's
> *network* location, in the form of an IP address (or other routing
> information, such as in the print-server model described below).
> 
> What Greg was asking about, as far as I can tell, is a way to get CUPS
> to tell him that network-location information - so that he, as someone
> external to the printing system, could then apply that information to
> his additional knowledge about the physical location of the printer with
> a specific IP address.
> 
> I'm not sure we (in this thread) have yet found a way to do that
> directly; we've found what appear to be two different ways to find the
> IP address of the printer with the name that CUPS is reporting, but it
> looks to me as if both of them are getting that information via an
> external method (probably similar to how CUPS found the printer in the
> first place), rather than getting that information from CUPS itself.
> 
> The IP-address (etc.?) information must exist within CUPS, since CUPS is
> able to actually send jobs to the printer; why isn't it straightforward
> and obvious how to get that information *from* within CUPS *to*
> someplace visible?

It is straightforward, I don't know about obvious to all users.

  avahi-browse -rt _ipp._tcp  
 
> >> However, if CUPS did autodiscovery and found the printer, then it
> >> must know what the place is that it was looking at when it found
> >> that device.
> > 
> > By "place" do you mean physical place?
> 
> No. I mean, the place on the network where it got the information.
> (Which will presumably be a place which has an IP address.)
> 
> >> Unless I'm missing something, the options are that either CUPS
> >> found the printer in a list of printers being maintained somewhere
> >> else (e.g. a print server on the network), or CUPS found the
> >> printer on the network directly.
> > 
> > The same technique is used for both: mDNS/DNS-SD.
> 
> I find that plausible enough, but will have to take your word for it.
> 
> >> If CUPS found the printer on a list of printers being maintained 
> >> somewhere else, then it must have also found information about
> >> that "somewhere else", and that information might include an IP
> >> address.
> > 
> > "somewhere else" would have to be explained. It is not part of my
> > inderstanding.
> 
> I was referencing the same definition of "somewhere else" as used in the
> previous sentence, where I gave the example of a print server on the
> network.
> 
> I was thinking of the design in which a print server maintains a list of
> print queues, and serves as a proxy to receive print jobs and pass them
> to those print queues, so as to both avoid contention on the printer
> itself and facilitate centra

Re: On IP addresses and bus tripe [was: CUPS - how to match autodetected printers to physical ones]

[Brian]

On Sat 09 Apr 2022 at 08:33:31 +0200, to...@tuxteam.de wrote:

> On Fri, Apr 08, 2022 at 08:52:26PM +0100, Brian wrote:
> 
> [...]
> 
> > You didn't like my bus analogy, did you?
> 
> I did like it. Nevertheless, I thought something's missing:

In general, analogies don't really work, do they?
 
> > What makes you think that knowing a bus number and destination
> > provudes information for where it departs from?
> >
> > What makes you think that knowing an IP address tells you where
> > any machine of any description is located?
> 
> This is, of course, not guaranteed. But "the system" might provide
> for the user not being an idiot and perhaps having bits of info
> "the system" doesn't. 
> 
> In Greg's (was he the OP? I lost the thread in the process) case
> it's the IP address stuck on the printer (most printers these days
> tell you, if you ticke their menus for long enough, BTW).

Setting up a queue in some circumstances may require knowledge of
an IP address. Printing to it doesn't. The wrong path was taken.
 
> In the bus's case, perhaps there is a big sign on the parking lot
> "NEUF-BRISACH". There, that's your IP address.
> 
> Back to the printers, I'm horrified at the idea that CUPS doesn't
> tell you the IP address it thinks the printer is at. It's what
> I call "authoritarian software", where the software thinks it's
> smarter than me. Don't get me wrong, I like comfort like the next
> guy, but I don't like being treated like an idiot.

What is important for printing is the queue name (the destination)
an the URI. Cups will take care of all the nitty-gritty in getting
the job to the printer. A card with the queue name would have saved
much head scratching.

> Look: if some programmer gal thinks she's smarter than me, I go
> "arrogant gal, but who knows, probably she's right". But if a
> piece of software does that, I tend to kick it out of my box.
> My box, my rules :)
> 
> And yes: no CUPS (no Avahi either) on my box :-)

Avahi is not mandatory for printing. However, it does benefit many
users.

Plug in a mouse. It wors straightaway. Nobody gives it a secomd
thought. Nowadays, plug in a modern printer to USB and, with Avahi,
it is immediately available for printing. What is there to dislike?
People have been asking for this level of operation for years.

-- 
Brian.

Re: CUPS - how to match autodetected printers to physical ones

[Tixy]

On Sat, 2022-04-09 at 00:05 +0100, Brian wrote:
> On Fri 08 Apr 2022 at 21:07:18 +0100, Tixy wrote:
> 
> > On Fri, 2022-04-08 at 20:18 +0100, Brian wrote:
> > > On Fri 08 Apr 2022 at 17:59:10 +0100, Tixy wrote:
> > > 
> > > > On Fri, 2022-04-08 at 12:10 -0400, Greg Wooledge wrote:
> > > > > Unfortunately, I was not able to find ANY way to determine the IP
> > > > > addresses of the autodetected printers that were presented to me.
> > > > 
> > > > If I go to http://localhost:631/printers/ and click on my printer it
> > > > shows amongst other information:
> > > > 
> > > > Connection: socket://192.168.2.3:9100
> > > 
> > > OK. That's the destination.
> > > > 
> > > > In case it got that IP address because I configured it that way, I just
> > > > tried it on another computer that didn't previously have CUPS on until
> > > > I just installed it and it shows the same for an auto discovered
> > > > printer.
> > > 
> > > Do you find that surprising? The destination hasn't changed because you
> > > use another computer. You would be miffed if it did.
> > > 
> > 
> > I wasn't expecting a different IP address but, given Greg's experience,
> 
> I think we have a differnet understanding of what The OP's experience
> was.

Possibly, I thought his experience was that he couldn't see the IP
address for printers in GUI or command-line interfaces.

-- 
Tixy

On IP addresses and bus tripe [was: CUPS - how to match autodetected printers to physical ones]

[tomas]

On Fri, Apr 08, 2022 at 08:52:26PM +0100, Brian wrote:

[...]

> You didn't like my bus analogy, did you?

I did like it. Nevertheless, I thought something's missing:

> What makes you think that knowing a bus number and destination
> provudes information for where it departs from?
>
> What makes you think that knowing an IP address tells you where
> any machine of any description is located?

This is, of course, not guaranteed. But "the system" might provide
for the user not being an idiot and perhaps having bits of info
"the system" doesn't. 

In Greg's (was he the OP? I lost the thread in the process) case
it's the IP address stuck on the printer (most printers these days
tell you, if you ticke their menus for long enough, BTW).

In the bus's case, perhaps there is a big sign on the parking lot
"NEUF-BRISACH". There, that's your IP address.

Back to the printers, I'm horrified at the idea that CUPS doesn't
tell you the IP address it thinks the printer is at. It's what
I call "authoritarian software", where the software thinks it's
smarter than me. Don't get me wrong, I like comfort like the next
guy, but I don't like being treated like an idiot.

Look: if some programmer gal thinks she's smarter than me, I go
"arrogant gal, but who knows, probably she's right". But if a
piece of software does that, I tend to kick it out of my box.
My box, my rules :)

And yes: no CUPS (no Avahi either) on my box :-)

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: CUPS - how to match autodetected printers to physical ones

[mick crane]

On 2022-04-08 17:10, Greg Wooledge wrote:

If you don't want to read the background information, the question is:

How is one *supposed* to figure out which autodetected printer is the
correct one, apart from trial and error?



I think you'd set up a printer on your machine with
'ipp://ip-address-of-print-server:631/printers/name-of-printer-as-written-on-sticker'
but you are saying that wasn't the exact name ?
There should be a way to query the print server of ip addresses by name.

cheers
mick

Re: CUPS - how to match autodetected printers to physical ones

[David Wright]

On Fri 08 Apr 2022 at 23:44:29 (+0100), Brian wrote:
> On Fri 08 Apr 2022 at 16:20:54 -0400, The Wanderer wrote:

> > What I understood Greg as asking about is how to get CUPS to *tell* you
> > what the IP address it knows about for a given printer object is. That
> > doesn't seem to be an unreasonable thing to want to know, or to expect
> > CUPS to be able to provide; I'd want the same thing, in anything
> > remotely like his place.
> 
> Finding the IP address is easy:
> 
>  ippfind -T 5
>  ipp://envy4500.local:631/ipp/print
>  ping -c 3 envy4500.local

Would the ping output give an IP address like the one quoted
(10.76.172.100), or would you only get a 169.254/16 one?
(I've not run an mDNS configured network.)

Cheers,
David.

Re: CUPS - how to match autodetected printers to physical ones

[The Wanderer]

(This is probably both overly long and overly repetitive, among possibly
other undesirable things, but I'm running short on time.)


On 2022-04-08 at 18:44, Brian wrote:

> On Fri 08 Apr 2022 at 16:20:54 -0400, The Wanderer wrote:
> 
>> On 2022-04-08 at 15:52, Brian wrote:

>> > You didn't like my bus analogy, did you?
>> > 
>> > What makes you think that knowing a bus number and destination 
>> > provudes information for where it departs from?
>> > 
>> > What makes you think that knowing an IP address tells you where any
>> > machine of any description is located?
>> 
>> I'm confused as to why you might think anyone involved in this
>> conversation thought that.
>> 
>> There's no reason to expect that knowing an IP address tells you the
>> location of the device at the other end.
> 
> The OP explicitly associated IP address with physical location:
> 
>  > "Aha," I thought.  "All I have to do is figure out which one of the
>  >  autodetected printers on this list has the same IP address as the printer
>  >  that I can see and touch over there.
> 
> The user may be aware of the printer's location, but is the printing
> system in possession of the same knowledge?

...I do not follow your reasoning in parsing that statement. I do not
see how that statement leads in any way to the conclusion that the
printing system has, or must have, any knowledge of the printer's
location.

Even if the printing system doesn't have any knowledge of the printer's
physical location, it must still have some knowledge of the printer's
*network* location, in the form of an IP address (or other routing
information, such as in the print-server model described below).

What Greg was asking about, as far as I can tell, is a way to get CUPS
to tell him that network-location information - so that he, as someone
external to the printing system, could then apply that information to
his additional knowledge about the physical location of the printer with
a specific IP address.

I'm not sure we (in this thread) have yet found a way to do that
directly; we've found what appear to be two different ways to find the
IP address of the printer with the name that CUPS is reporting, but it
looks to me as if both of them are getting that information via an
external method (probably similar to how CUPS found the printer in the
first place), rather than getting that information from CUPS itself.

The IP-address (etc.?) information must exist within CUPS, since CUPS is
able to actually send jobs to the printer; why isn't it straightforward
and obvious how to get that information *from* within CUPS *to*
someplace visible?

>> However, if CUPS did autodiscovery and found the printer, then it
>> must know what the place is that it was looking at when it found
>> that device.
> 
> By "place" do you mean physical place?

No. I mean, the place on the network where it got the information.
(Which will presumably be a place which has an IP address.)

>> Unless I'm missing something, the options are that either CUPS
>> found the printer in a list of printers being maintained somewhere
>> else (e.g. a print server on the network), or CUPS found the
>> printer on the network directly.
> 
> The same technique is used for both: mDNS/DNS-SD.

I find that plausible enough, but will have to take your word for it.

>> If CUPS found the printer on a list of printers being maintained 
>> somewhere else, then it must have also found information about
>> that "somewhere else", and that information might include an IP
>> address.
> 
> "somewhere else" would have to be explained. It is not part of my
> inderstanding.

I was referencing the same definition of "somewhere else" as used in the
previous sentence, where I gave the example of a print server on the
network.

I was thinking of the design in which a print server maintains a list of
print queues, and serves as a proxy to receive print jobs and pass them
to those print queues, so as to both avoid contention on the printer
itself and facilitate central management of those print queues (rather
than needing to manage them on the individual endpoints, whether the
client computers or the printers).

In that case, as the print server would not hand out the IP addresses of
the printers (since that would enable bypassing the server-side print
queues), but would only hand out the combination of the server's IP
address and the name of the print queue to specify when sending jobs to
that printer via that print server, CUPS would not have access to the IP
address of the printer itself.

(I could have sworn that I'd found this arrangement documented somewhere
in the past, but at the moment I can't completely rule out that it's
anything other than th

Re: CUPS - how to match autodetected printers to physical ones

[Greg Wooledge]

On Sat, Apr 09, 2022 at 12:05:01AM +0100, Brian wrote:
> On Fri 08 Apr 2022 at 21:07:18 +0100, Tixy wrote:
> > I wasn't expecting a different IP address but, given Greg's experience,
> 
> I think we have a differnet understanding of what The OP's experience
> was.

I knew the printer's IP address before I even touched CUPS.  It was
prominently displayed on the device itself.  It was the one thing I
didn't have to guess at during the entire adventure.(*)

In all of my experience working with printers BEFORE the CUPS/Avahi
thing came along, knowing the IP address of the network printer was
the first, fundamental step.  When you set up the printer device in
Unix, using lprng or whatever it was at the time, that was where you
started.  Here's the IP address, now add it to DNS so it has a name,
and then add a printer device that uses that hostname.

In CUPS/Avahi, apparently you aren't supposed to do things in that way,
because it would be too obvious.

Fortunately, there are low-level commands that allow you to bypass
the "right way of doing things" and get at the information you need to
actually make the thing *work*.  (Or if you don't know those commands
yet, there's still trial and error.)

(*) Remember, I had an entry in DNS pointing to that IP address already.
The IP address *predated the printer device*.  It was surely associated
with the previous printer that was in that spot.  Whoever installed this
printer was probably told to report its MAC address to the DHCP admin
so they could assign the old printer's IP address to the new printer.

Re: CUPS - how to match autodetected printers to physical ones

[Brian]

On Fri 08 Apr 2022 at 21:07:18 +0100, Tixy wrote:

> On Fri, 2022-04-08 at 20:18 +0100, Brian wrote:
> > On Fri 08 Apr 2022 at 17:59:10 +0100, Tixy wrote:
> > 
> > > On Fri, 2022-04-08 at 12:10 -0400, Greg Wooledge wrote:
> > > > Unfortunately, I was not able to find ANY way to determine the IP
> > > > addresses of the autodetected printers that were presented to me.
> > > 
> > > If I go to http://localhost:631/printers/ and click on my printer it
> > > shows amongst other information:
> > > 
> > > Connection:   socket://192.168.2.3:9100
> > 
> > OK. That's the destination.
> > > 
> > > In case it got that IP address because I configured it that way, I just
> > > tried it on another computer that didn't previously have CUPS on until
> > > I just installed it and it shows the same for an auto discovered
> > > printer.
> > 
> > Do you find that surprising? The destination hasn't changed because you
> > use another computer. You would be miffed if it did.
> > 
> 
> I wasn't expecting a different IP address but, given Greg's experience,

I think we have a differnet understanding of what The OP's experience
was.

> it might have shown no address at all if it was auto discovered as
> opposed to being configured by specifying an address. (Which is what I
> thought I had done.) 

Printer discovery results in no address (URI) being known? Just because
it wasn't manually configured? Where would the print job go? Discovery
would be useless.

-- 
Brian,

Re: CUPS - how to match autodetected printers to physical ones

[Brian]

On Fri 08 Apr 2022 at 16:20:54 -0400, The Wanderer wrote:

> On 2022-04-08 at 15:52, Brian wrote:
> 
> > On Fri 08 Apr 2022 at 15:22:58 -0400, Greg Wooledge wrote:
> > 
> >> On Fri, Apr 08, 2022 at 08:08:22PM +0100, Brian wrote:
> 
> >>> Now contact you highly paid sys admins to ask them to add a
> >>> "Location" field to whatever the server/printer is advertising.
> >> 
> >> So... if your corporate network is not set up in the way that
> >> Brian expects, there is simply nothing you can do about it.  You're
> >> just screwed, and must resort to trial and error to figure out
> >> where the printers are.  Even though CUPS can magically contact the
> >> printers, it will refuse to tell you how it does that, because of
> >> some kind of policy decision.
> > 
> > You didn't like my bus analogy, did you?
> > 
> > What makes you think that knowing a bus number and destination 
> > provudes information for where it departs from?
> > 
> > What makes you think that knowing an IP address tells you where any
> > machine of any description is located?
> 
> I'm confused as to why you might think anyone involved in this
> conversation thought that.
> 
> There's no reason to expect that knowing an IP address tells you the
> location of the device at the other end.

The OP explicitly associated IP address with physical location:

 > "Aha," I thought.  "All I have to do is figure out which one of the
 >  autodetected printers on this list has the same IP address as the printer
 >  that I can see and touch over there.

The user may be aware of the printer's location, but is the printing
system in possession of the same knowledge?

> However, if CUPS did autodiscovery and found the printer, then it must
> know what the place is that it was looking at when it found that device.

By "place" do you mean physical place?

> Unless I'm missing something, the options are that either CUPS found the
> printer in a list of printers being maintained somewhere else (e.g. a
> print server on the network), or CUPS found the printer on the network
> directly.

The same technique is used for both: mDNS/DNS-SD.
> 
> If CUPS found the printer on a list of printers being maintained
> somewhere else, then it must have also found information about that
> "somewhere else", and that information might include an IP address.

"somewhere else" would have to be explained. It is not part of my
inderstanding.
 
> If CUPS found the printer on the network directly, then it certainly
> also found the printer's IP address.

Indeed. But that information does not give the physical location of

 > ...the printer that I can see and touch over there.

> Regardless, if CUPS can send a print job to the printer, then it must
> have some information to be able to route the job towards that
> destination - and that information will certainly include an IP address
> at some point along the way, either that of the printer or of the print
> server or of some other intermediary system.

CUPS knows how to route the job. The physical location of the printer
is not involved in the routeing.

> What I understood Greg as asking about is how to get CUPS to *tell* you
> what the IP address it knows about for a given printer object is. That
> doesn't seem to be an unreasonable thing to want to know, or to expect
> CUPS to be able to provide; I'd want the same thing, in anything
> remotely like his place.

Finding the IP address is easy:

 ippfind -T 5
 ipp://envy4500.local:631/ipp/print
 ping -c 3 envy4500.local

If you were in his place, you should hope that the sys admins would
include the physical location of the printer when advertising it. This
is part of the IPP standard. It could then be matched with the IP.
 
> If the printer happens to be one from a central print server, CUPS might
> not have its IP address locally - but being able to get the information
> for that print server (whether IP address or hostname or whatever else),
> along with the identifier used on that print server for the printer,
> might well be enough to make it possible to proceed forward anyway.

Of course.

-- 
Brian.

Re: CUPS - how to match autodetected printers to physical ones

[Greg Wooledge]

On Fri, Apr 08, 2022 at 08:52:26PM +0100, Brian wrote:
> You didn't like my bus analogy, did you?

I don't think it's a very good analogy for this situation.

> What makes you think that knowing an IP address tells you where
> any machine of any description is located?

Because the device is (was) sitting 50 feet away from me, and even
if the people who installed it had not been kind enough to print some
kind of config page and attach it to the front of the printer, I could
have Googled the printer's model number and found out how to print the
printer's own config page myself.  Or else how to scroll through the
printer's control panel menus to find its IP address that way.

The printer's brand, model and IP address are the extremely concrete
pieces of information that I can readily acquire and compare.  Software
that refuses to divulge useful information is not acting in a helpful
manner.

Also, completely coincidentally, I happen to know how the corporate
network is subdivided -- at least in the building that I work in.
Each floor has a /23 network assigned to it.  So, from the IP address
alone, I can at least tell whether the device is on my floor.  If I
need more specific location info than that, I would either have to call
someone, or search manually.

> Trial and error is not neeed. Just an IT department with basic
> skills and the intention to help users would suffice.

I wonder how many IT departments match both parts of that description.

In any case, "avahi-browse -rt _ipp._tcp" was helpful and useful, so
thank you for that.  I've typed it into my notes for next time I need it.

Re: CUPS - how to match autodetected printers to physical ones

[The Wanderer]

On 2022-04-08 at 15:52, Brian wrote:

> On Fri 08 Apr 2022 at 15:22:58 -0400, Greg Wooledge wrote:
> 
>> On Fri, Apr 08, 2022 at 08:08:22PM +0100, Brian wrote:

>>> Now contact you highly paid sys admins to ask them to add a
>>> "Location" field to whatever the server/printer is advertising.
>> 
>> So... if your corporate network is not set up in the way that
>> Brian expects, there is simply nothing you can do about it.  You're
>> just screwed, and must resort to trial and error to figure out
>> where the printers are.  Even though CUPS can magically contact the
>> printers, it will refuse to tell you how it does that, because of
>> some kind of policy decision.
> 
> You didn't like my bus analogy, did you?
> 
> What makes you think that knowing a bus number and destination 
> provudes information for where it departs from?
> 
> What makes you think that knowing an IP address tells you where any
> machine of any description is located?

I'm confused as to why you might think anyone involved in this
conversation thought that.

There's no reason to expect that knowing an IP address tells you the
location of the device at the other end.

However, if CUPS did autodiscovery and found the printer, then it must
know what the place is that it was looking at when it found that device.

Unless I'm missing something, the options are that either CUPS found the
printer in a list of printers being maintained somewhere else (e.g. a
print server on the network), or CUPS found the printer on the network
directly.

If CUPS found the printer on a list of printers being maintained
somewhere else, then it must have also found information about that
"somewhere else", and that information might include an IP address.

If CUPS found the printer on the network directly, then it certainly
also found the printer's IP address.

Regardless, if CUPS can send a print job to the printer, then it must
have some information to be able to route the job towards that
destination - and that information will certainly include an IP address
at some point along the way, either that of the printer or of the print
server or of some other intermediary system.

What I understood Greg as asking about is how to get CUPS to *tell* you
what the IP address it knows about for a given printer object is. That
doesn't seem to be an unreasonable thing to want to know, or to expect
CUPS to be able to provide; I'd want the same thing, in anything
remotely like his place.

If the printer happens to be one from a central print server, CUPS might
not have its IP address locally - but being able to get the information
for that print server (whether IP address or hostname or whatever else),
along with the identifier used on that print server for the printer,
might well be enough to make it possible to proceed forward anyway.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: CUPS - how to match autodetected printers to physical ones

[Tixy]

On Fri, 2022-04-08 at 20:18 +0100, Brian wrote:
> On Fri 08 Apr 2022 at 17:59:10 +0100, Tixy wrote:
> 
> > On Fri, 2022-04-08 at 12:10 -0400, Greg Wooledge wrote:
> > > Unfortunately, I was not able to find ANY way to determine the IP
> > > addresses of the autodetected printers that were presented to me.
> > 
> > If I go to http://localhost:631/printers/ and click on my printer it
> > shows amongst other information:
> > 
> > Connection: socket://192.168.2.3:9100
> 
> OK. That's the destination.
> > 
> > In case it got that IP address because I configured it that way, I just
> > tried it on another computer that didn't previously have CUPS on until
> > I just installed it and it shows the same for an auto discovered
> > printer.
> 
> Do you find that surprising? The destination hasn't changed because you
> use another computer. You would be miffed if it did.
> 

I wasn't expecting a different IP address but, given Greg's experience,
it might have shown no address at all if it was auto discovered as
opposed to being configured by specifying an address. (Which is what I
thought I had done.) 

-- 
Tixy

Re: CUPS - how to match autodetected printers to physical ones

[Greg Wooledge]

On Fri, Apr 08, 2022 at 08:24:00PM +0100, Brian wrote:
>   avahi-browse -rt _ipp._tcp
> 
> is better.

That one actually works.  It completes in under 1 second, and it
includes IP addresses in its output.

Out of curiosity, I tried omitting the -r option, to try to figure out
what "resolve" means in this context.  The result was simply a list of
the top-level names, without any of the associated details such as
their IP addresses.  So it seems "resolve services" means "provide
details about each thing found, instead of simply reporting its name".

(I find that confusing, because "resolve" usually means "report a
human-readable name rather than a number", but so be it.)

Re: CUPS - how to match autodetected printers to physical ones

[Brian]

On Fri 08 Apr 2022 at 15:22:58 -0400, Greg Wooledge wrote:

> On Fri, Apr 08, 2022 at 08:08:22PM +0100, Brian wrote:
> > On Fri 08 Apr 2022 at 12:10:37 -0400, Greg Wooledge wrote:
> > > How is one *supposed* to figure out which autodetected printer is the
> > > correct one, apart from trial and error?
> 
> > Now contact you highly paid sys admins to ask them to add a "Location"
> > field to whatever the server/printer is advertising.
> 
> So... if your corporate network is not set up in the way that Brian
> expects, there is simply nothing you can do about it.  You're just
> screwed, and must resort to trial and error to figure out where
> the printers are.  Even though CUPS can magically contact the printers,
> it will refuse to tell you how it does that, because of some kind of
> policy decision.

You didn't like my bus analogy, did you?

What makes you think that knowing a bus number and destination
provudes information for where it departs from?

What makes you think that knowing an IP address tells you where
any machine of any description is located?

Trial and error is not neeed. Just an IT department with basic
skills and the intention to help users would suffice.

-- 
Brian.

Re: CUPS - how to match autodetected printers to physical ones

[David Wright]

On Fri 08 Apr 2022 at 15:30:13 (-0400), Greg Wooledge wrote:
> On Fri, Apr 08, 2022 at 08:28:31PM +0200, didier gaumet wrote:
> > CLI:
> > 
> > # avahi-browse -r _print-caps._tcp
> > (from the avahi-utils package) 
> 
> I tried this with and without the -r (which according to the man page
> asks to "resolve services", but it doesn't say what kind of resolution
> it's doing).
> 
> In both cases, after waiting a few minutes and seeing no output, I
> simply terminated the process.  I don't know what it's doing, or why
> it takes so long, but I'm afraid that if it happens to be generating a
> packet storm, I might get in trouble.

If your position is secure, that might be the way to get things
changed: trouble.

Cheers,
David.

Re: CUPS - how to match autodetected printers to physical ones

[David Wright]

On Fri 08 Apr 2022 at 15:22:58 (-0400), Greg Wooledge wrote:
> On Fri, Apr 08, 2022 at 08:08:22PM +0100, Brian wrote:
> > On Fri 08 Apr 2022 at 12:10:37 -0400, Greg Wooledge wrote:
> > > How is one *supposed* to figure out which autodetected printer is the
> > > correct one, apart from trial and error?
> 
> > Now contact you highly paid sys admins to ask them to add a "Location"
> > field to whatever the server/printer is advertising.
> 
> So... if your corporate network is not set up in the way that Brian
> expects, there is simply nothing you can do about it.  You're just
> screwed, and must resort to trial and error to figure out where
> the printers are.  Even though CUPS can magically contact the printers,
> it will refuse to tell you how it does that, because of some kind of
> policy decision.

It's an odd policy decision to pay someone to write IP addresses on
printers rather than the name(s) of the queue(s) that they serve.
It does look as if all the information that is published for/on these
printers is for the benefit of the support staff and not the users.

Cheers,
David.

Re: CUPS - how to match autodetected printers to physical ones

[Fred]

On 4/8/22 10:22, Greg Wooledge wrote:

On Fri, Apr 08, 2022 at 06:03:47PM +0100, Tixy wrote:

On Fri, 2022-04-08 at 17:59 +0100, Tixy wrote:

On Fri, 2022-04-08 at 12:10 -0400, Greg Wooledge wrote:

Unfortunately, I was not able to find ANY way to determine the IP
addresses of the autodetected printers that were presented to me.


If I go to http://localhost:631/printers/


I should say I got to that URL from the CUPs interface at
http://localhost:631/ then clicking the 'Admininitation' tab at the top
followed by the 'Manage Printers' button on the page that showed.


Here is what I have on that page:

=
Showing 7 of 7 printers.

Queue Name  Description LocationMake and Model  Status
Canon_LBP351dn_f9_7a_4a_CNLBP712C CNLBP712C, 
driverless, cups-filters 1.28.7Idle
Canon_LBP712Cdn_db_c0_d3_   Canon_LBP712Cdn_db_c0_d3_   
CNLBP712C CNLBP712C, driverless, cups-filters 1.28.7Idle
Cups_PDF_oc3261540276   Cups_PDF_oc3261540276   Local Raw Printer   
Paused
HP_LaserJet_4100_Series_0001E6A68D3D_   HP_LaserJet_4100_Series_0001E6A68D3D_   
HP LaserJet 4100 Series , driverless, cups-filters 1.28.7   Idle
hp_LaserJet_4250_621E13_hp_LaserJet_4250_621E13_hp 
LaserJet 4250, driverless, cups-filters 1.28.7   Idle
HP_LaserJet_P3010_Series_0FCDD7_HP_LaserJet_P3010_Series_0FCDD7_
HP LaserJet P3010 Series, driverless, cups-filters 1.28.7   Idle
PostScript_oc3261540276 PostScript_oc3261540276 Local Raw Printer   
Paused
=

Of course it looks like crap when I just paste the text from the web
page into an email.  But if you ignore the horrible formatting, you
can see there are NO IP addresses here.

If I go to a single printer's page, I get text like this:

=
Canon_LBP351dn_f9_7a_4a_
Canon_LBP351dn_f9_7a_4a_ (Idle, Accepting Jobs, Not Shared, Server Default)

Maintenance
  
Administration
Description:
Location:   
Driver: CNLBP712C CNLBP712C, driverless, cups-filters 1.28.7 (color, 2-sided 
printing)
Connection: implicitclass://Canon_LBP351dn_f9_7a_4a_/
Defaults:   job-sheets=none, none media=na_letter_8.5x11in sides=one-sided
=

Maybe I need to amend the question to "How is one supposed to figure out
which autodetected printer is which IN A CORPORATE NETWORK OF UNKNOWN
PROVENANCE?"  I don't know what I need to say to convey to you that
my workplace's network DOES NOT work like what you see on yours.

Looking at the stuff that I pasted here, how am I supposed to know whether
this corresponds to the physical printer with IP address 10.76.172.100?


Have you tried asking the IT dept.?

Best regards,
Fred

Re: CUPS - how to match autodetected printers to physical ones

[Greg Wooledge]

On Fri, Apr 08, 2022 at 08:28:31PM +0200, didier gaumet wrote:
> CLI:
> 
> # avahi-browse -r _print-caps._tcp
> (from the avahi-utils package) 

I tried this with and without the -r (which according to the man page
asks to "resolve services", but it doesn't say what kind of resolution
it's doing).

In both cases, after waiting a few minutes and seeing no output, I
simply terminated the process.  I don't know what it's doing, or why
it takes so long, but I'm afraid that if it happens to be generating a
packet storm, I might get in trouble.

Re: CUPS - how to match autodetected printers to physical ones

[David Wright]

On Fri 08 Apr 2022 at 20:08:22 (+0100), Brian wrote:
> On Fri 08 Apr 2022 at 12:10:37 -0400, Greg Wooledge wrote:

> > How is one *supposed* to figure out which autodetected printer is the
> > correct one, apart from trial and error?
> 
> Fancy an analogy?
> 
> My local bus intercange has display screens showing bus nummbers and
> destinations (IP addresses). It does not display the stands the buses
> start from. Whose responsibillity is that down to?
> 
> You got it!
> 
> Now contact you highly paid sys admins to ask them to add a "Location"
> field to whatever the server/printer is advertising.

Where I used to work, they got this right: they put /user/ information
into the Queue name, where it can't but be seen, using the pattern
DeptRoom_unusualCharacteristics.

So MathsB037 might be an ordinary one (A4 B), and PhysicsS221_A3_colour_foil
would be something rather special, that might only operate at certain
times of day when they load the foil.

Cheers,
David.

Re: CUPS - how to match autodetected printers to physical ones

[Brian]

On Fri 08 Apr 2022 at 20:28:31 +0200, didier gaumet wrote:

> Hello Greg,
> 
> Perhaps, try: 
> 
> GUI:
> 
> avahi-discover from the avahi-discover package presents a network tree:
> you can find the IP adresses of the printers
> 
> CLI:
> 
> # avahi-browse -r _print-caps._tcp
> (from the avahi-utils package) 
> In my case it's sufficient to detect my network printer but I do not
> know well avahi service types (here: _print-caps._tcp, seems to be
> printer capabilities at the TCP level)
> if you do not find your printers try a more general search:
> # avahi-browse -avr
> and explore the results

  avahi-browse -rt _ipp._tcp

is better.

This also gives the location of a printer if a highly paid sys admin
can be arsed to supply it.

-- 
Brian.

Re: CUPS - how to match autodetected printers to physical ones

[Greg Wooledge]

On Fri, Apr 08, 2022 at 08:08:22PM +0100, Brian wrote:
> On Fri 08 Apr 2022 at 12:10:37 -0400, Greg Wooledge wrote:
> > How is one *supposed* to figure out which autodetected printer is the
> > correct one, apart from trial and error?

> Now contact you highly paid sys admins to ask them to add a "Location"
> field to whatever the server/printer is advertising.

So... if your corporate network is not set up in the way that Brian
expects, there is simply nothing you can do about it.  You're just
screwed, and must resort to trial and error to figure out where
the printers are.  Even though CUPS can magically contact the printers,
it will refuse to tell you how it does that, because of some kind of
policy decision.

Re: CUPS - how to match autodetected printers to physical ones

[Brian]

On Fri 08 Apr 2022 at 17:59:10 +0100, Tixy wrote:

> On Fri, 2022-04-08 at 12:10 -0400, Greg Wooledge wrote:
> > Unfortunately, I was not able to find ANY way to determine the IP
> > addresses of the autodetected printers that were presented to me.
> 
> If I go to http://localhost:631/printers/ and click on my printer it
> shows amongst other information:
> 
> Connection:   socket://192.168.2.3:9100

OK. That's the destination.
> 
> In case it got that IP address because I configured it that way, I just
> tried it on another computer that didn't previously have CUPS on until
> I just installed it and it shows the same for an auto discovered
> printer.

Do you find that surprising? The destination hasn't changed because you
use another computer. You would be miffed if it did.
> 
> -- 
> Tixy
> 

Re: CUPS - how to match autodetected printers to physical ones

[Brian]

On Fri 08 Apr 2022 at 12:10:37 -0400, Greg Wooledge wrote:

[Misconceptions snipped. It would take too long to comment on and refute
every single one of them, interesting though they may be.]

> After all this, I have two final comments:
> 
> 1) To whomever received two surprise printer test pages: sorry.
> 2) I FUCKING HATE PRINTERS!

You are pointing the finger in the wrong direction. (As recent political
events show, this is seen as a good technique to draw attention from the
actual state of affairs).
> 
> And I have one question:
> 
> How is one *supposed* to figure out which autodetected printer is the
> correct one, apart from trial and error?

Fancy an analogy?

My local bus intercange has display screens showing bus nummbers and
destinations (IP addresses). It does not display the stands the buses
start from. Whose responsibillity is that down to?

You got it!

Now contact you highly paid sys admins to ask them to add a "Location"
field to whatever the server/printer is advertising.

-- 
Brian.
>