lpd is the "line printer daemon", one of the most venerable of all network services. It allows print jobs to be communicated over the network from workstations to printers. It is among the more elderly of network protocols, and its age shows its weaknesses in terms of contemporary security practices. Nevertheless it gets the job done, and its usage is still commonplace on many Linux and BSD systems today.

We use the LPRng version of lpd, or "next generation" lpr, in place of the standard lpd delivered with most distributions. LPRng is a little more secure and flexible than the system it replaces. For more information specifically on the installation and configuration of LPRng, see these resources:

http://www.lprng.com/

The main website for LPRng, with complete documentation

http://www.oreilly.com/catalog/netprint/chapter/ch05.html

From the book "Network Printing" by Todd Radermacher and Matthew Gast (O'Reilly, 2000), chapter five covers the usage of LPRng in some detail.

As a daemontools service, lpd is one of those servers we can't do a whole lot with. It does it's own listening for connections, and, regretably, listens on all interfaces of the host. And it logs with syslog. So two of the main tools of the djb way suite --tcpserver and multilog-- are lost on lpd.

Nevertheless, we still run lpd under daemontools for these benefits:

• consistent, reliable, platform-independent startup and monitoring
• easy signaling and process control

Start with the usual local service directories for the lpd service:

# mkdir -p /var/svc.d/lpd/log

Then a run script for /var/svc.d/lpd/run:

#!/bin/sh
# lpd/run
# daemontools run script for lpd daemon
# LPRng version
# ===
exec 2>&1

echo "*** Starting lpd service (LPRng)..."
exec \
    /usr/local/sbin/lpd -F

### that's all, folks!

Make executable, chmod 755. The path shown here is as found with LPRng installed on BSD systems; adjust to suit your own platform. The -F option is the crucial foreground flag, necessary for lpd to run under supervise.

We would also like to use the -L flag, to log output to stderr with /dev/stderr. Unfortunately, this did not work on our system. lpd complains about a "bad descriptor" and fails to run.

We setup the usual multilog anyway, force of habit, even though its usefulness with lpd is truncated:

#!/bin/sh
# lpd/log/run
exec setuidgid multilog multilog t /var/multilog/lpd

### that's all, folks!

Make executable, chmod 755. Prepare the log directory in /var/multilog:

# mkdir -p /var/multilog/lpd
# chown multilog /var/multilog/lpd

Link into /service:

# ln -s /var/svc.d/lpd /service/lpd

In addition to the usual /etc/printcap, the LPRng system may be further configured with etc/lpd.conf and etc/lpd.perms. The latter gives some degree of security/access control to the service, under pain of YACFF (yet another configuration file format).

A SIGHUP signal can be used to tell a running lpd service to re-read its configuration and initialization files:

# svc -h /service/lpd

That's about it for lpd. On the whole, it is not a very satisfying service under daemontools. And it makes one wonder, WWBD? (What would Bernstein do?) We imagine the Bernstein lpd would be qmail-like:

• spool jobs in a secure queue area
• privelege separation
• run under tcpserver
• log to stderr
• simple, no-parse control files (or cdb's)
• etc.

More likely though, djb would never mess with lpd, since the protocol (RFC 1179) is so in need of overhaul. Instead, he would develop something sensible from the ground up, like QNPP, the "quick network printing protocol".