File: README.accounting

package info (click to toggle)
cti-ifhp 2.2.8-1
  • links: PTS
  • area: main
  • in suites: slink
  • size: 904 kB
  • ctags: 673
  • sloc: ansic: 4,916; sh: 1,539; makefile: 287; perl: 99
file content (284 lines) | stat: -rw-r--r-- 11,756 bytes parent folder | download
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
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
Patrick Powell
Mon Sep  4 18:04:01 PDT 1995
Updated Mon Mar 18 08:52:13 PST 1996
Updated Tue Oct  7 18:20:37 PDT 1997

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.

> From essa@cs.sc.edu Tue Oct  7 13:48:42 1997
> From: Ossama Ahmed Essa <essa@cs.sc.edu>
> Subject: [LPRng] Accounting Question
> To: plp@iona.com
> Date: Tue, 7 Oct 1997 11:36:04 -0400 (EDT)
>
>
>   I inherited segments of partially working code for managing the printer
> quotas. The quota manager program consists of the following parts:
>
> - QMS: a Quota database Manager Server. This server checks and updates the
>   quota db. The reason a server is needed is because we have 5 printers around
>   an we need to keep track of all the printers at the same time.
>
> - Check: This is called by LPRng (the "as:" option in lpd_printcap). This filter
>   has two main tasks: contact QMS for availability of quota for a user, and
>   getting the current page count from the printer. 
>
> - Update: Called by LPRng (the ae: option). Gets the page count from the printer
>   and sends a request to QMS to update the users quotas.
>
> QMS is basically called twice for each print job by a user, first to check 
> whether the user exceeded his/her quota. The second call for QMS is to update
> the users quota record.
>
> As I mentioned at the beginning, I didn't write the code for that stuff. I am
> basically linking pieces of code together. 
>
>   Here's my problem, my apologies if it seems trivial, getting the page count
> from the printer.

Right.  This is a NASTY problem.  Briefly,  the only assured
way to do this is to have the filters get the page count.
If you have a PostScript filter,  the psfilter distributed with
LPRng will actually send a small PostScript job to the printer
which will get the (physical) page counter.  After this has been
done, the psfilter will write the page counts to a log file,
OR you can have it invoke a shell script with -pstartpagecount -bpages
as options.  (OR you can have it send this information to a logger
process, but this is HORRIBLE to make work correctly)

1. Create the following 'shim' program:

/usr/local/lib/filters/accnt_shim

#!/bin/sh
# This is the accounting shim called by the psfilter at the
# start and end of a job.  It is initially called with the
# -ppagecounter start option and then at the end
# -ppagecounter -busedpages end
#  Example:
#  ACCNT -q27678 -Ppsfilter -p41893 -tOct  7 17:15:00
#  ACCNT -b1 -q27678 -Ppsfilter -p41893 -tOct  7 17:15:30

#D echo ACCNT ARGS "$@" 1>&2
#D _n=1;
while [ "$#" -gt 0 ]; do
	#D echo ARG "$1" 1>&2;
	case "$1" in
		-* )
			_v=`expr "$1" : '-\(.\).*'`;
			_w=`expr "$1" : '-.\(.*\)'`;
			eval $_v=\""$_w"\";
			#D echo "ACCNT $_n: '$_v' '$_w' '$1'" 1>&2;
			#D _n=`expr $_n + 1`;
		;;
	esac;
	shift;
done;
# at this point you will have the various variables set to
# the desired values
if [ -z "$b" ]; then
	# you can echo to error log file
	echo ACCNT START $p 1>&2;
	# here you can exec the test script
	# return JREMOVE status to remove job
	# if /usr/whatever ; then
         ###### you can call your accounting program here
	# 	exit 34; # JREMOVE status
	# fi;
else
	# you can echo to error log file
	echo ACCNT END $p PAGES $b 1>&2;
	# here you can exec the test script
         ###### you can call your accounting program here
fi;
exit 0;


2. Now, in the printcap for the printer use:

   #postscript printer
   pr:
    :of=/usr/local/lib/psof -Taccounting=/usr/local/lib/shim
    :if=/usr/local/lib/psif

3. By uncommenting the stuff in the shim script,  you can trace
   what is happening.

NOTE:

   The psfilter is responsible for reporting usage.  If you
   do NOT let it report at the end,  then you will find that
   users do not get their jobs accounted for correctly.
   The LPRM and 'fatal job' will cause this to happen;  a bad
   PCL and/or PostScript job will cause the job to be aborted
   and the psof filter will not run to completion.

To make this work correctly,  you need to have your accounting
program record the sequence of usage of the printer and any
"gaps" need to be accomodated.

Patrick Powell