Cover V11, I02



Web-Based Printer Management

Brett Lymn

Some years ago, pundits predicted that there would soon be the paperless office -- an office where all communications and reporting would be performed electronically without consuming paper. At the time of this writing, I see little evidence of this happening, but I have seen the opposite -- more printers with more capabilities are being added to the office. The burgeoning printer population can be problematic for administrators when users want help removing print jobs from the printer queue.

On a UNIX system, users can kill their own print jobs if they have the correct tools and know-how. Unfortunately for the administrators, users sometimes can't kill the jobs without help (e.g., a user may be locked into an application and have no way of removing the print jobs). The printer problem becomes amplified when you have back-end services running on multiple machines talking to various printers, or a sys admin who may not be able to immediately kill a print job.


One approach to the problem is to use something such as sudo (a program that can allow specific users to run specific programs as root) and give select users the ability to remove jobs from the print queues. This requires that the users with this access have the technical skills to find the right machine, find the offending job on the print queue, and kill it. Unfortunately, even when this task is scripted, most people view the process as somewhat cumbersome. Additionally, if you have many back-end database servers, you will need to grant the people managing the print queues access to the machines and also set up sudo to allow them to kill the print jobs. The task of maintaining these privileged users and the associated sudo setup becomes even more cumbersome as the number of back-end servers grows.

Most people are familiar and comfortable with a Web interface, and it makes sense that being able to manage printer queues from a Web interface would simplify printer management. The straightforward approach is to wrap some CGI scripts around the standard lp commands and leave it at that. However, this approach has some problems. One approach is for the Web server hosting the printer management scripts to know about all the printers on all the back-end database servers so that the lp tools will be able to manage them. This, in itself, is a burden because the admin must remember to add the printer not only to the back-end database server, but also to the WWW server. Another problem with this approach is that if you want your Web interface to be able to kill print jobs, you must have a setuid root script or run the Web server as the user to which the back-end databases submit their print jobs. Both of these approaches have major security problems (especially running setuid root scripts from a Web server).

Solaris lpd

With these points in mind, I looked at how I could simplify printer management. I knew from prior experience that the line printer daemon (lpd) could be used to query a remote host about the status of a printer. As stated before, the normal tools require you to have a printer queue set up on the machine but reading RFC 1179 indicated that you could send a specially crafted packet to the remote host's lpd port to inquire about the status of a queue on a printer. This meant that I could get around the requirement of having the printers defined locally by simply talking directly to the printer port on the remote host using the lpd protocol. This lead to another discovery about Solaris.

On Solaris, the standard port for the lpd to listen on is defined as port 515. On a UNIX system, because this port is below 1024, it is considered a privileged port and can only be opened by root. This really only affects the lpd itself; you can connect to the port as a normal user. The quirk here is that some implementations of lpd actually check the port the connection is coming from and reject it if the source port is not the printer port (i.e., port 515). I think this was originally a method of preventing a normal user from connecting to the lpd and manipulating the queue because only root could open the printer port and therefore could be trusted. However, this scheme relied on everyone obeying the rule that unprivileged users could not open tcp ports below 1024. (This is not the case these days, which makes the source port checking a bit pointless.)

The Solaris lpd implementation does not check the source port of the lpd connection and, hence, will allow a normal user to manipulate a print queue via the lpd protocol. In my case, this was an advantage because it meant that I did not need to have any setuid root scripts to manipulate the print queues on my Web server. This could be a nightmare for others because a user with sufficient skills would be able to modify the print queue remotely. Note that you cannot just telnet to the printer port on the remote host and manipulate the queues due to the way the lpd reads the data from the network connection.

Writing the Script

Given that I had now satisfied my criteria, (not requiring the printers local on the Web server and being able to manipulate printer queues without root), it was time to start coding. I already had a Web server running Apache with the mod_perl extension, so instead of doing a normal CGI script, I was able to write one that worked with mod_perl. (See for information on both the Apache Web server and the mod_perl extension.) I wanted a script that took the machine and printer names as arguments and would then query the remote machine for the queue of the given printer. If there were jobs in the queue, then these jobs would be presented in a scrolling list. The user could select the jobs from the list and press a button to remove the jobs.

Some classes are imported to provide the functionality we need. The IO::Socket class is used for the network connection to the lpd on the remote host. The other classes import the necessary parts to deal with HTML and extracting parameters from the arguments passed by the Web server. For the moment, skip over the get_status and cancel_job functions and look at the mainline code. The first important bit is:

my $r = Apache->request;
which creates a new Apache request object holding all the information the server needs to handle requests. When the script has the request, it sends out a standard text HTTP header using:

The browser will now have been sent the header and be ready for the rest of the page. The script then grabs the arguments that were given to it, which is done by importing the names like this:

This imports the variables into the PARAMS name-space, which is a security measure to ensure that command-line arguments cannot be used to overwrite internal script variables. Using the PARAMS name-space, we grab copies of the remote machine name ($print_host) and the remote printer name ($printer). Once this is done, the script outputs the start of the page and starts an HTML form. The script then stashes a copy of the remote host name and the printer name in hidden fields in the page by doing this:

