Queue Redirection - An example in Linux
Last modified on 13 August 2020 09:44 PM
There are a number of cases where it is advantageous to have print jobs from one server, redirected to another server. This is typical for sites with AS400 servers or other hosts where it’s either not possible or desirable to have the PaperCut Print Provider installed on these machines. In these cases, we suggest that queues are redirected to a server which is hosting the PaperCut Print Provider for accountability. The method we will use, called LPD printing, isn’t limited to this case. It’s a handy trick to get Windows jobs to Linux, Mac jobs to Windows, or allow users that may not be authenticated against a domain to submit print jobs to an otherwise secured server.
This example is about solving a printing problem. Once the printing problem is solved, we then use PaperCut to solve the accounting problem, and to provide visibility and service to our customers.
For this queue redirection example let’s set the scene: Scenario A
Our goal is to position a Linux server in between the AS400 server (played by the role of windows) and the printer, so jobs can be accounted for that are sent from the AS400 server to the printer Scenario B.
Run up a Linux box
The first step is to build our Linux box. If this is new to you, it’s not as daunting as it sounds. In this case I’m using Ubuntu. At the time of writing this, the current build of Ubuntu supports CUPS straight out of the box, so establishing a Linux print queue that services this device is trivial. Just run the installer selecting the default options along the way.
Install a CUPS Printer
Like PaperCut, the admin of CUPS is managed via a Web UI. From the Ubuntu server, this is simply accessed using the URL;
Ubuntu even ships with FireFox as a browser, something most Windows users will be familiar with. Add a printer by navigating to Administration >> Add Printer where you will need to authenticate with the username and password you configured when installing the Ubuntu OS (and used to login to the desktop).
You may get lucky, and the Printer may appear in the list of Discovered Network Printers . If so, skip ahead to the next section, or follow through with this how-to and we’ll continue to set this printer up manually.
In the Other Network Printers section, we can follow a familiar process of creating a port, naming a printer, sharing a printer and so on.
The resulting form will allow you to use a drop down box to Print Self Test Page. Hopefully you’ve just created a CUPS queue.
Return to the Administration page of the CUPS Admin UI and tick Share printers connected to this system and be sure to click Change Settings to save this change.
The LPD protocol we will use for the CUPS server to accept jobs as if it were a printer requires an additional service listening on port 515 to be established. The current distribution of Linux I used didn’t have this service installed by default, so the following process enabled this.
Redirect the AS400 queue
At this point, the Linux print server is ready to accept jobs via the LPD service. A quick test of port 515 on this server from another machine will validate this. We can now redirect the existing AS400 queue (played by Windows) to print to this server as if it were a printer.
(Note: if you’re repeating this on a Windows machine playing the role of the AS400, check LPR Byte Counting Enabled)
LPD printing bypasses all authentication requirements for printing. The LPD server will simply accept the jobs on port 515 and direct them to the appropriate queue. This can be a positive or a negative depending on the context. In the case of the AS400 server, it’s a positive as the jobs will likely be owned by a username not recognised by the sites domain. We wouldn’t want these jobs to be denied because of this. In the context of a PaperCut deployment, it’s important to keep this in mind so as to not send these jobs to a hold/release queue if there is no way for these users to then release these jobs. It may pay to consider creating an OurPrinterAS400 queue which services jobs from this environment exclusively. Jobs submitted to this queue can be charged to a default Shared Account. This will ensure printing is unimpeded though still accounted to an appropriate department/matter/account/code.
More advanced implementations may consider using username aliasing or extracting usernames from the spool file itself where enterprise systems such as SAP may store this information in the document itself.