Queue Redirection - An example in Linux

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 We have a printer in the office with the IP address of 10.100.64.32 We have a print server configured to send jobs to this MFD via a queue called OurPrinter. This server has the IP address of 10.100.66.6. This implementation is a Windows server, playing the role of an AS400 server. 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. Process 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; *http://localhost:631 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. In Other Network Printers, I’m going to create an LPD/LPR port. This is how I’ll connect to the printer. All other options are equally valid. The next Add Printer form asks us to create the port as a URI. Helpful examples are given, so I’ll follow the example that suits the information I have and create the port; *lpd://hostname/queue *lpd://10.100.64.32/9100 Why 9100? This is the port printers typically listen on. This is easily validated for this printer using the Configure Port button on the Windows queue. Name the printer, omitting spaces in the name of the printer. Some systems don’t like port names with spaces in them, so it’s good practice to omit them. I’ve chosen OurPrinter to match the name of the queue on the AS400. Follow the rest of the workflow to choose the printer make, the driver any feature information (trays, finishers etc). 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. Install xinetd 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. In Unbuntu, open a Terminal ; akin to the command line for the Windows users out there. Run the following command to install the xinetd service: sudo apt-get install xinetd You will be prompted for your password to kick off the installation process. Personally, I find a graphical text editor easier to work with, so I then run sudo gedit to access the text editor with sufficient privileges for the next task. Paste the following text into the editor service printer { socket_type = stream protocol = tcp wait = no user = lp group = sys server = /usr/lib/cups/daemon/cups-lpd } and save the file as: /etc/xinetd.d/printer Close the editor to return to the terminal console and restart this new service. sudo /etc/init.d/xinetd restart 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. First, we need to note the IP address of the Ubuntu server if this isn’t known. Run the command ifconfig in a terminal window on the Linux print server to get this information. On your AS400 server, either create a new port or alter the existing port for the queue to have the updated information of; Printer IP = Ubuntu server IP Printer Port = Queue name in my example that is Printer IP = 10.100.66.121 Printer Port = OurPrinter (Note: if you’re repeating this on a Windows machine playing the role of the AS400, check LPR Byte Counting Enabled) Jobs will now be sent from the AS400 server, via the Linux box en route to the Printer. If the Linux box has PaperCut installed, you will have accountability and visibility of these jobs. A Test Print will validate this, and the CUPS Web UI should show these AS400 jobs in the job log (check the Jobs » Show All Jobs page). Further considerations 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.