<
You are here: Installation > Installation on Linux (CUPS and Samba) > The installation process

The installation process

The Linux version of PaperCut MF is supplied as a pre-compiled self-installing application. The installation process is designed to work with all major Linux distributions. Due to the varied nature of some installations and administrator preferences, often some manual configuration is required. This section describes the installation process in detail as well as some additional options available to SysAdmins.

Manual extraction

The Linux version of PaperCut MF is supplied in a self-extracting, self-installing archive. The archive is a tar archive compressed with gzip, and headed with a shell script to facilitate self-extracting. After extraction is complete, the installation script named install is executed to begin the install process. Some SysAdmins might want to inspect the contents of the archive, and possibly the installation process itself prior to the actual install. The self-extracting installer takes a number of command line arguments. The -e argument extracts the archive into the current working directory ready for inspection. Further options and documentation is available via the --help option.

Usage: pcmf-setup.sh [-e|-i|-l] [-v] [-n] [list ...]

 

-e

Extract the files and then exit without installing.

 

-i

Install after extracting the files (default).

 

-l

List the contents of the archive and exit without extracting.

 

-v

Verbose. Print the names of the files as they are extracted.

 

list

The list of files to extract."

The install process

Even though the majority of the installation process is completed under the identity of the non-privileged user account called papercut, most administrators want to know what the install process does. The main steps are outlined below:

Extraction

The first stage in the install process extracts the archive to /tmp or a location as defined by an environment variable TMPDIR. The command-line programs tar and gunzip are used during this phase.

Installation

After extraction is complete, the installation script is called. The install script, called install, presents the EULA and request acceptance. The script then determines the install location. This is the papercut user's home directory. The home directory is determined by the HOME environment variable, or if not set, the result of a call to getpwnam().

Files are then copied into the papercut user's home directory. Care is taken not to overwrite any existing data or configuration files if this is an install-over-the-top upgrade.

Permissions

To ensure the default installation is secure by default, permissions are applied to key files. The following area of the application are restricted to the papercut user only:

Table 6: Secured Application Areas
AreaComments
~/server/server.properties Contains server configuration including the default admin password.
~/server/data This directory contains application data including database files. Some of this data might contain sensitive information.
~/server/bin/linux-[x64|i686] This directory contains a setuid-root binary. Even though the binary is no use to an end user or hacker, good security practice stipulates that you should allow only the papercut user access to this directory.

You can check and reapply permissions at any time post-install by running the scripts:

~/server/bin/linux-*/setperms

~/providers/print/linux-*/setperms

Firewall

The PaperCut MF Application ServerAn Application Server is the primary server program responsible for providing the PaperCut user interface, storing data, and providing services to users. PaperCut uses the Application Server to manage user and account information, manage printers, calculate print costs, provide a web browser interface to administrators and end users, and much more. (pc-app process) listens on port 9191. This port is used for browser based administration access, for client access, and other services. Ensure that any firewall or local IP filtering software such as iptables is set to allow local network traffic access to this port.

Root level tasks

A small part of the install process needs to run as the root account. The tasks conducted as root include:

If the administrator decides not to run the root-level tasks during the install process, the tasks can be run again post-install by executing the shell scripts:

~/server/bin/linux-*/roottasks

~/providers/print/linux-*/roottasks

Alternatively the administrator can view the scripts and make the required changes by hand.

Linux print queue integration

PaperCut MF is able to integrate with and monitor CUPS, SambaSamba is a Windows interoperability suite of programs for Linux and Unix. It is used to integrate Linux/Unix servers and desktops into Active Directory environments. It can function as both a domain controller or as a regular domain member. and Novell iPrintiPrint is a technology developed by Novell that allows users to install printer-drivers from a web browser and to submit print jobs over the Internet or a local network through the standard Internet Printing Protocol (IPP). Common desktop operating systems such as Windows, Linux, and Mac support iPrint. based print queues. The configuration and an explanation of the integration methods follows:

CUPS configuration overview

If the print queues are managed and controlled via CUPS, modify the Device URI on each printer so the papercut backend is incorporated into the print process. To automate this, run the configure-cups script as root (the simplest option):

~/providers/print/linux-*/configure-cups

and follow the interactive instructions. Alternatively, you can do it manually via the CUPS web Admin web interface or by editing the CUPS printers.conf file:

  1. Open printers.conf (e.g. /etc/cups/printers.conf)

  2. Prefix the DeviceURL for each printers with "papercut:". For example:

    DeviceURI socket://192.168.1.200:9100

    Would become:

    DeviceURI papercut:socket://192.168.1.200:9100

  3. Restart cupsd so the new configuration is detected (e.g. /etc/init.d/cupsd reload)

CUPS integration explained

CUPS, the Common UNIX Printing System, is a popular system for managing printers on Linux servers. CUPS uses a chain-of-commands concept where filtersFilters allow you to control attributes of the print settings by either forcing a particular attribute or denying a a print job that does not meet specific criteria. There are two types of print filters: conversions and restrictions. and backends combine together to form a process steam - a workflow. PaperCut MF hooks into this workflow at the backend level, intercepting the job before it's passed on to physical printer hardware.

