Subject: Re: Does Netatalk allow printer accounting ...
From: Stefan Bethke (stefan@promo.de)
Date: Mon Jun 23 1997 - 12:56:02 EDT
netatalk 1.4b2 (or any early version) can neither do print job accounting
nor file copy protection.
At 17:44 Uhr +0200 23.06.1997, Edan Idzerda wrote:
>Mario Klebsch DG1AM allegedly said...
>> >
>> > - to be able to do per-user printer accounting,
>>
>> Since the netatalk afp server runs as a UNIX process under the
>> identity of the user, it should work (without any configuration) if
>
>Well, since apfd doesn't do printing, that's not necessarily true, is
>it? I haven't seen anything in the papd documentation describing
>how you can get the username from the connecting Mac. Of course,
>the whole 'pr=|lpr' wasn't in the docs, either.
Print job accounting is not easy to achieve. Although the Printer Access
Protocol contains provisions for a "password", neither LaserWriter 7.x nor
8.x make any use of, nor do they provide any user authentication data.
Two workarounds are possible:
- use the Owners Name (as set in the Sharing Setup control panel), which is
included as the ADSC comment %%For: to authenticate the user. This requires
that users have set this name correctly; it is quite easy to circumvent
this mechanism if you are to use the accounting data for billing or other
"real" accounting.
- require the user to be logged in to the file server on the same machine,
then matching the AppleTalk address of the job's sender to aquire
authentication data from the afpd process. This would require that afpd
would write something equivalent to stmp and wtmp; a good idea anyway.
>
>
>> > - to be able to do licence metering (on applications),
>> > (CAPS appears to be able to do this. That is, to have
>> > applications installed on the server, but limited in usage by
>>netatalk
>> > according to how many licences I tell it we have for each
>>application.)
>>
>> I don't know, hos this can be done. The users always can copy the
>> files on their local disk and after cpying them, they are not busy
>> anymore, on the server.
>
>I don't know exactly how it works, either, but I know it can be done.
>I can't remember if CAP denied people from copying the application
>or if we used different software for that function. (MacPrefect comes
>to mind.) So if you keep people from copying the application,
>then it can be done, eh?
>From Inside AppleTalk, 2nd., pp. 13-20:
"The Macintosh Finder will not copy a file whose CopyProtect bit is set. An
attempt to copy the file using the FPCopyFile command will result in an
error."
However, the Finder will allow launching if the file is an application
(APPL or appe). Actually, the Finder only inhibits copying the file;
openening it always OK. And if you have some other utility, say DiskTop,
you can copy the app regardless.
What would have to be implemented in afpd would be
- setting the CopyProtect bit for a file;
- managing a counter which counts the number of times the file is currently
open, and a mechanism to store the maximum allowed for that file (so you
can launch the app only so often).
Regards,
Stefan
-- Stefan Bethke Promo Datentechnik | Tel. +49-40-851744-0 + Systemberatung GmbH | Fax. +49-40-851744-44 Eduardstrasse 46-48 | e-mail: stefan@Promo.DE D-20257 Hamburg | http://www.Promo.DE/
This archive was generated by hypermail 2b28 : Sat Dec 18 1999 - 16:25:08 EST