Everyone (and their mother) have been trying to convince me that I should use one of my less loaded servers to be a Fediverse node. However, all Fediverse software packages I checked only support being installed on complicated systemd + Docker machines. My servers don’t have either of those, because neither systemd nor Docker even exist on OpenBSD and illumos.

I know that it would be possible to manually install (e.g.) Lemmy, assuming that I won’t ever need official support, but I wonder why the world outside a limited subset of the Linux ecosystem is - at most - an afterthought for Fediverse developers.

How can I help to change that?

  • dan@upvote.au
    link
    fedilink
    English
    arrow-up
    1
    ·
    2 years ago

    Calling Docker “modern” is a stretch, as it’s not much more than glorified Solaris Zone

    And yet the OS you’re using doesn’t support it. Hmm.

    OpenBSD does not have jails.

    Sorry, I didn’t realise that these are FreeBSD-specific (I guess? I’m not too familiar with BSD)

    Which feature of a federated web application requires modern tooling?

    Deployment. All web apps and APIs are moving towards containerization - Docker for smaller scale deployments, and Kubernetes for large-scale deployments.

    except with better isolation How so?

    I didn’t think jails had CPU, memory, or process limits similar to what cgroup2 provides, but it looks like this functionality was added to FreeBSD at some point. Sorry for the incorrect information.

    Actually, not using Docker prevents a number of security holes/issues.

    Sure, Docker has had a few issues, but overall it’s more secure to run your apps in Docker containers. If an app gets compromised, the attacker will generally be stuck inside the Docker container rather than getting access to your entire system. If you’re worried about (very rare) container escape security holes, using unprivileged containers helps - You can run the app inside the container as an unprivileged user, and you can also run the entire Docker container as an unprivileged user on the host system.

    And security patches impossible.

    Security patches are easier than if you used a tar archive to install the software. With a tar archive you threw into /opt or whatever, the app and its config/data are often stored together, so you need to be mindful of things like not overriding customized config files. Since Dockers containers are immutable and all the actual data is stored elsewhere, it’s always safe to delete the container and replace it with a patched version.

    • rhabarba@feddit.deOP
      link
      fedilink
      English
      arrow-up
      1
      ·
      2 years ago

      And yet the OS you’re using doesn’t support it.

      It would, but Docker doesn’t support it. I’m not sure how this means that the OS was worse.

      Sorry, I didn’t realise that these are FreeBSD-specific

      They are, including its descendants (that includes the FreeBSD 4.8 fork DragonFly BSD).

      Deployment.

      How is “run this black box of arbitrary software, requiring a kernel module and numerous services” a superior deployment than tar xf application.tgz? Just because people do it, people could still do the wrong thing. Not every website is Facebook.

      Sorry for the incorrect information.

      No problem. I was genuinely curious.

      Sure, Docker has had a few issues, but overall it’s more secure to run your apps in Docker containers.

      Docker imposes additional attack vectors to the underlying system, a (for example) backdoored PHP application running inside an OpenBSD chroot (OpenBSD runs its built-in web server inside chroot by default, so web applications can never reach anything outside the web folder anyway) does not, if I understand you correctly. I know that you consider the 1979 technology chroot to be not modern, but I wonder which security feature is missing.

      Since Dockers containers are immutable and all the actual data is stored elsewhere, it’s always safe to delete the container and replace it with a patched version.

      What if nobody maintains the container anymore, although the software itself is still maintained?