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.
Well, my suggestion sounds better in my mind.
Time flies (and I forget), or I go away from my current company and I forget to say to the new sysadmin : “Look! The foo package is manual because $reasons!”.
If there is something like a snap.d configuration directory like in my previous post, he will go to see this directory and he will remove or edit the configuration.
Because it seems the solutions proposed right now is global, but something like this could be needed:
Package foo: will update every x time
Package bar: will never update automatically. Only when I tested on the staging server.
I’ve spent months hunting down why my multi-day jobs on microk8s often fail.
Someone in microk8s said an update occurred at about the same time as one of my crashes.
Is there a log of snap update activity?
Is there no way for me to schedule the updates for when it’s convenient?
snap changes
ID Status Spawn Ready Summary
382 Done yesterday at 18:08 CST yesterday at 18:08 CST Running service command for snap "microk8s"
383 Done yesterday at 18:08 CST yesterday at 18:08 CST Running service command for snap "microk8s"
384 Done yesterday at 18:08 CST yesterday at 18:08 CST Running service command for snap "microk8s"
385 Done yesterday at 18:08 CST yesterday at 18:08 CST Running service command for snap "microk8s"
386 Done yesterday at 18:08 CST yesterday at 18:08 CST Running service command for snap "microk8s"
From this, looks like snap can be daemons or app. Is this correct ?
snap change 382
Status Spawn Ready Summary
Done yesterday at 18:08 CST yesterday at 18:08 CST restart of [microk8s.daemon-etcd]
john@john-trx40-designare:/var/log$ snap change 383
Status Spawn Ready Summary
Done yesterday at 18:08 CST yesterday at 18:08 CST restart of [microk8s.daemon-containerd]
john@john-trx40-designare:/var/log$ snap change 384
Status Spawn Ready Summary
Done yesterday at 18:08 CST yesterday at 18:08 CST restart of [microk8s.daemon-apiserver]
yes, snaps can contain daemons, apps or simply data … you should start a new thread if you want to go on discussing this though, it is kind of offtopic for this (already huge) “automatic refresh” thread …
It’s not a general statement against or even about anything, it’s just my personal preferences, so don’t be offended.