What about stopping and disabling snapd service?
Stop/disable when I am working on critical activity and don’t want snap updates:
sudo systemctl stop snapd
sudo systemctl disable snapd
And when I want to refresh snaps I enable and start service:
sudo systemctl stop snapd
sudo systemctl disable snapd
And if I want to manually update all snaps:
sudo snap refresh
Will this stop updating snaps or is there some other program that can trigger snaps updates?
I have also found a “socket” and disabled it:
sudo systemctl stop snapd.socket
sudo systemctl disable snapd.socket
Anything else to stop?
Forced automatic updates without off-switch are really a nightmare and definitely a no-go.
I understand considerations about that to enforce it but… i dont want to be patronized. I am updating often, so this is not a problem.
I want to control when and what i will update, especially at work. No, really no time frame will ever match my own schedule for things like this. It depends on the current situation and to update this in snap every time just to match it is kind of… annoying. A tool like this should help me and make things better this way… otherwise it is just wasted time.
A dev that never worked as SysAdmin will not see autorefresh as a problem… theoretically is good, because is updating “is great and get security updates”, but practically and in enterprise production, auto-update crash things, whe are humans, and the stable branches has issues too (like this one with dqlite & microk8s), so the advice that everyone get is to put the 127.0.0.1 api.snapcraft.io into the servers hosts file, really??? this is the way for a “production” ready tech??? i think that is a joke… please devs, you’re doing a great job, but don’t think only in your environment, so, let the most configuration options to allow the soft be configured by us the sysadmins too. Because even i can’t change the snap repository URL to even create a caché of packages… ufff really is a mess… This is like a Microsoft task on ubuntu dev pannel…
really??? a global switch is an issue??? tell that to my cluster that crash with your insane auto-scheduler…
It doesn’t work for some “platform apps” too. E.g. IntelliJ: Snap update for IntelliJ (already maximal deferred btw) -> Plugins in IntelliJ broken due to new version
Yes, i can stick the version etc. But again, snap introduces more problems than it solves with this paradigma.
If I want to have my system 10 years outdated, that’s on me. It’s MY system, not yours.
This is a never ending topic that is discussed. From my experience snap is more useful for desktop environment but you can also use it on servers for small applications.
If you need an enterprise level product it’s better to go with other container technology.
There are allot of good points being made here. Snaps for enterprise server software are dangerous with this level of auto update technologies. I would love the snapcraft store to create a new option inside the yaml file for auto update = false. Add the ability for vendors to pick and choose how old based on versions the snap will stay non updated. Then if it falls outside that, it will auto update but not 4 times a day. That could do real damage when using 24x7 enterprise apps on servers or kiosks with CORE os. Let the developers have full control over when the updates happen, so we can properly support our clients with our support contracts.
If the snap dev team adds more update flexibility and features, we will likely see an o crease in the creation of snaps for business software.
I disagree.
Let’s pick the flagship server application snap (Nextcloud) as an example.
If you really want to stick with an old version you can do that simply from the store pointing at the desired channel level. Till the point the software goes out of support.
Even the most important production system must have scheduled downtime for security maintenance (at least once a month IMO). Snaps allow you to scheduled it in a reasonable ammount of time.
Last point, as I commented earlier:
You would like to have HA, Redundancy and scalabilty that you would not achieve with this technology. If you are in such a mission critical situation you should reconsider your infrastructure.
It’s totally fine for me to stop the service, have updates AND BACKUP at 4AM every day when my NC users are 5. If you need to manage 100+ users, you might have different availability needs… and I would choose different tecnology.
you can set an exact schedule for updates with the snap refresh --time= command to only have a device refresh going on at a picked time …
if you commercially use Ubuntu Core you should simply use it with a brand store that gives your developers exactly these capabilities …
I don’t want developers having control over operations on my system, I want my system administrators to have control over my system, these developers might not even remotely know what is good for me or my business.
Only allowing some control, and only in a few areas, forcing administrators to bend to this software’s opinion (and not the other way around) is unacceptable. Full stop. No discussion around it. Setting a “time period” of refreshes is not a solution.
I do not tolerate Canonical’s encroachment of taking away power from the system administrators, thinking that they know what’s good for them, I never have, and never will.
I will continue to disrecommend Snapcraft (and by extension, Canonical’s entire proprietary ecosystem) for these reasons.
but the person i answered asked for exactly this when using fleet-managed IoT devices (digital signage kiosks on Ubuntu Core) …
… that said, developers always have full control over what they release when for your operating system (be it to a deb archive, a PPA or the snap store) …
for administrators there are enough options (that have been worked out closely with enterprise customers BTW) for setting proper maintenance windows within an annual quarter.
enterprise admins not doing regular scheduled maintenance windows at least once a quater are irresponsible IMHO
…and administrators always had the time, flexibility, and freedom to make up their minds when to patch, update, or delay on their own merits, then snapcraft prohibits this, so this is not an argument.
Also, developers do indeed push out updates whenever they want, they also push out bad or rushed updates, I do not want a (potentially) malicious, negligent, or unreliable developer breaking my system every few weeks (see; Windows), I do not want their schedule to hold hostage over mine, and to think otherwise is simply an admission that y’all rather want to treat administrators like children who have patched their security updates way too late way too many times, and that is exactly the wrong way to go about this.
snapcraft prohibits nothing, snapcraft is a build tool to create binaries from source trees … (sorry for the nitpick) …
nothing is taking away flexibility from admins here, in fact snap packages add flexibility:
no developer can push directly to the stable channel in the store which makes it easy for an enterprise admin to run a test system that uses its snaps from the candidate or beta channels to catch and report issues before the developer releases to stable.
admins have all the flexibility and even a lot more with snaps by design for integrating with their CD and test pipelines except that they can not hold back updates forever …
Outside of Ubuntu Core, you can trivially build your own version of snapd which would let you push back updates infinitely, it comes down to one variable in the source code.
Canonical has given you have the freedom to make bad choices, the software is GPL. What they haven’t done is gone out their way to actively encourage it.
My comment applies to snapd then (sorry for the confusion), but my point still stands, while snapd is in the perfect position to automate workflows for the administrator, in my opinion it has merely constrained the possible flexibility by not allowing the full degree of control. How hard is stopping all snap updates? Very hard, apparently, and for no other reason than “we decided it so” from canonical, because canonical thinks it’s better for administrators to be stripped that power, because canonical treats them like misbehaving children.
I can understand fully to take away this control from users; that is not what I am referring to. But canonical promotes snaps in Ubuntu server installs, meaning it officially endorses and recommends using it for server installs… while providing no extra control than users normally get. I am referring and arguing for the purpose of this usage, for the purpose of snaps being pushed onto admins, which’d then later on would encounter they don’t have control to stop a potentially breaking update over their systems, or have one breaking their systems on a (proverbial) Friday.
“Just fork it” is not an argument, certainly not when the distribution of the binaries is so tightly integrated in all of the systems. This isn’t about my own usecase, this is about the hundreds of people who have complained about this exact issue, they don’t have the time to maintain a fork, they don’t have the time to deal with this issue, and they’re trusting canonical to hear their preference.
Does it? Please point it for me.
And even if it’s one single variable to implement all of this, it is simply absolutely ridiculous that canonical doesn’t enable it by default, when so many people have asked and lamented about this exact feature.
well, for a creative and “flexible” admin it can be achieved with a single line entry in /etc/hosts to simply prevent access to the snap store (that you indeed need to remove when wanting to install or refresh something for your users)
That is not a solution, that is a hack, a hack to get around snapd because snapd doesn’t provide this functionality natively.
To change this is also a hack of sorts, yes you can change and swap this out for a time period of functionally infinite, but that is no proper support.