The trick is to get wordpress from debian’s repos itself. That way your wordpress is managed by debian and receives automatic security updates.

ssh is probably fine for 99% of things. I use ssh exclusively mostly

The features I load cockpit up for is:

• easier viewing of systemd/journalctl logs. You can click on services and see logs, search them, and so on.
• Partitioning a disk. Nothing too crazy, but I can format a disk, wipe them, via the GUI
• Networking configuration. If you are using networkmanager, cockpit will test the changes, attempt to connect, and then revert the changes if the connection fails (in like 15-30 seconds). This is legitimately insanely useful, I can change the ip address or something, connect via cockpit again, and only have the change stick if it’s actually good. (See also, netplan try from the netplan configuration framework.)

Cockpit also offers a GUI for managing virtual machines (via libvirt) or podman contaniers. So someone else might want that, although I don’t really use that. (virtual machines can be managed remotely via virt-manager over ssh by connecting to qemu+ssh://user@remote-host/system, I manage podman via the terminal).

I use cockpit, but via the client. They have a flatpak client that gives you cockpit’s features, connects over ssh (and reuses your ssh config), and doesn’t require anything to be installed on the host/server you are managing (besides ssh ofc).

I like Authentik, as I really like:

• Support for every auth protocol, particularly OIDC and LDAP
• Invites that can invite multiple people, letting me onboard a room of people at once
• Python based scripting that lets me script some integrations and do API calls when users authenticate

But at the same time, Authentik is very, very complex.

If you just want LDAP and OIDC in the same app, I would probably recommend KanIDM. KanIDM also does invites (although only one user at a time).

If you just want OIDC itself, pocket ID (passwordless /passkey only) and void auth both are really simple OIDC providers (that also support sign ups/invite links. EDIT: Ah, it looks like Void Auth has an experimental read only LDAP server feature. Nice.

I am also paying attention to (some less popular options):

• Rauthy: Fairly minimal, supporting OIDC… but also supports PAM for Linux/Unix integrations
• Casdoor: seems to be feature rich like authentik, but perhaps not as difficult to deploy and configure
• Univention Nubus: An open source, European auth software, that is feature rich, but has an appliance virtual machine that might make it easier to install.

deleted by creator

I only wish it had mock-LDAP so I could use it with things that don’t do OIDC like OpnSense

KanIDM is probably the simplest auth server that does both OIDC and LDAP in one app. Although Kanidm’s LDAP is read only.

Hmmm, games / game servers are a bit different since, they are rarely ARM and mostly x86.

You can use tools like muvm or fex to run the x86 version of wine, and then use that to run game servers: https://docs.fedoraproject.org/en-US/fedora-asahi-remix/x86-support/

People have been able to game on the M1 since it has hardware acceleration, although I never gamed.

When I had Asahi, I just used it as a daily driver laptop. It worked perfectly fine for all of the stuff I wanted to do on my M1.

For a server, it will probably work fine as well. You have to ensure that say, the apps/docker containers you use support ARM, but ARM is fairly popular and well supported nowadays.

I did have one issue with podman, where apparently the memory is organized differently on the M1, which causes some docker containers, even if they are built for ARM, to be incompatible. I had to use podman machine, which is podman’s built in virtual machine that lets you run containers in their instead. It is designed for Mac OS, which is kind of ironic since the whole point of using Linux was that I wouldn’t have to run a virtual machine just to run podman/docker containers.

You might be interested in: https://github.com/project-copacetic/copacetic

Is incus-compose a part of the base system, or an add-on

it’s a program you install on your client machine. It just connects to the Incus API (probably using the Incus cli).

How does it work on IncusOS if it’s a command-line tool and there’s neither a remote nor a local shell, only a web API?

The Incus cli connects to the API.

Does it provide a built-in way to automate container updates

For the most part, Incus containers are system containers, similar to lightweight virtual machines. They run a full distro, including systemd and all that. For keeping those updating, you would want to use the auto update methods that Linux distros provide.

There are also OCI containers that Incus can run, but I don’t think there is any form of auto update for those. You might be better off just running docker/podman/kubes in a VM for that.

Incus somewhat recently added support for gpu acceleration for VM’s via virtualgl/virgl: https://linuxcontainers.org/incus/news/#gpu-sharing-for-virtual-machines-through-drm-native-context

This does only support OpenGL, but it’s way, way better than no hardware accel for many things.

In addition to that, there is potential of windows virtual machines getting support for OpenGL hardware acceleration, as well: https://github.com/virtio-win/kvm-guest-drivers-windows/pull/943 . Unfortunately that looks like it stalled. I have seen other projects, like this or this, but even if people get something working, one big barrier is the drivers have to be signed (by Microsoft) before they can easily be included into Windows.

I use Incus on Debian 13. Debian 13 packages Incus, and that version only does security updates and focuses on stability. To be clear, Debian’s model is to not do bugfixes or feature updates, to prevent any update from being breaking in any way. This ensures users can automatically get security updates.

I get it from zabbly’s repos: https://github.com/zabbly/incus , in order to get newer versions of Incus, and to get, however. There is a risk of breaking updates but I’ll live and fixing the occasional thing on my one server is okay. The Zabbly incus repos also come with the UI, although the UI is just a static site you can put in the right spot. I like that design, because it means that only the API can do anything, which lessens the attack surface.

I also use Incus personally on my laptop on Arch Linux. It’s nice to have the same UI/UX for vm management, and being able to download the premade images from their docker like repository is pretty nice as well.

No, you can install Incus on any linux distro. I use it on a Debian server.

It’s IncusOS that is immutable.

But proxmox is actually just a set of packages on top of debian, and proxmox is not immutable either. You aren’s supposed to tinker with the host, but if you are doing things like jailbreaking consuner gpu’s to unlock the server gpu only features, then it becomes nice to have that option.

It’s not, but it doesn’t look like they need hardcore censorship resistance if they are able to host and use headscale. It looks like their main problem is internet outages.

I have been in environmenrs where any usage of wireguard is automatically fingerprinted and blocked.

yggdrasil

https://yggdrasil-network.github.io/

this is a beta release and will NOT be pushed to the repository

Yeah, that’s a nono from me. That’s a big security red flag.

Secondly, if goes against the stated goal of having testers find bugs. Part of finding bugs is being able to go through the code and figure out what issues are happening, in what parts of the code.

Finally, this project appears vibecoded. Here is the initial commit: https://github.com/adityakrishnan005-a11y/ScreenGuard/commit/c97cc2e6bd17b35e99ff0bb892aeed41f95cb4e0

That’s a lot of code in the initial commit. And emojis in the .md’s…

There are also some other bad patterns like binaries in the git repo :/

I can see why this project received mixed review on it’s previous pass. Please:

• Transparency about LLM usage — Allow people to make informed decisions rather than concealing it. You are still going to get mixed reviews, but it’s better to be honest
• No more binaries in the repo. C’mon
• All code has to be public. It’s not actually open source if not all code is public.

It’s a cool project, sure.

But what makes this project better than something I could vibecode? What makes this project better than the previously existing https://github.com/polesapart/timekpr-next , or other time keeper/time control projects? Can you guarantee that this project will stay maintained, which is a common issue with vibecoded projects.

One workaround is that you could use the trash-cli command, which moves files to the trash directory instead of truly deleting them.

But this only works on (usually desktop) systems that have a trash. And usually trash is set to autodelete items when it grows too big. I also am not sure if it’s always preinstalled.

But it would be a neat workaround for worrying about permanently deleting files.

Edit: no, it doesn’t. Looking at the comments below, it’s public key crypto.

Original comment:

The problem is that if that is your threat model, then the VPS provider, ISP, and literally everything between you and letsencrypt can pull a conpromised key fro letsencrypt.

This actually happened btw, an xmpp server was attacked this way, they compromised not the server itself, but the VPS provider MITMed their traffic: https://www.devever.net/~hl/xmpp-incident

If your threat model involves this, then the only solution is Tor, which eliminates these requirements of trust.

No, the license is not a real OSS license.

The short version is that the requirement of all infrastructure being open, could potentially apply to parts of the stack where you don’t have access to the source code, like the management engine or network card firmware.

It hasn’t been tested in court yet, and because this is unclear, the SSPL is a hot potato nobody wants to touch or test. The possibility of the requirement for closed source firmware to be open, makes the SSPL effectively unusable.

The SSPL is neither Open Source Initiative nor Free Software Foundation approved: https://en.wikipedia.org/wiki/Server_Side_Public_License

Currently, SSPL licensed code is best treated as source available, but proprietary code.

Mongodb is proprietary.

Postgres is open source, and then there is documentdb which adds a mongodb compatible layer on top.

But it would probably be better just to use postgres + jsonb directly for that case.