Linux Today: Linux News On Internet Time.

Grant Taylor: Open Letter to Linux Vendors, Developers and Admins: Line Printer Daemon Must Die!

Nov 01, 2000, 18:05 (17 Talkback[s])
(Other stories by Grant Taylor)

[ Thanks to Kurt Pfeifle for this link. ]

Grant Taylor, long standing author of the Linux Printing HOWTO and now creator and maintainer of the www.linuxprinting.org-Website (which by the way includes a database for print devices and approriate drivers) has issued an Open Letter to Linux vendors, developers and administrators calling for: "LPD Must Die!"
This is what he has to say:

LPD has a number of problems:

  • A new security flaw is discovered way too often for a critical system daemon that's been around for over a decade.
  • It is a support nightmare; there are more flavors of LPD out there than I can count, and more vendor-specific hacks and configuration tools than anyone could possible support.
  • As if to add insult to injury, it's gratuitously devoid of actual features.
Unfortunately, there are no perfect alternatives to LPD. An ideal replacement would:
  • Be secure, both by design and in implementation.
  • Offer lightweight and efficient IPP and LPD (the protocol) service.
  • Offer a simple and extensible interface for filters, drivers, accounting, queue management, etc.
  • Support a selection of clients; ideally with a client library offering job operations and printer status and capability information.
The three current alternatives are LPRng, CUPS, and PDQ. LPRng and CUPS are the primary competitors; both offer IPP and LPD protocol service, a structured and extensible filter and driverinterface, accounting features, and queue management. Both are not well tested on the security front; CUPS is brand new with a limitedsecurity design, and LPRng, while designed for security, is rumored tosuffer from spaghetti code and a lack of external maintainers. CUPS offers the best client functionality of the two; LPRng offers little client support beyond the traditional lpr client. PDQ offers excellent client and filtering facilities, but lacks management and queueing features. These can be added by bolting PDQ onto another spooler; PDQ plus LPD is actually not a bad combination.


I ask vendors to commit to offering a viable alternative to LPD ASAP (actually, some already do). For now, this will mean shipping one or more of the imperfect alternatives described above. Hopefully the wider exposure given to the spoolers from this first step will help boost the development efforts needed to adapt or create a complete good system. Only at that point may we sensibly discontinue shipping LPD. Similarly, I ask vendors to join in an open discussion around configuration and management issues. There are many (6-12, at least!) ongoing configration-related projects; it would be nice if we could cut this number down a bit (ideally to one!). Finally, if you are a Linux distributor; please either participate in the open discussion or email me to keep in touch. It's very important that we reach a consensus about what a good system is and what the parts are so that we can have a bit of standardization across distributions. The current state of affairs is dreadful.


Let's discuss how best to go about this in the general forum here on LinuxPrinting.org. (If traffic warrants I'll create a dedicated forum.)

Related Stories: