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?
more likely were logged in, but the token has expired
Snap doesn’t automatically refresh the macaroon?
not user macaroons under all scenarios
The device has a valid account to install/update the snap. First install of the snap was done using the same login.
When you do snap refresh it updates the snap but thats manual process and not-auto update.
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
aha! This I can reproduce.
@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?
so, this is a bug.
I’m seeing if there is a workaround to unblock you. Give me a mo’.
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.
What I need to do snapd.refresh.timer ?
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.
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”?
Thanks. I will try that out.
Will it log anything from which I know it actually tried the snap to update?
@tpatel snap changes will list it, yes.
@denis to answer your last question, if a collaborator installs a snap, and then is no longer a collaborator, they shouldn’t be able to refresh a private snap.
I need to discuss what the intended way for this to work is, as some things changed in how we handle this (which is why it broke). We are also obviously missing tests for this, which also needs addressing.
With systemctl list-timers, I see in snapd.refresh.timer getting executed without having etc/systemd/system/snapd.refresh.timer. Why is that not forcing private snap to refresh ? Is it because the root folder doesnot have .snap/ folder with login credential? Or is it something else?
snapd ships the timer in /lib/systemd/system; /etc/systemd/system is where I suggested you put the edited version, as it would then override the other without interfering with a packaging upgrade (also it’s writable on core).
The lack of credentials for root would break this, yes.
Does snap update when done manually by “snap refresh”, when it is private mode and confinement strict?
yes, but in 2.31 we are also fixing the automatic bit: