|
4.4. Delivering Printer Drivers to Windows ClientsOne critically important part of Samba printer configuration is distributing drivers to Windows clients. This task can be accomplished in several different ways. One approach that requires little explanation is to use the driver CD-ROM that came with the printer (or a generic PostScript driver for Ghostscript-driven printers) to install the driver on all the clients. This approach is simple enough on a small network, but it becomes awkward when many clients are involved. For these cases, SMB/CIFS provides mechanisms to help deliver drivers to many clients, and Samba supports these mechanisms.
You can take a middle ground. Instead of using the semiautomated driver installation mechanisms described here, you can create an ordinary file share that holds the printer drivers. You can then install the drivers from that share on all the clients. This procedure obviates the need to carry a CD-ROM around from one computer to another, or to keep track of the CD-ROM for the benefit of computers you add after setting up the printer. 4.4.1. Picking a DriverThe first task you must undertake in driver installation is to select the drivers you want to install. To a large extent, this decision depends on whether you share the printer using a PostScript queue or a raw queue. (This difference is moot, of course, in the case of PostScript printers.) In many cases, though, you can choose between drivers from more than one source:
Because of the array of printers available today, I can't make a blanket recommendation for what driver to use; any of the preceding classes of drivers might work well. In fact, chances are any of them will work well with most printers, with the exception of PostScript drivers if you already know you want to share a non-PostScript printer raw. 4.4.2. Defining Necessary SharesSamba 2.2 and later use a special file share to deliver printer drivers. This share is defined as [print$]. Ultimately, printer driver files will reside in this share, but for the moment you must simply create it. A typical [print$] share looks like this: [print$] comment = Printer Driver Storage directory = /usr/share/samba/drivers browseable = No read only = Yes write list = gutenberg The location of the shared directory is somewhat arbitrary, but the key point is that it must exist. This directory must also be readable to all those who might want to add printers to their machines. You'll typically give one or more users write access to the share (gutenberg in this example). These users are the printer administrators; they're authorized to add printer drivers to the share. Be sure that the printer administrators have Linux write privileges to the location you've chosen as the PRINT$ share directory. You should also list these users on the printer admin line in the [global] section of smb.conf: printer admin = gutenberg Before adding drivers, you must also define some printer shares. If you want to share all the printers on the server, a [printers] share, as described in the section Section 4.5.4, should do nicely. [printers] comment = All Printers path = /var/spool/samba printable = Yes After you make these changes to smb.conf, you must either wait a minute or two for Samba to discover and implement the changes or force Samba to restart or reload its configuration file.
4.4.3. Installing the Driver on the ServerOnce you've reconfigured Samba with the PRINT$ share and one or more printer shares, you can install Windows printer drivers in Samba. You can perform this task from the Samba server, from another Linux or Unix system, or from a Windows client. The CUPS driver can only be installed from a Linux or Unix system, the Adobe PostScript driver can be installed in either way, and most other drivers can be most easily installed from a Windows client. 4.4.3.1 Installing drivers from LinuxCUPS ships with a program, called cupsaddsmb, which can install Windows printer drivers on a Samba server computer. This command's syntax is as follows: cupsaddsmb [-H samba-server] [-U samba-user] [-h cups-server] [-v] {-a | printer-list} In the simplest case, you can type cupsaddsmb -a on the server system as the printer administrator. The system defaults to installing the CUPS drivers from localhost to localhost. The -a parameter tells the program to add drivers for all available CUPS printers. If you don't share all these printers, you must specify them individually. The -v parameter increases the verbosity of the program's output, which can be handy for debugging problems. Of course, cupsaddsmb can't conjure printer drivers out of thin air; you must place them somewhere the program can find them before executing the program. By default, cupsaddsmb looks for drivers in /usr/share/cups/drivers. These drivers can come from one of two sources:
In either case, you must install driver files in /usr/share/cups/drivers, but how you place them there depends on the driver. In the case of the CUPS drivers, you download a tarball from the CUPS web site, extract the tarball, and run the cups-samba.install script from the tarball. This script asks for confirmation and installs the files in /usr/share/cups/drivers. You can then run cupsaddsmb to install the drivers on the Samba server. The Adobe drivers, on the other hand, were designed to be installed from a Windows system to a Windows system. They come in the form of a Windows executable (.EXE) file. This file is a self-extracting Microsoft Cabinet archive, which can be extracted in Linux using the cabextract program. (Check your distribution for this program, or visit http://freshmeat.net/projects/cabextract/ to download the source code or a binary package.) When you extract the drivers file, you must copy several files into /usr/share/cups/drivers, as detailed in Table 4-1. Note that cupsaddsmb expects these files to appear in all-uppercase, but some of them are in lowercase or mixed case in the archive; you need to rename some of the files to change their case. Also, these files are scattered about in the Windows and WinNT subdirectories. In my experience, this option works well for Windows NT/200x/XP, but Windows 9x/Me tends to complain about a missing .INF file when installing the drivers installed in this way. If you run into this problem, you may need to install Windows 9x/Me drivers another way.
Once you've installed the CUPS or Adobe driver files, you can type cupsaddsmb -a or whatever variant you need to type, given your printer administration username and other variables. The program should ask for your password on the Samba server, copy the driver files, and configure the server to deliver the files to clients when they connect, as described in Section 4.4.4. Unfortunately, cupsaddsmb is rather delicate and sometimes doesn't work correctly. Likely problems include missing driver files, an attempt to install drivers without appropriate privileges on the server, and a mismatch of CUPS and Samba printer names (cupsaddsmb assumes that these names match). If you have problems, check these items. You may also want to add the -v parameter and check your Samba log files for clues to the cause of the problem.
4.4.3.2 Installing drivers from Windows NT/200x/XPIn theory, any Windows driver can be installed from Linux. The cupsaddsmb command merely copies files to the server and issues a few commands using the smbclient utility. You should be able to do the same for any printer driver files. In practice, though, the task is tedious without the help of cupsaddsmb, and it only supports the CUPS and Adobe PostScript drivers. For this reason, you may want to install some drivers from Windows clients. (This task can be accomplished only from Windows NT/200x/XP clients; Windows 9x/Me doesn't support this operation.) Doing so employs the same facilities on the Samba server cupsaddsmb uses, but the Windows driver-installation tools use these features.
When installing drivers from Windows, you must take one extra step on the Samba server computer. Windows printer drivers are installed in fixed directories on the Samba server's PRINT$ share. You must create these directories and set their permissions so that the user adding the drivers can write to them. Table 4-2 summarizes the directories you must add.
Before proceeding, you should obtain the driver installation files. If you choose to use a driver that ships with Windows, you need only the Windows installation CD-ROM. Alternatively, you can download drivers from the printer manufacturer, from Adobe, or conceivably from some other source. Once you've obtained the drivers, follow these steps on the Windows computer to install drivers for the OS you're running:
This procedure adds drivers for the OS that the client you used to install them is running. If you want to add drivers for additional operating systems, follow these steps.
4.4.4. Installing Drivers on ClientsWindows printer drivers, by their very nature, are Windows programs and so must be installed on Windows print clients. Installing them on a Samba server merely makes the drivers available for semiautomatic installation on Windows clients, thus obviating the need to keep track of driver installation CD-ROMs or files. Despite the fact that installing the drivers on the Samba server simplifies client driver installation, this task isn't wholly automatic, at least not when using SMB/CIFS printing. To install a driver on a Windows client, follow these steps:
If all goes well, you'll see a dialog box summarizing the progress as the client transfers files from the server. An icon for the printer should then appear in your Printers or Printers and Faxes window, which you can open from the Control Panel. Windows 9x/Me asks if you want to print a test page during the install process. You should probably do so to test the printer's operation, particularly on the first client you install. If you skip this step during installation but want to do so afterwards, right-click the printer icon in the Printers or Printers and Faxes window and select Properties from the resulting menu. This action opens a Properties dialog box. Click Print Test Page from the General tab in this dialog box to print a test page.
Some Windows PostScript printer drivers generate PostScript that can confuse Linux printer queues into thinking the file is plain text. The result is a printout of PostScript commands, rather than the file you'd intended to print. If this happens, you can try several solutions.
|
|