Make web interface working also with a CUPS daemon running on-demand

[tillkamppeter]

Current CUPS supports to run on-demand. As sson as request is sent to port 631 or to the domain socket, systemd starts cupsd and as soon as CUPS is idle for some time it stops again.

This does not work with the web interface. If the user goes through the several pages of a task, the server collects the inputs of the user, but if the user stays on one page for too long, CUPS times out idle and shuts down, forgetting the user's inputs from the previous pages. The web interface errors if the user clicks the "Continue" button now.

Could the architecture of the web interface be changed so that all user inputs are collected on the client (for example via cookies) and in the end of the task the complete request is sent to CUPS and when systemd has to start a new instance of CUPS for that, CUPS does not need to remember anything but gets a complete request which it can execute successfully.

See also

https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1598300

and also

https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1622707

[michaelrsweet]

The existing CGI programs do not depend on cupsd running. Aside from all of the state being saved in hidden form variables on each page (for the multi-step forms), there is also a session ID cookie that the CGIs maintain (all by themselves) so that they don't depend on cupsd in between submissions.

Finally, the systemd support code explicitly disables idle exit when the web interface is enabled, unless Ubuntu has changed what we do in the official, upstream code.

[tillkamppeter]

Sorry for the noise. I have found out what the problem was. The web interface is not accessible through CUPS' domain socket, as a browser is not able to do this. It requires access through port 631 and the systemd unit files which come with CUPS do not support triggering CUPS on port 631. Adding a line

ListenStream=631

to the "[Socket]" section of /lib/systemd/system/cups.socket solves the problem.

[michaelrsweet]

Till,

First, the reason why we don't include "ListenStream=631" is because that exposes cupsd to remote attack. And we don't listen on localhost (which has a similar security issue) because it causes problems when binding to the "any" address on Linux.

Second, once cupsd starts it will create the localhost (or "any" address) listener for you, and stay running indefinitely. And cupsd uses a KeepAlive file to tell systemd to start it up on bootup once you enable the web interface, so it should be running right away unless you've added something to manually start/stop cupsd.

[andyrtr]

Till, I've added your suggested "ListenStream=631" to /lib/systemd/system/cups.socket but this lead to forbidden access to the webinterface on my system. See also
http://lists.cups.org/pipermail/cups-devel/2016-September/016883.html