PyKota's internals
Last modified on $Date$
To account for pages or eventually ink usage
PyKota doesn't currently account for ink usage, it only accounts
pages. To account for ink usage, you should use PrintBill instead.
, you must plug your accounting
system somewhere into the printing system you use, be it either CUPS
or LPRng. One way to do this without having
to modify the printing system itself, is by using a filter.
A filter is a computer program which takes data in one format as its input, and outputs the
same data but transformed into another format. CUPS already
contains many filters. For example there's one filter named pstops which accepts
PostScript data as its input, and, as its name implies, outputs PostScript data too, but after having
eventually rearranged the pages to fit several pages on a single sheet of paper, or other manipulations
like that.
The pstops filter described above is also in charge of doing basic page
accounting, but PyKota currently doesn't use this facility since it may
prove to be unreliable depending on the drivers used or if a paper jam occurs for example.
LPRng can also use filters, one often used in combination with
LPRng is magicfilter which can convert
different input formats to native printers languages like PostScript or ESC/P2.
So to do its own accounting, PyKota has its own filter, named pykota,
which you have to plug into the different set of filters used by your printing system of choice. The procedure to
install the pykota filter is described in the
chapter.
Currently with a CUPS backend, the pykota filter is
deprecated. You have to use the cupspykota CUPS backend instead.
This CUPS backend ensures that jobs can't bypass the filtering mechanism, so you can use
any printer with any driver and any command line option, and you can be sure that your
print job will be correctly accounted for.
When used with an LPRng backend, the accounting filter is not defined the same way
input filters are, so the problem described above doesn't exist, and PyKota
may work with non-postscript printers, provided they can report their page counter and you know how to retrieve
it.
When you submit a print job, cupspykota (with CUPS) or pykota (with LPRng) is automatically launched by your printing system,
so it has to detect which system you are using (CUPS or LPRng)
and behave like if it was specifically designed for your printing system. Fortunately there's not a lot
of differences, the more important one is the exit codes used to tell the printing environment if a job
has to be accepted or rejected.
When using the querying accounting method,
pykota asks the printer for its internal page counter, reads from the Quota DataBase the internal
page counter for this printer when the previous job was launched, computes the difference, and report it as the
previous job's size in the Quota DataBase. It then updates the last user's print quota and account balance, and
warn him if he is over quota or if his account balance is below 0. Finally it checks if the user who launched the
current job is below or above his print quota, and either allows or denies the job's datas to pass to the underlying
layer (the printer itself). The cupspykota CUPS backend on the other hand,
asks the printer for its internal page counter at the start and at the end of the print job, and
computes the values' difference so accounting is done immediately. This way it doesn't let open a window for abuse in the case
several printers are managed. That's why the use of cupspykota
instead of pykota is recommanded with CUPS.
When using the external accounting method,
and if the user is still allowed to print,
the command you specified is launched with the job's data on its
standard input. Your command must print the job's size in number of
pages on a single line on its standard output. This number is then
read by PyKota and used to update the current user's quota information.
Of course checks are also done like with the querying
accounting method, to see if the current job is allowed to be printed or not.
If a problem occurs, it is logged either to the filter's standard output or to the system logger, depending on
your preferences in PyKota's configuration files. Also if a print quota is reached
you may choose if the administrator, the user, both or no-one will receive an email message explaining
the situation and proposing a solution.