On Sat 25 Feb 2023 at 22:22:55 +0300, Reco wrote:
> On Sat, Feb 25, 2023 at 06:30:28PM +0000, Brian wrote:
> > On Sat 25 Feb 2023 at 17:44:15 +0300, Reco wrote:
> >
> > > Hi.
> > >
> > > On Fri, Feb 24, 2023 at 12:58:15PM -0500, Greg Wooledge wrote:
> > > > On Fri, Feb 17, 2023 at 05:35:11PM +0300, Reco wrote:
> > > > > Try this next time you're on site:
> > > > >
> > > > > lpadmin -p D14841 -E -v ipp://10.76.172.100/ipp/print -m everywhere
> > > >
> > > > This worked. I printed two copies of the single-page PDF from Chrome
> > > > without any further problems.
> > >
> > > Just as planned. CUPS autodiscovery is only good for something if you
> > > don't know printer's real IP. This little episode shows us that nothing
> > > beats IP-on-sheet-of-paper discovery.
> >
> > 99% of users with tablets, smart phones, laptops etc would find
> > DNS-SD more to their liking, especially if DHCP assignment is
> > in place.
>
> It's interesting how you bring up DHCP, yet do not mention DHCP option 9
> (aka "option lpr-servers" in ISC lingo).
> A proper implementation of DHCP options would make DNS-SD (and other
> assorted kludges) completely redundant.
> But that would be in an ideal world, and in the real world DNS-SD
> serves its function (within its inherent limits of course).
> If it works, that is.
If the IP address changes, ipp://10.76.172.100/ipp/print as a
URI becomes useless. DNS-SD ensures a reachable URI. Got it?
It's as simple as that. Why complicate it with what DHCP can
do or not do?
> > It would also be hoped that port numbers and resource
> > paths are on the sheet of paper, otherwise a user will have a
> > lot of guessing to do.
>
> Nope. RTFM would suffice, as always.
I do not think you understand my argument. A port for an IPP
printer need not be on 631 and the resource path need not be
ipp/print. RTFM hardly helps when there is an immediate need
to print.
RTFM? Which ones would you recommend?
> > In this thread we see how a very experienced user reacted to
> > being denied mdns multicasting.
>
> Allow me to quote that original e-mail for the sake of completeness:
>
> > So the printer WORKS. It is ON THE NETWORK. I can print TEXT to it
> > using port 9100.
> >
> > What I CANNOT do is find it in CUPS. Or avahi-browse, or driverless, or
> > any of these other commands that are so allegedly wonderful.
> >
> > Is there any way I can tell CUPS "Please set up a queue for a printer
> > whose IP address is 10.76.172.100 even though you can't discover it with
> > your fancy tools"?
>
> The way I see it, Greg wrote about a CUPS configuration problem.
> The solution of said problem was (and still is btw) at lpadmin(8).
> Of course, to know that the solution just lies there, waiting to be
> implemented, that requires one to have a knowledge of CUPS administration.
> Luckily we have debian-user for last one.
Your interpretation of the OP's situation is misguided. He was
confused and, as such users do sometimes, lashed out at anything
in sight. There was not any CUPS missconfiguration.
Actually, CUPS performed splendidly. The OP was on a badly set
up, unco-operative network. That was (and probably still is) the
root of the issue.
> > How would an ordinary user go on? "Give them a piece of paper" sounds
> > awfully like "Let them eat cake".
>
> Easy, a user should RTFM. Failing that, a user can use a different
> device or OS, or *gasp* - just use ipptool. Given the environment, a
> creative use of samba suite would probably solve the problem too, but
> let's not get into *that*.
> And there's that last step - just ask somebody.
You welcome Big Boss into your office for a $100M deal.
Big Boss: Contract's on my phone. Let's print it and I'll sign.
What's the printer name?
You: GimmeMoney
Big Boss: Can't see it.
You: Just let me read the manual and do a bit of network probing.
Big Boss: (10 minutes later). Any joy?
You: No. I'll go ask someone. Give me half an hour.
Big Boss: I'm a busy woman with other options. Goodbye.
--
Brian.
