For workstations it would make sense? to make lpr do formatting/filtering
instead of lpd. So there would be no need to run lpd on workstations.
Also using non setuid clients (lpr etc.) would be better from security
lprng can do this now - but lpr will never do filtering.
you don't need lpd running at all though.
just have a central print server on your network and you can have lpr funnel the
job to the central server and the central server does all the work.
having lpr do all the work is a "bad idea" b/c it means MUCH more work to do on
the client side - which could be a lot of systems.
Finally if you want to run the daemon but not be at risk use either 1. the
lpd.perms file to control who can get access to the daemon or 2. ipchains to
restrict the daemon to localhost-only access.
go to: http://www.astart.com/LPRng/LPRng.html
for more information about lprng.
Or, from the LPRng lpd manpage:
Normally job files are forwarded to a printer without
modification. The flag makes the queue a bounce queue and
allows banners to be generated and data files to passed
through the appropriate format filter. The entire output
of this process is then passed to the destination with the
format specified by the bq_format option (default l or
binary). See PRINTING OPERATIONS for details about
filters. For example, the following printcap entry will
filter format f files.
Anyway, I am not rewriting the spooler just to put filtering into the lpr client
(if you want prefiltering, you can use the filters and route their output into
lpr, even make a nice pretty script to do so.)
Instead of rewriting LPRng I was thinking about using
lpr_bounce for the filtering. A while back I tested this a little bit
but the result was that the redhat printfilters didn't work "out of the box"
(I think it was something with lpd/lpr used different parameters when calling
For users simple lpr command should be easier than piping the file thru gs with
quite a few commandline parameters.