5.7. Printing services

The GNU/Linux [Gt] [Smi02] printing server derives from UNIX's BSD variant; this system was called LPD (line printer daemon). This is a very powerful printing system, because it integrates the capacity to manage both local and network printers. And it provides this service within the system for both the client and the printing server.

LPD is a system that is quite old, as its origins date back to UNIX's BSD branch (mid 1980s). Consequently, LPD usually lacks support for modern devices, given that the system was not originally conceived for the type of printing that takes place now. The LPD system was not designed as a system based on device drivers, as it was typical to produce only printers in series or in parallel for writing text characters.

Currently, the LPD system combines with another common software, such as the Ghostscript system, which offers a postscript type output for a very wide range of printers for which it has the right drivers. At the same time, they are usually combined with filtering software, which, depending on the type of document that must be printed, selects the appropriate filters. Normally, the procedure that should be followed is (basically):

Example 5-7. Note

The UNIX systems provide, possibly, the most powerful and complex printing systems, which provide a lot of flexibility to printing environments.

1) The work is started by a command in the LPD system.

2) The filtering system identifies the type of job (or file) that must be used and transforms the job into an outgoing postscript file, which is the one sent to the printer. In GNU/Linux and UNIX, most of the applications assume that the job will be sent to a postscript printer and many of them directly generate a postscript output, which is why the following step needs to be taken.

3) The Ghostscript has to interpret the postscript file it receives, and, depending on the driver of the printer to which the file has been sent, it performs the transformation to the driver's own format. If the printer is a postscript type printer, the printing process is direct; if not, it has to "translate" the job. The job is sent to the printing queue.

Example 5-8. Web site

Ghostscript: http://www.ghostscript.com/

