Mikeserv Support Forum

I had to set up Docker for a Proton build... my proton-tkg isn't tooled for a native build yet, for Valve's new Proton 11 Experimental Bleeding Edge. I was working around failures and almost had it, but the show stopper was that the scripting wasn't set up for the right --libdir. With Wine 11, the 64 and 32 bit files go to the same libdir (not lib and lib64, or lib and lib32, but subdirs within lib/wine for i386-unix, i386-windows, x86_64-unix and x86_64-windows and the 32 bit build has to be installed before the 64 bit. I could change libdir, but the scripting would need to be right for prefix creation/updating. Proton does that manually, not with "winecfg" so the paths would need to be correct.

So for now, I had to build it with Valve's tooling in a Docker container. It's quite the kludge, it checks out hundreds of things and builds the environment and libraries in the container (good) but then at runtime it's going to link against the environment in the Valve Sniper 4.0 runtime container (what a waste). It wasn't too bad for time though, my whole build including populating the container, compiling libraries and all the components of Proton 11 still only took about 33 minutes (as opposed to about 10 minutes for a normal proton-tkg build including checkouts)

Anyway, Docker. I just used the distro package (I don't intend for this to be permanent) but I had to rebuild my kernel for it (and I had just done 7.0.1 a few hours prior). Docker needs full cgroup support, including for BPF programs. It also needs "virtual ethernet pairing" (veth), which I don't normally enable, to create and link two bridges. I don't mind that one, I can build it as a module and it doesn't load until needed (doesn't load automatically at boot) but I DO mind having to add the cgroups. I fake that, only enabling cgroup support itself so systemd can mount /sys/fs/cgroup. I'm likely to disable the cgroup controllers again when I'm finished playing with this build method. I might do another build today, to see if I can do more to control the build. I hate a black box.

So, I have the docker daemon set up to start through a systemd socket (docker.socket) on demand, rather than enabling docker.service, and the veth module loads on demand, so none of this will bother me when it's unused. Except for the cgroups, that can only serve to throttle my i/o (nothing good will come from that, for me). It likely doesn't do me any harm, but I know it's there (systemd has the potential to throttle me through that) and I don't like it. It only takes me 2 minutes to rebuild a kernel (and I have the whole process interactively scripted now) so I can enable/disable that shit as needed.

In order to run this as a user, I have to add myself to the docker group. This has privilege escalation potential, but I'd rather do that, than run build scripts as root. It can also be setup to run in a user namespace using newuidmap and newgidmap (with files subuid and subgid granting namespace permissions to users by mapping subordinate UID/GID's) much like Podman, but that's a pain in the ass for a temporary kludge, for me. I don't intend to pursue a career using Docker or anything.

This is wasting valuable disk space on my rootfs though... I've got ~10Gb of crap in /var/lib/containerd now that's all but hidden from me. (I can go in there with root privileges but it's databases of shit in multiple directories). I can remove all containers with "docker containers prune -f" as long as they aren't running when I want to clean up after this, though. I sure don't want THAT going into my backup tarballs.

I really don't like containers, but what motivated me was wasting hours without any finished product. I had to come away with something!

As long as it works

My local file server is a Debian container running in Proxmox. The Proxmox machine has been overkill for that, I haven't been using it for anything else, no VM's etc like I had planned, and like I used to do. It's an 11 year old Xeon E5-2660 v4 @ 2.00GHz with 128 GB ECC DDR4 hosting a Debian container using 2 cores, 4 GB RAM and 2 TB dedicated drive space out of the 8 TB available (ZFS RAID). I've thought about moving to a smaller, cooler, more energy efficient setup.

Definitely overkill for just running an OS for a local file server (no need for the container overhead in that case anymore either... you could run that bare metal). However, a cooler, more energy efficient setup would be to shut it down when you're not going to be accessing it (or set it up to sleep and wake on LAN or something) rather than retire something that good

P.S. I also got to thinking, that I'd want much more than 4 Gb of RAM even for a local file server, because I wouldn't be able to keep much in the page cache and my kernel would start allocating swap. That's something you can do right now, allocate more RAM to it. Or maybe it doesn't much matter, because it's a container, not a VM and the host would have the files you're accessing cached.

Arch fucked me already... the docker 29.4.2 update package broke my builds, wine unable to create a socket in the container, and hence unable to generate default wine prefix.

I rolled up a docker 29.4.0 package, the original version I had installed, and it works again.

I almost can't trust distro packages for anything in this distro... yet another thing I have to take control of. I know very little about docker, too, I'm just lucky it works.