This is a read-only archive. Find the latest Linux articles, documentation, and answers at the new!

Feature: System Administration

Multifunction copiers in a Linux network

By Keith Winston on March 13, 2008 (7:00:00 PM)

Share    Print    Comments   

In many organizations, copiers get little respect. Often relegated to a break room or storage closet, they are underutilized and underappreciated, and get no attention from the IT department. Yet, multifunction copiers can play a critical role in reducing operating costs and become a hub for document processing.

Many modern multifunction devices support Windows, Macs, and Unix/Linux drivers and printing protocols. They also offer scanning to email or to disk, can search an LDAP directory, and optionally support faxing. In fact, most use a generic PC architecture, complete with a motherboard, Intel or AMD processor, and an internal hard disk. They are in most ways massive (roughly 200 kilograms each) PC-based servers with an integrated high-speed scanner and printer.

While my direct experience is based on deploying more than 20 Ricoh copiers, you'll find that Canon, Toshiba, and Xerox products all have similar capabilities.

Using the management interface

Built into each Ricoh copier is a Web server that offers up a slick management interface called the Web image monitor. With no authentication, you can view the current meter reading, active jobs of all kinds, status messages for each function, the size and amount of paper in each tray, and the toner levels. If you log in as the machine administrator (the highest privilege level), you gain access to almost all configuration settings, including network options, services, and defaults.

The Web monitor interface is served through cgi-bin scripts and uses basic authentication for logins. You can enable SSL (HTTPS) if a device certificate is installed. There are also options for using SSL on the back end to talk to LDAP and mail servers.

One of the basic system configuration parameters in Web monitor is to define the SMTP (mail) server that the copier will use to send and receive email for error reports, documents scanned to email, or inbound faxes. You can define how it will authenticate to the mail server, including POP before SMTP or SASL/TLS. It sends standards-based email, so the receiving server has no special requirements. Sendmail, Postfix, or any standard mail server will work without issues. A somewhat esoteric option lets it receive incoming mail from a specific address and either print or fax it.


The core function of a copier is copying paper documents. There is no network integration in the copying function, but the hardware required for high-speed copying -- that is, a fast scanner and fast printer -- can be easily applied to other functions.

The most common model of copier deployed at my organization has an output speed between 55 and 75 pages per minute, with the fastest capable of 135ppm. These speeds dwarf high-end office laser printers, making a copier an attractive target for large reports. The other benefit is the lower cost to print per page: about half a cent. Over time, shifting some of the print load to copiers will save money.

To integrate printing with our Linux-based network, I chose the Internet Printing Protocol (IPP), the native printing protocol supported by CUPS. IPP uses HTTP as the transport and communicates over port 631. If you have a segmented or firewalled internal network, you might have to make accommodations to allow traffic on port 631 throughout your network.

Each CUPS print queue was set up as a "raw" printer, meaning it forwards unfiltered print jobs to the device, relying on the client print driver to send a correctly formatted job. Print jobs can be queued by the copier itself, or the copier can accept jobs queued on a network print server. According to Ricoh, queuing on a network print server is considered best practice for larger organizations. Queuing on a network print server reduces some of the load on the copier and keeps local disk space free for other uses.

Other print protocols supported by the copier include LPR/LPD, JetDirect (port 9100), Netware 3.x, and AppleTalk, and Windows SMB. As a security precaution, I disabled the unused protocols. Ricoh copiers support HP PCL version 5 and 6 print language jobs natively. There is a software option to enable PostScript for an additional cost.

Using Windows and Mac drivers provided by Ricoh, print options include all the finishing options installed on the copier, such as stapling, collating, duplex printing, reducing or increasing the print image size, and making booklets. The resolution can be set up to 1200 dpi, and there are security features such as "locked print," which lets you assign a password to the print job. When locked, a print job is stored on the copier's hard disk until it is released with the correct password. This feature is valuable for sensitive documents.

