Learn Linux, 302 (Mixed environments): Print services

Create and manage Samba print shares in a mixed environment

In preparation for taking the Linux Professional Institute Certification exam LPI-302 for systems administrators, learn how to set up printers and share them between Linux and Microsoft clients.

Sean A. Walberg, Senior Network Engineer

Photo of Sean WalbergSean Walberg is a network engineer and the author of two books on networking. He has worked in several industries, including health care and media.



09 August 2011

Also available in Russian Japanese Portuguese Spanish

About this series

This series of articles helps you learn Linux systems administration tasks. You can also use the material in these articles to prepare for the Linux Professional Institute Certification level 3 (LPIC-3) exams.

See our developerWorks roadmap for LPIC-3 for a description of and link to each article in this series. The roadmap is in progress and reflects the current objectives (November 2010) for the LPIC-3 exams. As each article is completed, it is added to the roadmap.

Overview

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.

Prerequisites

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

About the elective LPI-302 exam

Linux Professional Institute Certification (LPIC) is like many other certifications in that different levels are offered, with each level requiring more knowledge and experience than the previous one. The LPI-302 exam is an elective specialty exam in the third level of the LPIC hierarchy and requires an advanced level of Linux system administration knowledge.

To get your LPIC level 3 (LPIC-3) certification, you must pass the two first-level exams (101 and 102), the two second-level exams (201 and 202), and the LPIC-3 core exam (301). After you have achieved this level, you can take the elective specialty exams, such as LPI-302.

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 [homes] section is used as a template for home directories. The [printers] section does the same thing for printers.

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.

The [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 template. The path is for Samba's use. When you print to a Samba printer, smbd spools the file to the directory that the path parameter 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

Build your own feed

You can build a custom RSS, Atom, or HTML feed so you will be notified as we add new articles or update content. Go to developerWork RSS feeds. Select Linux for the zone and Articles for the type, and type Linux Professional Institute for the keywords. Then, choose your preferred feed type.

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 you're using lp or 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 applications.

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.)
  • cupsenable and 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:

  • cups6.inf
  • cups6.ini
  • cupsps6.dll
  • cupsui6.dll

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:

  • ps5ui.dll
  • pscript5.dll
  • pscript.hlp
  • pscript.ntf

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 of activity.

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.

Vendor-specific drivers

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 (cupsaddsmb did 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.

Printer security

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.

Print quotas

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 QuotaPeriod, PageLimit, and KLimit options with the values you added above. To remove quotas, set the values to 0.

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.


Moving forward

The next exam objective, 312.4, will dive into the details of making Samba act as and with Microsoft primary and backup domain controllers.

Resources

Learn

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.

Discuss

  • Get involved in the My developerWorks community. Connect with other developerWorks users while exploring the developer-driven blogs, forums, groups, and wikis.

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Linux on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Linux
ArticleID=751630
ArticleTitle=Learn Linux, 302 (Mixed environments): Print services
publish-date=08092011