October 25, 1995 TO: Common Solutions Group FROM: Mark LukerSUBJECT: Report on "Current Accounting Methods for Network Printing" This group has requested short reports on current methods for managing and billing for networked printing (e.g., in computing labs) from six universities. We now have full or partial reports from four, and names to contact at each place. We will prepare and distribute a more complete list in the near future as the final responses come in. Notes by campus: ______________________________________________________________ CORNELL Thomas B Hughes tbh1@cornell.edu 220 CCC / CIT Ithaca, NY 14853 607-255-8960 We are about to try a Mac-only pilot of a new system for recovering the costs of laser printing in our public labs. Currently we have free dot matrix printing and stand-alone laser printing stations that charge $.15/page via VendaCard technology. We have plans to implement the system on Windows but have nothing beyond a conceptual plan and where we might buy the LPD/LPR code. The new model will have the student authenticate themselves at the Mac using a Kerberos based technology developed here at Cornell called Sidecar. To precluse spoofing, the Mac has a small init that registers an AppleTalk <-> IP mapping with the Unix/CAP based spooler upon bootup. When the user prints for the first time, the spooler requests authentication from the Sidecar via IP after confirming the AppleTalk <-> IP mapping. This callback code is based on some elegant CAP modifications made by Steve Andrewartha of the University of Tasmania (based originally on a callback system created by Neil Chesire and others at Stanford for the Stanford Residence Halls). If the user is in the authorization table, the spooler accepts the job. At this time we are planning to use IP based security that we have worked out for HP 4si printers (we're working on others) to restrict use of the printer to jobs coming from the spooler. We will set the printer to only accept jobs via IP from the spooler address. Steve Andrewartha uses an AppleTalk based solution that discourages circumventing the spooler by changing the Chooser device type for the laser to something that cannot be typed. We opted to not use this because of concerns that a savvy student with an AppleTalk sniffer could figure out the device type and replace the Chooser. In either case, the spooler queries the printer for the current page count, sends the job (including a header page), and then queries the printer again for the page count to determine the actual number of pages printed. The need for the page count via IP is the reason we are currently restricted to the HP 4si printer. Steve Andrewartha's method allows a wider range of printer types including all Apple LaserWriters. The final step of the print process records the page count in a database against the user's name/NetID. Steve Andrewartha uses QI, I believe we are using a generic flat file table in Unix. Eventually we wish to automatically bill the student's Busar account once a month, but for the pilot we are likely to just have the lab operator take a check (no cash) and increase the student's print allocation (Stanford does this with no apparent problems). Management of print queues is being done via dynamically created Web pages. Users can see their own queue and can delete jobs or move them to another queue if they wish. Lab operators will be able to shut down and wake up printers (via the spooler) and also move all the jobs in a queue to a different printer in the same location (in the case of a dead printer). LaserWriter 8.3 software will give the users desktop drag and drop printing to the spooler. ______________________________________________________________ Harvard Frank Steen, Director FAS Computer Services fsteen@fas.harvard.edu Harvard University 617-495-1266 We have indeed implemented a grow-your-own print charging system. I am not completely satisfied with it, but it is working in most regards. Here are my bullets: How it works: *CAP running on an Ulrix box captures the HP laserjet printers on Ethernet (100% of our printers are HP's with JetDirect cards) and Intel Ethernet to serial boxes with one or two dot matrix printers attached. Macs print to CAP which passes print jobs through a program that deducts money from their printer budget. CAP prints to the printers as UNIX printers. *PCs attach to our huge Novell server running on a VMS machine (TGV software for Novell 3.12 emulation). Printers are selected from a menu. Print jobs go from the Novell server directly to VMS. VMS passes the print jobs on to the Ultrix box which runs them through the accounting software and then sends the job to the same UNIX printers as above. *Users add money to their print budgets by either putting paper money into a cash acceptor attached to a terminal or by giving our User Assistants a check. In either case the money is entered into the user's print account. All of the lines between the terminals and the Ulrix box are considered secure. Users verify their identity with their ID numbers. We have a provision for overdraft and we currently give users a $2.00 overdraft in case they are stuck without money and a paper due. All copies cost $.10 each. *We have 21 laser printers and 21 dot matrix printers connected to the system. around campus. Dot matrix printing is free. Any of the 5000 network connected computers we deal with can print to any of our 42 printers. Plusses: We get central control of printing. We eliminated pesky venda-cards. (We have lots of vendacard readers and a couple of card-cash machines for sale!) Minuses: a very complex system. There have been frequent problems. We now offer a printing guaranty. If there is some kind of problem we give users free laser printing (we open up laser printing). When there is a problem we have to deal with UNIX, VMS, AppleTalk, CAP, Novell.... One person alone cannot handle our printing problems. The biggest problems were with the dot matrix printers which finally work on Ethernet. The cash acceptor acts up often. I am not ready to recommend this system, although it has stablized somewhat. ______________________________________________________________ Michigan Christopher C Barbeau ccb@us.itd.umich.edu ITD University of Michigan 2234 Argus 313 764-7128 A complete description is available at http://stimpy.css.itd.umich.edu/~ccb/printing.html (See attached pages) ______________________________________________________________ MIT Greg Jackson e40-359a/MIT/Cambridge MA 02139 voice: (617) 253-3712 First of all, for small machines (Wintels and Macs) we don't have any network print accounting. Most of our network-accessible printers are either in private spaces (making it hard for outsiders to retrieve print jobs they send there) or public Athena printers with Mac and Windows access disabled. Athena printers are a different story. We deploy something like 60 of these campus-wide, currently all LaserJet IVsi's with extra memory and so forth. The TCP/IP side of these is configured only to accept print jobs from a limited set of machines, our print servers. On the workstation client side (we have about 1,000 UNIX client machines), we've modified the relevant printing commands so that they direct output to the print servers. The print servers only accept authenticated print jobs (that is, the request must come with valid Kerberos tickets), and they then keep track of who printed how many pages. This system is rather awkward, and since it requires too much hacking of standard services it's difficult to maintain and operate. Moreover, since we give each Athena user a free allowance of 1,000 pages per year, and virtually no one reaches that limit, the charging system is rather moot, and has fallen into some disrepair. In fact I'm not sure it's running now! Our key requirements are that any system (a) rely on our standard authentication schemes and (b) provide accounting without burdening operations or development. It would be nice if the services extended to lesser machines, especially Macs and Wintels. It would be even nicer if it were possible for someone easily to set up a "private" printer that was network-accessible but had a locally controlled authorization list. We've seen no commercial products that do all this. We have high hopes of the Cornell stuff... If you want more technical detail, I can point you at people who know it. ______________________________________________________________ Stanford Merriman, Jeffrey W birdland@Jessica Dir Of Res Computing 2nd Floor Wilbur Hal Stanford University (415) 723-4800 Dean Spearing (for technical details) All the information regarding our print accounting is available as links off of our home page, http://rescomp.stanford.edu/. (See attached pages) As told to Mark Luker by phone: Stanford serves some 5,000 undergraduates and 3,000 graduate students through a print accounting system that works as follows: Mac's and UNIX computers are supported now. Work is underway to support PC's. Thirty-five HP 4M+ printers are scattered through the campus. These IP ready printers are configured to accept printing from only five Sun Sparcstation computers that are used to spool print jobs. (The printers are invisible on the Macintosh chooser, but the spoolers appear as printers.) CAP is run on the spoolers to accepts Macintosh print requests. When a request is received, the spooler generates a request for authentication back to the user's Macintosh. A small Mac Init called the Mac Authenticator brings up a window that requests username and password, using Kerberos for secure communication with the spooler. The spooler then queries and updates a flat file containing accounting information for each student and sends the print job to the printer. Students deposit money in their accounts at this time by handing checks to the computer coordinators, who update the accounting file. This will shift to the debit card system when it is available. Students have access through web tools to the status, balance, etc., of their accounts. They system has worked for three years and is working well. The Mac Authenticator is the private property of a student there. Stanford is negotiating to purchase it. ______________________________________________________________ Yale Philip E Long philip.long@yale.edu Director, Academic Computing Services 175 Whitney Ave Yale University 203-432-6612 Our current operation is a manual card based charging system. We have one or more laser printers at 22 locations each controlled by a private, dedicated-to-laser-printing, debit card system. The cards themselves are inexpensive plastic with a mag stripe. End users buy the cards and add $$ to them at cash machines at the five major campus clusters or in the Master's Office in the residences. We manage printing by a single Novell server. All Macs, PCs and Unix machines connected to the campus network can print to a queue associated with each public cluster printer (this includes student room connected machines). We have a Novell queue manager machine next to each printer (a Mac Plus). The student prints to the queue which will hold the print for 24 hours. The student then physically goes to the printer, inserts her "print debit card" in the associated card reader and releases her particular print job to that printer. Problems issues with this system include: * card reader costs: at $300+, the card readers add substantially to the cost of printers * cash machine costs: at $1,500, these are very expensive and, for reliability, we have multiple machines at most sites to increase the probability that one will be working at 3:00 am * printer reliability: we have tended to under invest in printers; these get tremendous business, so industrial strength is definitely required * reliability: students and cards are only 80% successful. Many students get confused and make mistakes which cost them $$ or require a refund; also, the machines themselves are finnicy and jam much more frequently than I think ought to happen. Repair of a machine required sending it back to the factory with a 2-3 week turnaround, so this fall we sent one of our technicians to the factory to be trained. * even with charging, there are huge costs to supporting printing: answering user questions, providing paper and toner, especially making it available to our student employees without making it available for theft; and servicing the equipment. We have a student visit every cluster once a day (attended clusters are, of course, continuously monitored). We also have a staff member who visits every other day to check for problems, swap broken equipment, etc. A printer down w/no back-up in a cluster is a "crisis" activity for us. Considering our large investment, we provide only an OK service. The staff member mentioned above is new this year, so I hope it will become a good service this year, but I doubt that we'll ever achieve excellence with this technology. I look forward to the reports from the other schools as this is an area we are very interested in improving and/or controlling/lowering costs (!). -- Mark Luker, CIO, University of Wisconsin-Madison mluker@DoIT.wisc.edu Div of Info Technology, 1210 W Dayton St, Madison, WI 53706 608-262-8874
webmaster at stonesoup fullstop org
Updated 16 July 2008