Linux print server enhances library printing

703

Author: Heidi Wessman Kneale

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.

Categories:

  • Case Study
  • File & Print Services