Linux Printing in a Microsoft World (and Vice-Versa)
Need to get Linux to access the printers on your Windows server? Or Windows clients to access your Linux printers? Our expert walks you through both scenarios, using SUSE Linux and Windows 2000 Server as primary examples.
Welcome to the first installment of Redmondmag.com's exclusive new
column, "Integration Station." Every month, 'Nix and Windows
author and trainer Emmett Dulaney will tackle some of the most common (and frustrating)
interop scenarios, walking you through the best solutions from both sides of
the fence. If you have a topic you want Emmett to tackle, a question or feedback
on this column, or just want to say hey, be sure to post your comment below,
visit the new Linux/Windows
Interop area of our forums or e-mail Emmett directly at [email protected].
– The Eds.
One of the most common resources shared on networks today are printers. Thankfully
long gone are the days when every user had a dot matrix printer sitting beside
their desk with a box of perforated paper running to it. Networks today operate
with the bare number of printers and stations needed spread throughout the worksite.
As networks have become more heterogeneous and begun including more than one
operating system, those behind most OSes have seen fit to make the access to,
and sharing of printers fairly straightforward. This is true not only of Microsoft
(with Windows XP and the various flavors of Windows Server), but also of the
companies behind most Linux distributions. While the Linux tools vary based
upon the distribution, most feature the same functionality.
For this article, I will look at the process of integrating the printers in
two different scenarios. First, we will walkthrough the process of configuring
SUSE Linux (formerly SuSE Linux Professional) to access a shared printer from
a Windows 2000 Server. This illustrates the means by which Linux desktop clients
can access printers on a Windows network. You should know that, as with most
things Linux, there is more than one way to accomplish each of these tasks,
and I am attempting to illustrate the most straightforward.
Following that, we'll walkthrough the process of configuring a Windows
XP Professional client to access a printer on a SUSE Linux Enterprise Server.
Again, there are many ways to approach this, but the method discussed here illustrates
the means by which Windows desktop clients can access printers on a Linux network.
Having looked at the issue from both angles, you should be comfortable with
integrating printing in your heterogeneous network.
Linux Clients to Windows Printer
In this scenario, a color printer (Canon BJC 8200) is connected to a Windows
2000 Server named Traveler and is using the spool name of LocalCol. A SUSE Linux
10 client is being configured to access this printer.
To start the configuration, use the printer tool available in your version
of Linux and make certain you have administrative (root-level) privileges. In
SUSE, there are a number of ways to arrive at the same spot, but the best tool
to use is YaST (Yet another Setup Tool). Once this is started, choose Hardware
and then Printer. Note that depending upon your settings, you may have to modify
the firewall configuration in order to allow Samba to work properly (more on
this in the "Possible Complications" section later
in this article).
When prompted to choose a Printer Type, select Print via SMB Network
Server, as shown in Figure 1.
Figure 1: On the Linux client, choose to print via SMB Network
Server.
(Click image to view larger version.) |
Within the Connection Information frame, the name of the Print Server
(the Windows Server, in this case) must be entered along with the Remote
Queue name (see Figure 2).
Figure 2: Enter the corresponding connection information
and click Next.
(Click image to view larger version.) |
Notice that the Workgroup information was not entered in this
case as the name between the two is the same. If the server is on a different
workgroup, that field needs to be entered as well. A username and corresponding
password is entered, and you should choose to Test Remote SMB Access
simply to see that the firewall is allowing the connection.
An interesting condition exists with the username and password. They are stored
and used with jobs as they are submitted to the printer. Given the sensitive
nature of the values, the password appears as asterisks on this configuration
screen, but -- surprisingly -- only on this configuration screen. When viewing
Printer Configuration, the values appear in clear text. For example, if the
username is edulaney and the password is bubbles, then the value in the Printer
Configuration dialog boxes will always appear as /edulaney:bubbles@traveler/localcol.
While there is little you can do about it, it is something you need to be aware
of should other administrators also view printer configuration on your network.
Next, you must choose the printer manufacturer and model. Finally, you are
given the option to test the printer at the configuration summary screen (see
Figure 3).
Figure 3: Once configured, test the printer before
continuing on. The client can now print to the printer on the Windows
network.
(Click image to view larger version.) |
Always use this opportunity to make certain the printout is correct
before clicking OK. The printer configuration is saved, you are free
to exit YaST, and use the printer as shown in Figure 4.
Figure 4: Success! The printer now appears as a print option
and can accept print jobs.
(Click image to view larger version.) |
Windows Client to Linux Printers
In this scenario, a color printer (Canon BJC 8200) is connected to a SUSE Linux
Enterprise Server 9 server named “linuxone” and is using the spool
name of “color”. A Windows XP client is being configured to access
this printer.
When Windows clients talk with Windows print servers, they download the drivers
they need -- if possible -- from that print server. Since it does not work quite
that way when Windows is talking to Linux, the method used here installs the
needed drivers on the client.
On the Linux server, the printer should be configured as a Common Unix Print
System (CUPS) printer – CUPS has pretty much replaced the older methods
of printing. The CUPS server settings should allow for browsing (192.168.0.*
allows it for that network), and you must make sure traffic can get through
the Linux firewall. Edit two files under /etc/cups – mime.types and mime.convs
and remove the hash mark at the beginning of the line:
#application/octet-stream
and save both files. Stop and restart cupsd with the commands:
/etc/init.d/cups stop
/etc/init.d/cups start
On the Windows XP client, start the Add Printer Wizard (Start, Printers
and Faxes, Add a Printer). Choose to add a network printer, then
select to add a printer connected to the Internet or on a home or office network,
as shown in Figure 5. Notice that port 631 (for CUPS) is used, and the name
of the printer is the same as what it is known as on the Linux server.
Figure 5: Use the Add Printer Wizard to find the
Linux printer.
(Click image to view larger version.) |
Choose the manufacturer and printer (see Figure 6) and the driver files will
be copied over.
Figure 6: Choose the correct printer to load the appropriate
drivers.
(Click image to view larger version.) |
Choose whether this printer will be the default or not, and
agree to the settings at the summary screen. Next, open the printer’s
properties (right-click on the icon and choose Properties) and choose
Print Test Page on the General tab as shown in Figure 7.
Figure 7: Always print a test page to make certain you can
access the Linux printer.
(Click image to view larger version.) |
The printer can now be accessed on the Windows client the same
as any other printer on the network.
Possible Complications
Though the examples given here were very straightforward, there are issues that
can complicate the matter. One of the most troublesome is the need to allow
traffic through the firewall in order to be able to communicate. If you are
going to allow remote configuration of the printer, you typically have to allow
HTTP through (port 80) as well as those related to SMB (137-139) and LPD (515),
not to mention CUPS (631). If JetDirect is used, it utilizes port 9100 by default.
Name resolution can also be a very tricky issue with an integrated network.
If the host name does not seem to be found, you have a couple of tricks at your
disposal. The first is to replace the name with the IP address (assuming the
addresses do not change frequently) and the second (also dependent upon addresses
remaining relatively the same) is to add the hostname and associated address
into the hosts file. On Linux clients, the file is /etc/hosts, while on Windows
XP clients, the file is \Windwsystem32\drivers\etc\hosts.
Lastly, there are a number of tweaks that can be done in the Samba configuration
file /etc/samba/smb.conf that can change some of the printing operations (for
better or worse). Samba is the topic of an upcoming article and these tweaks
will be addressed then.
Next Month...
Now that the Integration Station column has come to fruition, it is time to
create a framework for it. One of the main problems with discussing the topic
is that “integration” can mean many different things to various
administrators. Because of that, next month the focus will be on what is Linux/Windows
integration, followed by more hands-on integration topics – including
some I hope you’ll suggest. Be sure to post below, in our forums,
or write me at [email protected].