Integrate CUPS Web Interface into a common web configuration tool

[petrprikryl]

Hi, I just want to ask if it would be possible to add URL prefix for web interface configuration. Because it is impossible to host it under some domain e.g. my.domain.com/cups/. Workaround is to use subdomain :-/ e.g. cups.my.domain.com.

[zdohnal]

Hi @petrprikryl ,

thank you for reporting the issue!

IIUC this feature can be implemented the following way - cupsd could interpret /${string} as / in requests if there is directive WebInterfacePrefix used in cupsd.conf and set to /${string}. WDYT, @michaelrsweet ?

[michaelrsweet]

I think that the CUPS web interface was never designed to be proxied or otherwise redirected, so it's a hard no for me. It is not just cupsd that would need to change, it would be all of the CGI programs, the templates, and libcups' support for manipulating cupsd.conf.

Remember too that the HTTP layer serves the IPP layer for printing, and NONE of that would handle redirection or proxying like this.

I guess it would be important to understand exactly what @petrprikryl is trying to do and why pointing users at "https://my.domain.com:631" doesn't work?

[zdohnal]

@michaelrsweet thank you, Mike! I've read this part of client.conf, but I always imagined a proxy as a separate entity, so I didn't know that it can mean proxying as a different URL. And actually I thought the URL would be https://my.domain.com:631/cups and Petr was just simplifying in the report.

@petrprikryl Petr, would you mind telling us what are you trying to achieve and why https://my.domain.com:631 doesn't work for the use case?

Thank you in advance!

[petrprikryl]

Hi, my use case is hosting cups web interface next to other services behind same domain while routing the HTTP requests based on prefix in Traefik:

/cups/ => cups service (web interface)
everything else => other service 

The problem is that cups web interface must know that it is behind this prefix to inject this prefix to all URLs. Otherwise web interface requests fallback to other service.

The important thing here is that I am talking about web interface only. Because our services are running in Docker. And printing commands are sent from other service internally. So communication in this case is in the inner Docker network where the prefix is not used because cups server is resolved by the internal Docker DNS.

So I think the goal is to make some split in cups server and cups web interface?

[zdohnal]

@petrprikryl probably routing based on the port (631 is cups web interface, other ports for other services) is out of the question, right? I'm sorry, I'm not that much experienced at this topic, so I'm learning as I go.

So IIUC you are using the web interface just as online viewer of configured printers, since printing commands, communication and CUPS service as it is runs in Docker?

So I think the goal is to make some split in cups server and cups web interface?

Do you mean making CUPS Web Interface as a separate client/proxy, which won't reside at IPP port and is not directly connected with cupsd daemon?

I've always taken CUPS web interface as a simple portable configuration tool, so it was convenient to be connected with cupsd. IMHO if we separate web UI from the daemon, I would prefer to have it in some common configuration system like cockpit rather than a separate web interface...

@petrprikryl @michaelrsweet wdyt?

[michaelrsweet]

WRT the current CUPS software, the web interface (CGI) programs are tightly integrated with cupsd. Even assuming we want to support this sort of indirect access, it isn't going to be a simple change as the paths are hardcoded in the HTML templates, in the CGI programs, and in cupsd itself. And once again, all IPP traffic goes through the same service, so it will be really hard to make everything coexist seamlessly.

I think integrating CUPS with an existing configuration system as @zdohnal suggested is probably the best, long-term approach.

[zdohnal]

Just note - by CUPS is meant CUPS Web Interface, to prevent confusion in the future.

IMHO integrating CUPS Web Interface with Cockpit could happen in the CUPS 3.x timeline, once the web interface has features for CUPS Sharing server, so we know what features should be passed into Cockpit implementation and prevent feature regression.

CUPS web interface integration into Cockpit was discussed several years ago when system-config-printer was being removed from RHEL 8, and the upstream opinion on the matter is the integration is not a priority for now - so integration itself would be on OpenPrinting group, or it can be a future GSoC project.

I'll rename the issue, give it the labels GSoC idea and CUPS 3.x, pass it to CUPS Sharing project and close it for now - in future we can filter the ideas from community by that label.

[zdohnal]

Cockpit is just a proposal, since it is the only web based configuration tool I know about - we can discuss which tool to migrate in the future.

[zdohnal]

Currently it is not planned to implement this, but the idea can be implemented in the future.