[6525] in Release_7.7_team
Re: lprm for normal users doesn't work
daemon@ATHENA.MIT.EDU (Mark W. Manley)
Mon Nov 23 08:10:58 2009
Date: Mon, 23 Nov 2009 08:10:47 -0500 (EST)
From: "Mark W. Manley" <mmanley@MIT.EDU>
To: Geoffrey Thomas <geofft@mit.edu>
cc: ops@mit.edu, release-team@mit.edu, debathena@mit.edu
In-Reply-To: <alpine.DEB.1.10.0911230652280.948@dr-wily.mit.edu>
Message-ID: <alpine.DEB.2.00.0911230749310.30071@green-arrow.mit.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: -2.599
X-Spam-Flag: NO
That you have to point directly at the CUPS server in question (e.g.
print-this) is a totally known quantity that I mentioned at least twice.
I even mentioned it in the release team meeting again on Friday. That's
because when you submit a print job to the printers.mit.edu system, any
one of four servers will take the job, then bounce the jobs internally to
the final server (the one in Hesiod) for spooling to the printer. This
way, there aren't multiple servers trying to compete to send a job to the
same printer and there is a single server against which you can point
clients like lprm and cancel(*) to abort your jobs.
I can make the server short names work. I just put in the changes into
the CUPS configuration files and it should take effect by 11 today (I'll
just let the normal restarts take the changes). After that, you should be
able to point to sawmill and not to sawmill.mit.edu and what not.
Pointing to printers for queue operators will not work and will probably
never work because I can't make all six CUPS servers cognizant of all the
spooled jobs in all the queues on all six servers at once. If CUPS had a
real cluster mode, then that would be totally feasible, but it doesn't.
It's what's also driving me bonkers for Kerberized printing. So for now,
we just have to live with the methodology of looking up the queue and
directing queue operations there (a wrapper would be totes useful and
would be easy to write).
The (*) is because I see that the Berkeley commands are being deprecated
slowly in CUPS to de-support Berkeley-style printing. That writing has
been on the wall for a while, so if we're teaching users new tricks, I
suggest that the OLC folks may want to also start practicing their
SysV-style printing commands like:
lpr = lp
lprm = cancel
lpq = lpstat
lpc move = lpmove
lpc stop = cupsdisable
lpc start = cupsenable
lpc down = cupsreject
lpc up = cupsaccept
lpc holdall = cupsdisable --hold
lpc release = cupsenable --release
I'm sure there are more that I'll think of later. The lpr/lprm/lpq
commands are still fully supported, but you'll notice that if you try to
lpc against a CUPS queue, you'll get a dearth of options since the CUPS
folks decided that lpc wasn't worth continuing to work. I'm not sure why
they did that, but I didn't write the code.
Anyway, I appreciate your writing that wrapper. It's something that I
have wanted and suggested for a while. Your assessment of "it may not be
even possible" is, sadly, probably correct. Every time I try to do
something less non-clever on the server end to make it work, the clients
find a way to bung it up. Blergh.
-MM
On Mon, 23 Nov 2009, Geoffrey Thomas wrote:
> OLC ticket #1081121 implied that lprm for users without special printer bits
> doesn't work. This appears to be basically correct: as starnine@linerva I
> printed a job onto ceres' queue, and found that it has id 6900.
>
> lprm -Pceres gives no output and doesn't remove the job.
>
> lprm -Pceres 6900 gives me ASCII character 0x01 back (and doesn't remove the
> job either).
>
> cups-lprm -Pceres says "No active jobs on ceres!", and cups-lprm -Pceres 6900
> says "Job #6900 does not exist!"
>
> Adding -h printers.mit.edu gives the same result.
>
> Dereferencing the back-end server and trying cups-lprm -Pceres -h
> print-this.mit.edu gives "Forbidden".
>
> Finally cups-lprm -Pceres -h print-this.mit.edu 6900 succeeds. So while it's
> technically possible for an unprivileged user to remove his or her own jobs,
> it's not actually possible in practice. I don't know enough about CUPS to
> suggest how to fix this from the server side, and it might not even be
> possible. I can write up an emergency fix on the client side to do the
> various lookups; it would only apply to Debathena clients, but it might be
> good enough for now.
>
> --
> Geoffrey Thomas
> geofft@mit.edu
>
> (For bonus points, -h printers and -h print-this without the rest of the FQDN
> don't work, with "Error - unknown destination "ceres"!")
>
>
>
