18.3 Advanced Configuration

Before we delve into all the configuration options, let us clarify a few points. Network printing needs to be organized and setup correctly . This frequently doesn't happen. Legacy systems or small business LAN environments often lack design and good housekeeping.

18.3.1 Central Spooling vs. " Peer-to-Peer " Printing

Many small office or home networks, as well as badly organized larger environments, allow each client a direct access to available network printers. This is generally a bad idea. It often blocks one client's access to the printer when another client's job is printing. It might freeze the first client's application while it is waiting to get rid of the job. Also, there are frequent complaints about various jobs being printed with their pages mixed with each other. A better concept is the usage of a print server: it routes all jobs through one central system, which responds immediately, takes jobs from multiple concurrent clients at the same time, and in turn transfers them to the printer(s) in the correct order.

18.3.2 Raw Print Serving ” Vendor Drivers on Windows Clients

Most traditionally configured UNIX print servers acting on behalf of Samba's Windows clients represented a really simple setup. Their only task was to manage the " raw " spooling of all jobs handed to them by Samba. This approach meant that the Windows clients were expected to prepare the print job file that its ready to be sent to the printing device. Here is a native (vendor-supplied) Windows printer driver for the target device needed to be installed on each and every client.

It is possible to configure CUPS, Samba and your Windows clients in the same traditional and simple way. When CUPS printers are configured for RAW print-through mode operation, it is the responsibility of the Samba client to fully render the print job (file). The file must be sent in a format that is suitable for direct delivery to the printer. Clients need to run the vendor-provided drivers to do this. In this case, CUPS will not do any print file format conversion work.

18.3.3 Installation of Windows Client Drivers

The printer drivers on the Windows clients may be installed in two functionally different ways:

• Manually install the drivers locally on each client, one by one; this yields the old LanMan style printing and uses a \\sambaserver\printershare type of connection.

• Deposit and prepare the drivers (for later download) on the print server (Samba); this enables the clients to use " Point'n'Print " to get drivers semi-automatically installed the first time they access the printer; with this method NT/200x/XP clients use the SPOOLSS/MS-RPC type printing calls.

The second method is recommended for use over the first.

18.3.4 Explicitly Enable " raw " Printing for application/octet-stream

If you use the first option (drivers are installed on the client side), there is one setting to take care of: CUPS needs to be told that it should allow " raw " printing of deliberate (binary) file formats. The CUPS files that need to be correctly set for RAW mode printers to work are:

• /etc/cups/mime.types

• /etc/cups/mime.convs

Both contain entries (at the end of the respective files) which must be uncommented to allow RAW mode operation. In /etc/cups/mime.types , make sure this line is present:

 application/octet-stream 

In /etc/cups/mime.convs , have this line:

 application/octet-stream application/vnd.cups-raw 0 - 

If these two files are not set up correctly for raw Windows client printing, you may encounter the dreaded Unable to convert file 0 in your CUPS error_log file.

N OTE

Editing the mime.convs and the mime.types file does not enforce " raw " printing, it only allows it.

CUPS being a more security-aware printing system than traditional ones does not by default allow a user to send deliberate (possibly binary) data to printing devices. This could be easily abused to launch a " Denial of Service " attack on your printer(s), causing at least the loss of a lot of paper and ink. " Unknown " data are tagged by CUPS as MIME type: application/octet-stream and not allowed to go to the printer. By default, you can only send other (known) MIME types " raw ". Sending data " raw " means that CUPS does not try to convert them and passes them to the printer untouched (see the next chapter for even more background explanations ).

This is all you need to know to get the CUPS/Samba combo printing " raw " files prepared by Windows clients, which have vendor drivers locally installed. If you are not interested in background information about more advanced CUPS/Samba printing, simply skip the remaining sections of this chapter.

18.3.5 Driver Upload Methods

This section describes three familiar methods, plus one new one, by which printer drivers may be uploaded.

If you want to use the MS-RPC type printing, you must upload the drivers onto the Samba server first ( [print$] share). For a discussion on how to deposit printer drivers on the Samba host (so the Windows clients can download and use them via " Point'n'Print "), please refer to the previous chapter of this HOWTO Collection. There you will find a description or reference to three methods of preparing the client drivers on the Samba server:

• The GUI, " Add Printer Wizard " upload-from-a-Windows-client method.

• The command line, " smbclient/rpcclient " upload-from-a-UNIX-workstation method.

• The Imprints Toolset method.

These three methods apply to CUPS all the same. A new and more convenient way to load the Windows drivers into Samba is provided if you use CUPS:

• the cupsaddsmb utility.

cupsaddsmb is discussed in much detail further below. But we first explore the CUPS filtering system and compare the Windows and UNIX printing architectures.