Ticketed Print Monitoring System
Samantha
Abstract
Implement a monitored print server in CUPS to allow graduate students and faculty to print to a network of laser printers with a ticketed system hooked up to a monitor server with a front end GUI available on all platforms. This is in order to set printing limits and to meet budget constraints on toner and paper.
Additional Information
GSOC Goals Outline
Research Competitors Projects and CUPS
PaperCut and PyKota – had a chance to install and mess around with PaperCut, a closed source solution that costs around $2000 for a reasonably sized business. Very robust, almost exactly what I’m doing, has a few features such as web print that could be a security problem, integrates with Kerberos which is also a problem since Kerberos is ancient and hard to deal with. I got a few ideas on how to go about reporting, and they solved a few issues such as the SQL database getting too large due to storing print jobs. PaperCut was an excellent solution, and easy to set up. I did not check out PyKota because it seems like PaperCut should be what I am aiming for, and for being “opensource” PyKota charges $25 to use.
CUPS – Installed a simple CUPS server on a local machine just to poke around, CUPS has changed amazingly since I had last used it, the update from 1998 Geocities design has me amazed. Good effort OpenPrinting! Once again I am running into Kerberos, it’s like everyone wants me to use this awful convoluted platform. It seems to have a rudimentary accounting system and a good idea of where printers are at, although it seems to venture out into the huge ASU network without asking me to set printers in the department instead. That’s probably not a good thing and will be an issue later. I like the idea of RSS feeds, however, I’d like to tailor that a little more. The Jobs section should be customized and able to sort a little more, as do the printers. That functionality should be easy to add.
Job Monitoring and Printer Networking
Detailed System – Cups asks for the rudimentary details, who sent this, how many pages, what is the title of this document, but I’d like to ask for a little more to be monitored, like size, file format, and what time was it sent and to what printer.
SQL Database – I think I’m going to need two of these set up, one that stores the users, and another that stores the print jobs, a good idea for the print jobs is to have them be sent periodically to a text file to trim down the database size and let it only keep a running sum per user. This is going to take a lot of research to make it balance correctly without creating huge databases in the future. All Print jobs need to be processed through the database before seeing a printer so that no one can sneak around their quotas.
User Database – The user database must be easy to use, easy to monitor and easy to edit, for example, I want the admin to be able to adjust quotas easily, probably by a sliding bar.
Print Database – Needs to be set up to auto back up, and keep rolling tallies of the prints that come through it, it’s going to be accessed a lot so it needs to be fast and should cross reference with the user database. Will be the basis for admin reports, will be accessed for the web interface as well.
Web Interface
Admin Area – On login will see a feed of all current print jobs, the status of toner and paper of printers in his network, if any errors etc. Will have access to a table that shows the users and how close they are to print limits, will be sortable by user or number of pages printed. Options to add remove users and printers, see overall amount of pages printed, options to print out reports or to send reports through email. Might expand this to include some other options.
User Area – On login will see list of available printers, with options to see current queues for the printers, and download drivers for these printers. Will have a bar at the top to show how close they are to hitting their quota, if any. Thinking about including a floor plan with a map for the printer display. I also want to give them the option to ask for email alerts for their print job when it’s done at the printer, and the option to plead for a higher print limit. Might need more options, will come back to this later.
Implementation Stage
Testing – The initial test environment will involve the server and one networked printer and two test accounts, one admin and one user. The testing environment is currently Ubuntu 10.10. The SQL server will be tested for quickness, and the server tested for the ability to hold a large spool (preferably a large PDF) or ten regular sized documents.
Phase II – The server will be deployed to a testing environment of twenty graduate students for two weeks, letting them loose on it to see if any problems occur cross platform or when handling large amounts of jobs at once. The pool of students will be reporting bugs as the phase goes along
Phase III – The server will finally be deployed to a network of twelve printers and a userbase of around one hundred. A “REPORT BUG” feature will be added to the web interface for the user, and then it will be officially released after two weeks in this environment.
Code samples
| File name | Size | Date submitted |
|---|
