jeff@eniac.seas.upenn.edu (Jeffrey M White) (04/25/89)
In order to simplify our connections, and to have a better integration
of Mac's and PC's, we have recently switched almost all our LaserWriters
from direct serial connections to Appletalk, using the CAP papif program
in place of Adobe's pscomm. I have also gotten lwsrv to work, so that our
Unix hosts can publish their spooled printers as LaserWriters for Mac's and
PC's on the Appletalk.
Right now, the Mac to LW printing situation is a strange one. There is
one cluster of about 20 Mac's that are on a local Appletalk with a LaserWriter.
However, they have to pay $0.50/page to print on it. They can print for no
charge on the LaserWriters connected to our unix machines, but they must
first generate the PostScript file on the Mac and then download and print it,
not what I would call user friendly). What people here seem to be afraid of
is that people will print out unlimited copies with no control, or people from
the rest of the university will do all their printing here.
What I had in mind, as a compomise, was to make the only LaserWriters on
the Appletalk network the ones published by lwsrv, so that some accounting
can still be done. Lwsrv returns the Mac chooser name as the user, not the
unix login name, so I have modified the lwsrv program to allow a Mac Chooser
to unix login name mapping. My plan is that anyone wishing to print directly
from the Mac must come to the office and tell us: 1. their unix account name,
and 2. what name they plan to use for the Chooser Name. Then, when a print
job comes in over lwsrv, it sees if that Chooser name is in the file, and if
so, allows the job to go through (also doing a setuid to that user, so that
the accounting information is recorded properly). It's not perfect (as there
is no absolute security on the Chooser Name), but it does give us a way to trace
usage.
Enough of the background information. What I need to do is to somehow allow
papif to communicate with a LaserWriter over Appletalk, but make sure that a
Mac on the same network cannot see it. The easiest way of doing this I thought
was to change the type of the LaserWriter, that is, make it type 'Laser' (or
whatever) instead of 'LaserWriter'. Papif would be modified to allow it
talk to a device type Laser instead of LaserWriter.
What I need to know is:
1. Will this work?
2. If so, has anybody does it? What is the command/sequence to change
the type of the LW? There is Postscript parameter called 'product'
which is supposed to return the type of the printer, but I'm not that
familiar with Postscript to know if it is what I want and even how to
write a script to change it if it was.
Any help or advice would be greatly appreciated.
Jeff White
University of Pennsylvania
jeff@eniac.seas.upenn.eduRSILVERMAN@EAGLE.WESLEYAN.EDU (Richard Silverman) (04/26/89)
Jeff,
Your idea will work just fine; it's exactly what a spooler does when
it takes over a printer. To change the printer's NBP name, use the following:
serverdict begin 0 exitserver % assuming your printer password is 0
statusdict begin
(PrinterName:PrinterType@*) setprintername % PrinterType could be 'Laser'
The 'product' string is just the name of the printer type, e.g.
'LaserWriter II NT'; just for identification purposes.
Richard Silverman
arpa: rsilverman@eagle.wesleyan.edu Computing Center
bitnet: rsilverman@wesleyan Wesleyan University
CIS: [72727,453] Middletown, CT 06457inei@cs.glasgow.ac.UK (Nick Nei) (04/28/89)
Jeff White writes: > "... afraid people will print out unlimited copies with no control, > [on LaserWriter] or people from the rest of the university will > do all their printing here. We have the same problem here at Glasgow University. This is what I have done: * Rename the LaserWriter to "LazerWriter^A" (i.e. "z" instead of an "s" and embedd one/more control characters. This make the device invisible from the Macintosh Chooser. * Run lwsrv. The name it uses is visible from the Macintosh Chooser. The mapping between LaserWriter to "LazerWriter^A" in the cap.printers file is like so: lwf173=F173.LocalTalk:LazerWriter^A@* * Users from Macintosh MUST specify the following in their Chooser name: user-name:password The user-name is the UNIX login name and the password is anything they like. * lwsrv picks up the user-name:password pair in the job and verifies the user and his/her quota. The quota is whatever the System Manager likes: no quota, periodic quota, one-off quota, etc. * lwsrv uses /etc/passwd.laser which has user-name, password, real-name, group-name, real-name fields separated by colons. * papif prints the file and figures out number of pages. It updates /usr/spool/pages.laser. This file has user-name and pages-used field. * Before papif prints, it will check user-name, password and quota by reading /etc/passwd.laser and /usr/spool/pages.laser. If validation fails, it will print a diagnostic page on the LaserWriter saying: "wrong password", "wrong user-name" or "quota-exceeded". If the latter then, the user is charged for the diagnostic page. * Any lpr jobs from UNIX will similarly be charged. Since you have to be logged in, the user is already validated. The printing is done by papif and the quota will be updated. I have augmented lwsrv and papif code to perform the above. The system has worked very well for 9 months. (I know by the bribes I get from students and the complaints from total strangers that they can't use the LaserWriters!) If nothing, I hope at least the control system has saved a small forest somewhere. The main security risk I anticipated was the LaserWriter renaming part. Some clever hacker will be able to write an application to print to the hidden LaserWriter. If that happens, the log file will suddenly detect unaccounted pages and I will be alerted. Then what I will have to do is to remove the LaserWriter from LocalTalk and connect it serially to a UNIX machine and use something like Adobe's pscomm. Somehow is is very gratifying not to see our LaserWriters churning out multiple copies of party invitations, CVs, recipes and other Universities' theses. Mail: Nick Nei, Computing Science Dept., Glasgow Univ., 17 Lilybank Gardens, Glasgow G12 8QQ, UK. Tel: (041) 339 8855 x 5457 ARPA: inei%cs.glasgow.ac.uk@nsfnet-relay.ac.uk USENET: inei@cs.glasgow.uucp
neff@hpvcfs1.HP.COM (Dave Neff) (04/29/89)
I was playing with this ability to change the LaserWriter type and a couple of questions come to mind: If a spooler has changed the type of the LaserWriter and then your Mac is powered off/crashes the LaserWriter will have remembered this new type. In fact, the type is stored in non-volatile memory so even power cycling the LaserWriter will not revert back to the original name. Hence you can no longer choose the LaserWriter and subsequent use of the spooler would seem to also be confused. What is the workaround for this? Removing the battery in the LaserWriter? Why is the LaserWriter type "remembered" when power is turned off to the printer? Is this really necessary or is this just a side effect of the battery backed up RAM in the LaserWriter? This seems like a dubious "feature" or am I missing something? How are people "poking" out postscript commands to the LaserWriter? I changed the type using "Janus" (posted a few days ago) but then Janus wouldn't let me change the type back since it was assuming the type was LaserWriter! I did get the name back to LaserWriter using a program we have on an IBM PC that dumps any file to any AppleTalk printer but I couldn't do it on the Mac (ResEdit would not let me change the string in Janus for some reason). I assume I could have disconnected the battery in the LaserWriter but I fixed it before I got that desparate. Dave Neff hplabs!hpvcfs1!neff
RSILVERMAN@EAGLE.WESLEYAN.EDU (Richard Silverman) (04/30/89)
Dave Neff (hp-pcd!hpvcfs1!neff@hplabs.hp.COM) writes: >> Why is the LaserWriter type "remembered" when power is turned off to >> the printer? Is this really necessary or is this just a side effect >> of the battery backed up RAM in the LaserWriter? This seems like a >> dubious "feature" or am I missing something? Dave, Well, I suppose one could argue the point, but it never seemed strange to me. After all, just because the most common use of a LaserWriter involves having its NBP type be "LaserWriter" doesn't mean it always will; why force someone who wants to use it differently to have to reset the name every time the printer is restarted? If the printer is usually under the control of a spooler, it may as well have its name "permanently" set to the alternate type the spooler expects. >> How are people "poking" out postscript commands to the LaserWriter? The simplest thing to do is to change the LaserWriter communication protocol to serial and plug a terminal into the serial port (make sure you disconnect the AppleTalk cable first, though!). Then type in 'executive' (it will not be echoed) to start up the interactive mode line editor in the interpreter. If this is a pain because of logistics, then you need something that will communicate via the AppleTalk protocol PAP (Printer Access Protocol). The simplest thing in this category is to get a copy of Adobe's public-domain program SendPS, which allows you to download a file to a LaserWriter (and also get a font list and restart the printer). You write your programs in a text file, download them, and see the results in a log file SendPS creates. Not great, but it works. If you're doing a lot of work, you might want to look into products like Emerald City's LaserTalk, which gives you an interactive programming/debugging environment for the LaserWriter over AppleTalk (plus extras like online descriptions of PostScript operators excerpted from the red book, etc.) A note: I have written my own implementation of the PAP protocol from the specs in Inside AppleTalk. There is an implementation in the LaserWriter driver, of course (the famous PDEF 10), but Apple considers the interface unsupported so as to allow for "future protocol enhancements" (or so I have been told by Developer Technical Support). With this, I have developed an application like LaserTalk that I use for programming and managing our LaserWriters over AppleTalk. It also has other nice features like allowing you to do network name lookups and initiate a connection to any device, by NBP name or network address. This obviates silly difficulties of not being able to get to a device just because you've changed the name. I am hoping to polish it up and place it in the public domain this summer (if I get time). Richard Silverman arpa: rsilverman@eagle.wesleyan.edu Computing Center bitnet: rsilverman@wesleyan Wesleyan University CIS: [72727,453] Middletown, CT 06457