Testing of CUPS development versions more efficiently

Kurt Pfeifle kpfeifle at danka.de
Fri Jul 28 03:21:28 PDT 2006


[ crossposting ahead ]

In recent months I've locally implemented a way to run two (or more) 
different CUPS instances on the same machine.

My first instance is the distro's own package as installed on the 
system, bound to port 631, running as root. 

My second instance is locally built from the CUPS subversion sources,
bound to a (selectable) port above 1024 (I tend to use 20631), 
running as user.

This setup allows me to quickly run any test of development versions 
of CUPS the minute after Mike has committed new code changes. 

Both installations don't interfere with each other at all, can be 
stopped + started at will; they can have the same set of printers +
drivers installed or completely different ones.

I just need to run "make && make clone" to create a new running 
instance of the code. Or "make && reload_clone" to see a newly added 
document in the web interface of an already running instance. Or
"make && make test_1000_printers" to add 1000 printers to the cloned
instance....

I've wrapper scripts in place which allow me to use any commandline 
tool (lp, lpadmin, lpoptions, lpstat, .... whatever) either as the 
system installed "stable" version, or as the development version if 
called with an ".13svn" extension (examples: "lpadmin.13svn", 
"lpstat.13svn"). 

The web interface does of course work as well without any glitches 
(if security settings take into account that it runs as user).

It is also possible to use (and test) KDEPrint/kprinter with the 
CUPS development version by simply pointing it to the additional 
IPP_PORT (20631 in my case).

And of course, it is also possible to test the interoperability 
(Browsing, Polling, Relaying, printing,...) of development versions 
hosted on different systems by setting them all to the same IPP_PORT.

I also used it to stress-test various features by running a script 
that installed 10,000 print queues and then use it for my own 
printing needs.

It was a great way for me to become familiar with many of the new 
features CUPS 1.2 introduced (ErrorPolicy, OpPolicy, Limit [Policy],
auto-SSL, network printer discovery, the new web interface, server-
side default options, and many more...).

For me that setup works very well now. However, other people may
have difficulties to use it for themselves in the shape it is now.

But if other people are interested, I'd see to bring it into a 
"publishable" shape, and add a little bit of documentation so it is
easier to use for other people.

Just tell me what you think.

Cheers,
Kurt




More information about the cups mailing list