Automatic updates are baked into snap’s DNA. If you didn’t want this, simply don’t install the snap.
Choosing this medium to install your dev environment and then getting cranky when it does precisely what it was meant to do seems a bit unintentionally disingenuous to me.
I’m not necessary arguing for the correctness of Canonical’s choices around snaps here, because I have mixed feelings about them myself, but they make it pretty clear at every available opportunity that this is how they work.
On a more helpful note, have you tried setting the refresh.hold system wide configurable which you could set to an arbitrary date years in the future?
There’s another part to the disconnect: Ubuntu is trying to replace the deb parts of (large parts of) its ecosystem with snap equivalents. Putting these two things together makes the picture pretty interesting. How are LTS releases supposed to work with this kind of setup? I’ve had bugfix releases of software introduce bugs that blocked my work. Not often, but it does happen.
Operationally, I wish updates were always automatically-update-on-a-schedule-I-define, a la Patch Tuesday or something similar. That seems like the only possible sane option, but it seems tragically rare.
That’s interesting I’d only heard of them doing this with Chrome. What else are you referring to if you don’t mind my asking?
For sure there are going to be problems as this is absolutely a radical departure from traditional UNIX vendor app update strategies.
Their assertion is that the auto-update feature was a key blocker to bring third party vendors who otherwise wouldn’t even consider supporting the Ubuntu platform to do so.
I think there’s some value in that, but as you say there are definitely kinks to be worked out here. On the up side the Ubuntu folks are pretty good about engaging with the community. I’d suggest pinging Snapcraft or Alan Pope on Twitter. It’s not his job but he’s often good about taking the time to help people past snap difficulties.
Now that I think of it, I think part of the disconnect is that vendors think of their software as an end-product that nothing else depends on, so Slack or Spotify or whatever can update their own little worlds without affecting anything else. In the real world however, people script things to download stuff from Slack or ask Spotify to do things, and so those applications changing can break others’ functionality. Even non-techies do this, mentally; how many people have complained to tech support when a silent, undesired application update “moved that damn button” and broke their workflow?
I would urge you to be sure to get both sides of the story on the Mint snap amputation.
I don’t have any issue with the decision itself per se but the way they handled it was IMO very unfortunate and unprofessional.
Specifically, the Ubuntu folks said they were totally willing to work with Mint to accomplish the removal in a clean way that makes sense technically, but that they were never approached.
IMO when you choose to base your Linux distribution on an upstream distro, you agree to abide by the technical decisions that upstreeam makes, or at least to work with them in evolving your remix/flavor in a way that makes sense. None of that happened here.
Yes. The differences betwen Docker and LXD are interesting. Docker provides a convenient packaging format and allows for layering of components to create application stacks.
LXD seems to want you to start out with a single image and seems to have better / more / deeper integration with system services like networking.
I’d love to see someone do an in depth technical comparison of thw two technologies.
Ubuntu is trying to replace the deb parts of (large parts of) its ecosystem with snap equivalents.
I’ve only seen evidence of this in the packages that are particularly challenging to maintain as debs due to the way particular upstreams operate. Browsers are an example where security backports aren’t feasible so the debs that have been shipped by most distributions have for years been “fat” anyway. Snaps are mainly solving the problems of IoT device updates, third party (both Free and proprietary) software distribution directly to users and the areas where debs are a poor fit, such as shipping wholesale featureful updates to users such as with web browsers. The traditional deb parts are not affected.
Operationally, I wish updates were always automatically-update-on-a-schedule-I-define, a la Patch Tuesday or something similar.
Disclosure: I’m a Canonical employee and Ubuntu developer (and a Debian developer, if we’re going there). I’m not involved in snap architecture at Canonical (though I do maintain some snaps as I do debs in Debian!).
Choosing this medium to install your dev environment and then getting cranky when it does precisely what it was meant to do seems a bit unintentionally disingenuous to me.
Agree. So what I say below doesn’t apply to the situation in the article.
but they make it pretty clear at every available opportunity that this is how they work.
They may make it clear how they work but they don’t make pretty clear when you are installing a snap. Starting Ubuntu 20.04 they’ve started installing snaps when you install a Deb
The reason the snap is installed is because the chromium browser moved to a snap so we could iterate faster and consume fewer developer resources packaging a non-default web browser for multiple releases. If we didn’t have the deb to snap migration in 19.10 (and 20.04) then users upgrading from 19.04 to 19.10 or from 18.04 to 20.04 would lose their browser.
We decided at the time not to punch people in the face during the upgrade and make them choose “Do you want to keep your browser, by migrating to the snap?” because those kind of mid-upgrade dialogs are pretty awful for end users. Generally the vast majority of the audience don’t actually care what packaging scheme is used. They just want to click the browser icon and it open.
Yes, we could have communicated it better. We’re working on improving it for the 20.04.1 update which is due next week. We certainly do listen to the feedback we get.
We decided at the time not to punch people in the face during the upgrade and make them choose “Do you want to keep your browser, by migrating to the snap?”
You could use the motd announcements to give people ample notice.
Please see my answer above to icefox’s assertion along the same lines. This is only for Chromium, and there are good reasons behind that choice (They were spending vast amounts of engineering time JUST on chromium).
As I said in that response, IMO Linux Mint is very much in the wrong here, and has handled the situation abysmally. They could have enacted the removal of snaps/snapd in a much cleaner way without all the drama, and they chose not to do that.
Please see my answer above to icefox’s assertion along the same lines.
Yeah, I saw it after I had posted this comment.
This is only for Chromium, and there are good reasons behind that choice
You are conflating two separate things. There may be good reasons™ behind packing Chromium as a snap only. There is no good reason to do so behind the users back. If one uses apt to install something one most certainly doesn’t expect to be installing a snap.
What you chose to call ‘drama’ is a political stance. The issue was not “to accomplish the removal in a clean way”. It was “This breaks one of the major worries many people had when Snap was announced and a promise from its developers that it would never replace APT.”. You may not like or agree with that position but there is nothing wrong with that.
Also it is disingenuous to think this will stop at Chromium. Chromium is just for testing the waters.
# What version do I have installed?
$ snap info caprine | tail -n 1
installed: 2.47.0 (37) 66MB -
# Is there a pending update? (yes)
$ snap refresh --list | grep caprine
caprine 2.48.0 38 sindresorhus -
# Refresh blocked while app is running (experimental setting, should land "soon")
$ snap refresh caprine
error: cannot refresh "caprine": snap "caprine" has running apps (caprine)
# Let's kill the app
$ sudo killall caprine
# Try refreshing again
$ snap refresh caprine
caprine 2.48.0 from Sindre Sorhus (sindresorhus) refreshed
# Let's revert it because the update was terrible
$ snap revert caprine
caprine reverted to 2.47.0
I appreciate you’re “burned” by this and will likely switch to Mint, so this information may be academic, but for others stumbling on this thread it may be handy. Hope Linux Mint works out for you.
I’d not expect the Allen Pope to respond, you only exist in my podcasts :). How cool!
Now on point, also responding to the revert comment earlier. I did find that, but my point is about not being able to disable updates, not about not being able to rollback. Rolling back would not have been necessary if I could have done the update manually in two weeks, after which the plugins of the IDE would probably have been updated as well. I do however appreciate the option to rollback.
You also state that there are ways to disable updates and give the example of sideloading an application, after which it never gets updated. That also is not my main gripe. I do want my cake and eat it, but not automatically. As in, I want to update when I’m ready and expect it, not changing the engine while the car is driving on the highway.
Is there an official way to disable automatic updates? However hard to setup, with big red flashing warnings, promising my firstborn to whatever deity? Setting a proxy or hosts file might stop working, an “official” way would still give me all the other benefits of snaps.
As said, I do like updates and easy of use (not manually sideloading ever snap, just apt upgrade all the things) with just a bit more control.
There’s currently no way to fully disable completely all updates. I appreciate that’s hard news to take. However, I have been having many conversations at Canonical internally about the biggest pain points, and this is clearly one. Perhaps we could add a big red button marked “Give Alan all my cats, and also disable updates forever”. Perhaps we could really forcefully nag you with irritating popups once you get beyond the 60 days limit that’s currently set, I don’t know. But I agree, something needs to be done here, especially for desktop users who are super sticky on particular releases of their favorite tools.
It’s Friday night, and I’m enjoying family time, but rest assured I’ll bring it up again in our meetings next week.
What about a big button to disable automatic updates, and then give initially gentle, gradually escalating nags once updates are available?
Maybe in the handy “Software Manager” popup UI we’ve already got built. Checkboxes to select which ones you want to update. Make it really easy to “accept all”, after my workday is over.
Did you use windows 10? Did you read the comments when Microsoft did similar? They were heavily criticised there was a vocal cohort of users annoyed even by that. When I was near a deadline and my windows told me I cannot postpone updates anymore and broke my flow I happened to understand them.
This is a hard UX problem, despite how simple one might initially see it.
It is a problem but not that hard. A simple matter of control. Do I update or not? .hold? Then not. It’s perfectly feasible to add a ..hold.forever. Your workflow is not broken sms 99%of average Joes have the latest everything.
Now, this is just my opinion as am old schooler used to absolute control of my computing. I gladly let everything be automated until i don’t.
It is hard of you wish to please a wide range of users, ranging from novices to power users, and wish to provide a UI serving the different needs of these different cohorts. I mean it is hard if you want to do it well. :) Microsoft tried hard, and did not get it IMHO. Other vendors fail even more miserably.
Automatic updates are baked into snap’s DNA. If you didn’t want this, simply don’t install the snap.
Choosing this medium to install your dev environment and then getting cranky when it does precisely what it was meant to do seems a bit unintentionally disingenuous to me.
I’ve seen snaps come up on lobsters before but had no idea that they automatically update with no option to disable the updates. I thought they were basically like Canonical-flavored docker containers.
Thankfully I saw this post before I update my laptop next week. I’ll be avoiding Ubuntu and their snaps for now.
I’ve seen snaps come up on lobsters before but had no idea that they automatically update with no option to disable the updates. I thought they were basically like Canonical-flavored docker containers.
Couple of important differences between Docker and snaps.
Docker containers leverage Linux’s cgroups feature to offer each container it’s own pretty much complete Linux userland.
So that means that you can, as a for instance, have 3 containers all running on a Fedora system, one Alpine Linux, another Ubuntu, and a third something else.
Snaps, on the other hand, are application containers. They just bundle the application itself and any libraries that are necessary to run it.
Thankfully I saw this post before I update my laptop next week. I’ll be avoiding Ubuntu and their snaps for now.
And that’s the beauty of the Linux ecosystem right? :) I’d guess more people on here are Debian or maybe Arch users :)
Many HPE servers have a dedicated network ports for the iLO card but can also optionally share one of the regular network ports if needed. When in shared mode, you can indeed configure a VLAN tag for the management traffic, which can be different to the VLAN tag used by the host operating system normally.
Unfortunately, in the same way that chris explained that a any compromised host might be able to switch the device IPMI mode from dedicated to shared, using a VLAN for segregation can have a similar problem. If the compromised host adds a sub-interface with the tagged VLAN to their networking stack they now can gain network access to the entire IPMI VLAN.
In addition there are other annoyance with using a shared interface. Because the OS has control of the NIC it can reset the PHY. If the PHY is interrupted while, for example, you’re connected over Serial over LAN or a virtual KVM, you lose access. If you’re lucky, that’s temporary. If you’re really unlucky the OS can continually reset the PHY making IPMI access unusable. A malicious actor could abuse this to lock out someone from remote management.
That can’t happen when you use a dedicated interface for IPMI (other than explicit IPMI commands sent over /dev/ipmi0). Generally switching a BMC from dedicated mode to shared mode requires a BIOS/UEFI configuration change and a server reset.
(Speaking from experience with shared mode and the OS resetting the NIC. The malicious actor is merely a scenario I just dreamt up.)
Indeed, although I suspect in many cases these IPMI modules are already accessible from the compromised host over SMBus/SMIC or direct serial interfaces anyway - possibly even with more privileged access than over the network. That’s how iLOs and DRACs can have their network and user/group settings configured from the operating system.
The increased risk mostly isn’t to the compromised host’s own IPMI; as you note, that’s more or less under the control of the attacker once they compromise the host (although network access might allow password extraction attacks and so on). The big risk is to all of the other IPMIs on the IPMI VLAN, which would let an attacker compromise their hosts in turn. Even if an attacker doesn’t compromise the hosts, network access to an IPMI often allows all sorts of things you won’t like, such as discovering your IPMI management passwords and accounts (which are probably common across your fleet).
The L2 feature you are looking for is called a protected port. This should be available on any managed switch, but I’ll link to the cisco documentation:
In a previous life at a large hosting we used this feature on switch ports that were connected to servers for the purposes of using our managed backup services.
This is a response to that article, basically taking an position entirely counter to it, not a repost of the original. I’m not sure if this is suitable for folding?
It is, it keeps the discussion together, and (though this isn’t one) it disincentivizes hot takes by not rewarding them with their own slot on the front page.
I appreciate the motivation, but I still find it disappointing and unfair that newer (and frankly, higher-quality) content is merged away from the front page where few will see it.
I’m not sure that this is technically how folding works, but it appears that if multiple links are posted to similar topics within a time-span of roughly a few days, then they all share the “popularity factor” of whichever was posted first.
I feel like, if an article spurs multiple other people to write about the same topic (as happened in this case), then people are still talking about this topic, and so deserves at least one spot on the front page.
Maybe the comment threads could all be merged, but individual links preserved? Or all links on the topic could share the highest “popularity factor” instead?
Yep! We’re a telecommunications and cloud training company and love writing about the tools and techniques we learn in order to deliver awesome hands-on training.
We’re glad you liked our posts! Many more are in the works!
Maybe a generic regex filter would accomplish the same thing without then needing a tag for every language/company/software?
Do you mean each lobste.rs user creates custom tags (regular expressions to filter on) for their own account?
The purpose of tags are for discovery, filtering, and scope. That would throw out the latter, hard.
I see a fundamental disconnect here.
Automatic updates are baked into snap’s DNA. If you didn’t want this, simply don’t install the snap.
Choosing this medium to install your dev environment and then getting cranky when it does precisely what it was meant to do seems a bit unintentionally disingenuous to me.
I’m not necessary arguing for the correctness of Canonical’s choices around snaps here, because I have mixed feelings about them myself, but they make it pretty clear at every available opportunity that this is how they work.
On a more helpful note, have you tried setting the refresh.hold system wide configurable which you could set to an arbitrary date years in the future?
There’s another part to the disconnect: Ubuntu is trying to replace the deb parts of (large parts of) its ecosystem with snap equivalents. Putting these two things together makes the picture pretty interesting. How are LTS releases supposed to work with this kind of setup? I’ve had bugfix releases of software introduce bugs that blocked my work. Not often, but it does happen.
Operationally, I wish updates were always automatically-update-on-a-schedule-I-define, a la Patch Tuesday or something similar. That seems like the only possible sane option, but it seems tragically rare.
That’s interesting I’d only heard of them doing this with Chrome. What else are you referring to if you don’t mind my asking?
For sure there are going to be problems as this is absolutely a radical departure from traditional UNIX vendor app update strategies.
Their assertion is that the auto-update feature was a key blocker to bring third party vendors who otherwise wouldn’t even consider supporting the Ubuntu platform to do so.
I think there’s some value in that, but as you say there are definitely kinks to be worked out here. On the up side the Ubuntu folks are pretty good about engaging with the community. I’d suggest pinging Snapcraft or Alan Pope on Twitter. It’s not his job but he’s often good about taking the time to help people past snap difficulties.
My main source is https://lobste.rs/s/9q0kta/linux_mint_drops_ubuntu_snap_packages, which links to https://lwn.net/Articles/825005/. Chromium seems to be the main program currently, but the LWN article mentions work ongoing to apply it to other things like
gnome-software. Seems safe to assume that the trend is going to continue.Now that I think of it, I think part of the disconnect is that vendors think of their software as an end-product that nothing else depends on, so Slack or Spotify or whatever can update their own little worlds without affecting anything else. In the real world however, people script things to download stuff from Slack or ask Spotify to do things, and so those applications changing can break others’ functionality. Even non-techies do this, mentally; how many people have complained to tech support when a silent, undesired application update “moved that damn button” and broke their workflow?
I would urge you to be sure to get both sides of the story on the Mint snap amputation.
I don’t have any issue with the decision itself per se but the way they handled it was IMO very unfortunate and unprofessional.
Specifically, the Ubuntu folks said they were totally willing to work with Mint to accomplish the removal in a clean way that makes sense technically, but that they were never approached.
IMO when you choose to base your Linux distribution on an upstream distro, you agree to abide by the technical decisions that upstreeam makes, or at least to work with them in evolving your remix/flavor in a way that makes sense. None of that happened here.
LXD is another example
Yes. The differences betwen Docker and LXD are interesting. Docker provides a convenient packaging format and allows for layering of components to create application stacks.
LXD seems to want you to start out with a single image and seems to have better / more / deeper integration with system services like networking.
I’d love to see someone do an in depth technical comparison of thw two technologies.
I’ve only seen evidence of this in the packages that are particularly challenging to maintain as debs due to the way particular upstreams operate. Browsers are an example where security backports aren’t feasible so the debs that have been shipped by most distributions have for years been “fat” anyway. Snaps are mainly solving the problems of IoT device updates, third party (both Free and proprietary) software distribution directly to users and the areas where debs are a poor fit, such as shipping wholesale featureful updates to users such as with web browsers. The traditional deb parts are not affected.
You can configure snaps to do that that: https://snapcraft.io/docs/keeping-snaps-up-to-date#heading--controlling-updates
Disclosure: I’m a Canonical employee and Ubuntu developer (and a Debian developer, if we’re going there). I’m not involved in snap architecture at Canonical (though I do maintain some snaps as I do debs in Debian!).
Agree. So what I say below doesn’t apply to the situation in the article.
They may make it clear how they work but they don’t make pretty clear when you are installing a snap. Starting Ubuntu 20.04 they’ve started installing snaps when you install a Deb
https://blog.linuxmint.com/?p=3906
The reason the snap is installed is because the chromium browser moved to a snap so we could iterate faster and consume fewer developer resources packaging a non-default web browser for multiple releases. If we didn’t have the deb to snap migration in 19.10 (and 20.04) then users upgrading from 19.04 to 19.10 or from 18.04 to 20.04 would lose their browser.
I wrote a blog post 6 months ago about why this was done. https://ubuntu.com/blog/chromium-in-ubuntu-deb-to-snap-transition
We decided at the time not to punch people in the face during the upgrade and make them choose “Do you want to keep your browser, by migrating to the snap?” because those kind of mid-upgrade dialogs are pretty awful for end users. Generally the vast majority of the audience don’t actually care what packaging scheme is used. They just want to click the browser icon and it open.
Yes, we could have communicated it better. We’re working on improving it for the 20.04.1 update which is due next week. We certainly do listen to the feedback we get.
You could use the motd announcements to give people ample notice.
Good idea, but most normals don’t ever see motd.
normals? Normies perhaps?
Please see my answer above to icefox’s assertion along the same lines. This is only for Chromium, and there are good reasons behind that choice (They were spending vast amounts of engineering time JUST on chromium).
As I said in that response, IMO Linux Mint is very much in the wrong here, and has handled the situation abysmally. They could have enacted the removal of snaps/snapd in a much cleaner way without all the drama, and they chose not to do that.
Unfortunate.
Yeah, I saw it after I had posted this comment.
You are conflating two separate things. There may be good reasons™ behind packing Chromium as a snap only. There is no good reason to do so behind the users back. If one uses apt to install something one most certainly doesn’t expect to be installing a snap.
What you chose to call ‘drama’ is a political stance. The issue was not “to accomplish the removal in a clean way”. It was “This breaks one of the major worries many people had when Snap was announced and a promise from its developers that it would never replace APT.”. You may not like or agree with that position but there is nothing wrong with that.
Also it is disingenuous to think this will stop at Chromium. Chromium is just for testing the waters.
Refresh.hold is stated in the article, it does not honor dates further than 60 days in the future.
Did you try
snap revert?e.g.
I appreciate you’re “burned” by this and will likely switch to Mint, so this information may be academic, but for others stumbling on this thread it may be handy. Hope Linux Mint works out for you.
I’d not expect the Allen Pope to respond, you only exist in my podcasts :). How cool!
Now on point, also responding to the revert comment earlier. I did find that, but my point is about not being able to disable updates, not about not being able to rollback. Rolling back would not have been necessary if I could have done the update manually in two weeks, after which the plugins of the IDE would probably have been updated as well. I do however appreciate the option to rollback.
You also state that there are ways to disable updates and give the example of sideloading an application, after which it never gets updated. That also is not my main gripe. I do want my cake and eat it, but not automatically. As in, I want to update when I’m ready and expect it, not changing the engine while the car is driving on the highway.
Is there an official way to disable automatic updates? However hard to setup, with big red flashing warnings, promising my firstborn to whatever deity? Setting a proxy or hosts file might stop working, an “official” way would still give me all the other benefits of snaps.
As said, I do like updates and easy of use (not manually sideloading ever snap, just apt upgrade all the things) with just a bit more control.
Haha! I’m just some guy, you know.
There’s currently no way to fully disable completely all updates. I appreciate that’s hard news to take. However, I have been having many conversations at Canonical internally about the biggest pain points, and this is clearly one. Perhaps we could add a big red button marked “Give Alan all my cats, and also disable updates forever”. Perhaps we could really forcefully nag you with irritating popups once you get beyond the 60 days limit that’s currently set, I don’t know. But I agree, something needs to be done here, especially for desktop users who are super sticky on particular releases of their favorite tools.
It’s Friday night, and I’m enjoying family time, but rest assured I’ll bring it up again in our meetings next week.
Have a great weekend.
What about a big button to disable automatic updates, and then give initially gentle, gradually escalating nags once updates are available?
Maybe in the handy “Software Manager” popup UI we’ve already got built. Checkboxes to select which ones you want to update. Make it really easy to “accept all”, after my workday is over.
This sounds okay in a comment.
Did you use windows 10? Did you read the comments when Microsoft did similar? They were heavily criticised there was a vocal cohort of users annoyed even by that. When I was near a deadline and my windows told me I cannot postpone updates anymore and broke my flow I happened to understand them.
This is a hard UX problem, despite how simple one might initially see it.
It is a problem but not that hard. A simple matter of control. Do I update or not? .hold? Then not. It’s perfectly feasible to add a ..hold.forever. Your workflow is not broken sms 99%of average Joes have the latest everything.
Now, this is just my opinion as am old schooler used to absolute control of my computing. I gladly let everything be automated until i don’t.
It is hard of you wish to please a wide range of users, ranging from novices to power users, and wish to provide a UI serving the different needs of these different cohorts. I mean it is hard if you want to do it well. :) Microsoft tried hard, and did not get it IMHO. Other vendors fail even more miserably.
Thank you for the time you take in the replies here. Enjoy your weekend!
You’re quite right. I apologize for having missed this in my initial read.
I’ve seen snaps come up on lobsters before but had no idea that they automatically update with no option to disable the updates. I thought they were basically like Canonical-flavored docker containers.
Thankfully I saw this post before I update my laptop next week. I’ll be avoiding Ubuntu and their snaps for now.
Couple of important differences between Docker and snaps.
Docker containers leverage Linux’s cgroups feature to offer each container it’s own pretty much complete Linux userland.
So that means that you can, as a for instance, have 3 containers all running on a Fedora system, one Alpine Linux, another Ubuntu, and a third something else.
Snaps, on the other hand, are application containers. They just bundle the application itself and any libraries that are necessary to run it.
And that’s the beauty of the Linux ecosystem right? :) I’d guess more people on here are Debian or maybe Arch users :)
I think a large part of the criticism is that it gets installed automatically; and if you remove it it keeps getting reinstalled anyway.
Have you actually tried reading the article? It’s literally mentioned in there.
I don’t see anything in the article suggesting a snap gets automatically re-installed after removal? Can you please elaborate?
I did read the article but missed that detail. Thanks for pointing that out.
Is there no mode that would share the physical network port but tag all IPMI traffic with a VLAN you configure?
Many HPE servers have a dedicated network ports for the iLO card but can also optionally share one of the regular network ports if needed. When in shared mode, you can indeed configure a VLAN tag for the management traffic, which can be different to the VLAN tag used by the host operating system normally.
Unfortunately, in the same way that chris explained that a any compromised host might be able to switch the device IPMI mode from dedicated to shared, using a VLAN for segregation can have a similar problem. If the compromised host adds a sub-interface with the tagged VLAN to their networking stack they now can gain network access to the entire IPMI VLAN.
In addition there are other annoyance with using a shared interface. Because the OS has control of the NIC it can reset the PHY. If the PHY is interrupted while, for example, you’re connected over Serial over LAN or a virtual KVM, you lose access. If you’re lucky, that’s temporary. If you’re really unlucky the OS can continually reset the PHY making IPMI access unusable. A malicious actor could abuse this to lock out someone from remote management.
That can’t happen when you use a dedicated interface for IPMI (other than explicit IPMI commands sent over /dev/ipmi0). Generally switching a BMC from dedicated mode to shared mode requires a BIOS/UEFI configuration change and a server reset.
(Speaking from experience with shared mode and the OS resetting the NIC. The malicious actor is merely a scenario I just dreamt up.)
Indeed, although I suspect in many cases these IPMI modules are already accessible from the compromised host over SMBus/SMIC or direct serial interfaces anyway - possibly even with more privileged access than over the network. That’s how iLOs and DRACs can have their network and user/group settings configured from the operating system.
The increased risk mostly isn’t to the compromised host’s own IPMI; as you note, that’s more or less under the control of the attacker once they compromise the host (although network access might allow password extraction attacks and so on). The big risk is to all of the other IPMIs on the IPMI VLAN, which would let an attacker compromise their hosts in turn. Even if an attacker doesn’t compromise the hosts, network access to an IPMI often allows all sorts of things you won’t like, such as discovering your IPMI management passwords and accounts (which are probably common across your fleet).
(I’m the author of the linked to article.)
The L2 feature you are looking for is called a protected port. This should be available on any managed switch, but I’ll link to the cisco documentation:
https://www.cisco.com/en/US/docs/switches/lan/catalyst3850/software/release/3.2_0_se/multibook/configuration_guide/b_consolidated_config_guide_3850_chapter_011101.html
In a previous life at a large hosting we used this feature on switch ports that were connected to servers for the purposes of using our managed backup services.
Mods (@alynpost @pushcx) please fold into https://lobste.rs/s/fumh1r/why_doesn_t_python_have_main_function (fumh1r).
This is a response to that article, basically taking an position entirely counter to it, not a repost of the original. I’m not sure if this is suitable for folding?
It is, it keeps the discussion together, and (though this isn’t one) it disincentivizes hot takes by not rewarding them with their own slot on the front page.
Unfortunately the OP didn’t do so well so I didn’t even know this link was submitted. Thanks for folding!
I appreciate the motivation, but I still find it disappointing and unfair that newer (and frankly, higher-quality) content is merged away from the front page where few will see it.
I’m not sure that this is technically how folding works, but it appears that if multiple links are posted to similar topics within a time-span of roughly a few days, then they all share the “popularity factor” of whichever was posted first.
I feel like, if an article spurs multiple other people to write about the same topic (as happened in this case), then people are still talking about this topic, and so deserves at least one spot on the front page.
Maybe the comment threads could all be merged, but individual links preserved? Or all links on the topic could share the highest “popularity factor” instead?
Stories are ranked by “hotness”, calculated here.
I see, thanks for the clarification!
Having a counterpoint in the same context is valuable.
https://alta3.com/blog
We write about kubernetes, Linux, networking, devops and anything in between
Example posts:
Do you run a company just curious. Your blog had some pretty cool posts
Yep! We’re a telecommunications and cloud training company and love writing about the tools and techniques we learn in order to deliver awesome hands-on training.
We’re glad you liked our posts! Many more are in the works!