although this seems like a lost cause: I would like to get in line with the many others who very much can’t live with automatic updates and urge you to overthink this horrible design decision. We need an opt-out from auto-self-breakage. The argument is, that whenever there are auto updates, there will inevitably be auto-self-breakage. I myself experienced that multiple times when my intellij snap updated (plugins didn’t -> intellij broken, hours productivity loss). Please think about it: while things may look differently on server side the hard truth about linux on desktop is, that even core applications just don’t go through the same level of quality assurance that core desktop applications of other OS’s enjoy. This fact does not change just by having a snap daemon that just auto-updates everything. By enforcing said behaviour, you are enforcing instablility also upon people who could manage it. This is the opposite of what you want, I think
Yes, this was one of the solutions, there is always a way to fix it. But I’d rather only get into this situation at managed points in time. No offence, but the solution can’t be that I have my computer periodically gamble behind my back, possibly on my mobile internet bill, with a - in the case of intellij - 2/3 chance of breakage and having me to repair it.
Run sudo snap set system refresh.metered=hold, and head to your Wi-Fi Settings and set the relevant networks to ‘metered’ if they haven’t already been detected as metred. Snaps will no longer update whilst you’re connected to mobile internet, so you won’t get a mobile bill from automatic snap updates.
You can do this. Run sudo snap set system refresh.timer= and use the options in the documentation to set the points in time you want the snap to refresh. If one of these points of time are approaching and you can’t update on that occasion, run sudo snap set system refresh.hold= and use the correct format for the date as detailed in the documentation.
Please also mark yourself affected by my bug report to get all of these options into Software & Updates so that they are accessible graphically and not just via the command line.
If any of these options are inadequate for your purposes, as per the very long discussion about the automatic refresh feature above (please read it all if you can as there has been significant engagement from the developers on this feature and a lot more control over it is now available to users than there was previously), please specify exact (preferably real) use cases which the status quo is not adequate for and please explain exactly what you need to cover that aside from a straight-up off switch, which (former? He doesn’t seem to be an admin anymore or posted recently, who’s in charge now (aside from Shuttleworth, that is)?) snapd head @niemeyer was opposed to unless it can be shown that there’s literally no other way to deal with a real use case without an off-switch.
There’s also an extent to which if you oppose the anti-off-switch approach entirely then obviously this dispute has been going on for a long time and the developers do say that, ultimately, if you don’t like snappy’s approach, you probably should go elsewhere (Flatpak is the main solution that comes to mind).
There’s actually an even more straightforward way to completely disable automatic updates.
Instead of running snap install foo, you can actually use snap download foo ; snap install foo.snap --dangerous (or something along those lines). What that will do is, completely safely (still from the store etc!), sideload the snap onto your system, so that it won’t get updates from the store. You can then manually update the snaps as you wish by installing the new snap manually by running snap download foo ; snap install foo.snap --dangerous again (not sure, might be that it’s snap download foo ; snap refresh foo.snap --dangerous), point is that you can work out a one-command way of manually downloading and installing updates. It is, of course, not recommended, but if you want full control of your updates the option is there. The reason why the flag is --dangerous is because what you’re doing is considered dangerous by snapd firstly because you could be sideloading some completely random snap which could be malicious (but if you’re sideloading from the store with snap download foo ; snap install foo.snap then it won’t have been considered malicious by the store at the time you downloaded the snap, the only other way it’s dangerous is that, as you have intended, you will no longer get security and other updates for that snap automatically).
Note that method won’t allow you to sideload (disable updates for) the core snap I don’t think (though I suspect it may still be possible to sideload base snaps like core16), but since snaps contain most of the dependencies they need anyway, that shouldn’t be a huge problem…
Reading this thread was very depressing. I’m a long time Ubuntu user and I am sad to have to quit it over this. I’m not going to argue or give use cases. That’s already been covered. This is just a vote. I find the stance taken by the Snap representatives unjustified and inexcusable and that’s the the most depressing part. It feels like a betrayal.
Forcing me back to the topic I said I would not revisit to get
possibly pertinent information is more of the same, in my
opinion, unjustifiable and inexcusable behavior.
In addition to that, the teaser blurb ends with "push updates"
which just looks like more user unfriendliness. Pushing is for
bullies, not for makers of “the worlds most popular open source
desktop operating system”.
This is an irrelevant link as it pertains to “desktop controls”. There is a small generic section about snap behavior, but mostly, it’s a discussion based on introducing control panel items. I’ll walk the plank on the assumption that most people running servers in any capacity above hobbyist don’t have desktop environments on the machine.
@rickan is right, anything short of an off switch alienates the server and power user portion of the community.
To be completely honest, I’ve had unattended upgrades enabled for a long while on over 250 machines because I have faith in Ubuntu’s definitions of LTS and non breaking changes.
It can default to enabled. This fulfills the snap teams objective of enabling 3rd party authors to push new code to your machine. I disagree with that fundamentally, but also understand it.
For the rest of us on the server side begrudgingly using snaps, we can turn them off, plan, and prioritize updates based on changelogs and availability to clean up the potential mess.
After talking with a friend about this, I’m still kinda ready to strike over my heart and assume that snap developers would have the best intentions for us, but I have a few questions and suggestions:
Who’re snaps aimed at? Users, developers, or system administrators? Do snaps have a home on homelabs and user laptops/desktops, or is the target audience inclusive of large-scale production servers?
Please give or release a “total control” version of snapd, where a sysadmin can define, program, hook and set up hooks and callbacks on certain events, to include the refresh features into their workflow, but allow their tooling and implementation to make the final say. (For example: allow rolling updates between a cluster of machines for a particular snap, but coordinate reverts when one of the machines fail, or ignore and uncordon that machine, depending on the severity. Allow sysadmins to roll out updates under controlled automated circumstances, where production load gets shifted to a temporarily-provisioned cluster on standby to hold the load during the update, or do the same if an update breaks.
(Probably a bit out of scope) Please provide clear feedback to the community regarding features and visions, but also please respect a community’s wishes if they demand or require a certain package-manager-standard configurational feature for their workflow, allowing them to take advantage of snapd with no catch.
I think the obvious solution is the same as with distribution specific package management tools and repositories. Some systems and some software should never be updated on the background - on others it depends on the application specifically.
First of all, you can have automatic updates, but they just aren’t acceptable at all for some systems; so implementing a global configuration option for disabling automatic updates on the background is a must if you don’t want to give up on those systems. Seems like you want more, not less users. You can bury the option behind Advanced options in the man pages and on GUI configuration options.
Disabling automatic updates doesn’t have to, nor it is supposed to mean that you won’t be notified of them. Personally I choose to not allow automatic updates at all, but I do run full system upgrade via package manager as soon as I have time to review it through enough (most of the time I just glance it through with my mental filter adjusted to pinpoint any packages I might need to inspect (=mostly just read the changelog, but in case of browser updates or other software that I prefer or need to behave consistently and have to know if there are any important changes in how they behave). I look for the desktop statusbar notification widget for any pending updates on daily basis. Only on Android devices I have chosen to have automatic background updates on, and that’s because it took way more time than I have to check them all through. Plus I’m way more vary about security issues on Android platform. Software updates, especially on proprietary software, are something way too critical for me to allow happening without my full consent. I bitterly accepted snap for one application, WickrMe, because it was not available as .deb, .rpm or .tar archive anymore, but only on two of my several different laptop and desktop PC’s, because I needed it. And I’m not happy about it. Thankfully I now know that no package I install through APT (I’m using Linux Mint) will never install a snap package behind my back!!!
There should be a way to exclude any specific software package from either one or both, automatic updates and manually executed “full upgrade”. Some packages simply need to be listed when user requests information of available updates and show by a notification window and/or widget on graphical environment, but only updated when specifically requested. On GUI you can list them on update window with check boxes that are not checked by default. It’s an advanced configuration option, it may not even need to be shown on the GUI at all to exist, but there has to be a documented way to add packages to list of those excluded from updates unless the user selects to update it. That way it wouldn’t surely be used by users who haven’t got understanding of what they are doing. This option also is more important than any above, because you can use this to achieve the most important things, even if cumbersome way. If you won’t implement the two above, this is the very bare minimum that you should do if you want to include users who choose (yes, it’s an important preference) or need to prevent automatic and un-reviewed (by the system administrator) packages from being installed without their approval when such thing is important to the administrators or functioning of systems they administer. You must understand what the guy is saying: you simply can’t run a reliable server if it updates certain software automatically on background. It’s just not an acceptable option as would be obvious if you had thought the original posters issue through - there’s no schedule window that can fix this problem. And holding minor versions on independent tracks is not enough at all - you’re starting from the wrong end, because it’s often not security patches or minor changes that end up breaking the system but the major ones. Server administrator need to review every major version updates for this very reason. You need to understand this or declare clearly your system to be unfitting for software that needs to be reviewed by local administrator before updating them - and by doing that you’re shutting doors for any professional server use (or competent server administration anywhere).
I have no other strong opinions about this. Snap is not the kind of system I would ever like to prefer as my primary software package system no matter what changes; and the reasons for that are various and often personal preferences, it can’t be fully mitigated by fixing flaws like this in your system, it’s the nature of how it works more than anything, but that’s why we have options for users with different preferences, don’t we? It’s not a general statement against or even about anything, it’s just my personal preferences, so don’t be offended.
Yes: Chrome (on Windows), Firefox (on Windows), Chrome OS
I have no expertise on Chrome OS, but I would expect it to follow the same route as Android, in which you have the option to disable updates to both apps and the core OS. For Chrome and FireFox, you have an option to disable automatic updates (and they will still notify you).
It shouldn’t be too hard to tweak the automatic refresh behavior if one is willing to build one’s own version of snapd (in a PPA for instance). The auto refresh logic appears to be mostly contained in the source file https://github.com/snapcore/snapd/blob/master/overlord/snapstate/autorefresh.go. Of key importance is the maxPostponement parameter which is currently set at 60 days.
First of all, hello everyone, this is my first post ever.
I must say installing LXD via snap is super fast and easy.
But I have a possible problem:
let’s say I have a Ubuntu or Debian server with LXD installed via snap.
LXD got updated, but there is a bug which kills LXD because sh!t happens.
There should be, imho, a flag somewhere to keep some packages at a specific version (because I want another snap get always updated because reasons), and after some extented testings I’ll update the snaps manually, I can’t risk every day to see some important services broken, and recover a backup (which will be broken again because snapd tries to update my package again)
Or at least create a fork of snapd for servers called “Snap Pro” or something else and leave the option to make the sysadmins owners of their servers.
EDIT: if it could be helpful I can open a ticket on snapd launchpad with this request tomorrow, right now here it’s 1:15 in the night and my brain is going to standby
Following up on my earlier post, wouldn’t changing the maxPostponement constant in autorefresh.go from 60 days to 60 years effectively allow you to disable auto updates?
which sounds like a workaround like the manual download with the --dangerous switch or edit the source like @casey did.
Here an idea:
in /etc/default/snap.conf we can make a parameter called “manual” or something else. Default is 0, if someone puts the value 1, the manual management for single snap is enabled.
somewhere else in a directory called snap.d , we can make a configuration file (like a json or yaml) . Every file is the name of the snap app (let’s say “foo.conf” for the package “foo”)
Inside this foo.conf we can decide when to update the single package (with the already written configuration and logic, or even with a cron-like syntax.), and if there is something like “noupdate=1” directive, the package is ignored by the refresh.
When I want to update a package with “noupdate=1” or I delete the configuration file or I put a schedule inside the configuration.
A neat thing to do: could be interesting to pin a package inside this configuration, like I want only the channel of “LTS 4” of LXD, but IIRC it’s not necessary because when you install a snap you can do already something like that.
If there is no .conf the refresh of the package follows the standard configuration.
It’s not a general statement against or even about anything, it’s just my personal preferences, so don’t be offended.