18.14 Page Accounting with CUPS

Often there are questions regarding print quotas where Samba users (that is, Windows clients) should not be able to print beyond a certain number of pages or data volume per day, week or month. This feature is dependent on the real print subsystem you're using. Samba's part is always to receive the job files from the clients (filtered or unfiltered ) and hand it over to this printing subsystem.

Of course one could hack things with one's own scripts. But then there is CUPS. CUPS supports quotas that can be based on the size of jobs or on the number of pages or both, and span any time period you want.

18.14.1 Setting Up Quotas

This is an example command of how root would set a print quota in CUPS, assuming an existing printer named " quotaprinter ":

 root# lpadmin -p quotaprinter -o job-quota-period=604800 \ -o job-k-limit=1024 -o job-page-limit=100 

This would limit every single user to print 100 pages or 1024 KB of data (whichever comes first) within the last 604,800 seconds ( = 1 week).

18.14.2 Correct and Incorrect Accounting

For CUPS to count correctly, the printfile needs to pass the CUPS pstops filter, otherwise it uses a dummy count of " one ". Some print files do not pass it (e.g., image files) but then those are mostly one- page jobs anyway. This also means that proprietary drivers for the target printer running on the client computers and CUPS/Samba, which then spool these files as " raw " (i.e., leaving them untouched, not filtering them), will be counted as one- pagers too!

You need to send PostScript from the clients (i.e., run a PostScript driver there) to have the chance to get accounting done. If the printer is a non-PostScript model, you need to let CUPS do the job to convert the file to a print-ready format for the target printer. This is currently working for about a thousand different printer models. Linuxprinting has a driver list. ^[51]

^[51] http://www.linuxprinting.org/printer_list.cgi

18.14.3 Adobe and CUPS PostScript Drivers for Windows Clients

Before CUPS 1.1.16, your only option was to use the Adobe PostScript Driver on the Windows clients. The output of this driver was not always passed through the pstops filter on the CUPS/Samba side, and therefore was not counted correctly (the reason is that it often, depending on the PPD being used, wrote a PJL-header in front of the real PostScript which caused CUPS to skip pstops and go directly to the pstoraster stage).

From CUPS 1.1.16 onward, you can use the CUPS PostScript Driver for Windows NT/200x/XP clients (which is tagged in the download area of http://www.cups.org/ as the cups-samba-1.1.16.tar.gz package). It does not work for Windows 9x/ME clients, but it guarantees :

• To not write a PJL-header.

• To still read and support all PJL-options named in the driver PPD with its own means.

• That the file will pass through the pstops filter on the CUPS/Samba server.

• To page-count correctly the print file.

You can read more about the setup of this combination in the man page for cupsaddsmb (which is only present with CUPS installed, and only current from CUPS 1.1.16).

18.14.4 The page_log File Syntax

These are the items CUPS logs in the page_log for every page of a job:

• Printer name

• User name

• Job ID

• Time of printing

• The page number

• The number of copies

• A billing information string (optional)

• The host that sent the job (included since version 1.1.19)

Here is an extract of my CUPS server's page_log file to illustrate the format and included items:

 tec_IS2027 kurt 401 [22/Apr/2003:10:28:43 +0100] 1 3 #marketing 10.160.50.13 tec_IS2027 kurt 401 [22/Apr/2003:10:28:43 +0100] 2 3 #marketing 10.160.50.13 tec_IS2027 kurt 401 [22/Apr/2003:10:28:43 +0100] 3 3 #marketing 10.160.50.13 tec_IS2027 kurt 401 [22/Apr/2003:10:28:43 +0100] 4 3 #marketing 10.160.50.13 Dig9110 boss 402 [22/Apr/2003:10:33:22 +0100] 1 440 finance-dep 10.160.51.33 

This was job ID 401 , printed on tec_IS2027 by user kurt , a 64-page job printed in three copies and billed to #marketing , sent from IP address 10.160.50.13 . The next job had ID 402 , was sent by user boss from IP address 10.160.51.33 , printed from one page 440 copies and is set to be billed to finance-dep .

18.14.5 Possible Shortcomings

What flaws or shortcomings are there with this quota system?

• The ones named above (wrongly logged job in case of printer hardware failure, and so on).

• In reality, CUPS counts the job pages that are being processed in software (that is, going through the RIP) rather than the physical sheets successfully leaving the printing device. Thus if there is a jam while printing the fifth sheet out of a thousand and the job is aborted by the printer, the page count will still show the figure of a thousand for that job.

• All quotas are the same for all users (no flexibility to give the boss a higher quota than the clerk) and no support for groups.

• No means to read out the current balance or the " used-up " number of current quota.

• A user having used up 99 sheets of a 100 quota will still be able to send and print a thousand sheet job.

• A user being denied a job because of a filled-up quota does not get a meaningful error message from CUPS other than " client-error-not-possible ".

18.14.6 Future Developments

This is the best system currently available, and there are huge improvements under development for CUPS 1.2:

• Page counting will go into the backends (these talk directly to the printer and will increase the count in sync with the actual printing process; thus, a jam at the fifth sheet will lead to a stop in the counting).

• Quotas will be handled more flexibly.

• Probably there will be support for users to inquire about their accounts in advance.

• Probably there will be support for some other tools around this topic.