Seems okay-ish if it removes all the AI slop and spam quickly. The mods already have the technical power to dictate things, so this rule change just make their actions tie more closely to their management reputation

The blog also stated that FUTO repeatedly gave money to other FOSS projects without following proper process for institutional sponsors, and stick their names onto their front page.

Aside from that, their own projects are source-available at best.

So what are the alternatives that work with both Alpine and Debian?

My opinion is that you’d be better off sticking to the OOTB init system that these distros provide, and hop to an entirely different distro that supports the init system you want/need. And for distros that do support multiple, stick to their guides carefully. Would save from a lot of incompat quirks and unsupported bugs, since these things can be as integrated into the main system as the package manager, if not more.

Conceptually though systemd can be a bunch. The s6 dev put out these definitions for the way he conceptually breaks down the entire init/service ecology into small pieces so have a look (ou may be interested in his full post explaining the motivation behind s6/s6-manager too). And since you’re on Alpine, see their plans for a future init system.

With that said you may wanna try out dinit on Chimera Linux. They’re one of the unique distros that offers this and some other cool things

If you have the WireGuard config from Mullvad already, just edit your wg.conf files on client devices to route all traffic via the Mullvad servers. Basically replace all the values of the [Peer] block with Mullvad values.

If you can share your Mullvad wg config file and your wireguard-server config file here, we can sort this out together

Edit: actually since your only goal is to increase the Mullvad device limits, why not just use Mullvad-provided confs directly in your client WireGuard apps? Should be straightforward to do

It shouldn’t go through the VPN although idk how to verify that. Do you still have the timeout errors in your monitors? What do those errors say?

Could not resolve host

Then I guess you only define an A record in the DuckDNS panel. That’s fine.

A while back I ran a somewhat similar Wireguard tunnel and can’t connect. Turns out some MTU settings were lower than the docker’s MTU and that breaks big packets like SSL handshakes. Restarting makes it work fine until things start congesting again.

Suffice to say this would be something I’ll look at if the SSL errors reoccurs

seems like your DNS works fine but your certs doesn’t. Are you able to connect to your services on your browser normally, with SSL?

Edit: please also try curl -4 and curl -6 to your services from within the uptime kuma container to see if theres an ipv4/v6 issue

Another edit: seems like there is a dataprolet URL in your post and a datenprolet URL in your comments. It might just be a typo so also check that too.

• Is your uptime kuma server on the same machine as your other services?
• Are you using docker/podman? If so can you try to curl your services’ domain from inside the container and see if they resolve?

Might look into Gotosocial considering it’s more lightweight.

Other than that I wonder whether it’s better for the uni/department to register on another instance, similar to how fosstodon is home for many FOSS projects. An inter-unis, academic-focused Fediverse server might be a good club project, and could allow more donation sources to sustain too (although this is pretty above-scope from what you’re asking).

Tailscale/Headscale + DERP may work as they relay packets through a typical HTTP server. Just make sure your router has some space to download the binary - for MIPS they’re like ~60MB or something iirc.

My bad, I meant the recommended deployment is to bring your own auth provider, but normal username/password is fine too. Glad it works!

Assuming you just want file sync and storage, if you can live without External Storage (having another SFTP/WebDAV/whatever backend), then I think oCIS is great for you. It also expect an OIDC auth provider by default - this guide helped me through. Note that you have to configure the S3 storage driver in oCIS and properly backup your buckets and metadata.

For Talk you can setup an internal Matrix and TURN server too. I recommend conduwuit if you want something lightweight, or Synapse (quite heavy) if you need OIDC integration.

An alternative method is to run an actions workflow that syncs from upstream images directly, like what Forgejo actually do.

https://code.forgejo.org/forgejo/oci-mirror

Update: there seems to be a more “native” storage driver for OCIS that is currently WIP. It seems very exciting

FYI there is an upcoming storage driver that can solve this issue

I think oCIS spoiled me with regards to the database issue xD. You bring up a good point - I’ll try reinstalling Nextcloud with Postgres, removing unneeded bloat, and use it until oCIS has a “native” backend

Non-OCIS Owncloud still needs a dedicated database and recommend against SQLite in prod

I’ve looked at rclone mounting with the --vfs-cache-* flags. But I’m not sure how it can smart sync like mountain duck or handle conflicts elegantly like the Nextcloud/Owncloud clients do. Let me know how to set it up that way if possible

AFAIK, Syncthing clones the entire folder across peers (the server is just another peer it seems), which isn’t ideal for my use case Do you know any current way to configure it for selective syncing?