$r->print(hidden(-name => 'hidden_print_host', -default => "$print_host"));
$r->print(hidden(-name => 'hidden_printer', -default => "$printer"));
Apache normally forks multiple copies of itself, because you can't be sure that you are talking to the same Apache process on a UNIX machine when the user hits a form button. This means that keeping state between the generation of the form and the post of the form data cannot be done in the script itself, hence the hidden fields on the form page. Hidden fields are not a good idea in a security critical situation but do the job nicely in this case.

The script then checks whether it has received any values using one of the query submission buttons; more on those later. The script has two buttons to look for -- a delete button and a refresh button. If either of these buttons has been pressed, the script retrieves the value of the remote host name and the printer name from the hidden fields where the script initially placed them. The script just retrieved those parameters from the arguments a few lines ago, but remember that if a button has been pressed, the script is processing a form submission (not generating the original form). Thus, the script cannot trust the original arguments, because they may be for an entirely different machine and printer. When we know the printer and host that the script are dealing with, the script prints a nice heading at the top of the page using:

$r->print(h1("Printer Management For Printer $printer On $print_host"));
The script then checks whether the refresh button was pressed or whether the delete button was not pressed; the latter implies this is the first time the form has been generated, which happens when the user clicks on the link to load the form page. In this case, the script calls the get_status function, which simply opens a TCP/IP connection to the remote host and sends a message to the remote lpd to return a short queue status for the desired printer. The get_status function reads the reply from the remote lpd and puts the results into an array and returns it to the caller. In the mainline code, the script checks the first array entry. If it is empty, there were no jobs in the queue. Rather than printing a blank scrolling list, the script simply prints a message telling the user there were no jobs in the selected print queue. If there were jobs in the queue, then the script generates a scrolling list using:

$r->print(br, scrolling_list(-name => 'job_list', \
          -values => [@jobs], -size => 10, -multiple => 'true'));
The br is simply a line break and is used to position the scrolling list; the actual list is done by the scrolling_list method. We give the scrolling list a name so the script can retrieve the selections later. "values" is the array of jobs that the script fetched using get_status. The list-box has a size of ten lines, and multiple list selections are allowed. If there are jobs, then the script needs a delete button to delete them, which is done with:

$r->print(p,p, submit(-name=>'Delete', -value => 'Delete'));
This inserts a couple of paragraph breaks to space the delete button away from the scrolling list and creates a button labeled "Delete" and a value of "Delete". This is the value passed in the form submission if the button is hit. This is how the variable $button gets the value "Delete" earlier in the script. After the delete button is done, the script skips to the end and puts in a refresh button in a similar manner. It then closes off the form and the HTML page. The form is now rendered by the client browser, and the script waits for the user to press a button. If the user presses the refresh button, the script will go through the process just described, which results in the presented queue entries being updated. If the user hits the delete button then another code path is followed. In the case of a delete being processed, the script first retrieves the selections made by the user by getting the job_list parameter (the name given to the scrolling list) and puts them into an array. The script then processes the list of jobs and parses out the job identifier from the queue entries that were selected. If no jobs were selected for deletion, then the script simply complains and does nothing else. If some jobs were selected for deletion, then the array of identifiers is passed to the cancel_job function, which opens a TCP/IP connection to the remote host and sends the cancel command for the given job identifiers on the given printer queue.

One thing to note here is in the packet sent to the lpd by the script lies about the sender's identity. The script claims to be root, otherwise the lpd will refuse to kill any print jobs that are not owned by the same identity passed in the command packet. Root is allowed to kill any job. The lpd accepts that the identity of the user running the script is root because the lpd protocol assumes that it is talking to a well-behaved client who never lies.

The cancel_jobs function checks the reply from the cancel request and if there is any reply, then the cancel did not work and the function returns a false status. This is used back in the mainline code to give the user confirmation that the cancel happened or that it failed for some reason. Once the script has processed the deletions, the script will output the code for a refresh button so the user can refresh the view of the queue, and possibly delete more jobs.

Now that the script is done, we need to put it onto the Web server so other people can access it. Configuring Apache to run a mod_perl script is beyond the scope of this article. (Check out the Apache Web site for detailed instructions: I placed the script into the appropriate directory and told Apache that it was a mod_perl script and should be executed with the CGI emulation. Once the script was installed, I set up another script that automatically generated a Web page with links for all the printers on the remote machines to the printer queue management script like this:

<A HREF=http://webserver/perl/ \
  &printer=headoffice>Manage the Head Office printer queue</A>
I then pointed our help-desk people and a few others to the Web page and went on to the next task knowing that I would no longer get phone calls requesting emergency print job deletions.

Note that it is necessary to create access to a lpd remote printer on the remote machines that are going to have their printers managed for this scheme to work. The lpd service on the remote machine is not set up unless you have done this. I normally just use the admintool to create access to an lpd printer; this only needs to be done once on each remote host.


The script I have shown here can create a security risk because it is used in a restricted environment by trustworthy users. Access to the script should be restricted by using an access password to prevent accidental print job deletion. The use of hidden fields in the form can also create a security problem. In this case, there is no real danger but a user could view the hidden fields simply by viewing the HTML source and could possibly change the values in the hidden fields before the form is submitted.

Brett Lymn works for a global company helping to manage a bunch of UNIX machines. He spends entirely too much time fiddling with computers but cannot help himself.