Apart from the LPD printing system (that originated with UNIX's BSD), there is also the system known as System V (originally in the other System V branch of UNIX). Normally, for compatibility reasons, most UNIX systems integrate both systems, so that either one or the other is used as the main one and the other emulates the main one. In the case of GNU/Linux, a similar process occurs, depending on the installation that we have, we can have only the LPD commands of the printing system, but it will also be common to have the System V commands. A simple way of identifying the two systems (BSD or System V) is using the main printing command (which sends the jobs to the system), in BSD, it is Ipr, and it is Ip in System V.

This is the initial situation for the GNU/Linux printing systems, although over the last few years, more systems have appeared, which provide more flexibility and make more drivers available for the printers. The two main systems are CUPS and, to a lesser extent, LPRng. In fact, recently, CUPS is GNU/Linux's de facto standard, although the other systems must be supported for compatibility with the existing UNIX systems.

Example 5-9. Web sites

LPRng: http://www.lprng.org

CUPS: http://www.cups.org

Both (both CUPS and LPRng) are a type of higher-level system, but they are not all that perceptibly different for average users, with regard to the standard BSD and System V systems; for example, the same client commands (or compatible commands in the options) are used for printing. There are perceptible differences for the administrator, because the configuration systems are different. In one way, we can consider LPRng and CUPS as new architectures for printing systems, which are compatible for users with regard to the old commands.

In the current GNU/Linux distributions, we can find different printing systems. If the distribution is old, it may only incorporate the BSD LPD system; in the current distributions: both Debian and Fedora/Red Hat use CUPS. In older versions of Red Hat, there was a tool, Print switch, which made it possible to change the system, switching the printing system, although recently only CUPS is available. In Debian, it is possible to install both systems, but they are mutually exclusive: only one may be used for printing.

In the case of Fedora Core, the default printing system is CUPS (as LPRng disappeared in Fedora Core 4), and the Print Switch tool no longer exists, as it is no longer necessary: system-config-printer is used to configure devices. By default, Debian uses BSD LPD, but it is common to install CUPS (and we can expect it to continue to be the default option in future new versions) and LPRng may also be used. In addition, we must remember that we also had the possibility (seen in the unit on migration) of interacting with Windows systems through the Samba protocols, which allowed you to share printers and access to these printers.

Regarding each of the [Gt] systems:

The two systems emulate the printing commands of System V.

For GNU/Linux printing, various aspects have to be taken into account:

Example 5-10. Web site

Information on the most appropriate printers and drivers can be found at: http://www.openprinting.org/printer_list.cgi

With regard to the client part of the system, the basic commands are the same for the different systems and these are the BSD system commands (each system supports emulation of these commands):

Example 5-11. Example

Lpr example:

   lpr –Pepson data.txt

This command sends the data.txt file to the print queue associated to a printer that we have defined as "epson".

Example 5-12. Example


This command shows us the jobs in the queue, with the respective order and sizes; the files may appear with different names, as this depends on whether we have sent them with Ipr or with another application that might change the names when it sends them or if any filters have had to be used when converting them.

Example 5-13. Example

   lprm -Pepson 15

Delete the job with id 15 from the queue.

With regard to the administrative side (in BSD), the main command would be lpc; this command can be used to activate or deactivate queues, move jobs in the queue order and activate or deactivate the printers (jobs may be received in the queues but they are not sent to the printers).

We should also point out that, in the case of System V, the printing commands are usually also available, normally simulated on the basis of the BSD commands. In the client's case, the commands are: lp, lpstat, cancel and, for administrative subjects, lpadmin, accept, reject, lpmove, enable, disable, lpshut.

In the following sections we will see that it is necessary to configure a printer server for the three main systems. These servers may be used both for local printing and for the network clients' prints (if they are enabled).

5.7.1. BSD LPD

In the case of the BSD LPD server, there are two main files that have to be examined: on the one hand, the definition of the printers in /etc/printcap and, on the other, the network access permissions in /etc/hosts.lpd.

With regard to the permissions, by default, BSD LPD only provides local access to the printer and, therefore, it has to be expressly enabled in /etc/hosts.lpd.

Example 5-14. Example

The file may be:

#file hosts.lpd second first.the.com +@groupnis -three.the.com

which would indicate that it is possible to print to a series of machines, listed either by their DNS name or by the IP address. Machine groups that belong to a NIS server (groupnis, as shown in the example) may be added or it is possible to deny access to several machines by indicating this with a dash (-).

With regard to the configuration of the server in /etc/printcap, we define inputs, in which each represents a printing system queue that can be used to stop the printing jobs. The queue may be associated to a local device or a remote server, whether this is a printer or another server.

The following options may exist in each port:

Let us examine an example:

# Local printer input 
lp|epson|Epson C62:\
 :if = /etc/magicfilter/StylusColor@720dpi-filter:\filter 
 :af = /var/log/lp-acct:lf = /var/log/lp-errs:
# Remote printer input 
hpremote|hpr|remote hp of the department|:\
 :lp = :\ 
 :rm = server:rp = queuehp:\ 
 :lf = /var/adm/lpd_rem_errs:\log file. 
 :sd = /var/spool/lpd/hpremote:local associated spool

5.7.2. LPRng

In the case of the LPRng system, as this was made to maintain BSD compatibility, and, among other improvements with regard to access, the system is compatible in terms of the configuration of queues and this is performed through the same file format, /etc/printcap, with some additional intrinsic operations.

Where the configuration is different is with regard to access: in this case, we generally obtain access through a /etc/lpd.perms file that is general for the whole system and there may also be individual configurations for each queue with the lpd.perms file placed in the directory corresponding to the queue, usually /var/spool/lpd/name-queue.

These lpd.perms files have a greater capacity for configuring the access and permit the following basic commands:

DEFAULT ACCEPT DEFAULT REJECT ACCEPT [ key = value[,value]* ]* REJECT [ key = value[,value]* ]*

where the first two allow us to establish the default value, of accepting everything or rejecting everything, and the next two of accepting or rejecting a specific configuration in the line. It is possible to accept (or reject) requests from a specific host, user or IP port. Likewise, it is possible to configure the type of service that will be provided to the element: X (may be connected), P (job printing), Q (examine queue with lpq), M (remove jobs from the queue, lprm), C (control printers, Ipc command lpc), among others, as with the file:


Deleting jobs from the queue is allowed for the (first) user of the machine and the root user from the server where the printing service is hosted (localhost) and, in addition, whatsoever other requests for deleting jobs from the queue that are not the already established are rejected.

With this configuration, we have to be very careful, because in some distributions, the LPRng services are open by default. The connection may be limited, for example, with:


Connection service only accessible to the server's local machine and denying access if the machine does not belong to our subnet (in this case, we are assuming that it is 100.200.0.x).

For the administration of line commands, the same tools as the standard BSD are used. With regard to the graphical administration of the system, we should point out the lprngtool tool (not available in all versions of the LPRng system).

There are various software packages related to LPRng; for example, in a Debian, we might find:

lprng - lpr/lpd printer spooling system lprng-doc - lpr/lpd printer spooling system (documentation) lprngtool - GUI front-end to LPRng based /etc/printcap printop - Graphical interface to the LPRng print system.

5.7.3. CUPS

CUPS is a new architecture for the printing system that is quite different; it has a layer of compatibility with BSD LPD, which means that it can interact with servers of this type. It also supports a new printing protocol called IPP (based on http), but it is only available when the client and the server are CUPS-type clients and servers. In addition, it uses a type of driver called PPD that identifies the printer's capacities; CUPS comes with some of these drivers and some manufacturers also offer them (HP and Epson).

CUPS has an administration system that is completely different, based on different files: /etc/cups/cupsd.conf centralises the configuration of the printing system, /etc/cups/printers.conf controls the definition of printers and /etc/cups/classes.conf the printer groups.

In /etc/cups/cupsd.conf, we can configure the system according to a series of file sections and the directives of the different actions. The file is quite big; we will mention some important directives:

We must point out that CUPS is, in principle, designed so that both clients and the server work under the same system; if the clients use LPD or LPRng, it is necessary to install a compatibility daemon called cups-lpd (normally in packages such as cupsys-bsd). In this case, CUPS accepts the jobs that come from an LPD or LPRng system, but it does not control the accesses (cupsd.conf only works for the CUPS system itself and therefore, it will be necessary to implement some strategy for controlling access, like a firewall, for example (see unit on security).

For administering from the commands line, CUPS is somewhat peculiar, in that it accepts both LPD and System V commands in the clients, and the administration is usually performed with the SystemV's lpadmin command. Where the graphic tools are concerned, we have the gnome-cups-manager, gtklp or the web interface which comes with the same CUPS system, accessible at http://localhost:631.

With regard to the software packages listed with CUPS, in Debian, we can find (among others):

cupsys - Common UNIX Printing System(tm) - server cupsys-bsd - Common UNIX Printing System(tm) - BSD commands cupsys-client - Common UNIX Printing System(tm) - client programs (SysV) cupsys-driver-gimpprint - Gimp-Print printer drivers for CUPS cupsys-pt - Tool for viewing/managing print jobs under CUPS cupsomatic-ppd - linuxprinting.org printer support - transition package foomatic-db - linuxprinting.org printer support - database foomatic-db-engine - linuxprinting.org printer support - programs foomatic-db-gimp-print - linuxprinting - db Gimp-Print printer drivers foomatic-db-hpijs - linuxprinting - db HPIJS printers foomatic-filters - linuxprinting.org printer support - filters foomatic-filters-ppds - linuxprinting - prebuilt PPD files foomatic-gui - GNOME interface for Foomatic printer filter system gimpprint-doc - Users' Guide for GIMP-Print and CUPS gimpprint-locals - Local data files for gimp-print gnome-cups-manager - CUPS printer admin tool for GNOME gtklp - Front-end for cups written in gtk