Jobs have to be submitted from the command line to take advantage of finishing. For basic printing, you can print directly to a CUPS copier using a LaserJet PCL driver. It might be possible to use the Mac PPD in CUPS to gain access to the finishing options without using the command line, but I haven't explored it.


A secondary goal of the copier deployment was to replace an aging fleet of fax machines. A Group 3 (G3) fax modem is an optional feature that can be added to most multifunction copiers. It requires a standard analog telephone line for sending and receiving faxes. Ricoh models include software that integrates with other parts of the system and uses the system email settings.

There are two ways to send faxes with the multifunction device. You can walk up and fax a hard copy document by selecting the fax button, entering a phone number, and sending the documents through the scanner. You can also use the LAN-fax print driver to send faxes from your computer. I set up a separate raw CUPS print queue for LAN-fax print jobs on each copier. A separate print driver for LAN-fax has to be installed on each client. LAN-fax drivers were available for Windows and Mac OS X, but no driver was available from Ricoh for Unix/Linux clients.

Received faxes can be printed immediately as on a typical fax machine, or they can be routed to the local hard disk, or routed to an email address. To save paper, and reduce the chances of a lost fax, we decided to route incoming faxes to email, one mailbox per copier. Someone is assigned to monitor each fax mailbox and forward incoming faxes to the proper recipients via email as TIFF attachments. The one feature we missed was a PDF attachment option, which oddly is available for scanned documents, but not for faxes routed via email.

Fax options were the most difficult to configure. There are five separate pages of options in the Web monitor for setting fax options. Two of those pages discuss integrating faxing with third-party fax servers. We decided to stick with basic fax routing, so only three pages of options applied. On top of Web monitor options, we had to set a couple of things on each machine using the fax parameters -- a set of eight-bit switches that can only be turned off and on using the touch panel. For example, to prevent received faxes that are routed to email from also printing immediately, I had to set Switch 11 bit 6 to 0 (the default is 1). I only had to venture into the parameters a few times, but since none of the bits is discussed in user documentation, it felt like tinkering with something arcane and dangerous. How did I know what parameters to set? A Ricoh engineer working on the deployment had to tell me which ones to change based on my needs.

One final hurdle slowed the deployment. Copier-based faxing changed some fundamental business processes. Moving existing fax lines into each copier had to be planned to coincide with training on how to use the copier for sending and receiving faxes. Significant vendor training was required to get everyone in the organization up to speed.

Integration with OpenLDAP

Multifunction copiers can communicate with LDAP directories such as Active Directory, Novell NDS, Red Hat Directory, and OpenLDAP. Using the Web monitor, you enter the information for as many as five directory servers. For each LDAP server, you enter the address, base distinguished name (DN), and credentials to use to authenticate. You can also use anonymous connections. All configuration options are on a single Web page, including whether to use LDAPS (SSL) when connecting to the directory.

You can search any defined LDAP directory at the touch panel of the copier. By default, searches are done using part of a person's common name, and their email address (mail attribute) is returned. We had recently started migration of the network to OpenLDAP from Sun's Network Information System (NIS). The NIS-to-OpenLDAP scripts we used in the conversion did not add a mail attribute to our directory because it didn't exist in the NIS system files. Since the mail attribute is what we needed from the directory, I had to add it to our OpenLDAP schema. Connection tests and searches run before the mail attribute was added would succeed but return nothing. After adding the mail attribute and populating it, directory searches returned matching email addresses. The results of searches are primarily used as destinations for scanned documents and faxes.

You can also search on email address, fax number, organization, and department name (organizational unit). You can program one custom attribute from each directory as a search field; e.g. an employee number.


The high speed scanner on most copiers can be used in a number of different applications. With hard-disk-equipped copiers, for instance, you can scan a frequently used form and store it on disk so that it can be printed on demand.

