the physical display output is claimed by something else totally separate.

Yes, and the above solution I laid out is a way to get around that, that potentially dodges the complexity of configuring a truly headless session. It's possible to run two KDE sessions at once, next to eachother, and then simply put one on the main display, with the second being "headless", and not shown.

I started fiddling with the above setup I described, actually installing and testing sunshine. Unfortunately I hit some hiccups. I got sunshine to run, but with no input, and then then it attached to the wrong KDE, even though it was streaming the correct one initially. Now I'm running the same KDE session as a different user (since I was on the same user before), but having pairing issues, but I suspect these are because moonlight is seeing the wrong SSL cert, since the sunshine as a new user generated a new cert.

Do you actually need the headless backend? Or do you need a background session that doesn't interfere with the main session?

If you don't have internet, which you may need for some of the fixes mentioned here, you can try tethering, which is where you share a phone's internet with a computer over a wired connection.

https://wiki.archlinux.org/title/Android_tethering

https://wiki.archlinux.org/title/IPhone_tethering

Although, these might depend on NetworkManager, although they might not.

Second comment:

https://docs.lizardbyte.dev/projects/sunshine/v0.21.0/about/guides/linux/headless_ssh.html

There is also this guide, but it is specific for Xorg and Nvidia gpus. But I suspect that if you replace the startx here with startplasma-wayland or dbus-run-session startplasma-wayland, then it will work. It would still be nvidia gpu specific though.

If you log in (preferably as another user) to another tty (Cntrl + Alt + F2/3/4/5), and then run dbus-run-session startplasma-wayland, does that work?

Sometimes just startplasma-wayland works, which used to work for me but didn't work for me this time.

Then, you should be able to switch back to the original KDE session, which continues to work normally, at least it does for me. Both sessions should have shared access to the GPU, as well. You can then probably run sunshine in that second instance of KDE, while the monitor can be attached to tty1 or tty2, whichever one is the default where KDE is put.

Then, you would probably want to configure sunshine to work even when the screen is locked, that way you can lock the second session with Win + L, but it can still be interacted with remotely via sunshine.

EDIT: I only am somewhat confident that this setup will work, I haven't tested it personally.

Debian has old software and doesn’t support some newer hardware. Even the latest version, Trixie, is still very far behind. I realize this now.

Debian has backports, which enable you to get select versions of newer software. Relevant to your case, you can get a newer version of the kernel, drivers, and other things relevant to hardware support.

Might be a bug, so we can troubleshoot to try to figure it out.

If you visit about:processes, is there any website or extension taking up a lot of system resources?

In addition to that, you can try launching firefox in safe/troubleshooting mode. 3 bars in the top right > Help > Troubleshooting mode

This restarts firefox with all addons, extensions, and themes disabled.

For further troubleshooting, also try:

Go to about:profiles, and create and launch a new one. This is a more complete reset, since it also resets all settings, about:config options, and similar.

After creating a new profile, you can play around with rebuilding your current firefox config, adding extensions and changing settings.

Certbot?

It can automate provisioning of certificates using DNS-01 challenges, which have wildcard certificates.

https://eff-certbot.readthedocs.io/en/stable/using.html#dns-plugins

Example tutorial: https://www.digitalocean.com/community/tutorials/how-to-create-let-s-encrypt-wildcard-certificates-with-certbot

Once you do that it puts the cert in /etc/letsencrypt/live/ so you can then do whatever you want with it. You would have to handle distribution manually.

If you want to automate stuff across of a bunch of machines at once, I recommend Ansible: https://docs.ansible.com/projects/ansible/latest/index.html

https://libregamewiki.org/Roguelike_games

There are more games on there, but I have been meaning to try the roguelike stuff out.

One thing I read about is that Ubuntu provides unattended updates, so it can automatically update packages and restart the server (that seems a bit too far ;) ). It’s probably possible on Debian but not out of the box.

Ubuntu automatically has unattended upgrades, which makes I think makes it a popular choice for VPS providers to push (beyond being popular in corporate/institutions overall), since they don't have to worry about users forgetting security updates. However, it doesn't enable automatic reboots. But, it does look like automatic restarts of services updated via unattended upgrades is done, but only as of Ubuntu 24.

Another thing to note is that Ubuntu has updates that are explicitly for security, and then everything else, including more general bugfixes and program updates with additional features. By default, unattended upgrades on Ubuntu only do security updates.

Of course, both a unattended upgrades and automatic reboots are possible on Debian (same software, Ubuntu just preconfigures it), although default configurations can vary. I wouldn't be suprised if a VPS provider was shipping a default Debian configuration that enabled automatic upgrades.

