@ijohnson has posted PRs to the core Snaps to add /var/cups
: core, core-base, core18, core20.
As the review-tools of the Snap Store already require the “cups-socket-directory: $SNAP_COMMON/run
” line in snapcraft.yaml
I have committed its addition in the CUPS Snap now. Technically the CUPS Snap is completed now for the new cups
interface, but to assure that the cups
interface will work for everyone, we will add the assumes: [snapd2.55]
as soon as snapd 2.55 makes it into the stable channel of the Snap Store.
Recent tests have revealed the following bug:
In a client application I observed that the CUPS_SERVER
environment variable did not get set and therefore the snapped application tries to access CUPS on the standard socket of the system’s CUPS, and not on the mounted socket of the CUPS Snap.
After @ijohnson told me that he cannot reproduce the bug I have reported on Launchpad (previous comment) I tried testing again, snapd having auto-updated to version 2.54.4+git1079.gbf8d25c (from the Edge channel of the Snap Store), and this time everything worked again. We have closed the bug report now.
As the editability of the original TODO list has expired (after 1 month) I am re-posting it here to document the further development:
TODO List
What still needs to be done is the following:
-
snapd 2.55 release: The new snapd with the included
cups
interface needs to get released to the stable channel of the Snap Store. This will happen in 2-3 weeks from now. -
Snap Store permissions: [DONE] Request permissions from the Snap Store team for the CUPS Snap to use the
cups-socket-directory
attribute and for auto-connection of any Snap’scups
plug to thecups
slot of the CUPS Snap. I have already posted the request here on the forum. -
/var/snap
in base Snaps: [DONE] @ijohnson will post PRs (Update: has posted, see below, and they got all merged) on the base Snaps to create the/var/snap
directory. @ijohnson: There are some other PR’s I will file to the base snaps which will behind the scenes make using thecups
interface more efficient, but that will not change how it’s used at all (it will just change the mount namespace setup by creating the/var/cups
directory there so we don’t have to do lots of mount tricks) -
CUPS Snap auto-installation: [DONE via placeholder content interface] When an application Snap plugging
cups
gets installed from the Snap Store and the CUPS Snap is not installed (or a too old version), the CUPS Snap gets automatically installed in addition to the application Snap, like a package dependency. @ijohnson plans to adapt thedefault-provider
setting to also work for thecups
interface here: We have to either manually enable this using a transitional placeholder content interface or adapt thedefault-provider
setting to also work for thecups
interface. I plan on doing the latter at some point soon so I don’t think that the former needs to be implemented. -
Snapcraft extension to auto-set CUPS_SERVER environment variable: [NOT NEEDED ANY MORE] Currently in the
snapcraft.yaml
of an application Snap using thecups
interface we have to set theCUPS_SERVER
environment variable to/var/cups/cups.sock
viaenvironment:
entry. This can be made automatic by a snapcraft extension. @ijohnson: That environment variable setting could probably be done with a snapcraft extension, which is not added to snapd, but rather to snapcraft itself. The extension could look like this and also cover the CUPS Snap auto-install. Update: The automatic setting of theCUPS_SERVER
environment variable is already done by snapd. -
Changes in CUPS Snap: [IN PROGRESS] The CUPS Snap needs to have the correct
cups
slot definition, as shown in my earlier post, with the “cups-socket-directory: $SNAP_COMMON/run
” line added (Update: This line is added now, was needed by Snap Store’s review-tools to accept the CUPS Snap) and also in the beginning of thesnapcraft.yaml
a line “assumes: [snapd2.55]
” added (Update: This line is commented out now, as snapd 2.55.2 got withdrawn from the stable channel) as then the Snap will perhaps not work with older snapd versions any more. The latter I only will do when snapd 2.55 gets actually released to the stable channel, to make sure that the CUPS Snap can always be downloaded and used.
With all this done we will be able to launch the new cups
interface and tell all the snappers out there to use it for their printing applications, like LibreOffice, Darktable, evince, gedit, … And we are really close, only the release of snapd 2.55 is missing and probably the next landing of the core Snaps.
Update: snapd 2.55.2 is NOT yet in the stable channel, seems that it got put and withdrawn right after.
Some news about our progress:
- Core Snaps with
/var/cups
directories, at least core18 and core20, are in the stable channel now. - snapd 2.55.2 will reach the stable channel on Tue, April 5, 2022
- We have found a bug in snapd, snapd setting the
CUPS_SERVER
environment variable to/var/cups/cups.sock
not only when thecups
interface is plugged but always, on any Snap, and so breaks the CUPS Snap and Snaps which plugcups-control
and notcups
. A PR on snapd, at least to address the case of the CUPS Snap, got posted by @mvo. Thanks a lot for working with me on the fix and posting the PR. He is also working on a solution for thecups-control
case. In the proxy-mode the CUPS Snap works correctly even with this bug present.
Also thanks to @cachio for his testing work and finding several bugs concerning the cups
interface in snapd and the CUPS Snap.
Update: snapd 2.55.2 is NOT in the stable channel. Seems that it got accidentally promoted and withdrawn right after. Therefore I have commented out the assumes: [snapd2.55]
line in the snapcraft.yaml
of the CUPS Snap now.
snapd 2.55.2 made it into the Stable channel and I have added the assumes: [snapd2.55]
line to the snapcraft.yaml
of the CUPS Snap, so the TODO List above is completed.
The Pull Request to fix the bug of CUPS_SERVER
always being set to /var/cups/cups.sock
regardless of cups
plugged or not which I mentioned two posts earlier here got merged and you get the fix included if you upgrade your snapd to the one on the Edge channel:
sudo snap refresh --edge snapd
(Must be 2.55.2+git188.ge21669c or later, check with snap version
or snap list
)
This fixes the bug for both the CUPS Snap and Snaps plugging cups-control
. My earlier assumptions that the latter are not covered was wrong.
I have tested the fix intensively (see my comments in the PR starting here) and with the workaround described below everything is working as designed!
So principally we are ready to go with the cups
interface, but there is still a little problem when updating to the fixed snapd. If a Snap, especially the CUPS Snap has the environment variable set and after that we update snapd and restart the CUPS Snap, the variable stays set. There is some kind of cache pertinent through restart of the Snap.
To clean up this, once having updated snapd to the Edge version, run
sudo /usr/lib/snapd/snap-discard-ns cups
and the variable gets immediately cleared so that you can use the CUPS Snap and its cups
interface correctly from now on.
Also all your Snaps which plug cups-control
need this clean-up as otherwise you cannot print from these Snaps. Note that there are several, as cups-control
was the interface used up to now also if one just wants to print. Run the following command for each Snap:
sudo /usr/lib/snapd/snap-discard-ns SNAPNAME
replacing SNAPNAME by the name of the Snap to fix. Run
snap connections | grep cups-control
to find all your installed Snaps which plug cups-control
.
You need to run snap-discard-ns
on your Snaps only once and never again, only when you update from a still buggy snapd from version 2.55 on and older than 2.55.2+git188.ge21669c to a fixed version, 2.55.2+git188.ge21669c or newer.
So we hae now the following new TODO list:
To be done as soon as possible:
- Create an automated way to get rid of the
CUPS_SERVER
environment variable wrongly set by a buggy snapd, for example let snapd (snap-exec
) unset theCUPS_SERVER
environment variable if it finds that the/var/cups/
directory is not bind-mounted meaning thatcups
is not plugged, so when not settingCUPS_SERVER=/var/cups/cups.sock
unsettingCUPS_SERVER
. Or do asnap-discard-ns
on all installed Snaps every time snapd is updated. - Sort out the snapd 2.55.x release into the stable channel.
To be done during the coming weeks/months:
- Let snapd directly auto-install the CUPS Snap when we are installing a Snap which plugs
cups
, without the currently used placeholder content interface. This way a snapper only needs to addcups
to the plugs of an app so that it can print, nothing more. No ugly content interface entry needs to be added then. - Let snapd be able to set environment variables triggered by plugging a given interface (and remove them if the interface is not plugged any more). This way we can get rid of the current workaround of checking for the bind mount on
/var/cups/
and we can set environment variables also for other interfaces, where the use of them cannot get detected that easily.
@mvo thanks a lot for your cooperation with me to debug the CUPS_SERVER
environment variable issue, for posting the PR, and for adding the long-term TODOs to the current developemnt cycle, and thanks @cachio, @mardy, and @pstolowski for approving the PR so quickly.
snapd 2.55.2 is NOT in the stable channel. Seems that it got accidentally promoted and withdrawn right after.
Perhaps it was withheld due to the bug I described in the previous post, perhaps due to other bugs. I do not know …
snapd 2.55.2 got indeed withdrawn from the stable channel:
In version 2.55.2, for example, libreoffice does not list the printers configured in ubuntu. The problem was solved thanks to the regression of version 2.54.4. When the “cups” interface is merged with snapd and released in a new stable version of snap, will the apps list the configured printers? Thank you very much.
@jovimaco this is due to a known bug. In addition, there is also another, minor known bug. Both will get hopefully fixed in 2.55.3, but currently snapd release manager @mvo is very busy to fix the bug which has stopped 2.55.2 and so I cannot provide further information. Note also that next week is Easter week and many of my colleagues are on vacation. I will post here when there is something new to test.
I got news from @mvo: 2.55.3 with the fix for the bug of the CUPS_SERVER
environment also set in the CUPS Snap and Snaps plugging cups-control
is already released into the beta channel. @mvo will work on the bug of environment variables in Snaps persisting through restarts and updates in the beginning of next week.
@jovimaco, with snapd 2.55.3 installed LibreOffice should list your printers correctly and you should be able to print. Please test this by running the command:
sudo snap refresh --beta snapd
and then checking the print dialog of LibreOffice again. If you do not see your printers, run the command
sudo /usr/lib/snapd/snap-discard-ns libreoffice
Does it work correctly now?
If the problem occurs again for you, to get back into working state, do
sudo snap refresh --stable snapd
sudo /usr/lib/snapd/snap-discard-ns libreoffice
Please tell us your results. THanks.
Did some quick tests with (like the ones in PR #11616) with snapd 2.55.3 from the beta channel installed and the CUPS_SERVER
ennvironment variable now gets only set to /var/cups/cups.sock
in Snaps plugging cups
, not in any other Snap. So this bug is fixed with 2.55.3. So at least upgrading from snapd 2.54.x or earlier to 2.55.3 will get you a working cups
interface.
I did another test, also with snapd 2.55.3 from beta:
$ snap run --shell cups-admin-test-no-control.lpstat
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.
$ echo $CUPS_SERVER
/var/cups/cups.sock
$ stat / /var/cups | grep Device
Device: 740h/1856d Inode: 11789 Links: 21
Device: 10302h/66306d Inode: 53813571 Links: 2
$ exit
exit
$ sudo snap disconnect cups-admin-test-no-control:cups
$ snap run --shell cups-admin-test-no-control.lpstat
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.
$ echo $CUPS_SERVER
$ stat / /var/cups | grep Device
Device: 740h/1856d Inode: 11789 Links: 21
Device: 740h/1856d Inode: 11669 Links: 2
$ exit
exit
$ sudo snap connect cups-admin-test-no-control:cups cups:cups
$ snap run --shell cups-admin-test-no-control.lpstat
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.
$ echo $CUPS_SERVER
/var/cups/cups.sock
$ stat / /var/cups | grep Device
Device: 740h/1856d Inode: 11789 Links: 21
Device: 10302h/66306d Inode: 53813571 Links: 2
$ exit
exit
$
This shows that disconnecting the cups
interface immediately removes the bind mount on /var/cups/
and also the CUPS_SERVER
environment variable. Re-connecting immediately sets the CUPS_SERVER
variable and does the bind mount. No persistence of the variable over interface disconnect/connect actions.
Now I am doing an up/downgrade test (before starting I was on snapd 2.55.3, at the end of the tests of the previous post, also keep in mind that the Snap cups-admin-test
plugs cups-control
and the Snap cups-admin-test-no-control
plugs cups
):
$ sudo snap refresh --candidate snapd
2022-04-09T15:52:23+02:00 INFO Waiting for automatic snapd restart...
snapd (candidate) 2.55.2 from Canonical✓ refreshed
$ snap run --shell cups-admin-test-no-control.lpstat
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.
$ echo $CUPS_SERVER
/var/cups/cups.sock
$ stat / /var/cups | grep Device
Device: 740h/1856d Inode: 11789 Links: 21
Device: 10302h/66306d Inode: 53813571 Links: 2
$ exit
exit
$ snap run --shell cups-admin-test.lpstat
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.
$ echo $CUPS_SERVER
$ stat / /var/cups | grep Device
Device: 740h/1856d Inode: 11789 Links: 21
Device: 740h/1856d Inode: 11669 Links: 2
$ exit
exit
$ sudo /usr/lib/snapd/snap-discard-ns cups-admin-test
$ snap run --shell cups-admin-test.lpstat
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.
$ echo $CUPS_SERVER
/var/cups/cups.sock
$ stat / /var/cups | grep Device
Device: 740h/1856d Inode: 11789 Links: 21
Device: 740h/1856d Inode: 11669 Links: 2
$ exit
exit
$ snap run --shell cups.cupsd
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.
$ echo $CUPS_SERVER
$ exit
exit
$ sudo /usr/lib/snapd/snap-discard-ns cups
$ snap run --shell cups.cupsd
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.
$ echo $CUPS_SERVER
/var/cups/cups.sock
$ exit
exit
$ sudo snap refresh --beta snapd
2022-04-09T15:56:58+02:00 INFO Waiting for automatic snapd restart...
snapd (beta) 2.55.3 from Canonical✓ refreshed
$ snap run --shell cups-admin-test.lpstat
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.
$ echo $CUPS_SERVER
/var/cups/cups.sock
till@till-x1nano:/home/till/printing/openprinting/cups-snap/x$ exit
exit
$ sudo /usr/lib/snapd/snap-discard-ns cups-admin-test
$ snap run --shell cups-admin-test.lpstat
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.
$ echo $CUPS_SERVER
$ exit
exit
$ snap run --shell cups.cupsd
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.
$ echo $CUPS_SERVER
/var/cups/cups.sock
$ exit
exit
$ sudo /usr/lib/snapd/snap-discard-ns cups
$ snap run --shell cups.cupsd
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.
$ echo $CUPS_SERVER
$ exit
exit
$
Here one sees that updating or downdating snapd does not update the environments of the installed Snaps, independent whether variables need to get set or removed. One gets the installed Snaps only up-to-date with the running snapd if one runs snap-discard-ns
on each of them. So to get all problems solved with updating snapd and with the cups
interface bug fix (and consistent updating in general) the snapd install/update process should run snap-discard-ns
on each installed Snap.
In the above example I am on snapd 2.55.3, which sets the CUPS_SERVER
environment variable correctly only in Snaps plugging cups
, identified by the bind mount on /var/cups/
. Now to investigate u/downgrade behavior of snapd, I downgrade to snapd 2.55.2 by switching into the candidate channel. This version wrongly sets the CUPS_SERVER
environment variable on every Snap. So I now expect it to be set on all my test Snaps. This is not the case, it is set only on the cups-admin-test-no-control
Snaps, as it gets done by snapd 2.55.3, but we are under 2.55.2 now. So I run snap-discard-ns
on all my test Snaps now and only then I get the snapd 2.55.2 behavior of CUPS_SERVER
being set in all Snaps.
Now I upgrade back to snapd 2.55.3 by switching to the beta channel again. I expect an immediate transition to the correct configuration of the CUPS_SERVER
environment variable being set only in the Snap which plugs cups
, but it is still set in the other Snaps. I again have to run snap-discard-ns
on all my test Snaps to get their CUPS_SERVER
settings correct according to snapd 2.55.3.
We have finally made it!
The “cups
” interface is now live!
See the launch post with usage instructions, how it works, and everything you need to know.
The interface is principally working now but to make it perfect there will be done the following improvements on snapd in the next few months:
- Let snapd directly auto-install the CUPS Snap when we are installing a Snap which plugs
cups
, without the currently used placeholder content interface. This way a snapper only needs to addcups
to the plugs of an app so that it can print, nothing more. No ugly content interface entry needs to be added then. - Let snapd be able to set environment variables triggered by plugging a given interface (and remove them if the interface is not plugged any more). This way we can get rid of the current workaround of checking for the bind mount on
/var/cups/
and we can set environment variables also for other interfaces, where the use of them cannot get detected that easily.
Thanks
@mvo thanks a lot for your cooperation with me to debug the CUPS_SERVER environment variable issue, for posting the PR, and for adding the long-term TODOs to the current developemnt cycle, and thanks @cachio, @mardy, and @pstolowski for approving the PR so quickly. Thanks again, especially to @ijohnson and @jamesh, but also to @pedronis, @alexmurray, @mardy, and Michael Sweet, for their contributions to get the interface designed and implemented.