papplMainLoop should use persistent location for state files

[michaelrsweet]

Currently papplMainLoop defaults to a state file in $TMPDIR/BASENAME.state and a spool directory in $TMPDIR/papplUID.d.

When running in a SNAP, the state file should be in $SNAP_COMMON/BASENAME.state and the spool directory $SNAP_COMMON/BASENAME.d.

When running as root, the state file should be in LOCALSTATEDIR/lib/BASENAME.state and spool directory LOCALSTATEDIR/spool/BASENAME.d.

When running as non-root, the state file should be in $XDG_CONFIG_HOME/BASENAME.state if XDG_CONFIG_HOME is set and $HOME/.config/BASENAME.state or $HOME/Library/Application Support/BASENAME.state (macOS) otherwise. The spool directory should be $TMPDIR/BASENAME-UID.d.

[michaelrsweet]

[master b88be1a] Address persistence and a system-wide server (Issue #128, Issue #148)

[tillkamppeter]

I see in the change that you take into account that the Printer Application is running in a Snap, but you forgot the socket, in the function _papplMainloopGetServerPath() is no mention of if (snap_common) { ..., and as in a Snap the server runs as root and the client as user the generated socket names do not match.

[michaelrsweet]

@tillkamppeter I can't put the socket in SNAP_COMMON. What do other snap-based services do?

[tillkamppeter]

In the Snap of the PostScript Printer Application I am actually putting the socket into $SNAP_COMMON (via the --with-papplsockdir=/var/snap/ps-printer-app/common/tmp argument for ./configure) and there it works, at least for the Printer Application itself, from the same Snap, used for command line control of the Snap's Printer Application instance running as server. See the snapcraft.yaml of the PostScript Printer Application.

It should also be accessible this way for any unsnapped clients.

If you want to access the snapped Printer Application from another Snap (Snap-to-Snap communication via domain socket) you always need a special snapd interface, independent whether the socket is in $SNAP_COMMON or somewhere in the file system of the host system.

The CUPS Snap is such a case. The CUPS Snap's cupsd is listening on up to two domain sockets, always on /var/snap/cups/common/run/cups.sock and in case the the CUPS Snap's cupsd is the only cupsd on the system (no classically installed CUPS, from DEB, RPM, source, ...) also on /run/cups/cups.sock. Both can be used by unsnapped clients, the latter usually being used as it is the default in the system's classically installed libcups.

Client Snaps must plug an appropriate interface to access any file or domain socket of the host system or of another Snap, so for printing with or managing CUPS they need to plug an interface, "cups" (under development, see the linked snapcraft.io forum threads in README.md and especially the current discussion) for sole printing and "cups-control" for managing CUPS (create/modify/delete queues, delete anyone's jobs, ...).

The domain socket /var/snap/cups/common/run/cups.sock where the CUPS Snap always listens on is the only one confined Snaps plugging the "cups" interface can print through, this enforces the use of the CUPS Snap's CUPS, which always has Snap mediation (blocking administrative requests if client plugs "cups" and not "cups-control"). For this an confined Snap plugging "cups" installed from the Snap Store will auto-install the CUPS Snap as a dependency, and if on the system is already a classically installed CUPS (most of these do not have Snap mediation) the CUPS Snap switches to proxy mode, mirroring the queues of the classically installed CUPS and passing the jobs through to the classically installed CUPS so that drivers are used there.

The way to use Printer Application Snaps by any snapped or unsnapped client (especially the CUPS Snap) is to use http://localhost:PORT/ currently. If you want to have a domain socket communication between the CUPS Snap and the Printer Applications a new snapd interface for that has to get designed.

[michaelrsweet]

@tillkamppeter I still don't like putting the domain socket in SNAP_COMMON, as that is supposed to be for persistent data (or at least that's what the docs say). But I can add that.

As for a client (other than the executables in the snap) accessing the domain socket, I guess that is technically possible but not using the PAPPL client code (which will only work properly inside the snap).

[michaelrsweet]

[master eeb0991] Use SNAP_COMMON for domain socket, too (Issue #128, Issue #148)