ah ok. that makes sense. i figured i was missing something
Thank you for clarifying
Hi,
I’m trying to design a quick survey to give a perhaps wider perspective on how users, and contributors feel about this feature. My hope is that it will provide some insight to the number of people impacted by this, and some of the issues they’re facing.
Bellow there’s a straw poll with the sorts of questions that I believe could further inform this discussion.
https://www.strawpoll.me/18409903
I’d love to get some input.
thanks!
Edit: typos
4 Likes
Most of you think this is a technical matter. It isn’t.
This is a way for Canonical to
- Wrest as much control from us as possible
- Create their own app marketplace
- Force us to buy, update and maintain according to their schedule, not ours
It’s a business decision.
If it weren’t a business decision, and every sysadmin and power user everywhere would be opposed to it, then what would Canonical do? It would allow us to disable auto-updating, and apologise.
But they’ve stuck to their guns. Why? Because it’s a business decision.
It’s a private company, and doesn’t owe me a thing. But, this is precisely why I left Windows! And this is precisely why every time I upgrade a system, I replace Ubuntu.
I’m using linux because I want complete control. If you take that away from me, I won’t use your product. If you want to be the new Microsoft or Apple, good luck to you (I mean it, no hard feelings), but good bye.
3 Likes
What about only allowing the packagers (rather than the users) to disable automatic updates? Can’t we expect them to behave more “responsibly” than the users with this freedom?
packagers have full power over releases indeed. if you dont want to update your users, just keep your snap in a non-stable channel in the store (you have four by default) … push to stable only if you want to update …
1 Like
Snaps seem to be a great idea and I’ve already seen various improvements in the short time I’ve been using them. I don’t particular notice the speed problems people talk about.
Yet, this issue just seems like one where the business requirements of SNAP’s users don’t match what it is being designed for. It ‘looks’ to me like that snappy design team is viewing the SNAP store like the Google Play Store or something. Primarily something to be used by average users on their home devices (like smart phones). So… why not force them to keep it up to date?
Yet, the SNAP store is being viewed by its user base as a general linux application deployment system. The original post is really a great example of why the auto-update system breaks these use cases. If it’s doing any kind of services/networking, you can’t just have it auto update. Not to mention most organizations have rules and processes in place that they expect the software to be subservient to. Not the other way around. You don’t buy/install software and then rewrite your business processes. You buy/install software that meets your business processes.
I’d really suggest if this hard line is going to stand, just come out and say that the SNAP store is unsuitable for general enterprise use. Developers, such as the OP can then host local SNAP files on an FTP server or something. Their user base can then update it manually to their hearts content. Or maybe you push people on those cases to use private SNAP stores, where those kinds of options can be configured.
Alternatively, I really like one of the suggestions I read where there is a file where you can configure SNAPs which should not be auto-updated. You can even make editing this file require root. You can even mandate it is the exact file name, and not some regex. This would really emphasize that you need to add apps manually and not just * I really like this idea because
- It keeps apps up to date by default
- It makes non-auto-update apps an exception. For example, in the OPs case, his customers might only want to have his SNAP not auto-update. But other SNAPs which might not cause downtime can auto-update.
- The non-auto-update apps are all tracked in one place. This is great from an audit point of view; especially in the enterprise. To put it bluntly, whoever made that change to exempt that SNAP will be responsible if a non-updated app causes problems.
This could also be used in conjunction with a flag on the SNAP itself which indicates if the developer of the SNAP allows the SNAP not to auto-update. Feel free to have whatever process in place to approve that flag. That at least shifts the point of contention to developer-SNAPSTORE. For example, if there was ever a valid use case, the OP (networking products) should definitely get approved for such an flag. I just throw this in as no doubt you want to avoid everyone throwing that flag in there by default. You want to keep such things the exception.
4 Likes
sudo systemctl stop snapd.socket
sudo systemctl disable snapd.socket
This has disabled command line snap install & refresh so may work at the schedule level (tried on OpenSuSE Leap 15.1). I have captured the snap list in a file and will be comparing over the next few weeks to see if there are later revisions available and the revision status on my pc.
Obviously one must restart these to re-commence their functionality. I run a once annual update to the distro and if I were to allow snap auto-updating and one of my users was able to use a function from a later revision package on one computer but then sat at another and could not costs me support money. It’s that black and white.
1 Like
This issue sounds like a bug, could you please either start a new topic or file a bug on bugs.launchpad.net/snapd about this so we can take a look at that?
My Bad !!! need second morning coffee!!!
This is the actual report:
snap install blender --revision=34
yields
error: cannot install “blender”: Access by specifying a revision is not allowed for this Snap.
It looked like the maintainer of the blender snap is working on making the 2.81 and 2.82 versions of Blender available via tracks. This will mitigate the automatic update system you’re unhappy with. You’d be able to sit on the track required which contains 2.81 and stay there.
1 Like
As you can see I have only recently joined the discussion. I read all the posts. As an experienced systems administrator I Identified there were certain features that users without system admin exposure thought should be there but some may not have known the exact terminology required to articulate.
In short, it seems to me if auto-updating can be blocked/enabled at will and this easy to use ‘tracks’ system where by selective revisioning can be employed either for a home user machine, or across a pool of machines using a standard build (soe) this would summarily describe the management requirements of both home users and system administrators - and whilst there may be a little more invited to add to that description then SNAP certainly sounds like an evolved “repository” ecosystem highly worthy of application on many distros.
On a personal note I find SNAP satisfactory to my requirements because the audio/video multimedia apps are literally bleeding edge releases containing the h264/mp4 codecs that I would otherwise have to mix and match from the packman repository - which on an OpenSuSE Leap box can lead to all kinds of update source confusion down the track because of the arbitrary nature of it’s repository priority numbering.
So ‘hats off’ to SNAP as a solution.
4 Likes
The more I think about this, the more I think this should be pushed to the application developers.
SNAP already supports tracks. I couldn’t find if there’s a limit on the number of tracks, but assuming there isn’t, it should be up to the application developer to set tracks for versions.
So in the case of the OP, he can build out tracks for every version of his networking applications
1.1, 1.2, 1.3…
He could then tell his customer to choose a particular version to ‘stick to’. It would then be up to him to ‘not’ update his tracks so then nothing would auto update.
In the event of a security emergency, the OP still has the ability to ‘push an update’. Let’s say he’s at version 5.0, but there is a critical flaw in 1.1. The OP can then put in a fix for those branches and force an update. Which I think is the idea.
I think this kind of guidance would work well and offloads all this auto-update discussion to the applications themselves. If you don’t want auto-updating, bother the application developers to have a lot of tracks 1.1.1, 1.1.2… blah blah
For anyone who still doesn’t want apps to update, SNAP can push their store proxy as the way to stop that or fudging with networking.
A good write up for app developers and a page to point to would resolve offload all this from SNAP.
Don’t get me wrong, I still think you should be able to stop updates on a per app basis via an easy configuration or something, but if that’s really not in the cards, then I think the above makes sense.
Hi,
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
In this circumstance, did you try snap revert (snapname)? The entire purpose of snap revert is to go backwards to the last known good state.
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.
@jthr and anyone else on this thread not happy with the status quo:
@popey has done a fantastic video explaining all the commands one can use to control snap refreshes:
https://youtu.be/gVZOBgTDJWc?t=514
You can also read the options for yourself here.
For example, on:
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…
5 Likes
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.
I will not be looking at this thread again.
1 Like
in case you do anyway …
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”.
I am unsubscribing from “these emails”.
1 Like