In this article, learn to:
- Create and configure printer sharing
- Configure integration between Samba and the Common UNIX® Print System (CUPS)
- Manage Windows® print drivers, and configure downloads of print drivers
- Configure the [print$] share
- Understand security concerns with printer sharing
- Set up and manage print accounting
This article helps you prepare for Objective 312.3 in Topic 312 of the Linux Professional Institute's (LPI) Mixed Environment Specialty exam (302). The objective has a weight of 2.
To get the most from the articles in this series, you should have an advanced knowledge of Linux and a working Linux system on which you can practice the commands covered in this article. In addition, you should have access to a Windows environment that you can use to test file and print access.
Configuring a printer share
Configuring a Samba printer share is much like configuring a file share. You define a section, set some parameters, and connect your clients. Because printing is involved, however, there are some subtle differences. Listing 1 shows a fairly typical configuration inside smb.conf.
Listing 1. Typical printing configuration
[global] load printers = yes printing = sysv [printers] comment = Printers path = /var/spool/samba writable = no printable = yes
Listing 1 doesn't define any specific printers. Instead, it tells Samba to
load the list of system printers, then defines a template section called
[printers]. Recall from the previous article that the
section is used as a template for home directories. The
[printers] section does the same thing for
At the global level, the
load printers parameter
tells Samba to look for system printers and set them up as shares.
printing = sysv means to use the older SysV
printing system. This will do for now, but later, you will learn how to
configure the more modern CUPS.
[printers] section defines what each printer
share will look like. Unless you need to offer special options per
printer, such as restricting users, you can usually get away with the
path is for Samba's use. When you
print to a Samba printer,
smbd spools the file
to the directory that the
specifies before sending the job on to the system print facility. Then,
you must make sure that the share is not
writable and that it is
printable so that Samba can properly use it as
a printer share.
Now, if you browse to your server, you can see the list of printers. If you have the correct printer driver installed on your Windows client, you can proceed to install that printer and use it over the network.
Integrating Samba and CUPS
CUPS has replaced the SysV printing system in most Linux distributions.
CUPS is more flexible and user friendly than SysV printing, and it offers
a compatibility layer that integrates seamlessly with legacy printing. If
lpq commands, you're likely going through CUPS.
One way CUPS improves upon legacy printing is its ability to pre-process print jobs. For example, if you send a PDF file to a printer, CUPS can understand the file format, send the output through something like GhostScript, and translate the file into a language that the printer can understand. This was possible with a lot of hacking in the old days, but it's all baked into CUPS.
The simplest configuration required to enable CUPS printing is shown in Listing 2.
Listing 2. Enabling CUPS support
[global] printing = cups printcap = cups
Listing 2 works in global mode. First, printing is done through the CUPS
libraries instead of
lpr. The last command
tells Samba to fetch its list of printers from the CUPS daemon instead of
the system printcap file. You may still have a printcap file even if you
use CUPS, as CUPS maintains this file for compatibility with non-CUPS
Even with Samba integrated with CUPS, you still use CUPS tools to manage the print queues. If you do not know your way around CUPS, here is an overview of the more important commands:
lp. Sends output to the printer. (You usually pipe the output of one command to this command, such as
cat /etc/motd | lp.)
cupsdisable. Starts and stops printers, respectively. (These are good commands for resetting a printer, too.)
cupsreject. Rejects or accepts jobs to a printer. (This command does not change the status of the printer; instead, it tells CUPS to reject incoming jobs.)
lpadmin. Lets you set configuration values on a printer, such as assigning quotas.
lpq. Shows the queued entries for a given printer.
lprm. Lets you cancel jobs from a printer.
Raw vs. intelligent configuration
Printers generally understand a Page Description Language (PDL) such as Adobe® PostScript® or Printer Command Language (PCL). Some printers may use a vendor-specific PDL. It is the job of the Windows printer driver to translate the application's print commands into the PDL the printer speaks. Without the printer driver, the commands that the application generates will be printed directly as text, resulting in reams of garbage.
This method of having the client process the document into a format ready for the printer is called raw printing. In this mode, Samba merely copies the bytes from the client to the printer. This approach has two downsides:
- The client must have the printer-specific driver in order to print.
- It is difficult for Samba to understand what the job is doing, such as to log how many pages were printed.
Despite these two drawbacks, raw printing is easy to set up. Printer drivers can be distributed from the Samba server with some additional effort.
Distributing drivers to Windows clients
Getting Samba to distribute your printer drivers is a complicated matter. The best approach is to install a universal PostScript printer driver and use that for all your printers. CUPS will take care of converting the client's PostScript into something the printer understands through its intelligent printing system. You will also gain insight into the number of pages printed by using this approach instead of native drivers.
You will need to download the CUPS drivers: The current file is cups-windows-6.0-1.i386.rpm (see Resources for a link). This package installs the following files into /usr/share/cups/drivers:
The CUPS drivers only support Microsoft® Windows 2000 and later clients, which is usually alright, but the Samba utility used later is hard-coded to look for the legacy Microsoft drivers and fails if they are not present. The following files will be on your system, and they should also be copied to /usr/share/cups/drivers:
These files are usually in your C:\WINDOWS\ServicePackFiles\i386 directory.
Now that all eight files are in your CUPS drivers directory, you create the print$ share. This share is hard-coded into Windows clients, and this is where the clients look for printer drivers when a printer is installed. The printer share is a fairly standard share, as shown in Listing 3.
Listing 3. The print$ share
[print$] comment = Printer Driver Export path = /etc/samba/drivers browseable = yes guest ok = no read only = yes write list = root
Listing 3 shows a simple share that's Read-only to everyone but the root user. Don't forget to restart Samba to make this share take effect.
Finally, use the
cupsaddsmb command to install
the printer drivers. For the Downstairs_Laser share, simply run
cupsaddsmb -v Downstairs_Laser. You will be
prompted for your root password, and then your screen will show a flurry
Clients can now browser to your Samba server and double-click the printer. They will be able to use the printer without any extra steps, such as printer identification and driver installation.
You should use the generic CUPS PostScript driver so that CUPS can
understand what is being printed. If you decide to distribute Windows
drivers, the procedure is similar. First, you don't use the
cupsaddsmb command. You copy the drivers to
/etc/samba/drivers yourself but also must put them in an
architecture-specific directory (
this for you). For example, W32X86 is used for 32-bit drivers.
You use the
rpcclient command to tell Samba
about the driver. You must pass the name of the printer driver files and
the official name of the printer. See Resources
for a worked-out example.
Accounting and security
Accounting, when it comes to printers, is really about tracking and restricting page usage per user. Security refers to the ability to know who is using your printers and limiting access where required. This access could be the ability to print to the printer or the ability to cancel other people's jobs.
Samba's role in the printing process is to take a client's print file, such as PostScript, and send it to CUPS. Anything Samba does, such as showing the status of the print queue to a client, it does through CUPS. CUPS queues the files; CUPS controls the printer. Samba's job is to be a conduit between CUPS and the client.
It is possible to get the clients to print directly to CUPS using the Internet Printing Protocol. However, the ease of printer installation from the Microsoft Network Neighborhood cannot be underestimated. Just remember that any controls you implement at the Samba level can be potentially overridden at the CUPS level if clients connect directly to CUPS.
Consider a printer share that has been protected using
valid users = alice, bob to allow only two
users to print. If user mallory tries to print through Samba, the
request will be denied. If CUPS was not set up with similar permissions,
mallory could print to the printer through the CUPS queue.
One other security consideration is the use of guest users. If you can
authenticate every user who needs to print, ensure that
guest ok = no is in your
[printers] configuration section; then, only
authenticated users will be able to print. Otherwise, unknown users can
print to your printers.
As in printing jobs, CUPS handles the accounting work, not Samba. CUPS allows for the use of printer quotas, which limit the number of printed pages per user per time period. Listing 4 shows how to impose a quota on a printer.
Listing 4. Imposing a quota on a printer
# lpadmin -p Downstairs_Laser -o job-quota-period=604800 -o job-page-limit=100 \ job-k-limit=50000
Listing 4 sets three options on the printer. The first is the job quota period, which is 604,800 seconds (1 week). The second is the page limit during that quota period: Here, it is 100 pages. A third option limits the amount of printing to 50MB. The latter is not required, especially because it's a difficult value to gauge, but it does provide options for people who want to limit the printing of graphically intensive files.
To verify or check the quota on a printer, look in /etc/cups/printers.conf;
you will see the
KLimit options with the values you added above.
To remove quotas, set the values to
Each print job logs to a file called page.log, which is often found in /var/log/cups. A typical line looks like Listing 5.
Listing 5. A typical page accounting log
Downstairs_Laser 755 sean [26/Apr/2011:15:02:27 -0500] 1 1 - localhost smbprn.0019.FWqosE
The left part of the line is most relevant to printer accounting. The fields, in order, are:
- The printer name
- The job number assigned to the print job
- The user who printed
- The date in GMT and the time zone offset
- The number of pages printed
- The number of copies sent
Thus, the number of pages used is the number of pages printed times the number of copies sent. See Resources for a description of the remaining fields.
Note: The biggest limitation of CUPS quotas is that they apply to all users.
The next exam objective, 312.4, will dive into the details of making Samba act as and with Microsoft primary and backup domain controllers.
- The web version of the smb.conf man page is more convenient than the command-line version.
- Review the developerWorks study material for Topic 107 to get a refresher on command-line printing.
- Chapter 21 of the Samba-HOWTO describes "classical" printing support, which is what you had before CUPS was involved. This site also has a worked-out example for adding a Windows printer driver.
- Chapter 22 of the Samba-HOWTO has extra information on CUPS and Samba integration.
- The page_log section of the CUPS documentation lists all the fields inside the page log, just in case there was something else you needed to report on.
- At the LPIC Program site, find detailed objectives, task lists, and sample questions for the three levels of the LPI's Linux systems administration certification. In particular, look at the LPI-302 detailed objectives and the tasks and sample questions.
- Review the entire LPI exam prep series on developerWorks to learn Linux fundamentals and prepare for systems administrator certification based on LPI exam objectives prior to April 2009.
- Exam Preparation Resources for Revised LPIC Exams provides a list of other certification training resources maintained by LPI.
- In the developerWorks Linux zone, find hundreds of how-to articles and tutorials, as well as downloads, discussion forums, and a wealth of other resources for Linux developers and administrators.
- Stay current with developerWorks technical events and webcasts focused on a variety of IBM products and IT industry topics.
- Attend a free developerWorks Live! briefing to get up-to-speed quickly on IBM products and tools, as well as IT industry trends.
- Watch developerWorks on-demand demos ranging from product installation and setup demos for beginners, to advanced functionality for experienced developers.
- Follow developerWorks on Twitter, or subscribe to a feed of Linux tweets on developerWorks.
Get products and technologies
- Download the Windows CUPS driver.
- Get the latest Samba version so that you're up to date with the latest features.
- Evaluate IBM products in the way that suits you best: Download a product trial, try a product online, use a product in a cloud environment, or spend a few hours in the SOA Sandbox learning how to implement Service Oriented Architecture efficiently.
- Get involved in the My developerWorks community. Connect with other developerWorks users while exploring the developer-driven blogs, forums, groups, and wikis.