The interception is done by wrapping or proxying the real CUPS backend. CUPS calls the PaperCut MF backend, which processes the job. If the job is approved, it passes the document onto the real backend. If the job is denied, it is deleted and proceeds no further. The PaperCut MF backend is usually set up and installed by default during the standard installation.

Setting up the PaperCut MF CUPS backend proxy is a relatively simple task. All the administrator needs to do is prefix the existing DeviceURI with papercut:. For example, the entry:

DeviceURI socket://192.168.1.200:9100

would become:

DeviceURI papercut:socket://192.168.1.200:9100

The printer registers itself with PaperCut MF on the first print event.

PaperCut MF CUPS architecture

The PaperCut MF CUPS backend is a native compiled binary. In PaperCut MF documentation it is referred to it as a Print ProviderA Print Provider is a monitoring service installed on a secondary print server to allow PaperCut to control and track printers. This monitoring component intercepts the local printing and reports the use back to the primary Application Server. - a component that provides print event information to the Application Server. It's responsible for analyzing the print job and then communicating this information to the Application Server component. Communication is via an XML-RPC based Web Services call. This means that the backend does not need to be on the same server as the system hosting the Application Server component.

Samba configuration overview

If the print queues are exposed to network workstations using Samba (Samba Website), and a print system other than CUPS is used (e.g. BSD, LPRNG, SYSV, etc.) the smb.conf needs some additional configuration. The "print command" needs to be replaced with a PaperCut MF command.

  1. Open the smb.conf (e.g. /etc/samba/smb.conf)

  2. Under the [global] section insert the line:

    print command=/home/papercut/providers/print/linux-i686/samba-print-provider

    -u "%u" -J "%J" -h "%h" -m "%m" -p "%p" -s "%s"

    -a "[standard print command]" &

    Important:

    The above information is displayed on a single line. Note the use of the & (ampersand) on the end of the line.

    where [standard print command] is the command that would normally called for printing. Typical examples of commands usually used for printer are listed below:

    Table 7: Standard print commands
    Type Command
    BSD, AIX, QNX, LPRNG or PLP lpr -r -P%p %s
    SYSV or HPUX lp -c -d%p %s; rm %s

    More information on standard print commands is available under the Samba documentation installed on your system (see man smb.conf).

Samba integration explained

Samba is used to provide file and print sharing to Windows systems and is a popular solution. One of the main reasons for its popularity is that it avoids the need for expensive Microsoft Windows server licenses!

Samba exposes the locally set up Linux/Unix printers as network shared Windows printers. It does this by wrapping the underlying print system - usually CUPS or LPRThe Line Printer Remote protocol (LPR) is a network protocol for submitting print jobs to a remote printer. A server for the LPD/LPR protocol listens for requests on TCP port 515. A request begins with a byte containing the request code, followed by the arguments to the request, and is terminated by an ASCII LF character. An LPD printer is identified by the IP address of the server machine and the queue name on that machine. Many different queue names may exist in one LPD server, with each queue having unique settings. The LPR software is installed on the client device./LPDThe Line Printer Daemon protocol (LPD) is a network protocol for submitting print jobs to a remote printer. A server for the LPD/LPR protocol listens for requests on TCP port 515. A request begins with a byte containing the request code, followed by the arguments to the request, and is terminated by an ASCII LF character. An LPD printer is identified by the IP address of the server machine and the queue name on that machine. Many different queue names may exist in one LPD server, with each queue having unique settings. The LPD software is stored on the printer or print server.. In the case of LPR, Samba calls the standard lp command line programs to perform printing. PaperCut MF works by wrapping or proxying the "print command". More information on how Samba interacts with the underlying print system is available in the Samba documentation.

A typical entry in the Samba configuration file smb.conf defining the PaperCut MF print command wrapper would be:

print command=/home/papercut/providers/print/linux-i686/samba-print-provider

-u "%u" -J "%J" -h "%h" -m "%m" -p "%p" -s "%s"

-a "[standard print command]" &

Important:

The above information is displayed on the one line. Note the use of the & (ampersand) on the end of the line.

where [standard print command] is the command that would normally be called for printing.

The %u, %p, etc., are Samba substitution variables. These are replaced with content such as the username, printer name, etc. and are used by PaperCut MF in the reporting and logging.

The printer registers itself with the PaperCut MF web interface after the first print is received.

PaperCut MF Samba architecture

The PaperCut MF Samba print command wrapper is a native compiled executable. The PaperCut MF documentation refers to it as a Print Provider. It's responsible for analyzing the print job and then communicating this information to the Application Server component. Communication is via an XML-RPC based Web Services call. This means that the command does not need to be on the same server as the system hosting the Application Server component.

Novell iPrint configuration

PaperCut MF works by directly integrating with the Novell iPrint Print Manager.

The configuration process is detailed in Step 5 - Printer/iPrint configuration.

The development team at PaperCut Software has worked with the Novell iPrint engineers during 2008 to ensure an iPrint APIApplication Programming Interface (API) is a set of routines, protocols, and tools for building software and applications. An API expresses a software component in terms of its operations, inputs, outputs, and underlying types, defining functionalities that are independent of their respective implementations, which allows definitions and implementations to vary without compromising the interface. was available that allow iPrint users to have access to the same feature set as seen on Windows, Mac and Linux CUPS. PaperCut MF uses this API set to intercept and account for jobs as they pass into the iPrint queue.