Straight-forward Print Quota System for *nix?
saihung writes: "I pitched a Linux-based file and print queue server to a department at a local university, and they accepted with one caveat: that I also implement print quotas and accounting. The accounting isn't really a big deal, but I've looked high and low and found nothing even approaching comprehensive quota support. Does anyone know of a print quota system for *nix that doesn't amount to "here's a few perl scripts that don't work"?" There are several printing systems under development, but I don't have any idea which would be the easiest to implement a print quota system. Anyone?
in my time we used to use lpr to do everything. .. no fancy software and roll their own accounting/quota system using shell scripts.
/ printer_quota
real men use pure unix tools
If you really must have a howto on implementation details checks this site out : http://www.sct.gu.edu.au/~anthony/info/postscript
We use CUPS (The Common Unix Printing System) and find it very good. It seems they added quota support in 1.1.5, but I can't find any docs. It may be worth investigating this.
The Univ. of Bonn CS Dept. has a very nice
d e. html
homegrown network print accounting/quota system
written by Walter Steiner that handles different
cost on different printers, printing budgets,
accounting to different cost groups etc.
There is a german description on
http://www.informatik.uni-bonn.de/dv/pac/wspac-
I suggest you contact pacadm@iai.uni-bonn.de and
ask if they'll let you have it.
--Andreas
"in my time" must have been the '70s or early '80s. Anything that happend in the late '80s or '90s is "back in the day."
If all this should have a reason, we would be the last to know.
The biggest problem we had (still have?) with the PAS is figuring out how many pages in a print job. If this is a text file, its trivially easy, just divide by the number of lines per page. However with postscript, this is not at all easy. We have tried:
1) Using the % Pages: in the postscript file. This does not work in all cases. Remember that anything begining with % in postscript is a comment. While it *should* be there and *should* be correct, it does *NOT* have to. An example is mpage, the multi-up printer does not change the % Page : # comment line.
2) Using ghostscript to count bounding boxes. This is slow. Also, bounding boxes can be nested.
3) Hacking ghostscript to get the correct number of pages. This is slow. When a 250 page thesis is printed, ghostscript will slow things down by a good 10 minuts (on the machnine that is our print server). Further problems occur when the user lp's a 250 page job, then cancels it using the printer's control panel after only a few pages are printed. Here the user would get docked for the full 250 pages.
And finally what we do use:
4) Asking the printer how many pages it has printed before and after the print job and subtracting.
There are three ways that we do this. All three are printer dependent. Generally these will work on HP brand printers, YMMV.
We use HP's PJL to query the printer. This works on some printers but not all. (Does not work on all HP printers for that matter.)
We send a postscript job to the printer that request the printer how many pages it has printed. This works on most postscript printers, but as always, not all. I don't have the postscript handy, but if you need I can send it to you.
And lastly, we use SNMP to query the printer. Originally I just hacked a snmpget to get the number, but the OID seems to change (just a little) from printer to printer. I currently use a lp utility that I found on freshmeat that I don't remember the name of right now. (I'm not at work right now.) We had to hack it just a bit for some of our printers.
I would like to put all three of the above into one messy script, but have not had the time. We just run a hacked and kludged PAS. It works though ;)
There is one major drawback to this: we don't know how many pages in a print job until *after* it has printed. Thus, if a user has 1 page left in their print quota, then prints 10000 pages, we don't stop the job, nor do we stop the job in the middle. We just let the quota go negitive, so the user would have -9999 pages left. This does not seem to be too big of a problem in our environment. I'm sure a few people run the quotas negitive and then leave town, but its not enough to worry about.
As for the implementation of the rest of the PAS, thats pretty straight forward. Ours are made of ugly hacks and such, due to evolution and too many different developers working on the project in the past.
If you would like more info email me at (rewrite as appropiate): john harris vt edu.