Print server refers to a complete, dedicated printing host with the required CPU power, memory, and hard disk space.

There is an important distinction to be made between a network printer or a print server box on the one hand and a true print server on the other. As a somewhat special case, there are large printer devices that have a complete print server included with them to make them network-capable. These are treated like print servers because clients will talk to the printer only through the server and not directly.

An LPD server is a print server that is addressed with the LPD protocol. This is the case if the print server runs the LPRng and lpdfilter print system (lpd, to be precise) or the CUPS print system configured in a way that the machine can be addressed with the LPD protocol (cups-lpd, to be precise).

An IPP server or CUPS server is a print server that is addressed with the IPP protocol. This is the case if the print server runs the CUPS print system (cupsd, to be precise).

The term CUPS network server refers to a CUPS server that was specifically configured to share its queues with other network hosts via UDP broadcast (via UDP port 631).

no filtering (as this is usually done on the CUPS network server)

no filtering (as this is usually done on the LPD network server)

Filtering

Several workstations, one print server, and one or more print server boxes or network printers:

The easiest and most suitable configuration is shown in Figure 5.3. “Configuration 1”.

Figure 5.3. Configuration 1

[D]

For every queue with filtering on the print server, a queue without filtering can be configured on every workstation. Thus, the print jobs can be buffered in the workstation in the event of a temporary print server failure or overload. In this way, printouts can always be generated on the workstations without having to wait until the print server is available. The disadvantage of this approach is that all queues have to be configured on all workstations (though without filtering) and certain modifications of the queues on the print server (such as renaming, addition, or deletion of queues) require an adaption of the configurations on all workstations. Changes in the filtering process do not require any adaption.

This rather sophisticated configuration is shown in Figure 5.4. “Configuration 2”.

Figure 5.4. Configuration 2

[D]

Theoretically, the filtering process could take place on the individual workstations. In this case, the only function of the print server would be the transmission of the printer-specific data to the print server boxes or network printers. However, this would degrade the print server to an oversized print server box, which is usually not very practical, unless the print server's performance is not sufficient for filtering. The disadvantage of this approach is that all queues must be configured on all workstations (with filtering) and all changes would require the adaption of the configurations on all workstations. Figure 5.5. “Configuration 3” shows this configuration.

Figure 5.5. Configuration 3

[D]

A few workstations, no print server, and one or several print server boxes or network printers:

The only possible configuration is to have a queue with filtering for each printer on every workstation. The disadvantage of this approach is that all queues must be configured on all workstations (with filtering) and all changes would require the adaption of the configurations on all workstations. Figure 5.6. “Configuration 4” shows this configuration.

Figure 5.6. Configuration 4

[D]

If you consider the above cases in reverse order, see the development from the configuration on a stand-alone system with a locally connected printer to a high-level configuration for several workstations with a print server for several print server boxes or network printers.

Figure 5.7. Configuration 5

[D]

The previous constellations looks almost the same as the configuration for a stand-alone system with a locally connected printer. Figure 5.7. “Configuration 5” shows the configuration for a stand-alone system.

First, make sure everything is in order with the TCP/IP network in general, including name resolution.

Connect the printer to the first parallel port of your computer. To test the connection, initially set it up as a local printer to exclude any network-related problems. If the printer works locally, you have found the correct Ghostscript driver and other configuration options.

The following command tests whether lpd can be reached via TCP on port 515 of host:

netcat -z <host> 515 && echo ok || echo failed
       

If lpd cannot be reached in this way, it is either not running at all or there is some basic network problem.

This way you can get a (possibly very long) status report about the queue on the host, if lpd is running and the host is reachable. As root, enter the following command:

echo -e "\004<queue>" \
  | netcat -w 2 -p 722 <host> 515
        

If lpd does not respond, it is either inactive or there are basic network problems. If lpd responds, the response should indicate why queue on host cannot be used for printing. Examples:

lpd: your host does not have line printer access
lpd: queue does not exist
printer: spooling disabled
printer: printing disabled
         

If you receive such a response from the lpd, the problem is caused by the remote lpd.

By default, a CUPS network server broadcasts its queue every thirty seconds via the UDP port 631. Thus, the following command can be used to test if a CUPS network server exists in the network:

netcat -u -l -p 631 & PID=$! ; sleep 40 ; kill $PID
       

By default, CUPS network servers broadcasts its queues via port 631 at thirty-second intervals. After waiting for forty seconds, the output should appear as follows if a broadcasting CUPS network server exists:

... ipp://<host>.<domain>:631/printers/<queue>
         

The following command tests whether cupsd can be reached via TCP on port 631 of host:

netcat -z <host> 631 && echo ok || echo failed
        

If cupsd cannot be reached in this way, it is either not running at all or there is some basic network problem.

lpstat -h <host> -l -t
       

With this command, get a (possibly very long) status report about all queues on host, provided cupsd is running and the host is reachable.

echo -en "\r" \
| lp -d <queue> -h <host>
       

This command sends a print job consisting of a single carriage return character to test if the queue on host accepts any print jobs. This test command should not print out anything or only cause the printer to eject an empty page.

To test the basic operability of an SMB server, enter:

echo -en "\r" \
| smbclient '/<HOST>/<SHARE>' '<PASSWORD>' \
-c 'print -' -N -U '<USER>' \
 && echo ok || echo failed
        

For HOST, enter the host name of the Samba server. For SHARE, enter the name of the remote queue (i.e., the name of the Samba share). For PASSWORD, enter the password string. Replace USER with the user name. This test command should not print out anything or only cause the printer to eject an empty page.

The following command displays any shares on the host that are currently available. Details on this can be obtained from the manual page of smbclient.

smbclient -N -L <host>
       

Spoolers on print server boxes often become unreliable when having to deal with relatively high printing volumes. As the cause of this lies with the server-side spooler, there is mostly no way to fix this. As a workaround, however, circumvent the spooler on the print server box by using TCP sockets to directly stream data to the printer connected to the host.

This turns the print server box into a mere data converter between the two different data streams (TCP/IP network and local printer line), which effectively makes the printer behave like a local printer although it is connected to the print server box. Without the spooler acting as an intermediary, this method also gives much more direct control over the printer device in general. To use this method, you need to know the corresponding TCP port on the print server box. If the printer is switched on and properly connected, you should be able to determine the TCP port a minute or so after booting the print server box with the program nmap. Running nmapIP-address on the print server box may return an output similar to this:

Port       State       Service
23/tcp     open        telnet
80/tcp     open        http
515/tcp    open        printer
631/tcp    open        cups
9100/tcp   open        jetdirect
       

This output means:

By default, nmap only probes a number of common ports, as listed in /usr/share/nmap/nmap-services. To have all ports probed, use the command nmap -p from_port-to_port IP-address — which, however, might take quite some time. To learn more about this, have a look at the manual page with man nmap.

With a command like:

echo -en "\rHello\r\f" | netcat -w 1 <IP-address> <port>
cat <filename> | netcat -w 1 <IP-address> <port>
        

send entire strings or files straight to a given port, which is helpful when testing whether a printer can be addressed through that port.