The most popular use of scanning is to convert paper documents into Adobe Portable Document Format (PDF) and email the files. Most scan-to-email tasks are for internal use or filing. You must configure the email server address in order for the copier to send email, and the server must accept incoming mail from the devices. The LDAP directory is useful for selecting the email destination of a scanned document, though you could enter it manually at the touch panel. Scanned images default to 200 dpi, but the models we installed can scan at up to 600 dpi. You can also scan double-sided documents by selecting an option at time of the scan. Documents that are too large to send through email can be stored on the local disk and downloaded through the Web monitor.

PDF is not the only file type you can create from a scan; TIFF and JPG image formats are also possibilities. While scanning produced excellent results for our text documents, I suggest using a high-end color device to create graphics-quality scanned images.


The programmability of multifunction devices brings new security concerns. Most have a built-in Web interface for configuration and management. Each Ricoh machine came from the factory with no password; one of the first things you need to do with a system is set the Web monitor administrator password. Even with a password set, the device uses basic authentication by default unless you create and install a device certificate. Then, HTTPS can be used with the Web monitor.

Multifunction devices come with a laundry list of enabled services. As with a standard Linux server, you should disable any services you don't plan to use. Here is the list of enabled services on our standard unit:

  • HTTP
  • LPD
  • RSH
  • Telnet
  • JetDirect port 9100
  • FTP
  • IPP
  • AppleTalk
  • BonJour
  • NetWare
  • SNMP
  • SMB file sharing

Fortunately, you can disable all services (except HTTP) through the Web monitor. Some, like NetWare and AppleTalk, forced a system restart that took from 60 to 90 seconds.

The security system supports four levels of administration, so you can delegate mundane tasks to users without giving up complete control of the device. Individuals can be assigned the following levels, from lowest to highest:

  • File administrator
  • User administrator
  • Network administrator
  • Machine administrator

Job logs, access logs, and a system log aid in troubleshooting problems. I found logging surprisingly complete, including a list of all copy jobs, print jobs, and inbound and outbound faxes. Job history appears to be limited to the last 100 jobs of each type, though there may be a way to save more.

Command-line interface

Options that can be set through the Web monitor can also be set from a command-line interface via Telnet. The Telnet login drops you into the RICOH Maintenance Shell, a restricted shell that recognizes Ricoh-specific commands. Standard Unix/Linux commands are not available -- only commands that set configuration options.

An SSH service is supposed to be available, and it appears in the Web monitor, but I could never log in using SSH. An Nmap port scan did not show anything listening on the standard SSH port 22. It reported the operating system as NetBSD, but I haven't found a way to confirm that.

Logistics and training

While we had a few technical obstacles to integrating multifunction copiers in a Linux network, the logistics turned out to be the most difficult to manage. Unlike personal computers, copiers are massive and bulky. Deploy more than a few units and it quickly adds up to metric tons of equipment. Before you can begin installation, you have to address the environmental needs, such as electrical power requirements, phone and data cabling, and available space. The standard power requirement for the industry in the US seems to be NEMA 5-20R, a 110-volt 20-amp line. Larger units may require a 220-volt 20-amp line with a different face plate. The manufacturer will have all the details.

A final important consideration is the support and training available. The quality of the trainers for large multifunctions can make or break a project, especially when you're introducing new features like scanning, LAN-fax, and finished printing. These functions affect the daily work life of many people, and improving their lives is bound to improve yours.

Share    Print    Comments   


on Multifunction copiers in a Linux network

Note: Comments are owned by the poster. We are not responsible for their content.

Printer manufacturers with official open source Linux drivers

Posted by: Anonymous [ip:] on March 13, 2008 08:24 PM

HP is best at open source among its competitors. Unfortunately HP ink cartridges costs a fortune.


Brother comes in second, but both printer and cartridges tends to be expensive.


Epson has cheap printers and cartidges, but the open source drivers depends on a proprietary library and that is a problem for most Linux distributions.



Multifunction copiers in a Linux network

Posted by: Anonymous [ip:] on March 13, 2008 09:02 PM
The support for Ricoh multifunction printers seems quite impressive to me, certainly better results than I had with other manufacturers. For a large number of models Ricoh has published their own PPD files.

