DCS Office Documentation Project. First in a series of articles to assist anyone dealing with DCS office staff. This series will be posted at http://www.cs.toronto.edu/~lloyd/howtoDCS Topic One -- Printing The DCS Office staff print through several different mechanisms; * SIS (ROSI) * AMS (FIS/HRIS) * DCS/CSLab Windows clients I'm going to deal with them in order of increasing complexity. 1. Student Information Systems (SIS) SIS maintains the Repository of Student Information (ROSI), which runs on mvsb.utcc.utoronto.ca, an AIX box. Users connect to it with a TN3270 emulator. Print queues are defined on ROSI and print via the remote host emma.utcc.utoronto.ca. From emma the job is sent by lpr to any accessible printer. Currently defined queues are CNS Our Print Server Queue AMS ROSI --- ---------------------- ----------- --- ------------- cs1 granite.cs.utoronto.ca lw3301d cs1 cs2 granite.cs.utoronto.ca lw-ba5246 cs2 cs3 granite.cs.utoronto.ca lw3302 cs3 CPSCFP04 R532 cs4 granite.cs.utoronto.ca lw3303b cs4 cs5 granite.cs.utoronto.ca lw283 cs5 cs6 granite.cs.utoronto.ca clw3303 cs6 cs7 granite.cs.utoronto.ca lw-theory cs7 cs8 granite.cs.utoronto.ca lw3302f cs8 cs9 lpd.cs.utoronto.ca lw3304 GRADFP19 R232**** csa lpd.cs.utoronto.ca lw-ba4242-s CPSCFP01 R302 csb lpd.cs.utoronto.ca lw-3304 CPSCFP02 R303 csc granite.cs.utoronto.ca clw290a csc csd granite.cs.utoronto.ca lw-ba5244 csd cse lpd.cs.utoronto.ca lw-ba4236 CPSCFP05 R546 csf granite.cs.utoronto.ca lw-ba4254 CPSCFP06 R549 csg lpd.cs.utoronto.ca theory CPSCFP03 R510 csh granite.cs.utoronto.ca lw3210 csh csi lpd.cs.utoronto.ca lw-vc csi New printers are defined at http://www.utoronto.ca/wts/printing/ Reconfiguation requests are made by email to wts.help@utoronto.ca The principle correspondent is Steve Jones. ROSI will only print to a postscript printer. -- Update: this is possibly untrue. It is probably best to purchase postscript devices whenever possible, but documentation suggests printing to PCL devices should be possible. Currently untested. (05-03-16 lloyd) 2. Administrative Management System AMS runs two subsystems: the Financial Information System (FIS) and the Human Resources Information System (HRIS). Both run on poort.utcc.utoronto.ca, using the same software (SAP and Oracle). AMS print jobs are also forwarded to emma.utcc then sent by lpr. The same printer request form as ROSI is used to set up a new printer. It is possible to request the same printer under both systems, but each system (AMS and ROSI) use different queue names. *HOWEVER* there is a major difference when it comes to CSLab. Jobs sent from mvsb.utcc through emma.utcc to lpd.cs succeed. Jobs sent from poort.utcc through emma to lpd.cs fail silently. Jobs sent from poort through emma to granite.cs succeed. When AMS was initially established on campus, the ip address of each client machine had to be registered with AMS, as part of their security model. (Update: apparently it was a licensing issue, not security). The 128.100.112 subnet was established jointly with Engineering to have all administrative machines, and only admin machines, on the same subnet. With this background, the observed behaviour was attributed to a security measure. Finance documents in postscript could be sniffed and compromised, so they were restricted to "trusted" subnets. (granite is on 112). This assumption was wrong. Later the restriction on AMS client machines was lifted and any oncampus machine could be used, but attempts to establish queues directly to lpd.cs still failed. Samir looked into it and discovered the lpd software used at CSLab compares the hostname in the control and data files for the print job. Jobs from mvsb have the same value. Jobs from poort have "localhost" in one, and the actual hostname in the other. granite.cs (a Windows NT server) accepts the job, then prints through lpr to lpd.cs, evidently synchronizing the hostnames in the process. Unless the software at CSLab is adjusted, it seems a Windows machine will be needed to reflect the print jobs for AMS. Perhaps lprng or cups will solve this. AMS name queue CS2 128.100.112.230:lw-ba5246 CS3 ? 128.100.112.230:lw3302 CS4 128.100.112.230:lw3303b CSD 128.100.112.230:lw-ba5244 ? 128.100.112.230:lw3301d ? 128.100.112.230:lw3302f ? 128.100.112.230:lw283 Printers are set up from the URL in the SIS section above. 3. Printing from Windows clients At the time of writing, DCS staff on Windows machines print through one of four mechanisms: * Windows native printing on granite.cs * lpr printing to lpd.cs * Windows native printing on smb.cs * locally attached printer 3.1 Printing through granite Almost all DCS users have accounts on both CSLab and the DCS_OFFICE domain controller, granite.cs. Print queues are established on granite printing to lpd.cs whenever possible, or printing to the printer directly if there is not a queue for it under CSLab. The Add Printer wizard allows normal user accounts to install drivers for a new printer. Print jobs are spooled to granite and sent under their username to lpd. Users can add or delete printers from their individual list of known printers and since the list roams, the same selection is available on any machine they log in on. Since the job is not resident on granite, users must ssh into cslab and use the queue management tools (lpq, lprm). 3.2 Printing through lpr Recent new DCS machines have been laptops, so printing has been set up using lpr, to enable users to print to CSLab printers from alternate locations (eg. home). see http://www.cs.toronto.edu/~lloyd/howtoDCS/office/lpr/ The printer can only be added from an administrator account, and subtle errors result if the printer driver is not correct, especially with colour printers. Different Windows lpr clients have been used, with slightly different characteristics. Queue management tools are not always available. This is not a preferred method for general office printing, only in cases where printing is required from other networks. 3.3 Printing through smb.cs Most recently the issue of users without accounts on granite has come up, accelerating the need to establish seamless end user printing though smb.cs. Currently smb.cs advertises known printers, but does not export drivers for them. (This is the default behaviour for samba). If a user account attempts to add a new printer they get the message "You are not authorized to ...". If an adminstrator account is used the message is "A suitable null driver was not found." The administrator account can install the correct drivers (if available) and the printer can then be used by regular user accounts on that system. Given the numbers of printers on CSLab and of DCS machines, this is not a scalable solution. Samba provides for the same Add Printer functionality as from a Windows server. A special share (printers$) is set up containing the correct driver files (copied from a Windows machine) and a definition file is created mapping printer models to the correct files. When printing through smb in this fashion, users can use Windows native queue managment tools to query the queue and remove their own jobs. Currently only cinnabar.cs (in SF 3202e) and jade.cs (in PT 283 are set up using smb printing, since Mary Jane and Elaine do not have a accounts on granite. 3.4 Directly attached Printers are directly attached to computers if there are compelling reasons, chiefly because they are not postscript devices. The computer can share the printer through Windows native mechanisms, or by running a lpd service (available from the Hummingbird package available from SIS). It is possible to run Ghostview as a print spooler and use a PCL printer as PostScript. Appendix DCS Printers in use, and troubleshooting There are four printers connected through external Jet Direct 170X boxes. These boxes are susceptible to occasional hangs. The device needs to be unplugged and (almost always) the queue restarted on jane. * lw3301d (in SF 3302F) * lw3302f (in SF 3302E) * lw3303b (in SF 3303B) * lw3304 (in SF 3304) There is a photocopier in SF 3304 that is connected by parallel cable to rhyolite.cs, which shares it under the name "PowWow", for use by the other Grad office staff. It's possible that someone has to be logged in on rhyolite for sharing to work. (Was the case for WinNT, untested under 2K). There is a photocopier in SF 3302 (mailroom) with ip 128.100.112.225. It speaks postscript and listens on port 9100. It also sends mail through mail.cs to transmit scanned documents. There is a photocopier in BA 4254 that uses the ip 128.100.108.198 It accepts jobs from granite, as it appear that it only accepts lpr jobs, not jobs on port 9100 (JetAdmin port). It might accept jobs on another port, I haven't checked yet. There is an inkjet in BA 4237 (Luna's office) connected by USB, not shared. Luna order the ink cartridges. When it breaks the printer is tossed and a new one bought (they're ~$80).