Ticket #1021 (closed task: fixed)

Opened 10 years ago

Last modified 8 years ago

KIll off LPRng

Reported by: geofft Owned by: jdreed
Priority: normal Milestone: Current Semester
Component: -- Keywords:
Cc: Fixed in version: debathena-printing-config 1.30
Upstream bug:

Description

Ops has turned off the LPRng servers. Per #465, we should stop supporting the LPRng client, i.e., debathenifying it, including it, including debathena-lprng-config, calling it from debathena-printing-config, and enabling the LPR print dialog backend in the global gtkrc.

This is actually a bit tricky, though, because it is LPRng that we call to print to non-Athena LPR printers: LPRng supports the lpr -Pqueue@host syntax, and CUPS doesn't. (And CUPS would print over IPP instead of LPR anyway.) And if we want to keep unpatched, unconfigured LPRng around, we have a couple of issues: at least, LPRng likes to run a server by default, which we disable, and it installs to /usr/bin/lpr etc., which we rename out of the way in our rebuild so that it doesn't conflict with cupsys-bsd, which we definitely want.

Another option would be to use a lightweight, serverless LPR-compatible client like rlpr. Since it installs itself as rlpr, rlpq, and rlprm, there aren't any filename conflicts. It seems to work in light testing; the only real issue is that it displays "warning: cannot bind to privileged ports: lpd may reject" all the time. It might be possible to suppress this in the global rlprrc.

A similar option would be to take the Python code we started including in debathena-printing-config's lpq to work around CUPS 1.3 issues, and extend that to have lpr and lprm support. It's not like LPD is a hard protocol.

Still another option would be to figure out some way for CUPS to dynamically use the lpd: backend without configuring a queue first. This might actually be something we want to do to pull off some other ponies, like entering a custom printer in the print dialog (see #465 and #378). We currently do this with the LPR backend to gtk, which we'd like to get rid of. Having the CUPS backend deal would be nicer.

Finally, we could decide that the upstream way and light is not to support the lpr -Pqueue@host syntax, and have you create a new CUPS queue before printing, and that if you really care you should just locally install rlpr or something. (If go this route, I might be tempted to put rlpr in extra-software or so.)

Change History

comment:1 Changed 10 years ago by jdreed

"What LPR queues?" In theory, we have no official ones. Users of unofficial ones can suck it up and add a printer via s-c-p. That is the right answer here.

comment:2 Changed 9 years ago by jdreed

  • Status changed from new to closed
  • Resolution set to wontfix

We're not doing anything with LPRng anymore. Users who want it can put it in lockers or something. People who want LPD queues can use the CUPS LPD backend.

comment:3 Changed 9 years ago by jdreed

  • Status changed from closed to reopened
  • Resolution wontfix deleted

No, we still want this open until we actually kill it with fire.

comment:4 Changed 9 years ago by jdreed

I think the answer here is "Ubuntu has decided to use CUPS. CUPS requires you to configure an LPD queue prior to printing to it. Have a nice day.".

I would like to pull LPRng from the release this summer. I have no problem adding rlpr, and I don't even think we need to worry about that error message -- if you're trying to use rlpr, you probably know what you're doing.

comment:5 Changed 9 years ago by jdreed

  • Milestone changed from The Distant Future to Precise Release
  • Summary changed from Will no one rid me of this turbulent LPRng? to KIll off LPRng

I played with rlpr and like it. rlpr goes in the release, LPRng dies, we're done.

comment:6 Changed 9 years ago by jdreed

rlpr added to extra-software-nox 1.4 (r25645)

comment:7 Changed 9 years ago by jdreed

  • Status changed from reopened to committed

extra-software-nox 1.4 in -dev.

The actual killing will be done in October. Once this goes into prod, this changes back to "accepted" and then we do the actual killing.

Also, uh, did printing-config ever support printer@host? I'm not sure it did.

comment:8 Changed 9 years ago by jdreed

  • Status changed from committed to development

comment:9 Changed 9 years ago by jdreed

  • Status changed from development to proposed
  • Fixed in version set to deabthena-extra-software-nox 1.4

comment:10 Changed 9 years ago by jdreed

  • Status changed from proposed to new
  • Fixed in version deabthena-extra-software-nox 1.4 deleted
  • Milestone changed from Precise Release to Quantum Quetzalcoatl

OK, rlpr is now in the release. We need to actually pull LPRng later this fall.

comment:11 follow-up: ↓ 12 Changed 8 years ago by jdreed

  • Owner set to jdreed
  • Status changed from new to accepted

So, the question is: Do we want printing-config to continue to be clever and shell out to rlpr, or do we just want printing-config to only accept CUPS and mention rlpr in any error messages? I favor the latter, I think.

comment:12 in reply to: ↑ 11 Changed 8 years ago by kaduk

Replying to jdreed:

So, the question is: Do we want printing-config to continue to be clever and shell out to rlpr, or do we just want printing-config to only accept CUPS and mention rlpr in any error messages? I favor the latter, I think.

Excessive cleverness seems likely to end up with things pointed at one's own appendages; I think you are probably right.

comment:13 Changed 8 years ago by jdreed

  • Status changed from accepted to committed
  • Fixed in version set to debathena-printing-config 1.30

comment:14 Changed 8 years ago by jdreed

(Part of this issue was tracked in #860)

comment:15 Changed 8 years ago by jdreed

  • Status changed from committed to development

comment:16 Changed 8 years ago by jdreed

Right, this breaks "lpq -Pbw", which apparently the entire world has been doing, despite being told not to, because printing-config rightly assumes that all Hesiod printcap entries are CUPS servers, and of course Pharos isn't. I'm fine with not caring, but I'm loathe to break behavior during the term. I wonder if it would be terrible to special-case our pharos servers, and print an error message, and we cna throw "pharoslpq" in the printing locker.

comment:17 Changed 8 years ago by jdreed

OK, I committed 1.31, which special-cases anything whose server is PHAROS-PRODP1, and goes through the lpq compatibility code. /mit/printing/bin/pharoslpq is also now a thing

comment:18 Changed 8 years ago by jdreed

  • Status changed from development to closed
  • Resolution set to fixed

Finally in production.

"And the people did feast upon the lambs and sloths and carp and anchovies and orangutans and breakfast cereals, and fruit bats ..."

Note: See TracTickets for help on using tickets.