From dab7a7053916e80dba2c7dca4714780b149f9f75 Mon Sep 17 00:00:00 2001 From: Daniel Olsen Date: Mon, 27 Apr 2026 05:40:08 +0200 Subject: [PATCH] mm publieesh --- .gitignore | 2 + config.toml | 11 +- content/2023-08-11-thoughts-on-docker.md | 230 +++++++++++++++++++++++ content/2024-08-10-minecraft-gpl.md | 163 ++++++++++++++++ flake.lock | 10 +- 5 files changed, 410 insertions(+), 6 deletions(-) create mode 100644 content/2023-08-11-thoughts-on-docker.md create mode 100644 content/2024-08-10-minecraft-gpl.md diff --git a/.gitignore b/.gitignore index 69aaac0..59aef8e 100644 --- a/.gitignore +++ b/.gitignore @@ -1,3 +1,5 @@ themes/ public/ static + +result diff --git a/config.toml b/config.toml index d24cce0..99e3168 100644 --- a/config.toml +++ b/config.toml @@ -24,8 +24,15 @@ taxonomies = [ ] [markdown] -highlight_code = true -highlight_theme = "base16-ocean-dark" +# render_emoji = true +github_alerts = true +bottom_footnotes = true + +[markdown.highlighting] +error_on_missing_language = true +style = "inline" +# theme = "ayu-mirage" +theme = "andromeeda" [extra] # Put all your custom variables here diff --git a/content/2023-08-11-thoughts-on-docker.md b/content/2023-08-11-thoughts-on-docker.md new file mode 100644 index 0000000..5111d85 --- /dev/null +++ b/content/2023-08-11-thoughts-on-docker.md @@ -0,0 +1,230 @@ ++++ +title = "My Thoughts on Docker" +date = 2023-08-11 + +slug = "thoughts-docker" +[taxonomies] +categories = ["All", "Technical"] +tags = ["Docker", "Networking", "Homelab"] ++++ + +# My Thoughts on Docker + +Docker is a tool that uses kernel level namespaces +to isolate processes from each other. +This tool allows users to create a consistent\* runtime environment +for their program that can run on any computer with the right kernel +and hardware without having to consider the rest of the userspace. +This is what most people, including me, would largely consider a _good_ thing. + +In addition to this, docker has evolved into the OCI-Standards, +and you can now run docker containers with a myriad of tools, +such as podman or kubernetes. +In this post I'm going to argue quite heavilly against using docker for "normal" small server deployments. +If you have a microservice oriented software stack which you designed to to run on a big cluster orchestrated via containers, +most of these arguments won't apply. +But that's not what most people using docker in a homelab environment do. +I'm also not going to talk about swarm and bigger cluster orchestration services. +They require setups too homogenic for it to be useful to me personally, +I might do a follow up post on why I feel this way. + +## What does docker provide? + +As mentioned before, docker provides namespace isolation, +it's important to note that this is not the same as providing security. +It probably helps if you set it up correctly, +but it's not explicitly designed to provide security between the host platform and the running environment. +To accomplish this you need some sort of hypervisor. + +The containers get spun up via container images, +these images can be downloaded from the internet or be built by you. + +Docker provides a way to build container images via a "Dockerfile" +which provides a little recipe docker can follow to build the required environment +and configure the command which should run on start-up. + +When it comes container orchestration, +docker allows you to manage your containers, +start new ones, delete old ones, attach filesystems - "volumes" in docker-speak, +stop them, set up networking connections and so on. +It has a few different ways of accomplishing this but the most used one is probably `docker compose`. + +docker-compose files are a declerative way to define what containers should be running, +what volumes they should have, virtual networks they should each be in, and the whole `#!`. + +Declarative systems like this makes it very easy to move the configuration from one place to another. +It means you can just move the docker-compose.yml and whatever volumes you had for your state, +and everything will hopefully just work! + +## Problems with Docker + +I used docker for my homelab for a couple years and was heavilly invested in the ecosystem. + +Nowadays very little of that setup remains. And I will touch upon some of the reasons why here. + +### Yo dawg I heard you like init Systems + +Docker requires an always running daemon which manages the state of the running containers. +It'll do things like restart containers if they crash. +It will also make sure the right containers +are started when your computer boots up, +and probably lots of other internally important tasks. + +That should probably remind you of another daemon on your system +which do many of those same tasks, namely systemd. +We'll get back to that later. + +#### Dependency management + +In any kind of infrastructure there are _a lot_ of interconnected systems, +which very often depend on each other: +A network interface needs an ip adress, +a filesystem needs mounting, +a database needs to go through an initialization sequence and become available. + +Docker has a good answer to dependencies on other containers +(often limited to whether or not the container is running, not whether it's healthy), +but have little to no knowledge of any externalities. +This will lead to problems if you let docker decide whether or not start your container. + +You already have an init system that knows the status of most everything in your system, +wouldn't it be nice if you could use that knowledge to start your services? + +There are even docker images out there which themseselves include an systemd or another light-weight init system. +Some alarm bells should probably be ringing once you're three levels deep. + +Again podman actually plays fairly nicely with this. +It's possible to use podman in systemd units and reap the benefits of systemd as lifecycle-management and containers as namespace isolation. + +###TODO INFO BOX +### Did you know systemd has a built in container engine? + +`systemd-nspawn --oci-bundle` can run oci images! + +### Logging + +`journald` has blessed us with nice extensible binary logging, +unfortunately without some workarounds docker will output all logs from its executables to stdout. + +Most docker images are also set up to log with time and date, loglevel, and other such metadata in each logmessage, +something we've moved away from on "real linux" since syslog. + +Not being able to quickly filter on loglevels, +and the "unit" responsible for the logger often being some weird cryptic container-id that changes run to run, +means any docker container on your system will spam your logs. +Requiring much fancier log-ingestion services that try to parse the output and reclassify it with metadata + +Just using the normal logging features available with journald is a lot better. + +### Network mangling + +Docker uses virtual network card bridges, and a whole lot of them. +This is kind of aesthetically unpleasing, but there's nothing directly technically wrong with it. +One gotcha however is that all that port forwarding magic needs to happen in nftables before it reaches those virtual NICs. +Those iptables rules get added to whatever configuration you had from before and will in most distros take priority.. + +That means any firewall settings you have mean _nothing_ to docker. If you say `-p 8000:8000` port `8000` will be open the internet; perhaps without you intending it. +That's how it has to work so this is understandable, but it's fair to mention since it trips people up, and makes your firewall rules a bit of a mess. + +Inspectability/tractability is imporatant here! + +### Debugging + +Debugging containers can be annoying. +You need to optimize for image size since this has a multiplicative effect on storage, bandwidth, and time. + +Unfortunately that means when you shell into a container you might just end up with a bourne-shell and not much else. + +With "normal" unix tools, you can just inspect all files as root, it's not perfect, especially not when you need to debug the environment itself, +but in most cases it is easier to use your familiar tools from the "outside" of the service. + +### User and group ids + +All our programs are being ran as root, or alternatively using uids managed by hand. +Programs generally don't need to be ran as root, and managing uids by hand is annoying at best and impossible at worst. +As some images make a lot of assumptions around this. + +Managing state can also be bad, there's nothing built in to take care of chowning data to the right ids, +and sharing files between containers can be very complicated. + +Some of this is inherent, but systemd has good alternatives with `DynamicUser=`, and `Group=`. + +### Turtles all the way up? + +You start with an OS, but install docker to deal with the difficulty of managing correct runtimes and state. +Then you start orchestrating with compose, but as you realize the shortcomings of that approach you spin up a single-node kubernetes cluster. +Kubernetes turns out not to solve everything either and now you're using rancher, or some other init-ish-system like helm, +or alternatively maybe something simpler like a templating language you can use with kubectl. + +I think it's healthy to be skeptical of soulutions which claim to solve your woes simply by adding another layer of abstraction. +Sometimes infrastructure and software just is complicated, and only adding layers to it isn't a sustainable approach. +Do it right from the start and you might not need to add so many management-layers on top. + +### Using docker as your package manager + +This is why most people _actually_ want to use docker. + +Im sure if you ask a homelabber the reason they use docker, it will be be beacause it makes setting up software easy. +You only need one look at docker hub to see this. +A lot of the most popular images are software stacks wrapped in shell-scripts that for better or for worse make spinning up and configuring them very simple. + +#### Poor Quality Images + +Images are made by anyone. +Sometimes that's upstream developer of a program, who might be motivated by making the software easier to test. +Sometimes it's a user who just wanted to make their usecase work. +Sometimes it's a organization of packagers, like linuxserver.io + +This leads to users having a lot of choice, which can be good! +But it in practice also means it's on the users to make sure they're using a good image which is kept up to date, +is secure, and exposes the right configuration options. + +There are no standards here, so each container you spin up comes with their own gotchas, +and sometimes act like an entirely new ecosystem to dive into. + +This isn't a big deal when you start, but becomes one whenever something goes wrong. + +Not to mention having to validate all the image providers for trustability! + +#### Updates + +Updating software is a very important aspect of package-management. +Gernerally the simplest way is to rely on the image tag. +`latest`, or if you're lucky the maintainer of your image could be making tags like `-` allowing you to pin your images to certain channels. +Then using `docker pull` to re-deploy your software. These tags are different for every image you use. + +That's not the whole story however. +All software has dependencies, and these also require updating. +This relationship isn't captured by docker infrastructure. +The program you're running might not have gotten an update in a couple of months - so there aren't any new releases of the image either. +That means you end up running months old versions of `openssl`, or `glibc`, or any other library or program your software depends on. + +Relying on each image maintainer to rebuild images routinely is a poor solution for a package-management system (something docker therefore does not replace!). + +#### Inspectability + +This is related to the issues above. Whenever there is a security issue somewhere in the stack, how can you make sure you're patched? + +You have to look into how the end-user software is built and included in the container: + +From another package-manager? Built from source then cleaned up? Downloaded from a binary release somewhere? + +Then your containers are built at different times, was the patch included in the repository of the base-image at that time? + +Then your containers are built with different base-images following different release channels, or even completely different package-managers and repositories! + +This information isn't recorded anywhere and you must piece together the information from `Dockerfile`s (if you have them), upstream repos, logs, and historical time information. + +## What to use instead + +I want to say, you should be using NixOS... +The union of systemd and Nix solves all the problems docker _should_ solve while also avoiding the pitfalls of the solution. + +This is a hard ask though, of beginner homelabbers, or people who just need their stuff to "work". + +Maybe the answer is to just not deploy so much software, or prefering things available in your distribution. +Or better yet making your own images/packages. + +In any case you probably need to learn more about the systems that run your applications, and take more direct ownership of it. + +Not because doing so is something extra docker provides, but because these are things you should be doing, which docker does not! diff --git a/content/2024-08-10-minecraft-gpl.md b/content/2024-08-10-minecraft-gpl.md new file mode 100644 index 0000000..a0d8d98 --- /dev/null +++ b/content/2024-08-10-minecraft-gpl.md @@ -0,0 +1,163 @@ ++++ +title = "Minecraft is GPL" +date = 2024-08-10 + +slug = "minecraft-gpl" +[taxonomies] +categories = ["All", "Legal"] +tags = ["Minecraft", "Licensing"] ++++ + +# Minecraft is GPL + +> [!WARNING] +> I'm not a lawyer! +> This post is meant to be a fun history lesson and thought experiment, +> \- or maybe a parable - around a complex licensing situation. + + +## Preamble + +Bukkit was a very popular modded minecraft server licensed under GPLv3 and LGPL. + +Throughout the first half of the 2010s +it was the defacto standard minecraft server implementation in use, +and its forks and api are still going strong today through projects like spigot, +paper, and glowstone. + +## The Licensing Situation + +Bukkit was two projects, +the API (licensed under GPLv3), +and CraftBukkit (LGPL): +a modded mincraft server wich exposed this API to enable making plugins. + +If you know anything about Free Software licenses, +you might be able to tell that this is already pretty problematic. + +CraftBukkit - which depends on Bukkit +is licenced under a _more_ permissive license than Bukkit. +Thus distributing CraftBukkit under the LGPL (as a whole) +would be a violation of Bukkit's license. + +Maybe this could be overlooked - I mean, it's the same project +and no one contributing could be thinking their contributions weren't +intended to end up in CraftBukkit. +Besides in the worst case all that has to be done +is for the whole to be released under GPLv3 - Something the LGPL generally allows. + +> [!NOTE] +> Since the Bukkit API (and library) is GPLv3, +> techincally all plugins are probably also GPLv3? + + +Unfortunately CraftBukkit is more than just bukkit. +The distribution is more like Bukkit (GPLv3) ++ CraftBukkit (LGPL) ++ Minecraft (Proprietary) + +Not only does it link to Minecraft, +it includes decompiled code, +and most of it could definetly be construed as a derivative work of it. + +This makes the distribution itself a straight copyright violation. + +That would be that, +and the argument is that CraftBukkit +not being able to be released under the GPLv3 voids the license. + +All authors have copyright for their contributions +and have never had license from any other contributor +\- Just like they didn't have a license for Minecraft. + +Anyone could at will DMCA anyone. +Which as you will see, is what happened in the end. + +## How did this happen? + +The bukkit project was so successfull that eventually +[their core developers were hired my Mojang](https://web.archive.org/web/20120310061720/http://forums.bukkit.org/threads/bukkit-the-next-chapter.62489/) +\- the owners of Minecraft, +just two years after the project was started. + +After this, +[three out of](https://github.com/Bukkit/Bukkit/commits?author=Dinnerbone) +the [four core developers](https://github.com/Bukkit/Bukkit/commits?author=grum) +stopped [working on bukkit](https://github.com/Bukkit/Bukkit/commits?author=tahg). +The one that remained active in the bukkit project left Mojang 20 months later. + +> [!NOTE] +> Unfortunately the CraftBukkit repository is not available due to a DMCA, +> therefore I can't link to a more busy repository. + +It's clear that Mojang is very much aware +of the copyright infringements taking place at this point, +and are really enabling and directly endorsing it. + +[Then in 2014 minecraft changed their terms and conditions to include language that disallows distributing mojangs work, and bukkit decided to shut down.](https://web.archive.org/web/20141125024150/http://forums.bukkit.org/threads/bukkit-its-time-to-say.305106/) + +This made Mojang and the ex-bukkit developers spring into action. +[Here's a summary from the mojang developers themselves](https://web.archive.org/web/20140914010750/https://storify.com/lukegb/the-tale-of-bukkit-for-minecraft-1-8), +including tweets from the lead developer "Jeb_". + +They were suddenly revealing that +when the bukkit developers were hired two years earlier, +they also "bought bukkit", +and would be updating it themselves, +insisting the project was not shut down. +And that bukkit had a "special relationship" with regards to the EULA + +This surprised and angered a lot of people who +were working under the assumption that bukkit was a community lead project +and not beholden to Mojang +(apart from the copyright violations looming over them at all times). +[Including one developer who decided to DMCA the project](https://github.com/github/dmca/blob/master/2014/2014-09-05-CraftBukkit.md) + +## And now for the epilogue, or rather, the punchline + +However, CraftBukkit was released, +as a whole under the LGPL (really GPLv3), +for 2.5 years _while_ being owned by Mojang. +It might be fair to say that +the copyright holder of minecraft was the one releasing it. +This is even suggested at with the "special relationship" according to Jeb_. + +The only legal way for this to be done +is for minecraft to be at least LGPL-compatible. +Such that CraftBukkit could be released by Mojang +(or at least their subsidiary) +as GPLv3. + +Mojang certainly had the rights to publish minecraft +under an LGPL-compatible license. +Bukkit's LGPL code can be linked to in a work licensed as GPLv3. +Thus Minecraft Java Edition 1.2 to 1.7 is free software. + +Unfortunately +(contrary to horrifyingly common practice in the free software community) +licenses don't really act automatically like this, +the most restrictive license in the chain +(plus whatever ownership the distributor actually has) +isn't what actually counts. + +## Post Scriptum + +The most glaring hole in this logic is that more than likely +Mojang "owning bukkit" was limited to the trademark, +and maybe the contributions of the developers who joined Mojang. + +Bukkit was an informal organization, +not a legal entity, and even if it was, +a subsidiary does not automatically get the rights to their parent's assets. + +The way Mojang communicated during the situation +is hard to decipher in regards to exactly what "owning bukkit" means. +And the tweets of some employees +(even high ranking ones) +might not have that much legal sway + +So it's entirely possible that bukkit +\- even during this timeframe - +did not actually have the right +to publish CraftBukkit under a theoretical GPLv3. + diff --git a/flake.lock b/flake.lock index 6fdb1c5..c083022 100644 --- a/flake.lock +++ b/flake.lock @@ -18,10 +18,12 @@ }, "nixpkgs": { "locked": { - "lastModified": 0, - "narHash": "sha256-xKel5kd1AbExymxoIfQ7pgcX6hjw9jCgbiBjiUfSVJ8=", - "path": "/nix/store/ylrrz211xgjzkcpyiafpq9y2yws7fyah-source", - "type": "path" + "lastModified": 1776949667, + "narHash": "sha256-GMSVw35Q+294GlrTUKlx087E31z7KurReQ1YHSKp5iw=", + "owner": "NixOS", + "repo": "nixpkgs", + "rev": "01fbdeef22b76df85ea168fbfe1bfd9e63681b30", + "type": "github" }, "original": { "id": "nixpkgs",