Queue Release System

Overview

Various departments provide free printing within the studios for their students. The printing provided includes both plotter and laser printing.

Due to sky-rocketing costs, we had to look into some mechanism by which we can both audit and control printing.

The first step of the printing solution was to convert all of the students in the studios from the direct HP JetDirect Port based printing to some form of queue based printing. This would give us the ability to configure print queues to be on hold, and restrict/authenticate who releases a print job.

We use SAMBA to provide Microsoft Network Printer Shares for the students in the studios. More information on configuring clients for the SAMBA based printing can be found at the IT Center Printing Page.

Once we converted the students, the next step was to implement an auditing system. Initially, I was going to use LPD to dump all print queue jobs to a Netware based queue, then use PCOUNTER.NLM in conjunction with the CIRCA developed print release system, to track all print jobs that were released.

However, after a lot of consideration, I concluded that this would be a very bad idea because it adds extra levels of complexity, namely:

The system would require extra software running on our Novell Server.
The system would require an external PC in each room with a printer running custom software. If the PC broke, all printing would cease.
The system would require print queues on our Novell server.
The system would require that each printer be reconfigured for Novell queue based printing.

The concept added unnecessary layers of complexity, and if any of the additional components broke, then the whole system would cease to function. Since there was no reason to add complexity to the system, especially at the risk of stability, an alternative solution needed to be investigated and/or developed.

The completed system was developed in house using perl and the GLcgi.pm (Gatorlink Cookie) module developed by Mike Wright at CIRCA.

The queues are configured to hold all print jobs until explicitly released. After a student has printed a job to the queue (via SAMBA), they must explicitly release the job through a web-interface. When a job is released, the system logs the activity.

Although the LPRng printing system offers excellent print job reporting capabilities, we're only logging print job releases and the byte count of the job. If at a future point in time we decide we need more detailed information, such as the printed page count or coverage areas, with LPRng we can add that functionality.

How does it all work?

Back end -> Students print to a queue via a public Samba Share. Samba spools the job to an LPR (LPRng) queue which is configured to hold all jobs. When a job is selected to be released by the CGI, lpc is used to release the job, and the event is logged. LPC has the ability to release jobs by a rights assignment in the /etc/lpd.perms file, so no special rights are needed for the cgi (it runs as nobody).

Front end -> Student submits print job via Microsoft Networking (Samba). Student then authenticates to the system via a Gatorlink cookie, and selects the print queue to release a job. The student is then given a list of all print jobs in the system, and he selects the print job he would like to release. Once the job is selected to be released, it is tagged for print and the printer will print the job.

Any job not released will be automatically removed at 3:00am by a cronjob that runs lprm to remove all jobs held in the queue.

Configuring a Queue

The process of configuring a queue for use with the system is straight-forward and simple.

Step 1: Configure the Print Queue for SAMBA and LPD.

Step 2: Edit the configuration to put all jobs on hold. You will need to edit the file /etc/printcap on GAUDI and add the "ah" flag to the queue configuration. For example, if you were configuring the queue "arc-314-dj" to work with the print system, you would change the /etc/printcap entry from:



###add-smb-printer script added Wed Oct  3 12:48:53 EDT 2001
arc-314-dj:\
	:sd=/var/spool/lpd/arc-314-dj:\
	:mx#0:\
	:sh:\
	:rm=arc-314-dj.dcp.ufl.edu:\
	:rp=:\
	:bkf:\
	:if=/var/spool/lpd/filter/filter:

To:



###add-smb-printer script added Wed Oct  3 12:48:53 EDT 2001
arc-314-dj:\
	:sd=/var/spool/lpd/arc-314-dj:\
	:mx#0:\
	:sh:\
	:ah:\
	:rm=arc-314-dj.dcp.ufl.edu:\
	:rp=:\
	:bkf:\
	:if=/var/spool/lpd/filter/filter:

Please note the addition of the ":ah:\" tag underneath the ":sh:\" tag.

Step 3: Add printer entry to /opt/www/data/printers.txt. All printers used in the queue release system must also have an entry in the file /opt/www/data/printers.txt which contains the name for the print queue. Although we could just as easily generate the queue list based strictly on which queues were configured for auto-hold, we decided that having a seperate control file provided greater flexibility. Use your favorite text editor to add a one line entry with the queue name to the file.

Generating a Queue Report

In order to view summary data on the print queues, please run the script at http://gaudi.dcp.ufl.edu/tools/repjobs.pl. You will see summary data for all users and queues in the system. From there you will be able to select a specific queue (audit all jobs released on it) or a particular user (all jobs released by a user).

Blocking Release Job Access

There may be users that take advantage of the free print and will need to have their print job access control culled. Blocking a user from having the ability to print is a simple task.

In order to block a user from being able to release a print job, edit the file /opt/www/data/restricted.txt and add a line with the users gatorlink id. Although the system is insensitive to case, we encourage lower case characters for the data file (they look nicer!)

If you decide to grant a user print job access again, it's a simple matter of removing their entry from the restricted users file.

Ken Sallot, 10/8/2001