Strange. Are you on Android or iOS?

Proxmox which uses KVM

Firefox showed all green on my phone, same as Chrome. Are tou maybe missing an update? Check the Play Store for updates.

None of my VM require sharing of data, so each gets their own. I don’t currently use ZFS in Proxmox, but do have snapshots and periodic backups to my NAS, so recovery is generally not an issue.

Conceptually, mounting a host storage inside a VM requires the use of either virtiofsd or NFS daemon running on the host (depending whether you mount it as local or network storage), so if either of the two or the underlying filesystem has a vulnerability, it does in theory create an attack surface, which is not ideal. With that said, as I mentioned above, I have not research led this enough, since I haven’t had the need yet, so don’t quote me on that. At the end of the day, it’s all about where you personally draw the line, so if you are fine with that risk and absolutely can’t give up the feature than go for it, it’s your system.

I mean, unattended upgrades has it’s own config file where you can specify when to schedule a reboot (when needed), which you’d usually do in off-hours like 2 AM your local time, so changing the Systemd unit activation time seems like the wrong fix.

Edit: Nevermind, your issue was that the daemons were being rebooted, not the whole system, if I understood that correctly

• Forgejo for private git repos, coz F GitHub (F as in paying respect obviously… :v)
• Portainer, though don’t use much as of late as I got used to the CLI
• qBittorrent for Linux ISOs. No, really, I use it to download Linux ISOs :v
• WireGuard, several instances, some for accessing specific services, one for accessing GeoIP blocked content when traveling
• Vaultwarden for managing passwords
• Home Assistant for managing a couple of sensors
• Nginx Proxy Manager for managing hosts
• TeamSpeak 6, just playing around with the beta for now
• Apache Subversion for private SVN repos
• A handmade C# service for storing some MQTT data into a database
• peaNUT a NUT dashboard for the UPS
• RustDesk for remote management of desktops

As for the hardware:

• A Raspberry pi 4 running Docker containers
• A Dell Wyse 5070 (16GB) running Proxmox with mainly Alpine Linux VMs

If you asked me 2 years ago, I’d say they give a decent level of isolation for cheap, but, at the end of the day, in the eyes of the kernel, containerized processes are just another process running on the same host, just with a different set of privileges. If you have public facing services, or untrusted binaries, I suggest moving those to VMs, local services can stay in containers. This is what I did after Copy Fail and Dirty Frag were discovered. Alpine Linux VMs are pretty lean, so I went with that, and to keep the migration simple, I run the services as containers inside the VMs.

Did you read it to the end?

Without root user login, the attacker would have to guess not only the password to the user but also the username (hopefully it’s not something simple like admin), and once you are logged in you can use sudo -i to chage into root, which will require a password, therefore, we also disable password login so if someone does manage to somehow compromise the SSH user, they’d still need the password to become root.

You could spin a publicly exposed WireGuard daemon firewalled to allow peers access to the non-public SSH port only, which would result in double encryption, but would give you the peace of mind that an attacker would have to compromise both at the same time, which is very unlikely. Plus, WireGuard is very cheap to deploy and produces no logs. We use that model in my office to access our server.

Edit: Otherwise, as others mentioned, you’d move the SSH daemon to a random port, disable password login and weaker keys and cyphers, setup Fail2ban, and optionally setup GeoIP blocking (only allow IPs from your region to connect).

The way a reverse proxy works is to literally stand in the middle of a connection, so either side only sees them communicating with the proxy, oblivious to the actual endpoint. The only “solution” to this, though it’s more of a hack really, is to somehow send the original IP as additional data in a way that both sides agree on, e.g. the X-Forwarded-For header as others have mentioned, however, as I’ve said, both sides need to support and aggree with that, so you may have to find a setting/config to enable on the services behind the proxy. Think of it this way, if services blindly trusted that header and you weren’t using a reverse proxy, a bad actor could send a request to your service with that header included thereby spoofing their identity in your logs, therefore, this kind of thing is usually opt-in

The removed drivers are usually those that are really old and not used by anybody (using the latest kernel), so it’s a bit different.

Yep, don’t forget to seed!

Yeah, but I thought the philosophy was not to break userspace. I’m fine with the removal if absolutely nobody uses it, but some have commented here being users of the feature

Ah, I see! From googling “data=ordered” is the default and does what you said. Still, why not leave it for those that want it?

Wasn’t the journal the main selling point in the transition from EXT2 to EXT3? This seems kinda backwards, what even is the rational?

From what I’ve seen, there are 4 core issues people complain with snaps:

1. For full functionality, snap requires Ubuntu specific kernel patches, and has a hard dependence on Systemd, whereas Flatpaks work everywhere.
2. Most Flatpak users default to the flarhub repo, however, just like you can have other apt sources, Flatpak supports other repos. Snaps on the other hand are exclusively tied to and controlled by Canonical, which seems very unlike Unix and rubs many wrong.
3. You can install packages as a non-root user into your home with Flatpaks, but snaps can only be managed by root, since they are system packages. This means that they are very unsuitable for atomic distros like Fedora Silverblue.
4. Technically not the fault of snaps but the decision by Canonical, when you try to install something with apt on Ubuntu (and derived) it may instead install it through snap, which, because of sandboxing and other security measures, may result in very unexpected and hard to diagnose issues. I personally wasted a day trying to fix a broken Docker daemon, which turned out to be due to snap, when I explicitly wanted an apt! I personally have no major issues with snaps in general, but ffs let me decide whether it’s a snap or not >_<

Bonus: Some also complain about security, that snaps have had many vulnerabilities, and that malware was distributed as snaps, but the same has been true for Flatpaks too, so I don’t think it’s fair to point that out.

Yeah, that and avoid very new things when using Linux are the morals of my story. But I can’t help it, I am a human and hate all Thinkpads now :P

The laptop BIOS did see updates and now works fine running Cachy, but for over a year it was terible. A whole list of cryptic kerner boot arguments would make it boot, but then touchpad and keyboard issues would remain, and if it ever went to sleep it would hard lock again, not ideal on a laptop. I personally didn’t contact support, but on the official forum there was a thread with a tonne of comments about how support would say Linux is not officially supported on this model and people giving up and returning it. I couldn’t because I ordered from overseas, specifically because I heard Thinkpads worked great with Linux. Needless to say I was royally disappointed. At least it works now, and works better than with Windows.

At least at launch it was a total mess, Linux would instantly hard freeze at boot time. They did eventually release BIOS updates that fixed them more than a year later, so mine is currently running Cachy, but just google for E484/E585 Linux issues, there’s a tonne of people complaining back in the day, and I was one of those early birds >_<

From what I remember, there was a similar-ish laptop a tier above which had received a BIOS update pretty fast, but even though the symptops were pretty much the same, Lenovo dragged their feet on this one.