Five Guys have better service that is free

It wasn’t free — they were charging money for it:

Jetflicks, which charged $9.99 per month for the streaming service

Yeah, take a look at the solution at the top of the post.

so might run into more roadblocks with its use.

This has been my experience with Podman. That’s not to say that these roablocks aren’t without reason, nor merit, but there is always a trade off of convenience when optimizing for security.

Podman is […] “better” because it doesn’t run as root, but other than that I don’t know of any advantages to it that are not a derivation of “it runs as a regular user”.

Podman can run in rootless mode (with some caveats), but it is still able to run as root — it doesn’t only have the capability to run as a “regular user”.

I am curious what kind of performance you’re seeing for DNS requests considering how old and anemic the first gen Pi is

I haven’t done any rigorous tests to gather empirical data for an accurate comparison, but, annectdotally, it, at least, doesn’t feel any slower than when I had my router (Linksys E8450) resolving to Cloudflare.

I could be misunderstanding your comment, but you don’t seem to have answered my question of why I don’t see my rules anymore.

Now that it is up and running, do you think it’s is a good service?

That’s a good question. The service itself is well made — it functions as advertised, it has satisfactorily intuitive UX, a sizeable community, and a good amount of documentation. I’m not sure, yet, if it’s a service that I personally need — I set it up mostly for the benefit of others.

While you may not like the setup

The main pain points were the sparse, vague, and misleading documentation that I encountered — I understand that documentation is difficult, but for a company like Raspberry Pi, my standards, and expecations are quite a bit higher. I probably won’t use Podman anymore, as I don’t find its setup overly user friendly, currently, as compared to something like docker. I had never used Podman before, and I was considering switching my existing services over to it, so this was sort of meant to be a trial run on something with little impact. I will keep an eye on Podman, but I will stick with Docker for the time being.

do you enjoy the results?

I personally don’t notice its effects as much, but I do like what I’m seeing for others. It has also made me aware of some other issues that I’ll have to look into, so that is good.

It’s a raspberry pi 1. Those things have 256mb of RAM

The exact model that I am using, which I referenced in my post, actually has 512MB of RAM.

Given the extremely limited resources: why bother with containers?

While, from what I can see, containers virtually don’t add any resource overhead, it’s honestly moreso that I favor consistency. Containerization is well documented, it is well supported, and its behaviour (if one is familiar with the platform) tends to be more predictable than running a service natively.

See the post for the solution.

If you are interested, a solution was found. See the post for the update.

See the solution in the post.

See the solution in the post.

See the solution in the post.

You can always do what I do, and just blow up the install and start fresh.

This may be what I’ll have to do. I just don’t understand what’s going wrong here. It’s so strange.

Yup. I ran # nc -u -l 0.0.0.0 53 to listen on port 53. Then I ran # drill @127.0.0.1 53 archlinux.org in another shell. I saw the request in the listening shell.

You still running into trouble?

Yes.

Are you able to run ss -alnp as root?

I have already tried checking if something is listening on 53 in about 10 different ways. That command yields the same outcome as before — nothing appears to be listening on 53.

I appreciate the suggestion, but I have already tried essentially all alternative network commands to see if one might yield a different result. They, of course, all show the same things — nothing is listening on 53. That command specifically only shows that sshd is listening on 22, which is expected.

If you read the post, I already did that. It shows no device using port 53.

That is not the solution. As I have already mentioned a number of times, I am running the container in priveleged mode — I am running the container as root. It has access to all ports.