Brand store.
https://docs.ubuntu.com/core/en/build-store/create
First Thanks to all the snap team for the awesome job you are doing. It’s great the idea of a software always updated and secure, but we are loosing the option to select if we want the update or not. Having the auto-updates option is fantastic for many uses cases, but for others it’s not (as mentioned in many posts before this one). Perhaps the global switch is not a priority, but many of us (snap users) would like to have the ability of disabling the updates.
As niemeyer said:
and that shouldn’t be a problem, because if that’s what the user wants, there’s no reason for us (developers) to enforce any update.
2 Likes
I hear your view, but still have a hard time accepting this. Just recently my system broke again with my FRR snap. But this time it wasn’t the FRR snap which broke it (so independent tracks won’t help), but the core snap update which had a bug (see Weird udev_enumerate error ).
Not blaming anyone for the bug. Bugs happen. I accept this as a fact. But it broke all my FRR snap’s during the update of the core. None of these workarounds would have protected me from this (the precise window might help to lower the impact, but still limited)
1 Like
@mvo for that bug what action has been taken to ensure it doesn’t regress again?
I think the snappy team expects snappy users to test stuff on candidate to ensure no regressions every time a new core release is put into candidate. If you report the bug on the forum then they will hold the release from stable until the bug is fixed. I can’t remember which version but I think there was a version of core which was never released because there were bugs holding it back?
However - is this requirement (of every user using snappy in critical cases testing every core candidate release) too demanding? Action may be taken to ensure that previous bugs aren’t recreated, but brand new bugs can’t really be prepared for (aside from the usual automated and manual testing)?
Thanks for all the feedback. We are still hearing, and still want to make sure that these concerns are all addressed.
The first thing we need to do with priority is to support the monthly scheduling, which will mean as long as you try to refresh the system once every month in a window of your choice, the system will never update out of band.
But we’re still looking into the option of implementing some other option too. This will definitely continue to be a topic in our conversations, so please don’t take it as a final design right now.
1 Like
Hello,
I am an Ubuntu Desktop (16.04.3) user and I have recently installed some snaps. I am doing some research to understand their effect on my system and I found out about this.
I was really surprised by this and I have to say I am a bit disappointed. The obvious similarities to Windows 10 and it’s problems have already been pointed out. More surprising to me is the project management approach of controlling the user (through restricting the user’s options). This is against what free software is about.
It’s not that I don’t want to keep my laptop updated. Whenever I start it it’s one of the first things that I do. But having that control taken away is very off putting.
I can think of cases where I would want to delay updates. Some have been mentioned already. It’s true that they are the minority of my usage. But it is also true that they are there. So I would like to put the issue on a statistics point of view.
Let’s say that snaps are successful and get deployed at 500 million devices until 2020. (According to some lazy googling IoT devices in 2020 were expected to be upwards of 20bil so the market share I picked ain’t huge. Didn’t check the validity of those estimates though). Let’s also say that you have designed snap forceful updates so well that you can successfully cover 99.9% of use cases. This will leave you with 500.000 devices (!!!) that have use cases you are not addressing and will be forced to hacks like blocking connections to the update servers etc, which are even worse!
If a knowledgeable user with root access wants to disable updates he can do it, you might as well give him an option to do it in a way that doesn’t further compromise his system.
The solution, as far as I can see, is to add attrition to the option you don’t want to be enabled. You know the power of defaults. If the update option is on most people will leave it at that. On your enterprise customers you can explicitly say in the support contract that this option will void any support contract guarantees. You can output a big warning whenever a user connects to the device urging them to turn automatic updates on.
If after all your measures somebody insists on disabling updates you should allow him. He will be using an unsupported configuration, he may very well be doing it wrong, but in the end it is the user’s prerogative (in the context of open source where you are supposed to own your computing devices instead of renting them through an EULA).
Please reconsider this.
TLDR:
- Don’t try to control the user.
- If you gain serious market share there will be a lot of users with valid use cases that need this option.
7 Likes
I’ve already told you the workaround to stop automatic updates on your routers.
- Create a new devmode daemon snap that runs this upon startup:
sudo iptables -A OUTPUT -d api.snapcraft.io -j DROP
-
Install it manually on any device you want to be free from updates.
-
That’s all.
As it is a daemon snap –> it will be started as root.
As it is a devmode snap –> it will bypass Apparmor and allow you to execute iptables.
If sometimes you want to make a one-shot update, you log in to the particular device and run:
sudo iptables -D OUTPUT -d api.snapcraft.io -j DROP
snap refresh
sudo reboot
1 Like
Denis,
thanks for outlining this again, but I might be a “special” user. I don’t really care for myself as I’m on the developer side, but I care for the users of my snap who complain about a “crash” (not a crash, it’s actually the restart) every time I push a new snap of my application.
The best I can do is suggest your solution to my users, but I would rather have a real solution.
I’ve outlined the above case as frequently the push back was to do better testing and slowly promoting the snap from edge to stable. In this case this would not have helped.
A workaround like you suggest would work. Downloading the snap and installing it manually is another (ugly) workaround to avoid updates for a specific snap.
- Martin
Updates happen on scheduled windows, not every time you push your snap. We’re working right now (@mborzecki is looking into this already) into pushing the scheduling to a monthly basis, which means people can schedule exactly what they want inside the month.
The primary goal is not to take control away from the user altogether, but to strongly encourage the practice of regular maintenance. Per conversation above, we’re working on multiple features that better support this idea, wider scheduling being one of them, and epochs being another, both in progress (health checks too, but not yet in progress). We also haven’t ruled out doing exactly what you suggest, and simply introducing a global refresh shutdown flag. The reason we haven’t done that yet, again, is because once we go there we cannot take it out, and that one chance of trying to establish new practices around this problem is gone.
If you can do what @denis suggests for the time being for the unbearable cases, and stick with us while trying to see if we’re able to move forward with the paradigm of automatic refreshes being the common rule, then we’d also be very happy to continue learning from your experiences (positive and negative) with those mechanisms so we can jointly understand how far we can take it.
^^ This behavior would be desirable for our application. We have an auto-update built in to our application that allows us to update the app without updating the snap. We allow our users to set the maintenance window that we would like any updates to conform to. Even though we don’t have to update the snap to update our application, there may be times when an update to the snap is necessary and we’d love to be able to have the snap refresh conform to the maintenance window set for our app.
Any word on a timeline for this feature?
We don’t have a timeline on that part of the feature just yet. The high-priority changes which are already in progress aim at increasing control on the user side.
Maybe I’m late for this discussion, but I want the developers to know how necessary is to give the users the option to disable the autopdates. Imagine for a moment that you live in a 3rd world country where 40 people share a 1Mbps link and suddenly all of them start downloading the ubuntu-core update. That’s the case where I work. Microsoft Windows 10 is banned in our environment until we hack it and prevent it from autoupdating. The process is complicated, but doable. With snapd is hardcoded, so our only option would be to download the sources, disable the autoupdate in the code, compile, deply, etc and that’s insane. Implementing scheduling will take you time, giving the users a way to disable autoupdates will take you a couple of hours at most and will make everybody happy. Give the users freedom. Thank you for the all hard work and please think again about this issue.
6 Likes
‘everybody happy’ except when some vulnerability which would’ve got fixed by updates gets exploited. It seems monthly refresh scheduling will be out by the end of January or so (there’s no release dates for snapd 2.31 yet but it looks like it’ll be in that) or a few weeks earlier if you refresh to the snapd 2.31 beta when it comes out. See The snapd roadmap
I agree with your sentiment though, it would be faster to implement an automatic refresh disable switch, and would respect users’ control…but it seems the snappy developers would rather go for the long haul here and instead try and meet all users’ needs without implementing that switch. Do they need to allow refreshes to be capped at a certain speed? Managed across all your devices at a higher level? Give a longer refresh window than one month? I’m sure they will seriously consider and implement suggestions that don’t involve an off switch, so this is the place to make them!
By everybody I mean, everybody who wants to disable it for some reason. While I support 100% reasonable defaults, I also think people should be able to override them if necessary. Life’s entropy can prove any configuration, default or decision wrong. While updates are usually good there are a thousand edge cases where they are not desirable or can be even dangerous.
The current thread is about disabling the automatic refresh, so this should the right place to suggest a switch off. If snapd developers don’t want to listen and want to continue thinking their users are children who cannot handle the consequences of disabling automatic updates, then probably many will stop using it.
Another option is also to point api.snapcraft.io to 127.0.0.1. Sysadmins with low bandwidth on their networks could also implement it for their whole networks at the DNS servers.
5 Likes
Looks like refresh scheduling planned to land in snapd 2.31 which will help mitigate this problem (as previously noted by Niemeyer). 2.31 is due to be released 12th February. Presumably it’ll be in edge soon (or is already), I don’t know when it’ll be in the other channels.
As previously discussed, this doesn’t fully mitigate the problem that people have here, but it’s something 
Perhaps it is advisable to consider creation of a store proxy which allows interception of legitimate store requests and caching the binaries delivered in the response while allowing everything else to occur synchronously?
1 Like
RC1 is there now, RC2 will be coming tomorrow morning.
1 Like
Is there documentation for this? I can only find https://docs.ubuntu.com/core/en/reference/automatic-refreshes, and it doesn’t describe how to set the update time.
Probably not yet, someone needs to add something under #doc ideally.
To see now how to use it, see here for the command and then use the appropriate syntax here for the end of that command (assuming there weren’t changes in the PR that deviated from that design…)
1 Like
There’s some documentation on it already actually, under the core configuration options. The monthly style isn’t there yet, though, because it’s only coming in this next release. We need to update it to cover that indeed.
2 Likes