Rootless Docker Compose with Podman
March 30, 2023
I have to open by acknowledging the proverbial elephant in the room. In Australian slang, Australia being where I'm writing this, root is one of the many (many) euphemisms we have for sex, and it's used much like other equivalent slang terms. As in the insult "get rooted", which means just what you think it might. The teenage boy in me would demand nothing less than full disclosure on this score.
Docker turned openly evil a few weeks ago. More so. They've threatened to delete "unused" containers before, but now it's open source they're targeting. Docker's actions should at the very least mean everybody using containers should be thinking hard about their software supply chains, because some relied upon piece of open source software's likely to no longer be on Docker Hub just when it's needed most. Docker's also fostered some very bad DevOps habits around running containers as root (tee hee). So as often happens, a good story's gone bad.
Both of these problems, of not running containers as root, and of not relying on Docker Hub, could perhaps eventually be solved by using RedHat's Docker alternative Podman, but it's not quite there yet. Podman itself seems OK. In my limited experience of it by itself it works much like Docker does, except that it's also easy to point it at different container repositories. There's the problem of what those repositories will end up being, because I suspect it's likely to mean relying on the good graces of Microsoft & GitHub instead of on Docker, but I didn't get far enough along to worry about that yet. Problems rapidly mounted when I tried to get Docker Compose to talk to Docker as a non root user.
Docker without Docker Compose means a lot of one-off scripting, or worse, cutting & pasting commands. It's not a production ready solution by itself. Podman likewise. People do it, you can do it, but I wouldn't. Docker Compose should be able to talk to Podman over a REST API, but as far as I can tell everything needs to run as root, Docker-style, for that to work. On Debian any way. I haven't tried this on Fedora, perhaps it's possible to make it work there, but the documentation story is, well, almost completely nonexistent, so I don't know.
Because this is obviously a moving feast it's worth pointing out this was with Podman v3.0.1 from Debian 11 Stable, and Docker Compose v2.17.2, which was the latest on GitHub at the time. I tried to build Podman from source to get a more up to date version, but no dice. I also tried to get a more up to date version of Podman out of Debian Testing and Unstable, and that's when bad things happened. Mixing C libraries like a fool, very bad things happened. I broke it. Everything. I saw the Debian sad PC screen. I had to reinstall Linux. Again.
I'm on the Debian Stable train for now, so I'll wait. Once it's all more stable & better documented Podman feels like it's going to be the future. There is a Podman specific version of Docker Compose too, Podman Compose, but I didn't try it. It calls Podman commands directly rather than via the REST interface so maybe that would work. The little I read about it said using it means rewriting Docker Compose files though, and that's not going to happen for me until Docker ramps up its evil game some more. So, some time soon I suppose.
BTW I use Debian now
March 27, 2023
Well that didn't last long. It was only in October that I switched from Ubuntu to Fedora, and late Friday afternoon, just as I was wrapping up something I'd been working on all week, boom, Fedora died. To be fair it could've been anything on the box, but whatever it was was killing Gnome so it didn't really matter what it was, at the very least Fedora let it happen. That sort of thing never happened to me on a Mac in thirty years of using them, & hasn't happened to me on Windows in a long time. On Linux desktops it seems to be at least an annual event for me. Maybe I'm just lucky.
Luckily (not ironically this time) the cost of reinstalling & of changing distros is pretty small. Set your /home folder up in its own partition to root & swapping out the OS becomes a lot easier. So I spent the weekend distro shopping. Again. Maybe I should do that annually even when I don't get forced into it, just because I can.
I wanted something less cutting edge than Fedora this time. I thought about the rest of the RedHat stack, but not for very long. I'm not even sure I understand what CentOS is meant to be now that it's CentOS Stream, & I'm not convinced RedHat do either. So I didn't go there.
I did spend all of Saturday pleasantly prodding away at Arch. It's the exact wrong thing for what I was aiming for, but I've wanted to know what was involved in a completely manual install for a while, & I wanted to know I could do it. I suspected I could, but actually doing it's a different thing altogether. Any way, now I've done it. Tick. Arch, from nothing to a working set up in only six or seven hours.
The Arch installation guide's pretty good if anyone's tempted. Mostly I just followed along to that with the occasional diversion to investigate how various unixy tools that I've taken for granted for years work (usually) behind the scenes. The guide probably needs to mention that you need to install & configure grub on your way through, it implies that it's there, but like everything else in Arch it ain't there unless you put it there. Likewise, once you chroot onto your new system & go to edit the config you're going to need to install nano or similar, because 2MB worth of text editor's more bloat than those guys were willing to put up with out of the box. It's all completely bonkers, but quite wonderful. Having done it once I never need to go back there again now though. Not without scripting it at the very least.
If I was going to use Arch it'd probably be as one of the derivative distros. Likely EndeavourOS, that's pretty close to what I ended up with doing it all by hand, but it has an actual installer. Takes twenty minutes instead of hours to get up & running. Still, Arch's bleeding edge rolling releases aren't what I'm after. For now any way. I might get bored, but for now entertainment isn't what I want out of my OS. I have stuff I want to get done, & I want an OS that gets out of my way.
I did look into Mint. It seemed pretty good, but the giant sucking black hole of Canonical wasn't quite far enough away for my liking. I wasn't thrilled by the ad for Netflix in the installer but that was small beer in comparison. I also looked at Linux Mint Debian Edition (what a name!) which promised to solve the Canonical problem. It's Mint but derived straight from Debian rather than from Ubuntu. But I couldn't get it to work reliably. Something was wrong with the boot, grub misconfigured by the installer maybe. I was pretty punch drunk after Arch, it may well have been me, but for me it didn't work.
So, rapidly running out of weekend at that point I went with Debian. It was always going to be Debian. The least hipster solution possible. Which is just what I set out to achieve. I've used it on servers for years, because it was usually just the right sort of boring for the job. Boring also sounds pretty good to me for a desktop solution now too. If you're also tempted & until Debian 12 comes out then like me you'll likely need the "experimental" install, the one with proprietary drivers on it, but that's the only trick. I put an alpha release of Debian 12 on an old laptop just to see where I'd be in a year or two if I stay with it & it seems to be pretty good already. With Debian 12 the normal install disk will have all the required stuff on it too.
I logged in this morning, ran my usual update scripts, & there was nothing to change. That's what I'm after.
A Ruby interface for the Mastodon API
February 17, 2023
Ruby's library for dealing with Mastodon's API's been left languishing for years. The last release was in January 2019. There are plenty of libraries for dealing with the API written in other languages, complete with web pages & example code. But the language Mastodon's written in? Not so much.
What's especially annoying about this is people have submitted code, but it's been left to sit there, unreviewed. We can still benefit from those other people's hard work though.
I forked one of the forks & merged another fork's code into it to get the two missing features I especially needed, namely the ability to run on a version of Ruby newer than 2.6, and the ability to deal with paginated results.
You can require that version:
gemfile do
source 'https://rubygems.org'
gem 'http', '~> 4.0'
gem 'mastodon-api', git: 'git@github.com:mikekreuzer/mastodon-api.git', branch: 'merged-forks'
end
require 'mastodon'
Then after setting up a client in the way suggested in the original README, get paginated results by looping over the API's responses, something like for example:
next_max = nil
results = []
loop do
data = client.followers(ID, { limit: 80, max_id: next_max })
next_max = data.next_max_id
results += data.to_a
break if next_max.nil?
end
That code could be abstracted out into a method where you only had to request a number of replies or even no particular number expecting to get all of them, and if there was paging to be done it'd happen under the hood. Pretty easily too.
But that's left as an exercise for the reader, for the same reason I haven't merged the feature branch into main on that forked repo, or renamed the gem & pushed it to RubyGems as a standalone thing. That way lies madness. Or at least open source obligations I'd also be glacially slow to meet.