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. > 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. > 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. > 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. > > > I've gotta say, though, this option is a disaster: > > > > > > -E When specified before the -d, -p, or -x options, forces the use of > > > TLS encryption on the connection to the scheduler. Otherwise, > > > enables > > > the destination and accepts jobs; this is the same as running the > > > cupsaccept(8) and cupsenable(8) programs on the destination. > > > > > > Whoever decided to overload that option in that way... yikes. > > > > Back in the day Apple's slogan was "think different". The whole CUPS > > suite is a living proof of that. > > Wrong target! -E was there in its present form well before Apple > acquired CUPS. I stand corrected here. Reco
