It’s shocking that anyone would use MS, they have a pretty terrible security record. https://www.cisa.gov/sites/default/files/2024-04/CSRB_Review_of_the_Summer_2023_MEO_Intrusion_Final_508c.pdf

Basically they used the same encryption key for every tenant and thought that rotating the key was too hard, so they stopped.

I don’t see enough people using the Pummeler and Ballistic Shield. I know it’s not meta, but it’s just so much fun to slowly advance on bots while laying down suppressing fire. I feel like it helps the squad push into tricky spots too.

That’s a good way to think about it, actually. Thanks for sharing

It does make establishing a critical mass of comments to make a good discussion difficult. I’ve had it once or twice where I discovered a post in one community commented and didn’t get any replies, only to discover some other discussion on the same content happened elsewhere on the fediverse that I wasn’t subscribed to.

Because documentation was so great for sysv and everything else back in the day…

To actually answer your question, you need some kind of job scheduling service that manages the whole operation. Whether that’s SSM or Ansible or something else. With Ansible, you can set a parallel parameter that will say that you only update 3 or so at a time until they are all done. If one of those upgrades fails, then it will abort the process. There’s a parameter to make it die if any host fails, but I don’t recall it right now.

How have I never seen that before. It’s perfection

Don’t you go and reinstall, learn how to fix this

Realistically, yes. But it’s a phrase and it’s important that they start doing that first. Maybe it’s their intention to do it publicly.

Also, sure, but a Wireguard installation is going to be much more secure than a Nextcloud that you aren’t sure if it’s configured correctly. And Tailscale doubly so.

Please set up Tailscale or a Wireguard VPN before you start forwarding ports on your router.

Your configuration as you have described it so far is setting yourself up for a world of hurt, in that you are going to be a target for hackers from literally the entire world.

I think the real headline here is that the internet overall has gotten worse, and even the top Google results still point to shit.

There is a lot of complexity and overhead involved in either system. But, the benefits of containerizing and using Kubernetes allow you to standardize a lot of other things with your applications. With Kubernetes, you can standardize your central logging, network monitoring, and much more. And from the developers perspective, they usually don’t even want to deal with VMs. You can run something Docker Desktop or Rancher Desktop on the developer system and that allows them to dev against a real, compliant k8s distro. Kubernetes is also explicitly declarative, something that OpenStack was having trouble being.

So there are two swim lanes, as I see it: places that need to use VMs because they are using commercial software, which may or may not explicitly support OpenStack, and companies trying to support developers in which case the developers probably want a system that affords a faster path to production while meeting compliance requirements. OpenStack offered a path towards that later case, but Kubernetes came in and created an even better path.

PS: I didn’t really answer your question”capable” question though. Technically, you can run a kubernetes cluster on top of OpenStack, so by definition Kubernetes offers a subset of the capabilities of OpenStack. But, it encapsulates the best subset for deploying and managing modern applications. Go look at some demos of ArgoCD, for example. Go look at Cilium and Tetragon for network and workload monitoring. Look at what Grafana and Loki are doing for logging/monitoring/instrumentation.

Because OpenStack lets you deploy nearly anything (and believe me, I was slinging OVAs for anything back in the day) you will never get to that level of standardization of workloads that allows you to do those kind of things. By limiting what the platform can do, you can build really robust tooling around the things you need to do.

I used to be a certified OpenStack Administrator and I’ll say that K8s has eaten its lunch in many companies and in mindshare.

But if you do it, look at triple-o instead of installing from docs.

I wish I could fully endorse Escalidraw, but it only partially works in self-hosted mode. For a single user it’s fine, but not much works beyond that.

It’s like all the vegans vs the people that bitch about vegans.

You’re on the right track here. Longhorn kind of makes RAID irrelevant, but only for data stored in Longhorn. So anything on the host disk and not a PV is at risk. I tend to use MicroOS and k3s, so I’m okay with the risk, but it’s worth considering.

For replicas, I wouldn’t jump straight to 3 and ignore 2. A lot of distributed storage systems use 3 so that they can resolve the “split brain” problem. Basically, if half the nodes can’t talk to each other, the side with quorum (2 of 3) knows that it can keep going while the side with 1 of 3 knows to stop accepting writes it can’t replicate. But Longhorn already does this in a Kubernetes native way. So it can get away with replica 2 because only one of the replicas will get the lease from the kube-api.

Longhorn is basically just acting like a fancy NFS mount in this configuration. It’s a really fancy NFS mount that will work well with kubernetes, for things like PVC resizing and snapshots, but longhorn isn’t really stretching its legs in this scenario.

I’d say leave it, because it’s already setup. And someday you might add more (non-RAID) disks to those other nodes, in which case you can set Longhorn to replicas=2 and get some better availability.

Can you easily switch drives in your system? I’ll often do that on my computer because little m.2 SSDs are so darn cheap now. It’s easier and cheaper to pick up a little 64GB drive for one off projects than it is to do a proper backup and restore.

Also, I’d just go with Tumbleweed. I don’t distro hop like I used to, but that’s because as everyone else is saying, most of the distros have gotten really good. Most of the time, my little projects are trying out specific features of a different distros. So I’ll just pop a new drive in, test drive it, then either switch back or not.

Also, all of us have done things because we didn’t know better. The only dumb thing to do here is to not learn how to fix this. Try and fail, so next time you know how it works and can do better.

Unless it was encrypted, it prob doesn’t matter. The partition table is just the road map that points to the houses (files). A tool like FTK or PhotoRec goes byte by byte to find the files and figure out what they are. You won’t have file names, but the data might still be there.