Non-BSD CUPS clients should choose the correct server

[broder]

Apparently the BSD-style commands (lpr, lpq, lprm, lpc) are being phased out with CUPS in favor of the SysV-style commands (lp, lpstat, cancel, etc). If that's the case, we're probably going to want to eventually transition to teaching and using the SysV commands, which means they're going to need to be able to deal with our multi-server configuration.

Specifically, we probably want to add wrapper scripts for:

• cancel
• lpstat
• lpoptions
• accept
• reject
• cupsaccept
• cupsreject
• lpmove
• cupsenable
• cupsdisable

We probably don't care about wrapper scripts for:

• cupstestdsc
• cupstestppd
• cupsaddsmb
• lppasswd
• lpadmin
• cupsctl
• lpinfo

[broder]

While I'm not working on this issue specifically, I'm currently doing a fairly substantial reorganization of printing-config that will conflict with anybody attempting to work on this.

On the upside, it'll make solving this ticket much easier.

[broder]

Ok - I've finished my substantial refactoring of printing-config, so anybody who is interested in working on this should feel free.

[jdreed]

Of these, cancel and lpstat are the highest priority, since I want to teach the frosh about them (and not lpq/lprm, since CUPS seems hell-bent on breaking all Berkeley functionality).

[jdreed]

I'm going to postpone this, for a couple of reasons:

-simple.simple doesn't exactly do what we want here. Specifically, it requires an option that specifies the queue. cancel(1) doesn't have such an option. lpstat(1) has 3, depending on how it was invoked. So this requires a bit more thought.

• CUPS broke BSD functionality, or something. I cannot figure out how to get a single queue listing using lpstat on Lucid.

         Jaunty:
         $ lpstat -h get-print -o westgate
         westgate-453690         Jin           129430528   Wed 18 Aug 2010 09:57:34 AM EDT
     
         Lucid:
         $ lpstat -h get-print -o westgate
         ashdown-453113          tcolle          173056   Tue 17 Aug 2010 12:45:23 AM EDT
         acantha-453314          SONY            330752   Tue 17 Aug 2010 12:54:49 PM EDT
         albany-453356           qjli            152576   Tue 17 Aug 2010 02:30:18 PM EDT
         clearcut-453363         hollings        175104   Tue 17 Aug 2010 02:46:01 PM EDT
         acantha-453314          SONY            330752   Tue 17 Aug 2010 12:54:49 PM EDT  
         albany-453356           qjli            152576   Tue 17 Aug 2010 02:30:18 PM EDT
         clearcut-453363         hollings        175104   Tue 17 Aug 2010 02:46:01 PM EDT
         albany-453401           kennylam       1103872   Tue 17 Aug 2010 03:58:52 PM EDT
         ashdown-453544          coolhuh         114688   Tue 17 Aug 2010 07:33:35 PM EDT
         ashdown-453545          coolhuh          17408   Tue 17 Aug 2010 07:33:39 PM EDT
         albany-453554           cbonnoit       6581248   Tue 17 Aug 2010 08:08:22 PM EDT
         ashdown-453560          chouskyr         52224   Tue 17 Aug 2010 09:11:44 PM EDT
         ashdown-453568          davliu          906240   Tue 17 Aug 2010 10:30:28 PM EDT
         ashdown-453620          nikhilg1       2117632   Wed 18 Aug 2010 12:36:30 AM EDT
         acantha-453677          pwidener       1143808   Wed 18 Aug 2010 09:42:22 AM EDT
         ashdown-453686          apgarcia      50971648   Wed 18 Aug 2010 09:51:46 AM EDT
         westgate-453690         Jin           129430528   Wed 18 Aug 2010 09:57:34 AM EDT
         celine-453691           chenxin        1847296   Wed 18 Aug 2010 09:59:09 AM EDT
         celine-453692           chenxin        2155520   Wed 18 Aug 2010 10:00:30 AM EDT
  

(same behavior if I use CUPS_SERVER instead of -h, and whether or not I use the FQDN of the print server).

• We're already scrambling, and we don't have time to re-train the user community to use the BSD commands. So I think we should wait and see what this semester brings in terms of printing changes.

[jdreed]

s/BSD/SysV/g, obviously.

[jdreed]

Once again, I want to see where we are with Pharos. There is no job control with Pharos nor with IP printing. I think the right answer is going to be to not use simple.simple (for the reasons specified above). We may end up using some parts of it, but I think we're going to need separate wrappers for each command, because CUPS hates consistency. However, I think we wrap at most lpstat and cancel, and move on. The job control command wrappers can live in a locker or something.

[jdreed]

OK, I've been thinking a bit more about this. I started writing a wrapper for cancel(1), but thinking more about it, I'm not sure we want this, for a couple of reasons:
a) PRINTER has never worked with SysV clients
b) SysV clients have never worked with Hesiod

There's no historical behavior to support here, and we're trying to convince people who want a Hesiod queue to create a local CUPS queue. Also, as noted, the SysV commands don't fall easily into the model of printing-config. For example, "cancel 123" can mean "cancel job 123 on the default printer" or "cancel the default job on printer 123". If we suddenly make cancel(1) Hesiod-aware, then the behavior of "cancel 123" could easily change. And I don't think we want to do that.

I think we also need to have a detailed conversation with Ops about the future of centrally-maintained print queues.

[jdreed]

At release-team, we decided that we only need to support the legacy behavior of printing to a non-locally-configured-printer from the BSD clients. If you want to use the SysV clients (modulo "lp", which is special), go configure a local queue pointing at the printer you want. (We can of course later flip out and implement a new central printing infrastructure that works seamlessly with CUPS, using both SysV and BSD clients, but we don't have that now)

[jdreed]

Apparently the BSD-style commands (lpr, lpq, lprm, lpc) are being phased out with CUPS in favor of the SysV-style commands (lp, lpstat, cancel, etc).

Also, uh, [citation needed]. I don't see Ubuntu or any distro being able to completely punt all BSD functionality. Certainly those commands are well documented on the Apple side, which is upstream these days.

[jdreed]

Also also, "go configure a local queue" is and has always been the right answer. That is only Effort(tm) on cluster, and really, it's not that hard. Whatever we do for #761 could easily re-add printers.