1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
|
Patrick Powell
Mon Sep 4 18:04:01 PDT 1995
Updated Mon Mar 18 08:52:13 PST 1996
In Academic institutions, avoiding printing accounting has been
regarded as a challenge, an ongoing game of fat cat and poor starving
mouse, between the Adminstration and the downtrodden, poor, overcharged
student. The following is a lighthearted ramble down the dark lane of
printing accounting.
We will disregard the fact that if most students put as much effort
into their studies as in finding ways to avoid accounting procedures
then they would be Rhodes Scholar material, but I digress...
The accounting procedures put into the LPRng and the hpif filters may
appear to be extraordinarily complex, but believe me, they are not.
Firstly, we make the assumption that the printer has some sort of
non-volatile page counter mechanism that is reliable and impervious to
power on/off cycles. Without this mechanism the enterprising student
ummm... user will simply turn off the printer. Software that prescans
jobs for line counts and pages is notoriously unreliable, given even
the most modest efforts of users to hide these procedures. The cost
of running a PostScript simulator simply to do accounting has its
flaws; without ensuring that the simulator has all of the interesting
security loopholes closed, such as opening files, etc., it can become
a trap door to hell for the system administrator.
Secondly, we must make the assumption that the student... uhhh...
user will not be able to tinker with the page counter mechanism, i.e.-
they will not be able to roll back the odometer on the printer, FOR THE
DURATION OF A SINGLE JOB. I will digress and point out that a student
actually did this for a challenge; it only took him a couple of weeks
of study and a fully equipped micrcontroller lab, and two (2) laser
printers which he ruined in the experiment. HP was not amused when we
sent them back under warranty, claiming that this our 'normal lab usage.'
Lastly, you should not mind a small amount of pilferage, or a few
pages here and there being charged to the wrong account.
The basic mechanism the CTI/LPRng filter uses is to record the page
counter value at the start and end of each part of a print job. Each
record has the form:
start -qpagecounter -Ff -kjob -uuser -hhost -R...
end -ppages -qpagecounter -Ff -kjob -uuser -hhost -R...
When we use the OF filter and/or banners, we will see the
individual jobs bracketed by the OF filter records:
start -q100 -Fo -kcfA100taco -uuser -hhost -R...
start -q101 -Ff -kcfA100taco -uuser -hhost -R...
end -p1 -q102 -Ff -kcfA100taco -uuser -hhost -R...
start -q102 -Ff -kcfA100taco -uuser -hhost -R...
end -p3 -q105 -Ff -kcfA100taco -uuser -hhost -R...
end -p5 -q105 -Fo -kcfA100taco -uuser -hhost -R...
It should be clear from the above that all we need to do is to add up
the values for the -Fo (OF) filter lines and we are done.
Unfortunately, this is too simplistic. If for some reason the job is
killed or terminates due to error conditions, the OF filter may not
get to finish its work. Thus, we may see the following:
start -q100 -Fo -kcfA100taco -uuser -hhost -R...
start -q101 -Ff -kcfA100taco -uuser -hhost -R...
start -q110 -Fo -kcfA101taco -uuser -hhost -R...
This is a clear indication that the user's job has been terminated. In
this case we need to use the differences between pagecounters of the start
records to do accounting.
There is a caveat to all of this; that is the problem of the last dead
job in the list. If the last line in the accounting file is:
start -q110 -Fo -kcfA101taco -uuser -hhost -R...
is the last job finished or did it abort?
YOU USED 2000 PAGES, WHO DO WE BILL?
Now we move on to the problem of real time accounting. Due to limited
budgets, etc., many institutions would like to strictly enforce limits
on paper use by students. As jobs are printed their accounts should be
docked for the amount of paper use. One way to do this is to have an
external accounting procedure update a shared database. The CTI filter
has provision for a shell script to be called at the end of print job;
this is done by both the OF and IF filter. Thus, we can blithely
assume that there is a central database carefully getting updates
from the LPRng software, proably from dozens of different printers,
and updating the accounting information.
The first question to be asked is simple: is this worth it?
Perhaps doing accounting as a batch job once an hour/four times
a day/once a day is cheaper than buiding an running such a database.
If it costs $5K/year for the database software, you might just consider
ignorng the 10,000 pages that get lost in the shuffle and use
a simple set of awk/sed/perl scripts to update a database once
an hour.
BAD JOBS - Who Do We Bill?
We inevitably run into an interesting question:
what happens if a job does not complete correctly?
If you use the completion of the OF filter as a success status, I have
to point out that many students... ummm... users soon find ways to send
jobs to the printer that will cause it to lock up after their output
has been printed. These jobs require power cycling of the printer and
restarting the filter; a bit extreme, perhaps, but it has happened.
I suggest that you simply adopt a 'bill to last user of record'
attitude, using the pagecount information as follows:
start OF -- starting point for THIS job
start IF -- nice information, but not useful
start IF --
end OF -- ending point for this job - can record infomaiton
start OF --
if no end OF for previous job, then treat as end OF and
update accounting.
Now somebody is sure to complain that they got charged for a bunch of
pages that they did not use. This is inevitable; always carry a
can of oil for the squeaky wheels. I might make the observation that
once is accident, twice is coincidence, but three times is malice;
be wary of the constant complainer and check out not only him but
also his co-workers.
HOW DO WE UPDATE THE DATABASE
I suggest that database update be done as follows:
You maintain a 'last page reported' counter for each printer in the
database. When a successful job reports in, check to see that old
pagecount + joblength == newpagecount;
if this is not the case, then you have had a some unsuccessful jobs.
In this case I strongly recommend that you have a means to request the
accounting reporting program to go back through the accounting file and
find the last report for the page counter value and try to backtrack
through the accounting files. The accounting file is one of the first
things to be attacked by students... Ummm... users. It should NOT be
kept on and NFS exported or mounted file system. It should be
carefully pruned and copied, perhaps on an hourly basis.
Now some adminstrators have fallen in love with network based printers;
do not believe ANYTHING that comes over a network connection without
some form of authentication; PGP has some very nice Public Key
mechansims for handling this. This is a major weakness in using a
database for keeping track of accounting - a weak authentication
mechanism may lead to denial of service attacks by students flooding
the database with bogus print usage reports; suddenly NOBODY can print
and the adminstrator is driven to turning off accounting.
Good luck. I am never suprised when I encounter yet another wrinkle in
this area.
Patrick ("You call me a Bean Counter? Guido, break this kids fingers
with an adding machine!") Powell
------- Addendum
The hpif filters now have the capability of invoking a shell script
to do accounting - seek the accounting.sh script in the distribution.
In addition, you can specify your own script using the
-Taccounting=scriptpath option.
|
