@ijohnson Brilliant plan, it is great. I like it a lot.
Some remarks:
- The firewall cupsd (the snapped one which is running in parallel to a classic one) only can forward print requests not admin requests. This is no problem as we go the firewalled printing path only for snapped clients using the content interface as they are not plugging
cups-control
. Snaps pluggingcups-control
always communicate with the “standard” CUPS (classic if present, snapped otherwise) and manage this one. - If we have a classic CUPS, the user creates CUPS queues on this classic CUPS and the user only manages this classic CUPS with printer setup tools or the web interface. The snapped CUPS in firewall mode will run fully automatic without being managed by the user. It does not open port 10631 but only uses the socket in $SNAP_DATA and also has its web interface turned off. It has its cups-browsed attached to see the queues of the classic CUPS and replicate them on the snapped firewall CUPS. The classic CUPS therefore needs one little change in configuration: If it is configured to not share its print queues it now must share them but to localhost only, so that the cups-browsed of the snapped CUPS can pick them up and forward them. This would require some mechanism to change the classic CUPS’ configuration automatically when the CUPS Snap gets force-installed as firewall.
- As the CUPS Snap already automatically switched between two modes, first beint the only stand-alone/system CUPS and second being alternative CUPS in parallel to classic CUPS (on alternative port and socket) it is easy to change the alternative mode to a firewall mode. The startup scripts for both cupsd and cups-browsed in the CUPS Snap do all required configuration changes.
- You say: “(6) All of the above means we can actually just get rid of the cups interface as it exists …” We can simply make the interface named
cups
being this content interface mentioned in (1), but be careful, a print client Snap not only needs access to the cupsd socket but also to the D-Bus interfaces of CUPS, as some clients want to subscribe to notifications. The D-Bus interfaces are the same as incups-control
.
CUPS and cups-browsed should have enough configuration options to be able to auto-configure them appropriately in the start-up scripts of the CUPS Snap so that we can run a cupsd in firewall mode. If something is missing, no problem, I have the upstream maintainer power over both and so I can add the missing configuration options.
For me it looks all workable, the most difficult part is probably to automatically change the classic CUPS’ configuration so that its printers get shared localhost-only.
Till