On Debian, for the most part, ALL updates are only for security issues or severe bugfixes (program crashes or the like). Debian, for the most part, doesn't do minor bugfixes at all, or do program feature updates. I prefer this model, since it's easier to manage than having separate types of package updates. It ensures absolute stability, a guarantee that the system tomorrow will behave the same as it did yesterday, while still enabling automatic security updates. This model is ideal for a server I don't want to babysit, or for your grandpa who loses his mind when the button he is supposed to click was moved one spot over.

In addition to that, I like the policy of automatic reboots. With the stable, slow moving nature of both distros, it's safe to automatically reboot to ensure that kernel vulnerabilities, or vulnerabilities in other critical systems are fixed. Automatic updates and reboots can be the difference between someone being able to escape a docker container or someone not being able to.

There is one thing to note, is that adding additional repos (or PPA's which technically you aren't supposed to work on Debian), can be dangerous, and you have to be careful: https://wiki.debian.org/DontBreakDebian/#Don.27t_make_a_FrankenDebian

The main problem is that if a third party repo and Debian provide the same package, and the system is configured to prefer the third party repo, then you can be installing a potential dependency to the rest of your system that isn't actually tested against your system, or compatible.

You have to be really careful to ensure that the programs in the repo are actually built and designed for your system, and also that the your system does not default to installing them.

Third party repos also break the guarantee of stability that automatic updates depend on. Third party repos don't have a separate security channel, so Ubuntu will probably avoid touching them, even if critical security fixes are needed. Debian will update them, but unlike Debian's packages, the overall program updates won't be guaranteed to be behave the same due to potential major/minor version changes.

For example, if you get Docker from docker's repo instead of Debian's/Ubuntu's, now your version of docker can no longer auto update and receive potential security fixes safely.

Overall, I prefer Debian but Ubuntu is fine. If I was in an environment that used Ubuntu already, I would also just use Ubuntu. If you are already using Debian, then Debian is probably preferable.

Built-in live preview for HTML

Only in electron based editors AFAIK. It requires an integrated browser engine, and electron already is an integrated browser engine so that makes it easy.

Lots of rambling in this comment. Solution below the heading.

From a security perspective of limiting privileges it doesn't quite work. If they can run apt install then they can install a malicious hand crafted package, that has an install script that runs with root privileges, or enables a systemd service or so on.

From a preventing users from doing stupid stuff, it mostly works. Of course, there are still ways it can break, like when Linus Tech Tips typed in yes, do as I say when apt had a bug and refused to continue because it suspected that something would break and then Linus did it anyways...

But it will mostly work.

I want users to be able to install apps, but only from the the gui software manager and apt install in the terminal.

Firstly, I want to mention that flatpak does not need root and can work without root. So if the goal is to have users be able to install apps from the app store, you could remove non flatpak apps from the GUI, and then they would be able freely install and remove apps from the GUI app store. They can also use the flatpak cli, but it's more difficult to use.

Secondly, I agree with the other commenter. It's probably way easier to make a backup, or use syncthing, and just give them root if that getting them apt packages the goal. If you do something like automatic btrfs snapshots (which Linux Mint has support for), it mostly gets you to the goal of "I don't want a privileged user to break their system", since it is easy to walk them through booting into an older snapshot over the phone.

If your goal is actual management of apt programs, then the specific problem you are encountering is that there are two methods of authorizing to root, and you have configured only one of them so far. There is sudo, which governs cli programs, but there is also polkit, which governs GUI programs. Polkit has a cli command that has a similar feature to sudo, pkexec, which you can use for testing configuration of polkit.

Since it looks like you got sudo working I won't waste time on that. Here is a nice intro from Red Hat:

https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/7/html/desktop_migration_and_administration_guide/policykit

Hmm doesn't have what I want. (I am figuring out as I go).

Okay it looks like the GUI stuff is powered by packagekit, which is an actual daemon: https://en.wikipedia.org/wiki/PackageKit (I thought it was just a library/interface), that runs as root. You can use the pkgcli to interact with it from the command line, and it still uses polkit.

Okay here is the relevant policy file: https://github.com/PackageKit/PackageKit/blob/main/policy/org.freedesktop.packagekit.policy.in

Solution Here

Polkit rules are written in javascript, so you would want a rule that's something like:

polkit.addRule(function(action, subject) {
    if (subject.isInGroup("GROUPNAME") &&
        subject.local &&
        subject.active &&
        action.id.startsWith("org.freedesktop.packagekit.")) {
        return polkit.Result.YES;
    }
});

And put this in /etc/polkit-1/rules.d/10-enable-rootless-packagekit.rules

This does read from the local unix groups, not active directory groups, meaning you have to ensure it's present there, and also have the exact name, which is not used in the sudoers file example above.

if you run getent group, then it should be exact name of the group in that list.