Slashdot Mirror
Printer Quotas in Linux?
borgquite asks: "At the
school that I work for students waste a lot of paper and toner because they
print without thinking. I've been looking at printer quota / charging software,
but unfortunately I can't seem to find any for Linux, and the
Windows
based
software is all priced
far too high. What I need to do is to say that students can print a certain
amount per day/week/month/year, and provide a system where they can
pay to increase their quota. I've looked for Linux / BSD based solutions,
but all I could find is lots of references to a tool called lpquota, but no
information on how I can obtain and implement this on my network. Does
anyone know of such a system?"
Of course, this was back when line-printers were still in use. Printing any code listing on a laser printer is pretty much worthless. I'd give my right arm for an old 9pin epson with formfeed.
Anyways, doesn't lpd(1) keep track of page count? Seems like you could do something with that, assuming all of the users have an account on the print server.
lprng/ifhp and printers with hardware pagecounters enable this functionality. We have implemented this for approximately 50 great lexmark laser printers across 5 campuses (hint.. look at the achk and af entries that you can put in to an lprng printcap file).
I strongly recommend reading lprng doco regarding pagecounting. And then don't follow our example and use software based counting instead (which we may test when we get time.. I think it is also much easier to implement as good hardware page counters in printers are rare these days).
~~~
the quick brown fox jumps over the lazy dog
I don't think it would be too difficult to write a
program that would:
1. Count how many times 'showpage' shows up in a
postscript doucment
2. keep track of how many 'showpage's each student
has sent
3. pass all arugment received by the program to lpr
4. gives lpr its own uid, have only that uid be able to access the printer, have only that uid be able to run lpr, and have your program run suid
CUPS (Common Unix Printing System) has support for simple quotaing. You can limit number of pages per user per time interval (e.g. month) and so forth. You cannot however set quotas per user individually or per user group. THere is, however a page_log which logs who has print how many pages. This can be used to disable access to the printing server for those who print to much to your likings :)
-larsch
It might be useful to see if you can track down
the quota software MIT used to use. MIT has
a very heterogenous environment so that speaks
well for this. It's also interesting to note
that MIT no longer enforces a printing quota.
Previously students were allowed 1000 pages per year free, and additional at some preset rate.
Were that I say, pancakes?
To count the number of pages in a PostScript file you'll have to run it through a PostScript interpreter (e.g. GhostScript) and get it to count the pages. You'll then have to send the PS to the printer (or if you have a non-PS printer driven by GS you could count the pages and spit the GS output to the printer simultaneously).
Printers with hardware page counters are a better bet - get the page count, print the job, get the page count, subtract.
Yes, you're right. My explanation was highly simplified and I can think of several other ways to beat it as stated, though I admit that one didn't occur to me.
If you do implement printing quotas, it would be nice to also provide options like printing 4 pages on one sheet, and maybe double sided printing. This doesn't reduce toner costs (the more expensive part, I would presume), but it does reduce paper use, which is always a nice plus. I used to do this when I needed to print out tons of pages of class notes at the end of the semester.
"Of all days, the day on which one has not laughed is the most surely the one wasted." -Sebastian Roch Nicol
Check out Printbill. It provides a fair way to bill printjobs. Basically, when you print a job, it scans the document and analyzes the amount of ink that is actually used. Then, it charges the user for cost of the ink and the paper. If the user has a sufficient quota to cover the job, it'll print it.
It's designed to be used in a pre-pay system. But it's all in perl, so you could easily hack it to support other methods (i.e. email them a bill at the end of the semester, etc.)
-Andy
This is slightly off-topic, but it's already a good practice to use two (or more) lprng queues.
All of the "public" queues are located on a central server, where the jobs are "cooked" by ghostscript, troff, whatever (you can easily create very specialized queues!) and the results 'bounced' into a 'raw' queue for each printer. The raw queues may be held on the print server, but they ultimately feed queues on the systems that host the individual printers.
The point of mentioning this? It's not practical to count the number of pages of the original queue, but it shouldn't be hard to run the 'raw' queue through a filter that parses the PCL being sent to the printer and counts the number of "page eject" (or whatever PCL uses) in each job. At worst this would require an additional bounce queue for each printer, but it wouldn't require additional disk space since the jobs shouldn't remain in this queue for long.
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
It worked pretty well, apart from some issues with certain printer drivers where my scripts didn't pick up the fact it was postscript so it counted the number of lines/80! For graphics, this gave some very skewed results, but that was fixed easily enough. Wish I'd kept the scripts; they took me a while to write...
you can do it all in software. i implemented a printbill (http://freshmeat.net/projects/printbill/) based system with debian print servers, postgresql for the database and printbill to handle the rest. printbill can also be obtained with apt-get install printbill and it gives stuff like per page toner accounting, coverage accounting and stuff for inkjet printers as well as lasers. very useful.
Columbia University has a home-rolled, open-sourced system called Jake that worked for us. It involves dedicating a linux box (can be a cheap one) to each printing station; users then print a job and go to the station to verify that they really want to print it. It also has a quota system that can span multiple printing stations. The whole thing is a bit kludgy to set up but once it's working it's fairly reliable. You may have to bug somebody to get the latest source code; it's available but they don't really bother to package it for anyone.
A tutorial can be found at http://printing.kde.org/documentation/tutorials/qu otas.phtml.
I implemented this at our school. The basic problem is figuring out who owns a job - the LPR proto only gives you a hostname and username which can both be easily changed, and you very well can't do accounting based on IPs (must deal with DHCP, lab machines, etc). You have the same problem no matter what system you use to get print jobs, whether you use samba and netatalk as a front-end for lprng. The basic problem is that these protocols do not do authentication, and you do not want to use some "custom" protocol which supports authentication (such as lprng+kerberos) because you would have to maintain the client software for every OS that students might run (every version of windows, MacOS and windows).
What I finally came up with is that each printer gets a print spooler - when someone prints, they walk up to the print spooler (a very old lab machine, now running Linux), click on their job, type in a username/password and the job comes out of the printer. You'll want to use whatever username/password is most appropriate for your school (ie, don't make people learn a new password just to print, tap into your school's authentication system (NIS/ldap/kerberos) instead). For getting the pagecount, don't try to parse the PostScript/PCL that's sent to the print spooler - the pagecounts of both of those can be "fixed" by someone clever enough. Instead, query the printer for its hardware pagecount before and after the job prints. Also, you'll want to make sure the job's actually done printing before you ask the printer for the post-pagecount; you can just query the printer's status until the printer says it's idle. This is quite easy to do with PostScript, but I imagine it's also possible using PCL if you have crappy printers that don't do PostScript (any high-quality printer nowadays supports PostScript, or has a different model which supports PostScript).
I'm the developer of PaperCut , a Windows print charging system. I'm about 3/4 the way through developing a Samba/Linux version (done in my spare time). I'm aiming for an initial release in March. The applications has a number of components; a page count parser written in C, an application server and webadmin interface in Python, and it all sit's on PostgreSQL. It simply substitutes the lp command in smb.conf . I haven't yet decided on a licence however it'll most likely be GPL. Keep an eye on the website. Windows charging systems are quite expensive. This is due to the high development costs associated with maintaining compatibility with the every changing Win print drivers. You will however find that the systems will usually pay for themselves very quickly (amazing how much students will print if it's for free!). I'm hoping a community supported page count parser will ensure a viable Linux version. Chris
I think that's what we used. You'd have to talk to the person in charge of the lab (go to www.cec.wustl.edu/news) and click on that email link - she's an administrator (as in she shuffles paperwork), but she's in charge and can point you to who you need to talk to. I think we use lpquota (Wash U doesn't enforce the limits - see below) and we run it off UNIX, but that's as much as I know.
You also might want to be sure that this is a good idea, like I said, we run lpquota, but don't enforce it 'cause it's not worth the time to track down and add a $.50 charge to someone's transcript, have them raise hell 'cause they didn't know there was a printer limit, and then ultimately get someone to remove it. Not to mention then getting your ass chewed after this happens enough times.
If you actually want to affect the people who print out large numbers of pages, screen out any print jobs larger than 50 pages (not file size) - it's amazing how many people view something a few pagedowns into a really long (poorly segmented) webpage, and then click pring, expecting only that page to show up, and then not realize that it comes out as 104 pages take the 1 they want and throw the rest away (ignoring the bright blue recycle bin). If people complain to your lab admins or whoever, it's an excellent chance to teach them the wonders of how to choose exactly which pages (ie, pages 3-4) they actually want.
Kurdt
I'm not anti-social. Just pro-technology.
LPRng does a good job if your printer supports page counting. PPR looks like another nice system.
http://ppr.trincoll.edu/