This is a read-only archive. Find the latest Linux articles, documentation, and answers at the new Linux.com!

Linux.com

Feature: Case Study

Linux print server enhances library printing

By Heidi Wessman Kneale on November 07, 2008 (7:00:00 PM)

Share    Print    Comments   

My employer, Warnbro Community Library in Western Australia, had a problem with wasted paper from printing. Library patrons often sent unnecessary print jobs to the printers, then refused to pay for them, leaving reams of unclaimed paper. The library needed a print queue to enable library staff to control patrons' print jobs. It needed to be easy to set up and maintain and cost nothing. We found the answer in using Linux as a print server.

Our public network consisted of a simple local area network with 15 Windows clients connecting to the outside world via a dedicated proxy server, and one networked Hewlett-Packard LaserJet 5200. As there was no budget to purchase any special server hardware or software, that left out the option of a dedicated Windows print server, which in any case would have been overkill. But we has an old Compaq desktop computer in storage with a 40GB hard drive and 512MB of RAM, which was powerful enough to run Linux.

Though I'm the on-site computer support person, I wasn't a Linux guru, so I wanted to choose a distribution that was easy to load and easy to tweak. After a bit of research, I chose the Ubuntu-derivative Linux Mint for its size and its friendly GUI.

Configuration

Once I had Mint installed on the hardware, I chose to configure the print server through Samba. To configure Samba, I installed the Samba Web Administration Tool (SWAT), as it didn't come natively installed with Mint.

SWAT not only lists possible options for Samba's smb.conf file from an interface that includes radio buttons and Yes/No options, but it also features context-sensitive help. SWAT replaces the default smb.conf file with one of its own making, thus removing any original comments placed therein, but since no one would be fiddling directly in the conf file, this was acceptable. I could access SWAT via a Web browser interface from any computer on the network, and connect to the print server, which I named Starlight, via https://starlight:901.

I added the network printer via a file share and set it to allow sharing and make the printers printable. Samba.org has an excellent how-to manual explaining classical printing support. In my smb.conf file I set up the following print option parameters:

printing = cups cups option = raw, job-hold-until-indefinite

I set printing as Common Unix Printing System (CUPS) because I wanted to use a Web browser interface to control print jobs from the circulation desk. Under cups option I configured the first parameter to use raw spooling because the drivers installed on each Windows workstation did all print job processing for us.

The second parameter, job-hold-until-indefinite, is the crucial one. It tells the print queue to hold all print jobs until manually released -- the whole purpose behind our setting up of a print queue.

Administrating the print queue

Once we had our smb.conf file properly configured, we could add and manage printers, classes, and jobs through CUPS from a browser via https://starlight:631. I chose to go in via a secure connection because otherwise CUPS wouldn't let staff manage jobs. To give staff full use of CUPS, I set up a generic login on the server that had administrative rights over printing (and little else).

Under the Administration page in CUPS we added our printer as attached to the print server. I then installed the printer on each workstation as a local printer with a TCP/IP port connecting to Starlight. I chose that configuration when I found that if I tried to connect to it as a network printer, print jobs disappeared into cyberspace.

The staff now accesses the CUPS Web interface at a circulation desk computer. Every print job sent to the printer shows up here. Each job listing shows the user who sent the job, the name of the document, and a time stamp. Each job has a green "release job" button. The job will not print until this button is clicked. In practice, a library patron sends a print job, then comes up to the circulation desk and tells library staff what computer they printed from and how many print jobs they sent. A staff member then releases all wanted jobs and cancels any unwanted jobs.

The only information CUPS doesn't display properly is the number of pages. Held jobs list a page count as "unknown"; after a job has gone through, the page count lists as "1." This is because the print queue handles only "raw" files, leaving them untouched and unprocessed. Allowing a print file to pass the CUPS pstops filter could solve this problem, but the filter doesn't pass certain files (such as some image files) properly. Since listing incorrect page amounts would cause more problems in our customer service environment than not listing any, we chose to stay with a raw queue and manually count the pages as they are printed so we can charge for them.

Problem solved!

Both library staff and patrons love the print queue system. Before we installed the print queue, library patrons wasted reams of paper, and hundreds of pages went unclaimed every day as patrons refused to pay for unwanted print jobs. Sometimes sensitive information from one patron, such as bank statements, would find their way between two jobs belonging to another patron, and if every page of a print job were not properly checked before being handed over, this information ended up in a stranger's hands.

Now, only wanted jobs are released and paid for. Jobs are released on demand and don't get mixed up with the jobs of other patrons. Jobs are handed to patrons as soon as they are printed, thus ensuring privacy.

Thanks to Linux, Warnbro Community Library was able to set up a simple print queue with a budget of zero using an old computer from the storage room. The paper usage through the public printer has been cut by nearly half and patrons receive (and only pay for) wanted jobs. It's a win all around.

Heidi Wessman Kneale has worked in the IT industry for nearly 20 years. Except for a brief stint in a dotcom, she has worked in schools, libraries, or, most often, school libraries.

