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?"
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).
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
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.
I remember that one of the departments at my college bought some rather pricy windows software to implement quotas. We quickly figured out that if you printed a postscript document generated by a2ps it only counted as one page. Apparently the software must have assumed that people would only be printing poorly generated postscript documents. I don't believe they ever figured out where all the paper was going.
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.
A tutorial can be found at http://printing.kde.org/documentation/tutorials/qu otas.phtml.
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.