There are two traditional clients that send data to a print server:
lpr This is the matching client for Berkeley LPD-based servers. Associated programs include lpq (to view the current printer job queue) and lprm (to remove a job from the queue).
lp Both CUPS and System V lpsched use the lp interface to print (CUPS also has limited lpr capability). The lpstat command shows printer jobs, and cancel removes a print job.
On traditional Linux systems, you send a PostScript job to the printer named printer with a command like this (you do not need -P printer if you want to send the job to the default printer):
lpr -P printer file
For CUPS, you may also use the lp program ( -d printer is optional if you are sending to the default printer):
lp -d printer file
Commands like lpr and lp let you send any PostScript file or data pipeline directly to a printer. However, one of the biggest problems with this model is that users have no idea that the print server expects PostScript (in fact, most users have no idea what PostScript is). In response, administrators change their print filters to automatically convert plain-text input files to PostScript so that users can use lpr to send either a PostScript or plain-text file to the printer without worrying about conversions.
Other operating systems don't usually let you get very close to the printer; instead, they make you print through an application that produces the correct output. Unix has these applications, too (such as gimp and its gimp-print counterpart ), but Unix also lets you get very close to the printer with lpr .
Users tend to want to print pictures and various other kinds of data. If you send a JPEG file or other file to a printer with lpr , it may do the right thing if the administrator set up the print filter to recognize and filter the file. More often than not, though, the print system either rejects the file or prints endless pages of junk, because the system tried to convert the binary file into PostScript using the text filter.
Therefore, it is extremely important that you know where the system converts your file into PostScript. This is not a problem if you primarily use graphical applications to print, because these programs normally generate PostScript and send the result to a command such as lpr . However, if you like to use the command line, you must be very careful about what you send to the printer.
CUPS is fairly smart about document conversions because it attempts to determine the MIME type of any input data before sending it to the printer. Furthermore, the system verifies that it can convert the data to something that the printer understands. If CUPS doesn't know how to convert the data, the CUPS server rejects the document rather than passing the printer data that it won't understand.
You should have an idea of how network printing clients send data to print servers:
Berkeley LPD clients send data to TCP port 515 on a print server.
CUPS uses the Internet Printing Protocol (IPP). IPP is a TCP protocol that looks like HTTP (Hypertext Transfer Protocol). The standard IPP port is 631, but CUPS also comes with a daemon that accepts the LPR protocol on port 515.
Most network-ready PostScript laser printers allow you to connect to TCP port 9100 and talk directly to the print engine. Most network-aware print filters use this port to send data.
Regardless of the protocol, you should be especially vigilant with respect to open network ports on print servers. Filter out or firewall any open ports. There have been serious vulnerabilities in print servers in the past, and you can expect that many more will crop up in the future, especially with a system as new as CUPS. This also holds true for network-aware printers. You do not want an intruder to waste the money that you spend on printer supplies .