1 / 24

Network printing in heterogenous environments

Network printing in heterogenous environments. Christoph Beyer christoph.beyer@desy.de Deutsches Elektronen Synchrotron, IT Notkestr. 85 22607 Hamburg, Germany. Printing at DESY . ~300 printer and ~400 queues 2 E250 running SOLARIS 2.7 with 1GB memory each as server

orli
Download Presentation

Network printing in heterogenous environments

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Network printing in heterogenous environments Christoph Beyer christoph.beyer@desy.de Deutsches Elektronen Synchrotron, IT Notkestr. 85 22607 Hamburg, Germany

  2. Printing at DESY • ~300 printer and ~400 queues • 2 E250 running SOLARIS 2.7 with 1GB memory each as server • ~250.000 jobs per month • No MAC and Novell support defacto • 2 administrators • LPRng 3.6.26 (slidely patched) and IFHP 3.4.4

  3. The perfect system • Printserver should understand every protocol the clients speak • Access to printers should be restricted, every job must go through the central spooler, this gives every job a fair chance to be printed • The system should be robust, in case of server failures jobs should be redirected to a working machine • Additional features like accounting, format conversion, loadbalancing and filtering should be possible • Administration and update of clients and servers should be as painless as possible

  4. The perfect architecture NET WARE UNIX MAC NETWARE SERVER WINDOWS NETWARE client SMB AppleTalk LPR LPR Central Printserver LPR TCP Remote printer HP jetdirect printer

  5. Solution (obvious) Take advantage of the flexibility of UNIX as a backend for queuing jobs and talking to the printer. Use software to present the UNIX queues to the clients using their native protocols. That's all !!!

  6. The Berkley printserver architecture (see RFC1179 for the 'nitty gritty details') Job file '/etc/printcap' Spooling client LPR Server LPD Printer (target) Mngmnt clients LPQ LPRM LPC Server LPD Pr2 Printer (target) Pr1 Datafile dfA001host '/etc/lpd.conf' '/etc/lpd.perms' /var/spool/lpd/pr1 Controlfile cfA001host (LPRng only) Started at boottime

  7. Controlfile content ASCII printable characters, line ending with \n Example: Hpcx1839.desy.de Host name Pchbeyer User name (banner) J(stdin) Job title CA Job class Lchbeyer User name (billing) fdfA458pcx1839.desy.de Data file N(stdin) Data file name UdfA458pcx1839.desy.de Unlink data file

  8. LPRng the next generation Berkeley spooler • An enhanced, extended and portable implementation of the Berkeley lpr print spooler functionality. • While providing the same interface and meeting RFC 1179 requirements, the implementation is completely independent • Compiles and runs on a wide variety of UNIX systems, and is compatible with other print spoolers • LPRng supports Kerberos 5 for authentication • Complexity comes with functionality

  9. Nice LPRng features • On UNIX clients the ':rm=<spoola>,<spoolb>:\' entry is a great built in failover feature • Stand alone printing using 'lpr -P<printer>@<host>' or eaven 'lpr -P<port>@<printer>' • Very nice 'lpc' features (is not mentioned in RFC1179): topq, hold, redirect queues, set status message, reread conf files, redirect jobs • Great debugging by simply typing 'lpq -L -P<printer>', different debugging levels in addition • 4 ascii files (printcap, lpd.conf, lpd.perms, ifhp.conf) make the only difference to any other workgroupserver in your network • Localy attached printers can be defined in a second printcap

  10. Nice LPRng features (ct'd) • Provides SysV and BSD binaries for all UNIX platforms • Is compatible to all known printing implementations eaven to those who violate the RFC1179 while being as close at the RFC1179 as possible • The permission file 'lpd.perms' allows different access to the functions of 'lpr', 'lpq', 'lprm', 'lpc' for classes of users • Global definitions in the 'lpd.conf' file greatly simplify management and printcap • Very good documentation for LPRng and IFHP • Good support on the mailing list • Accounting per page and printer

  11. What is a filter ? • Is typically run on the server to convert the data files into the printer specific language, to create bannerpages (bp) or to query the printer (of) • Is called by the lpd daemon, reads from <STDIN> writes to <STDOUT> • Is invoked by printcap entry: :if=<path to your filter>:\ for special formats, refering to the controlfile content: :<index>f:<path to your filter>:\ • In LPRng: :filter=<path to your filter>:\ generally defined for all formats

  12. The IFHP filter package • Enhanced, extended, highly configurable and portable implementation of a print filter for use with LPRng. • Supports network, serial and parallel printers • Page accounting and job recovery possible • Supports text, PostScript, PCL and PJL printer • Very strong file type detection due to the additional use of the file tool • Over 500 printer models types and configurations are supported • The config file makes configuration and implementation of new printers or features / formats extremely easy and flexible

  13. Connecting the printer (Possible network communication protocols) • RFC1179 BSD or TCP/IP supported by most if not all printers with TCP/IP interface, the only status information exchanged is success or failure of the transfer. Used typically for transport between client and spooler, default no filtering, transfered just like a set of files! • Socket protocol (TCP/IP) bidirectional connection to the internal printengine, error and status conditions are reported over the connection. PJL and PS status requests can be sent to the printer. Typical for connecting HP printers on port 9100. • Appsocket protocol (TCP/IP) two ports are used a TCP/IP listening port and a UDP query port. Typically used by Tectronics Phaser series and QMS printers.

  14. Printer specific languages • PostScript is a stack based programming language, developed mainly by ADOBE in the 70's - comes in different versions (level 1-3) - must be compiled/interpreted by the printengines, which always have bugs - requires a huge amount of memory on the printer, is very slow otherwise + everybody uses it because the code for the interpreter was sold by ADOBE for a very low price (higher now, so we see some interesting imitations) + very portable over different vendors printers and nearly generic + previewer can give you an exact idea of what your code will look like + standard and most portable way to generate documents for printing

  15. Printer specific languages (ct'd) • PrinterControlLanguage (PCL) developed by Hewlett Packard in the 80's it grew from a simple escape code control language to a fully developed PDL. - old printers do not have font download support - due to the heavy use of control characters (ESC) PCL files are not easy to edit or view - there is no real standard, the documentation is very poor + simple to generate + much faster because there is not much to do for the printengine

  16. What is PJL ? • PrinterJobLanguage (PJL) developed by Hewlett Packard to gain control over whole printjobs not just individual files in a print job. • Works as a wrapper for each job (if the printer supports it). The sequence 'ESC%-12345X' is heavily used by PJL. Whenever it appears the current language interpreter is interrupted and hands over control to PJL. • The most common use of PJL is for language switching at the beginning of a printjob. • There is a standard set of error messages provided by PJL as well, unfortunately not all printers support all PJL features and manufactures are very quiet about the sets of PJL messages their printers support.

  17. UNIX clients • To gain full functionality (job querying and removing) using LPRng on the server, LPRng must run on the clients as well! - You have to provide mechanisms for installation and compiled binaries + The architecture and behaviour is similar on all clients + Both BSD and SysV style binaries are available on all machines + Very good debugging (lot of built in functions) + Very easy and scalable update mechanism with 'checkpc' tool + Built in failover with ':rm=<spool1>,<spool2>:\' entry in printcap + Local attached printers can be supported without editing the distributed printcap + You get rid of complicated and stupid native implementations (e.g. Solaris)

  18. The native Windows printing architecture • Printserver installs minimal driver information on client ('add printer' button) • Client gets printerdefinition from server via RPC for each printjob (early binding) • Since NT 4.0 TCP/IP printing to UNIX server is possible if the LPR package is installed

  19. Windows integration methods • job forwarding from the NT spooler + automatic driver installation through NT spooler + printer information is held in one central place, changes take effect immediately (RPC) - no job control, because NT spooler doesn't forward querys • TCP/IP printing on the NT client + job control over the known NT GUIs (if you use LPRng for Windows) - need to be local administrator on client to 'add printer' - no automatic driver installation - once installed the driver never gets changed, big problems if printer hardware or tray specififcation changes etc.

  20. What about SAMBA ? • Extremely reliable and stable print and fileserver under UNIX for Windows clients, current release is 2.0.7 • Remote client driver installation is possible in the latest release, but it's kind of very tricky • You need to be local admin on the client to add a printer • RPC's are not supported, full driver installation on the clients • Print service is very stable and easy to administrate, job control and removement over the native Windows GUI's • RPC support and enhanced driver installation features are realised in the next release (2.2)

  21. Windows printing at DESY Desktop Driver installation, RPC support, printjob transfer via SMB Windows printserver LPR Lpq / lprm using GUI for LPRng for Windows Remote printer Central Printserver (UNIX) LPR TCP Remote printer

  22. DESY printing tool (screenshot)

  23. Strategies for large sites • Printer panels must be locked, host access lists and IP adress over bootp • Only a small number of printserver is running a lpd daemon, all clients send their jobs directly to them. Every printer should be known on every server (failover) • Use NIS / LDAP to distribute printcap or don't use a printcap at all but a default spooler (lpd.conf entry) • On UNIX clients the ':rm=<spoola>,<spoolb>:\' entry is a great built in failover feature, all other clients should print on a nameserver alias which can be changed in case of server downtimes • IFHP can be configured to send mails to operators on certain traps (for ex: paper out, toner low etc.)

  24. Some useful stuff • http://www.lprng.com For LPRng and IFHP • Patched 3.6.26 version: http://www.desy.de/dtg/printing/download.html • HPNP, a snmp tool to query and configure jetdirectinterfaces at: http://www.hp.com • NPADMIN, a very nice tool to query and administrate any kind of printer: http://npadmin.sourceforge.net/ • Adobe Systems Inc: Postscript Language tutorial and Cookbook Addison-wesley • Network Printing by T. Rademacher & M. Gast O'Reilly

More Related