Share    Print    Comments   

Comments

on Linux print server enhances library printing

Note: Comments are owned by the poster. We are not responsible for their content.

Linux print server enhances library printing

Posted by: Anonymous [ip: 71.34.47.5] on November 08, 2008 05:19 AM
I used the same strategy for my 25 iMacs lab (dual-boot OSX and XP). However, at the time I setup the print station with Ubuntu (a year ago), the PAUSE functionality in CUPS didn't work very well, and it doesn't show how many pages in the document before actual printing (we need to make sure students have enough money before printing).

I setup a fake print queue and stop it so that all jobs have to be moved manually to the real print queue. I also modified the CUPS source code a little bit, utilizing pkpgcounter tool (http://www.pykota.com/software/pkpgcounter/) to count the number of pages before printing. Also, clicking on the job name will open the raw (PS) file to print with Preview (OSX) in case the print job couldn't go through.

One glitch in CUPS 1.3.8: if the remote print queue is paused or stopped, the local print queue is stopped too, this make the lab computers hold all subsequent print job. Version 1.3.9 fixed this, but OSX 10.5.5 doesn't have the update yet. You can download the CUPS 1.3.9 binary package here:
http://web.mac.com/a.ramos/Als_Blog/Macintosh_Digest/Entries/2008/10/13_CUPS_1.3.9_has_been_compiled_and_uploaded..html

I should try the PAUSE feature in new CUPS some times.

in case you want my modified source of CUPS: ho_a__ng__027_@_um_n._ed_u (kill underscores)

#

Linux print server enhances library printing

Posted by: Anonymous [ip: 192.168.1.253] on November 09, 2008 08:17 PM
Note that CUPS make all printers look like a postscript printer. So if you would install the printer driver on the print server, then you can choose a generic postscript printer (Any Apple Laser printer) on the Windows machines.

This is a simple trick to make print configuration easier.

#

Linux print server enhances library printing

Posted by: Anonymous [ip: 68.19.214.133] on November 10, 2008 04:11 AM
Wish I could find an open source print costing system for Linux that would work with a vending unit. My library uses an expensive and rather buggy proprietary system at the moment.

#

Re: Linux print server enhances library printing

Posted by: Anonymous [ip: 192.168.5.194] on November 29, 2008 03:15 PM
Which one are you using? We have PCCop - it should be called PCCrap. It is always mis-counting pages and otherwise screwing up. We have begun to work on a system to replace it, using autoit for the client on the pc's and the backend will be linux. The client is pretty much done - it uses Redmon EE to generate a postscript file, using the ghostscript print driver. It calls an autoit script that searches the ps file for page count and copy count. A GUI is presented to the patron, and when the patron agrees to print, the file is SCP'd to the server. All that is working now. I am working on the web front end for our staff interaction.

I have no access to a coin/bill acceptor to create a patron self-pay system. Anybody know anything about interfacing with one?

Thanks -

LibraryMark

#

Linux print server enhances library printing

Posted by: Anonymous [ip: 67.60.95.83] on November 10, 2008 06:17 AM
You probably already know this but you don't need to keep your graphical environment running for your print server. You may find it a bit snappier than you expected but if it gets loads of print jobs all at once that GUI could cause some slowdown. All configuration can be done from any client in the network using the web interface. You can also use it to print over the internet. Very spiffy if you have multiple office locations.

#

Linux print server enhances library printing

Posted by: Anonymous [ip: 10.0.0.8] on November 12, 2008 11:59 PM
Indeed it is extremely spiffy. We use CUPS to power our online shopping cart for restaurants. Customers select what they want and which location to pick up deliver from, and items print out on labels in the shop usually within 5 seconds of the user pressing Submit.

Now we got the remote print server locked down pretty tight, I can only access the online interface if I'm SSHed into the box using Lynx, but so far we handling 400 - 500 online orders a day without a hiccup. And there is only once glitch that we know about, but that is due to the label printers not accepting the Form Feed command.

#

Linux print server enhances library printing

Posted by: IT WHIZ KID on November 13, 2008 06:12 PM
Indeed the article is extremely spiffy. The only question that I have is the selection of pages for each print job. In your article, you stated the following:

"The only information CUPS doesn't display properly is the number of pages. Held jobs list a page count as "unknown"; after a job has gone through, the page count lists as "1." This is because the print queue handles only "raw" files, leaving them untouched and unprocessed. Allowing a print file to pass the CUPS pstops filter could solve this problem, but the filter doesn't pass certain files (such as some image files) properly. Since listing incorrect page amounts would cause more problems in our customer service environment than not listing any, we chose to stay with a raw queue and manually count the pages as they are printed so we can charge for them."

There are two questions:
1. Is there a way to create a filter to allow for image files?
2. Does CUPS have a function of creating a page count? Since you are talking about sensitive info & reducing the amount of wasted paper, I would think that this feature would be vital.




#

This story has been archived. Comments can no longer be posted.



 
Tableless layout Validate XHTML 1.0 Strict Validate CSS Powered by Xaraya