Hi Patrick

On Mon, 3 Jul 2000 [EMAIL PROTECTED] wrote:

> > Date: Wed, 28 Jun 2000 23:23:07 +0200 (CEST)
> > From: Jesper Dangaard Brouer <[EMAIL PROTECTED]>
> > To: [EMAIL PROTECTED]
> > Subject: LPRng: Accounting and file descriptor 3 
> >
> > I want file descriptor 3 back!!!
> >
> >
> > In the "old" versions of LPRng, file descriptor 3 was assigned to the name
> > of accounting file or server (server option :af=host%port).  
> > (Just as specified by the man page printcap(5))
> >
> > I'm using "af" as an server option (":af=host%port"), and setting the
> > "achk" option. This workes just fine. That is sending "as" string to
> > host%port, and returning "accept" og "hold".
> >
> > Now what does NOT work (anymore):
> >
> >  When I call my accounting.sh script from "ifhp", then file descriptor 3
> >  is no longer assigned to the "accounting file or server".
> >
> 
> I might add an option to do this,  say, 'open_accounting_port',  but
> it would not be provided by default.
> 
> I am a bit puzzled on this.  Right now you get the same effect for the :achk
> option,  which is called BEFORE any connections to the printer are opened.

The :achk option is working fine. It asks my quota-server (host%port) for
permission to print, gets back "accept" or "hold".
(my quota-server in.lpracctd is at locally developed program)

> So you are trying to connect to the accounting server using the
> 'ifhp' accounting script facility.  Why not just write the page
> count out to a file (where you have a permanent record) and don't
> depend on the network connection.

I'm running and providing, at realtime/online information of the
printer quota.  The users on my system, can checks their printer quota by
running "lpracct" (a locally developed program).  And the printersystem
LPRng (with option :achk specified) also need realtime/online information,
to be able to "accept" a users print request.
That is why i don't want to just write the page count out to a file.

> The problem is that when the connection to the accounting server
> is terminated,  this opens a lovely way to avoid the accounting
> procedures.
> 
> For example,  if a student^H^H^H^H^H^H user is on the same
> (non-switched) network as the accounting server or the print server,
> when the connection is opened the student^H^H^H^H^H^H user can use
> the 'Whack' DOS program to send a forged RST packet to either end
> of the connection.  The TCP/IP stack then closes the connection
> and the next read or write (at either end) will get an error.

I don't have the problem with forged packets. At the University we are
running a completly switched network. And more: all of our switches, is
running with mac/ethernet level port security, that is every port on the
switch only allows _one_ mac/ethernet address access. This way student
can't connect to the main network (They have a seperat network, which is
firewalled, where they are allowed to connect their laptop)

> The accounting script happily runs UNLESS you have taken extreme
> precautions to check for errors on reads and writes,  and you
> merrily proceed,  thinking that the accounting information has
> been updated.

I do know that my weekness is that I depend on the network connections.
But I really like having realtime/online information of the printer quota.


> OK,  so how can we fight this?  Well, you can't
> really.  But you can make a PERMANENT record of the information,
> and then connect to the server after the record has been made,
> and update the server QUICKLY by opening a new connection.  If the
> update to the server fails, you still have the accounting information.
> 
> You need to be able to deal with a terminated connection by
> having the accounting script reopen the connection if it has been
> closeed.
> 
> You should log the accounting information locally and THEN deal with
> updating the server,  and deal with reopening failed connections,
> read errors, write errors, etc by reopening and retrying.
> This connection open and retry should be done in the accounting
> script,  where it can hammer away several times,  rather than
> having a one-shot effort done by the LPD server.
> 
> See the latest version of the LPRng/UTILS/accounting.pl script for
> a script that handles the information in the accounting file.
> You can add your code to update and/or query the server pretty
> easily to it.

I have solved the problem! Still using a network quota-server.
I'm now using my own modified version of the accounting.pl script.

I now get the best of the two worlds (local file and network).

The accounting.pl script creates an local file, which it scans and
updates.  When it updates the file, all the nessary information is
available. At this point I simply send the information to my 
quota-server (in.lpracctd).

Now I both have the log created by accounting.pl, and the quota-server
information and log.

In accounting.pl, I'm doing the "accept" check manually (not using achk
any more).


My only problem with this solution, is that my "offline" consistent check
of the quota-server (in.lpracctd) log, does not work any more.  I used to
depend on the connection being kept open during the hole accounting fase.
Well the accounting.pl, does some consistent check on its own log file, so
this is not at serious a problem. 

Hilsen
  Jesper Brouer

-------------------------------------------------------------------
System Administrator
Dept. of Computer Science, University of Copenhagen
E-mail: [EMAIL PROTECTED], Direct Tel.: 353 21375
-------------------------------------------------------------------





-----------------------------------------------------------------------------
If you need help, send email to [EMAIL PROTECTED] (or lprng-requests
or lprng-digest-requests) with the word 'help' in the body.  For the impatient,
to subscribe to a list with name LIST,  send mail to [EMAIL PROTECTED]
with:                           | example:
subscribe LIST <mailaddr>       |  subscribe lprng-digest [EMAIL PROTECTED]
unsubscribe LIST <mailaddr>     |  unsubscribe lprng [EMAIL PROTECTED]

If you have major problems,  send email to [EMAIL PROTECTED] with the word
LPRNGLIST in the SUBJECT line.
-----------------------------------------------------------------------------

Reply via email to