Bug when running cupsd on non-standard port?

[Kurt Pfeifle]

This is a bug I'm experiencing with CUPS-1.2.7 on Solaris 10 (using CSW software packages from "blastwave.org").

I cannot test this on a newer version or another OS right now. However, my suspicion is, that this bug is still present in current CUPS versions (scanning the CUPS release notes since 1.2.7 didn't lead me to any hint that it may have been discovered and fixed earlier).

Therefor I ask a reader or two on this list to verify (or disproof) this problem on their respective systems...


Here is the scoop:
------------------

* Setup your CUPS system to run on a non-standard port (i.e. remove all mentions of "631" from cupsd.conf and add for example "Port 1632" or "Listen *:1632" plus "BrowsePort 1632" instead).

* Add "KeepJobFiles True" to your cupsd.conf.

* Print something. One test page is enough.

* Now go to "http://localhost:1632/jobs?which_jobs=all". Check the links for the printer and the "Reprint Job". They'll point to a "localhost:631" URI (instead of the expected and correct "localhost:1632" one...)!

Because of the above bug, reprints will of course also fail.

It looks to me like the web interface uses, (wherever the "{job_printer_uri}" variable is coming into play) a hard-wired "*:631" URI part. I have no idea if this bug goes beyond the web interface or if it is limited to that.

I'd like to know if this is just a local problem here, or if it has already been fixed in a newer release.

(I need to implement a few dozen CUPS server instances running on one machine, but on different ports, serving different SAP ERP domains for their printing needs; using Solaris 10 zones/containers is ruled out for various reasons).

--
Kurt Pfeifle
System & Network Printing Consultant ---- Linux/Unix/Windows/Samba/CUPS