Automatic refresh of private snaps

denis 2017-10-19 14:10:14 UTC #1

Private snaps don’t get updated by snapd.
I see that snapd skips these snaps during its refresh stage:

232  Done    2017-10-19T13:47:49Z  2017-10-19T13:47:49Z  Refresh all snaps: no updates

Even when there is a new revision in a particular private snap.

And by the way this is related to Why do devmode snaps not auto update?
Because “private” flag is generally used in conjunction with “devmode” flag when it’s not ready for public access, but developers want to take advantage of all the functionality of snapd, including automatic updates.

Devmode updates feature is marked as upcoming in the future. What about “private” updates? This would be great actually.

Any ideas?

kyrofa 2017-11-02 15:06:17 UTC #2

@chipaca do you know anything about this?

chipaca 2017-11-02 15:08:10 UTC #3

Private snaps should definitively get updated.

Devmode snaps do not get updated, currently (I’m uncertain as to whether that will change).

I’m not clear whether @denis is saying they’re seeing a private non-devmode snap not getting updated, or whether their private snap is also devmode.

tpatel 2017-11-02 15:10:40 UTC #4

@chipaca I’m seeing similar issue where private-stable snap released on stable channel is not getting auto updated.

chipaca 2017-11-02 15:11:11 UTC #5

I’ll see if I can reproduce this.

pedronis 2017-11-02 15:11:51 UTC #6

does the device has a valid login to access the snap? what happens if you try to update it manually "snap refresh "

chipaca 2017-11-02 15:17:02 UTC #7

I just installed an old revision of a snap I made private, then did snap refresh, and it got updated.

I suspect, as @pedronis pointed out, that you’re probably not logged in to the store? Can you even install the private snap in the first place?

pedronis 2017-11-02 15:19:30 UTC #8

more likely were logged in, but the token has expired

kyrofa 2017-11-02 15:20:04 UTC #9

Snap doesn’t automatically refresh the macaroon?

pedronis 2017-11-02 15:20:22 UTC #10

not user macaroons under all scenarios

tpatel 2017-11-02 15:20:23 UTC #11

The device has a valid account to install/update the snap. First install of the snap was done using the same login.

tpatel 2017-11-02 15:21:57 UTC #12

When you do snap refresh it updates the snap but thats manual process and not-auto update.

pedronis 2017-11-02 15:22:28 UTC #13

this is an area were the warnings framework would be useful, also there were some plans for a slightly different approach to tie users to devices that we haven’t worked on yet

chipaca 2017-11-02 15:26:37 UTC #14

aha! This I can reproduce.

tpatel 2017-11-02 15:28:30 UTC #15

@chipaca, @pedronis Will the snap auto-update if login used is a collaborator account?
Do the device have to be logged in as primary account to get auto-updates?

chipaca 2017-11-02 15:30:32 UTC #16

so, this is a bug.

I’m seeing if there is a workaround to unblock you. Give me a mo’.

chipaca 2017-11-02 15:48:09 UTC #17

Unfortunately it’s going to take some fixing.

In the meanwhile, would tweaking snapd.refresh.timer work for you? As that runs as root you’d have to copy ~/.snap from the user that logged in, to /root/, for everything to work.

I’ll be digging into this so it works at least ini the common case asap.

tpatel 2017-11-02 16:16:11 UTC #18

What I need to do snapd.refresh.timer ?

chipaca 2017-11-02 16:22:25 UTC #19

snapd.refresh.service is the “emergency refresh”, left in place in case snapd’s internal refresh gets confused. You can see the timer, and the service it triggers, in /lib/systemd/system/snapd.refresh.timer and .../snapd.refresh.service. I’d say: copy the .timer to /etc/systemd/system/, and change its OnCalendar=weekly to OnCalendar=daily or somesuch. This will just run snap refresh on that schedule.

Once you edited it, systemctl daemon-reload should re-read the file. You can see whether it’s going to work as expected via systemctl list-timers; you can also trigger the service to start manually (systemctl start snapd.refresh.service) to check it’s doing as expected.

Remember to copy ~/.snap/ to /root/ for the auth macaroon to be found though.

denis 2017-11-02 16:56:55 UTC #20

I tried to login to the store under root and run "snap refresh " from temporary devmode deamon snap. This gave “snap not found” or something.
Apparently logging in to the store under root doesn’t create /root/.snap/auth.json. I should’ve just copied this file from the main user account but I gave up earlier.

BTW, what is the intended way of snapd to update such snaps during its main internal update procedure? It should store this auth info somewhere internally? Won’t this token expire at some point of time in the future leaving this snap with no updates?
And as a general thought, isn’t it just sufficient to have a private snap installed on the system to say “ok, this device has a legitimate right to update”?