The Administration of the CUPS+PYKOTA server cups.cs

This document is primarily addressed to system administrators who have root access but is also valuable for those whose duties are confined to ManageUsersPrintersOnPykota. All systems used are Ubuntu based.

Introduction

The hostname cups.cs is a CNAME.

The server cups.cs is being used to drive some colour printers from Xerox as it permits hardware print accounting via snmp whereas the old system could not. Furthermore, the setting up of colour and monochrome print queues is possible on the server side via configuration of the corresponding PPD file that CUPS uses to describe a printer's capabilities. cups.cs is in the core region and is a setpw client of core.cs with logins restricted to CSCF staff as determined by the file /software/setpw/data/config/non-restricted-users on cups.cs and maintained on cups.cs. You must use ssh, as rlogin is disabled.

You must login from cscfnet, otherwise, you will be denied access. Check the file /etc/hosts.allow for the current access configuration.

It also has Pykota, a Python-based print quota system installed which uses PostgreSQL as it's backend database to store users, printers, and job history amongst other data.

Anyone in the Unix pykota group can run Pykota commands.

A necessary pre-condition for PYKOTA to manage a CUPS print queue

We want to add a CUPS print queue to the Pykota printer database. First we must describe an important pre-condition that must hold prior to adding a queue to the printers database in Pykota.

In order that a print queue, ABC, become a candidate for Pykota management the deviceURI for the print queue ABC has the name cupspykota mentioned in it, that is, if we run

lpstat -v ABC

yields

device for ABC: cupspykota:...

where ... represents some extra data that is not important for the moment. The important thing is that value of device for ABC begins with the string cupspykota which tells us that ABC has the potential to be Pykota managed.

Creating a new print queue

There are two ways: one is to use the web interface at http://cups.cs:631 (administrative access is limited to cscfnet) and the other is to login to cups.cs and use the command lpadmin from the command line. Anyone who is in the lpadmin group can run the command.

Enabling an existing print queue to use pykota accounting

Running lpstat -v on cups.cs results in the following output

# lpstat -v
device for lj_dc2306: socket://lj-dc2306.cs.uwaterloo.ca:9100
device for lp_dc3341: cupspykota:socket://csprinter002.cs.uwaterloo.ca:9100
device for lp_dc3341-colour: cupspykota:socket://csprinter002.cs.uwaterloo.ca:9100
device for lp_dc3516: cupspykota:socket://csprinter001.cs.uwaterloo.ca:9100
device for lp_dc3516-colour: cupspykota:socket://csprinter001.cs.uwaterloo.ca:9100
device for lpbw_dc3116: lpd://lpc-002.cs.uwaterloo.ca/PS-DCEB4C-U3
device for lpc_dc3116: lpd://lpc-002.cs.uwaterloo.ca/PS-DCEB4C-U3

which shows that the printer lp_dc3341, has a deviceURI that mentions the backend filter cupspykota, the main python based backend that is responsible for checking whether a user exists in the database (based on postgresql) and whether they have permission to print, if so, it queries the printer (if hardware accounting is being used) for the internal page count and sends the job and logs that into the job history.

A quick way to change an existing print queue to use pykota is to edit /etc/cups/printers.conf and change

DeviceURI socket://csprinter002.cs.uwaterloo.ca:9100

to

DeviceURI cupspykota:socket://csprinter002.cs.uwaterloo.ca:9100

and then restart cups by running /etc/init.d/cupsys restart. Check that the deviceURI has changed by running lpstat -v.

Pykota Configuration Files

There are two primary configuration files, /etc/pykota/pykota.conf and /etc/pykota/pykotadmin.conf with the following permissions and ownership

-rw-r--r--  1 pykota pykota 44329 2007-06-15 12:43 pykota.conf
-rw-r-----  1 pykota pykota  2851 2007-06-12 13:42 pykotadmin.conf