On the 3 models I tested almost all the options were available, including the advanced finishing features such as booklet stapling (although didn't try out automation of reducing A4 to A5 and sorting the page order properly).

Also the document server was impressive to. Allowed printing to the printers HD of documents that are regularly printed out, for permanent storage, and can be reprinted without the job having to be reprinted from the original source.


Multifunction copiers in a Linux network

Posted by: Anonymous [ip:] on March 13, 2008 09:10 PM
With regard to fax drivers...they do somehow exist though not necessarily easy to get hold of yet.,3847

Check out posts 4, 6 and 7


...or an underestimated security gap

Posted by: Michael Shigorin on March 13, 2008 10:25 PM
there was a nice whitepaper on multifunc security issues


Multifunction copiers in a Linux network

Posted by: Anonymous [ip:] on March 14, 2008 03:37 AM
I hooked up a Ricoh copier on our mixed Linux/Windows network. I installed the PPD from on our print server, and used the Windows CUPS driver on our Windows computers, giving the CUPS address at the print server as the http address of the printer. All capabilities of the PPD are available to Windows users. We have been quite happy with all our Ricoh products, both copiers and color lasers.


Multifunction copiers in a Linux network

Posted by: Anonymous [ip: unknown] on March 14, 2008 07:59 AM
We use a Brother MFC-8860DN in our network, we can scan, print, use LDAP, even faxing is working (we first need to create a PS-file and the send it). It is a great machine an for use in SOHO environment.


Maybe a Linux Project to replace Firmware/OS with standard stuff (askerisk-like, hylafax, etc)

Posted by: Anonymous [ip:] on March 14, 2008 02:13 PM
Maybe this would work.
A Linux Project to replace Firmware/OS with standard stuff (askerisk-like, hylafax, etc),
then you could have a remote admin tool to control the multi-function system better?

Like the Linksys routers, that you can replace with firmware that will allow for VIOP traffic to have dedicated bandwidth, maybe it is time for folks to start hacking these copiers too?


Multifunction copiers in a Linux network

Posted by: Anonymous [ip:] on March 14, 2008 07:39 PM
Samsung supports GNU/Linux.
I have a Lexmark MFP X215 which came with Windows drivers only.
Fortunately Samsung has similar MFP to Lexmark's and Samsung's driver works with X215 under GNU/Linux.
That is why Lexmark sucks and if I'll buy a new printer/MFP/whatever it will be Samsung.


Re: Multifunction copiers in a Linux network

Posted by: Anonymous [ip:] on March 17, 2008 03:14 PM
Hi there,

I work for Lexmark, with the user interface group for MFPs + the embedded website. Currently, I am putting together user survey for the website redesign and would like to get your feedback. Would you mind giving me your email so I can send you the survey link ?


Windu -


What about backups?

Posted by: rigius on March 17, 2008 09:52 AM
We do also have a Ricoh copier and it's really a nice machine. Nevertheless, there is something that is missing: backups. Apparently one can't easily make a backup of the configuration once the machine is correctly configured. We had a hard disk failure several months ago and we had to fully reconfigure the copier by hand when the disk was replaced.


Multifunction copiers in a Linux network

Posted by: Anonymous [ip:] on March 19, 2008 06:43 AM
We spent big bucks on a Kyocera Mita copier with network print and scan capabilities only to find out that (a) the scanner uses a proprietary protocol which requires software running on an NT or Windows 2K server as a scanner manager and (b) the PCL/PostScript emulation is flakey and on complex jobs the unit locks up or reboots.

We received NO SUPPORT WHATSOEVER from Kyocera Mita -- they couldn't care less.

Things may be better now but we'll never buy another Kyocera Mita unit.


This story has been archived. Comments can no longer be posted.

Tableless layout Validate XHTML 1.0 Strict Validate CSS Powered by Xaraya