Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
Linux Software

Printer Quotas in Linux? 27

Posted by Cliff from the toner-doesn't-grown-on-trees-ya-know dept.
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?"
This discussion has been archived. No new comments can be posted.

Printer Quotas in Linux? More

Printer Quotas in Linux?

Comments Filter:
  • Some of the kids in the CS dept used to print out entire MUDs, just to try to learn more about how they worked (and how to get the advantage, presumably).

    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 (Score:3, Informative)

    by elvisior ( 230844 ) on Saturday January 26, 2002 @10:03AM (#2906105) Homepage Journal
    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).
    • 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.
  • 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
    • PostScript is a programming language. The 'showpage' could be embedded in a loop, or more likely in a function that the software inserts at the end of a page. A 200 page file might only have one showpage.

      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.
      • In addition, running it through a PostScript interpreter won't work. Consider the following code which prints a "random" number of pages between one and ten:

        statusdict begin pagecount
        10 mod {showpage} 1 add repeat

        In addition, I believe it would be possible to write a PostScript program that could figure out if it's running under an interpreter and behave accordingly (requires some research).

        So, if you have any PostScript hackers, your best bet is to rely on a hardware page count. If you don't have any hackers, on the other hand, you can simply count the "%%Pages:" DSC comment that PostScript-generating programs put in :)
        • Of course, I got the program wrong (I was messing with the interpreter as I was writing it, wasn't too careful).

          Instead of:

          10 mod {showpage} 1 add repeat

          It should be:

          10 mod 1 add {showpage} repeat

          PostScript is a beatiful language :)
          • hehe nice one. The top hack would be to fiddle your 200-page postscript document to spot if it was being run by ghostscript and only print one page, yet when being run by a genuine Adobe interpreter on a PS printer to print the full 200 pages, yet only be billed for the one page counted by the gs thing!

            My problem with hardware page counters is how to determine when to query the printer. Surely the printer will cache up as much of the print job as it can and as soon as it has then the spooler will think its done, and if you get a pagecount then the printer wont have done all the pages.

            I really think there has to be some way of the printer saying 'I've just finished job XXX, and I printed YYY pages' in order to do it reliably.

            Baz
    • 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.
    • Hehe. Can you say "halting problem"?

  • CUPS (Score:3, Informative)

    by Fellgus ( 16870 ) on Saturday January 26, 2002 @12:16PM (#2906484) Homepage
    CUPS (Common Unix Printing System) [cups.org] 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 :)
  • 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.
  • 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.
  • Check out Printbill [freshmeat.net]. 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.
  • I actually wrote my own stuff for this while I was working at a Uni. Quotas were held in a PostgreSQL database (which means you don't have to worry about file locks etc) and I used ghostscript to do page counts of everything which was printed (there's some stuff on this on the web; basically you add a few lines of postscript to the end of the job which prints out the number of pages in the PS/PCL doc). Text documents were kludged to be #pages=lines/80 (or something)

    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...

  • See http://printing.kde.org for a tutorial (Score:3, Informative)

    by chowells ( 166602 ) on Saturday January 26, 2002 @08:45PM (#2907931) Homepage
    A tutorial can be found at http://printing.kde.org/documentation/tutorials/qu otas.phtml [kde.org].

  • PaperCut for linux (Score:2, Interesting)

    by cdance ( 516169 )
    I'm the developer of PaperCut [papercut.biz] , 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

  • Washington Univesity (Score:3, Interesting)

    by KurdtX ( 207196 ) on Monday January 28, 2002 @11:59AM (#2913767)
    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 [wustl.edu]) 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.
  • LPRng does a good job if your printer supports page counting. PPR looks like another nice system.

    http://ppr.trincoll.edu/

Slashdot Top Deals

Our business is run on trust. We trust you will pay in advance.

Close