Ticket #465 (closed task: fixed)

Opened 11 years ago

Last modified 9 years ago

come up with a coherent plan for debathena-printing-config

Reported by: geofft Owned by:
Priority: normal Milestone: Precise Release
Component: printing Keywords:
Cc: broder Fixed in version:
Upstream bug:

Description (last modified by geofft) (diff)

Right now our lpr wrapper is a descendant of a descendant of a hack, solving lots of little use cases but with no particular overarching intention about what it's doing. While we shouldn't forget about the edge cases we're supporting and break them in a rewrite (cf. #455), it's about time to have a clear design and spec for what it's doing rather than continuing its descent into feature creep.

As I see it the two main issues with the current setup is that user-visible behavior depends on users being aware of whether a queue is CUPS and LPRng and that answering questions about the behavior usually requires looking at the source.

This includes: (some of the following are inspired by TODOs in the current printing-config lpr wrapper)

  • Should we support the traditional LPRng arguments that Athena's used for years, e.g., -Zduplex (ticket #444)? Forever?
  • Should we try to get these arguments upstream somehow, or is a cross-platform Athena lpr script that you can put early in your PATH sufficient? (Or do we not care for non-Athena platforms?)
  • Should the LPROPT environment variable be supported? Currently if you are printing to a CUPS queue, and if passed to lpr can be interpreted purely as CUPS arguments (such as if you just do lpr -Pfoo), then the arguments in LPROPT aren't inserted into the processed command-line arguments (see also  RT:1098339). We could desupport it, or support it all the time.
  • How do you default to double-sided printing, etc., for all queues? In theory LPROPT is an answer, but converting LPRng args to CUPS ones in perpetuity is silly and prevents you from actually specifying default CUPS arguments.
  • Are we keeping LPRng clients installed forever, or at some point will we say that if you want to print to an lpd printer, you should add a CUPS queue, and that Kerberized lpd printing is desupported (unless CUPS grows support for it)? (We can also keep the clients around while making lpr.debathena never call them.)
  • Are we keeping Hesiod pcap entries forever?
  • Are we keeping the "Print to LPR..." gtk backend forever? This saved me last week when some subtle BrowsePolling? bug caused only three faraway printers to show up in the pick list, but this is a config change from upstream and one that I think we intended to be temporary.
  • Can CUPS be made to zephyr (ticket #184)
  • Can CUPS be made to have an equivalent of -Zbanner=?

Change History

comment:1 Changed 11 years ago by geofft

  • Cc broder added
  • Summary changed from printing-config wrappers don't always use LPROPT to come up with a coherent plan for debathena-printing-config
  • Description modified (diff)
  • Reporter changed from broder to geofft
  • Milestone set to IAP 2010

comment:2 Changed 11 years ago by andersk

We want Debathena to be as easy to maintain as possible into the future, and we want debathena-standard to modify as little of the user’s software as necessary. In the ideal future, LPRng will be gone and CUPS upstream will eventually have integrated enough functionality that we will not need wrapper scripts for CUPS commands. We should work with the CUPS developers to get there as quickly as possible.

(Fundamentally, there’s no reason you should need to use different software to print to Athena vs. printing to anywhere else. And it’s especially poor if you can’t do both from the same computer.)

So, until we get there, the wrapper scripts should add as little functionality as realistically necessary on top of CUPS queues. (It can do whatever it wants to LPRng queues, as long as we can eventually remove it all.) We should agree with upstream on a switch for duplex printing, a replacement for LPROPT, and a clean way to redirect lpq/lpc/etc. to other print servers. We should implement it in the wrapper scripts for old CUPS versions, and then deprecate anything else with a clear warning message so that it can eventually be removed.

comment:3 in reply to: ↑ description Changed 11 years ago by broder

Replying to geofft:

This includes: (some of the following are inspired by TODOs in the current printing-config lpr wrapper)

  • Should we support the traditional LPRng arguments that Athena's used for years, e.g., -Zduplex (ticket #444)? Forever?

My preference is to translate them with a warning for the indefinite future, and possibly de-support them in a year or so.

  • Should we try to get these arguments upstream somehow, or is a cross-platform Athena lpr script that you can put early in your PATH sufficient? (Or do we not care for non-Athena platforms?)

We should see if CUPS supports a Location header or can be made to. If it can, my best idea on how to make this work is to support a special redirect:// backend that does the appropriate 301 or 302 redirect to another URL.

Since I believe some of the IPP protocol basically consists of POST requests, we also need to figure out how to make the client do the right thing with redirects of a POST request. Of course, since we (or CUPS upstream, really) controls the client, we can make the behavior whatever we want.

  • Should the LPROPT environment variable be supported? Currently if you are printing to a CUPS queue, and if passed to lpr can be interpreted purely as CUPS arguments (such as if you just do lpr -Pfoo), then the arguments in LPROPT aren't inserted into the processed command-line arguments (see also  RT:1098339). We could desupport it, or support it all the time.

My inclination is that we shouldn't add any support for LPROPT over what's already present in CUPS upstream. I'd rather see us lean on  CUPS:3455 and get support for a syntax in ~/.cups/lpoptions that does the same thing.

  • How do you default to double-sided printing, etc., for all queues? In theory LPROPT is an answer, but converting LPRng args to CUPS ones in perpetuity is silly and prevents you from actually specifying default CUPS arguments.

I think  CUPS:3455 is the right answer here - add support for a new syntax in ~/.cups/lpoptions and /etc/cups/lpoptions that specifies defaults across all queues. If we can convince CUPS upstream to add this support, we can bridge the gap in our wrapper scripts and interpret ~/.cups/lpoptions and /etc/cups/lpoptions in our wrappers until the version of CUPS in Debian/Ubuntu? catches up.

  • Are we keeping LPRng clients installed forever, or at some point will we say that if you want to print to an lpd printer, you should add a CUPS queue, and that Kerberized lpd printing is desupported (unless CUPS grows support for it)? (We can also keep the clients around while making lpr.debathena never call them.)

I don't think we should support LPRng past when ops decommissions their LPRng servers. I don't think we should go out of our way at all to support Kerberized lpd - if you need Kerberized printing, you should do it with CUPS. If that's too hard now, then maybe SIPB should pull some docs together.

  • Are we keeping Hesiod pcap entries forever?

It'd certainly be nice to move pcap entries into LDAP. mmanley certainly had an LDAP server running on printers.mit.edu at one point when he was planning to use that as a BrowsePoll? replacement - maybe it's possible to get that server running again to replace Hesiod. But other than that, moving things out of Hesiod and into something isn't really a Debathena discussion - it's something to coordinate with ops and network, which goes outside the scope of release-team.

  • Are we keeping the "Print to LPR..." gtk backend forever? This saved me last week when some subtle BrowsePolling? bug caused only three faraway printers to show up in the pick list, but this is a config change from upstream and one that I think we intended to be temporary.

I think we should assume we'll be keeping it indefinitely, since we've basically confirmed that it'll never be possible to have all of our print queues show up in the picklist. On the other hand, if we come up with our own backend that uses CUPS but lets you type in a printer name somewhere, I don't see any reason to keep "Print to LPR..." around.

  • Can CUPS be made to zephyr (ticket #184)

This is a question for mmanley, not Debathena.

  • Can CUPS be made to have an equivalent of -Zbanner=?

Yes - I think the way to do this is to support something like -o job-sheets=athena-staff or whatever. I'm still not sure if there's an easier way to configure this than to have N completely separate copies of the banner sheet.

comment:4 Changed 11 years ago by jdreed

  • Priority changed from critical to major
  • Type changed from defect to task
  • Milestone changed from Karmic Deploy to Summer 2010

This is a task, not a defect.

I think we're at the point where things work reasonably reliably with our wrapper, so I don't think we should add functionality to it. Going forward, a coherent plan may be difficult given the large number of moving targets: CUPS itself, our printing environment, our default per-queue settings, the status of authenticated printing, and Athena 9.

Once Karmic is out and all CUPS-style commands actually work (lp, cancel, lpstat, etc), my plan is to transition documentation to CUPS-style commands, and teach those to the incoming frosh in August. By IAP '11, we can hopefully have the lprng-style wrappers start whining loudly at users.

However, there are some issues with this plan:

  • It assumes we're going to be an all-CUPS environment. It's not clear to me that this is true if we go down the Pharos road.
  • The CUPS commands still fail miserably in our F5/bounce queue environment. We should work with upstream to make them not suck, but we have to do that ~now, if there's any hope of getting SRUs in time for August.

It seems to me both of these things could be solved with wrappers around the CUPS commands. I don't have a problem with this, particularly if we're only playing with the -P and -h arguments, and passing everything else intact.

That having been said, we only get to re-train the users *once*, realistically. I don't want to be in the position of implementing a huge transition from LPRng-syntax to CUPS-syntax, to only have us then move to /usr/bin/pharos-print, or a web interface, or something.

So we should come up with the UI the way we want it, and then keep that static. If that means wrapper scripts, it means wrapper scripts. But I'll note there's a huge difference between the scary argument-munging we do now, and simply mucking with the queue name or host name.

comment:5 Changed 11 years ago by jdreed

  • Status changed from new to proposed

This is Evan's awesome thing in proposed, right? (Scheduled to move to production this weekend or on Monday)

comment:6 follow-up: ↓ 7 Changed 11 years ago by andersk

I’m pretty sure that, regardless of Evan’s awesome thing in proposed, a coherent plan is still sorely lacking.

comment:7 in reply to: ↑ 6 Changed 11 years ago by geofft

  • Status changed from proposed to new
  • Milestone changed from Summer 2010 (Lucid Deploy) to The Distant Future

Replying to andersk:

I’m pretty sure that, regardless of Evan’s awesome thing in proposed, a coherent plan is still sorely lacking.

Agreed. We moved Evan's awesome thing to production last night. Per release-team discussion we're planning on not targeting Maverick for the clusters, given previous bad experiences both with October releases and our ability to get them out, and planning on using that time to address some of the Distant Future tickets. I'm remilestoning this to one of them since it's an actual-effort ticket, and to a large extent it depends on the current state of Athena printing, so we should watch what happens with Pharos &c.

comment:8 Changed 11 years ago by geofft

Let me note a few things here before I forget them. Some may end up being separate tickets (and some may be extant tickets, not sure):

  • It is impossible to print to a non-cluster printer from Acrobat Reader (or most other clients that implement CUPS on their own, instead of using GTK+, so the thing in printing-config where we add "Print to LPR" to the GTK+ dialog box doesn't help; I believe this includes Matlab and OOo).
  • It is impossible to set an LPROPT environment variable to double-side printouts, since we add LPROPT to the command line before transformation regardless of whether the rest of the command line is an LPRng one or a CUPS one (and indeed before we know which it is). If you set LPROPT to -hZduplex, then programs like Acrobat Reader that generate CUPS command lines with -o will cause an invalid half-LPRng half-CUPS argument list to get passed to our wrapper.
  • Relatedly, we don't catch errors, and you get an ugly backtrace that "NoneType? is not iterable" if you do that. Took _me_ a few minutes to figure out what was up when helping a user with this.
  • It is impossible to turn off header pages in Acrobat Reader, because that's not one of the options its CUPS support exposes.
  • Nobody has any idea whether things are coming out single-sided or double-sided any more, because some apps do CUPS support and some don't, and it depends on whether you click "Print to LPR" in the GTK+ print dialog or not. The end result is that everything gets printed twice.

comment:9 Changed 10 years ago by geofft

So yeah, there's this Pharos thing. Looking at things raised above:

  • Header pages are no longer interesting, nor is zephyring on job completion.
  • Command-line compatibility might be. ... does mit-lpr -Zduplex -Pbw@mitprint work? Or do you use lpr -o sides=two-sided-long-edge and let the hpijs driver encode that?
  • Being able to set defaults, specifically single/double-sided printing, is interesting.
  • Printing to non-Pharos printers from Athena via either the command-line or a GUI is still interesting.
  • printing-config existing for non-Athena platforms is not really interesting, I think, since it's only one queue to add now and you don't need to involve Hesiod in any way.
  • Kerberized LPR is not our problem. If someone else wants to make it work on their machines / print server and get things working upstream, good for them.

comment:10 Changed 9 years ago by jdreed

I have opened #1128 and #1129 for the upstream issues. I think the only remaining question here is "Are we keeping the "Print to LPR" backend. I think we are, at least for the next release, because this is a user education issue. Thoughts?

comment:11 Changed 9 years ago by jdreed

  • Milestone changed from The Distant Future to Precise Release

We have one. rlpr is going in the release, LPRng is getting pulled by Quizzical at the latest, and printing-config will go back to its solitary life of being a wrapper to make the F5-CUPS interaction suck slightly less.

comment:12 Changed 9 years ago by jdreed

  • Status changed from new to closed
  • Resolution set to fixed
Note: See TracTickets for help on using tickets.