The crucial point to remember is that the cups daemon runs as user cupsys which is a member of the pykota group which implies the cupspykota backend can process these files, a necessity as the file pykotadmin.conf contains the write passwd to the database allowing for updates. To ensure this passwd not be seen by the general user the file has 640 permissions, that is, it is not world readable.

The file /etc/pykota/pykota.conf is liberally documented. We point out the key accounting global parameter (this can be changed on a per print queue basis in this file) to

       accounter: hardware(snmp)

which says snmp is used to query the printer's internal counter with the added benefit that this is done only when the printer is in a stable state. Other methods are documented in the file. It may be necessary, depending on the printer hardware, to use something other than snmp accounting, in which case, a separate section in the configuration file should be setup for that print queue.

Debugging Pykota+Cups

All logs that Pykota generates are sent to syslog. Look for 'Pykota' in the file, or one of the gzipped rolled files.

All logs Cups generates are sent to files in /var/log/cups/, in particular, error_log.

Cups must be running

In particular you should be able to access http://cups.cs.uwaterloo.ca:631 albeit only from on campus.

In order to support clients that are running lpr clients, in particular, Solaris hosts, the cups-lpd daemon must be running, that is, we must have

lsof -i | grep printer
xinetd     4126     root    5u  IPv4   13669       TCP *:printer (LISTEN)

where access to this daemon is controlled by the file /etc/xinetd.d/printer.

Configuring the PostgreSQL database

On the Ubuntu system we are running we installed postgresql-8.2 server package and then added the following file fragment

host  pykota pykotauser  127.0.0.1 255.255.255.255 crypt
host  pykota pykotaadmin 127.0.0.1 255.255.255.255 crypt
host  pykota all         127.0.0.1 255.255.255.255 reject

to /etc/postgresql/8.2/main/pg_hba.conf which suffices for the case where the database is on the same host where Pykota and Cups are installed, however, it desirable to have the database be on another host in which case the server needs to be configured to listen for any incoming connections and to restrict permissions to the print servers and admin hosts. In particular, the following fragment

# Allow access from cscfprint1
hostssl  pykota pykotauser  129.97.15.165 255.255.255.0 crypt
hostssl  pykota pykotaadmin 129.97.15.165 255.255.255.0 crypt
hostssl  pykota all         129.97.15.165 255.255.255.0 reject

allows the host 129.97.15.165 to connect as user pykotauser or pykotaadmin to the pykota database using crypt passwd and securely (some preliminary packet sniffing suggests this is indeed achieved with this configuration).

PostgreSQL backend must be running

For a Pykota managed print queue, the backend database PostgreSQL must be running. In particular

ps -ef | grep postgres
postgres 25585     1  0 Jun15 ?        00:00:00 /usr/lib/postgresql/8.2/bin/postgres -D /var/lib/postgresql/8.2/main -c config_file=/etc/postgresql/postgresql.conf
postgres 25588 25585  0 Jun15 ?        00:00:00 postgres: writer process                                                                           
postgres 25589 25585  0 Jun15 ?        00:00:00 postgres: stats collector process

If you do not get any output. Please start the process by running /etc/init.d/postgresql-8.2 start

Rename printer database while retaining job history

The situation we are in is the case where we are rename a CUPS+Pykota managed print queue, old_queue_name to a new name, new_queue_name, and we want to retain the job history attached to old_queue_name. We first create the new queue in the cups setup and ensure that it is Pykota managed. Next see if pkprinters --list new_queue_name gives positive output, if it does, please delete it by running pkprinters --delete new_queue_name. Now connect to directly with the SQL database, which, in our case, is PostgreSQL, by becoming the Unix user postgres one does:

# su - postgres

and then connect to the pykota database

$ psql pykota
pykota=# UPDATE printers SET printername='new_queue_name' WHERE printername='old_queue_name';
pykota=# \q                         
$ exit

External References

• Cups Homepage
• http://cups.cs/doc/pykota/html for official docs on pykota.
• http://article.gmane.org/gmane.comp.printing.pykota.user/1706/match=hard+limit+soft+difference for description of the some of the nuances of controlling print quotas (might be out of date)